Pravidla AWS Client VPN patří k prostředku, ne k podsíti

Zaměstnanci potřebují dosáhnout jedné aplikace ve VPC a nesmějí dosáhnout listeneru databáze na stejné instanci, takže někdo přidá druhou veřejnou podsíť pro endpoint VPN a prohlásí požadavek za splněný. Umístění podsítě mění směrování a dostupnost. Nedává ani neodpírá jediný port. Oprávnění, které požadavek vyjadřuje, žije v cíli, v bezpečnostní skupině prostředku, a hranice VPN dodává držadlo, na které se to pravidlo odkazuje.

Umístění podsítě je směrování, ne autorizace

Kde síťové přidružení endpointu leží, rozhoduje o tom, která směrovací tabulka nese provoz klientů a které zóny dostupnosti přežijí výpadek. Nic to neříká o tom, který port na které instanci může tento provoz dosáhnout. Dva klienti přidružení ke stejné podsíti přicházejí se stejnou identitou zdroje a prostředek je podle názvu podsítě nerozliší.

Začněte raději od požadavku: kdo volá, který prostředek, který port služby a kterým směrem. Pak zvolte model pravidla, který tyto čtyři věci umí vyjádřit v cíli. Takový rámec obvykle nadbytečnou podsíť z návrhu úplně odstraní.

Skupina přidružení Client VPN je ono držadlo

U endpointu AWS Client VPN přidruženého k podsíti je dokumentované uspořádání konkrétní. Použijte zamýšlenou bezpečnostní skupinu na síťová přidružení cílové sítě endpointu a poté povolte požadovaný provoz v bezpečnostní skupině prostředku s touto skupinou Client VPN jako zdrojem.

Konkrétně skupina instance aplikace povoluje port aplikace ze skupiny přidružení a nic jiného. Postup přístupu k prostředku od AWS tento vztah popisuje a vyplatí se držet stejnou politiku skupiny na každé podsíti, ke které se endpoint přidruží, protože zastaralé přidružení s jinou skupinou tiše rozšiřuje hranici.

Toto pravidlo nikoho neautentizuje. Přihlášení je samostatná kontrola a cesta k prostředku je třetí. Všechny tři musí platit, než požadavek dorazí. Kterákoli selže, určuje, která oprava je správná, a změna pravidla je správnou odpovědí jen pro první z nich.

Co jedna skupina přidružení nerozliší

Každý klient za stejnou skupinou přidružení dosáhne prostředku jako stejný zdroj bezpečnostní skupiny. Dva uživatelé s různými rolemi jsou v této vrstvě nerozlišitelní, ať je skupina pojmenovaná nebo označená jakkoli. Autorizace externích skupin v Client VPN omezuje přístup podle cílového prefixu pro skupinu adresáře nebo SAML, což je hrubší než role prostředku a má se s tím zacházet jako se síťovou hranicí, ne jako s identitním systémem.

Jemnější rozlišení patří aplikaci. Listener databáze, který má zůstat zavřený pro většinu zaměstnanců, je lépe chráněn tím, že na povoleném prefixu vůbec není dostupný, než spoléháním na to, že členství ve skupině zůstane uklizené.

Přejmenování skupiny nevytváří identitu a její zdvojení pro každý tým jen násobí přidružení k auditu.

Nekopírujte to pravidlo do každého návrhu VPN

Samoobslužná brána EC2 VPN, směrované inspekční zařízení a spravovaný Client VPN jsou tři různé cesty paketů. Zjistěte, která zdrojová adresa skutečně dosáhne prostředku, zda se po cestě překládá a které referenční mechanismy služba na této cestě podporuje.

Předávání provozu přes mezilehlé zařízení nezachová referenci na zdrojovou bezpečnostní skupinu tak jako přímý provoz mezi instancemi. AWS dokumentuje, že takové návrhy mohou místo reference skupiny potřebovat odpovídající privátní zdrojové adresy nebo CIDR. Postup spravovaného Client VPN není důkazem, že připojená skupina každé brány funguje jako univerzální identitní token pro předávané pakety.

Jeden NAT skok na cestě stačí k rozbití předpokladu a porucha vypadá jako pravidlo, které existuje, ale nikdy neodpovídá.

Projděte efektivní hranici

Přečtěte každou bezpečnostní skupinu připojenou k prostředku, protože povolovací pravidla se sčítají a úzké pravidlo neruší širší v jiné skupině. Pak zkontrolujte síťový ACL, firewall hostitele a vlastní autorizaci aplikace, což jsou oddělené vrstvy s oddělenými chybami.

Skončete jedním povoleným a jedním záměrně vyloučeným požadavkem na stejný prostředek. Ta dvojice dokazuje hranici, zatímco jediné úspěšné spojení dokazuje jen to, že je něco otevřené. Potvrďte trasu, efektivní zdroj a zamýšlený port služby, ne podsíť, která endpoint obsahuje.

Pořadí práce: napište požadavek o čtyřech částech, připojte skupinu k přidružením, omezte pravidlo prostředku na port, ověřte jedno povolení a jedno zamítnutí a teprve potom zvažujte dělení podsítí z důvodů směrování.