Dienstkonto-VPN-Zugang: Zertifikat oder geteilter Login

Zwei Entwürfe decken fast jede unbeaufsichtigte VPN-Einrichtung ab: ein geteilter menschlicher Login in einem Skript oder ein Maschinenzertifikat, das an den Host gebunden ist. Sie scheitern an unterschiedlichen Stellen, was mehr zählt als die Einrichtungsgeschwindigkeit. Ein gespeichertes Passwort bricht, wenn sein Besitzer es ändert oder das Unternehmen verlässt; ein Zertifikat bricht, wenn es abläuft oder der Host ohne den Schlüssel neu aufgebaut wird. Drei Bedingungen entscheiden, welche Kosten Sie tragen können, und keiner der Entwürfe beschränkt etwas, bis die Autorisierungsrichtlinie es tut.

Beginne bei der Aufgabe, nicht beim Konto

Die Aufgabe definiert die Grenze: welche Ziele, welche Dienste, welche Zeiten, wie lange eine Sitzung laufen darf. Eine Tunnelroute ist nur die Hälfte dieser Grenze. Das Gateway entscheidet, ob die Sitzung erlaubt ist; die Ressource dahinter entscheidet, was die Sitzung tun kann. Schreiben Sie die Liste zuerst auf, mit einem benannten Eigentümer, denn beide Identitätsentwürfe müssen sie erfüllen.

Halten Sie Authentifizierung und Autorisierung getrennt, während Sie das aufschreiben. Authentifizierung beantwortet, wer sich verbindet; Autorisierung beantwortet, was die Sitzung danach erreichen darf. RADIUS trägt den zweiten Teil als Attribute wie Filter-Id, Framed-IP-Address, Session-Timeout und Class, und das Gateway hängt sie an, sobald der Login gelingt. Ein Entwurf, der den Login tauscht und die Autorisierung unangetastet lässt, hat nichts begrenzt.

Geteilter menschlicher Login: Das Passwort wird zur Grenze

Ein menschliches Konto wiederzuverwenden ist der schnellste Weg und der, der am schlechtesten altert. Die Anmeldedaten sind ein Passwort, also landen sie in einem Skript, einer Umgebungsdatei und einer Scheduler-Konfiguration, und jede Kopie muss rotiert werden. Wenn der Besitzer es an einem Freitag ändert, scheitert der Job beim nächsten Lauf, und niemand schaut zu.

MFA ist der Punkt, an dem dieser Entwurf meist zusammenbricht. Ein Skript kann keine Push-Abfrage beantworten, also wird das Konto von der Richtlinie ausgenommen, und das ist genau das Konto, das ein Angreifer wählen würde. Ausnahmen, Umgehungen vertrauenswürdiger Standorte und Ausnahmen pro Konto vermehren sich, und keine davon ist für die nächste Person sichtbar, die die Tenant-Einstellungen liest.

Zuordnung ist der andere Preis. Jede Sitzung im Gateway-Protokoll trägt denselben Benutzernamen, sodass die nächtliche Synchronisierung nicht von der Arbeit der Person zu unterscheiden ist, die sie geschrieben hat, und den Job zu widerrufen bedeutet, diese Person zu widerrufen.

Maschinenzertifikat: Identität an den Host gebunden

Ein Zertifikat ändert die Frage von dem, was das Konto weiß, zu dem, was der Host ist. Bei EAP-TLS legt der Client ein Zertifikat vor und beweist den Besitz des passenden privaten Schlüssels; der Richtlinienserver ordnet den Betreff oder das Computerkonto einer Gruppe zu und wendet die Richtlinie für diese Gruppe an. Keine Abfrage, kein gemeinsames Geheimnis in einer Textdatei.

Die Grenze, die es schafft, ist enger, als Menschen erwarten. Ein Zertifikat authentifiziert den Host, nicht die Aufgabe, und jeder mit Root- oder lokalen Administratorrechten kann diesen Schlüssel auf diesem Host verwenden. Bewahren Sie den Schlüssel dort auf, wo die Plattform ihn schützt: nicht exportierbar im Windows-Zertifikatspeicher, TPM-gestützt, wo das Profil es erlaubt, oder eine Root-eigene 0600-Datei unter Linux. Host-Kompromittierung ist Anmeldedaten-Kompromittierung.

Der Ablauf ist der wiederkehrende Fehler. Ein Zertifikat, das an einem Sonntag abläuft, stoppt den Job am Sonntag, und das Gateway meldet normalerweise einen allgemeinen Authentifizierungsfehler, statt das Datum zu nennen. Prüfen Sie die Daten vom Job-Host als Teil des Runbooks:

openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcerts

Widerruf braucht einen Pfad, den das Gateway prüft. OpenVPN liest eine CRL über die Option crl-verify, und strongSwan hängt je nach Aufbau des Verbindungsprofils von CRL oder OCSP ab. Wenn keines von beiden angebunden ist, bedeutet das Entfernen eines Hosts, auf den Ablauf des Zertifikats zu warten.

