Verificări de acceptare pentru un gateway VPN virtual cu autentificare în doi factori
Demonstrați gatewayul etapă cu etapă: înrolare, autentificare, refuz, revocare și restaurare, fiecare cu un artefact și o condiție de trecere scrisă înainte de test.
Furnizorii descriu acest aparat ca virtual și capabil de doi factori, iar niciunul dintre cele două cuvinte nu răspunde la întrebările care decid achiziția. Ce imagine de hipervizor este suportată, ce clienți se pot înrola, ce dovedește de fapt al doilea factor și ce se întâmplă când furnizorul de identitate cade rămân deschise. Transformați-le în etape de acceptare pe care le puteți rula într-o repetiție, iar decizia nu mai depinde de cât de convingătoare este fișa tehnică. Foaia de mai jos este o structură pentru aceste dovezi, nu un clasament de produse.
Ce trebuie să confirme furnizorul despre acest implementare
Începeți prin a strânge implementarea pe o singură pagină: hipervizorul sau cloudul, arhitectura invitatului, imaginea suportată și interfețele pe care le așteaptă aparatul. Adăugați utilizatorii cu sistemele lor de operare, dacă dispozitivele sunt administrate și cum ar trebui să funcționeze înrolarea și autentificarea. Apoi accesul privat: aplicații și prefixe, aranjamentul DNS, căile de întoarcere și dacă o ieșire publică spre internet face parte din ofertă.
Operarea aparține aceleiași pagini: cine întreține echipamentul, de unde vin actualizările, unde ajung jurnalele, cum este protejată configurația și ce obiectiv de recuperare a acceptat de fapt afacerea. Cereți furnizorului să confirme exact acea combinație, nu că software-ul rulează într-o mașină virtuală. Păstrați vizibile dependențele externe, precum un furnizor de identitate sau un serviciu de licențiere, pentru că fac parte din implementare indiferent dacă sunt livrate cu ea. O pagină de implementare fără nicio dependență numită este de obicei o pagină de implementare cu o dependență necunoscută.
Dovediți că al doilea factor este un al doilea factor
Numiți autentificatorul și fluxul de verificare și spuneți ce identitate stabilește fiecare pas. Două solicitări de parolă consecutive nu sunt un al doilea factor, iar o parolă plus un cod de unică folosință este o afirmație diferită de cea a unui autentificator criptografic legat de serviciu. Scrieți fluxul pe care îl cumpărați, nu eticheta de pe cutie.
Rezistența la phishing este o proprietate separată, iar ghidul NIST privind autentificatorii o tratează ca atare: un cod pe care utilizatorul poate fi păcălit să îl retransmită satisface încă autentificarea multifactor dar eșuează acea condiție suplimentară. Cereți proprietatea explicit dacă vă pasă. Apoi cereți o demonstrație de la tipul de client pe care utilizatorii dumneavoastră îl rulează efectiv, care să acopere înrolarea, o provocare respinsă sau expirată, recuperarea după pierderea autentificatorului și revocarea unui utilizator în timp ce ceilalți rămân conectați. Țineți verificarea identității gatewayului în scop, pentru că un client care se încrede în orice gateway a mutat problema în loc să o rezolve.
Scrieți condiția de trecere înainte de a strica ceva
Tabelul de mai jos este partea foii care supraviețuiește contactului cu un furnizor, pentru că fiecare rând cere un artefact în loc de o asigurare. Completați condiția de trecere înainte de repetiție și tratați un rând fără dovezi ca un rând eșuat. Cinci etape acoperă ce trebuie să facă un gateway.
| 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 |
Înrolarea vine prima pentru că tot ce urmează depinde de ea: un dispozitiv care nu se poate înrola nu poate fi testat. Autentificarea este o etapă separată de înrolare, iar refuzul este etapa pe care majoritatea foilor o uită, pentru că un gateway care îi primește pe toți nu a demonstrat că refuză pe cineva. Revocarea și restaurarea poartă cea mai mare parte a riscului operațional, iar ambele sunt ieftin de exersat pe o copie.
Exersați pe copie, nu pe gatewayul în producție
Rulați etapele perturbatoare pe o copie a platformei, urmând procedura de implementare suportată, și păstrați fiecare dovadă cu data și versiunea de configurație. Un rând de repornire nu primește răspuns printr-o repornire din consolă, iar un rând de restaurare nu primește răspuns prin exportul configurației. Notați ce stare revine de la sine și ce trebuie reconectat, pentru că acea diferență este ce moștenește echipa de operare. Repetiția este și singura ocazie de a cronometra o restaurare fără a explica o cădere.
Înregistrați starea furnizorului de identitate în momentul fiecărui test, pentru că un rând de cădere testat împotriva unui furnizor sănătos dovedește opusul a ceea ce afirmă foaia. Doi recenzori la aceeași repetiție prind lucruri diferite, iar al doilea găsește de obicei rândul a cărui dovadă este o captură de ecran a unui panou. Țineți dovada atașată rândului căruia îi aparține, nu într-un folder cu numele proiectului.
Măsurați sarcina de lucru pe care o va rula echipa dumneavoastră
Conveniți asupra unei sarcini asemănătoare unei săptămâni normale, apoi măsurați-o acolo unde intenționați să implementați: concurență, mix de trafic și fereastra de mentenanță pe care echipa o are efectiv. O cifră de debit anunțată descrie o condiție de laborator și nu spune nimic despre utilizatorii dumneavoastră. Măsurați restaurarea față de obiectivul de recuperare, nu față de plan.
Foaia este terminată când fiecare etapă are un artefact și fiecare artefact are o dată. Un aparat pe care cineva îl întreține, cu dovezi pentru fiecare rând, este o altă achiziție decât cea mai lungă listă de căsuțe bifate.