Acceptancetest for en virtuel VPN-gateway med tofaktor-login
Bevis gatewayen trin for trin: tilmelding, login, afvisning, tilbagekaldelse og gendannelse, hver med et artefakt og en beståelsesbetingelse skrevet før testen.
Leverandører beskriver denne enhed som virtuel og tofaktor-kompatibel, og ingen af de ord besvarer de spørgsmål, der afgør købet. Hvilket hypervisor-image der understøttes, hvilke klienter der kan tilmelde sig, hvad den anden faktor egentlig beviser, og hvad der sker, når identitetsudbyderen går ned, er stadig åbent. Gør dem til acceptancetrin, du kan køre i en generalprøve, og beslutningen holder op med at afhænge af, hvor overbevisende databladet er. Arket nedenfor er en struktur for den dokumentation, ikke en rangering af produkter.
Det skal leverandøren bekræfte om denne udrulning
Start med at presse udrulningen ned på én side: hypervisoren eller skyen, gæstearkitekturen, det understøttede image og de grænseflader, enheden forventer. Tilføj brugerne med deres styresystemer, om enhederne administreres, og hvordan tilmelding og login skal fungere. Derefter den private adgang: applikationer og præfikser, DNS-arrangement, returveje, og om en offentlig internetudgang er en del af tilbuddet.
Drift hører på samme side: hvem vedligeholder boksen, hvor opdateringer kommer fra, hvor logfilerne ender, hvordan konfigurationen beskyttes, og hvilket gendannelsesmål forretningen faktisk har aftalt. Bed leverandøren bekræfte netop den kombination frem for at softwaren kører i en virtuel maskine. Hold eksterne afhængigheder som en identitetsudbyder eller en licenseringstjeneste synlige, fordi de er en del af udrulningen, uanset om de leveres med den. En udrulningsside uden en navngivet afhængighed er som regel en udrulningsside med en ukendt afhængighed.
Bevis at den anden faktor er en anden faktor
Navngiv autentifikatoren og verifikationsforløbet, og sig hvilken identitet hvert trin fastslår. To adgangskodeopfordringer i træk er ikke en anden faktor, og en adgangskode plus en engangskode er et andet løfte end en kryptografisk autentifikator bundet til tjenesten. Skriv det forløb ned, du køber, frem for etiketten på boksen.
Modstandsdygtighed over for phishing er en separat egenskab, og NISTs vejledning om autentifikatorer behandler den netop som sådan: en kode, en bruger kan narres til at videresende, opfylder stadig multifaktor-godkendelse, men fejler den ekstra betingelse. Kræv egenskaben udtrykkeligt, hvis den betyder noget for dig. Kræv derefter en demonstration fra den klienttype, dine brugere faktisk kører, der dækker tilmelding, en afvist eller udløbet udfordring, gendannelse efter en mistet autentifikator og tilbagekaldelse af én bruger, mens andre forbliver forbundet. Hold gatewayens identitetsverifikation i omfanget, fordi en klient, der stoler på enhver gateway, har flyttet problemet frem for at løse det.
Skriv beståelsesbetingelsen, før du ødelægger noget
Tabellen nedenfor er den del af arket, der overlever kontakten med en leverandør, fordi hver række kræver et artefakt i stedet for en forsikring. Udfyld beståelsesbetingelsen før generalprøven, og behandl en række uden dokumentation som en mislykket række. Fem trin dækker det, en gateway skal gø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 |
Tilmelding kommer først, fordi alt nedstrøms afhænger af den: en enhed, der ikke kan tilmelde sig, kan ikke testes. Login er et trin for sig i forhold til tilmelding, og afvisning er det trin, de fleste ark glemmer, fordi en gateway, der lukker alle ind, ikke har vist, at den afviser nogen. Tilbagekaldelse og gendannelse bærer mest af den driftsmæssige risiko, og begge er billige at øve på en kopi.
Øv på kopien, ikke på den live gateway
Kør de forstyrrende trin på en kopi af platformen efter den understøttede udrulningsprocedure, og gem hvert bevis med dets dato og konfigurationsversion. En genstartsrække besvares ikke af en genstart fra konsollen, og en gendannelsesrække besvares ikke ved at eksportere konfigurationen. Noter, hvilken tilstand der vender tilbage af sig selv, og hvad der skal genoprette forbindelse, fordi netop den forskel arver driftsteamet. Generalprøven er også den eneste chance for at tage tid på en gendannelse uden at forklare et nedbrud.
Registrer identitetsudbyderens tilstand i det øjeblik, hver test kører, fordi en nedbrudsrække testet mod en sund udbyder beviser det modsatte af, hvad arket hævder. To bedømmere på samme generalprøve fanger forskellige ting, og den anden finder som regel rækken, hvis bevis er et skærmbillede af et dashboard. Hold det bevis knyttet til den række, det hører til, ikke i en mappe opkaldt efter projektet.
Mål den arbejdsbyrde, dit team kommer til at køre
Bliv enige om en arbejdsbyrde, der ligner en normal uge, og mål den derefter, hvor du vil udrulle: samtidighed, trafikmiks og det vedligeholdelsesvindue, teamet faktisk har. Et annonceret gennemstrømningstal beskriver en laboratorietilstand og siger intet om dine brugere. Mål gendannelsen mod gendannelsesmålet frem for mod planen.
Arket er færdigt, når hvert trin har et artefakt, og hvert artefakt har en dato. En enhed, nogen vedligeholder, med dokumentation for hver række, er et andet køb end den længste liste af afkrydsede felter.