Přijetí vzdáleného přístupu je tabulka očekávaných výsledků, ne snímek obrazovky funkční stránky. Pro každou skupinu zapište, co má uspět a co má selhat, a pak obojí spusťte proti vyhrazeným testovacím identitám v řízeném okně. Odmítnutí jsou ta část, která dokazuje hranici; úspěšné přihlášení dokazuje jen to, že tunel existuje. To vše funguje s již zvoleným produktem VPN.

Pro testy používejte samostatné účty a označte je tak, aby si nikdo nespletl testovací identitu se skutečnou výjimkou.

Zapište hranici jako očekávané výsledky

Začněte u rolí, ne u komponent: kdo potřebuje kterou službu, odkud a s jakou identitou. Vezměte ilustrativní VPC: jedna skupina potřebuje testovací prostředí přes HTTPS, další potřebuje produkční databázi a třetí, menší skupina spravuje samotnou bránu. Každý řádek dostane očekávané povolení a očekávané odmítnutí, včetně sousední služby a sousedního účtu, které by fungovat neměly. Tato tabulka je kritérium přijetí a lidé, kteří testy nespouštějí, ji mohou zkontrolovat.

Testujte přihlášení do databáze odděleně od síťové cesty. Dostupný port TCP by neměl způsobit úspěch neschváleného databázového účtu a členství ve VPN by nemělo vytvořit cloudovou roli IAM ani udělit administrativní přístup k API. To jsou tři nezávislé kontroly a selhávají nezávisle.

Trasa není autorizace

Trasa činí cestu možnou; neuděluje oprávnění. Zadržování trasy je slabou náhradou za omezení vynucené v cíli, protože klient si vždy může přidat vlastní trasu. Bezpečnostní skupina, oprávnění databáze a vlastní autorizace aplikace zůstávají kontrolami, které rozhodují. Když test nečekaně uspěje, podívejte se nejprve na politiku cíle, ne na směrovací tabulku, kterou jste klientovi zamýšleli dát.

Proto také testy odmítnutí míří na stranu serveru: tyto výsledky nelze změnit úpravou klienta.

Který zdroj kontrola skutečně vidí?

Zdrojová adresa, kterou kontrola vyhodnocuje, závisí na architektuře brány. Brána hostovaná na EC2 může předávat směrovaný fond, překládat na svou vlastní adresu nebo po NAT předkládat jinou adresu; spravovaný Client VPN se přidružuje k podsíti a řídí se vlastním modelem. Bezpečnostní skupiny a síťové ACL vidí to, co dorazí po tomto zpracování. Kontrola pravidla proti nesprávnému předpokladu o zdroji je běžný způsob, jak postavit hranici, která vypadá správně a propouští nesprávný provoz.

Propojte každý výsledek s nejmenší užitečnou událostí: identita a relace, prostředek, operace, čas a rozhodnutí. Volání API v CloudTrail, záznam toku ve VPC a protokol relace VPN odpovídají na různé otázky a žádný z nich sám o sobě není auditem aplikace.

Zrušte identitu a otestujte ji znovu

Zahrňte zrušení do stejné tabulky. Odstraňte testovací identitu, potvrďte, že nová relace je odmítnuta, a poté samostatně potvrďte, jak se zachází s existujícími relacemi, protože jde o různé chování s různými vlastníky. Zkontrolujte, co se stane po restartu nebo výměně brány, aby ručně přidaná výjimka tiše nezmizela nebo se nevrátila širší. Hranice, která vydrží jen do příštího nasazení, není hranice.

Nic z toho nenahrazuje záplatování, obnovu ani práci s životním cyklem přihlašovacích údajů. Činí měřitelným užší slib: správní lidé se dostanou ke správným službám, zatímco blízké trasy, účty a správní plochy zůstávají mimo oprávnění.

Udržujte tabulku spolu s nasazením a znovu ji spusťte, když se brána změní. Testy jsou levné; předpoklady za nimi ne.

Související články