Virtualios VPN tinklo vartų su dviejų veiksnių autentifikavimu priėmimo patikros
Įrodykite vartus etapas po etapo: registracija, prisijungimas, atmetimas, atšaukimas ir atkūrimas, kiekvienas su artefaktu ir prieš testą parašyta sėkmės sąlyga.
Tiekėjai šį įrenginį apibūdina kaip virtualų ir galintį dviejų veiksnių autentifikavimą, ir nė vienas iš šių žodžių neatsako į klausimus, kurie lemia pirkimą. Koks hipervizoriaus atvaizdas palaikomas, kurie klientai gali registruotis, ką antrasis veiksnys iš tikrųjų įrodo ir kas nutinka, kai tapatybės teikėjas nustoja veikti, vis dar atvira. Paverskite tai priėmimo etapais, kuriuos galite paleisti repeticijoje, ir sprendimas nustos priklausyti nuo to, kiek įtikinama yra duomenų lentelė. Žemiau pateiktas lapas yra tų įrodymų struktūra, o ne produktų reitingas.
Ką tiekėjas turi patvirtinti apie šį diegimą
Pradėkite nuo to, kad sutalpintumėte diegimą į vieną puslapį: hipervizorius arba debesis, svečio architektūra, palaikomas atvaizdas ir sąsajos, kurių tikisi įrenginys. Pridėkite naudotojus su jų operacinėmis sistemomis, ar įrenginiai valdomi, ir kaip turėtų veikti registracija bei prisijungimas. Tada privati prieiga: programos ir priešdėliai, DNS išdėstymas, grįžimo keliai ir ar vieša interneto išėjimas yra pasiūlymo dalis.
Eksploatacija priklauso tam pačiam puslapiui: kas prižiūri įrenginį, iš kur ateina atnaujinimai, kur keliauja žurnalai, kaip saugoma konfigūracija ir kokį atkūrimo tikslą verslas iš tikrųjų suderino. Paprašykite tiekėjo patvirtinti būtent tą derinį, o ne tai, kad programinė įranga veikia virtualioje mašinoje. Laikykite matomas išorines priklausomybes, tokias kaip tapatybės teikėjas ar licencijavimo paslauga, nes jos yra diegimo dalis, nesvarbu, ar tiekiamos kartu su juo. Diegimo puslapis be įvardytos priklausomybės paprastai yra diegimo puslapis su nežinoma priklausomybe.
Įrodykite, kad antrasis veiksnys yra antrasis veiksnys
Įvardykite autentifikatorių ir patvirtinimo eigą, ir pasakykite, kokią tapatybę nustato kiekvienas žingsnis. Du iš eilės slaptažodžio prašymai nėra antrasis veiksnys, o slaptažodis su vienkartiniu kodu yra kitas teiginys nei su paslauga susietas kriptografinis autentifikatorius. Užrašykite eigą, kurią perkate, o ne etiketę ant dėžutės.
Atsparumas fišingui yra atskira savybė, ir NIST autentifikatorių gairės ją traktuoja būtent taip: kodas, kurį naudotojas gali būti apgautas perduoti, vis dar atitinka daugiaveiksnę autentifikaciją, bet nepraeina tos papildomos sąlygos. Reikalaukite savybės aiškiai, jei ji jums svarbi. Tada reikalaukite demonstracijos su tuo kliento tipu, kurį jūsų naudotojai iš tikrųjų naudoja, apimdami registraciją, atmestą ar pasibaigusį iššūkį, atkūrimą po prarasto autentifikatoriaus ir vieno naudotojo atšaukimą, kol kiti lieka prisijungę. Laikykite vartų tapatybės patvirtinimą apimtyje, nes klientas, kuris pasitiki bet kuriais vartais, problemą perkėlė, o ne išsprendė.
Užrašykite sėkmės sąlygą prieš ką nors sulaužydami
Žemiau pateikta lentelė yra ta lapo dalis, kuri atlaiko susidūrimą su tiekėju, nes kiekviena eilutė prašo artefakto, o ne užtikrinimo. Užpildykite sėkmės sąlygą prieš repeticiją ir eilutę be įrodymų laikykite nepavykusia eilute. Penki etapai apima tai, ką vartai turi daryti.
| 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 |
Registracija yra pirmoji, nes nuo jos priklauso viskas, kas toliau: įrenginio, kuris negali registruotis, negalima išbandyti. Prisijungimas yra atskiras nuo registracijos etapas, o atmetimas yra etapas, kurį dauguma lapų pamiršta, nes vartai, įleidžiantys visus, neįrodė, kad kam nors atsisako. Atšaukimas ir atkūrimas neša didžiąją dalį eksploatacinės rizikos, ir abu pigiai repetuojami kopijoje.
Repetuokite kopijoje, o ne veikiančiuose vartuose
Trikdančius etapus vykdykite platformos kopijoje, laikydamiesi palaikomos diegimo procedūros, ir saugokite kiekvieną įrodymą su jo data ir konfigūracijos versija. Perkrovimo eilutė neatsakoma perkrovimu iš konsolės, o atkūrimo eilutė neatsakoma eksportuojant konfigūraciją. Pažymėkite, kuri būsena grįžta pati ir ką reikia prijungti iš naujo, nes būtent tą skirtumą paveldi eksploatacijos komanda. Repeticija taip pat vienintelė proga išmatuoti atkūrimą neaiškinant sutrikimo.
Užfiksuokite tapatybės teikėjo būseną kiekvieno testo metu, nes sutrikimo eilutė, patikrinta su sveiku teikėju, įrodo priešingai, nei teigia lapas. Du recenzentai toje pačioje repeticijoje pagauna skirtingus dalykus, o antrasis paprastai randa eilutę, kurios įrodymas yra ataskaitų srities ekrano kopija. Laikykite tą įrodymą pritvirtintą prie eilutės, kuriai jis priklauso, o ne aplanke, pavadintame pagal projektą.
Išmatuokite darbo krūvį, kurį atliks jūsų komanda
Susitarkite dėl krūvio, panašaus į įprastą savaitę, ir tada išmatuokite jį ten, kur ketinate diegti: lygiagretumas, srauto mišinys ir techninės priežiūros langas, kurį komanda iš tikrųjų turi. Skelbiamas pralaidumo skaičius apibūdina laboratorinę sąlygą ir nieko nesako apie jūsų naudotojus. Matuokite atkūrimą pagal atkūrimo tikslą, o ne pagal planą.
Lapas baigtas, kai kiekvienas etapas turi artefaktą ir kiekvienas artefaktas turi datą. Įrenginys, kurį kažkas prižiūri, su įrodymu kiekvienai eilutei, yra kitas pirkinys nei ilgiausias pažymėtų langelių sąrašas.