Technische Klarheit
für regulierte IT.

Warum dieser Blog

lennlay arbeitet in einem Bereich, in dem viel Erfahrungswissen existiert, aber wenig davon aufgeschrieben ist. Middleware-Migration, Compliance-Automatisierung, Plattform-Engineering in regulierten Umgebungen: die Probleme sind bekannt, die Lösungsansätze weniger.

Wir starten diesen Blog, um das zu ändern. Nicht als Marketing-Kanal, sondern als technisches Arbeitsjournal.

Was hier erscheint

• Middleware-Migration: JBoss EAP 7 zu EAP 8, Tomcat-Versionssprünge, Apache-HTTPD-Konfigurationen in CI/CD-Umgebungen. Was funktioniert, was nicht, was man vorher wissen sollte.
• Compliance-Automatisierung: CIS-Benchmark-Umsetzung mit Ansible, Drift-Detection, Audit-Reporting. Konkrete Techniken, keine abstrakten Frameworks.
• Plattform-Engineering: Wie regulierte Organisationen Plattformen bauen, die Governance integrieren, ohne Engineering zu bremsen.
• SPAS-Updates: Changelogs und technische Erläuterungen zu neuen Features.

Wer schreibt

Die Inhalte kommen aus der Projektarbeit von lennlay. Wir schreiben über Probleme, die wir selbst gelöst haben, und Entscheidungen, die wir begründen können. Keine synthetischen Best-Practice-Listen.

Intervall und Format

Kein fester Veröffentlichungsrhythmus. Wir schreiben, wenn es etwas Konkretes zu sagen gibt. Beiträge sind entweder kurze Changelogs wie dieser oder längere technische Artikel mit Kontext und Begründung.

Wer nichts verpassen will: RSS-Feed ist verfügbar.

SPAS 2.0 ist verfügbar

Mit Version 2.0 liefert SPAS zwei zentrale Erweiterungen: automatisiertes Audit-Reporting und eine vollständige Golden-Image-Pipeline. Beide Features adressieren direkt die Anforderungen regulierter Umgebungen, in denen manuelle Nachweiserstellung und unkontrollierte Baselines operative Risiken erzeugen.

Was neu ist

Automatisiertes Audit-Reporting

• Compliance-Berichte werden am Ende jedes Playbook-Laufs automatisch erzeugt.
• Ausgabeformate: PDF (prüffertig, mit Zeitstempel und Host-Referenz) und JSON (für SIEM-Integration oder Weiterverarbeitung).
• Berichte umfassen: CIS-Benchmark-Ergebnisse je Control, Abweichungsliste, Remediationsstatus und ausführende Ansible-Version.
• Keine nachträgliche manuelle Zusammenstellung. Der Nachweis entsteht direkt aus dem Ausführungslauf.

Golden-Image-Pipeline für JBoss EAP 8 und Tomcat 10

• Neue Pipeline-Definition für reproduzierbare, gehärtete Basis-Images.
• Unterstützte Ziele: JBoss EAP 8.0, Tomcat 10.1.
• Jedes Image durchläuft automatisch CIS-Level-2-Hardening, Konfigurationsvalidierung und Signaturschritt.
• Das fertige Image wird als versioniertes Artefakt in der Registry abgelegt. Jeder Deployment-Lauf ist damit auf einen bekannten, geprüften Stand zurückführbar.
• Drift-Erkennung (ab SPAS 1.5) nutzt diesen Stand als Referenz.

GitLab CI Integration

• SPAS-Playbooks lassen sich direkt in GitLab-CI-Pipelines einbinden.
• Vorgefertigte .gitlab-ci.yml-Templates für die häufigsten Szenarien: Hardening-Check beim Merge Request, Golden-Image-Build bei Tag, Audit-Report als Pipeline-Artefakt.
• Keine separate Trigger-Logik nötig. Die Templates funktionieren mit Standard-GitLab-Runner-Konfigurationen.

Geänderte Voraussetzungen

• Red Hat Ansible Automation Platform 2.4 oder neuer.
• Für PDF-Reports: wkhtmltopdf muss auf dem Execution Node verfügbar sein.
• GitLab 16.x oder neuer für die CI-Templates (CI/CD-Catalog-kompatibel).

Upgrade-Hinweise

SPAS 2.0 ist kompatibel mit bestehenden 1.x-Inventaren und -Variablen. Einzelne Variablennamen im Reporting-Modul wurden umbenannt. Die Migrationsnotiz ist im Repository unter CHANGELOG.md dokumentiert.

