Sicherheitsregeln automatisch testen

Schnell abgehakt

Rudolf Grötz, Nebojsa Nicolic

Unternehmen in regulierten Märkten müssen hohe Anforderungen an die Compliance erfüllen. Statt die Einhaltung aller Regeln manuell zu prüfen, erlaubt ein Open-Source-Werkzeug die automatisierte Kontrolle.

Sicherheitsregeln (Compliance Rules, Controls) im Sinne von Regelkonformität stehen scheinbar im Widerspruch zu der sich transformierenden, agilen Welt. Denn auf den ersten Blick passt Agilität mit übermäßiger Vorsicht und strikter Einhaltung von Vorschriften nicht zusammen. Können regulierte Industrien neue Produkte und Dienstleistungen kontinuierlich und schnell liefern und gleichzeitig immer alle gesetzlichen Vorschriften einhalten?

Die Antwort ist ein klares „Ja“. Die Lösung besteht unter anderem darin, die Einhaltung gesetzlicher Vorschriften in den Prozess der Softwareentwicklung und -bereitstellung einzubetten. Diese Einbettung basiert auf der Idee von Infrastruktur als Code, die es Unternehmen ermöglicht, ihre Compliance-Anforderungen so festzulegen, dass man sie automatisch testen kann. Die Automatisierung erhöht nicht nur das Tempo der Systembereitstellung, sondern ermöglicht auch die konsequente Umsetzung regulatorischer Anforderungen in Umgebungen, die Hunderte oder Tausende von Servern umfassen. Dieser Artikel zeigt am Beispiel von PCI DSS (Payment Card Industry Data Security Standard), wie das automatisierte Testen solcher Erfordernisse praktisch aussieht.

PCI DSS sichert Kreditkartendaten

PCI DSS ist ein Standard für Unternehmen, die Kreditkartendaten elektronisch speichern, verarbeiten oder übertragen. 2004 schuf das Payment Card Industry Security Standards Council unter diesem Namen sechs Controls (siehe ix.de/ix1801114, [a]) und 12 Requirements (siehe Kasten „PCI DSS Requirements“) zum Schutz von Kreditkartendaten. Große Kreditkartenunternehmen schreiben nun ihren Mitgliedern, Händlern und Dienstleistern vor, PCI DSS zu befolgen. Bei fehlender oder nicht ordnungsgemäßer Umsetzung dürfen sie Bußgelder verhängen. Besonders grobe Verletzungen des Standards können dazu führen, dass das Unternehmen keine Kreditkartendaten mehr verarbeiten darf.

Viele Unternehmen speichern Sicherheitsregeln noch als Excel-Sheets, PDF- oder Word-Dokument. Die Umsetzung dieser Richtlinien erfolgt durch meistens manuell durchgeführte Application-Audits. Statt nun in Audits Checklisten oder ähnliche Dokumente von Hand abzuarbeiten, lassen sich Richtlinien und Regeln auch automatisiert prüfen. Dieses Verfahren, besser bekannt als „Compliance as Code“, ersetzt die abstrakte Beschreibung der Prüfung durch konkrete, automatisch durchführbare Tests, die sich in die Continuous-Delivery-Pipeline integrieren lassen. So sind missachtete Vorgaben frühzeitig im Entwicklungsprozess zu erkennen und zu beheben. Unternehmen können diese Tests für jede Umgebung in ihrer Organisation anwenden, um sicherzustellen, dass sie alle Richtlinien einhalten und den Compliance-Anforderungen entsprechen.

Beim Umsetzen von Compliance as Code hat sich das Open-Source-Projekt InSpec [b] etabliert. Damit kann man Sicherheitsregeln in einer menschen- und maschinenlesbaren Sprache definieren. Ist es in eine Continuous-Delivery-Pipeline integriert, prüft man damit auszuliefernde Systeme rechtzeitig vor dem Deployment auf Einhaltung dieser Anforderungen.

Anhand des fiktiven Versandhauses Dagobert’s Duck Online (DDO) sei erklärt, wie man mit InSpec die PCI-DDS-Compliance in der Continuous-Delivery-Pipeline automatisch überprüft. DDO liefert viermal jährlich neue Features in Main-Releases aus. Zusätzlich gibt es Hotfix-Releases, die Fehler in der Produktion beheben. Vor der Inbetriebnahme muss die Compliance-Abteilung jede Release auf PCI-DSS-Compliance kontrollieren. Dabei betrachtet sie nur die 40 wichtigsten Sicherheitsregeln des Onlineshops. Einmal pro Jahr untersucht ein Security-Audit das gesamte System auf PCI-DSS-Compliance. Sämtliche Prüfungen erfolgen bisher manuell.

Um schneller auf Marktanforderungen reagieren zu können, hat der CTO von DDO beschlossen, den Onlineshop in Microservices aufzuteilen. Dazu dienen Spring-Boot, Tomcat und Docker-Container. Sie sollen Continuous Delivery ermöglichen.

300 Docker-Container und 20 Regeln

Der neue Onlineshop besteht aus rund 300 Docker-Containern, die Entwicklungs-, Test- und Produktionsumgebungen bilden. Insgesamt gibt es mehr als 20 Sicherheitsregeln, die die PCI-DSS-Compliance der Docker-Container gewährleisten. Deren manuelle Kontrolle widerspräche dem Gedanken von Continuous Delivery. Deshalb hat sich das Team entschlossen, diese Überprüfungen mit InSpec und dessen Beschreibungssprache zu automatisieren.

control "helloInSpecWorld-1.0" do                                          
  impact 1.0
  title "Hello World"
  desc "Text should include the words Hello World '."
  describe file('helloInspecWorld.txt') do
   its('content') { should include 'Hello World' }
  end
end

Aller Anfang ist leicht, auch bei InSpec. Einfach das passende Plattformpaket [c] laden und gemäß Installationsanweisung einrichten. Danach steht der Entwicklung von Sicherheitsregeln nichts mehr im Wege. Listing 1 zeigt das klassische Hello-World-Beispiel für InSpec. Es prüft, ob eine bestimmte Datei die Zeichenkette „Hello World“ enthält. Das beginnt mit describe und der zu testenden Ressource. Dies ist ein Konfigurations-Item des geprüften Systems, beispielsweise IP-Ports, Dateien oder Konfigurationswerte für Webserver und Datenbanken [d]. Hier ist es die Ressource file.