Å akseptere VPC-fjerntilgang krever avvisningstester

Aksept av fjerntilgang er en tabell med forventede resultater, ikke et bilde av en side som virker. For hver gruppe noterer du hva som skal lykkes og hva som skal feile, og kjører så begge mot egne testidentiteter i et kontrollert tidsrom. Avvisningene er den delen som beviser grensen; en vellykket innlogging beviser bare at tunnelen eksisterer. Alt dette virker sammen med VPN-produktet som allerede er valgt.

Bruk egne kontoer for testene og merk dem slik at ingen tar en testidentitet for et virkelig unntak.

Skriv grensen som forventede resultater

Begynn med rollene og ikke med komponentene: hvem trenger hvilken tjeneste, hvorfra og med hvilken identitet. Ta et eksempel på en VPC: én gruppe trenger testmiljøet over HTTPS, en annen trenger en produksjonsdatabase, og en tredje og mindre gruppe administrerer selve gatewayen. Hver rad får en forventet tillatelse og en forventet avvisning, inkludert tjenesten og kontoen ved siden av som ikke skal virke. Den tabellen er akseptkriteriet, og folk som ikke kjører testene, kan gjennomgå den.

Test databaseloggingen adskilt fra nettverksveien. En tilgjengelig TCP-port skal ikke gjøre en ikke-godkjent databasekonto vellykket, og VPN-medlemskap skal ikke opprette en sky-IAM-rolle eller gi administrativ API-tilgang. Det er tre uavhengige kontroller, og de svikter uavhengig.

En rute er ikke autorisasjon

En rute gjør en vei mulig; den gir ikke tillatelse. Å holde tilbake en rute er en svak erstatning for en begrensning som håndheves ved destinasjonen, fordi en klient alltid kan legge til sin egen rute. Sikkerhetsgruppen, databasetildelingen og applikasjonens egen autorisasjon er fortsatt kontrollene som bestemmer. Når en test lykkes uventet, se først på destinasjonens policy og ikke på rutetabellen du mente klienten skulle ha.

Derfor retter avvisningstestene seg mot serversiden: disse resultatene kan ikke endres ved å redigere klienten.

Hvilken kilde ser kontrollen egentlig?

Kildeadressen som en kontroll vurderer, avhenger av gateway-arkitekturen. En gateway som kjøres på EC2 kan videresende en rutet pool, oversette til sin egen adresse eller presentere en annen adresse etter NAT; administrert Client VPN knytter seg til et subnett og følger sin egen modell. Sikkerhetsgrupper og nettverks-ACL-er ser det som kommer inn etter den behandlingen. Å inspisere en regel mot en feil kildeantagelse er en vanlig måte å bygge en grense som ser riktig ut og slipper inn feil trafikk.

Koble hvert resultat til den minste nyttige hendelsen: identitet og sesjon, ressurs, operasjon, tid og beslutningen. Et CloudTrail-API-kall, en VPC-flytrecord og en VPN-sesjonslogg svarer på forskjellige spørsmål, og ingen av dem er alene en applikasjonsrevisjon.

Trekk tilbake en identitet og test den på nytt

Ta med tilbaketrekkingen i samme tabell. Fjern en testidentitet, bekreft at en ny sesjon avvises, og bekreft deretter separat hvordan eksisterende sesjoner behandles, fordi det er forskjellig atferd med forskjellige eiere. Sjekk hva som skjer etter en omstart eller utskifting av gatewayen, slik at et håndlaget unntak ikke forsvinner stille eller kommer tilbake bredere. En grense som bare varer til neste utrulling, er ikke en grense.

Ingenting av dette erstatter arbeid med oppdateringer, gjenoppretting eller livssyklusen til påloggingsinformasjon. Det gjør et smalere løfte målbart: de riktige menneskene når de riktige tjenestene, mens nærliggende ruter, kontoer og administrasjonsflater holder seg utenfor tildelingen.

Ta vare på tabellen sammen med utrullingen og kjør den på nytt når gatewayen endres. Testene er billige; antakelsene bak dem er det ikke.