Für Umgebungen, die SPAS 1.5 mit aktivierter Drift-Detection betreiben, empfehlen wir, vor dem Upgrade einen manuellen Baseline-Snapshot zu erstellen, da das neue Golden-Image-Format die Referenzstruktur erweitert.

Nächste Schritte

Dokumentation und Beispiel-Pipelines sind im SPAS-Repository verfügbar. Bei Fragen zur Integration in bestehende Red-Hat-AAP-Installationen: kontakt@lennlay.de

Ansible Collection für JBoss EAP Hardening verfügbar

lennlay veröffentlicht eine Ansible Collection, die CIS-Benchmark-konformes Hardening für JBoss EAP als wiederverwendbare Rollen bereitstellt. Die Collection ist auf Ansible Galaxy verfügbar und direkt in bestehende AAP-Setups integrierbar.

Was die Collection enthält

Unterstützte Plattformen

• JBoss EAP 7.4 (inkl. Extended Lifecycle Support)
• JBoss EAP 8.0

Benchmark-Abdeckung

• CIS Red Hat JBoss EAP Benchmark, Level 1 und Level 2
• Controls werden pro Rolle einzeln aktivierbar. Kein Zwang zur Vollabdeckung beim ersten Einsatz.

Enthaltene Rollen

• jboss_eap_hardening_base: Grundkonfiguration, SSL/TLS-Einstellungen, Management-Interface-Absicherung
• jboss_eap_hardening_logging: Audit-Log-Aktivierung, Log-Format, Log-Rotation
• jboss_eap_hardening_access: Rollenbasierter Zugriff, Management-User-Konfiguration, Remote-Access-Einschränkungen
• jboss_eap_hardening_network: Bind-Adressen, Interface-Konfiguration, AJP-Deaktivierung
• jboss_eap_compliance_check: Standalone-Rolle zur Prüfung ohne Remediierung. Liefert strukturierten JSON-Report.

Variablen und Defaults

Alle sicherheitsrelevanten Defaults folgen CIS Level 2. Abweichungen sind über host_vars und group_vars steuerbar. Die Collection enthält keine hartcodierten Passwörter oder Environment-spezifischen Werte.

Voraussetzungen

• Ansible Core 2.15 oder neuer
• Zugriff auf JBoss-EAP-Installationspfad mit Schreibrechten
• Management-CLI muss erreichbar sein (lokal oder remote)

Integration in SPAS

Die Collection ist Grundlage der JBoss-EAP-Rollen in SPAS. Wer SPAS einsetzt, bekommt die Collection als abhängige Komponente automatisch mitgeliefert. Die eigenständige Veröffentlichung auf Ansible Galaxy ermöglicht den Einsatz auch ohne die vollständige SPAS-Plattform.

Installation

ansible-galaxy collection install lennlay.jboss_eap_hardening

Dokumentation und Beispiel-Playbooks sind im zugehörigen Repository verfügbar.

SPAS 1.5 ist verfügbar

Version 1.5 führt Drift-Detection als eigenständiges Modul ein. Ziel ist es, unautorisierte oder ungeplante Konfigurationsänderungen in regulierten Umgebungen frühzeitig zu erkennen, bevor sie zum Compliance-Problem oder zur Ursache eines Vorfalls werden.

Was neu ist

Automatisierter Konfigurationsvergleich

• SPAS vergleicht den tatsächlichen Laufzeitstand eines Hosts mit dem definierten Golden State.
• Verglichen werden: JBoss-EAP-Konfiguration (standalone.xml / domain.xml), Tomcat-Konfiguration (server.xml, context.xml), Apache-HTTPD-Einstellungen (vhosts, SSL-Parameter, Module) und ausgewählte Betriebssystem-Controls.
• Abweichungen werden zeilengenau protokolliert. Das Ergebnis liegt als strukturiertes JSON vor und ist maschinenlesbar.

Alert bei unautorisierten Änderungen

• Abweichungen vom Golden State lösen konfigurierbare Alerts aus.
• Unterstützte Ziele: E-Mail, Webhook (Slack, Teams, generisch), AAP-Notification-Integration.
• Alert-Schwellwerte sind je Control-Typ einstellbar: informativ, Warning, Critical.
• Wer nur bestimmte Controls überwachen will, kann über Tags filtern.

Geplante Scans

• Drift-Scans lassen sich als wiederkehrender Job in Red Hat AAP einplanen.
• Empfohlene Basisfrequenz: täglich. Kritische Umgebungen können stündliche Scans konfigurieren.
• Scan-Ergebnisse werden historisiert und sind über die AAP-UI abrufbar.

Baseline-Management

