Provjere prihvatanja virtualnog VPN pristupnika s dvofaktorskom autentifikacijom
Dokažite pristupnik etapu po etapu: upis, prijava, odbijanje, opoziv i vraćanje, svaki s dokazom i uslovom prolaza napisanim prije testa.
Dobavljači opisuju ovaj uređaj kao virtualan i sposoban za dvofaktorsku autentifikaciju, a nijedna od tih riječi ne odgovara na pitanja koja odlučuju o kupovini. Koja je slika hipervizora podržana, koji se klijenti mogu upisati, šta drugi faktor zaista dokazuje i šta se dešava kad pružalac identiteta padne — sve je to još otvoreno. Pretvorite to u etape prihvatanja koje možete izvesti na probi, i odluka prestaje da zavisi od toga koliko je tehnički list uvjerljiv. List ispod je struktura za te dokaze, a ne rangiranje proizvoda.
Šta dobavljač mora potvrditi o ovom postavljanju
Počnite tako što ćete postavljanje svesti na jednu stranicu: hipervizor ili oblak, arhitektura gosta, podržana slika i interfejsi koje uređaj očekuje. Dodajte korisnike, njihove operativne sisteme, da li se uređaji upravljaju i kako upis i prijava treba da rade. Zatim privatni pristup: aplikacije i prefiksi, uređenje DNS-a, povratne putanje i da li je javni internet izlaz dio ponude.
Operacije pripadaju istoj stranici: ko održava kutiju, odakle dolaze ažuriranja, kuda idu zapisi, kako je konfiguracija zaštićena i koji cilj vraćanja je poslovanje zaista dogovorilo. Tražite od dobavljača da potvrdi upravo tu kombinaciju, a ne da softver radi u virtualnoj mašini. Držite vanjske zavisnosti, poput pružaoca identiteta ili usluge licenciranja, vidljivima, jer su dio postavljanja bez obzira na to da li se isporučuju s njim. Stranica postavljanja bez imenovane zavisnosti obično je stranica postavljanja s nepoznatom zavisnošću.
Dokažite da je drugi faktor drugi faktor
Imenujte autentifikator i tok provjere i recite koji identitet uspostavlja svaki korak. Dva uzastopna zahtjeva za lozinku nisu drugi faktor, a lozinka plus jednokratni kod drugačija je tvrdnja od kriptografskog autentifikatora vezanog za uslugu. Zapišite tok koji kupujete, a ne etiketu na kutiji.
Otpornost na phishing je zasebno svojstvo, i NIST smjernice za autentifikatore ga tretira upravo tako: kod koji korisnik može biti prevaren da proslijedi još uvijek zadovoljava višefaktorsku autentifikaciju, ali ne ispunjava taj dodatni uslov. Tražite to svojstvo izričito ako vam je važno. Zatim zahtijevajte demonstraciju na tipu klijenta koji vaši korisnici zaista koriste, obuhvatajući upis, odbijeni ili istekli izazov, oporavak nakon izgubljenog autentifikatora i opoziv jednog korisnika dok ostali ostaju povezani. Držite provjeru identiteta pristupnika u obuhvatu, jer klijent koji vjeruje bilo kojem pristupniku premjestio je problem umjesto da ga riješi.
Napišite uslov prolaza prije nego što bilo šta pokvarite
Tabela ispod je dio lista koji preživi susret s dobavljačem, jer svaki red traži dokaz umjesto uvjeravanja. Popunite uslov prolaza prije probe i tretirajte red bez dokaza kao neuspješan red. Pet etapa pokriva ono što pristupnik mora raditi.
| 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 |
Upis je prvi jer sve nizvodno od njega zavisi: uređaj koji ne može da se upiše ne može se testirati. Prijava je zasebna etapa od upisa, a odbijanje je etapa koju većina listova zaboravi, jer pristupnik koji pušta sve nije dokazao da ikome odbija. Opoziv i vraćanje nose većinu operativnog rizika, i oba se jeftino uvježbavaju na kopiji.
Vježbajte na kopiji, ne na živom pristupniku
Izvedite disruptivne etape na kopiji platforme, slijedeći podržanu proceduru postavljanja, i čuvajte svaki dokaz s njegovim datumom i verzijom konfiguracije. Red o restartu ne odgovara restart s konzole, a red o vraćanju ne odgovara izvoz konfiguracije. Zabilježite koje se stanje vraća samo i šta mora ponovo da se poveže, jer tu razliku nasljeđuje operativni tim. Proba je i jedina prilika da mjerite vrijeme vraćanja bez objašnjavanja ispada.
Zabilježite stanje pružaoca identiteta u trenutku svakog testa, jer red o ispadu testiran uz zdravog pružaoca dokazuje suprotno od onoga što list tvrdi. Dva recenzenta na istoj probi hvataju različite stvari, a drugi obično nađe red čiji je dokaz snimak ekrana kontrolne table. Držite taj dokaz prikačen uz red kojem pripada, a ne u fascikli nazvanoj po projektu.
Izmjerite opterećenje koje će vaš tim izvoditi
Dogovorite opterećenje slično normalnoj sedmici, pa ga izmjerite tamo gdje namjeravate postavljati: paralelnost, mješavina saobraćaja i prozor održavanja koji tim zaista ima. Oglašena brojka propusnosti opisuje laboratorijski uslov i ništa ne govori o vašim korisnicima. Mjerite vraćanje prema cilju vraćanja, a ne prema planu.
List je gotov kada svaka etapa ima dokaz i svaki dokaz ima datum. Uređaj koji neko održava, s dokazom za svaki red, drugačija je kupovina od najduže liste označenih polja.