Preberacie kontroly pre virtuálnu bránu VPN s dvojfaktorovým overovaním
Dokážte bránu etapu po etape: zápis, prihlásenie, odmietnutie, odvolanie a obnova, každá s artefaktom a podmienkou úspechu napísanou pred testom.
Dodávatelia opisujú toto zariadenie ako virtuálne a schopné dvoch faktorov, a ani jedno z tých slov neodpovedá na otázky, ktoré rozhodujú o kúpe. Ktorý obraz hypervizora je podporovaný, ktorí klienti sa môžu zapísať, čo druhý faktor skutočne dokazuje a čo sa stane, keď poskytovateľ identity vypadne, je stále otvorené. Preveďte to na preberacie etapy, ktoré môžete spustiť na skúške, a rozhodnutie prestane závisieť od toho, aký presvedčivý je technický list. Nižšie uvedený list je štruktúrou pre tieto dôkazy, nie rebríčkom produktov.
Čo musí dodávateľ k tomuto nasadeniu potvrdiť
Začnite tým, že nasadenie vtesnáte na jednu stránku: hypervizor alebo cloud, architektúra hosťa, podporovaný obraz a rozhrania, ktoré zariadenie očakáva. Pridajte používateľov s ich operačnými systémami, či sú zariadenia spravované a ako majú zápis a prihlásenie fungovať. Potom súkromný prístup: aplikácie a prefixy, usporiadanie DNS, návratové cesty a či je verejný internetový výstup súčasťou ponuky.
Prevádzka patrí na rovnakú stránku: kto udržiava zariadenie, odkiaľ prichádzajú aktualizácie, kam idú záznamy, ako je chránená konfigurácia a aký cieľ obnovy firma skutočne odsúhlasila. Požiadajte dodávateľa, aby potvrdil presne túto kombináciu, a nie že softvér beží vo virtuálnom stroji. Udržujte vonkajšie závislosti, ako poskytovateľa identity alebo licenčnú službu, viditeľné, pretože sú súčasťou nasadenia bez ohľadu na to, či sa dodávajú s ním. Stránka nasadenia bez pomenovanej závislosti je zvyčajne stránka nasadenia s neznámou závislosťou.
Dokážte, že druhý faktor je druhý faktor
Pomenujte autentifikátor a tok overenia a povedzte, akú identitu každý krok ustanoví. Dve po sebe idúce výzvy na heslo nie sú druhý faktor a heslo plus jednorazový kód je iné tvrdenie než kryptografický autentifikátor viazaný na službu. Zapíšte tok, ktorý kupujete, nie etiketu na krabici.
Odolnosť proti phishingu je samostatná vlastnosť a usmernenia NIST k autentifikátorom ju tak aj berú: kód, ku ktorému možno používateľa naviesť, aby ho preposlal, stále spĺňa viacfaktorové overenie, ale zlyháva v tej dodatočnej podmienke. Ak vám na nej záleží, žiadajte ju výslovne. Potom žiadajte ukážku na type klienta, ktorý vaši používatelia skutočne používajú, zahŕňajúcu zápis, odmietnutú alebo prepadnutú výzvu, obnovu po stratenom autentifikátore a odvolanie jedného používateľa, kým ostatní zostávajú pripojení. Držte overenie identity brány v rozsahu, pretože klient, ktorý verí ktorejkoľvek bráne, problém presunul, namiesto aby ho vyriešil.
Napíšte podmienku úspechu skôr, než niečo rozbijete
Tabuľka nižšie je tou časťou listu, ktorá prežije stretnutie s dodávateľom, pretože každý riadok žiada artefakt namiesto uistenia. Vyplňte podmienku úspechu pred skúškou a riadok bez dôkazov považujte za zlyhaný riadok. Päť etáp pokrýva to, čo brána musí robiť.
| 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 prvý, pretože na ňom závisí všetko ďalšie: zariadenie, ktoré sa nemôže zapísať, nemožno otestovať. Prihlásenie je samostatná etapa od zápisu a odmietnutie je etapa, na ktorú väčšina listov zabúda, pretože brána, ktorá pustí všetkých, nedokázala, že niekomu odmieta. Odvolanie a obnova nesú väčšinu prevádzkového rizika a obe sa dajú lacno vyskúšať na kópii.
Skúšajte na kópii, nie na živej bráne
Spúšťajte rušivé etapy na kópii platformy podľa podporovaného postupu nasadenia a každý dôkaz uchovávajte s jeho dátumom a verziou konfigurácie. Riadok o reštarte nevyrieši reštart z konzoly a riadok o obnove nevyrieši export konfigurácie. Zaznamenajte, ktorý stav sa vráti sám a čo sa musí znovu pripojiť, pretože práve ten rozdiel prevádzkový tím dedí. Skúška je aj jediná príležitosť zmerať obnovu bez vysvetľovania výpadku.
Zaznamenajte stav poskytovateľa identity v okamihu každého testu, pretože riadok o výpadku testovaný proti zdravému poskytovateľovi dokazuje opak toho, čo list tvrdí. Dvaja recenzenti na tej istej skúške zachytia rôzne veci a druhý zvyčajne nájde riadok, ktorého dôkazom je snímka obrazovky panela. Držte ten dôkaz pripevnený k riadku, ku ktorému patrí, nie v priečinku pomenovanom po projekte.
Zmerajte záťaž, ktorú bude váš tím prevádzkovať
Dohodnite sa na záťaži podobnej bežnému týždňu a potom ju zmerajte tam, kde hodláte nasadzovať: súbežnosť, zmes prevádzky a servisné okno, ktoré tím skutočne má. Inzerovaný údaj o priepustnosti opisuje laboratórnu podmienku a o vašich používateľoch nehovorí nič. Merajte obnovu proti cieľu obnovy, nie proti plánu.
List je hotový, keď má každá etapa artefakt a každý artefakt dátum. Zariadenie, ktoré niekto udržiava, s dôkazom pre každý riadok, je iná kúpa než najdlhší zoznam zaškrtnutých políčok.