• Der Golden State wird als versionierte Datei im Repository gehalten.
• Geplante Konfigurationsänderungen werden als neue Baseline committed, bevor sie ausgerollt werden. Damit bleibt der Drift-Vergleich konsistent mit dem tatsächlichen Sollzustand.
• SPAS 2.0 baut auf dieser Baseline die Golden-Image-Pipeline auf.

Warum das in regulierten Umgebungen relevant ist

Viele Compliance-Frameworks (BSI IT-Grundschutz, ISO 27001, SOC 2) verlangen den Nachweis, dass Systeme im definierten, geprüften Zustand betrieben werden. Ohne automatisierten Abgleich lässt sich das nur durch manuelle Kontrollen belegen, die personal- und zeitintensiv sind und Prüflücken erzeugen.

Drift-Detection macht diesen Nachweis reproduzierbar und kontinuierlich, ohne zusätzlichen manuellen Aufwand.

Voraussetzungen

• SPAS 1.4 oder neuer als Basis
• Red Hat Ansible Automation Platform 2.3 oder neuer
• Definierter Golden State im SPAS-Repository (Ansible-Variablen oder separates Baseline-File)

Upgrade

Das Modul wird als neue Rolle (spas_drift_detection) in die bestehende Collection eingespielt. Bestehende Inventare und Variablen bleiben kompatibel. Konfiguration der Alert-Targets erfolgt über neue group_vars-Definitionen, die in der Dokumentation beschrieben sind.

Drei Jahre, ein Gründer

Die ersten drei Jahre von lennlay waren Einzelarbeit. Marcel König hatte lennlay 2020 gegründet, um Plattformautomatisierung für regulierte Organisationen als Produkt zu bauen, nicht als Beratungsleistung. Das funktionierte. SPAS nahm Form an, erste Kundenprojekte liefen, die Positionierung bewährte sich in der Praxis.

Aber ein Einzelpersonbetrieb hat eine strukturelle Grenze, die keine Effizienz überwindet: Ein Projekt kann nicht zwei vollständige parallele Engagements tragen. SPAS-Entwicklung und Kundenprojekt gleichzeitig bedeutete, eines von beiden litt. Der Codebase wuchs, aber der Test in unterschiedlichen Produktionsumgebungen fehlte. Und die Zertifizierungsinitiative, die König für sinnvoll hielt, war alleine schlicht nicht finanzierbar.

2023 änderte sich das.

Benjamin Strebel: Linux und Ansible als Kernkompetenz

Benjamin Strebel brachte etwas mit, das in der Arbeit von lennlay direkt anschlussfähig war: tiefe Linux-Systemkenntnis kombiniert mit Ansible-Erfahrung aus produktiven Enterprise-Umgebungen.

Wer Ansible-Rollen für regulierte Produktionsumgebungen schreibt, operiert auf zwei Ebenen gleichzeitig. Die Automatisierungslogik muss stimmen. Aber die Systeme, gegen die sie läuft, müssen verstanden sein - ihr Verhalten unter Last, ihre Eigenheiten bei Konfigurationsänderungen, die Stellen, an denen ein Playbook in der Entwicklungsumgebung funktioniert und in Produktion nicht. Dieses Systemverständnis ist nicht lehrbar ohne echte Betriebserfahrung.

Wolf hatte diese Erfahrung. Sein Fokus auf Linux-Systemhärtung ergänzte den SPAS-Kern direkt. JBoss-Hardening-Rollen setzen auf einem Betriebssystem auf, das selbst konfiguriert, gehärtet und auditierbar sein muss. Die Qualität dieser Basis bestimmt, was darüber möglich ist.

Matthias Siegl: Middleware-Tiefe aus der Praxis

Matthias Siegl kam mit dem Hintergrund, der lennlay ursprünglich definierte: JBoss und Middleware in regulierten Produktionsumgebungen.

JBoss EAP ist kein System, das man aus der Dokumentation heraus versteht. Die Komplexität liegt in dem, was die Dokumentation nicht beschreibt: Classloading-Konflikte unter Last, Deployment-Verhalten in Cluster-Konfigurationen, Interaktion zwischen HTTPD-Proxy und EAP bei spezifischen TLS-Versionen, Legacy-Konfigurationen, die über Jahre gewachsen sind und bei Upgrades unerwartet reagieren. Steiner hatte diese Szenarien in Kundenprojekten durchgearbeitet.

Für SPAS bedeutete das: Ein zweiter Spezialist, der JBoss-Härtungsregeln nicht nur ausführen, sondern bewerten kann. Wenn ein CIS-Benchmark-Control in einer bestimmten EAP-Konfiguration nicht direkt umsetzbar ist, weil er mit einer Applikationsanforderung kollidiert, braucht es jemanden, der die Konsequenz versteht und eine technisch begründete Ausnahme definieren kann. Das ist keine Automatisierungsaufgabe. Das ist Fachwissen.

