OZG 2.0 & EfA: Die technische Architektur für den digitalen Staat

Das Ziel des Onlinezugangsgesetzes ist ehrgeizig: Alle Verwaltungsleistungen sollen digital verfügbar sein. Doch die Umsetzung scheiterte in der ersten Phase oft an der kleinteiligen föderalen Struktur. Die Lösung für die zweite Phase (OZG 2.0) ist das EfA-Prinzip. Ein Land entwickelt einen Dienst (z. B. das Elterngeld-Verfahren) und stellt diesen zentral als Cloud-Service für alle anderen Kommunen bereit.

Technisch gesehen ist dies ein massives Skalierungs- und Integrationsproblem. Es erfordert den Wechsel von lokalen “Insel-Servern” hin zu einer modernen, mandantenfähigen Cloud-Native-Plattform.

Die technologische Basis: Cloud-Native & Mandantenfähigkeit

Damit ein Dienst wie “Kfz-Zulassung” für tausende Kommunen gleichzeitig funktionieren kann, muss die Infrastruktur auf drei technischen Säulen stehen:

1. Mandantentrennung auf Namespace-Ebene

In einer EfA-Architektur teilen sich viele Kommunen dieselbe physische Infrastruktur, aber ihre Daten müssen strikt getrennt bleiben.

• Technik: In einem Kubernetes–Cluster werden die Dienste über Namespaces isoliert. Über Network Policies wird auf Layer-3/4-Ebene sichergestellt, dass beispielsweise die Instanz der Stadt Köln keinen Zugriff auf die Datenbank der Stadt Hamburg hat.
• Storage: Jeder Mandant erhält über Persistent Volume Claims (PVC) eigene verschlüsselte Speicherbereiche, die logisch und physikalisch voneinander getrennt sind.

2. Standardisierte Schnittstellen (FIT-Connect)

Das Kernproblem der Verwaltung ist die Interoperabilität. Ein Online-Antrag muss sicher in das jeweilige Fachverfahren der Kommune übertragen werden.

• Technik: Hier kommt der Standard FIT-Connect ins Spiel. Er nutzt eine asynchrone, ereignisgesteuerte Architektur. Die Infrastruktur muss hierfür robuste API-Gateways und Message Broker (wie NATS oder Kafka) bereitstellen, die Ende-zu-Ende-verschlüsselte Metadaten und Anhänge sicher transportieren.
• Zertifikatsmanagement: Da Behördenkommunikation hochgradig abgesichert sein muss, automatisiert die Plattform das Zertifikats-Handling (z. B. via cert-manager), um sicherzustellen, dass jede Verbindung zu den Kommunen TLS-verschlüsselt und authentifiziert ist.

3. Skalierung durch “Einer-für-Millionen”

Wenn ein bundesweit relevanter Dienst (z. B. eine Energiepreispauschale) gelauncht wird, muss die Infrastruktur innerhalb von Sekunden von Null auf Millionen Nutzer skalieren können.

• Technik: Durch den Einsatz von Horizontal Pod Autoscalern (HPA) und dem Cloud-Native-Paradigma können Rechenressourcen dynamisch zugewiesen werden. Die Plattform erkennt Lastspitzen an den Ingress-Controllern und fährt die notwendige Anzahl an Applikations-Instanzen hoch, bevor es zu Timeouts kommt.

DevOps in der Verwaltung: GitOps als Compliance-Anker

Im öffentlichen Sektor ist jede Änderung dokumentationspflichtig. Hier bietet der GitOps-Ansatz (z. B. mit ArgoCD oder Flux) einen unschätzbaren Vorteil: Die gesamte Konfiguration der Verwaltungs-Infrastruktur liegt versioniert in einem Git-Repository.

• Audit-Sicherheit: Jede Änderung am System ist nachvollziehbar (Wer hat wann welche Firewall-Regel geändert?).
• Disaster Recovery: Sollte eine Umgebung ausfallen, kann sie innerhalb von Minuten exakt so wieder aufgebaut werden, wie sie dokumentiert war – “Infrastructure as Code” macht den Staat resilient.

FAQ: Die Technik hinter OZG & EfA

Was ist der Unterschied zwischen einer “normalen” Cloud und einer OZG-Cloud? Eine OZG-Cloud muss zusätzlich zu den technischen Standards die Anforderungen des BSI-Grundschutzes und der Geheimschutzordnung erfüllen. Zudem ist die Anbindung an das “Verwaltungsnetz” (NdB - Netze des Bundes) eine spezifische technische Voraussetzung, um interne Fachverfahren sicher zu erreichen.

Warum nutzt man für EfA-Dienste Container (Docker/Kubernetes)? Container garantieren, dass eine Software in der Entwicklungsumgebung exakt so läuft wie später im Rechenzentrum des Dienstleisters. Das verhindert das “Bei mir hat es aber funktioniert”-Problem bei der Übergabe von Software zwischen verschiedenen Behörden oder IT-Dienstleistern.

Wie wird der Datenschutz bei EfA-Diensten technisch garantiert? Durch eine Kombination aus technischer Isolation (Namespaces, Micro-Segmentation) und organisatorischer Trennung. Zudem kommen oft Technologien wie “Confidential Computing” zum Einsatz, bei denen Daten sogar während der Verarbeitung im Arbeitsspeicher verschlüsselt bleiben.

Wie binden Kommunen ihre lokalen Fachverfahren an die EfA-Plattform an? Meist über sichere VPN-Tunnel oder dedizierte Leitungen zum Verwaltungsnetz. Die Kommunikation erfolgt über standardisierte APIs (wie XÖV-Standards), die sicherstellen, dass die Datenformate zwischen dem zentralen Online-Dienst und der lokalen Datenbank kompatibel sind.

Kann man EfA-Dienste auch bei US-Cloud-Anbietern hosten? Dies ist rechtlich umstritten (Stichwort: Schrems II). Die technische Strategie tendiert daher stark zu souveränen Plattformen unter deutscher Jurisdiktion oder privaten Clouds der öffentlichen IT-Dienstleister (wie Dataport, Komm.ONE oder IT.NRW), um die volle Souveränität über Bürgerdaten zu behalten.