Provjere prihvaćanja virtualnog VPN pristupnika s dvofaktorskom autentifikacijom
Dokažite pristupnik etapu po etapu: upis, prijava, odbijanje, opoziv i vraćanje, svaki s dokazom i uvjetom 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 kupnji. Koja je slika hipervizora podržana, koji se klijenti mogu upisati, što drugi faktor doista dokazuje i što se događa kad pružatelj identiteta padne — sve je to još otvoreno. Pretvorite to u etape prihvaćanja koje možete izvesti na probi, i odluka prestaje ovisiti o tome koliko je tehnički list uvjerljiv. List ispod je struktura za te dokaze, a ne rangiranje proizvoda.
Što dobavljač mora potvrditi o ovom postavljanju
Počnite tako da postavljanje svedete na jednu stranicu: hipervizor ili oblak, arhitektura gosta, podržana slika i sučelja koja uređaj očekuje. Dodajte korisnike, njihove operativne sustave, upravlja li se uređajima i kako upis i prijava trebaju raditi. Zatim privatni pristup: aplikacije i prefiksi, uređenje DNS-a, povratne putanje i je li javni internetski izlaz dio ponude.
Operacije pripadaju istoj stranici: tko održava kutiju, odakle dolaze ažuriranja, kamo idu zapisi, kako je konfiguracija zaštićena i koji je cilj vraćanja poslovanje doista dogovorilo. Tražite od dobavljača da potvrdi upravo tu kombinaciju, a ne da softver radi u virtualnom stroju. Držite vanjske ovisnosti, poput pružatelja identiteta ili usluge licenciranja, vidljivima, jer su dio postavljanja bez obzira na to isporučuju li se s njim. Stranica postavljanja bez imenovane ovisnosti obično je stranica postavljanja s nepoznatom ovisnošć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 drukčija je tvrdnja od kriptografskog autentifikatora vezanog uz uslugu. Zapišite tok koji kupujete, a ne etiketu na kutiji.
Otpornost na phishing zasebno je svojstvo, i NIST-ove 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 uvjet. Tražite to svojstvo izričito ako vam je važno. Zatim zahtijevajte demonstraciju na tipu klijenta koji vaši korisnici doista koriste, obuhvaćajuć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 je klijent koji vjeruje bilo kojem pristupniku premjestio problem umjesto da ga riješi.
Napišite uvjet prolaza prije nego što bilo što pokvarite
Tablica ispod dio je lista koji preživi susret s dobavljačem, jer svaki red traži dokaz umjesto uvjeravanja. Popunite uvjet 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 ovisi: uređaj koji se ne može upisati 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žani postupak 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 što se mora ponovno povezati, 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žatelja identiteta u trenutku svakog testa, jer red o ispadu testiran uz zdravog pružatelja 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 snimka zaslona kontrolne ploče. Držite taj dokaz prikopčan uz red kojem pripada, a ne u mapi nazvanoj po projektu.
Izmjerite opterećenje koje će vaš tim izvoditi
Dogovorite opterećenje slično normalnom tjednu, pa ga izmjerite tamo gdje namjeravate postavljati: paralelnost, mješavina prometa i prozor održavanja koji tim doista ima. Oglašena brojka propusnosti opisuje laboratorijski uvjet i ništa ne govori o vašim korisnicima. Mjerite vraćanje prema cilju vraćanja, a ne prema planu.
List je gotov kad svaka etapa ima dokaz i svaki dokaz ima datum. Uređaj koji netko održava, s dokazom za svaki red, drukčija je kupnja od najduljeg popisa označenih polja.