Was sich operativ änderte

Die direkteste Konsequenz: Zwei Kundenprojekte konnten parallel laufen, ohne dass eines davon degradiert wurde. König konnte Engagements übernehmen, während Wolf oder Steiner ein anderes Projekt führten. Jede Person im Team war von Anfang an in der Lage, ein Kundenprojekt eigenständig zu leiten. Das war kein Zufall - es war das Einstellungsprinzip.

lennlay stellt keine Unterstützungspositionen ein. Wer ins Team kommt, muss in der Lage sein, einem Kunden in einer regulierten Produktionsumgebung eigenständig gegenüberzutreten. Technische Entscheidungen treffen, Fragen beantworten, Probleme eskalieren wenn nötig, ohne den Eindruck zu erwecken, dass eine übergeordnete Person nachgeprüft werden muss. Das setzt ein Niveau voraus, das sich nicht durch Onboarding herstellen lässt. Es muss mitgebracht werden.

Die Zertifizierungsinitiative

Mit einem dreiköpfigen Team wurde das möglich, was für eine einzelne Person zu aufwändig gewesen wäre: eine strukturierte Zertifizierungsoffensive. RHCSA, RHCE, Red Hat Specialist in Containers - alle drei Zertifizierungen für alle drei Ingenieure.

Das hatte einen praktischen Hintergrund. lennlay arbeitet mit Kunden aus KRITIS, Finanzdienstleistung, Gesundheitswesen. In diesen Umgebungen werden Dienstleister auf ihre Kompetenznachweise hin geprüft. Red Hat Zertifizierungen sind in diesem Kontext keine Dekoration. Sie belegen, dass eine Person unter realen Bedingungen ohne externe Hilfe handlungsfähig ist - genau das, was in einer kritischen Infrastruktur gefordert wird.

Lennlay trug die Zertifizierungskosten für das gesamte Team und räumte Lernzeit ein. Das war eine Investition, die sich in der Kundenwahrnehmung direkt niederschlug.

SPAS-Entwicklung unter realen Bedingungen

Das zweite operative Ergebnis war weniger sichtbar, aber substanziell: SPAS wurde unter breiteren Bedingungen getestet.

Ein Ansible-Playbook, das in einer Umgebung funktioniert, hat noch nichts bewiesen. Die eigentliche Aussage kommt aus dem zweiten und dritten Einsatz - in Umgebungen mit anderen Konfigurationen, anderen Versionsständen, anderen Ausnahmen. Mit Wolf und Steiner im Team liefen SPAS-Rollen in mehr Produktionskontexten, und die Fehler, die dabei auftraten, flossen direkt in die Collection zurück.

Bis Ende 2023 war SPAS nicht mehr das Produkt eines einzelnen Ingenieurs, der seinen eigenen Annahmen vertraute. Es war ein Produkt, das gegen die unterschiedlichen Praxiskontexte dreier Spezialisten entwickelt worden war.

Stand 2023

Mit Benjamin Strebel und Matthias Siegl war lennlay ein Team. Drei Personen, drei vollständige Zertifizierungssätze, parallele Projektkapazität, ein weiterentwickeltes Produkt. Die Richtung blieb dieselbe: Plattformautomatisierung für regulierte Umgebungen, tief statt breit, mit persönlicher Verantwortung in jedem Engagement.

Was 2020 als Idee einer einzelnen Person begann, hatte jetzt die operative Grundlage, um über Einzelprojekte hinaus zu wachsen.

Der Ausgangspunkt

Marcel König arbeitete im September 2020 seit über 20 Jahren in der IT. Angestellt bei Siegele Software, dann als Freiberufler in Projekten bei VW Financial Services, KfW, Baloise, Deutsche Post. Middleware-Migration, Plattform-Implementierung, JBoss-Betrieb in Umgebungen, die keine Fehler tolerieren. Irgendwann war die Erkenntnis nicht mehr wegzudiskutieren: Dieselben Probleme tauchen immer wieder auf, in jeder Organisation neu, jedes Mal ohne Gedächtnis an die vorige Lösung.

Compliance-Prüfungen, die manuell vorbereitet werden. Hardening-Konfigurationen, die einmal erstellt und nie wieder systematisch geprüft werden. Konfigurationsabweichungen, die im Betrieb entstehen und erst beim Audit sichtbar werden. Know-how, das Einzelpersonen gehört und mit ihnen die Organisation verlässt.

