Abnahmeprüfungen für ein virtuelles VPN-Gateway mit Zwei-Faktor-Anmeldung
Belegen Sie das Gateway Stufe für Stufe: Registrierung, Anmeldung, Ablehnung, Widerruf und Wiederherstellung, jeweils mit einem Artefakt und einer vor dem Test formulierten Bestehensbedingung.
Anbieter beschreiben dieses Gerät als virtuell und zweifaktorfähig, und keines der beiden Wörter beantwortet die Fragen, die den Kauf entscheiden. Welches Hypervisor-Image unterstützt wird, welche Clients sich registrieren können, was der zweite Faktor tatsächlich beweist und was passiert, wenn der Identitätsanbieter ausfällt, ist weiterhin offen. Machen Sie daraus Abnahmestufen, die Sie in einer Probe durchspielen können, und die Entscheidung hängt nicht mehr davon ab, wie überzeugend das Datenblatt ist. Das Blatt unten ist eine Struktur für diese Nachweise, keine Rangliste von Produkten.
Was der Anbieter zu dieser Bereitstellung bestätigen muss
Beginnen Sie damit, die Bereitstellung auf eine Seite zu bringen: der Hypervisor oder die Cloud, die Gastarchitektur, das unterstützte Image und die Schnittstellen, die das Gerät erwartet. Ergänzen Sie die Nutzer mit ihren Betriebssystemen, ob Geräte verwaltet werden und wie Registrierung und Anmeldung funktionieren sollen. Dann der private Zugang: Anwendungen und Präfixe, DNS-Anordnung, Rückwege und ob ein öffentlicher Internetausgang Teil des Angebots ist.
Der Betrieb gehört auf dieselbe Seite: wer die Box wartet, woher Updates kommen, wohin Protokolle gehen, wie die Konfiguration geschützt wird und welches Wiederherstellungsziel das Unternehmen tatsächlich vereinbart hat. Verlangen Sie vom Anbieter die Bestätigung genau dieser Kombination und nicht die, dass die Software in einer virtuellen Maschine läuft. Halten Sie externe Abhängigkeiten wie einen Identitätsanbieter oder einen Lizenzdienst sichtbar, denn sie gehören zur Bereitstellung, ob sie mitgeliefert werden oder nicht. Eine Bereitstellungsseite ohne benannte Abhängigkeit ist meist eine Bereitstellungsseite mit einer unbekannten Abhängigkeit.
Belegen Sie, dass der zweite Faktor ein zweiter Faktor ist
Benennen Sie den Authenticator und den Verifizierungsablauf, und sagen Sie, welche Identität jeder Schritt herstellt. Zwei Passwortabfragen hintereinander sind kein zweiter Faktor, und ein Passwort plus Einmalcode ist eine andere Behauptung als ein kryptografischer, an den Dienst gebundener Authenticator. Schreiben Sie den Ablauf auf, den Sie kaufen, nicht das Etikett auf der Box.
Phishing-Resistenz ist eine eigene Eigenschaft, und die NIST-Leitlinie zu Authenticatoren behandelt sie genau so: Ein Code, zu dessen Weitergabe ein Nutzer verleitet werden kann, erfüllt weiterhin Multifaktor-Authentifizierung und verfehlt doch diese zusätzliche Bedingung. Verlangen Sie die Eigenschaft ausdrücklich, wenn sie Ihnen wichtig ist. Verlangen Sie dann eine Vorführung mit dem Clienttyp, den Ihre Nutzer tatsächlich einsetzen, die Registrierung, eine abgelehnte oder abgelaufene Aufforderung, Wiederherstellung nach einem verlorenen Authenticator und den Widerruf eines Nutzers abdeckt, während andere verbunden bleiben. Halten Sie die Identitätsprüfung des Gateways im Umfang, denn ein Client, der jedem Gateway vertraut, hat das Problem verschoben statt gelöst.
Schreiben Sie die Bestehensbedingung, bevor Sie etwas kaputt machen
Die Tabelle unten ist der Teil des Blatts, der den Kontakt mit einem Anbieter übersteht, weil jede Zeile ein Artefakt statt einer Zusicherung verlangt. Füllen Sie die Bestehensbedingung vor der Probe aus, und behandeln Sie eine Zeile ohne Nachweis als fehlgeschlagene Zeile. Fünf Stufen decken ab, was ein Gateway leisten muss.
| 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 |
Die Registrierung steht zuerst, weil alles Weitere von ihr abhängt: ein Gerät, das sich nicht registrieren kann, lässt sich nicht testen. Die Anmeldung ist eine eigene Stufe gegenüber der Registrierung, und die Ablehnung ist die Stufe, die die meisten Blätter vergessen, denn ein Gateway, das alle hereinlässt, hat nicht gezeigt, dass es jemanden ablehnt. Widerruf und Wiederherstellung tragen den größten Teil des Betriebsrisikos, und beides lässt sich billig auf einer Kopie üben.
Üben Sie auf der Kopie, nicht am produktiven Gateway
Führen Sie die störenden Stufen auf einer Kopie der Plattform nach dem unterstützten Bereitstellungsverfahren aus, und bewahren Sie jeden Nachweis mit Datum und Konfigurationsversion auf. Eine Neustartzeile wird nicht durch einen Neustart von der Konsole beantwortet, und eine Wiederherstellungszeile nicht durch den Export der Konfiguration. Notieren Sie, welcher Zustand von selbst zurückkehrt und was sich neu verbinden muss, denn genau diese Differenz erbt das Betriebsteam. Die Probe ist auch die einzige Gelegenheit, eine Wiederherstellung zu messen, ohne einen Ausfall erklären zu müssen.
Halten Sie den Zustand des Identitätsanbieters im Moment jedes Tests fest, denn eine Ausfallzeile, die gegen einen gesunden Anbieter getestet wird, beweist das Gegenteil dessen, was das Blatt behauptet. Zwei Prüfer bei derselben Probe finden unterschiedliche Dinge, und der zweite findet meist die Zeile, deren Nachweis ein Screenshot eines Dashboards ist. Halten Sie diesen Nachweis an der Zeile befestigt, zu der er gehört, nicht in einem nach dem Projekt benannten Ordner.
Messen Sie die Last, die Ihr Team fahren wird
Einigen Sie sich auf eine Last, die einer normalen Woche ähnelt, und messen Sie sie dann dort, wo Sie bereitstellen wollen: Nebenläufigkeit, Verkehrsmischung und das Wartungsfenster, das das Team tatsächlich hat. Eine beworbene Durchsatzzahl beschreibt eine Laborbedingung und sagt nichts über Ihre Nutzer. Messen Sie die Wiederherstellung am Wiederherstellungsziel statt am Plan.
Das Blatt ist fertig, wenn jede Stufe ein Artefakt und jedes Artefakt ein Datum hat. Ein Gerät, das jemand wartet, mit einem Nachweis für jede Zeile, ist ein anderer Kauf als die längste Liste abgehakter Kästchen.