Acceptanstester för en virtuell VPN-gateway med tvåfaktorsinloggning
Bevisa gatewayen steg för steg: registrering, inloggning, avslag, återkallande och återställning, var och en med en artefakt och ett godkännandevillkor skrivet före testet.
Leverantörer beskriver den här apparaten som virtuell och tvåfaktorskapabel, och inget av de två orden svarar på frågorna som avgör köpet. Vilken hypervisor-avbildning som stöds, vilka klienter som kan registrera sig, vad den andra faktorn faktiskt bevisar och vad som händer när identitetsleverantören fallerar är fortfarande öppet. Gör dem till acceptanssteg du kan köra i en repetition, och beslutet slutar bero på hur övertygande databladet är. Arket nedan är en struktur för dessa bevis, inte en rangordning av produkter.
Vad leverantören måste bekräfta om denna utrullning
Börja med att pressa ihop utrullningen till en sida: hypervisorn eller molnet, gästarkitekturen, den stödda avbildningen och de gränssnitt apparaten förväntar sig. Lägg till användarna med deras operativsystem, om enheterna hanteras och hur registrering och inloggning ska fungera. Sedan den privata åtkomsten: applikationer och prefix, DNS-upplägg, returvägar och om en offentlig internetutgång ingår i erbjudandet.
Drift hör till samma sida: vem som underhåller boxen, varifrån uppdateringar kommer, vart loggarna tar vägen, hur konfigurationen skyddas och vilket återställningsmål verksamheten faktiskt har kommit överens om. Be leverantören bekräfta exakt den kombinationen, inte att programvaran körs i en virtuell maskin. Håll externa beroenden som en identitetsleverantör eller en licensieringstjänst synliga, eftersom de är en del av utrullningen vare sig de levereras med den eller inte. En utrullningssida utan namngivet beroende är oftast en utrullningssida med ett okänt beroende.
Bevisa att den andra faktorn är en andra faktor
Namnge autentiseraren och verifieringsflödet, och säg vilken identitet varje steg fastställer. Två lösenordsfrågor i rad är inte en andra faktor, och ett lösenord plus en engångskod är ett annat påstående än en kryptografisk autentiserare bunden till tjänsten. Skriv ned flödet du köper, inte etiketten på boxen.
Motståndskraft mot nätfiske är en separat egenskap, och NIST:s vägledning om autentiserare behandlar den just så: en kod som en användare kan luras att vidarebefordra uppfyller fortfarande multifaktorautentisering men fallerar på det extra villkoret. Kräv egenskapen uttryckligen om den spelar roll för dig. Kräv sedan en demonstration från den klienttyp dina användare faktiskt kör, som täcker registrering, en avvisad eller utgången utmaning, återställning efter en förlorad autentiserare och återkallande av en användare medan andra förblir anslutna. Håll gatewayens identitetsverifiering inom ramen, för en klient som litar på vilken gateway som helst har flyttat problemet i stället för att lösa det.
Skriv godkännandevillkoret innan du förstör något
Tabellen nedan är den del av arket som överlever kontakten med en leverantör, eftersom varje rad kräver en artefakt i stället för en försäkran. Fyll i godkännandevillkoret före repetitionen, och behandla en rad utan bevis som en misslyckad rad. Fem steg täcker vad en gateway måste göra.
| 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 |
Registreringen kommer först eftersom allt nedströms beror på den: en enhet som inte kan registrera sig kan inte testas. Inloggning är ett eget steg från registrering, och avslag är steget som de flesta ark glömmer, eftersom en gateway som släpper in alla inte har visat att den avvisar någon. Återkallande och återställning bär större delen av den operativa risken, och båda är billiga att öva på en kopia.
Öva på kopian, inte på den skarpa gatewayen
Kör de störande stegen på en kopia av plattformen, enligt den stödda utrullningsproceduren, och spara varje bevis med datum och konfigurationsversion. En omstartsrad besvaras inte av en omstart från konsolen, och en återställningsrad besvaras inte av att konfigurationen exporteras. Notera vilket tillstånd som återkommer av sig självt och vad som måste återansluta, eftersom den skillnaden är vad driftsteamet ärver. Repetitionen är också det enda tillfället att ta tid på en återställning utan att förklara ett avbrott.
Registrera identitetsleverantörens tillstånd i ögonblicket för varje test, eftersom en avbrottsrad testad mot en frisk leverantör bevisar motsatsen till vad arket hävdar. Två granskare på samma repetition fångar olika saker, och den andre hittar oftast raden vars bevis är en skärmbild av en instrumentpanel. Håll det beviset fäst vid raden det hör till, inte i en mapp uppkallad efter projektet.
Mät den arbetsbelastning ditt team kommer att köra
Kom överens om en belastning som liknar en normal vecka, och mät den sedan där du tänker rulla ut: samtidighet, trafikmix och det underhållsfönster teamet faktiskt har. En annonserad genomströmningssiffra beskriver ett laboratorieförhållande och säger ingenting om dina användare. Mät återställningen mot återställningsmålet, inte mot planen.
Arket är klart när varje steg har en artefakt och varje artefakt har ett datum. En apparat som någon underhåller, med bevis för varje rad, är ett annat köp än den längsta listan av ikryssade rutor.