Terraform-Sicherheit in Scalr-Deployments mit Regula automatisieren [Tutorial]

Einführung in die Integration von Regula und Scalr

Regula

Regula ermöglicht Cloud-Teams, Terraform, CloudFormation, Azure Resource Manager und Kubernetes-Infrastructure-as-Code (IaC) vor dem Deployment auf Sicherheits- und Compliance-Verstöße zu überprüfen. Regula ist eine Open-Source-Implementierung von Rego, der Abfragesprache des Open Policy Agent (OPA)-Projekts. Wo relevant, wurden die Richtlinien von Regula den Benchmarks des Center for Internet Security (CIS) für Amazon Web Services (AWS), Azure, Google Cloud und Kubernetes Foundation zugeordnet. So können Nutzer diese Richtlinien bereits vor dem Deployment auf IaC durchsetzen.

Durch Regulas Fähigkeit, IaC vor dem Deployment auf Fehlkonfigurationen zu prüfen, werden Cloud-Sicherheit und Compliance auf entwicklerfreundliche Weise zur Verantwortung der Entwicklungsteams. So wird der Sicherheitsengpass beim Deployment von Cloud-Infrastruktur mit IaC beseitigt. Regula wird von Fugue-Ingenieuren gepflegt.

Scalr

Scalr ist eine Software für Terraform-Automatisierung und Zusammenarbeit (TACO), die Automatisierung von Pull Requests, die native Terraform-CLI und modulbasierte Workflows unterstützt. Scalr hilft Unternehmen jeder Größe, durch ein hierarchisches Modell zu skalieren, das Admin-Vorgänge wie RBAC, Richtlinienkontrolle über OPA, Betriebsansichten und eine private Modul-Registry zentralisiert. So lassen sich Terraform-Vorgänge kontrolliert dezentralisieren, sodass Entwickler Terraform-Workflows unabhängig in ihren Umgebungen ausführen können.

Ziel

Regulas komfortable, leistungsstarke IaC-Scanning-Funktionen mit Scalrs Automatisierungs- und Kollaborationsmöglichkeiten für Terraform kombinieren und zeigen, wie Unternehmen das sichere Deployment von Cloud-Infrastruktur mit Terraform automatisieren können.

Voraussetzungen

Wenn Sie mitmachen möchten, benötigen Sie Folgendes:

• Ein Scalr-Konto mit aktivierten Custom Hooks (Hinweis: Diese Funktion ist kostenpflichtig). Weiter unten erfahren Sie, wie Sie sie konfigurieren.

• Einen in Ihrem Scalr-Konto konfigurierten Workspace. In einem Workspace werden alle Objekte gespeichert und verwaltet, die zu Terraform-verwalteten Ressourcen gehören.

• Zu Ihrem Scalr-Konto hinzugefügte Cloud-Provider-Zugangsdaten (für diese Demo verwende ich AWS)

• Einen in Ihrem Scalr-Konto konfigurierten Provider für ein Versionskontrollsystem (VCS) (für diese Demo verwende ich GitHub)

• Weisen Sie scripts/security.bash als Custom Hook „Before plan“ und scripts/validate.bash als Custom Hook „After plan“ zu

• Die aktuelle Regula-Version in Ihrem Verzeichnis /usr/local/bin (unser Skript security.bash lädt sie herunter und führt sie in der Scalr-Pipeline aus. Wenn sie lokal vorhanden ist, können Sie Ihren Code jedoch schon vor dem Commit überprüfen.)

Optional können Sie auch mein Repository klonen und sich etwas Arbeit ersparen, indem Sie den folgenden Befehl in Ihrem Terminal ausführen:

git clone https://github.com/fugue/fugue-scalr-integration.git

Was steckt im Repository?

Oben sehen Sie eine grafische Darstellung der Dateistruktur meines Repositorys. Besonders wichtig sind folgende Dateien:

• main.tf: Eine Terraform-Datei mit Angaben zu Providern und Modulen

• s3/: Ein Unterverzeichnis mit Terraform-Dateien, die bewusst Schwachstellen enthalten

• waivers.rego: Eine Datei, mit der ausgewählte Regeln ausgenommen und deaktiviert werden

• .regula.yaml: Eine Regula-Konfigurationsdatei, in der festgelegt wird, wie Regula in diesem Repository ausgeführt werden soll

• scripts/: Ein Unterverzeichnis mit dem oben beschriebenen Custom Hook

