Pravidlo EC2 jen pro VPN: všechny připojené bezpečnostní skupiny se musí shodnout

Přidáte jedno příchozí pravidlo pro pool VPN klientů, nic neodeberete a služba je stále dostupná z internetu. Nic není rozbité. Bezpečnostní skupina nemá žádné přepsání, prioritu ani konečné zamítnutí, proti kterému by úzké pravidlo mohlo vyhrát. Každá skupina připojená k instanci přispívá svými povoleními do jednoho sloučeného souboru a široké pravidlo, na které jste zapomněli, je v tomto souboru stále. Udělat z instance pouze-VPN znamená auditovat všechny, ne přidat lépe znějící pravidlo k jedné z nich.

Napište službu dřív, než napíšete pravidlo

Začněte přesným cílem, protokolem a portem a síťovým rozhraním, na kterém služba skutečně naslouchá. Instance s několika rozhraními nebo několika službami na jednom portu vyžaduje audit pro každé rozhraní, protože připojené skupiny se mohou lišit. Potom určete jakou zdrojovou adresu toto rozhraní skutečně dostává pro uživatele VPN, a ne adresu, kterou klient zobrazuje ve svém vlastním okně připojení.

Tyto dvě adresy se rozcházejí častěji, než lidé čekají, jakmile do hry vstoupí překlad a směrování.

Tři modely zdroje, tři různá pravidla

Při privátním směrovaném přístupu instance dostává pool klientů nebo firemní rozsah, podle toho, jak je cesta směrována a překládána. U veřejného koncového bodu dosahovaného přes firemní výstup instance místo toho vidí firemní adresu NAT, a to jen pokud toto cílové umístění skutečně používá cestu VPN, protože rozdělené tunelování ho může nechat na domácím připojení. U spravovaného koncového bodu Client VPN platí dokumentovaný model přidružení a cílové sítě a adresa klienta pochází z nakonfigurovaného CIDR klienta.

Co nefunguje, je odkazovat bránu VPN jako zdroj bezpečnostní skupiny. Odkazy na skupiny odpovídají elastickým síťovým rozhraním uvnitř VPC nebo propojené sítě a brána, která předává pakety, není jedním z nich.

Přečtěte sjednocení přes všechny připojené skupiny

Otevřete instanci, najděte její síťové rozhraní a vypište každou bezpečnostní skupinu, která je k němu připojená. U každé zkontrolujte každé pravidlo, které pokrývá váš protokol a port, včetně širokých rozsahů portů a obou rodin adres. Pravidlo IPv4 z 0.0.0.0/0 vás nezbavuje kontroly ::/0 a pravidlo povolující veškerý provoz zcela skrývá otázku portu. Teprve po tomto soupisu můžete říct, jaké je efektivní povolení pro službu.

Referenční příručka pravidel AWS popisuje bezpečnostní skupiny jako pouze-povolující a uvádí, že pravidla všech připojených skupin se agregují, což je celý mechanismus stojící za tímto selháním.

Síťové ACL jsou samostatná politika bez stavu s uspořádanými položkami povolení a zamítnutí a vyhodnocují se na podsíti, ne na instanci.

Neodpovídejte zdí zamítnutí

Přidat zamítnutí NACL pro celou podsíť, abyste napodobili firewall, na který jste zvyklí, je špatný nástroj a riskantní. Položky NACL jsou uspořádané a bez stavu, takže zamítnutí umístěné nad existujícím povolením tiše rozbije nesouvisející provoz, včetně zpětné cesty pro relace, které jste se snažili udržet. Opravte široké povolení bezpečnostní skupiny ve skupině, která ho vlastní, a pak nechte ACL na pokoji, pokud není skutečně součástí návrhu.

Odebrání veřejné adresy z instance je silnější záruka a je to také architektonická změna s administrativními a aplikačními důsledky, ne zaškrtávací políčko v seznamu povolení.

Testujte novou relací a ponechte si cestu dovnitř

Než zrušíte jakékoli existující povolení, potvrďte schválenou nezávislou administrativní cestu, protože pravidlo, které se chystáte smazat, může být to, na kterém závisí obnova vaší relace. Potom otestujte nové povolené připojení z VPN a nové zamítnuté připojení ze schválené testovací cesty mimo VPN. Existující sledované relace přežívají změny pravidel tak, že staré otevřené shelly jsou jako důkaz přijetí nepoužitelné.

Nakonec ponechte vlastní autorizaci aplikace na místě. Přeložený firemní výstup může zastupovat stovky lidí a síťové přijetí nikdy neidentifikovalo jednotlivého uživatele ani jeho zařízení.