KRITIS und Softwarearchitektur, was kritische Infrastruktur von Software verlangt

Was ist KRITIS?

KRITIS steht für Kritische Infrastrukturen, Organisationen und Einrichtungen mit wichtiger Bedeutung für das staatliche Gemeinwesen, deren Ausfall oder Beeinträchtigung nachhaltige Versorgungsengpässe oder erhebliche Störungen der öffentlichen Sicherheit zur Folge hätte. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) reguliert diese Bereiche durch das IT-Sicherheitsgesetz und die BSI-KritisV.

Die betroffenen Sektoren umfassen Energie, Wasser, Ernährung, Informationstechnik, Telekommunikation, Gesundheit, Finanzwesen und Transport. Wer Software für diese Sektoren entwickelt, muss verstehen, dass Architekturentscheidungen hier nicht nur technische, sondern regulatorische Konsequenzen haben.

Aus der Arbeit an Systemen im Bereich Eisenbahn-Infrastruktur und später im Energiesektor hat sich ein konkretes Bild ergeben, was KRITIS in der täglichen Softwareentwicklung tatsächlich bedeutet.

Verfügbarkeit: Mehr als ein SLA

In den meisten Enterprise-Projekten ist Verfügbarkeit ein Thema für die Betriebsvereinbarung: 99.5% oder 99.9%, je nach Budget. In KRITIS-Systemen ist Verfügbarkeit eine regulatorische Pflicht. Ein Ausfall des Leitsystems einer Bahnstrecke oder eines Energienetzes hat Konsequenzen, die weit über verlorene Umsätze hinausgehen.

Für die Softwarearchitektur bedeutet das konkret:

• Keine Single Points of Failure: Jede Komponente muss redundant ausgelegt sein. Das betrifft nicht nur Datenbanken und Application Server, sondern auch Load Balancer, DNS und Monitoring-Systeme.
• Graceful Degradation: Das System muss bei Teilausfällen in einem eingeschränkten, aber funktionsfähigen Modus weiterlaufen. Ein ausgefallener Analytics-Service darf nicht das Kernsystem lahmlegen.
• Definierte Recovery-Zeiten: RTO (Recovery Time Objective) und RPO (Recovery Point Objective) müssen architektonisch unterstützt werden. Ein RPO von 15 Minuten erfordert andere Replikationsstrategien als ein RPO von 24 Stunden.

Audit Trails: Lückenlose Nachvollziehbarkeit

Jede Aktion in einem KRITIS-System muss nachvollziehbar sein, wer hat wann was getan, und warum. Das klingt trivial, hat aber tiefgreifende Auswirkungen auf die Architektur.

public class AuditEvent {
    private final Instant timestamp;
    private final String userId;
    private final String action;
    private final String resourceType;
    private final String resourceId;
    private final Map<String, Object> previousState;
    private final Map<String, Object> newState;
    private final String justification;
    private final String sourceIp;
    private final String sessionId;
}

Wichtige Anforderungen an den Audit Trail:

• Unveränderlichkeit: Audit-Einträge dürfen nicht gelöscht oder modifiziert werden. Append-only Storage ist Pflicht.
• Vollständigkeit: Nicht nur erfolgreiche Aktionen, sondern auch fehlgeschlagene Zugriffsversuche müssen protokolliert werden.
• Zeitliche Integrität: Zeitstempel müssen aus einer vertrauenswürdigen Quelle stammen, nicht vom Client.
• Separierung: Der Audit Trail muss getrennt vom operativen System gespeichert werden, damit ein Angreifer, der Zugriff auf das Hauptsystem erlangt, nicht auch die Audit-Daten manipulieren kann.

Netzwerksegmentierung: Architektur folgt Zonen

KRITIS-Systeme operieren in segmentierten Netzwerken. Die typische Zonenarchitektur umfasst:

Zone	Funktion	Zugriff
DMZ	Externe Schnittstellen, Reverse Proxies	Aus dem Internet erreichbar
Anwendungszone	Application Server, APIs	Nur aus DMZ und interner Zone
Datenzone	Datenbanken, File Storage	Nur aus Anwendungszone
Management-Zone	Monitoring, Logging, Deployment	Nur für Administratoren
OT-Zone	Steuerungssysteme (bei Energie/Transport)	Strikt isoliert

Für die Softwarearchitektur bedeutet das: Die Anwendung muss so gestaltet sein, dass Komponenten in verschiedenen Zonen deployt werden können. Ein Monolith, der Datenbankzugriff und externe API in derselben Applikation bündelt, ist in einer segmentierten Umgebung nicht betreibbar.

Microservices oder zumindest eine modulare Architektur mit klaren Netzwerkgrenzen sind hier keine Stilfrage, sondern eine betriebliche Notwendigkeit.

Access Control: Beyond RBAC

Die Berechtigungsanforderungen in KRITIS-Systemen gehen über klassisches Role-Based Access Control (RBAC) hinaus. In der Praxis sind zusätzliche Dimensionen relevant:

• Zeitbasierte Berechtigungen: Wartungszugriffe werden nur für definierte Zeitfenster freigeschaltet
• Vier-Augen-Prinzip: Kritische Aktionen erfordern die Bestätigung durch eine zweite Person
• Attribut-basierte Zugriffskontrolle (ABAC): Berechtigungen hängen nicht nur von der Rolle ab, sondern auch vom Kontext, Standort, Uhrzeit, Gerät
• Notfallzugriffe: Es muss Break-Glass-Verfahren geben, die in Notfällen erhöhte Berechtigungen gewähren und gleichzeitig lückenlos protokolliert werden

Testing und Deployment

Auch hier gelten verschärfte Anforderungen:

• Change Management: Jede Änderung am Produktionssystem muss durch einen formalen Change-Prozess gehen. Direkte Deployments sind ausgeschlossen.
• Staging-Pflicht: Änderungen müssen in einer produktionsnahen Staging-Umgebung getestet werden, bevor sie in Produktion gehen.
• Rollback-Fähigkeit: Jedes Deployment muss rückgängig gemacht werden können, ohne Datenverlust.
• Penetration Testing: Regelmäßige Sicherheitstests sind nicht optional, sondern Pflicht, und sie müssen dokumentiert werden.

Die CI/CD-Pipeline muss diese Anforderungen abbilden. Automatische Deployments in Produktion, wie sie in vielen Projekten üblich sind, sind in KRITIS-Umgebungen in der Regel nicht zulässig. Die Pipeline endet bei der Bereitstellung des Artifacts und der Dokumentation, das tatsächliche Deployment erfolgt gesteuert.

Fazit

KRITIS-Anforderungen sind kein Bürokratie-Monster, das gute Softwarearchitektur verhindert. Im Gegenteil: Sie erzwingen Architekturentscheidungen, die ohnehin Best Practice sind, Redundanz, Audit Trails, Zugriffskontrolle, Netzwerksegmentierung. Der Unterschied zum normalen Enterprise-Projekt liegt darin, dass diese Dinge nicht optional sind. Man kann sie nicht auf “später” verschieben oder als Nice-to-have abtun. Diese Verbindlichkeit führt, richtig umgesetzt, zu robusteren und besser durchdachten Systemen.