Ziel dieser Anleitung

Dieser Teil schließt die technische SUSE-Multi-Linux-Manager-Reihe um Compliance und OpenSCAP ab. Du siehst, wie du verwaltete Linux-Systeme nicht nur patchst, sondern nachvollziehbar gegen Sicherheitsprofile prüfst, Ergebnisse auswertest und Remediation verantwortungsvoll planst.

Wir verwenden in den Beispielen mlm01.example.test als dokumentierten Platzhalter für den echten Manager-FQDN. In deiner Umgebung ersetzt du ihn durch den produktiven Namen deines Managers.

Kompletter Ablauf der Serie

Diese Reihe führt dich Schritt für Schritt durch den produktiven Aufbau: 1. SLES 16 produktiv installieren · 2. SUSE Multi-Linux Manager 5.2 installieren · 3. Erste Linux-Clients onboarden · 4. Patch- und Lifecycle-Management · 5. Mixed Linux verwalten · 6. OpenSCAP, Compliance und Audit · 7. Proxies für Standorte aufbauen · 8. SSO mit Keycloak integrieren · 9. Ansible neben Salt nutzen · 10. Reporting, Inventar und Audit · 11. Produktiv betreiben und härten

SUSE-Serie: Teil 6

  • Teil 1: SLES 16 produktiv installieren
  • Teil 2: SUSE Multi-Linux Manager 5.2 produktiv installieren
  • Teil 3: erste Linux-Clients onboarden
  • Teil 4: Patch- und Lifecycle-Management
  • Teil 5: Mixed Linux verwalten
  • Teil 6: Compliance und OpenSCAP-Audits
  • Teil 7: Reporting und Subscription Audit
  • Teil 8: Betrieb härten
https://mlm01.example.test

Was OpenSCAP im Manager leistet

OpenSCAP prüft Systeme anhand maschinenlesbarer Security-Profile. SUSE Multi-Linux Manager kann Scans für Clients planen, Ergebnisse zentral anzeigen und die Daten als Audit-Nachweis nutzbar machen. Das ersetzt keinen manuellen Security-Review, gibt dir aber wiederholbare technische Prüfpunkte.

  • CVE-Audit zeigt, welche Systeme für bekannte Schwachstellen relevant sind.
  • OpenSCAP bewertet Konfigurationen gegen Profile wie Standard, STIG, PCI-DSS oder distributionsspezifische Community-Profile.
  • Scan-Ergebnisse gehören in einen Remediation-Prozess, nicht blind in automatische Änderungen.

Clients vorbereiten

Ein Client muss als Salt-System funktionieren, ausreichend Ressourcen haben und passende OpenSCAP-Pakete sowie SCAP-Content besitzen. Plane für moderne Systeme mindestens 2 GB RAM für Scans ein, weil Profile und Reports auf dem Client berechnet werden.

bash
zypper install openscap-utils scap-security-guide
rpm -ql scap-security-guide | grep ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Für RHEL-kompatible Systeme wie Rocky Linux, AlmaLinux oder Oracle Linux verwendest du in der Regel openscap-utils und scap-security-guide-redhat aus passenden Kanälen. Debian 13 und Ubuntu 24.04 LTS sind technisch prüfbar, benötigen aber communitybereitgestellten SCAP-Content und sind deshalb anders zu bewerten als der SUSE/RHEL-kompatible Standardpfad.

bash
dnf install openscap-utils scap-security-guide-redhat
rpm -ql scap-security-guide-redhat | grep ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
bash
apt update
apt install openscap-scanner ssg-debian
dpkg -L ssg-debian | grep ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-debian13-ds.xml

Scan aus der Web-UI planen

Öffne in der Weboberfläche den Client über Systems -> System List -> All, wechsle in den Systemdetailbereich und dort zum Audit-Tab. Im Schedule-Subtab hinterlegst du den XCCDF-Pfad und das Profil. Der Scan läuft beim nächsten Client-Check-in beziehungsweise zur geplanten Aktion.

bash
/usr/bin/oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_standard /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
https://mlm01.example.test

Ergebnisse auswerten

Die zentrale Auswertung liegt unter Audit -> OpenSCAP -> All Scans. Dort prüfst du Zielsystem, Profil, Zeitpunkt, Ergebnis und Detailreport. Für Audits ist wichtig, dass Ergebnisse reproduzierbar, versioniert und mit einer Remediation-Entscheidung verbunden werden.

bash
spacewalk-report system-history-scap
spacewalk-report scap-scan
spacewalk-report scap-scan-results

Remediation verantwortungsvoll durchführen