Hier sehen Sie den Inhalt des S3-Moduls genauer, ergänzt um eine Übersicht des Konfigurationsstatus der gesamten Infrastruktur (Verstöße gegen CIS-Benchmarks sind rot markiert):

Scalr-Custom-Hooks konfigurieren

Mit Custom Hooks lässt sich der grundlegende Terraform-Workflow anpassen, etwa durch Befehle, Skripte oder API-Aufrufe. Neben Regula für Sicherheits- und Compliance-Scans enthalten die in dieser Demo verwendeten Shell-Skripte auch Prüfungen der Terraform-Formatierung und -Validierung.

Custom Hooks können beim Erstellen eines Workspaces oder jederzeit danach hinzugefügt werden. Rufen Sie dazu die Workspace-Einstellungen auf und legen Sie fest, was vor und nach „plan“ sowie vor und nach „apply“ ausgeführt werden soll. Unten sehen Sie, wie Sie Custom Hooks einrichten:

Unter den „Advanced“-Optionen auf der Seite „Settings“ können Nutzer in Scalr den relativen Pfad auswählen, in dem Terraform-Befehle ausgeführt werden (für dieses Beispiel habe ich das Verzeichnis s3/ ausgewählt). Deshalb steht vor dem Skriptpfad “./../”.

Sicherheits-Scans auf dem Weg des geringsten Widerstands automatisieren

Der Weg des geringsten Widerstands in die Cloud führt Anfänger wie Experten zu Terraform-Code, den sie im Internet finden oder von Kollegen und Teams erhalten – oft in der Annahme, dass dieser sicher und compliant ist. Solcher Code besteht möglicherweise alle verfügbaren Formatierungs-, Linting- und Validierungsprüfungen, kann Nutzer aber dennoch potenziell verheerenden Schwachstellen aussetzen.

Verborgene Schwachstellen aufdecken: Infrastruktur mit Regula scannen

Für diese Demo bin ich bewusst den Weg des geringsten Widerstands gegangen und habe nach Terraform-Code gesucht, mit dem ich möglichst schnell einen S3-Bucket bereitstellen kann. Zunächst zeige ich Ihnen, wie anfällig dieser Terraform-Code ist, indem ich in diesem Repository lokal regula run ausführe:

Wenn Sie diesen Befehl ausführen, wird Regula:

• automatisch unterstützte IaC-Dateien im gesamten Repository erkennen

• alle erkannten und unterstützten IaC-Dateien auf Sicherheit und Compliance prüfen

