Die 5 größten Sicherheitsrisiken bei Infrastructure as Code

Infrastructure as Code (IaC) hat verändert, wie wir unsere Cloud-Infrastruktur bereitstellen und verwalten. Statt Server und Netzwerke manuell mit einem großen Betriebsteam konfigurieren zu müssen, können wir unsere Service-Architektur jetzt als Code definieren. Mit IaC können wir die Bereitstellung der Infrastruktur automatisieren, unsere gesamte Serverflotte skalieren, Änderungen an unserer Architektur dokumentieren und inkrementelle Änderungen am Netzwerk testen. Kein Wunder, dass IaC für Teams und Unternehmen zum wichtigsten Weg geworden ist, ihre Cloud-Services einzurichten und zu verwalten.

IaC bietet zwar viele Vorteile, ist aber nicht frei von Sicherheitsrisiken. Sehen wir uns die fünf größten Sicherheitsrisiken bei IaC und die Best Practices an, mit denen wir sie eindämmen können.

1. Fehlkonfigurationen in IaC-Vorlagen

Eines der größten Sicherheitsrisiken bei IaC sind Fehlkonfigurationen in Vorlagen. IaC-Vorlagencode und Abhängigkeiten können Fehler enthalten, die die Infrastruktur unbeabsichtigt gefährden oder versierten Angreifern Möglichkeiten bieten, das System auszunutzen.

Nehmen wir an, eine IaC-Vorlage enthält versehentlich fest codierte Anmeldedaten mit Benutzername und Passwort für eine Datenbank mit sensiblen Benutzerdaten, etwa Finanzdaten oder personenbezogenen Daten (PII). Ein Angreifer, der sich unbefugten Zugriff auf diese Vorlage verschafft, könnte die Daten einsehen und die Datenbank manipulieren.

Stellen Sie sich ebenso eine IaC-Vorlage mit einer fest codierten IP-Adresse für einen kritischen Server vor. Der Server könnte Ziel eines Denial-of-Service-Angriffs (DoS) werden, und es könnte schwierig sein, schnell zu reagieren und die Infrastruktur zu aktualisieren. Parametrisierte Eingaben oder Umgebungsvariablen sind unverzichtbar, um Anmeldedaten und sensible Informationen vom Vorlagencode zu trennen.

Ein weiteres Beispiel ist die Verwendung veralteter oder abgekündigter IaC-Frameworks und anderer Abhängigkeiten von Drittanbietern. Angreifer können neue Schwachstellen in älteren Codeversionen entdecken und dadurch bislang unbekannte Fehlkonfigurationen ausnutzen. Das Risiko steigt zusätzlich, wenn dieselben IaC-Vorlagen in verschiedenen Umgebungen eingesetzt werden, da eine einzelne Fehlkonfiguration dann weit größere Auswirkungen haben kann. Es ist wichtig, den Code regelmäßig zu warten und zu aktualisieren und Abhängigkeiten von Drittanbietern sorgfältig zu prüfen, damit sie auf dem neuesten Stand sind.

Um IaC-Vorlagen zusätzlich abzusichern, sollten wir sichere Programmierpraktiken umsetzen. Dazu gehört, robusten IaC-Code zu schreiben, der Eingaben und Parameter in Funktionen validiert, sowie Test-Frameworks und Versionsverwaltung einzusetzen, um Codeänderungen zu prüfen und nachzuverfolgen und Fehler schnell zu beheben. Außerdem sollten wir überprüfen, ob die Vorlage bei der Bereitstellung und beim Abbau korrekt funktioniert, um unerwartete Kosten durch nicht ordnungsgemäß entfernte Services zu vermeiden.

2. Unsichere Speicherung und Übertragung von Secrets

Die Verwaltung von Secrets ist ein weiteres kritisches Sicherheitsrisiko bei IaC. Passwörter und API-Schlüssel stellen eine Gefahr dar, wenn sie offengelegt werden. Angreifer können andere sensible Informationen wie Webhook-URLs oder IP-Adressen missbrauchen, um Ressourcen mit Spam zu überlasten oder lahmzulegen und so einen Service oder ein Netzwerk außer Betrieb zu setzen.

Schon Lesezugriff auf eine IaC-Vorlage kann Angreifern wertvolle Einblicke in die Infrastruktur verschaffen und ihnen helfen, mögliche Fehlkonfigurationen zu erkennen. Dadurch lassen sich gezielte Angriffe leichter planen und durchführen.