SCAP-Profile können Bash- und Ansible-Remediation liefern. Trotzdem solltest du Änderungen nie ungeprüft auf Produktion ausrollen. Baue eine Testgruppe, sichere den Ist-Zustand, prüfe Auswirkungen auf Applikationen und überführe akzeptierte Änderungen in Configuration as Code.

  • Scan-Ergebnis lesen und Risiko bewerten.
  • Regel verstehen, nicht nur den Fail-Status betrachten.
  • Remediation zuerst auf Testsystemen ausführen.
  • Änderungen in Ansible, Salt State oder Policy dokumentieren.
  • Danach erneut scannen und den Befund schließen.

Produktionscheckliste

  • Clients sind als Salt-Systeme erreichbar.
  • SCAP-Pakete und Profile sind pro Distribution dokumentiert.
  • CVE-Audit, OpenSCAP und Patch-Prozesse sind getrennt verstanden.
  • Ergebnisaufbewahrung und Detailreports sind organisatorisch geregelt.
  • Remediation läuft nur über getestete Wartungsfenster.
  • Debian/Ubuntu-Community-Content wird nicht als SUSE-Supportzusage dargestellt.

Audit-Modell für Produktion festlegen

Bevor du den ersten Scan planst, brauchst du ein klares Audit-Modell. Ein Profil ist kein Selbstzweck. Es muss zu regulatorischen Anforderungen, Betriebsrisiko, Applikationslandschaft und Supportmodell passen. Für ein internes Baseline-Audit reicht oft ein Standardprofil. Für stärker regulierte Umgebungen können STIG, CIS-orientierte Profile oder projektspezifische Tailoring-Dateien relevant werden.

Wichtig ist, dass du den Scope klein genug hältst. Starte mit einer Testgruppe, nicht mit der gesamten Flotte. Prüfe zuerst einen repräsentativen SLES-Client, danach einen RHEL-kompatiblen Client und erst dann Debian- oder Ubuntu-Systeme, wenn der Content und die Erwartungshaltung geklärt sind.

  • Profil und Content-Version dokumentieren.
  • Scan-Zeitfenster und Zielgruppe festlegen.
  • Speicher- und CPU-Last auf Clients berücksichtigen.
  • Ergebnisaufbewahrung mit Security und Betrieb abstimmen.
  • Remediation nur nach Review und Change-Freigabe ausführen.

Distributionsunterschiede sauber behandeln

SUSE Multi-Linux Manager ist stark, weil er unterschiedliche Linux-Plattformen zentral sichtbar und steuerbar macht. Bei Compliance heißt das aber nicht, dass jedes Profil auf jedem System denselben Aussagewert hat. SLES und RHEL-kompatible Systeme haben in der Regel den klarsten Enterprise-Pfad. Debian und Ubuntu können technisch eingebunden werden, brauchen je nach Version aber Community-SCAP-Content. Dieser Unterschied muss im Auditbericht sichtbar bleiben.

Für Kundenprojekte ist genau diese Einordnung entscheidend. Es reicht nicht, einen grünen oder roten Scan zu erzeugen. Man muss erklären können, welche Regeln geprüft wurden, welche Regeln für die Plattform sinnvoll sind, welche Regeln aus Applikationsgründen bewusst abweichen und welche Findings echte Risiken darstellen.

bash
# SLES / openSUSE: Content-Pfade prüfen
rpm -ql scap-security-guide | grep -E "ds.xml$|xccdf"
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml


# RHEL-kompatible Systeme: Red-Hat-kompatiblen Content prüfen
rpm -ql scap-security-guide-redhat | grep -E "ds.xml$|xccdf"
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

Scan-Ergebnisse in Maßnahmen übersetzen

Nach dem Scan beginnt die eigentliche Arbeit. Ein Fail ist ein Signal, aber noch kein fertiger Change. Prüfe pro Finding, ob die Regel für den Servertyp sinnvoll ist, ob Applikationen betroffen sind, ob es eine Ausnahme gibt und wie der Zielzustand automatisiert hergestellt werden soll. Genau hier entsteht aus OpenSCAP ein belastbarer Betriebsprozess.

In einer produktiven Umgebung entstehen daraus Tickets, Changes, Ansible- oder Salt-States, Dokumentationsänderungen und erneute Scans. Der zweite Scan ist wichtig: Er zeigt, ob die Änderung wirklich den gewünschten Zustand erzeugt hat oder nur Symptome verändert wurden.

  • Finding bewerten: Risiko, Auswirkung, Priorität.
  • Owner definieren: Plattform, Applikation, Security oder Fachbereich.
  • Änderung testen und automatisieren.
  • Erneut scannen und Ergebnis archivieren.
  • Akzeptierte Abweichungen mit Ablaufdatum dokumentieren.

