openDesk in der Airgapped-Umgebung: eigene PKI für vertrauenswürdige Zertifikate

Wenn das Internet bewusst keine Option ist

Es gibt Umgebungen, in denen ein Internetzugang keine Bequemlichkeitsfrage ist, sondern per Sicherheitskonzept ausgeschlossen wird: Netze mit Verschlusssachen, Leitstellen von KRITIS-Betreibern, Systeme im Verteidigungsumfeld oder Produktionsnetze in der Industrie. Solche Airgap-Umgebungen sind physisch oder logisch vom Internet getrennt – und genau dort wächst der Bedarf an einem souveränen, modernen Arbeitsplatz.

openDesk, der Open-Source-Arbeitsplatz der öffentlichen Verwaltung, passt fachlich hervorragend in dieses Bild. Technisch bringt der Offline-Betrieb jedoch eine Reihe von Fragen mit, die in Standardinstallationen niemand stellt. Eine der wichtigsten: Woher kommen vertrauenswürdige Zertifikate, wenn keine öffentliche Zertifizierungsstelle erreichbar ist?

Warum Let's Encrypt im Airgap nicht weiterhilft

In Umgebungen mit Internetzugang ist die Antwort heute Routine: ACME-Verfahren wie Let's Encrypt stellen Zertifikate automatisch aus, öffentliche Trust-Stores in Browsern und Betriebssystemen sorgen dafür, dass jeder Client ihnen vertraut. Im Airgap fällt beides weg. Die Zertifizierungsstelle ist nicht erreichbar, und selbst wenn ein Zertifikat auf Umwegen hineingelangen würde, ließe es sich mangels Verbindung weder validieren noch automatisch erneuern.

Gleichzeitig braucht eine openDesk-Plattform Verschlüsselung an jeder Stelle, nicht nur am sichtbaren Rand:

• Die Web-Oberflächen aller Module müssen per TLS ausgeliefert werden, damit Anmeldedaten und Inhalte geschützt sind.
• Die Anbindung an den Verzeichnisdienst läuft über LDAPS, also LDAP mit TLS-Verschlüsselung – unverschlüsseltes LDAP ist in Hochsicherheitsumgebungen keine akzeptable Option.
• Auch die interne Service-Kommunikation im Kubernetes-Cluster soll abgesichert sein, denn Zero-Trust-Prinzipien enden nicht an der Cluster-Grenze.

Ohne tragfähiges Zertifikatskonzept bleibt eine Airgap-Installation also entweder unsicher oder funktioniert schlicht nicht, weil Komponenten Verbindungen mit nicht vertrauenswürdigen Zertifikaten verweigern.

Die Antwort: eine eigene Zertifikatsinfrastruktur

Die Lösung ist eine interne PKI, also eine eigene Public-Key-Infrastruktur, die alle benötigten Zertifikate selbst ausstellt. Bewährt hat sich ein zweistufiger Aufbau: Eine Root-CA bildet den obersten Vertrauensanker und wird besonders geschützt aufbewahrt. Eine ihr untergeordnete Issuing-CA übernimmt das Tagesgeschäft und stellt die eigentlichen Zertifikate für Dienste und Systeme aus.

Diese Trennung hat einen praktischen Grund: Sie erlaubt es, die Root-CA offline und außerhalb des Wirkbetriebs zu halten, während die Issuing-CA bei Bedarf erneuert oder ersetzt werden kann, ohne dass das Vertrauen aller Clients neu aufgebaut werden muss. Für den Aufbau stehen erprobte Open-Source-Werkzeuge wie OpenXPKI oder Smallstep zur Verfügung – passend zum Souveränitätsanspruch der Gesamtplattform.

Automatisierung mit cert-manager in Kubernetes

Eine PKI, deren Zertifikate manuell beantragt und eingespielt werden, skaliert in einer Plattform wie openDesk nicht – dafür sind es schlicht zu viele Dienste und Endpunkte. In Kubernetes übernimmt deshalb cert-manager die Automatisierung: Mit einem CA-basierten ClusterIssuer, der an die interne Issuing-CA angebunden ist, werden Zertifikate für alle Workloads automatisch ausgestellt und rechtzeitig vor Ablauf erneuert.

Für den Betrieb bedeutet das: Die Plattform verhält sich beim Thema Zertifikate genauso komfortabel wie eine Internet-Installation mit ACME – nur dass die ausstellende Instanz vollständig unter eigener Kontrolle steht. Das CA-Zertifikat wird als Vertrauensanker an alle Komponenten und Clients verteilt, vom Browser der Anwender bis zum letzten Backend-Dienst.

