Sprejemni preizkusi za virtualno VPN-prehod z dvofaktorsko avtentikacijo
Dokažite prehod korak za korakom: vpis, prijava, zavrnitev, preklic in obnovitev, vsak z artefaktom in pogojem za uspeh, zapisanim pred testom.
Dobavitelji to napravo opisujejo kot virtualno in zmožno dveh dejavnikov, in nobena od teh besed ne odgovarja na vprašanja, ki odločajo o nakupu. Katera slika hipervizorja je podprta, kateri odjemalci se lahko vpišejo, kaj drugi dejavnik v resnici dokazuje in kaj se zgodi, ko ponudnik identitete odpove, ostaja odprto. Spremenite to v sprejemne korake, ki jih lahko izvedete na vaji, in odločitev ne bo več odvisna od tega, kako prepričljiv je podatkovni list. Spodnji list je struktura za te dokaze, ne razvrstitev izdelkov.
Kaj mora dobavitelj potrditi o tej namestitvi
Začnite tako, da namestitev stisnete na eno stran: hipervizor ali oblak, gostujoča arhitektura, podprta slika in vmesniki, ki jih naprava pričakuje. Dodajte uporabnike z njihovimi operacijskimi sistemi, ali so naprave upravljane in kako naj delujeta vpis in prijava. Nato zasebni dostop: aplikacije in predpone, ureditev DNS, povratne poti in ali je javni internetni izhod del ponudbe.
Upravljanje sodi na isto stran: kdo vzdržuje napravo, od kod prihajajo posodobitve, kam gredo dnevniki, kako je zaščitena konfiguracija in kateri cilj obnovitve je poslovanje v resnici dogovorilo. Od dobavitelja zahtevajte, da potrdi natanko to kombinacijo, ne pa da programska oprema teče v virtualnem stroju. Ohranjajte zunanje odvisnosti, kot sta ponudnik identitete ali licenčna storitev, vidne, ker so del namestitve ne glede na to, ali se dobavijo z njo. Stran namestitve brez imenovane odvisnosti je običajno stran namestitve z neznano odvisnostjo.
Dokažite, da je drugi dejavnik drugi dejavnik
Imenujte avtentikator in potrditveni tok ter povejte, katero identiteto vzpostavi vsak korak. Dve zaporedni zahtevi za geslo nista drugi dejavnik, geslo z enkratno kodo pa je drugačna trditev kot kriptografski avtentikator, vezan na storitev. Zapišite tok, ki ga kupujete, ne etikete na škatli.
Odpornost na phishing je ločena lastnost in smernice NIST o avtentikatorjih jo obravnavajo prav tako: koda, h kateri je mogoče uporabnika pretentati, da jo posreduje, še vedno izpolnjuje večfaktorsko avtentikacijo, a ne izpolni tega dodatnega pogoja. Zahtevajte to lastnost izrecno, če vam je pomembna. Nato zahtevajte predstavitev na vrsti odjemalca, ki ga vaši uporabniki v resnici uporabljajo, ki pokriva vpis, zavrnjen ali potekel izziv, obnovitev po izgubljenem avtentikatorju in preklic enega uporabnika, medtem ko drugi ostanejo povezani. Držite preverjanje identitete prehoda v obsegu, ker je odjemalec, ki zaupa kateremukoli prehodu, težavo premaknil, namesto da bi jo rešil.
Zapišite pogoj za uspeh, preden karkoli pokvarite
Spodnja tabela je tisti del lista, ki preživi stik z dobaviteljem, ker vsaka vrstica zahteva artefakt namesto zagotovila. Izpolnite pogoj za uspeh pred vajo in vrstico brez dokazov obravnavajte kot neuspešno vrstico. Pet korakov pokriva, kaj mora prehod narediti.
| 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 |
Vpis je prvi, ker je od njega odvisno vse nadaljnje: naprave, ki se ne more vpisati, ni mogoče preizkusiti. Prijava je ločen korak od vpisa, zavrnitev pa je korak, ki ga večina listov pozabi, ker prehod, ki spusti vse, ni dokazal, da komu zavrne. Preklic in obnovitev nosita večino operativnega tveganja in oba sta poceni za vadbo na kopiji.
Vadite na kopiji, ne na živem prehodu
Izvedite moteče korake na kopiji platforme po podprtem postopku namestitve in vsak dokaz shranite z datumom in različico konfiguracije. Vrstice o ponovnem zagonu ne reši ponovni zagon s konzole, vrstice o obnovitvi pa ne reši izvoz konfiguracije. Zabeležite, katero stanje se vrne samo in kaj se mora znova povezati, ker prav to razliko podeduje operativna ekipa. Vaja je tudi edina priložnost za merjenje obnovitve brez razlaganja izpada.
Zabeležite stanje ponudnika identitete v trenutku vsakega testa, ker vrstica o izpadu, preizkušena proti zdravemu ponudniku, dokazuje nasprotno od tega, kar list trdi. Dva preglednika na isti vaji ujameta različne stvari in drugi običajno najde vrstico, katere dokaz je posnetek zaslona nadzorne plošče. Ta dokaz imejte pritrjen na vrstico, ki ji pripada, ne v mapi, poimenovani po projektu.
Izmerite obremenitev, ki jo bo izvajala vaša ekipa
Dogovorite se o obremenitvi, podobni običajnemu tednu, in jo nato izmerite tam, kjer nameravate uvajati: sočasnost, mešanica prometa in vzdrževalno okno, ki ga ekipa v resnici ima. Oglaševana številka prepustnosti opisuje laboratorijske razmere in o vaših uporabnikih ne pove ničesar. Merite obnovitev glede na cilj obnovitve, ne glede na načrt.
List je dokončan, ko ima vsak korak artefakt in vsak artefakt datum. Naprava, ki jo nekdo vzdržuje, z dokazom za vsako vrstico, je drugačen nakup od najdaljšega seznama obkljukanih polj.