Godkjenningskontroller for en virtuell VPN-gateway med tofaktor-pålogging
Bevis gatewayen trinn for trinn: registrering, pålogging, avvisning, tilbakekalling og gjenoppretting, hver med et artefakt og en beståelsesbetingelse skrevet før testen.
Leverandører beskriver dette apparatet som virtuelt og tofaktorkapabelt, og ingen av de to ordene svarer på spørsmålene som avgjør kjøpet. Hvilket hypervisor-avbilde som støttes, hvilke klienter som kan registrere seg, hva den andre faktoren faktisk beviser, og hva som skjer når identitetsleverandøren faller ned, er fortsatt åpent. Gjør dem om til godkjenningstrinn du kan kjøre i en prøve, og beslutningen slutter å avhenge av hvor overbevisende databladet er. Arket nedenfor er en struktur for disse bevisene, ikke en rangering av produkter.
Hva leverandøren må bekrefte om denne utrullingen
Begynn med å presse utrullingen ned på én side: hypervisoren eller skyen, gjestearkitekturen, det støttede avbildet og grensesnittene apparatet forventer. Legg til brukerne med operativsystemene deres, om enhetene administreres, og hvordan registrering og pålogging skal fungere. Deretter den private tilgangen: applikasjoner og prefikser, DNS-oppsett, returveier, og om en offentlig internettutgang er en del av tilbudet.
Drift hører på samme side: hvem vedlikeholder boksen, hvor oppdateringene kommer fra, hvor loggene går, hvordan konfigurasjonen beskyttes, og hvilket gjenopprettingsmål virksomheten faktisk har avtalt. Be leverandøren bekrefte nøyaktig den kombinasjonen, ikke at programvaren kjører i en virtuell maskin. Hold eksterne avhengigheter som en identitetsleverandør eller en lisenseringstjeneste synlige, fordi de er en del av utrullingen enten de leveres med den eller ikke. En utrullingsside uten navngitt avhengighet er som regel en utrullingsside med en ukjent avhengighet.
Bevis at den andre faktoren er en andre faktor
Navngi autentikatoren og verifiseringsflyten, og si hvilken identitet hvert trinn etablerer. To passordforespørsler etter hverandre er ikke en andre faktor, og et passord pluss en engangskode er en annen påstand enn en kryptografisk autentikator bundet til tjenesten. Skriv ned flyten du kjøper, ikke etiketten på boksen.
Motstandsdyktighet mot phishing er en egen egenskap, og NISTs veiledning om autentikatorer behandler den nettopp slik: en kode en bruker kan lures til å videresende oppfyller fortsatt multifaktor-autentisering, men feiler på den ekstra betingelsen. Krev egenskapen uttrykkelig hvis den betyr noe for deg. Krev deretter en demonstrasjon fra den klienttypen brukerne dine faktisk kjører, som dekker registrering, en avvist eller utløpt utfordring, gjenoppretting etter en tapt autentikator og tilbakekalling av én bruker mens andre forblir tilkoblet. Hold gatewayens identitetsverifisering i omfanget, fordi en klient som stoler på enhver gateway har flyttet problemet i stedet for å løse det.
Skriv beståelsesbetingelsen før du ødelegger noe
Tabellen nedenfor er den delen av arket som overlever kontakten med en leverandør, fordi hver rad krever et artefakt i stedet for en forsikring. Fyll ut beståelsesbetingelsen før prøven, og behandle en rad uten bevis som en mislykket rad. Fem trinn dekker det en gateway må gjøre.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
Registrering kommer først fordi alt nedstrøms avhenger av den: en enhet som ikke kan registrere seg, kan ikke testes. Pålogging er et eget trinn fra registrering, og avvisning er trinnet de fleste ark glemmer, fordi en gateway som slipper alle inn, ikke har vist at den avviser noen. Tilbakekalling og gjenoppretting bærer mesteparten av den driftsmessige risikoen, og begge er billige å øve på en kopi.
Øv på kopien, ikke på den levende gatewayen
Kjør de forstyrrende trinnene på en kopi av plattformen, etter den støttede utrullingsprosedyren, og ta vare på hvert bevis med dato og konfigurasjonsversjon. En omstartrad besvares ikke av en omstart fra konsollen, og en gjenopprettingsrad besvares ikke ved å eksportere konfigurasjonen. Noter hvilken tilstand som kommer tilbake av seg selv og hva som må kobles til på nytt, fordi den forskjellen er det driftsteamet arver. Prøven er også den eneste sjansen til å ta tid på en gjenoppretting uten å forklare et avbrudd.
Registrer identitetsleverandørens tilstand i det øyeblikket hver test kjøres, fordi en avbruddsrad testet mot en frisk leverandør beviser det motsatte av det arket hevder. To gjennomgåere på samme prøve fanger ulike ting, og den andre finner som regel raden hvis bevis er et skjermbilde av et dashbord. Hold beviset festet til raden det hører til, ikke i en mappe oppkalt etter prosjektet.
Mål arbeidsbelastningen teamet ditt skal kjøre
Bli enige om en belastning som ligner en normal uke, og mål den der du har tenkt å rulle ut: samtidighet, trafikkmiks og vedlikeholdsvinduet teamet faktisk har. Et annonsert gjennomstrømningstall beskriver en laboratorietilstand og sier ingenting om brukerne dine. Mål gjenopprettingen mot gjenopprettingsmålet, ikke mot planen.
Arket er ferdig når hvert trinn har et artefakt og hvert artefakt har en dato. Et apparat noen vedlikeholder, med bevis for hver rad, er et annet kjøp enn den lengste listen av avkryssede bokser.