Dies ist der vierte Artikel in meiner Serie über Red Hat Insights. In diesem beschäftige ich mich mit der Möglichkeit meine Systeme auf Compliance prüfen zu können.
Hinweis: Um Systeme auf Compliance prüfen zu können, müssen neben dem insights-client auch die Pakete openscap-scanner und scap-security-guide auf den jeweiligen Systemen installiert sein.
Compliance Policy erstellen und Systeme zuweisen
Compliance bedeutet vereinfacht ausgedrückt, Regeln einzuhalten bzw. Vorgaben zu erfüllen. Demnach benötigt man eine Richtlinie mit einem Regelwerk gegen welches man seine Systeme abgleichen kann. Diese Regelwerke findet man häufig in Form von Standards wie z.B. PCI-DSS, HIPAA (en) oder SOX. Bevor man eine entsprechende Richtlinie (Policy) erstellt bzw. ausgewählt hat, gibt es daher im Insights-Dashboard auch noch nichts zu sehen (siehe Bild 1).
Als erstes ist daher eine Policy zu erstellen. Hierbei wird man von einem Assistenten durch die verschiedenen Dialoge geführt (siehe Bild 2-7). Für meinen Test habe ich eine SCAP-Policy für RHEL 7 Systeme mit dem „Standard System Security Profile for Red Hat Enterprise Linux 7“ erstellt (vgl. Bild 2 und 3). Selbstbewusst und ohne zu wissen, was mich erwartet, habe ich den Compliance Threshold auf 96 Prozent festgelegt (vgl. Bild 4). Im nächsten Schritt (Bild 5) werden die im Profil enthaltenen Regeln aufgelistet, mit der Möglichkeit sich zu jeder Regel eine detaillierte Beschreibung anzeigen lassen zu können. An dieser Stelle können einzelne Regeln deaktiviert werden, sofern man diese für unwichtig erachtet. Für diesen Test lasse ich alle Regeln aktiviert und bin auf das Ergebnis gespannt.
Bild 6 zeigt den Auswahldialog, in dem Systeme der zu erstellenden Policy zugewiesen werden. Grundsätzlich kann man verschiedene Policies für unterschiedliche Systeme verwenden oder einzelne Systeme nach mehren Policies auditieren lassen. Für diesen Test wurden alle 13 Systeme der aktuellen Policy zugewiesen.
Bild 2: Erstellen einer SCAP-Policy für RHEL 7 
Bild 3: Auswahl eines SCAP-Profils 
Bild 4: Details des ausgewählten SCAP-Profils und Einstellung des Compliance-Thresholds 
Bild 5: Übersicht über die im ausgewählten Profil enthaltenen Regeln, mit der Möglichkeit einzelne Regeln zu deaktivieren 
Bild 6: Auswahl von Systemen, welche der neuen Policy hinzugefügt werden sollen 
Bild 7: Zusammenfassung der Einstellungen 
Bild 8: Übersicht der vorhandenen SCAP-Policies mit Anzahl zugewiesener Systeme und Compliance-Threshold
Zum Abschluss des Assistenten wird noch einmal eine Zusammenfassung angezeigt (Bild 7), bevor die Policy erstellt wird. Anschließend kann man die soeben erstellte Policy in der Übersicht wiederfinden (vgl. Bild 8).
Compliance-Scan ausführen
In vorstehendem Abschnitt wurde eine SCAP-Policy erstellt und mit den vorhandenen Systemen verknüpft. Um die Systeme nun auf Compliance zu prüfen, ist der insights-client auf jedem System mit der Option --compliance zu starten. Der folgende Code-Block zeigt beispielhaft einen interaktiven Aufruf.
# insights-client --compliance
Running scan for xccdf_org.ssgproject.content_profile_standard... this may take a while
Uploading Insights data.
Successfully uploaded report for foo.example.com.
#Möchte man seine Systeme regelmäßig mit dem Compliance-Scan prüfen, kann dies über einen Cronjob oder durch ein regelmäßig auszuführendes Ansible-Playbook gelöst werden.
Hinweis: Es handelt sich dabei nicht um den normalen Scan des insights-client, welcher täglich ausgeführt wird und Informationen an den SaaS-Dienst übermittelt.
Der hochgeladene Report ist wenige Minuten später im Compliance-Menü des Insights-Dashboards sichtbar.
Compliance-Reports im Insights-Dashboard
Das Insights-Dashboard bietet die aus den vorhergehenden Artikeln bekannte tabellarische Übersicht auch im Compliance-Menü. Hierüber gelangt man zu einer Ansicht, welche die Systeme mit ihrem jeweiligen Compliance-Score und der Anzahl nicht eingehaltener Regeln auflistet (siehe Bild 9).
Bild 10 zeigt einen Ausschnitt eines Reports für ein ausgewähltes System. Hier werden die Compliance-Regeln mit Name und ID aufgeführt. Darüber hinaus erkennt man auf einen Blick die Severity, ob der Test bestanden wurde und ob ein Ansible-Remediation-Playbook existiert.
Bild 9: Übersicht der zur SCAP-Policy vorliegenden Reports aller Systeme 
Bild 10: Compliance-Report für ein ausgewähltes System
In Bild 10 wurde eine Regel exemplarisch aufgeklappt, um die dahinter liegenden Informationen anzuzeigen. Diesen kann man entnehmen, welche Einstellungen vorhanden sein müssen, um diese konkrete Regel zu erfüllen. Man erhält an dieser Stelle daher nicht nur allgemeine Hinweise, sondern zudem explizite Handlungsempfehlungen. Darüber hinaus gibt es zu jeder Regel einen Hinweis, warum es sinnvoll erscheint, die empfohlenen Maßnahmen umzusetzen.
In diesem Test hat übrigens keines der 13 Systeme den vorgegebenen Compliance-Score erreicht. Dabei erreichten acht Systeme einen Score zwischen 80-85%, drei lagen bei 70-75% und zwei Systeme erreichten lediglich einen Score von 43-48%.
Das Ergebnis ist nun aber nicht so schlimm, wie es auf den ersten Blick aussieht. Denn einige der im verwendeten Profil geforderten Einstellungen sind in unserem Fall mitbestimmungspflichtig und müssen im Vorfeld einer möglichen Umsetzung mit dem Personalrat abgestimmt werden.
Fazit
Zwar sind unsere Systeme Stand heute an keine konkrete Policy gebunden, doch macht es in meinen Augen durchaus Sinn sich an einigen dieser Policies zu orientieren und deren sinnvoll erscheinenden Regeln einzuhalten. Ihnen blind zu folgen ist hingegen nicht sinnvoll. Oder wie mein Kollege sagte: „Man muss sich vielleicht nicht unbedingt wie eine Bank verhalten, wenn man keine Bank ist. :) „
Zur Erstellung von Compliance-Reports und der Ableitung einer Konfigurations-Baseline aus diesen hätte es des Insights-Dashboards nicht bedurft. Mit dem openscap-scanner und dem scap-security-guide können Reports für ausgewählte SCAP-Profile auch lokal auf jedem System erstellt und analysiert werden. Gerade bei der Erstellung einer Baseline lassen sich dabei Erkenntnisse von wenigen ausgewählten Systemen auf eine größere Gruppe von Hosts in der eigenen Infrastruktur übertragen.
Das Insights-Dashboard bietet an dieser Stelle den Mehrwert, alle relevanten Informationen an einer Stelle vorliegen bzw. verlinkt zu haben. Der Wechsel zwischen verschiedenen Anwendungen entfällt und Ergebnisse lassen sich leichter miteinander vergleichen.
Die verfügbaren Ansible-Remediation-Playbooks machen einen soliden Eindruck und sind geeignet, notwendige Einstellungen zu setzen, um eine konkrete Regel einzuhalten. Ich selbst führe diese jedoch nicht direkt in meiner Infrastruktur aus, sondern nutze sie lediglich als Ausgangspunkt für eigene Playbooks und Vorlagen. So fällt der Lerneffekt für mich persönlich größer aus.