• die Scan-Ergebnisse nach absteigendem Schweregrad ausgeben, einschließlich folgender Angaben:

  • Fugue-Regel-ID (z. B. FG_R00099) und Titel

  • Schweregrad der Regel (z. B. [High])

  • Link zu den Schritten zur Behebung des Regelverstoßes (z. B. https://docs.fugue.co/FG_R00099.html)

  • Fundstelle des Regelverstoßes in der IaC-Datei

Die obigen Scan-Ergebnisse sollten DevOps- und Security-Engineers gleichermaßen beunruhigen. Wenn wir anfälligen Code kopieren, einfügen und bereitstellen, setzen wir uns Hackern aus, die solche Schwachstellen automatisiert aufspüren und ausnutzen. Außerdem habe ich diesen Scan freiwillig durchgeführt, ohne ihn in eine Pipeline wie die von Scalr zu integrieren – nicht gerade der Weg des geringsten Widerstands! Frühere Sicherheitsvorfälle zeigen: Cloud-Hacker finden Schwachstellen mithilfe von Automatisierung und nutzen sie anschließend als Einstiegspunkt, etwa einen anfälligen S3-Bucket, um die Infrastruktur und Daten anzugreifen, die am dringendsten geschützt werden müssen. Wenn wir Ressourcen nicht ebenfalls automatisiert korrekt konfigurieren, bevor sie in die Cloud gelangen, ist ein solcher Angriff nur eine Frage der Zeit.

Sehen wir uns diese Regelverstöße genauer an und betrachten einen Codeausschnitt. (Wenn Sie mitmachen: Der folgende Code stammt aus den Zeilen 18–26 von s3/bucket.tf. Für bessere Lesbarkeit habe ich die Einrückung nach links angepasst.)

18server_side_encryption_configuration {
19  rule {
20    apply_server_side_encryption_by_default {
21      #Un-comment below to satisfy FG_R00099
22      #kms_master_key_id = aws_kms_key.mykey.arn
23      #sse_algorithm     = "aws:kms"
24    }
25  }
26}

Ich habe die bewusst eingebauten Schwachstellen im Code mit Kommentaren versehen, die Hinweise darauf geben, wie Sie den Code an die standardmäßig in Regula enthaltenen nummerierten Regeln anpassen können. In seiner aktuellen Form verstößt der obige Code gegen Regel FG_R00099 (ein Verstoß mit hohem Schweregrad gemäß den CIS-Benchmarks): Wird dieser AWS Simple Storage Service (S3)-Bucket ohne entsprechende Korrektur bereitgestellt, sind ruhende Daten darin ungeschützt. Für Einsteiger lässt sich das mit einem offenen Banktresor und einem unverschlossenen Schließfach vergleichen. Selbst wenn Sie Ihre Einzahlung mit einem Geldtransporter bringen (in dieser Analogie: Verschlüsselung während der Übertragung), wäre dieser Aufwand für die Datensicherheit vergeblich, wenn Sie Tresor und Schließfach nicht abschließen (also keine serverseitige Verschlüsselung aktivieren).

Das Beunruhigende an diesem Beispiel: Die Terraform-Dokumentation, aus der ich den Code übernommen habe, zeigt, wie sich ein S3-Bucket möglichst einfach bereitstellen lässt – wie es bei Dokumentation oft der Fall ist. Dabei stehen Beispiele für erforderliche Parameter im Vordergrund, während optionale Parameter (darunter die serverseitige Verschlüsselung!) in späteren, leicht zu übersehenden Abschnitten behandelt werden. Schließlich sind Sie für die Konfiguration Ihrer Cloud-Ressourcen verantwortlich: Ihr Cloud-Provider stellt Ihnen lediglich die Mittel zur Verfügung, mit denen Sie Cloud-Infrastruktur sicher bereitstellen und nutzen können.

Warum die Sicherheit dem Zufall überlassen, wenn Sie sie so einfach automatisieren können?

Flexibilität in der Praxis: Regeln ausnehmen und deaktivieren

Kritische Geschäftsanforderungen stehen manchmal im Widerspruch zu Regeln mit niedrigem oder mittlerem Schweregrad. Ein Unternehmen, das Inhalte über einen S3-Bucket mit einer statischen Website bereitstellt, wird beispielsweise verständlicherweise ungern immer wieder darauf hingewiesen, dass der betreffende S3-Bucket gegen FG_R00229 verstößt (alle Optionen für „block public access“ müssen für S3-Buckets aktiviert sein). Regula-Nutzer können bestimmte Regeln für bestimmte Ressourcen ausnehmen oder bestimmte Regeln vollständig deaktivieren. Für diese Demo nehme ich für meinen Logging-Bucket FG_R00274 aus und deaktiviere die Fugue-Regel FG_R00275 vollständig mithilfe meiner Ausnahmedatei (waivers.rego). Unten sehen Sie, wie einfach Sie mit Regula Regeln ausnehmen und deaktivieren können:

package fugue.regula.config

waivers[waiver] {
  waiver := {
    #Waiving bucket logging (for the logging bucket)
    "rule_id": "FG_R00274",
    "resource_id": "module.s3.aws_s3_bucket.logbucket"
  }
}

rules[rule] {
  rule := {
    #Disabling cross region replication (budgetary purposes)
    "rule_id": "FG_R00275",
    "status": "DISABLED"
  }
}

IaC-Sicherheit in den Betrieb integrieren: Fehlkonfigurationen vom Weg in die Cloud abhalten

Sehen wir uns nun an, wie Regula mit Scalrs Terraform-Backend für Remote State und Vorgänge zusammenspielt, um zu verhindern, dass falsch konfigurierte Infrastruktur in der Cloud bereitgestellt wird.

Das erste Custom-Hook-Skript (security.bash) lädt die aktuelle Regula-Version herunter, entpackt sie, verschiebt sie und führt sie aus. Es scannt alle Terraform-Dateien (Pläne in der HashiCorp Configuration Language (HCL) oder im Terraform-JavaScript-Object-Notation-Format (JSON)) und gibt entweder einen Exit-Code ungleich null und eine Meldung aus, die den Scalr-Build anhält, oder einen Exit-Code von null, der die Fortsetzung des Scalr-Builds ermöglicht.

Das nächste Custom-Hook-Skript (validate.bash) stellt sicher, dass Terraform in diesem Repository gültig ist und dem kanonischen HCL-Format entspricht. Ist Terraform ungültig, gibt das Skript einen Exit-Code ungleich null aus. Ist Terraform gültig, führt Scalr den restlichen Build aus und startet automatisch terraform plan und terraform apply. Dadurch wird Ihre Infrastruktur in der Cloud bereitgestellt und der Terraform-Status in der einfach zu bedienenden Oberfläche verwaltet.

Einen Build ausprobieren – und scheitern

Als Nächstes zeige ich Ihnen, was passiert, wenn ich anfälligen Terraform-Code in mein GitHub-Repository committe. Dazu führe ich die folgenden Befehle aus (<files> ist ein Platzhalter für die Dateien, die in GitHub committet und gepusht werden sollen):

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

Scalr erkennt, dass ich Änderungen an meinem Repository committet habe, und verwendet die von mir bereitgestellten Skripte, um meinen Terraform-Code auf Sicherheits- und Compliance-Probleme zu prüfen:

Konfigurationsprobleme mit Regula beheben

Jetzt weiß ich, dass meine Terraform-Dateien Fehlkonfigurationen enthalten. Ich kann also zu meinem Repository in VSCode zurückkehren und lokal regula run ausführen, um die Probleme zu beheben. Alternativ kann ich auch die Ausgabe von regula run exportieren, die bei meinem Scalr-Lauf entstanden ist. Ich habe dieses Repository so eingerichtet, dass ich Korrekturen am Terraform-Code einfach einkommentieren kann. Ihre Infrastruktur korrekt zu konfigurieren, ist aber genauso einfach: Klicken Sie auf den Link, der nach jedem regula run für jede Regel angezeigt wird. Beachten Sie, dass die beiden Regeln, die ich behebe (FG_R00036 und FG_R00101), jeweils nur eine Codezeile betreffen. Diese Zeilen stammen direkt aus den Schritten zur Behebung des Regelverstoßes, die über den in der Befehlsausgabe angegebenen Link erreichbar sind. Entwicklerfreundlicher geht es kaum.

Einen Build ausprobieren – und erfolgreich sein!

Da meine Infrastruktur nun korrekt konfiguriert ist, commite ich erneut in mein GitHub-Repository, um Scalrs Terraform-Automatisierung optimal zu nutzen. Dabei werden wieder meine Custom-Hook-Skripte ausgeführt. Sind sie erfolgreich, führt Scalr anschließend terraform plan und terraform apply aus.

Zur Veranschaulichung führe ich die Befehle, die ich anfangs ausgeführt habe, erneut aus:

git add <files>
git commit -m "initiating the scalr terraform pipeline"
git push

...und der Build wird erfolgreich abgeschlossen!

Und das war’s schon! Dank Regula und Scalr haben wir jetzt eine Pipeline, mit der sich die Bereitstellung von Cloud-Infrastruktur mit Terraform sicher automatisieren lässt.

Nächste Schritte

Das obige Beispiel zeigt, wie Sie Ihre IaC gemäß den CIS-Benchmarks absichern. Wenn Sie jedoch andere Compliance-Standards benötigen (z. B. HIPAA, SOC2, ISO 27001, NIST 800-53, GDPR, PCI DSS, AWS WAF oder CSA), besuchen Sie bitte www.fugue.co. Das Beispiel zeigt außerdem benutzerdefinierte Hooks (eine kostenpflichtige Scalr-Funktion). Wenn Sie weitere Komfortfunktionen wie Kostenschätzungen für Cloud-Infrastruktur, selbst gehostete Agents, SSO oder Richtlinienvorschauen nutzen möchten, besuchen Sie bitte https://www.scalr.com/.

Möchten Sie mehr über Regula erfahren? Besuchen Sie unser GitHub-Repository und unsere Dokumentation. Regula prüft Terraform-HCL, Terraform-Plan-JSON, CloudFormation-YAML/JSON, Kubernetes-YAML-Manifeste und Azure-Resource-Manager-Vorlagen auf Sicherheits- und Compliance-Verstöße. Regula unterstützt außerdem Ausnahmeregelungen, benutzerdefinierte Regeln, das Aktivieren und Deaktivieren von Regeln und vieles mehr.

Interessieren Sie sich für weitere Möglichkeiten, die sichere Bereitstellung von Cloud-Infrastruktur zu automatisieren? Lesen Sie unseren Blogbeitrag zur Integration von Regula und Travis CI oder unseren Blogbeitrag zur Integration von Regula und Bitbucket Pipelines.