Přejímací kontroly virtuální VPN brány s dvoufázovým ověřením
Dokažte bránu etapu po etapě: zápis, přihlášení, odmítnutí, odvolání a obnova, každá s artefaktem a podmínkou splnění napsanou před testem.
Dodavatelé popisují toto zařízení jako virtuální a schopné dvoufázového ověření, a ani jedno z těch slov neodpovídá na otázky, které rozhodují o koupi. Který obraz hypervizoru je podporován, kteří klienti se mohou zapsat, co druhý faktor skutečně dokazuje a co se stane, když poskytovatel identity vypadne, je stále otevřené. Převeďte to na přejímací etapy, které můžete spustit při zkoušce, a rozhodnutí přestane záviset na tom, jak přesvědčivý je technický list. Níže uvedený list je strukturou pro takové důkazy, ne žebříčkem produktů.
Co musí dodavatel k tomuto nasazení potvrdit
Začněte tím, že nasazení vtěsnáte na jednu stránku: hypervizor nebo cloud, architektura hosta, podporovaný obraz a rozhraní, která zařízení očekává. Přidejte uživatele s jejich operačními systémy, zda jsou zařízení spravována a jak mají zápis a přihlášení fungovat. Pak soukromý přístup: aplikace a prefixy, uspořádání DNS, návratové cesty a zda je veřejný internetový výstup součástí nabídky.
Provoz patří na stejnou stránku: kdo udržuje krabici, odkud přicházejí aktualizace, kam jdou záznamy, jak je chráněna konfigurace a jaký cíl obnovy firma skutečně odsouhlasila. Požádejte dodavatele, aby potvrdil přesně tuto kombinaci, a ne že software běží ve virtuálním stroji. Udržujte vnější závislosti, jako poskytovatele identity nebo licenční službu, viditelné, protože jsou součástí nasazení bez ohledu na to, zda se dodávají s ním. Stránka nasazení bez pojmenované závislosti je obvykle stránkou nasazení s neznámou závislostí.
Dokažte, že druhý faktor je druhý faktor
Pojmenujte autentizátor a tok ověření a řekněte, jakou identitu každý krok ustavuje. Dvě výzvy k zadání hesla po sobě nejsou druhý faktor a heslo plus jednorázový kód je jiné tvrzení než kryptografický autentizátor svázaný se službou. Zapište tok, který kupujete, ne etiketu na krabici.
Odolnost proti phishingu je samostatná vlastnost a pokyny NIST k autentizátorům ji tak i bere: kód, ke kterému lze uživatele přemluvit, aby ho přeposlal, stále splňuje vícefaktorové ověření, ale tu dodatečnou podmínku nesplňuje. Pokud vám na ní záleží, žádejte ji výslovně. Pak požadujte ukázku na typu klienta, který vaši uživatelé skutečně používají, zahrnující zápis, odmítnutou nebo propadlou výzvu, obnovu po ztraceném autentizátoru a odvolání jednoho uživatele, zatímco ostatní zůstávají připojeni. Držte ověření identity brány v rozsahu, protože klient, který věří jakékoli bráně, problém přesunul, místo aby ho vyřešil.
Napište podmínku splnění, než něco rozbijete
Tabulka níže je tou částí listu, která přežije střet s dodavatelem, protože každý řádek žádá artefakt místo ujištění. Vyplňte podmínku splnění před zkouškou a považujte řádek bez důkazu za neúspěšný řádek. Pět etap pokrývá to, co brána musí dělat.
| 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 |
Zápis je první, protože na něm závisí vše další: zařízení, které se nemůže zapsat, nelze otestovat. Přihlášení je samostatná etapa od zápisu a odmítnutí je etapa, na kterou většina listů zapomíná, protože brána, která pustí všechny, nedokázala, že někomu odmítá. Odvolání a obnova nesou většinu provozního rizika a obojí se dá levně vyzkoušet na kopii.
Zkoušejte na kopii, ne na živé bráně
Spouštějte rušivé etapy na kopii platformy podle podporovaného postupu nasazení a každý důkaz uchovávejte s jeho datem a verzí konfigurace. Řádek o restartu nevyřeší restart z konzole a řádek o obnově nevyřeší export konfigurace. Zaznamenejte, který stav se vrátí sám a co se musí znovu připojit, protože právě ten rozdíl provozní tým dědí. Zkouška je také jediná příležitost změřit obnovu, aniž byste vysvětlovali výpadek.
Zaznamenejte stav poskytovatele identity v okamžiku každého testu, protože řádek o výpadku testovaný proti zdravému poskytovateli dokazuje opak toho, co list tvrdí. Dva recenzenti na stejné zkoušce zachytí různé věci a druhý obvykle najde řádek, jehož důkazem je snímek obrazovky panelu. Držte ten důkaz přiložený k řádku, ke kterému patří, ne ve složce pojmenované po projektu.
Změřte zátěž, kterou bude váš tým provozovat
Dohodněte se na zátěži podobné běžnému týdnu a pak ji změřte tam, kde hodláte nasazovat: souběžnost, směs provozu a servisní okno, které tým skutečně má. Inzerovaný údaj o propustnosti popisuje laboratorní podmínku a o vašich uživatelích neříká nic. Měřte obnovu proti cíli obnovy, ne proti plánu.
List je hotový, když má každá etapa artefakt a každý artefakt datum. Zařízení, které někdo udržuje, s důkazem pro každý řádek, je jiná koupě než nejdelší seznam zaškrtnutých políček.