Die Details, die über Erfolg entscheiden

Ob eine interne PKI im Alltag trägt, entscheidet sich an Punkten, die in keiner Schnellanleitung stehen. Einige Beispiele aus unserer Projektpraxis, bewusst verallgemeinert:

• Private Schlüssel werden direkt auf dem Zielsystem erzeugt und verlassen es nie. An die CA geht ausschließlich die Zertifikatsanforderung, der sogenannte CSR. So bleibt das Schlüsselmaterial auch organisatorisch dort, wo es hingehört.
• Zertifikate sollten sowohl den DNS-Namen als auch die IP-Adresse eines Dienstes als Subject Alternative Name (SAN) enthalten. Dann greifen Hostname-Prüfungen der Clients korrekt, und auch Verbindungen direkt per IP-Adresse bleiben vertrauenswürdig – im Airgap mit eigener Namensauflösung keine Seltenheit.
• Java-basierte Komponenten vertrauen dem System-Zertifikatsspeicher nicht automatisch. Der CA-Vertrauensanker muss explizit in ihren Truststore aufgenommen werden, sonst scheitert der Verbindungsaufbau mit dem typischen PKIX-Fehler – einer der häufigsten Stolpersteine in solchen Projekten.
• Weil kein externer Dienst aushilft, müssen Lebenszyklus und Rotation aller Zertifikate intern automatisiert sein. Ein Zertifikat, das unbemerkt abläuft, legt im Zweifel die halbe Plattform still.

Wer diese Punkte von Anfang an einplant, erhält eine Umgebung, in der Zertifikate im Hintergrund zuverlässig funktionieren und kein Betriebsrisiko mehr darstellen.

Was eine eigene PKI strategisch bringt

Jenseits der reinen Notwendigkeit eröffnet die interne PKI handfeste Vorteile:

• Vollständige Datensouveränität: Kein externer Anbieter sieht, welche Systeme existieren oder welche Namen sie tragen.
• Eigene Richtlinien: Laufzeiten, Kryptoalgorithmen und Namensschemata folgen den eigenen Sicherheitsvorgaben, nicht den Vorgaben einer fremden Zertifizierungsstelle.
• Volle Auditierbarkeit: Jede Ausstellung und Erneuerung ist intern nachvollziehbar und dokumentierbar – ein Pluspunkt für Prüfungen und Zertifizierungen.
• Reproduzierbarer Offline-Betrieb: Die Plattform lässt sich ohne jede Internetabhängigkeit wiederherstellen und erweitern.

Ein Baustein der souveränen Airgap-Architektur

Eine interne PKI entfaltet ihren Wert im Zusammenspiel mit weiteren Offline-Bausteinen. Dazu gehören eine interne Image-Registry beziehungsweise ein Mirror für Container-Images, eine interne Namensauflösung per DNS sowie geordnete Offline-Update-Prozesse, über die neue openDesk-Versionen kontrolliert in die abgeschottete Umgebung gelangen. Erst das Zusammenspiel dieser Bausteine macht eine Airgap-Installation dauerhaft betreibbar – die PKI liefert dafür die Vertrauensbasis.

Wie Netpage unterstützt

Wir haben openDesk in abgeschotteten Umgebungen mit hohen Schutzanforderungen aufgebaut und kennen die Stellen, an denen solche Projekte üblicherweise haken. Unsere Leistung umfasst die Konzeption und den Aufbau der internen PKI, ihre Integration in openDesk und Kubernetes mit automatisierter Ausstellung und Erneuerung über cert-manager, die kontrollierte Verteilung der Vertrauensanker an alle Komponenten und Clients sowie die Absicherung des durchgängigen Offline-Betriebs.

Je nach Ausgangslage begleiten wir dabei von der ersten Architekturentscheidung bis zum Regelbetrieb – oder prüfen eine bestehende Umgebung gezielt auf Lücken im Zertifikats- und Vertrauenskonzept.

Nächster Schritt

Wenn Sie openDesk in einer abgeschotteten oder besonders schutzbedürftigen Umgebung einführen wollen, lohnt sich ein früher Blick auf das Zertifikatskonzept – es beeinflusst Architekturentscheidungen, die später nur aufwendig korrigierbar sind. Ein unverbindliches Erstgespräch genügt meist, um den Reifegrad der eigenen Planung einzuschätzen und die nächsten Schritte zu priorisieren.