VPN-Zertifikatsausstellung ohne den Root-Schlüssel delegieren

Jemandem die Möglichkeit zu geben, VPN-Clients zu registrieren, und ihm eine portable Kopie des Root-Schlüssels zu geben, sind zwei verschiedene Handlungen, und der Unterschied wird erst sichtbar, wenn diese Person geht oder dieser Schlüssel abfließt. Das Erste gewährt eine Operation innerhalb eines Ablaufs, den Sie kontrollieren; das Zweite gewährt die Fähigkeit, überall, offline und unbegrenzt Vertrauen zu erzeugen. Entscheiden Sie, welche von beiden die Aufgabe braucht, bevor Sie irgendein Schlüsselmaterial anfassen. Ein Hierarchiediagramm beantwortet Ihnen diese Frage nicht.

Schreiben Sie die Registrierungsaufgabe als drei Fragen auf: wer beantragen darf, wer genehmigt und was die ausstellende Komponente signieren darf.

Entscheiden Sie, welche Fähigkeit Sie vergeben

Ein Ausstellungsdienst kann einen Genehmigungsablauf bereitstellen und das Signiermaterial dennoch bei einem getrennten Eigentümer halten. Ein Operator genehmigt eine Geräteanfrage, der Dienst wendet die Richtlinie an und protokolliert die Ausstellung, und niemand Beteiligter besitzt den CA-Schlüssel. Dokumentieren Sie die zulässigen Identitäten, die Genehmiger und den Bereich dessen, was der Dienst signieren darf; schützen Sie dann seine Verwaltung ebenso sorgfältig wie den Schlüssel. Eine Zertifikatsignierungsanfrage ist eine Anfrage, keine Autorisierungsentscheidung.

Hardwaregestützte Speicherung verändert das Risiko, den Schlüssel zu kopieren, nicht die Notwendigkeit einer Autorisierung. Nicht exportierbar bedeutet, dass der Schlüssel nicht herausgehoben werden kann, und es bedeutet nicht, dass jeder, der die Signierschnittstelle aufrufen kann, Anspruch auf ein Zertifikat hat. Bewerten Sie diese beiden Eigenschaften getrennt.

Ein Intermediate begrenzt die Vollmacht

Ein Root kann ein Intermediate für die tägliche Ausstellung zertifizieren, sodass Routinearbeit den Root-Schlüssel nicht mehr berührt, solange die eigenen Signier- und Wiederherstellungsverfahren des Roots geschützt bleiben. Das ist eine echte Grenze, und sie ist nicht kostenlos: ein weiteres Zertifikat, ein weiterer Schlüssel, eine weitere Erneuerung und eine weitere Sperrliste, die gepflegt werden muss. Verwenden Sie eines, wenn es eine bewusste Verwaltungs- oder Risikogrenze darstellt. Für jeden Administrator einen Aussteller anzulegen, erzeugt von allem mehr und kauft nichts, was der Ablauf nicht schon bot.

Prüfen Sie, dass die VPN-Verifier die Kette so aufbauen, wie Sie es erwarten. Ein Intermediate für den Kettenaufbau auszuliefern und es als direkt vertrauenswürdigen Anker zu installieren, sind verschiedene Arrangements.

pathLen null bedeutet nicht, was Sie denken

RFC 5280 Abschnitt 4.2.1.9 definiert die Basiseinschränkungen, und sein Pfadlängenfeld begrenzt, wie viele nicht selbst ausgestellte Intermediate-Zertifikate in einem gültigen Pfad folgen dürfen. Der Wert null beschränkt die weitere Intermediate-Tiefe; er begrenzt nicht die Anzahl der Endentitäts-Zertifikate. Leute lesen es als null erlaubte Zertifikate und wundern sich dann, warum die Ausstellung noch funktioniert. Lesen Sie das Feld als Tiefenbegrenzung für CAs, und das Verhalten wird vorhersagbar.

Derselbe Abschnitt legt nahe, dass ein Trust Anchor eine Eingabe in die Pfadvalidierung ist und kein gewöhnliches Zertifikat innerhalb des Pfads. Deshalb entfernt die Veröffentlichung eines Sperreintrags für einen selbstsignierten Root ihn nicht zuverlässig aus jedem Speicher.

Offboarding ist keine Schlüsselkompromittierung

Wenn die ausscheidende Person nichts als ein persönliches Verwaltungskonto hatte, widerrufen Sie diesen Zugang und seine Sitzungen über den unterstützten Identitätsprozess und prüfen Sie dann die Aktivität und die Genehmigungen, die er erzeugt hat. Zuvor ausgestellte Client-Zertifikate werden nicht ungültig, weil ihr Genehmiger gegangen ist, und sie als kompromittiert zu behandeln erzeugt eine große, unnötige Neuregistrierung. Ein Konto zu deaktivieren kann auch einen kopierten Signierschlüssel nicht ungültig machen, daher hängt die Reaktion davon ab, welche Fähigkeit gehalten wurde.

Wenn ein Intermediate kompromittiert wird, muss seine Autorisierung entzogen und jede Identität, für die es gebürgt hat, ersetzt werden, nach welcher Richtlinie der Verifier auch immer durchsetzt. Root-Vertrauen braucht eine eigene Reaktion, weil der Anker in Vertrauensspeichern lebt, die Sie möglicherweise nicht kontrollieren.

Akzeptieren Sie das Design mit vier konkreten Fällen: ein berechtigtes Gerät registriert sich, eine nicht genehmigte Anfrage wird abgelehnt, ein entfernter Operator kann nicht mehr ausstellen, und ein stillgelegter Aussteller gewährt keinen Zugang mehr. Diese vier Ergebnisse sind das Runbook.