OpenSCAP und Patchmanagement trennen

Patchstatus und Konfigurationscompliance sind verwandt, aber nicht identisch. Ein vollständig gepatchtes System kann falsch konfiguriert sein. Ein hart konfiguriertes System kann trotzdem sicherheitsrelevante Updates vermissen. Deshalb gehören CVE-Audit, Patchlisten und OpenSCAP-Ergebnisse nebeneinander in den Betriebsreview.

Sinnvoll ist ein monatlicher Compliance-Lauf für definierte Systemgruppen und ein separater, häufiger Patch-Review für kritische Advisories. Für besonders kritische Systeme kann der Rhythmus enger sein. Entscheidend ist, dass der Prozess geplant, wiederholbar und nachvollziehbar bleibt.

Quellen und weiterführende Dokumentation

  • SUSE Multi-Linux Manager 5.2 OpenSCAP: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/openscap.html
  • SUSE Multi-Linux Manager 5.2 Auditing: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/auditing.html
  • SUSE Multi-Linux Manager 5.2 Reports: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/reports.html
  • SUSE Multi-Linux Manager 5.2 Backup and Restore: https://documentation.suse.com/multi-linux-manager/5.2/en/docs/administration/backup-restore.html

OpenSCAP im produktiven Betrieb

OpenSCAP macht technische Compliance prüfbar. Im Manager planst du Scans für registrierte Systeme, wertest Ergebnisse zentral aus und leitest daraus Härtungsaufgaben ab. Das ist kein Ersatz für ein Sicherheitskonzept, aber ein starker Nachweis, ob Baselines eingehalten werden.

app.example.com

Ablauf für einen Compliance-Scan

  1. Client vorbereiten: OpenSCAP-Pakete und passenden SCAP-Content installieren.
  2. System im Manager öffnen und unter Audit einen Scan planen.
  3. Profil und XCCDF-Content auswählen.
  4. Scan ausführen und Ergebnis zentral prüfen.
  5. Findings priorisieren: kritisch, schnell behebbar, bewusst akzeptiert oder projektrelevant.
  6. Remediation zuerst auf Testsystemen validieren.

Distributionen realistisch einordnen

  • SLES und RHEL-kompatible Systeme haben den stärksten Enterprise-Compliance-Pfad.
  • Rocky und AlmaLinux können mit RHEL-kompatiblen SCAP-Inhalten arbeiten, müssen aber gegen den realen Supportkontext geprüft werden.
  • Debian und Ubuntu können technisch gescannt werden; offizieller Content und Aussagekraft müssen je Policy sauber bewertet werden.
  • SSH-contact-method Clients sind laut SUSE-Dokumentation für OpenSCAP nicht geeignet.
bash
salt 'sles16-client01.example.test' pkg.install openscap-utils
salt 'sles16-client01.example.test' pkg.install scap-security-guide
salt 'sles16-client01.example.test' cmd.run 'oscap --version'

Audit-Nachweis

Ein guter Audit-Nachweis besteht aus Scan-Zeitpunkt, Systemgruppe, Profil, Ergebnis, Ausnahmen, Remediation-Entscheidung und Nachprüfung. Diese Kette ist wichtiger als ein grüner Score ohne Kontext.

CVE-Audit mit echten Daten statt leerer Suche

Ein leerer CVE-Suchlauf beweist nur, dass genau diese CVE im lokalen Datenbestand nicht gefunden wurde. Für einen produktiven Audit zeigst du deshalb zuerst relevante Patches und Advisorys, wählst daraus eine echte CVE oder Advisory-ID und prüfst danach betroffene Systeme.

app.example.com
  • CVE-/Patchdaten regelmäßig synchronisieren und nach Channel-Änderungen einen Extra-Update-Lauf einplanen.
  • Eine reale CVE oder ein Advisory aus der Patchliste auswählen, nicht eine beliebige Nummer testen.
  • Betroffene Systeme, verfügbare Fixes, Patchstatus und Ausnahmen dokumentieren.
  • OpenSCAP-Ergebnisse getrennt bewerten: CVE-Audit prüft Verwundbarkeit/Patches, OpenSCAP prüft Konfiguration gegen Profile.

SUSE Multi-Linux Manager produktiv einsetzen

Du möchtest SLES, SL Micro, Debian, Ubuntu, Rocky, AlmaLinux oder Oracle Linux zentral verwalten, Patches prüfen, Compliance nachweisen oder den Betrieb härten? ForgeOne unterstützt dich bei Lizenzen, Architektur, Installation, Professional Services und laufendem Support.

SUSE-Projekt besprechen