Interne PKI

Die interne PKI von Enterprise kann Root- und Zwischenzertifizierungsstellen erstellen, Server-, Client-, Code-Signing- und E-Mail-Zertifikate ausstellen, Vorlagen anwenden, CRLs veröffentlichen und unterstützte Formate mit ausdrücklichen Scopes exportieren.

In der Konsole befindet sich die interne PKI auf der Seite Certificates in den Registerkarten Authorities, PKI Certificates und Templates.

Verwenden Sie die interne PKI, wenn Opfield eine private Vertrauensdomäne für Personen, Dienste, Code-Signing oder E-Mail-Schutz betreiben soll. Das Ausstellen eines Zertifikats ist der erste Schritt: Bevor es zu einer Produktionsabhängigkeit wird, weisen Sie seine Kette, den vorgesehenen Verwendungszweck, Verlängerung, Widerruf, Backup und Wiederherstellung nach.

PKI bedeutet Public-Key-Infrastruktur: die Zertifizierungsstellen, Zertifikate, privaten Schlüssel, Widerrufseinträge und Richtlinien, mit denen Systeme entscheiden, welchen Identitäten sie vertrauen. Eine Root-Zertifizierungsstelle ist der oberste Vertrauensanker. Eine Zwischenzertifizierungsstelle stellt die alltäglichen Zertifikate aus, damit die Root seltener verwendet und stärker geschützt werden kann.

Private Schlüssel werden mit PKI_MASTER_KEY verschlüsselt. Bewahren Sie diesen Schlüssel unabhängig vom Datenbank-Backup auf. Beschränken Sie Exportberechtigungen und protokollieren Sie jede Operation an Zertifizierungsstellen, Zertifikaten, Widerrufen und privaten Schlüsseln im Audit.

Die benutzerseitige interne PKI ist von der verborgenen System-PKI von Opfield für den verwalteten Transport getrennt. Nach dem Ende einer Lizenz-Kulanzfrist bleiben bestehende Zertifizierungsstellen, Zertifikate, Vorlagen und der Audit-Verlauf erhalten; Sie können sie weiterhin ansehen, Widerrufslisten herunterladen, Zertifikate widerrufen und exportieren und Vorlagen löschen, während das Erstellen von Zertifizierungsstellen, das Ausstellen von Zertifikaten und das Ändern von Vorlagen wieder den Tarif erfordern. Der Systemtransport funktioniert weiter.

Vertrauensmodell

Erstellen Sie eine Root-Zertifizierungsstelle nur, wenn Opfield für diesen Vertrauensanker zuständig sein soll. Halten Sie die Root bevorzugt offline oder verwenden Sie sie selten und stellen Sie betriebliche Zertifikate von einer Zwischenzertifizierungsstelle aus. Vorlagen beschränken Subject, Laufzeit, Key Usage, Extended Key Usage und Exportverhalten, damit Operatoren die Richtlinie nicht für jede Anfrage manuell nachbilden.

Die benutzerseitigen Zertifizierungsstellen von Opfield dürfen niemals umfunktioniert werden, um die verborgene System-PKI, die Database CA, Daemon-Identitäten oder Dienstidentitäten von Relay zu ersetzen. Diese internen Vertrauensdomänen haben eigene Verträge für Rotation und Wiederherstellung.

Governance-Entscheidungen

Geben Sie vor dem Erstellen einer Root ihren Geltungsbereich, Verantwortlichen, ihre Laufzeit, die erlaubten Zertifikatszwecke, den Kontakt bei Vorfällen und den Plan zur Außerbetriebnahme frei. Entscheiden Sie, ob die Root in Opfield erzeugt oder importiert wird, ob der Export privater Schlüssel erlaubt ist und welche vertrauenden Systeme Zertifikatssperrlisten (CRLs) verwenden werden. Sind diese Entscheidungen nicht dokumentiert, ist das Erstellen der Zertifizierungsstelle verfrüht.

Verwenden Sie getrennte Zwischenzertifizierungsstellen für wesentlich unterschiedliche Umgebungen oder Vertrauensstufen. Eine kompromittierte Ausstellungsstelle für die Entwicklung sollte nicht automatisch die Produktion gefährden, und eine Ausstellungsstelle für Code-Signing sollte nicht mit einer allgemeinen Ausstellungsstelle für Serverzertifikate austauschbar sein. Vorlagen sollten diese Grenzen abbilden, statt sich auf das Gedächtnis der Operatoren zu verlassen.

