JBoss EAP 7 Configuration Drift: Compliance-Risiko unter NIS2

Configuration Drift bei JBoss EAP 7 ist kein Betriebsproblem, das sich intern regeln lässt. Unter NIS2 Artikel 21 und BSI-Grundschutz APP.3.3 ist ein undokumentierter Konfigurationszustand ein messbares rechtliches Risiko. Wer 2026 noch mit manuell gepflegten standalone.xml-Dateien zwischen Umgebungen arbeitet, hat keine belastbare Grundlage für ein Audit.

Was Configuration Drift technisch bedeutet

Drift entsteht, wenn der Ist-Zustand einer JBoss-Instanz vom dokumentierten Sollzustand abweicht - und diese Abweichung nicht erkannt oder kontrolliert wird.

In JBoss EAP 7 passiert das an mehreren Stellen gleichzeitig. Die standalone.xml oder domain.xml wird in Production direkt angepasst, weil ein Incident-Fix schnell sein musste. Security-Realm-Konfigurationen in der security-domains-Sektion weichen zwischen Staging und Production ab, weil jemand in Staging einen neuen Authentifizierungsprovider getestet hat, der nie sauber zurückgebaut wurde. Datasource-Verbindungsparameter - Verbindungspool-Größen, Timeout-Werte, Validierungsintervalle - unterscheiden sich zwischen Umgebungen, weil sie initial per JBoss-CLI gesetzt wurden, aber nie in die versionierte Konfiguration eingeflossen sind.

Drei typische Drift-Szenarien in JBoss EAP 7:

Security Realm Divergenz: Die ApplicationRealm-Konfiguration in Production nutzt LDAP-Integration, Staging läuft noch auf Properties-Files. Security-Tests gegen Staging sind damit nutzlos.
Subsystem-Konfigurationsabweichungen: Das undertow-Subsystem in Production hat abweichende Buffer-Größen und HTTP/2-Settings gegenüber der versionierten Baseline - angepasst während eines Performance-Incidents, nie dokumentiert.
Datasource-Parameterabweichungen: max-pool-size, blocking-timeout-wait-millis und exception-sorter-class-name wurden per jboss-cli.sh im laufenden Betrieb gesetzt. Die standalone.xml zeigt noch die alten Werte.

Laut einer Analyse von Red Hat aus 2024 haben mehr als 60 Prozent der JBoss-EAP-Installationen in Enterprise-Umgebungen relevante Konfigurationsabweichungen zwischen Umgebungen, die nicht dokumentiert sind.

Warum NIS2 Artikel 21 das zum Compliance-Problem macht

NIS2 Artikel 21 Absatz 2 fordert explizit “Maßnahmen zum Schutz von Netzwerk- und Informationssystemen”, einschließlich “Sicherheitskonzepten in Bezug auf den Netzbetrieb” und “Kontrollen bezüglich der Vergabe des Zugangs”. Das klingt abstrakt, hat aber konkrete Konsequenzen für JBoss-Betreiber.

Wenn eine Security-Realm-Konfiguration in Production von der dokumentierten Baseline abweicht, ist keine der folgenden Aussagen mehr belastbar:

“Wir betreiben Zugriffskontrolle nach definiertem Standard.”
“Unsere Authentifizierungsinfrastruktur entspricht den dokumentierten Anforderungen.”
“Änderungen an sicherheitsrelevanten Systemkomponenten sind nachvollziehbar.”

NIS2 sieht Bußgelder von bis zu zehn Millionen Euro oder zwei Prozent des globalen Jahresumsatzes vor - je nachdem, was höher ist. Für KRITIS-Betreiber, die auch unter BSIG fallen, können Betriebsuntersagungen hinzukommen.

Der entscheidende Punkt: Es muss kein Sicherheitsvorfall eintreten. Der undokumentierte Konfigurationszustand selbst ist bereits die Pflichtverletzung.

BSI-Grundschutz APP.3.3 und was er konkret verlangt

BSI-Grundschutz APP.3.3 “Relationale Datenbanksysteme” greift nicht direkt auf Applikationsserver, aber OPS.1.1.3 “Patch- und Änderungsmanagement” und CON.8 “Software-Entwicklung” sind in regulierten Umgebungen relevant. Wichtiger ist APP.3.2 “Webserver”, das für über JBoss exponierte Services gilt.

Konkret verlangt das BSI-Grundschutz-Kompendium (Edition 2023):

Dokumentierter Sollzustand für alle produktiven Systemkonfigurationen (OPS.1.1.3.A5)
Nachvollziehbarkeit von Konfigurationsänderungen mit Zeitstempel und Verantwortlichem (OPS.1.1.3.A7)
Regelmäßige Soll-Ist-Vergleiche für sicherheitsrelevante Konfigurationsparameter (OPS.1.1.3.A13)

Ein JBoss-EAP-7-System, das mit manuellen CLI-Anpassungen ohne Rückfluss in versionierte Konfigurationsdateien betrieben wird, erfüllt OPS.1.1.3.A5 strukturell nicht.

Drift erkennen: Konkrete Methoden

Drift-Erkennung in JBoss-Umgebungen braucht einen definierten Sollzustand als Referenz. Ohne Baseline ist jeder Vergleich sinnlos.

Methode 1 - Konfigurations-Snapshot-Vergleich: JBoss EAP 7 bietet den CLI-Befehl attachment display --operation=/core-service=management:read-config-as-xml, der die aktuelle Konfiguration als XML ausgibt. Dieser Output kann gegen das versionierte Konfigurationsfile differenziert werden. Automatisiert mit xmldiff oder Python-basierten Tools.

