Leveranciers beschrijven dit apparaat als virtueel en tweefactor-capabel, en geen van beide woorden beantwoordt de vragen die de aankoop beslissen. Welk hypervisor-image wordt ondersteund, welke clients kunnen zich inschrijven, wat de tweede factor werkelijk bewijst en wat er gebeurt als de identiteitsprovider uitvalt, staat nog open. Maak daar acceptatiefases van die u in een repetitie kunt uitvoeren, en de beslissing hangt niet langer af van hoe overtuigend het datablad is. Het blad hieronder is een structuur voor dat bewijs, geen ranglijst van producten.

Wat de leverancier over deze uitrol moet bevestigen

Begin met de uitrol op één pagina te zetten: de hypervisor of de cloud, de gastarchitectuur, het ondersteunde image en de interfaces die het apparaat verwacht. Voeg de gebruikers toe met hun besturingssystemen, of apparaten worden beheerd, en hoe inschrijving en aanmelden moeten werken. Dan de private toegang: applicaties en prefixen, DNS-indeling, retourpaden en of een openbare internetuitgang deel van het aanbod is.

Beheer hoort op dezelfde pagina: wie het apparaat onderhoudt, waar updates vandaan komen, waar logs naartoe gaan, hoe de configuratie wordt beschermd en welk hersteldoel het bedrijf werkelijk is overeengekomen. Vraag de leverancier precies die combinatie te bevestigen, niet dat de software in een virtuele machine draait. Houd externe afhankelijkheden zoals een identiteitsprovider of een licentiedienst zichtbaar, want ze horen bij de uitrol of ze nu meegeleverd worden of niet. Een uitrolpagina zonder genoemde afhankelijkheid is meestal een uitrolpagina met een onbekende afhankelijkheid.

Bewijs dat de tweede factor een tweede factor is

Noem de authenticator en de verificatiestroom, en zeg welke identiteit elke stap vaststelt. Twee wachtwoordvragen achter elkaar zijn geen tweede factor, en een wachtwoord plus een eenmalige code is een andere bewering dan een cryptografische authenticator die aan de dienst is gebonden. Schrijf de stroom op die u koopt, niet het etiket op de doos.

Weerstand tegen phishing is een aparte eigenschap, en de NIST-richtlijn voor authenticatoren behandelt die als zodanig: een code die een gebruiker kan worden misleid door te geven voldoet nog steeds aan multifactor-authenticatie maar faalt op die extra voorwaarde. Vraag de eigenschap expliciet als die voor u belangrijk is. Eis dan een demonstratie van het clienttype dat uw gebruikers werkelijk draaien, die inschrijving, een geweigerde of verlopen uitdaging, herstel na een verloren authenticator en intrekking van één gebruiker dekt terwijl anderen verbonden blijven. Houd de identiteitsverificatie van de gateway in scope, want een client die elke gateway vertrouwt heeft het probleem verplaatst in plaats van opgelost.

Schrijf de slaagvoorwaarde voordat u iets kapotmaakt

De tabel hieronder is het deel van het blad dat contact met een leverancier overleeft, omdat elke rij een artefact vraagt in plaats van een verzekering. Vul de slaagvoorwaarde in vóór de repetitie, en behandel een rij zonder bewijs als een mislukte rij. Vijf fasen dekken wat een gateway moet doen.

Acceptance stageEvidence to keepPass condition
EnrolmentEnrolment record with the device type and the identity usedA new device enrols once, and nobody else can enrol it afterwards
Sign-in with the second factorSession record naming both factors and the gateway identity that was checkedThe session carries the expected identity and the gateway certificate validated
Denial of an unapproved destinationLog line from the control that refused the flow, with the policy nameThe flow is refused and the refusal is attributable to one control
Revocation of one userRevocation timestamp and the sessions that survived itThe named user is out and unaffected users keep working
Restore from configuration backupRestored version plus a probe of a revoked identityThe revision matches the backup and revoked identities stay revoked

Inschrijving komt eerst omdat alles daarna ervan afhangt: een apparaat dat zich niet kan inschrijven, kan niet worden getest. Aanmelden is een aparte fase van inschrijving, en weigering is de fase die de meeste bladen vergeten, omdat een gateway die iedereen toelaat niet heeft aangetoond dat hij iemand weigert. Intrekking en herstel dragen het grootste deel van het operationele risico, en beide zijn goedkoop te oefenen op een kopie.

Oefen op de kopie, niet op de live gateway

Voer de verstorende fasen uit op een kopie van het platform, volgens de ondersteunde uitrolprocedure, en bewaar elk bewijs met datum en configuratieversie. Een herstartrij wordt niet beantwoord door een herstart vanaf de console, en een herstelrij niet door de configuratie te exporteren. Noteer welke toestand vanzelf terugkomt en wat opnieuw moet verbinden, want dat verschil erft het beheerteam. De repetitie is ook de enige kans om een herstel te timen zonder een storing uit te leggen.

Leg de toestand van de identiteitsprovider vast op het moment van elke test, want een storingsrij die tegen een gezonde provider is getest bewijst het omgekeerde van wat het blad beweert. Twee reviewers bij dezelfde repetitie vangen verschillende dingen, en de tweede vindt meestal de rij waarvan het bewijs een schermafbeelding van een dashboard is. Houd dat bewijs vast aan de rij waartoe het hoort, niet in een map die naar het project is vernoemd.

Meet de werklast die uw team gaat draaien

Spreek een werklast af die op een normale week lijkt, en meet die dan waar u wilt uitrollen: gelijktijdigheid, verkeersmix en het onderhoudsvenster dat het team werkelijk heeft. Een geadverteerd doorvoergetal beschrijft een laboratoriumomstandigheid en zegt niets over uw gebruikers. Meet het herstel tegen het hersteldoel, niet tegen het plan.

Het blad is klaar wanneer elke fase een artefact heeft en elk artefact een datum. Een apparaat dat iemand onderhoudt, met bewijs voor elke rij, is een andere aankoop dan de langste lijst met aangevinkte vakjes.

Gerelateerde artikelen