Godkjenningstestar for ein virtuell VPN-gateway med tofaktor-pålogging
Prov gatewayen trinn for trinn: registrering, pålogging, avvising, tilbakekalling og gjenoppretting, kvar med eit artefakt og ein beståingsbetingelse skriven før testen.
Leverandørar skildrar dette apparatet som virtuelt og tofaktorkapabelt, og ingen av dei to orda svarar på spørsmåla som avgjer kjøpet. Kva hypervisor-avbilete som er støtta, kva klientar som kan registrere seg, kva den andre faktoren faktisk provar, og kva som skjer når identitetsleverandøren fell ned, er framleis ope. Gjer dei om til godkjenningstrinn du kan køyre i ein prøve, og avgjerda sluttar å henge på kor overtydande databladet er. Arket nedanfor er ein struktur for desse prova, ikkje ei rangering av produkt.
Kva leverandøren må stadfeste om denne utrullinga
Byrja med å presse utrullinga ned på éi side: hypervisoren eller skya, gjestearkitekturen, det støtta avbiletet og grensesnitta apparatet ventar. Legg til brukarane med operativsystema deira, om einingane blir styrte, og korleis registering og pålogging skal verke. Deretter den private tilgangen: applikasjonar og prefiks, DNS-oppsett, returvegar, og om ein offentleg internettutgang er del av tilbodet.
Drift høyrer på same sida: kven vedlikeheld boksen, kvar oppdateringane kjem frå, kvar loggane går, korleis konfigurasjonen er verna, og kva gjenopprettingsmål verksemda faktisk har avtalt. Be leverandøren stadfeste nøyaktig den kombinasjonen, ikkje at programvara køyrer i ein virtuell maskin. Hald eksterne avhengnader som ein identitetsleverandør eller ei lisensieringsteneste synlege, fordi dei er del av utrullinga anten dei blir leverte med henne eller ikkje. Ei utrullingsside utan namngjeven avhengnad er som regel ei utrullingsside med ei ukjend avhengnad.
Prov at den andre faktoren er ein andre faktor
Nemn autentikatoren og verifiseringsflyten, og sei kva identitet kvart trinn fastset. To passordførespurnader etter kvarandre er ikkje ein andre faktor, og eit passord pluss ein eingongskode er ein annan påstand enn ein kryptografisk autentikator bunden til tenesta. Skriv ned flyten du kjøper, ikkje etiketten på boksen.
Motstandskraft mot phishing er ein eigen eigenskap, og NIST-rettleiinga om autentikatorar handsamar han nettopp slik: ein kode ein brukar kan luras til å senda vidare oppfyller framleis multifaktor-autentisering, men feilar på den ekstra føresetnaden. Krev eigenskapen uttrykkeleg om han betyr noko for deg. Krev deretter ein demonstrasjon frå den klienttypen brukarane dine faktisk køyrer, som dekkjer registrering, ei avvist eller utlopen utfordring, gjenoppretting etter ein tapt autentikator og tilbakekalling av éin brukar medan andre blir verande tilkopla. Hald identitetsverifiseringa av gatewayen i omfanget, fordi ein klient som stolar på kva gateway som helst har flytta problemet i staden for å løyse det.
Skriv beståingsbetingelsen før du øydelegg noko
Tabellen nedanfor er den delen av arket som overlever kontakten med ein leverandør, fordi kvar rad krev eit artefakt i staden for ei trygging. Fyll ut beståingsbetingelsen før prøva, og handsam ei rad utan prov som ei mislukka rad. Fem trinn dekkjer det ein gateway må gjere.
| 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 kjem først fordi alt nedstraums heng på henne: ei eining som ikkje kan registrere seg, kan ikkje testast. Pålogging er eit eige trinn frå registrering, og avvising er trinnet dei fleste arka gløymer, fordi ein gateway som slepp alle inn ikkje har synt at han avviser nokon. Tilbakekalling og gjenoppretting ber mesteparten av den driftsmessige risikoen, og begge er billege å øve på ein kopi.
Øv på kopien, ikkje på den levande gatewayen
Køyr dei forstyrrande trinna på ein kopi av plattforma, etter den støtta utrullingsprosedyren, og ta vare på kvart prov med dato og konfigurasjonsversjon. Ei omstartrad blir ikkje svara av ein omstart frå konsollen, og ei gjenopprettingsrad blir ikkje svara av å eksportere konfigurasjonen. Noter kva tilstand som kjem att av seg sjølv og kva som må koplast til på nytt, fordi den skilnaden er det driftsteamet arvar. Prøva er også den einaste sjansen til å ta tid på ei gjenoppretting utan å forklare eit avbrot.
Registrer tilstanden til identitetsleverandøren i augneblinken kvar test blir køyrd, fordi ei avbrotsrad testa mot ein frisk leverandør provar det motsette av det arket hevdar. To gjennomlesarar på same prøva fangar ulike ting, og den andre finn som regel rada der provet er eit skjermbilete av eit dashbord. Hald provet fest til rada det høyrer til, ikkje i ei mappe kalla opp etter prosjektet.
Mål arbeidslasta teamet ditt skal køyre
Bli samde om ei last som liknar ei vanleg veke, og mål henne der du har tenkt å rulle ut: samtidigheit, trafikkmiks og vedlikehaldsvindauget teamet faktisk har. Eit annonsert gjennomstrøymetal skildrar ein laboratorietilstand og seier ingenting om brukarane dine. Mål gjenopprettinga mot gjenopprettingsmålet, ikkje mot planen.
Arket er ferdig når kvart trinn har eit artefakt og kvart artefakt har ein dato. Eit apparat nokon vedlikeheld, med prov for kvar rad, er eit anna kjøp enn den lengste lista av avkryssa boksar.