Methode 2 - Ansible-basierter Drift-Check: Ein Ansible-Playbook kann JBoss-Konfigurationsparameter direkt über den Management-API-Endpunkt (http://host:9990/management) abfragen und gegen ein Soll-Inventar in YAML prüfen. Bei Abweichungen kann es einen Alarm auslösen, ohne selbst in die Konfiguration einzugreifen.

Methode 3 - File-Integrity-Monitoring: Tools wie AIDE oder Tripwire auf dem Filesystem-Level, kombiniert mit einem JBoss-spezifischen Profil für $JBOSS_HOME/standalone/configuration/. Änderungen an standalone.xml, application-roles.properties oder application-users.properties werden so innerhalb von Minuten erkannt.

Methode 4 - CI/CD-Pipeline-Gate: Jede JBoss-Konfigurationsänderung muss durch einen Pull-Request-Prozess mit automatisiertem Diff gegen die Baseline. Direktzugriff auf die Konfigurationsdateien in Production wird technisch unterbunden.

Remediation: Wie man aus dem Drift-Zustand herauskommt

Der erste Schritt ist eine vollständige Bestandsaufnahme. Für jede JBoss-Instanz wird ein aktueller Snapshot der standalone.xml (oder domain.xml) erstellt und in ein Git-Repository eingecheckt. Das ist der neue Ausgangspunkt - nicht ein theoretisches Sollzustand-Dokument, sondern der tatsächliche Ist-Zustand.

Dann beginnt die Konsolidierung. Abweichungen zwischen Umgebungen werden klassifiziert: legitime Unterschiede (Production hat andere Datasource-URLs als Staging) versus undokumentierte Abweichungen (Production hat andere Security-Realm-Konfiguration ohne dokumentierten Grund). Letztere werden entweder bereinigt oder formal als Ausnahme mit Genehmigung dokumentiert.

Für laufende Systeme in regulierten Umgebungen ist der realistische Zeitplan:

Bestandsaufnahme und Baseline: zwei bis vier Wochen
Klassifizierung und Bereinigung kritischer Abweichungen: vier bis acht Wochen
Einführung automatisierter Drift-Erkennung: zwei bis sechs Wochen parallel

Gesamtaufwand: drei bis vier Monate für eine mittlere JBoss-Installation mit fünf bis zwanzig Instanzen.

Wie viele JBoss-Instanzen betreibt Ihr Team, und welche davon haben einen dokumentierten Sollzustand? Falls diese Frage intern schwer zu beantworten ist, lohnt ein Blick auf SPAS (Secure Platform Automation Suite), das Configuration Drift-Erkennung und Remediation für JBoss-EAP-Umgebungen automatisiert.

Konkrete Drift-Szenarien aus der Praxis

Drei reale Muster, die in regulierten JBoss-Umgebungen regelmäßig auftauchen:

Szenario A - Der Notfall-Patch: Ein kritischer Fehler erfordert um 23:00 Uhr eine Konfigurationsänderung direkt in Production. Die standalone.xml wird angepasst, der Dienst läuft wieder. Aber die Änderung findet den Weg zurück ins Repository nie - weil das Ticket als “erledigt” geschlossen wurde. Vier Monate später kann niemand mehr erklären, warum Production sich von der Baseline unterscheidet.

Szenario B - Die Umgebungsanpassung: Staging bekommt für Lasttests neue Connection-Pool-Parameter. Der Test wird abgeschlossen, aber die Parameter werden nicht zurückgesetzt - weil “es ja gut lief”. Security-Tests in Staging simulieren nun andere Lastbedingungen als Production.

Szenario C - Die vererbte Konfiguration: Eine neue JBoss-Instanz wird als Kopie einer bestehenden aufgesetzt. Die Ausgangsinstanz hatte aber selbst undokumentierte Änderungen. Drift wird kopiert und multipliziert.

Alle drei Szenarien sind mit einem versionierten Konfigurationsmanagement und automatischer Drift-Erkennung vermeidbar. Die technischen Mittel existieren. Die Lücke ist organisatorischer Natur.

Mehr über den übergeordneten Ansatz auditierbar betriebener IT-Plattformen in regulierten Umgebungen unter Warum auditierbare IT-Plattformen wichtig sind.

FAQ

Ist Configuration Drift bei JBoss EAP 7 strafbar?

Nicht direkt - aber unter NIS2 Artikel 21 kann ein undokumentierter Konfigurationszustand eine Pflichtverletzung darstellen, die zu Bußgeldern bis zehn Millionen Euro führt. Der Vorfall selbst muss nicht eintreten.

Wie erkenne ich, ob meine JBoss-Instanzen Drift haben?

Vergleich der laufenden Konfiguration (read-config-as-xml via JBoss CLI) mit der versionierten standalone.xml. Wenn diese Files abweichen oder kein versioniertes Referenzdokument existiert, liegt Drift vor.

Was ist der Unterschied zwischen Drift und geplanter Umgebungsdifferenzierung?

Geplante Unterschiede (z.B. andere Datasource-URLs in Production) sind legitim und müssen dokumentiert sein. Drift entsteht, wenn Abweichungen existieren, die nicht dokumentiert, nicht genehmigt und nicht nachvollziehbar sind.

Welche JBoss-Konfigurationsparameter sind NIS2-relevant?

Security Realms, Authentifizierungs- und Autorisierungskonfigurationen, TLS/SSL-Settings, Audit-Logging-Konfiguration im undertow-Subsystem und alle Firewall- oder Netzwerkbindungs-Parameter.

Wie lange dauert es, aus einem Drift-Zustand herauszukommen?

Für fünf bis zwanzig JBoss-Instanzen realistisch drei bis vier Monate: zwei bis vier Wochen Bestandsaufnahme, vier bis acht Wochen Bereinigung, zwei bis sechs Wochen Einführung automatisierter Kontrollen.

Verwandte Artikel: