Aanvaarding van VPC-afstandtoegang verg weieringstoetse

Aanvaarding van afstandtoegang is 'n tabel van verwagte uitkomste, nie 'n skermkiekie van 'n werkende bladsy nie. Vir elke groep skryf jy neer wat behoort te slaag en wat behoort te misluk, en dan voer jy albei teen toegewyde toetsidentiteite in 'n beheerde tydvenster uit. Die weierings is die deel wat die grens bewys; 'n suksesvolle aanmelding bewys net dat die tonnel bestaan. Dit alles werk met die VPN-produk wat reeds gekies is.

Gebruik aparte rekeninge vir die toetse en benoem hulle sodat niemand 'n toetsidentiteit met 'n werklike uitsondering verwar nie.

Skryf die grens as verwagte resultate

Begin by die rolle eerder as by die komponente: wie het watter diens nodig, van waar af, en met watter identiteit. Neem 'n voorbeeld-VPC: een groep het toegang tot die verhoogomgewing via HTTPS nodig, 'n ander het 'n produksiedatabasis nodig, en 'n derde, kleiner groep beheer die poort self. Elke ry kry 'n verwagte toelating en 'n verwagte weiering, insluitend die naburige diens en die naburige rekening wat nie behoort te werk nie. Daardie tabel is die aanvaardingskriterium, en mense wat nie die toetse uitvoer nie, kan dit nagaan.

Toets die databasis-aanmelding afsonderlik van die netwerkpad. 'n Bereikbare TCP-poort behoort nie te veroorsaak dat 'n ongoedgekeurde databasisrekening slaag nie, en VPN-lidmaatskap behoort nie 'n wolk-IAM-rol te skep of administratiewe API-toegang te verleen nie. Dit is drie onafhanklike beheermaatreëls, en hulle faal onafhanklik.

Roete is nie magtiging nie

'n Roete maak 'n pad moontlik; dit verleen nie toestemming nie. Om 'n roete terug te hou is 'n swak plaasvervanger vir 'n beperking wat by die bestemming afgedwing word, want 'n kliënt kan altyd self 'n roete byvoeg. Die sekuriteitsgroep, die databasis-toekenning en die toepassing se eie magtiging bly die beheermaatreëls wat besluit. Wanneer 'n toets onverwags slaag, kyk eerste na die bestemming se beleid eerder as na die roetertabel wat jy bedoel het die kliënt moes hê.

Dit is ook hoekom die weieringstoetse op die bedienerkant mik: daardie resultate kan nie verander word deur die kliënt te wysig nie.

Watter bron sien die beheermaatreël werklik?

Die bronadres wat 'n beheermaatreël evalueer, hang van die poort-argitektuur af. 'n EC2-gehuisde poort kan 'n geroteerde poel deurstuur, na sy eie adres vertaal, of ná NAT 'n ander adres voorhou; bestuurde Client VPN koppel aan 'n subnet en volg sy eie model. Sekuriteitsgroepe en netwerk-ACL's sien wat ook al ná daardie verwerking aankom. Om 'n reël teen die verkeerde bronaanname te ondersoek, is 'n algemene manier om 'n grens te bou wat korrek lyk en die verkeerde verkeer toelaat.

Korreleer elke resultaat met die kleinste nuttige gebeurtenis: identiteit en sessie, hulpbron, bewerking, tyd en die beslissing. 'n CloudTrail-API-oproep, 'n VPC-vloeirekord en 'n VPN-sessielogboek beantwoord verskillende vrae, en nie een alleen is 'n toepassingsoudit nie.

Onttrek 'n identiteit en toets weer

Sluit onttrekking by dieselfde tabel in. Verwyder 'n toetsidentiteit, bevestig dat 'n nuwe sessie geweier word, en bevestig dan afsonderlik hoe bestaande sessies hanteer word, want dit is verskillende gedrag met verskillende eienaars. Kyk wat ná 'n herbegin of vervanging van die poort gebeur, sodat 'n handmatig bygevoegde uitsondering nie stilweg verdwyn of wyer terugkeer nie. 'n Grens wat net tot die volgende ontplooiing hou, is nie 'n grens nie.

Niks hiervan vervang pleisterwerk, herstel of werk aan die lewensiklus van geloofsbriewe nie. Dit maak 'n smaller belofte meetbaar: die regte mense bereik die regte dienste, terwyl nabygeleë roetes, rekeninge en bestuursoppervlakke buite die toekenning bly.

Hou die tabel by die ontplooiing en voer dit weer uit wanneer die poort verander. Die toetse is goedkoop; die aannames agter hulle is nie.