Eine Hierarchie von Zertifizierungsstellen bereitstellen

1. Bestätigen Sie den Enterprise-Leistungsumfang und die benötigten PKI-Scopes.
2. Erzeugen oder importieren Sie die Root-Zertifizierungsstelle.
3. Sichern Sie PKI_MASTER_KEY und die Opfield-Datenbank über getrennte geschützte Verfahren.
4. Erstellen Sie eine Zwischenzertifizierungsstelle für die vorgesehene Umgebung oder Organisationsgrenze.
5. Erstellen Sie Vorlagen für Server-, Client-, Code-Signing- oder E-Mail-Zertifikate.
6. Stellen Sie ein Testzertifikat aus und prüfen Sie seine Kette, Key Usage, Laufzeit und sein Exportformat.
7. Veröffentlichen und testen Sie den CRL-Ort vor der Ausstellung für die Produktion.

Zertifikate ausstellen und betreiben

Halten Sie für jedes Zertifikat Verantwortlichen, Zweck, Vorlage, Subject, Gültigkeit, erwartete Verlängerung und Kontakt für den Widerruf fest. Gewähren Sie den Export privater Schlüssel nur Identitäten, die das Schlüsselmaterial benötigen. Ein Benutzer, der Zertifikatsmetadaten einsehen kann, benötigt nicht automatisch Berechtigungen für Zertifizierungsstellen oder den Schlüsselexport.

Verwendet eine Route ein Zertifikat einer internen CA, liefert der Ingress Node es zusammen mit seinen Zwischen-CAs aus, sodass Clients, die nur der Root vertrauen, es validieren können.

Prüfen Sie vor einer Verlängerung, dass Subject und vorgesehener Verwendungszweck noch gültig sind. Widerrufen Sie kompromittierte oder ausgemusterte Zertifikate, veröffentlichen Sie die aktualisierte CRL und bestätigen Sie, dass vertrauende Systeme sie verwenden. Das Löschen eines Eintrags in der Oberfläche ersetzt keinen Widerruf, wenn einem Zertifikat extern noch vertraut werden könnte.

Gültigkeit, Ablaufalarme und automatische Neuausstellung

Ein Zertifikat kann die CA, die es ausstellt, nicht überdauern. Standardmäßig wird eine Anfrage, deren Gültigkeit nach dem Ende der CA enden würde, mit VALIDITY_EXCEEDS_CA abgelehnt. Setzen Sie clampToCaValidity in der REST API, MCP oder im Assistenten, damit das Zertifikat stattdessen mit seiner CA endet; der Ausstellungsdialog zeigt einen Hinweis und wendet es automatisch an. Aus einem CSR signierte Zertifikate folgen derselben Regel. Leaf-Zertifikate der System-CAs von Opfield enden immer mit ihrer CA.

Opfield löst Ablaufalarme für Benutzer-CAs 180, 60, 30 und 7 Tage vor ihrem Ablauf aus (die letzten beiden folgen den Einstellungen für PKI-Ablaufwarnung und -kritisch) und für System-CAs 730, 365, 180, 60, 30 und 7 Tage im Voraus. System-CAs haben noch keine automatische Erneuerung, und jedes von ihnen ausgestellte Zertifikat für Nodes, Relays, verwalteten Speicher und verwaltete Datenbanken funktioniert nach ihrem Ablauf nicht mehr; planen Sie ihren Ersatz daher, sobald der erste Alarm erscheint. Alarme nennen die zuständige Ressource, etwa einen verwalteten Speichercluster, eine verwaltete Datenbank, ein Relay, einen Opfield-Listener oder einen Node. Jede Schwelle alarmiert einmal: Das Verwerfen eines Alarms gilt bis zur nächsten Schwelle, und ein verlängertes Zertifikat alarmiert in seiner neuen Laufzeit erneut.

Ein Zertifikat der internen PKI, das als SSL-Zertifikat verknüpft ist oder auf das eine Route direkt verweist, wird automatisch neu ausgestellt, wenn Opfield seinen privaten Schlüssel hält; aus einem CSR signierte Zertifikate werden nie neu ausgestellt. Die Neuausstellung erfordert wie eine manuelle Ausstellung pki:cert:issue auf der CA.

