A titkosított átvitel nem ad hozzáférést a szolgáltatóhoz

Két jóváhagyott átjáró továbbítja egy alacsonyabb bizalmú hálózat forgalmát egy korlátozott átviteli hálózaton keresztül. A hasznos terhelés titkosítása olvashatatlanná teszi azt a szokásos átviteli megfigyelők számára, és ez az a rész, amelyet az emberek először terveznek meg, majd abbahagynak rajta gondolkodni. Amit a titkosítás nem tesz meg, az annak meghatározása, hogy az alacsonyabb bizalmú oldal mely erőforrásokat érheti el. A tervezésnek két határvonalra van szüksége: az egyik a továbbított beszélgetés körül, a másik magához a szolgáltatóhoz való hozzáférés körül.

Hajtsa végre az alábbi lépéseket sorrendben, és tekintsen minden lépésnél fellépő hibát tervezési változtatásnak, nem konfigurációs módosításnak.

Határozza meg mindkét határvonalat, mielőtt konfigurációhoz nyúlna

Az első határvonal a beszélgetés: mely átjárópárok hozhatnak létre alagutat, és milyen belső forgalom haladhat át rajta. A második a szolgáltató: mely címeket és szolgáltatásokat érhetik el az alacsonyabb bizalmú gazdagépek az alagúton kívül. A csapatok általában az elsőt építik meg, a másodikat pedig öröklik bármilyen útvonalválasztásból, amely már létezett, és így egy korlátozott tervezés csendben szélesedővé válik. Ez az örökség a szokásos kiváltó ok, amikor egy felülvizsgálat azt találja, hogy egy alacsonyabb bizalmú gazdagép olyasvalakivel beszél, amit senki sem hagyott jóvá.

Írja le mindkettőt címek, portok és irányok listájaként. Ha egy lista nem írható le, a határvonal még nincs meghatározva.

1. lépés: korlátozza a külső alagutat

A szolgáltató felé néző interfészen csak azt engedje, amire az alagútnak szüksége van: IKE-t UDP 500 és 4500 között a két átjárócím között, és ESP-t ott, ahol nem használnak NAT-átjárást. Tagadjon meg minden mást, ami ezen az interfészen érkezik, beleértve a felügyeleti protokollokat. ESP-specifikáció a védelmi szolgáltatásokat fedi le; semmit sem mond arról, hogy az átjárók mely saját szolgáltatásait használhatják a szolgáltatónak. Fejezze ki ezt explicit engedélyezési listaként, hogy egy nemrég közzétett szolgáltatói szolgáltatás ne váljon alapértelmezés szerint elérhetővé.

Ez az a szabálykészlet, amely a tervezést átviteli tervezéssé teszi, nem peering-megállapodássá.

Ellenőrizze az alacsonyabb bizalmú oldalról, ne az átjáró konzoljáról. Egy ottani gazdagépnek már az alagút felállása előtt sem szabadna elérnie a szolgáltató DNS-kiszolgálóját.

2. lépés: döntse el, mit szállít a távoli átjáró

A távoli végponton a helyreállított forgalomnak egy meghatározott helyre kell mennie. Határozza meg, mely belső szolgáltatások engedélyezettek, mely forrástartományokból, és hogy a válaszok szimmetrikusak-e. Vizsgálja felül külön a felügyeleti hozzáférést, mert ugyanaz az átjáró gyakran olyan adminisztratív interfészt tesz elérhetővé, amely soha nem volt része az átviteli tervnek.

A sikeres visszafejtésnél megálló ábra kihagyta a legfontosabb döntést.

3. lépés: tartsa meg a tulajdonjogot rétegenként

Az átviteli berendezés továbbra is fogad és továbbít külső csomagokat, ezért javításokra és kapacitástervezésre van szüksége. Az alagút végpontjai a védett protokollt dolgozzák fel, és belső forgalmat tesznek elérhetővé a továbbítási útvonalukon, ezért saját szabályokra és saját megfigyelésre van szükségük. A végleges alkalmazások a hasznos terhelést dolgozzák fel, és az átlátszatlan terhelés nem bizonyíték arra, hogy egy visszafejtett letöltés ártalmatlan.

Rendeljen tulajdonost minden réteghez. A tulajdonos nélküli rétegek azok, amelyek elsodródnak.

4. lépés: ellenőrizze, majd adja át a hatóságnak

Ellenőrizze a külső útvonalat felállított alagúttal és érvényben lévő szolgáltatói szabályokkal. Ezután próbáljon ki minden olyan erőforrást, amelyet az alacsonyabb bizalmú oldalnak nem szabadna elérnie, és erősítse meg, hogy a hiba elutasítás, nem pedig egy útvonalat elrejtő időtúllépés. Ellenőrizze az elérhetőséget és az erőforráskorlátokat is, mert egy titkosított kapcsolat is telíthető.

Szabályozott vagy minősített környezetekben vigye a tervezést a felelős biztonsági hatósághoz, és használja annak jóváhagyott elkülönítési architektúráját. Egy VPN-konfiguráció és egy fogalmi magyarázat nem alapoz meg akkreditációt. Ez a lépés nem papírmunka; eldönti, hogy a tervezés egyáltalán létezhet-e.