Zum Glück ermöglichen IaC-Frameworks und Cloud-Plattformen, diese Secrets sicher zu speichern und zu verwenden. Terraform Cloud bietet beispielsweise eine Funktion für die Verwaltung von Secrets, mit der sichergestellt wird, dass diese sensiblen Werte ordnungsgemäß verschlüsselt und gespeichert werden. Cloud-Services stellen Secrets wie Zugriffsschlüssel und Datenbankverbindungszeichenfolgen häufig automatisch als Umgebungsvariablen bereit, sodass wir sie bei der lokalen Entwicklung mit eigenen Werten überschreiben können.

3. Fehlkonfigurierte Zugriffskontrollrichtlinien und Configuration Drift

Die OWASP Top 10, ein weltweit anerkanntes Dokument zur Sicherheit von Webanwendungen, stuft unzureichende Zugriffskontrollen und Fehlkonfigurationen in der Cloud als erhebliche Risiken ein.

Hacker können zu weit gefasste Zugriffsrichtlinien für Ressourcen wie Server und Cloud-Speicher ausnutzen, um Angriffe durchzuführen oder private Informationen abzurufen. Fehlkonfigurierte AWS-S3-Buckets waren für die Offenlegung sensibler Daten wie Anmeldedaten, PII und Kreditkarteninformationen verantwortlich.

Angreifer können Fehlkonfigurationen ausnutzen, etwa offene Netzwerkports, uneingeschränkte Ratenbegrenzungen oder unverschlüsselte Daten bei der Übertragung oder Speicherung. So können sie sich unbefugten Zugriff verschaffen, sensible Daten stehlen oder Services stören.

Fehlkonfigurationen können sich im Laufe der Zeit auch unauffällig durch Configuration Drift entwickeln. Sie entsteht, wenn Änderungen an der Infrastruktur nicht dokumentiert oder ordnungsgemäß verwaltet werden. Beispielsweise können Sie Systempatches einspielen, ohne die Änderungen festzuhalten. Oder Entwickler melden sich an, um Probleme zu untersuchen, nehmen manuelle Änderungen vor und vergessen, diese rückgängig zu machen. Dadurch wird es schwieriger, potenzielle Risiken außerhalb des IaC-Vorlagenumfangs zu erkennen und zu beheben, sodass das System Bedrohungen ausgesetzt bleibt.

IaC-Vorlagen helfen durch Automatisierung und Versionsverwaltung, einige dieser Risiken einzudämmen, lösen aber nicht alle Probleme. Es ist frustrierend, lange auf die Bereitstellung einer IaC-Vorlage zu warten und dann festzustellen, dass sie aufgrund eines Berechtigungsfehlers fehlgeschlagen ist. Da kann es verlockend sein, das Problem mit einer Richtlinie für Vollzugriff zu beheben. Diese Abkürzung führt jedoch zu vermeidbaren Fehlkonfigurationen.

Um angemessene Zugriffskontrollen sicherzustellen, sollten Sie stets das Prinzip der geringsten Berechtigungen (PoLP) befolgen und Berechtigungen so weit wie möglich einschränken. Gewähren Sie Zugriff nur bei Bedarf und verwenden Sie streng definierte Kontrollrichtlinien, automatisch rotierende Schlüssel und temporäre Zugriffsrollen.

Sicherheitsprüfungstools wie Snyk Infrastructure as Code und Snyk Container können ebenfalls dabei helfen, die Infrastruktur zu scannen und zu überwachen. Sie automatisieren diesen Prozess und erleichtern die Aufrechterhaltung sicherer Konfigurationen und Zugriffsrichtlinien.

4. Unsichere Statusdateien

Da die meisten IaC-Frameworks Statusdateien erstellen, um den aktuellen Zustand der bereitgestellten Infrastruktur festzuhalten, müssen diese Dateien sicher und mit dem tatsächlichen Zustand der Cloud synchronisiert sein. Statusdateien im Klartext können detaillierte Informationen zur Sicherheit von Cloud-Ressourcen enthalten. Um diese Informationen zu schützen, müssen Sie die Statusdatei verschlüsseln und den Zugriff darauf absichern.

Geht diese Statusdatei verloren, haben wir keine Aufzeichnung mehr über den Zustand der Infrastruktur, die mit den IaC-Vorlagen bzw. dem IaC-Code bereitgestellt wurde. In diesem Fall müssten vorhandene Cloud-Ressourcen manuell wieder in die persistente Statusdatei importiert werden, damit die künftige IaC-Verwaltung nicht beeinträchtigt wird.

Wird IaC in einer automatisierten CI/CD-Pipeline verwaltet, kann der Verlust der Statusdatei zur Zerstörung oder Erstellung von Ressourcen führen und so Systemausfälle oder Datenverlust verursachen. Ebenso kann eine beschädigte oder nicht synchronisierte Statusdatei schnell für Chaos sorgen, wenn Ressourcen manuell zugeordnet und wieder zusammengefügt werden müssen.

