Feedback für die Seite /aufbau/

Feedback:
Die lose aufgezählten Schichten, Technologien und Anwendungen bilden keinen Stack, hierzu muss eine Sicherheitsarchitektur konzipiert werden, die die unterschiedlichen Komponenten berücksichtigt und diese sicher miteinander verknüpft.

Um möglichst effizient Skaleneffekte zu erzeugen und zu nutzen, sollten in einem ersten Schritt Schichten wie Anschluss Gebäude Transport Verteilung übergangen werden. Diese sind zu heterogen und kleinteilig strukturiert und organisiert, Veränderungen wären hier langwierig und aufwändig. Ebenso die Plattform- und Anwendungsschichten zunächst ausgelassen werden, solange die Themen Identity (ePerso-Signaturen), Payment-API, Daten-Ontologie, Basis-API und Betriebsparameter (Logging, Monitoring, Automation, SDLC) nicht gelöst sind.

Stattdessen sollte eine offene und freie Betriebssystems- und Containerbasierte Laufzeitumgebung, auf der auch virtuelle Maschinen mit proprietären Betriebsystemen (Windows) und Fachanwendungen betrieben werden können. Eine solche Umgebung kann aus meiner Sicht ein erster Schritt für langfristige Migrationsschritte sein und muss die bisherigen, oft VM-basierte Umgebungen aufnehmen können. Zur Verbreitung der Umgebung sollte ein dezentrales Betriebsmodell gewählt werden, damit beispielsweise die RegMo-SAKs oder die Security-Scan-Infrastruktur nach § 5 BSIG in den unterschiedlichen Behörden des Bundes betrieben werden kann.

Identity: Der Bund sollte sichere Identity-Services bereitstellen, etwa VPN mit ePerso, Authentifizierung an Reverse-Proxy mittels ePerso und einem Managementinterface für die Benutzerverwaltung sowie eine sichere PKI auf Basis von Hardware-Token für die öffentliche Verwaltung (Abwicklung und Ersatz der unsicheren Verwaltungs-PKI).

Als Basisdienste sollten Offline-Signaturfunktionen für natürliche und juristische Personen kostenfrei zur Verfügung stehen, um Netzwerkeffekte zu erzeugen und den Datenfluss per Zero Trust absichern zu können. Die Integrität und Vertraulichkeit verschlüsselter und signierter Daten können auf dem Transportweg (Loadbalancer, Webserver, TLS-Terminatoren, WAF, Firewalls, etc) nicht beeinträchtigt werden und für die internet-facing Komponenten ist ein Breach nicht mehr so kritisch wie aktuell. In der aktuellen OZG-Architektur besteht eine End-to-End Verifiability von Daten, sondern öffentliche Stellen sind zu transitiven Vertrauensketten gezwungen, kurz: Wird die IT-Sicherheit einer öffentlichen Stelle beeinträchtigt, könnte dies Folgen für tausende andere haben. Daher sollte in der DStack-Architektur der Datenaustausch zwingend mit qualifizierten elektronischen Signaturen gestaltet werden.

Für einen Payment-Service sollte das KISS-Prinzip angewendet werden (keep it simple stupid). Eine zentrale API reicht bei Paypal für den gesamten Planeten, Projekte wie XBezahldienste und die Parametrisierung sollte man streichen. Ein Bezahldienst zeichnet sich dadurch aus, dass ihm mitgeteilt wird, welche Summe zu bezahlen ist, einen Referenzcode und eine Zahlungsziel für die Behörde. Wenn das Geld über unterschiedliche, angebotene Zahlungsmethoden bezahlt wurde, reicht eine Rückmeldung an die Behörde, dass das Geld eingegangen ist. Weitere Parameter benötigen die Behörden nicht.

Datenontologie: Mit einer strukturierten Graph-Datenbasis mit einer Beschreibung von Datenfeldern wird der Grundstein für die Konzeption von Formularen und Fachanwendungen gelegt. Erst mit dem Zugriff auf eine einheitliche Definition können Felder referenziert und so wiedergefunden werden (SDG, RegMo, OnceOnly, LinkedData). Es macht wenig Sinn, ohne eine entsprechende Definitionsbasis weitere Antragsformulare oder Register zu konzipieren. Nicht zuletzt bietet die maschinenlesbare Verlinkung (Datenqualität) auch die Basis für zahlreiche Möglichkeiten von KI.

Betriebsumgebung: Um Betriebsumgebungen und Anwendungen für die öffentliche Hand zu entwickeln und zu designen, sollte es öffentlich zugängliche und freie Definitionen von Referenzimplementierungen geben, um auch Integrationstests von Anwendungen durchführen zu können. Man sollte hier die Developer Experience aktiv gestalten. Referenzimplementierungen, die offen verfügbar sind und als technische Basis in verbindlichen Beschaffungsklauseln in EVB-IT verankert werden, sind die Voraussetzung für die Abnahme standardkonformer und hochwertiger Komponenten.

Die Governance sollte zunächst ausschließlich im Bund bleiben, mit einem Konsortium aus BMDS, BSI und ITZBund. Es sollte eine Politikverflechtungsfalle vermieden werden und ausufernde Gremienarbeit mit den Ländern vermieden werden. Auf keinen Fall sollten Komponenten an Länder oder deren IT-Dienstleister delegiert werden.