Å godta VPC-fjerntilgang krever avvisningstester

Godkjenning av fjerntilgang er en tabell med forventede resultater, ikke et skjermbilde av en side som virker. For hver gruppe skriver du ned hva som skal lykkes og hva som skal feile, og kjører deretter begge mot dedikerte testidentiteter i et kontrollert tidsvindu. Avvisningene er den delen som beviser grensen; en vellykket innlogging beviser bare at tunnelen finnes. Alt dette fungerer med VPN-produktet som allerede er valgt.

Bruk separate kontoer for testene, og merk dem slik at ingen forveksler en testidentitet med et reelt unntak.

Skriv grensen som forventede resultater

Start med rollene i stedet for komponentene: hvem trenger hvilken tjeneste, hvorfra og med hvilken identitet. Ta en illustrerende 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 godkjenningskriteriet, og folk som ikke kjører testene, kan gjennomgå den.

Test databaseloggingen separat 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 feiler 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, siden en klient alltid kan legge til sin egen rute. Sikkerhetsgruppen, databasetildelingen og applikasjonens egen autorisasjon er fortsatt kontrollene som avgjør. Når en test uventet lykkes, se først på destinasjonens policy og ikke på rutetabellen du mente klienten skulle ha.

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

Hvilken kilde ser kontrollen egentlig?

Kildeadressen en kontroll vurderer, avhenger av gateway-arkitekturen. En gateway som driftes 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 ankommer etter den behandlingen. Å inspisere en regel mot en feil kildeantakelse er en vanlig måte å bygge en grense som ser riktig ut og slipper inn feil trafikk.

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

Trekk tilbake en identitet og test den igjen

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 ulik atferd med ulike eiere. Kontroller hva som skjer etter en omstart eller utskifting av gatewayen, slik at et håndlagt unntak ikke forsvinner stille eller kommer tilbake bredere. En grense som bare varer til neste utrulling, er ikke en grense.

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

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