A VPC távoli hozzáférés elfogadásához elutasítási tesztek kellenek

A távoli hozzáférés elfogadása az elvárt eredmények táblázata, nem egy működő oldal képernyőképe. Minden csoporthoz írja le, minek kell sikerülnie és minek kell meghiúsulnia, majd futtassa mindkettőt dedikált tesztidentitásokkal egy ellenőrzött időablakban. Az elutasítások az a rész, amely bizonyítja a határt; a sikeres bejelentkezés csak azt bizonyítja, hogy az alagút létezik. Mindez a már kiválasztott VPN-termékkel működik.

Használjon külön fiókokat a tesztekhez, és jelölje meg őket úgy, hogy senki ne keverje össze egy tesztidentitást egy valódi kivétellel.

Írja le a határt elvárt eredményekként

A szerepekkel kezdje, ne az összetevőkkel: kinek melyik szolgáltatásra van szüksége, honnan és milyen identitással. Vegyünk egy szemléltető VPC-t: az egyik csoportnak HTTPS-en keresztül tesztkörnyezetre van szüksége, a másiknak éles adatbázisra, a harmadik, kisebb csoport pedig magát az átjárót igazgatja. Minden sor kap egy elvárt engedélyezést és egy elvárt elutasítást, beleértve a szomszédos szolgáltatást és a szomszédos fiókot, amelyeknek nem szabadna működniük. Ez a táblázat az elfogadási kritérium, és a tesztet nem futtató emberek is átnézhetik.

Az adatbázis-bejelentkezést külön tesztelje a hálózati útvonaltól. Egy elérhető TCP-port nem tehet sikeressé egy nem jóváhagyott adatbázis-fiókot, és a VPN-tagság nem hozhat létre felhő IAM-szerepkört, és nem adhat adminisztratív API-hozzáférést. Ez három független vezérlő, és függetlenül hibáznak.

Az útvonal nem engedélyezés

Egy útvonal lehetővé tesz egy ösvényt; nem ad engedélyt. Egy útvonal visszatartása gyenge helyettesítője a célnál érvényesített korlátozásnak, mivel egy kliens mindig hozzáadhat saját útvonalat. A biztonsági csoport, az adatbázis-engedély és az alkalmazás saját engedélyezése marad a döntő vezérlő. Ha egy teszt váratlanul sikerül, először a cél szabályzatát nézze, ne az útválasztási táblázatot, amelyet a kliensnek szánt.

Ezért célozzák az elutasítási tesztek a kiszolgáló oldalát: ezeket az eredményeket nem lehet a kliens szerkesztésével megváltoztatni.

Melyik forrást látja valójában a vezérlő?

A forrás-cím, amelyet egy vezérlő kiértékel, az átjáró architektúrájától függ. Az EC2-n üzemeltetett átjáró továbbíthat egy útvonalazott poolt, lefordíthatja a saját címére, vagy NAT után más címet mutathat; a felügyelt Client VPN egy alhálózathoz kapcsolódik, és a saját modelljét követi. A biztonsági csoportok és a hálózati ACL-ek azt látják, ami a feldolgozás után érkezik. Egy szabály vizsgálata rossz forrásfeltételezés mellett gyakori módja annak, hogy helyesnek látszó határt építsünk, amely beengedi a rossz forgalmat.

Korrelálja az egyes eredményeket a legkisebb hasznos eseménnyel: identitás és munkamenet, erőforrás, művelet, idő és a döntés. A CloudTrail API-hívás, a VPC-folyamatrekord és a VPN-munkamenet naplója különböző kérdésekre válaszol, és egyik sem önmagában az alkalmazás auditja.

Vonjon vissza egy identitást, és tesztelje újra

Vegye fel a visszavonást ugyanabba a táblázatba. Távolítson el egy tesztidentitást, erősítse meg, hogy az új munkamenetet elutasítják, majd külön erősítse meg, hogyan kezelik a meglévő munkameneteket, mert ezek eltérő viselkedések eltérő tulajdonosokkal. Ellenőrizze, mi történik az átjáró újraindítása vagy cseréje után, hogy egy kézzel hozzáadott kivétel ne tűnjön el csendben, és ne térjen vissza szélesebben. Az a határ, amely csak a következő telepítésig tart, nem határ.

Ezek egyike sem helyettesíti a javítási, helyreállítási vagy hitelesítőadat-életciklus munkát. Mérhetővé tesz egy szűkebb ígéretet: a megfelelő emberek elérik a megfelelő szolgáltatásokat, miközben a közeli útvonalak, fiókok és felügyeleti felületek az engedélyen kívül maradnak.

Tartsa a táblázatot a telepítés mellett, és futtassa újra, amikor az átjáró megváltozik. A tesztek olcsók; a mögöttük álló feltevések nem.