Mit einigen einfachen Vorsichtsmaßnahmen können wir eine solche Situation vermeiden:

• Speichern Sie die Statusdatei remote in der Cloud, damit sie einfach geteilt und gesichert werden kann.

• Aktivieren Sie die Versionsverwaltung, um die Datei bei einer Beschädigung wiederherstellen zu können.

• Verwenden Sie eine Dateisperre, damit jeweils nur eine Person die Statusdatei bereitstellen und ändern kann.

• Verschlüsseln Sie die Datei bei der Speicherung, damit ein Angreifer sie selbst dann nicht entschlüsseln kann, wenn er Zugriff darauf erhält.

• Beschränken Sie den Benutzerzugriff auf die Statusdatei auf das Team. Selbst wenn Secrets sicher gespeichert und aus IaC-Vorlagen herausgehalten werden, können sie in Statusdateien im Klartext enthalten sein. Deshalb müssen diese Dateien unbedingt verschlüsselt und Zugriffe eingeschränkt werden, um eine Offenlegung von Secrets zu verhindern.

5. Fehlende Tests und Validierung

IaC-Vorlagen, die nicht gründlich getestet und validiert werden, können zu unsicheren Bereitstellungen oder Fehlkonfigurationen führen, die Angreifern ermöglichen, die Infrastruktur zu kompromittieren.

Wenn wir Tests und Validierung fest in unseren IaC-Entwicklungsworkflow integrieren, können wir Risiken frühzeitig erkennen, eindämmen und minimieren und unsere Infrastruktur proaktiv absichern.

Berücksichtigen Sie beim Testen und Validieren von IaC die folgenden Fragen:

• Wurde die IaC-Vorlage erfolgreich bereitgestellt?

• Entsprechen die Zugriffskontrollen und Konfigurationen dem Code?

• Sind Ressourcen korrekt zugeordnet und referenziert?

• Werden Serveraktivitäten ordnungsgemäß überwacht und protokolliert?

• Kann die Infrastruktur die erforderliche Auslastung bewältigen?

Für das Testen und Validieren von IaC gelten dieselben allgemeinen Grundsätze wie für jeden anderen Code. Führen Sie im Team einen Code-Review-Prozess ein. Testen Sie den Code in einer Staging-Umgebung, bevor Sie ihn in der Produktionsumgebung bereitstellen. Verwenden Sie Linting-Tools, um Syntax- und Formatierungsfehler zu erkennen, und schreiben Sie Unit-Tests – etwa zur Prüfung von Ressourcennamen oder Kennungen. Scannen Sie hochrangigen IaC-Code aus Tools wie Pulumi mit automatisierten Static-Application-Security-Testing- (SAST-) Tools wie Snyk Code.

Letztendlich lässt sich IaC am besten sicher entwickeln, testen und validieren, indem Sie Sicherheit in den Entwicklungsprozess integrieren. Eine Möglichkeit dafür ist Snyk Infrastructure as Code, ein spezialisiertes Tool zur Verbesserung des Testens und Validierens von IaC. Es lässt sich nahtlos in Entwicklungstools und Workflows integrieren und ermöglicht eine sichere IaC-Entwicklung in Echtzeit und auf kontinuierlicher Basis.

Snyk Infrastructure as Code scannt Code auf mögliche Fehlkonfigurationen und Richtlinienverstöße und liefert umsetzbare Erkenntnisse und Empfehlungen zur Behebung der gefundenen Probleme. Mit diesen Informationen können wir die Sicherheitslage unseres IaC insgesamt verbessern und sicherstellen, dass es den Vorgaben entspricht.

Fazit

In diesem Artikel haben wir fünf Sicherheitsrisiken bei der Verwendung von IaC untersucht. Außerdem haben wir Möglichkeiten kennengelernt, ihnen zu begegnen – etwa durch die Anwendung des Prinzips der geringsten Berechtigungen, sichere Programmierpraktiken und die Integration von Sicherheitstools in den Prozess.

Wie wichtig Best Practices für die Absicherung von IaC sind, lässt sich kaum überschätzen – insbesondere angesichts der möglichen Folgen unsicheren IaC. Wenn wir Risiken wie fest codierte Anmeldedaten, schlecht verwaltete Secrets und Configuration Drift ignorieren, setzen wir die Vorteile von IaC aufs Spiel und riskieren Datenschutzverletzungen, unbefugten Zugriff und die Störung kritischer Services.

Indem wir Sicherheit proaktiv in den IaC-Entwicklungsprozess integrieren und Best Practices anwenden, können wir Risiken wirksam eindämmen, unsere Infrastruktur schützen und unsere Unternehmen und Kunden absichern.