Adjon a VPN-felhasználóknak hozzáférést egy szolgáltatáshoz, ne az alhálózathoz

Egy vállalkozónak egy belső webalkalmazásra van szüksége, semmi másra, és a könnyű válasz az, hogy adunk neki egy alagutat a szerver alhálózatába. Ez addig működik, amíg meg nem szkenneli. A szűkebb tervezés több gondolkodást igényel, mert az elérhetőség, az útválasztás és az alkalmazásengedély három külön vezérlő, amelyeknek egyezniük kell.

A követelményt szolgáltatásként írja le, ne alhálózatként

Kezdje a célgazdával, a protokollal és a porttal, majd adja hozzá azt a felhasználói vagy eszközcsoportot, amelynek el kell érnie. A privát DNS-zónát csak akkor vegye fel, ha az alkalmazás nevet old fel, és az identitásszolgáltatót csak akkor, ha a bejelentkezési folyamatnak szüksége van rá. Minden más olyan függőség, amelyet még nem indokolt.

Az alhálózat a hálózati csapat megvalósítási részlete, míg a szolgáltatás az, amit az üzlet kért, és az az egység, amely felülvizsgálható és kivezethető.

Ha a függőségek listája három tétel fölé nő, az alkalmazásnak valószínűleg saját tervezési beszélgetésre van szüksége.

Irányítson szűken, de kényszerítsen máshol

A szűk útvonal vagy szelektor megmondja az alagútnak, mely csomagokat vigye; ez nem engedélyezési szabály. Az átjáró szűrője, a célgazda tűzfala és az alkalmazás saját engedélymodellje az a hely, ahol a hozzáférés eldől. Az egy címet lefedő útvonal jó kezdet, és nem az a vezérlő, amely megállít egy elszánt felhasználót. Ez az elkülönítés teszi lehetővé a szűrő módosítását az alagút újratervezése nélkül.

Fordítva, egy szigorú szűrővel ellátott széles útvonal is lehet jogszerű, de csak akkor, ha minden érintett tudja, melyikük végzi a kényszerítést.

Dokumentálja kifejezetten a kényszerítési pontot, különben a következő módosítás véletlenül elmozdítja.

Ellenőrizze, milyen forrást lát a szolgáltatás valójában

A cél vagy az ügyfél poolcímét látja, vagy az átjáró címét, attól függően, hogy fordít-e. A gazda tűzfalszabályainak és naplóinak meg kell felelniük a valódi forrásnak. Ha több felhasználó osztozik egy lefordított forráson, azon a gazdán semmilyen felhasználónkénti szabály nem tudja megkülönböztetni őket, és ez tervezési korlát, nem hiba.

Válassza a fordítást tudatosan: egyszerűsíti az útválasztást és megsemmisíti a forrás identitását, ami számít az auditnál és a felhasználónkénti szabályoknál.

Jegyezze fel, melyiket választotta a kettő közül, annak a szabálynak a mellé, amelyik függ tőle.

Az alkalmazásengedélyezés nem választható

Egy port elérése nem ad szerepet. Az alkalmazásnak továbbra is saját bejelentkezésre és saját engedélyekre van szüksége, mert a hálózati réteg nem tudja kifejezni, mely rekordokat szerkeszthet a felhasználó. Egy szolgáltatás, amely megbízik a belső alhálózat bármely kérésében, szűk alagutat teljes hozzáféréssé alakít egy kompromittált hitelesítő adat számára. Az alagút dönti el, ki nyithatja meg a socketet, és az alkalmazás dönti el, mit lehet vele tenni.

Itt fizetődik ki kétszeresen a szűk tervezés, mert a kevesebb elérhető gazda kevesebb helyet jelent, ahol egy alkalmazásszintű hiba kihasználható.

Tartsa a hálózati szabályt és az alkalmazásszerepet külön rendszerekben, és külön vezesse ki őket.

Bizonyítsa az engedélyezett és a megtagadott útvonalat is

Csatlakozzon jogosult felhasználóként, és hajtson végre egy ártalmatlan reprezentatív műveletet, majd próbáljon meg egy elérhetetlennek lennie kellő célt. Az a tervezés, amely csak az első felét teszteli, nincs tesztelve, és a megtagadási teszt az, amely bizonyítja a tervezést. Minden szabálymódosítás után teszteljen friss munkamenetet, és nézze meg a visszautat, ha a kérések megérkeznek, de a válaszok nem.

Ne kapcsolja ki a továbbítási szűrőket, hogy az elfogadási teszt átmenjen, mert az megváltoztatja a tesztelt dolgot.

Amikor a felhasználónak már nincs szüksége a szolgáltatásra, vezesse ki a távoli identitást és az alkalmazásszerepet a megfelelő rendszereikben, és rögzítse mindkettőt. A strongSwan továbbítási útmutatója lefedi az útvonal átjáró oldalát.