Drei Bedingungen, die zwischen ihnen entscheiden

Vergleichen Sie mit der Plattform, die Sie haben, nicht mit einem Referenzentwurf.

Erste Bedingung: Kann das Gateway eine Maschinenidentität autorisieren? Wenn es nur einen RADIUS-Benutzernamen einem Verzeichnisbenutzer zuordnet, authentifiziert ein Zertifikat den Host und bleibt dann bei der Autorisierung hängen. Zweite Bedingung: Braucht der Job Ressourcenzugriff, den nur ein Benutzerkonto trägt, etwa eine eingebundene Freigabe oder eine Lizenz pro Arbeitsplatz? Dann kann eine Maschinenidentität nicht einspringen, und die ehrliche Antwort ist ein dediziertes Benutzerkonto mit einer eng gefassten Richtlinie. Dritte Bedingung: Wer kann die Anmeldedaten ohne eine Person im Ablauf rotieren? Automatische Registrierung macht Zertifikate billig zu halten; ein Passwort, das eine Person kennt, nicht.

Lesen Sie die Tabelle als Kostenliste, nicht als Rangfolge. Die Spalte mit dem gespeicherten Geheimnis gewinnt bei der Widerrufsgeschwindigkeit und bei der Kompatibilität mit Ressourcen, die nur Benutzerkonten verstehen; die Zertifikatsspalte gewinnt bei der Rotation und dabei, MFA nicht zu schwächen, damit ein Skript funktioniert.

Legen Sie die Grenze in die Richtlinie, nach der Authentifizierung

Welche Identität Sie auch wählen, die Berechtigungsgrenze gehört in die Richtlinie, die nach der Authentifizierung läuft. In NPS werden Netzwerkrichtlinien der Reihe nach ausgewertet, und die erste Richtlinie, die jede Bedingung erfüllt, wendet ihre Einstellungen an, sodass eine breite Richtlinie über einer engen das Ergebnis bestimmt, unabhängig davon, was der Client vorlegt. Microsoft dokumentiert das Bedingungs- und Einstellungsmodell in seiner NPS-Richtlinienübersicht.

Geben Sie dem Job eine eigene Gruppe oder Richtlinienbedingung, basierend auf etwas, das die Maschinenidentität trägt: eine Zertifikatsvorlage, eine Kennung der anrufenden Station oder eine Adresse aus einem dedizierten Pool. Begrenzen Sie dann die Sitzung mit Attributen: ein Filter-Id für die Rolle, auf die Ihr Gateway sie abbildet, ein kurzes Session-Timeout, damit ein hängender Job sich neu authentifiziert, statt tagelang eine Sitzung zu halten, und eine Framed-IP-Address aus einem Pool, den Sie auf der Gegenseite per Firewall filtern. Die Anwendungsautorisierung bleibt getrennt: Ein Tunnel zu einem Datenbankserver ist keine Berechtigung, eine Tabelle darin zu lesen.

Prüfen Sie Ablehnungen, planen Sie dann die Entfernung

Zugang, der funktioniert, beweist nichts über minimale Rechte. Testen Sie stattdessen die Ablehnungen: Verbinden Sie sich mit der Job-Identität und greifen Sie nach einem Ziel außerhalb der Liste, öffnen Sie eine zweite gleichzeitige Sitzung, wenn das Gateway nur eine zulassen soll, und wiederholen Sie den Login nach dem Widerruf der Anmeldedaten.

Bestätigen Sie dann dieselbe Sitzung an zwei Stellen. Das Gateway-Protokoll zeigt die Identität, die sich authentifiziert hat; das Protokoll des Richtlinienservers zeigt, welche Richtlinie gepasst hat und welche Attribute zurückgegeben wurden. Bei OpenVPN zeichnet der Server den Common Name des Zertifikats auf, und ipsec statusall auf strongSwan gibt den aufgebauten Tunnel mit der verwendeten Identität aus. Wenn die beiden Protokolle über die Identität uneinig sind, passt die Richtlinie auf etwas anderes, als Sie annehmen.

Die Entfernung gehört in den Entwurf, nicht in einen Aufräum-Sprint. Schreiben Sie alles auf, was zu löschen ist (Zertifikat oder Konto, Gruppenmitgliedschaft, Netzwerkrichtlinie, Pool-Eintrag, Firewall-Regel auf dem Ziel), und führen Sie es einmal aus, solange der Job leicht neu aufzubauen ist.

Wenn Sie heute beginnen, arbeiten Sie in dieser Reihenfolge: Schreiben Sie die Ressourcenliste, wählen Sie die Identität mit den drei Bedingungen, legen Sie die Grenze in die Richtlinie, und üben Sie eine Ablehnung, bevor der Job live geht.