Ehrlich gesagt: Manuelles Abhaken einer 300-Zeilen-Härtungs-Checkliste ist 2026 schlicht keine Option mehr. Drei Treiber haben das Spielfeld endgültig verschoben:
- Supply-Chain-Angriffe auf Open-Source-Pakete und CI/CD-Pipelines erfordern eine kontinuierliche Validierung der Soll-Konfiguration — nicht punktuelle Stichproben einmal im Quartal.
- Cloud-native Skalierung — Hunderte ephemerer VMs, Container und Edge-Knoten lassen sich nur mit maschinenlesbaren Policies sinnvoll auditieren. Per Hand? Vergessen Sie's.
- Regulatorischer Druck durch NIS2 (seit Oktober 2024 in DE umgesetzt), DORA für Finanzdienstleister und der EU AI Act fordern reproduzierbare, dokumentierte Konfigurations-Nachweise.
Genau hier setzt der SCAP-Stack an: Security Content Automation Protocol ist ein NIST-Standard, der Härtungs-Policies in maschinenlesbarem XML beschreibt — inklusive automatischer Remediation. Klingt sperrig, ist in der Praxis aber überraschend angenehm.
Toolchain im Überblick: OpenSCAP, SSG, CIS und Ansible
Vier Komponenten greifen ineinander:
- OpenSCAP (
oscap) — der Open-Source-Scanner, der SCAP-Inhalte ausführt. Liefert XCCDF-Ergebnisse, OVAL-Schwachstellen-Scans und (sehr nützlich für Reviews) hübsche HTML-Reports.
- SCAP Security Guide (SSG) — das Paket
scap-security-guide mit fertigen Profilen für CIS, STIG, BSI-Grundschutz, ANSSI-BP-028, OSPP und mehr.
- CIS-Benchmark — der De-facto-Standard für Server-Härtung. Level 1 ist betriebssicher, Level 2 erhöht Schutz auf Kosten von Komfort.
- Ansible — agentenlose Automatisierung. Das Schöne:
oscap erzeugt aus Scan-Resultaten direkt Ansible-Playbooks zur Behebung jedes Fail-Findings.
Der entscheidende Vorteil? Sie schreiben keine Härtungs-Skripte mehr selbst. Sie konsumieren geprüfte, versionierte SCAP-Inhalte und übersetzen sie in idempotente Ansible-Tasks. Das spart nicht nur Zeit — es spart Bugs.
Voraussetzungen
- RHEL 9, AlmaLinux 9, Rocky Linux 9 oder Ubuntu 24.04 LTS (mit USG)
- Root-Zugriff oder
sudo
- Mindestens 2 GB freier Speicher unter
/var (für Reports — die werden über die Zeit größer als gedacht)
- Optional, aber empfohlen: Ansible 2.16+ auf einer Steuer-Maschine
Schritt 1: OpenSCAP und SCAP Security Guide installieren
Auf RHEL 9 / AlmaLinux 9 / Rocky Linux 9 ist es ein Einzeiler:
sudo dnf install -y openscap-scanner scap-security-guide openscap-utils
oscap --version
# OpenSCAP command line tool (oscap) 1.3.10
rpm -q scap-security-guide
# scap-security-guide-0.1.76-1.el9
Auf Ubuntu 24.04 LTS verwenden Sie das Ubuntu-eigene Ubuntu Security Guide (USG), das auf OpenSCAP basiert:
sudo apt update
sudo apt install -y libopenscap8 ssg-base ssg-debderived
# Pro-Subscription für USG (kostenlos für bis zu 5 Maschinen):
sudo pro attach <TOKEN>
sudo pro enable usg
sudo apt install -y usg
Schritt 2: Verfügbare CIS-Profile auflisten
Die SSG-Inhalte liegen in /usr/share/xml/scap/ssg/content/. Inspizieren Sie das passende Datastream:
ls /usr/share/xml/scap/ssg/content/ | grep rhel9
# ssg-rhel9-ds.xml
# ssg-rhel9-oval.xml
# ssg-rhel9-xccdf.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml | grep -E "Profile|Title:"
Typische Ausgabe (gekürzt — die Liste ist länger):
Profile
Title: CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Server
Id: xccdf_org.ssgproject.content_profile_cis_server_l1
Profile
Title: CIS Red Hat Enterprise Linux 9 Benchmark for Level 2 - Server
Id: xccdf_org.ssgproject.content_profile_cis
Profile
Title: CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Workstation
Id: xccdf_org.ssgproject.content_profile_cis_workstation_l1
Profile
Title: DISA STIG for Red Hat Enterprise Linux 9
Id: xccdf_org.ssgproject.content_profile_stig
Profile
Title: ANSSI-BP-028 (high)
Id: xccdf_org.ssgproject.content_profile_anssi_bp28_high
Welches Profil wählen?
| Profil | Zielgruppe | Auswirkung |
|---|
cis_server_l1 | Produktive Web-/App-Server | Niedrig, kompatibel |
cis (L2 Server) | Hoch-sensible Workloads | Mittel, ggf. Funktionsverlust |
stig | Behörden, Verteidigung | Hoch, sehr restriktiv |
anssi_bp28_high | Französische OIV/OSE | Hoch |
Mein Rat: Für die meisten Unternehmen ist CIS Level 1 Server der richtige Einstieg. Sie können später auf Level 2 oder STIG eskalieren — und glauben Sie mir, das wollen Sie auch erst tun, wenn L1 stabil läuft.
Schritt 3: Den ersten CIS-Scan ausführen
Legen Sie zunächst ein Verzeichnis für Audit-Artefakte an:
sudo mkdir -p /var/log/compliance
sudo chmod 750 /var/log/compliance
Und dann starten Sie den Scan gegen das CIS-Level-1-Server-Profil:
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 --results /var/log/compliance/cis-l1-results.xml --report /var/log/compliance/cis-l1-report.html --oval-results /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
echo "Exit-Code: $?"
# 0 = alle Regeln bestanden
# 2 = mindestens eine Regel fehlgeschlagen
Der Scan dauert je nach System 1–5 Minuten. Pro Regel sehen Sie live pass, fail, notapplicable oder notchecked. Den Output kann man durchaus laufen lassen und sich nebenbei einen Kaffee holen.
Schritt 4: Ergebnisse interpretieren
Öffnen Sie den HTML-Report im Browser oder transferieren Sie ihn auf Ihre Workstation:
scp root@server:/var/log/compliance/cis-l1-report.html ./
# oder:
python3 -m http.server 8000 --directory /var/log/compliance
Der Report ist farbcodiert — was ich tatsächlich für eine der besten UX-Entscheidungen im OpenSCAP-Ökosystem halte:
- Grün (Pass) — Regel erfüllt
- Rot (Fail) — Regel verletzt; Remediation nötig
- Grau (Not Applicable) — Regel trifft auf System nicht zu (z. B. Cloud-Service deaktiviert)
- Blau (Manual) — Manuelle Prüfung erforderlich (z. B. physische Zugangskontrolle)
Wenn Sie schnell nur die fehlgeschlagenen Regeln per Kommandozeile sehen wollen:
grep -E 'idref|result' /var/log/compliance/cis-l1-results.xml | grep -B1 'result="fail"' | grep idref | sed -E 's/.*idref="([^"]+)".*/^A/'
Realistische Ausgangslage: Ein frisch installiertes RHEL 9 erreicht typischerweise 55–70 % CIS-L1-Compliance. Klingt erstmal mau, aber das ist normal — und nach automatisierter Remediation sind 92–98 % erreichbar. Die letzten Prozente betreffen meist umgebungsspezifische Manual-Checks.
Schritt 5: Ansible-Playbook für die Remediation generieren
Jetzt wird's nett. OpenSCAP erzeugt aus dem Scan-Resultat direkt einen Ansible-Playbook, der nur die fehlgeschlagenen Regeln behebt:
sudo oscap xccdf generate fix --fix-type ansible --result-id "" --output /var/log/compliance/cis-l1-remediation.yml /var/log/compliance/cis-l1-results.xml
# Alternative: Bash-Skript (wenn Ansible nicht verfügbar)
sudo oscap xccdf generate fix --fix-type bash --result-id "" --output /var/log/compliance/cis-l1-remediation.sh /var/log/compliance/cis-l1-results.xml
Niemals ungeprüft ausführen. Ich kann das nicht oft genug betonen — sichten Sie den Playbook erst:
head -80 /var/log/compliance/cis-l1-remediation.yml
Ein typischer Auszug sieht so aus:
- hosts: all
vars:
var_password_pam_minlen: '14'
var_password_pam_dcredit: '-1'
tasks:
- name: Set Password Minimum Length in login.defs
lineinfile:
path: /etc/login.defs
regexp: '^PASS_MIN_LEN'
line: 'PASS_MIN_LEN 14'
state: present
tags:
- CCE-90871-9
- NIST-800-53-IA-5(f)
- PCI-DSS-Req-8.2.3
- low_complexity
- medium_severity
Beachten Sie die Tags — sie mappen jede Regel auf konkrete Compliance-Frameworks (NIST 800-53, PCI DSS, ISO 27001, DISA STIG). Das ist Gold wert für Auditoren. Im Ernst: Ich habe schon erlebt, wie Auditoren mit diesem Tag-Mapping eine ganze Frageliste in zehn Minuten abhaken konnten, statt eine Stunde Diskussion.
Schritt 6: Vorgefertigte SSG-Playbooks für Vollprofile nutzen
Wenn Sie ein komplettes Profil anwenden wollen (statt nur die aktuellen Fails), liefert scap-security-guide bereits geprüfte Playbooks:
ls /usr/share/scap-security-guide/ansible/ | grep cis
# rhel9-playbook-cis_server_l1.yml
# rhel9-playbook-cis.yml
# rhel9-playbook-cis_workstation_l1.yml
# rhel9-playbook-cis_workstation_l2.yml
Lokale Anwendung mit ansible-playbook:
sudo ansible-playbook -i 'localhost,' -c local /usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml
Remote auf eine Server-Flotte:
cat > inventory.ini <<EOF
[webservers]
web01.example.com
web02.example.com
web03.example.com
EOF
ansible-playbook -i inventory.ini --become --check --diff /usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml
Das --check --diff-Paar ist Pflicht für den ersten Lauf: kein Schreibzugriff, aber Diff aller geplanten Änderungen. Dieser Schritt hat mir schon mehr als einmal den Hintern gerettet.
Schritt 7: Tailoring — Ausnahmen sauber dokumentieren
Nicht jede CIS-Regel passt zu jeder Umgebung, das ist eine simple Wahrheit. Beispiel: CIS verlangt das Deaktivieren von chronyd-Clients ohne authentifizierten NTP-Server — in einer Air-Gapped-Umgebung ist das schlicht unsinnig. Statt die Regel ungelöst zu lassen oder den Playbook zu hacken (was übrigens die schlechteste aller Optionen ist), erstellen Sie eine Tailoring-Datei:
sudo dnf install -y scap-workbench
scap-workbench &
SCAP Workbench (GUI) lädt das Profil, erlaubt das Ab-/Anwählen einzelner Regeln und exportiert eine tailoring.xml. Beim Scan wird sie ergänzend übergeben:
sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1_customized --tailoring-file /etc/compliance/tailoring.xml --results /var/log/compliance/cis-l1-results.xml --report /var/log/compliance/cis-l1-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Jede Ausnahme erhält in der Tailoring-Datei eine Begründung — auditfähig und versionierbar in Git. Das ist genau der Unterschied zwischen „wir haben halt eine Ausnahme gemacht" und „hier ist die dokumentierte, geprüfte Risikoabwägung".
Schritt 8: Wiederkehrender Scan-Fix-Verify-Workflow per Cron
Audits sind kein einmaliges Event. (Wäre schön, ist aber so.) Automatisieren Sie wöchentliche Scans mit einem systemd-Timer:
sudo tee /etc/systemd/system/oscap-scan.service >/dev/null <<'EOF'
[Unit]
Description=Weekly OpenSCAP CIS Compliance Scan
[Service]
Type=oneshot
ExecStart=/usr/local/bin/oscap-scan.sh
EOF
sudo tee /etc/systemd/system/oscap-scan.timer >/dev/null <<'EOF'
[Unit]
Description=Run OpenSCAP scan weekly
[Timer]
OnCalendar=Mon *-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now oscap-scan.timer
Und das passende Skript:
sudo tee /usr/local/bin/oscap-scan.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
DATE=$(date +%Y-%m-%d)
OUTDIR=/var/log/compliance/${DATE}
mkdir -p "${OUTDIR}"
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 --results "${OUTDIR}/results.xml" --report "${OUTDIR}/report.html" /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml || true
PASS=$(grep -c 'result="pass"' "${OUTDIR}/results.xml" || echo 0)
FAIL=$(grep -c 'result="fail"' "${OUTDIR}/results.xml" || echo 0)
logger -t oscap "CIS L1 scan: ${PASS} pass, ${FAIL} fail"
echo "Compliance: $(hostname) — pass=${PASS} fail=${FAIL}" | mail -s "OpenSCAP weekly report" [email protected]
EOF
sudo chmod 750 /usr/local/bin/oscap-scan.sh
Schritt 9: Integration in DevSecOps-Pipelines
Für CI/CD lässt sich der Scan als Pipeline-Stage betreiben — Commits, die die Compliance unterhalb eines Schwellwerts drücken, werden geblockt. Das ist die Stelle, an der Compliance plötzlich operativ wird.
GitLab-CI-Beispiel
compliance_scan:
stage: test
image: registry.access.redhat.com/ubi9/ubi:latest
before_script:
- dnf install -y openscap-scanner scap-security-guide
script:
- oscap xccdf eval
--profile xccdf_org.ssgproject.content_profile_cis_server_l1
--results results.xml
--report report.html
/usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml || true
- PASS=$(grep -c 'result="pass"' results.xml)
- FAIL=$(grep -c 'result="fail"' results.xml)
- SCORE=$(awk "BEGIN { printf "%.1f", ${PASS}*100/(${PASS}+${FAIL}) }")
- echo "Compliance score $SCORE %"
- test "$(echo "$SCORE >= 90" | bc)" -eq 1
artifacts:
when: always
paths: [results.xml, report.html]
expire_in: 90 days
Mit einem Schwellwert von 90 % wird der Build rot, wenn jemand eine kritische CIS-Regel verletzt — z. B. durch ein versehentliches sshd_config-Diff. Das fängt Fehler ab, bevor sie in Produktion landen.
Container-Images scannen
OpenSCAP scannet auch OCI-Images offline:
sudo oscap-podman registry.access.redhat.com/ubi9/ubi:latest xccdf eval --profile xccdf_org.ssgproject.content_profile_cis_server_l1 --report ubi9-cis-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Schritt 10: Re-Scan und Compliance-Score messen
Nach jedem Remediation-Lauf scannen Sie erneut und vergleichen die Scores. Hier ein einfaches Beispielskript:
#!/usr/bin/env bash
RES=$1
PASS=$(grep -c 'result="pass"' "$RES")
FAIL=$(grep -c 'result="fail"' "$RES")
NA=$(grep -c 'result="notapplicable"' "$RES")
TOTAL=$((PASS + FAIL))
SCORE=$(awk "BEGIN { printf "%.2f", ${PASS}*100/${TOTAL} }")
printf "Score: %s%%
Pass: %d
Fail: %d
N/A: %d
" "$SCORE" "$PASS" "$FAIL" "$NA"
Halten Sie die Scores in einer Zeitreihe — Prometheus mit node_exporter-Textfile-Collector ist die übliche Wahl. So sehen Sie sofort, wenn ein Drift den Score nach unten zieht. Und ein Drift kommt — meistens dann, wenn Sie es am wenigsten erwarten.
Häufige Stolpersteine
- "Permissive Trap": SELinux/AppArmor-Regeln werden zwar überprüft, aber das System läuft im
permissive-Modus. CIS L1 erkennt das, wenn Sie das richtige Profil verwenden.
- SSH-Lockout: Aggressive Remediation kann
PermitRootLogin deaktivieren, bevor ein Service-User existiert. Immer mit Konsole-Zugang testen — ich spreche aus schmerzlicher Erfahrung.
- Kernel-Module-Blacklist: CIS deaktiviert
cramfs, squashfs, udf. Squashfs ist aber für snap-Pakete und Live-Boot zwingend — Tailoring nötig.
- FIPS-Mode-Konflikt: STIG aktiviert FIPS, was nicht-FIPS-fähige Crypto-Bibliotheken bricht. Vorab Kompatibilität testen, sonst hagelt es Tickets.
Best Practices 2026
- Niemals zuerst auf Produktion remediieren. Staging zuerst, dann Canary, dann Rollout. Klingt selbstverständlich — wird trotzdem regelmäßig ignoriert.
- Versionieren Sie Tailoring-Dateien in Git. Jede Ausnahme braucht einen Pull-Request mit Begründung.
- Mappen Sie CIS-Tags auf Ihr Compliance-Framework. Auditoren lieben es, wenn ein Finding direkt PCI-DSS-Req-2.2.4 zeigt.
- Behandeln Sie Compliance-Score wie ein SLO. Ein Drift unter 95 % ist ein Incident, kein Backlog-Item.
- Kombinieren Sie OpenSCAP mit Wazuh oder auditd. SCAP zeigt Konfigurations-Drift, SIEM zeigt aktive Angriffe — beides braucht es.
- Auditieren Sie auch CI/CD-Runner. Build-Maschinen werden gern vergessen — sind aber ein klassischer Supply-Chain-Eintrittspunkt.
FAQ — Häufig gestellte Fragen
Was ist der Unterschied zwischen OpenSCAP und Lynis?
Lynis ist ein Bash-basiertes Audit-Tool ohne formales Policy-Modell — schnell, aber ohne standardisierte Rule-IDs oder Remediation-Generierung. OpenSCAP implementiert dagegen den NIST-SCAP-Standard mit XCCDF-Profilen, OVAL-Checks, automatischer Ansible-/Bash-Remediation und Compliance-Framework-Mapping (CIS, STIG, PCI DSS, ISO 27001). Für Audit-Nachweise und reproduzierbare DevSecOps-Pipelines ist OpenSCAP klar die professionellere Wahl; Lynis eignet sich für schnelle Erst-Bewertungen.
Welches CIS-Level sollte ich für einen produktiven Webserver wählen?
In der Regel CIS Level 1 Server. Level 1 ist explizit so designt, dass es ohne Funktionsverluste anwendbar ist. Level 2 erhöht die Sicherheit auf Kosten von Komfort und Kompatibilität (z. B. striktere Filesystem-Mount-Optionen, eingeschränkte Kernel-Module) und ist für hoch-sensible Workloads wie Datenbanken mit PII, Tresore oder PKI-Server gedacht. Mein Rat: Beginnen Sie mit L1, erreichen Sie 95 %+ Score und eskalieren Sie pro Workload-Klasse auf L2.
Funktioniert OpenSCAP auch mit Ubuntu und Debian?
Ja. Ubuntu liefert seit 22.04 das Ubuntu Security Guide (USG), das auf OpenSCAP basiert und CIS-Profile sowie DISA-STIG für Ubuntu enthält. Debian wird durch das Community-Projekt ssg-debderived abgedeckt, wenngleich die Profil-Reife geringer ist als auf RHEL. Auf Ubuntu 24.04 LTS aktivieren Sie USG via sudo pro enable usg; das CLI-Werkzeug usg audit cis_level1_server ist im Grunde ein Wrapper um oscap.
Kann ich OpenSCAP-Berichte für ISO-27001- oder BSI-Audits verwenden?
Direkt nutzbar sind die HTML-/ARF-Reports in jedem Audit, da sie zeitgestempelt, signiert (mit --validate) und mit Rule-IDs auf NIST 800-53, ISO 27001 A.12, PCI DSS, DISA STIG und CCE-Kennungen gemappt sind. Für BSI-Grundschutz existieren keine offiziellen SSG-Profile, aber CIS-L1+L2 deckt >80 % der Bausteine SYS.1.1 (Allgemeiner Server) und SYS.1.3 (Linux/Unix-Server) ab — viele Auditoren akzeptieren CIS-Reports plus dokumentiertes Mapping als Nachweis.
Wie lange dauert ein vollständiger CIS-Scan?
Auf einem typischen 4-vCPU-VM-Server liegt ein CIS-L1-Scan bei 60–180 Sekunden, ein L2-Scan bei 180–300 Sekunden. Der OVAL-Vulnerability-Scan kann zusätzlich 60–120 Sekunden brauchen. Auf Container-Images via oscap-podman sind 30–60 Sekunden realistisch. Für eine Flotte von 100 VMs in paralleler Ansible-Ausführung rechnen Sie mit ~10 Minuten End-to-End — schnell genug für nächtliche Pipeline-Läufe.
Fazit
Compliance-Auditing 2026 funktioniert nur als Code: SCAP-Profile als Single Source of Truth, OpenSCAP als Scanner, Ansible als Remediation-Engine. Die Kombination liefert Auditoren maschinenlesbare Nachweise, dem Ops-Team idempotente Härtungs-Playbooks und der Pipeline ein hartes Compliance-Gate.
Wenn Sie unsere bisherigen Härtungs-Leitfäden zu SSH, Boot-Chain, Container und nftables bereits umgesetzt haben, ist OpenSCAP der logische nächste Baustein — und macht aus einem gehärteten System ein nachweisbar gehärtetes System. Das ist der Unterschied, der im Audit zählt.