lennlay war die Antwort auf diese Beobachtung.

Warum 2020

Gründungen passieren selten zu einem perfekten Zeitpunkt. Bei lennlay war es eine Kombination aus technischer Reife und persönlicher Klarheit. Ansible hatte sich als Standard für Infrastrukturautomatisierung in Enterprise-Umgebungen durchgesetzt. Red Hat Ansible Automation Platform bot eine Grundlage, auf der auditierbare, reproduzierbare Playbooks in regulierten Umgebungen betreibbar wurden. Der technische Stack war bereit.

Gleichzeitig hatte König in seinen Freelance-Jahren ein klares Bild davon entwickelt, welche Lücke existierte. Nicht das Fehlen von Beratungskapazität. Das Fehlen eines Produkts, das Compliance kontinuierlich sicherstellt - kein Bericht, kein Konzept, sondern ausführbarer Code, der jederzeit nachweist: Dieser Host ist konform. Dieser nicht. Hier ist die Abweichung.

Die Idee für SPAS - den Secure Platform Automation Service - war der Kern, um den herum lennlay entstand.

Die ersten Monate

Der Betrieb startete ohne Büro, ohne Pitch Deck, ohne externe Finanzierung. Was vorhanden war: 20 Jahre Projekterfahrung, ein klar definiertes technisches Problem und die Überzeugung, dass Ansible-basierte Automatisierung der richtige Ansatz war, um dieses Problem strukturell zu lösen.

Die ersten Monate waren technische Aufbauarbeit. König begann, die Ansible-Rollen zu entwickeln, die später den Kern von SPAS bilden würden. JBoss EAP Hardening nach CIS-Standards, reproduzierbar und idempotent. Konfigurationsmanagement, das den Iststand eines Hosts gegen einen definierten Sollstand abgleicht. Audit-Outputs, die maschinenlesbar sind und ohne manuelle Aufbereitung in Compliance-Nachweise eingehen können.

Diese Arbeit war nicht neu - König hatte ähnliche Automatisierungen in Kundenprojekten gebaut. Was neu war: Sie wurden nicht für eine einzelne Organisation gebaut und danach vergessen, sondern als wiederverwendbare, erweiterbare Produkt-Basis. Jeder Aufwand, der in diese Rollen floss, würde jedem künftigen Kunden zugutekommen.

Der erste Kundeneinsatz

Die erste echte Bewährungsprobe kam früher als geplant. Eine Kundenorganisation aus dem regulierten Bereich - der genaue Kontext bleibt intern - stand vor einem JBoss-Hardening-Projekt mit engem Zeitrahmen und strengen Audit-Anforderungen. König konnte mit bereits entwickelten Rollen in einen Stand einsteigen, den er sonst erst hätte bauen müssen.

Das war der erste Praxistest für die Produktidee. Nicht als Beratungsleistung, die einen Report produziert, sondern als technisches Produkt, das Ergebnisse liefert. Hardening-Stand vor dem Einsatz: manuell und lückenhaft dokumentiert. Hardening-Stand danach: automatisiert hergestellt, reproduzierbar, mit maschinenlesbarem Nachweis.

Der Ansatz funktionierte. Das war die Bestätigung, die zählte.

Remote-first von Anfang an

lennlay hatte nie ein Büro und hat bis heute keins. Das war keine Reaktion auf veränderte Arbeitsbedingungen, sondern von Beginn an der operative Standard.

Die Kunden, mit denen lennlay arbeitet, sitzen über den DACH-Raum verteilt. Regulierte Umgebungen bedeuten oft, dass tiefe Zusammenarbeit remote funktionieren muss - Zugänge werden kontrolliert vergeben, nicht jede Umgebung ist vor Ort zugänglich. Wer in diesem Bereich arbeitet, muss asynchrone Kommunikation und strukturierte Dokumentation nicht erst lernen. König hatte das über Jahre als Freiberufler praktiziert.

Remote-first bedeutete auch: keine fixen Gemeinkosten, die Projektentscheidungen beeinflussen. lennlay wächst, wenn das fachliche Fundament trägt - nicht wenn ein Mietvertrag Auslastung erzwingt.

Was 2020 entstand

Am Ende des ersten Jahres stand lennlay als funktionierendes Unternehmen: erste Kundenreferenz, ein wachsender Kern-Ansible-Codebase, klare Positionierung in einem definierten Markt. Kein breites Portfolio, keine vagen Kompetenzbeschreibungen. Plattformautomatisierung für regulierte Umgebungen, auf Basis von Red Hat Ansible.

Das war der Ausgangspunkt für alles, was folgte.