Å godta VPC-fjerntilgang krev avvisingstestar

Godkjenning av fjerntilgang er ein tabell med venta resultat, ikkje eit skjermbilete av ei side som verkar. For kvar gruppe skriv du ned kva som skal lukkast og kva som skal mislukkast, og køyrer deretter begge mot dedikerte testidentitetar i eit kontrollert tidsvindauge. Avvisingane er den delen som provar grensa; ei vellukka innlogging provar berre at tunnelen finst. Alt dette fungerer med VPN-produktet som alt er valt.

Bruk separate kontoar for testane, og merk dei slik at ingen forvekslar ein testidentitet med eit reelt unntak.

Skriv grensa som venta resultat

Start med rollene i staden for komponentane: kven treng kva teneste, kvarfrå og med kva identitet. Ta ein illustrerande VPC: éi gruppe treng testmiljøet over HTTPS, ei anna treng ein produksjonsdatabase, og ei tredje og mindre gruppe administrerer sjølve gatewayen. Kvar rad får ei venta tillating og ei venta avvising, inkludert tenesta og kontoen ved sida av som ikkje skal verke. Den tabellen er godkjenningskriteriet, og folk som ikkje køyrer testane, kan gå gjennom han.

Test databaselogginga separat frå nettverksvegen. Ein tilgjengeleg TCP-port skal ikkje gjere ein ikkje-godkjend databasekonto vellukka, og VPN-medlemskap skal ikkje opprette ei sky-IAM-rolle eller gje administrativ API-tilgang. Det er tre uavhengige kontrollar, og dei feilar uavhengig.

Ei rute er ikkje autorisasjon

Ei rute gjer ein veg mogleg; ho gjev ikkje løyve. Å halde att ei rute er ei svak erstatning for ei avgrensing som blir handheva ved destinasjonen, sidan ein klient alltid kan leggje til si eiga rute. Tryggingsgruppa, databasetildelinga og eigen autorisasjon i applikasjonen er framleis kontrollane som avgjer. Når ein test vellukkas uventa, sjå først på politikken til destinasjonen og ikkje på rutetabellen du meinte klienten skulle ha.

Derfor rettar avvisingstestane seg mot servarsida: dei resultata kan ikkje endrast ved å redigere klienten.

Kva kjelde ser kontrollen eigentleg?

Kjeldeadressa ein kontroll vurderer, er avhengig av gateway-arkitekturen. Ein gateway som blir drifta på EC2 kan videresende ein ruta pool, omsetje til si eiga adresse eller presentere ei anna adresse etter NAT; administrert Client VPN knyter seg til eit subnett og følgjer sin eigen modell. Tryggingsgrupper og nettverks-ACL-ar ser det som kjem etter den handsaminga. Å inspisere ei regel mot ei feil kjeldeantaking er ein vanleg måte å byggje ei grense som ser riktig ut og slepp inn feil trafikk.

Korreler kvart resultat med den minste nyttige hendinga: identitet og sesjon, ressurs, operasjon, tid og avgjerda. Eit CloudTrail-API-kall, ei VPC-flytoppføring og ein VPN-sesjonslogg svarar på ulike spørsmål, og ingen av dei er åleine ein applikasjonsrevisjon.

Trekk attende ein identitet og test han på nytt

Ta med tilbaketrekkinga i same tabell. Fjern ein testidentitet, stadfest at ein ny sesjon blir avvist, og stadfest deretter separat korleis eksisterande sesjonar blir handsama, fordi det er ulik åtferd med ulike eigarar. Kontroller kva som skjer etter ein omstart eller utskifting av gatewayen, slik at eit handlagt unntak ikkje forsvinn stille eller kjem tilbake breiare. Ei grense som berre varer til neste utrulling, er ikkje ei grense.

Ingenting av dette erstattar arbeid med lappar, attoppretting eller livssyklusen for påloggingsinformasjon. Det gjer eit snevrare løfte målbart: dei rette menneska når dei rette tenestene, medan nærliggjande ruter, kontoar og administrasjonsflater held seg utanfor tildelinga.

Oppbevar tabellen saman med utrullinga og køyr han på nytt når gatewayen endrar seg. Testane er billegare; føresetnadene bak dei er det ikkje.