Inhalt
17In der Cloud-First-Welt ist Infrastructure-as-Code (IaC) ein wichtiger Bestandteil der Softwareentwicklung und -bereitstellung geworden. IaC ermöglicht es Entwicklungsteams, ihre Cloud-Infrastruktur auf wiederholbare, konsistente Weise zu verwalten. Wenn es um die Sicherheit geht, liegt der Schwerpunkt leider allzu oft auf der Anwendung selbst, während dem IaC-Code wenig Aufmerksamkeit geschenkt wird.
Unternehmen, die in einem modernen, auf die Cloud ausgerichteten Ökosystem sicher bleiben wollen, sollten ihre IaC-Konfigurationen als erstklassige Sicherheitsprobleme betrachten. Einfach ausgedrückt: IaC ist ein wichtiger Bestandteil der Sicherheit in Ihrer Infrastruktur.
In diesem Artikel befassen wir uns mit der Funktionsweise von Infrastructure-as-Code, mit einigen potenziellen Angriffsvektoren und damit, was Sie machen können, um Ihre Cloud-Umgebung zu sichern.
Infrastructure-as-Code: Eine Einführung
In der Vergangenheit wurde der Begriff „Infrastructure as Code“ verwendet, um eine Vielzahl verschiedener Implementierungsmöglichkeiten zu beschreiben. Tools wie CFEngine, Puppet und Chef sind den frühen Anwendern von IaC zweifellos bekannt. Das Konfigurationsmanagement bot eine einfache Handhabung bei der Verwaltung von Serverflotten in großem Umfang, wurde aber oft auf bereits bereitgestellte Infrastrukturen aufgesetzt.
Was versteht man darunter?
Moderne IaC-Lösungen wie Terraform und CloudFormation automatisieren die Konfiguration, Bereitstellung und Verwaltung der Infrastruktur von Anfang bis Ende. Benutzer von IaC erstellen Ressourcenkonfigurationen, um zu definieren, welche Infrastruktur sie für einen bestimmten Anbieter bereitstellen möchten. Diese Tools haben im Allgemeinen einige gemeinsame Merkmale:
- Eine domänenspezifische Sprache („domain-specific language“, DSL): Im Gegensatz zu allgemeinen Programmiersprachen wie Python handelt es sich bei DSLs um Sprachen, die in einem bestimmten Anwendungskontext verwendet werden. Eine DSL bietet in der Regel eine Art Binärprogramm oder Compiler, mit dem Sie eine Vielzahl von Befehlen ausführen können.
- Zustandsverwaltung: Um die Infrastruktur auf kohärente Weise zu verwalten, müssen IaC-Tools eine dauerhafte Zustandsdarstellung aufrechterhalten, in der Regel eine große Textdatei oder Datenbank, die eine vollständige Datenobjektdarstellung der aktuell verwalteten Ressourcen enthält.
- Schnittstelle oder Proxy für Anbieter-APIs: Eine der leistungsfähigsten Funktionen, die IaC bietet, ist die Abstraktion, die es zwischen Anbietern und Ressourcenkonfigurationen schafft. Benutzer von IaC-Tools wie Terraform müssen keine direkten API-Aufrufe zu GCP oder AWS implementieren, da die Provider-Logik über ein Plugin abgewickelt wird.
- Deklarativ: Das deklarative Paradigma dominiert nicht mehr die IaC-Landschaft. Neuere Tools bieten Entwicklern die Möglichkeit, mit imperativen Mustern zu schreiben.
Bei der Verwendung deklarativer Sprachen „deklarieren“ die Benutzer den gewünschten Endzustand der in der Konfiguration definierten Infrastruktur, und der Compiler entscheidet automatisch über den besten Weg, um diesen Zustand zu erreichen. Im Gegensatz dazu, ist bei imperativen Programmiermodellen der Benutzer für die Definition des Programmablaufs verantwortlich.
Mit Tools wie Pulumi und AWS CDK können Benutzer einfach eine Bibliothek in ihren Anwendungscode importieren und die Infrastruktur so bereitstellen, als würden sie eine Standardanwendung mit einer imperativen Sprache erstellen. Es ist wichtig zu beachten, dass sich die zugrundeliegende Logik auch bei Verwendung dieser imperativen Tools im Allgemeinen immer noch deklarativ verhält.
Anwendungsmuster
In kleineren und weniger komplexen Umgebungen wird IaC typischerweise von einem oder zwei Ingenieuren verwaltet, die von einzelnen Arbeitsplätzen aus arbeiten. Sie können einige Standardkonventionen der Skalierung anwenden, wie z.B. die gemeinsame Nutzung von Zuständen, aber der Umfang der Infrastruktur kann leicht von einem kleinen Team oder einer Einzelperson gehandhabt werden.
In der Größenordnung umfasst die IaC-Nutzung in der Regel mehrere Instanzen eines gemeinsamen Zustands, isolierte Arbeitsbereiche, mehrere Ingenieurteams im gesamten Unternehmen, die zur Konfiguration beitragen, und eine automatisierte Bereitstellung über CI/CD. Änderungen werden idealerweise auf mögliche Probleme hin analysiert, und das Testen gibt Rückmeldung über die möglichen Auswirkungen der vorgeschlagenen Änderungen.
Das Testen wirft auch ein Schlaglicht auf ein größeres Thema: Wenn die IaC-Nutzung innerhalb eines Unternehmens zunimmt, fallen immer mehr Systeme und Datenspeicher in seinen Verwaltungsbereich. Angesichts dieser weitreichenden Befugnis, Änderungen vorzunehmen, stellen IaC und die damit verbundenen Systeme ein sehr einladendes Ziel für Bedrohungsakteure dar.
Infrastructure-as-Code-Schwachstellen
Die Infrastruktur selbst war schon immer ein wichtiger Angriffsvektor für Cyberkriminelle. In der modernen Cloud-Ära ist die potenzielle Angriffsfläche für die digitale Architektur eines Unternehmens exponentiell gewachsen.
Infrastruktur-als-Code-Schwachstellen fallen in der Regel in einige gängige Kategorien und sind aufgrund des potenziellen Angriffsradius fast immer kritisch.
Offenlegung von Anmeldeinformationen/Geheimwerten
Wie jeder andere Code landet auch die IaC-Konfiguration wahrscheinlich in einer Art Versionskontrollsystem (VCS) wie Git. Die meisten Unternehmen nutzen eine VCS-Plattform eines Drittanbieters wie GitHub für die Speicherung ihrer Repositorys. Der öffentliche Charakter dieser Plattformen bedeutet, dass alle sensiblen Werte, die versehentlich in einen gepushten Commit einfließen, potenziell für die Öffentlichkeit zugänglich sind.
Mit einem IaC-Tool wie Terraform können Sie das AWS-Provider-Plugin mithilfe des folgenden Codeblocks konfigurieren:
# Configure the AWS Provider
provider „aws“ {
region = „us-east-1“
}
Obwohl dies harmlos erscheint, ist es auch möglich, es mit fest kodierten Anmeldeinformationen zu konfigurieren:
# Configure the AWS Provider
provider „aws“ {
region = „us-east-1“
access_key = „my-access-key“
secret_key = „my-secret-key“
}
Würden diese Werte eingegeben und die Konfiguration in ein entferntes Repository übertragen, wäre sie für jeden zugänglich, der Zugriff darauf hat. Dies ist besonders gefährlich, wenn man bedenkt, dass diesen Identitäten in der Regel weitreichende Berechtigungen zugewiesen werden.
AWS CDK bietet mit seiner Klasse „Credentials“ ein weiteres Beispiel. Sensible Werte werden in der Regel mit der SecretsManager-API gehandhabt, aber es ist durchaus möglich, dass ein Entwickler einen sensiblen Wert mit dieser statischen Methode fest kodiert. Obwohl es offensichtlich scheint, dass dies nicht getan werden sollte, kommt es häufig zu dieser Art der Offenlegung von Geheimnissen, wenn ein Test- oder Entwicklungsmodell nie vollständig auf eine produktionsreife Implementierung portiert wurde.
Die meisten IaC-Tools verfügen über Funktionen, mit denen Benutzer sensible Werte explizit definieren können, damit sie nicht in Protokollen oder anderen Ausgaben erscheinen. Diese Werte werden jedoch oft im Status als Klartext beibehalten. Wenn geheime Werte in etwas wie Vault mit Terraform bereitgestellt werden, wächst der Umfang der Kontrolle über diese Geheimnisse über Vault selbst hinaus.
Fehlkonfiguration
Eine Fehlkonfiguration der Infrastruktur kann im Allgemeinen zwei unterschiedliche, aber negative Folgen haben. Die erste ist, dass die Sicherheitskonfiguration einer bestimmten Ressource unerwartet in eine weniger sichere Haltung geändert werden kann. Ein klassisches Beispiel sind Amazon S3-Buckets, bei denen sensible Daten so konfiguriert sind, dass sie für die Öffentlichkeit zugänglich sind.
Die zweite Art von Fehlkonfiguration ist oft das Ergebnis von Umgebungen, in denen es wenig oder gar keine Änderungsverwaltung oder Testverfahren gibt.
Eine fehlerhafte Konfiguration kann zu Ausfällen führen und kundenorientierte Dienste beeinträchtigen.
Berechtigungen mit erweiterten Rechten
Wie im vorangegangenen Abschnitt über die Offenlegung von Anmeldeinformationen angedeutet, ist der Zugriff mit erweiterten Berechtigungen ein ernsthaftes Problem für IaC-Tools. Bei der IaC-Automatisierung werden häufig Identitätsrollen mit sehr hohen Berechtigungen innerhalb eines bestimmten Anbieters übernommen, um die Infrastruktur bereitzustellen. Wenn diese Identitäten durch eine Offenlegung von Anmeldeinformationen kompromittiert werden, haben Angreifer potenziell unbegrenzten Zugriff auf wichtige Daten und Systeme.
CI/CD-Infrastruktur
CI/CD-Systeme (Continuous Integration/Continuous Delivery) sind die zentrale Säule von DevOps und der Bereitstellungsautomatisierung. Sie sind oft der Mechanismus, über den IaC-Änderungen in größeren Unternehmen in großem Umfang erfolgen.
Die Architektur von CI/CD-Pipelines ist oft komplex und umfasst mehrere Knoten, APIs und eine Art integrierte Benutzeroberfläche. Mehr Komplexität bedeutet mehr potenzielle Angriffsvektoren. Die breitere Anerkennung der Bedrohungen, die von unsicheren CI/CD-Systemen ausgehen, hat dazu geführt, dass ein Ökosystem von Sicherheitswerkzeugen und Schulungen entstanden ist.
Absicherung von Infrastructure-as-Code
Um eine starke Sicherheitslage aufrechtzuerhalten, müssen Softwareunternehmen bei IaC die gleichen sicheren Entwicklungspraktiken anwenden wie bei der normalen Softwareentwicklung. Das Risiko, das von laxen IaC-Sicherheitspraktiken ausgeht, ist einfach zu groß.
Zusätzlich zu seiner ausgezeichneten Bibliothek von Sicherheitsreferenzen hat OWASP ein Spickzettel für die Sicherung von Infrastruktur als Code hinzugefügt. Glücklicherweise gibt es einige Abhilfemaßnahmen und Praktiken, die dazu beitragen, das Risiko der Ausnutzung von IaC-Schwachstellen erheblich zu verringern.
Statische Analysewerkzeuge verwenden
Tools zur statischen Analyse oder statischen Anwendungssicherheitsprüfung (SAST) werden in der Regel eingesetzt, um den Quellcode auf potenzielle Schwachstellen zu analysieren. Im Falle von IaC-Tools können Sie eine bestimmte Untergruppe von SAST-Tools verwenden, um potenziell sensible Werte zu identifizieren, die im Quellcode vorhanden sein können. Tools wie TruffleHog scannen proaktiv bestehende Repositories und können sogar mit Pre-Commit-Hooks integriert werden, um sicherzustellen, dass Geheimnisse niemals in lokale oder entfernte Git-Protokolle gelangen.
Nutzen Sie einen Policy-Engine
Policy-Engines und richtlinienbasierte Kontrollen wie OPA ermöglichen es Administratoren, präzise, deklarative Richtlinien für eine Vielzahl von System- und Infrastrukturkomponenten zu definieren. Mithilfe einer DSL können Sie diese Richtlinien definieren, um zu verhindern, dass Sicherheitsfehlkonfigurationen oder potenziell destruktive Änderungen jemals auf die aktive Infrastruktur angewendet werden. Richtlinien können lokal über Git-Hooks oder im großen Maßstab über eine API-Sicherheitsbereitstellung der Policy Engine durchgesetzt werden.
Protokollierung kritischer Identitätsaktivitäten
Wie bereits erwähnt, verfügt die Identität, die eine IaC-Automatisierung annimmt, oft über einen sehr weitreichenden und freizügigen Zugang zu einer Vielzahl von Anbieter-APIs. Aus diesem Grund ist es wichtig, die API-Aufrufe und das Verhalten der Identität jederzeit genau zu überwachen.
Die meisten Anbieter bieten Benutzern Zugriff auf verschiedene Protokollierungsmechanismen, einschließlich Protokollen der API-Aufrufe, die von verschiedenen Identitäten im Konto getätigt werden. AWS CloudTrail ist ein solches Tool. Diese Protokolle können in eine SIEM-Lösung eines Drittanbieters gestreamt werden, mit der Sie dann die Protokolle auf verdächtiges Verhalten analysieren und die Sicherheitsteams benachrichtigen können, wenn etwas entdeckt wird.
Sichern Sie Ihre CI/CD-Pipeline
CI/CD-Systeme unterscheiden sich nicht von anderen Infrastrukturen und sollten denselben strengen Sicherheitsanforderungen unterliegen wie Anwendungshosts. Die selbst gehostete CI/CD-Architektur sollte in einem eigenen isolierten Netzwerksegment untergebracht werden, wobei rollenbasierte Zugriffskontrollen („Role Based Access Control“, RBAC) durchgängig durchgesetzt werden. Sie sollten die Protokolle für diese Systeme genau auf verdächtiges oder unerwartetes Verhalten überwachen. Die aktive Überwachung der CVE-Liste kann dabei helfen, potenzielle Komponenten oder Systeme zu identifizieren, die ebenfalls eine Schwachstelle aufweisen könnten.
CI/CD bringt auch einzigartige Sicherheitsherausforderungen mit sich, wie z. B. die Möglichkeit, Build-Artefakte versehentlich preiszugeben. Die großen Cloud-Anbieter bieten alle Tools an, die dabei helfen; wir haben sie in einem früheren Artikel über die Sicherung von CI/CD-Pipelines in der Cloud vorgestellt.
Sicherheit ist für Infrastructure-as-Code von entscheidender Bedeutung
Die automatische Entschärfung potenzieller Infrastrukturschwachstellen ist ein wichtiger Bestandteil der Verlagerung der Sicherheit in den SDLC.
Infrastructure-as-Code erleichtert die Verwaltung der Cloud-Infrastruktur in großem Umfang. Allerdings bringt sie auch zusätzliche Sicherheitsherausforderungen mit sich. Unternehmen müssen diese Herausforderungen durch eine Kombination aus Tools, Prozessen und Schulungen angehen. Mit den richtigen Sicherheitsmaßnahmen für die Cloud können Sie Ihr Sicherheitsrisiko erheblich verringern.
Anstatt sie als nachträgliche Maßnahme zu behandeln, müssen Unternehmen den Code ihrer Infrastruktur mit der gleichen Strenge und Sorgfalt sichern wie den Code ihrer Anwendungen.
Share this post
