Sprejem oddaljenega dostopa do VPC zahteva teste zavrnitve
Delujoča prijava VPN je prva vrstica tabele sprejema, ne zadnja. Zapišite pričakovane zavrnitve za vsako vlogo in preizkusite kontrole, ki jih določajo.
Sprejem oddaljenega dostopa je tabela pričakovanih izidov, ne posnetek zaslona delujoče strani. Za vsako skupino zapišite, kaj naj bi uspelo in kaj naj bi spodletelo, nato pa oboje izvedite z namenskimi testnimi identitetami v nadzorovanem oknu. Zavrnitve so tisti del, ki dokaže mejo; uspešna prijava dokaže le, da tunel obstaja. Vse to deluje z že izbranim izdelkom VPN.
Za teste uporabite ločene račune in jih označite tako, da nihče ne zamenja testne identitete s pravo izjemo.
Zapišite mejo kot pričakovane izide
Začnite pri vlogah in ne pri komponentah: kdo potrebuje katero storitev, od kod in s katero identiteto. Vzemite ponazoritveni VPC: ena skupina potrebuje testno okolje prek HTTPS, druga potrebuje produkcijsko bazo podatkov, tretja in manjša skupina pa upravlja prehod sam. Vsaka vrstica dobi pričakovano dovoljenje in pričakovano zavrnitev, vključno s sosednjo storitvijo in sosednjim računom, ki ne bi smela delovati. Ta tabela je merilo sprejema in ljudje, ki testov ne izvajajo, jo lahko pregledajo.
Prijavo v bazo podatkov preizkusite ločeno od omrežne poti. Dosegljiva vrata TCP ne bi smela omogočiti uspeha neodobrenemu računu baze podatkov, članstvo v VPN pa ne bi smelo ustvariti vloge IAM v oblaku ali podeliti skrbniškega dostopa do API. To so tri neodvisne kontrole in spodletijo neodvisno.
Pot ni pooblastilo
Pot omogoči pot; ne podeli dovoljenja. Zadrževanje poti je šibka zamenjava za omejitev, ki se uveljavlja na cilju, saj lahko odjemalec vedno doda svojo pot. Varnostna skupina, dodelitev baze podatkov in lastno pooblastilo aplikacije ostajajo kontrole, ki odločajo. Ko test nepričakovano uspe, poglejte najprej politiko cilja in ne usmerjevalne tabele, ki ste jo nameravali dati odjemalcu.
Zato testi zavrnitve ciljajo na strežniško stran: teh izidov ni mogoče spremeniti z urejanjem odjemalca.
Kateri vir kontrola dejansko vidi?
Naslov vira, ki ga kontrola ocenjuje, je odvisen od arhitekture prehoda. Prehod, gostovan na EC2, lahko posreduje usmerjeni nabor, ga prevede v svoj naslov ali po NAT predstavi drug naslov; upravljani Client VPN se poveže s podomrežjem in sledi svojemu modelu. Varnostne skupine in omrežni ACL vidijo, kar prispe po tej obdelavi. Preverjanje pravila ob napačni predpostavki o viru je pogost način za gradnjo meje, ki je videti pravilna in spusti napačen promet.
Povežite vsak izid z najmanjšim koristnim dogodkom: identiteta in seja, vir, operacija, čas in odločitev. Klic API v CloudTrail, zapis toka VPC in dnevnik seje VPN odgovarjajo na različna vprašanja in noben sam ni revizija aplikacije.
Prekličite identiteto in jo znova preizkusite
Preklic vključite v isto tabelo. Odstranite testno identiteto, potrdite, da je nova seja zavrnjena, nato pa ločeno potrdite, kako se obravnavajo obstoječe seje, ker gre za različna vedenja z različnimi lastniki. Preverite, kaj se zgodi po ponovnem zagonu ali zamenjavi prehoda, da ročno dodana izjema ne izgine tiho ali se ne vrne širša. Meja, ki zdrži le do naslednje namestitve, ni meja.
Nič od tega ne nadomesti dela s popravki, obnovitvijo ali življenjskim ciklom poverilnic. Naredi merljivo ožjo obljubo: pravi ljudje dosežejo prave storitve, medtem ko bližnje poti, računi in upravljalne površine ostanejo zunaj dodelitve.
Tabelo hranite skupaj z namestitvijo in jo znova zaženite, ko se prehod spremeni. Testi so poceni; predpostavke za njimi niso.