Vergeben Sie pki:ca:edit, um CRL- und Aussteller-URLs, die maximale Gültigkeit und den OCSP-Responder einer CA zu ändern, und pki:ca:export, um eine CA samt privatem Schlüssel zu exportieren; beide können auf eine CA beschränkt werden. pki:ca:view umfasst Root- und Zwischen-CAs und kann ebenfalls auf eine CA beschränkt werden.

Zertifizierungsstellen, Zertifikate und Zertifikatsvorlagen können wie Routen und SSL-Zertifikate in Ordnern organisiert werden: Ordner erstellen, umbenennen und neu ordnen, Einträge zwischen ihnen verschieben und beim Erstellen eines Eintrags einen Ordner wählen. Ein CA-Ordner enthält ganze Hierarchien: Nur Root-CAs werden verschoben, und ihre Zwischen-CAs folgen. Berechtigungen auf einem CA-Ordner umfassen jede Root-CA darin und ihre Zwischen-CAs, und Berechtigungen auf einem Zertifikatsordner umfassen die Zertifikate darin; Ordner für Zertifikatsvorlagen organisieren nur die Liste. Siehe Ordnerunterstützung nach Ressourcentyp.

Messen Sie den betrieblichen Erfolg an der Abdeckung von Abläufen, der Veröffentlichung von Widerrufen, der Vollständigkeit des Audits und Wiederherstellungstests. Prüfen Sie Zertifikate ohne Verantwortliche, zu weit gefasste Vorlagen, unerwartete Exporte privater Schlüssel, ungenutzte Zwischen-CAs und CRLs, die vertrauende Systeme nicht erreichen können. Das Anzeigen oder Exportieren privater Schlüssel sollte selten sein, separat autorisiert werden und von einer sicheren Verwahrung außerhalb von Opfield gefolgt werden.

Backup und Wiederherstellung

Ein Datenbank-Backup ohne PKI_MASTER_KEY kann verschlüsselte private Schlüssel nicht wiederherstellen. Ein Schlüssel-Backup ohne die Datenbank kann Zertifizierungsstellen, Vorlagen, Zertifikate, Widerrufe und Audit-Beziehungen nicht rekonstruieren. Speichern und testen Sie beide Teile und halten Sie sie betrieblich getrennt.

Prüfen Sie nach einer Wiederherstellung Ketten der Zertifizierungsstellen, Entschlüsselung, Berechtigungen für den Zertifikatsexport, CRL-Veröffentlichung und Kontinuität des Audits, bevor Sie neues Material ausstellen.

Details für Betreiber: Vorfall und Außerbetriebnahme

Wird ein ausstellender Schlüssel vermutlich kompromittiert, stoppen Sie neue Ausstellungen, ermitteln Sie alle nachgeordneten Zertifikate, bereiten Sie eine Ersatzhierarchie vor, veröffentlichen Sie Widerrufsinformationen und stimmen Sie Änderungen an Truststores mit den vertrauenden Systemen ab. Denselben kompromittierten Schlüssel wiederherzustellen ist keine Wiederherstellung. Bewahren Sie Audit-Belege und die alte öffentliche Kette für die Untersuchung auf, ohne ihr weiter zu vertrauen.

Die Außerbetriebnahme einer Zertifizierungsstelle erfordert mehr, als sie aus der Navigation zu löschen. Stoppen Sie die Ausstellung, ersetzen Sie nachgeordnete Zertifikate oder lassen Sie sie ablaufen, bewahren Sie Widerrufsbelege für den erforderlichen Zeitraum auf, entziehen Sie Clients das Vertrauen und entfernen Sie die Zertifizierungsstelle erst dann, wenn Opfield bestätigt, dass abhängige Objekte aufgelöst sind.

Verhalten bei Leistungsumfang und Löschung

Nach dem Ende einer Lizenz-Kulanzfrist bewahrt Opfield Zertifizierungsstellen und Zertifikate und hält Ansicht, Widerrufslisten, Widerruf und Export von Zertifikaten sowie das Löschen verfügbar, während das Erstellen von Zertifizierungsstellen, das Ausstellen von Zertifikaten und das Ändern von Vorlagen wieder den Tarif erfordern. Der Systemtransport wird nie deaktiviert. Lösen Sie vor dem Löschen einer Zertifizierungsstelle alle untergeordneten Zwischen-CAs und Zertifikate auf und bewahren Sie die erforderlichen Widerrufsbelege auf.