VPC-toegang op afstand accepteren vereist weigeringstests

Acceptatie van toegang op afstand is een tabel met verwachte uitkomsten, geen schermafbeelding van een werkende pagina. Schrijf voor elke groep op wat zou moeten slagen en wat zou moeten mislukken, en voer beide vervolgens uit met speciale testidentiteiten in een gecontroleerd tijdvenster. De weigeringen zijn het deel dat de grens bewijst; een geslaagde login bewijst alleen dat de tunnel bestaat. Dit alles werkt met het al gekozen VPN-product.

Gebruik aparte accounts voor de tests en label ze zo dat niemand een testidentiteit voor een echte uitzondering aanziet.

Schrijf de grens als verwachte resultaten

Begin bij de rollen en niet bij de componenten: wie heeft welke dienst nodig, van waaruit en met welke identiteit. Neem een voorbeeldige VPC: de ene groep heeft de testomgeving via HTTPS nodig, een andere een productiedatabase, en een derde, kleinere groep beheert de gateway zelf. Elke rij krijgt een verwachte toestemming en een verwachte weigering, inclusief de naburige dienst en het naburige account die niet zouden moeten werken. Die tabel is het acceptatiecriterium, en mensen die de tests niet uitvoeren kunnen hem beoordelen.

Test de databaselogin apart van het netwerkpad. Een bereikbare TCP-poort mag een niet-goedgekeurd databaseaccount niet laten slagen, en VPN-lidmaatschap mag geen cloud-IAM-rol aanmaken of administratieve API-toegang verlenen. Dat zijn drie onafhankelijke controles, en ze falen onafhankelijk.

Een route is geen autorisatie

Een route maakt een pad mogelijk; hij verleent geen toestemming. Een route achterhouden is een zwakke vervanging voor een beperking die bij de bestemming wordt afgedwongen, omdat een client altijd zijn eigen route kan toevoegen. De beveiligingsgroep, de databasetoekenning en de eigen autorisatie van de applicatie blijven de controles die beslissen. Wanneer een test onverwacht slaagt, kijk dan eerst naar het beleid van de bestemming en niet naar de routingtabel die je de client toedacht.

Daarom richten de weigeringstests zich op de serverkant: die resultaten zijn niet te veranderen door de client te bewerken.

Welke bron ziet de controle werkelijk?

Het bronadres dat een controle evalueert, hangt af van de gateway-architectuur. Een op EC2 gehoste gateway kan een gerouteerde pool doorsturen, naar zijn eigen adres vertalen of na NAT een ander adres presenteren; een beheerde Client VPN koppelt aan een subnet en volgt zijn eigen model. Beveiligingsgroepen en netwerk-ACL's zien wat na die verwerking aankomt. Een regel toetsen aan de verkeerde aanname over de bron is een veelgebruikte manier om een grens te bouwen die correct lijkt en het verkeerde verkeer doorlaat.

Correleer elk resultaat met de kleinste nuttige gebeurtenis: identiteit en sessie, resource, bewerking, tijd en de beslissing. Een CloudTrail-API-aanroep, een VPC-flowrecord en een VPN-sessielog beantwoorden verschillende vragen, en geen ervan is op zichzelf een applicatie-audit.

Trek een identiteit in en test opnieuw

Neem het intrekken op in dezelfde tabel. Verwijder een testidentiteit, bevestig dat een nieuwe sessie wordt geweigerd, en bevestig daarna afzonderlijk hoe bestaande sessies worden behandeld, want dat zijn verschillende gedragingen met verschillende eigenaren. Controleer wat er gebeurt na een herstart of vervanging van de gateway, zodat een handmatig toegevoegde uitzondering niet stil verdwijnt of breder terugkomt. Een grens die alleen tot de volgende uitrol standhoudt, is geen grens.

Niets hiervan vervangt werk aan patches, herstel of de levenscyclus van inloggegevens. Het maakt een smallere belofte meetbaar: de juiste mensen bereiken de juiste diensten, terwijl nabijgelegen routes, accounts en beheerrijplakken buiten de toekenning blijven.

Bewaar de tabel bij de uitrol en voer hem opnieuw uit wanneer de gateway verandert. De tests zijn goedkoop; de aannames erachter niet.