Accept af VPC-fjernadgang kræver afvisningstests

Accept af fjernadgang er en tabel over forventede resultater, ikke et skærmbillede af en side, der virker. For hver gruppe skal du skrive, hvad der bør lykkes, og hvad der bør fejle, og derefter køre begge dele mod dedikerede testidentiteter i et kontrolleret tidsvindue. Afvisningerne er den del, der beviser grænsen; et vellykket login beviser kun, at tunnelen findes. Alt dette fungerer med det VPN-produkt, der allerede er valgt.

Brug separate konti til testene, og mærk dem, så ingen forveksler en testidentitet med en rigtig undtagelse.

Skriv grænsen som forventede resultater

Begynd med rollerne i stedet for komponenterne: hvem har brug for hvilken tjeneste, hvorfra, og med hvilken identitet. Tag en illustrativ VPC: én gruppe har brug for staging over HTTPS, en anden har brug for en produktionsdatabase, og en tredje og mindre gruppe administrerer selve gatewayen. Hver række får en forventet tilladelse og en forventet afvisning, inklusive den tilstødende tjeneste og den tilstødende konto, som ikke bør virke. Den tabel er acceptkriteriet, og folk, der ikke kører testene, kan gennemgå den.

Test databaselogin separat fra netværksstien. En tilgængelig TCP-port bør ikke gøre en ikke-godkendt databasekonto vellykket, og VPN-medlemskab bør ikke oprette en cloud-IAM-rolle eller give administrativ API-adgang. Det er tre uafhængige kontroller, og de fejler uafhængigt.

Rute er ikke autorisation

En rute gør en sti mulig; den giver ikke tilladelse. At tilbageholde en rute er en svag erstatning for en begrænsning, der håndhæves ved destinationen, da en klient altid kan tilføje sin egen rute. Sikkerhedsgruppen, databasebevillingen og applikationens egen autorisation er fortsat de kontroller, der afgør sagen. Når en test uventet lykkes, skal du først se på destinationens politik frem for den rutetabel, du havde tænkt, at klienten skulle have.

Det er også derfor, at afvisningstestene rammer serversiden: de resultater kan ikke ændres ved at redigere klienten.

Hvilken kilde ser kontrollen egentlig?

Den kildeadresse, som en kontrol vurderer, afhænger af gatewayarkitekturen. En EC2-hostet gateway kan videresende en routet pulje, oversætte til sin egen adresse eller præsentere en anden adresse efter NAT; administreret Client VPN knytter sig til et subnet og følger sin egen model. Sikkerhedsgrupper og netværks-ACL'er ser det, der ankommer efter den behandling. At inspicere en regel mod en forkert kildeantagelse er en almindelig måde at bygge en grænse, der ser korrekt ud og lukker den forkerte trafik ind.

Korrelér hvert resultat med den mindste nyttige hændelse: identitet og session, ressource, handling, tid og beslutningen. Et CloudTrail-API-kald, en VPC-flowpost og en VPN-sessionslog besvarer forskellige spørgsmål, og ingen af dem er alene en applikationsrevision.

Fjern en identitet og test den igen

Medtag fjernelse i samme tabel. Fjern en testidentitet, bekræft at en ny session afvises, og bekræft derefter særskilt, hvordan eksisterende sessioner behandles, for det er forskellig adfærd med forskellige ejere. Kontrollér, hvad der sker efter en genstart eller udskiftning af gatewayen, så en håndtilføjet undtagelse ikke forsvinder lydløst eller vender bredere tilbage. En grænse, der kun holder til næste udrulning, er ikke en grænse.

Intet af dette erstatter arbejdet med patches, gendannelse eller legitimationslivscyklus. Det gør et snævrere løfte målbart: de rigtige mennesker når de rigtige tjenester, mens nærliggende ruter, konti og administrationsflader forbliver uden for bevillingen.

Behold tabellen sammen med udrulningen, og kør den igen, når gatewayen ændres. Testene er billige; antagelserne bag dem er ikke.