Az AWS Client VPN szabályai az erőforráshoz tartoznak, nem az alhálózathoz

A munkatársaknak el kell érniük egy alkalmazást a VPC-ben, és nem érhetik el az adatbázis-figyelőt ugyanazon a példányon, ezért valaki hozzáad egy második nyilvános alhálózatot a VPN-végponthoz, és teljesítettnek nyilvánítja a követelményt. Az alhálózat elhelyezése megváltoztatja az útválasztást és a rendelkezésre állást. Egyetlen portot sem engedélyez vagy tilt. A követelményt kifejező engedély a célhelyen, az erőforrás biztonsági csoportjában él, a VPN-határ pedig biztosítja azt a fogantyút, amelyre ez a szabály hivatkozik.

Az alhálózat elhelyezése útválasztás, nem engedélyezés

Az, hogy a végpont hálózati társítása hol van, eldönti, melyik útvonaltábla szállítja az ügyfélforgalmat, és mely rendelkezésre állási zónák élik túl a hibát. Semmit sem mond arról, hogy ez a forgalom melyik példány melyik portjára juthat el. Két, ugyanahhoz az alhálózathoz társított ügyfél továbbra is ugyanazzal a forrásidentitással érkezik, és az erőforrás nem tudja őket az alhálózat neve alapján megkülönböztetni.

Induljon inkább a követelményből: ki hív, melyik erőforrás, melyik szolgáltatási port és milyen irány. Ezután válassza azt a szabálymodellt, amely ezt a négy dolgot a célhelyen ki tudja fejezni. Ez a keretrendszer általában teljesen eltávolítja a plusz alhálózatot a tervezésből.

A Client VPN társítási csoport a fogantyú

Egy alhálózathoz társított AWS Client VPN végpont esetében a dokumentált elrendezés konkrét. Alkalmazza a szándékolt biztonsági csoportot a végpont célhálózati társításaira, majd engedélyezze a szükséges forgalmat az erőforrás biztonsági csoportjában úgy, hogy forrásként ezt a Client VPN csoportot használja.

Konkrétan az alkalmazáspéldány csoportja az alkalmazásportot a társítási csoportból engedélyezi, és semmi mást. Az AWS erőforrás-hozzáférési eljárása leírja ezt a kapcsolatot, és érdemes ugyanazt a csoportházirendet tartani minden alhálózaton, amelyhez a végpont társul, mert egy másik csoporthoz tartozó elavult társítás csendesen szélesíti a határt.

Ez a szabály senkit nem hitelesít. A bejelentkezés külön kontroll, és az erőforráshoz vezető útvonal a harmadik. Mindháromnak teljesülnie kell, mielőtt egy kérés megérkezik. Amelyik elbukik, az dönti el, melyik javítás a helyes, és a szabály módosítása csak az első esetében helyes válasz.

Amit egy társítási csoport nem tud megkülönböztetni

Ugyanazon társítási csoport mögötti minden ügyfél ugyanazon biztonsági csoport forrásaként éri el az erőforrást. Két különböző szerepkörű felhasználó ezen a rétegen megkülönböztethetetlen, akárhogy nevezik vagy címkézik a csoportot. A Client VPN külső csoportos engedélyezése a cél-előtag szerint korlátozza a hozzáférést könyvtár- vagy SAML-csoport esetén, ami durvább az erőforrás-szerepkörnél, és hálózati határként, nem identitásrendszerként kell kezelni.

A finomabb megkülönböztetés az alkalmazás dolga. Egy adatbázis-figyelőt, amelynek a legtöbb munkatárs előtt zárva kell maradnia, jobban véd az, ha az engedélyezett előtagon egyáltalán nem érhető el, mint ha abban bízunk, hogy a csoporttagság rendezett marad.

A csoport átnevezése nem hoz létre identitást, a csapatonkénti sokszorosítása pedig csak megsokszorozza az auditálandó társításokat.

Ne másolja ezt a szabályt minden VPN-tervbe

Az önállóan kezelt EC2 VPN-átjáró, az útválasztott ellenőrző készülék és a kezelt Client VPN három különböző csomagút. Állapítsa meg, melyik forráscím éri el valóban az erőforrást, történik-e fordítás közben, és mely hivatkozási mechanizmusokat támogatja a szolgáltatás azon az úton.

A forgalom köztes eszközön át történő továbbítása nem őrzi meg a forrás biztonsági csoport hivatkozását úgy, mint a közvetlen példány-példány közötti forgalom. Az AWS dokumentálja, hogy az ilyen terveknek a csoporthivatkozás helyett a megfelelő privát forráscímekre vagy CIDR-ekre lehet szükségük. A kezelt Client VPN eljárása nem bizonyíték arra, hogy minden átjáró csatolt csoportja univerzális identitásjelként működik a továbbított csomagokhoz.

Egyetlen NAT-ugrás az úton elég a feltevés megtöréséhez, és a hiba úgy néz ki, mint egy létező szabály, amely soha nem illeszkedik.

Vizsgálja felül a tényleges határt

Olvassa el az erőforráshoz csatolt minden biztonsági csoportot, mert az engedélyező szabályok összeadódnak, és egy szűk szabály nem semmisít meg egy tágabbat egy másik csoporton. Ezután ellenőrizze a hálózati ACL-t, a gazdagép tűzfalát és az alkalmazás saját engedélyezését, amelyek külön rétegek külön hibákkal.

Fejezze be egy engedélyezett és egy szándékosan kizárt kéréssel ugyanazon erőforrás ellen. A pár bizonyítja a határt, míg egyetlen sikeres kapcsolat csak azt bizonyítja, hogy valami nyitva van. Erősítse meg az útvonalat, a tényleges forrást és a szándékolt szolgáltatási portot, nem pedig a végpontot tartalmazó alhálózatot.

A munka sorrendje: írja meg a négyrészes követelményt, csatolja a csoportot a társításokhoz, szűkítse az erőforrás szabályát a portra, ellenőrizzen egy engedélyezést és egy elutasítást, és csak ezután fontolja meg az alhálózatok felosztását útválasztási okokból.