Deep Dive: Infrastruktur-Drift und Drift-Erkennung

Erwartungen und Realität liegen bekanntlich oftmals weit auseinander. So auch in punkto Infrastructure as Code (IaC). Denn mit der Provisionierung Ihrer Infrastruktur via IaC haben Sie zwar einen wichtigen Schritt auf dem Weg zu mehr Cloud-Sicherheit gemacht. Doch das Infrastruktur-Lifecycle geht noch weiter – entscheidend ist nämlich die Frage, wie Sie feststellen, welche Ihrer Cloud-Ressourcen noch außerhalb Ihrer IaC-Kontrolle liegen. Außerdem: Bleiben all jene Ressourcen, die Sie damit bereits abdecken, auch dauerhaft so konfiguriert wie ursprünglich im Code definiert?

Cloud-Workloads sind höchst dynamisch und somit laufend Änderungen unterworfen. Und je mehr Workloads Sie in die Cloud überführen, desto größer wird die Zahl der Entwickler und authentifizierten Services, die über verschiedene Umgebungen hinweg mit der zugrunde liegenden Infrastruktur interagieren. So wird es im Zuge der Ausweitung Ihrer IaC-Nutzung und zugehörigen Codebase zunehmend schwieriger, Änderungen im Blick zu behalten und sicherzustellen, dass manuelle Konfigurationsänderungen nicht durchs Raster fallen. Umso wichtiger ist es daher, diese Veränderungen mittels Drift-Erkennung ausmachen zu können, damit automatisierte Cloud-Deployments auch in der Live-Umgebung sicher bleiben.

Worum es sich bei Infrastruktur-Drift genau handelt, worin seine Ursachen liegen und wie Sie das Problem als einzelner Entwickler wie auch unternehmensweit in den Griff bekommen, beleuchten wir im Folgenden. Weitere Details zur Erfassung und Prävention von Infrastruktur-Drift lesen Sie in diesem Artikel.

Was ist Infrastruktur-Drift?

Infrastruktur-Drift (im Folgenden auch einfach „Drift“ genannt) tritt auf, wenn die Infrastruktur in der Live-Umgebung von dem abweicht, was eigentlich via IaC definiert wurde. Entsprechend besteht also eine Divergenz zwischen Status quo von Cloud-Ressourcen und ihrer Definition im Code, wobei die Ursachen hierfür vielfältig gelagert sind.

Mittels IaC lassen sich entsprechende Drift-Instanzen so gering wie möglich halten – dies umso mehr, je größer die IaC-Abdeckung von Cloud-Ressourcen ist. Denn die für sie vorgesehene Konfiguration wird bereits vor dem Deployment definiert. Dabei werden auch Security Best Practices direkt umsetzbar. Zu Änderungen ihrer Konfiguration in der Cloud-Konsole kommt es daher zumeist nur, wenn Notfälle sie ad hoc nötig machen. Oder, was womöglich häufiger der Fall ist, aufgrund von Humanfehlern.

So reichen die Ursachen für Drift von Benutzereingaben und mangelhaften Konfigurationen bis hin zu unerwünschten Änderungen durch Anwendungen. Diese wiederum sind häufig auf Prozess- oder Workflow-Probleme zurückzuführen, bei denen manuelle Änderungen in der Cloud-Konsole nicht als Code transponiert oder Änderungen an einer einzelnen Umgebung nicht in andere übernommen wurden.

Zu den häufigsten Ursachen für Infrastruktur-Drift gehören:

1. Manuelle Änderungen: Manuelle Einrichtung oder Modifikation von Ressourcen außerhalb von Terraform, CloudFormation oder einem anderen für IaC genutzten Tool

2. Authentifizierte Anwendungen: Nicht vorgesehenes Verhalten von Microservices

3. Nicht synchronisierte IaC-Umgebungen: Versteckte oder übersehene Änderungen, die nicht über alle Umgebungen hinweg übernommen wurden

Was ist Drift-Erkennung?

Im Kern geht es bei Drift-Erkennung darum, via IaC verwaltete Cloud-Infrastruktur fortlaufend auf Konfigurationsabweichungen zu überwachen, insbesondere im Hinblick auf solche, die mit Sicherheitsrisiken für Ihr Unternehmen einhergehen. Idealerweise sollten hierfür verwendete Scanning-Tools die Ergebnisse in entwicklerfreundlicher Weise aufbereiten (z. B. durch Ausgabe einer Terraform-Ressource in ihrem nativen Format). So können Entwickler erkannte Probleme direkt nachvollziehen und schnell im Infrastruktur-Deployment beheben.

Auch markiert Drift-Erkennung gewissermaßen die zweite Phase im Komplex der IaC-Sicherheit: Nachdem innerhalb von Dev- und Build-Pipelines Fehlkonfigurationen behoben und andere Sicherheitskontrollen implementiert wurden, bildet sie die Security-Instanz, die an der Produktionsumgebung ansetzt.

„Jede Konfigurationsabweichung, jeder Drift, hinterlässt Unsicherheit, Arbeitsaufwand und natürlich eine potenzielle Sicherheitslücke.“

DevOps-Experte

Drift-Erkennung ist gerade deshalb so wichtig, weil die Sicherheit Ihrer Infrastruktur ganz entscheidend von dem abhängt, was Sie in Ihren Cloud-Umgebungen ausrollen und ausführen. Allzu oft wird IaC-gestützte Infrastruktur-Automatisierung automatisch mit Sicherheit gleichgesetzt. Doch ist dem eben nicht so, wie die bereits genannten Ursachen zeigen. Genau deshalb braucht es Drift-Erkennung, um mit der Automatisierung von Ressourcen Schritt halten und Sicherheit von der IaC-Definition bis zum Cloud-Deployment in der gesamten Infrastruktur durchgängig gewährleisten zu können.

Konsequenzen von vernachlässigtem Drift-Management

Selbst mit einem simplen IAM-Schlüssel oder SDK können Entwickler bei unachtsamer Verwendung bereits erheblichen Schaden anrichten. Umso wichtiger ist es daher, Fehlentscheidungen im Infrastrukturkontext schnell erkennen und beheben

und so Sicherheitsproblemen infolge von Infrastruktur-Drift wie z. B. den folgenden vorbeugen zu können:

• Datenpannen durch ungewollt zugänglich gemachte Bestände sensibler Daten

• Anwendungs-Downtime aufgrund von Abstürzen durch abweichende Konfigurationen

• Deployment-Fehler mit der Folge, dass die Ressource nicht ausführbar ist

Vermeiden lassen sich Drift und damit verbundene Probleme wie diese, indem ein möglichst größer Anteil der Infrastruktur via IaC verwaltet wird. Beziehungsweise lassen sich entsprechende Probleme dann schneller beheben als bei Infrastruktur, die nicht via IaC definiert ist. Denn im Unterschied zu Deployments, die via IaC automatisiert wurden, sind manuell konfigurierte und somit nicht verwaltete Ressourcen zeitintensiver in der Einrichtung und anfälliger für Fehler. IaC standardisiert dagegen ihre Einrichtung, reduziert also auch das Risiko, dass sich dabei Probleme wie fehlende Security-Gruppenregeln oder IAM-Policies einschleichen oder etwa Abhängigkeiten gelöscht werden.

Auch lassen sich Datenpannen durch eine durchgängige IaC-Abdeckung besser vorbeugen, da Sicherheitskontrollen standardisiert werden und sich Probleme wie etwa die ungewollt öffentlich zugänglich gemachten S3-Buckets leicht beheben lassen. Downtime wiederum kann effektiv adressiert werden, da sich die betroffenen Infrastruktur-Ressourcen effizienter aufspüren und schnell durch eine Version von vor dem Incident ersetzen lassen, die stabil läuft.

Drift-Erkennung vs. Drift-Management

Drift-Management ist eine Methodik, die das Risiko von Konfigurationsabweichungen ganzheitlich angeht, indem sie über die Drift-Erkennung hinaus auch eine schnelle Behebung erkannter Abweichungen in verwalteten Ressourcen möglich macht. Zugleich beinhaltet sie die Erkennung nicht verwalteter Ressourcen, damit diese schnell unter IaC-Kontrolle gebracht werden können.

Ziel ist dabei der Idealzustand von 100 % IaC-Abdeckung, umgesetzt von Security- und Dev-Teams in einem Workflow, der sich in etwa so gestaltet: Bei Erkennung einer nicht verwalteten Ressource wird diese als Code importiert, getestet und in eine stabile und sichere Konfiguration im Einklang mit den für das Unternehmen definierten Best Practices für IaC-Sicherheit und Compliance-Policies überführt.

Sichere, konsistent synchronisierte Infrastruktur durch Code

Ein strategischer Fahrplan für umfassende Sicherheit im IaC-Kontext beinhaltet folgende Schritte:

1. Zunächst gilt es, die IaC-Abdeckung Ihrer Cloud-Ressourcen auszuweiten. Dies über alle Cloud-Umgebungen hinweg.

2. Hierzu implementieren Sie ein Tool für IaC-Sicherheit, das die Erkennung und Behebung von Konfigurationsfehlern direkt im Dev-Prozess sowie in Build-Pipelines möglich macht. Zur zusätzlichen Absicherung geht die Konfiguration dann noch durch finale Security-Reviews.

3. Über Ihr IaC-Tool, z. B. Terraform oder AWS CloudFormation, gewährleisten Sie die Erkennung synchronisierter Infrastruktur.

4. Zur Drift-Erkennung implementieren Sie ein Open-Source-Tool wie driftctl. Dev-Teams können damit Konfigurationsabweichungen in Produktionsumgebungen aufdecken und erhalten die Ergebnisse in einem entwicklerfreundlichen Report.

5. Die Ergebnisse aus driftctl überführen Ihre Entwickler dann in Code und importieren diesen in Ihr IaC-Tool (z. B. Terraform).

6. Im letzten Schritt unterziehen Sie die so eingerichteten Konfigurationen noch einem Security-Check anhand Ihres Tools für IaC-Sicherheit. (Mit Snyk erfolgt dies über snyk iac test.)

7. Nach dem gleichen Prozedere erhöhen Sie die Abdeckung nun sukzessive für weitere Cloud-Ressourcen, dies etwa nach Region.

8. Ergänzend dazu richten Sie außerdem so viele Drift-Scans wie nötig ein. So etwa Checks auf IAM-Änderungen einmal pro Stunde sowie im Tagesturnus durchgeführte Prüfungen für weniger kritische Cloud-Services.

Tooling-Fragen im Kontext der Drift-Mitigierung

Angesichts der großen Zahl an Tools, die heute für Drift-Erkennung und -Management zur Verfügung stehen, sollten Sei bei Ihrer Wahl eine Reihe von Kriterien berücksichtigen.

Hierbei wichtig ist insbesondere die Frage nach dem Umfang des Zugriffs, den das jeweilige Tool auf Ihre Ressourcen erhält (z. B. uneingeschränkt, nur Lesezugriff oder nach dem Prinzip der geringsten Rechte). Tools wie Terraform etwa erfordern umfassenden Zugriff mit Authentifizierung, andere kommen bereits mit Lesezugriff aus. Das oben bereits erwähnte driftctl wiederum benötigt zur Drift-Erkennung nur das minimal erforderliche Maß an Zugriffsrechten.

Drift-Management mit Snyk IaC

Die Abdeckung nicht verwalteter Ressourcen ebenso wie die Erkennung von Infrastruktur-Drift in verwalteten Ressourcen vereint Snyk IaC in einer umfassenden Methodik für Drift-Management, mit der Ihre Entwickler Probleme rund um Konfigurationsabweichungen effektiver angehen. Hierzu erhalten sie entsprechende Scan-Reports nicht nur direkt in Ihrer Umgebung, sondern auch für sie intuitiv aufbereitet. Ein effizienter Feedback-Loop zwischen den Dev- und Cloud-Security-Teams sorgt dabei dafür, dass Entwickler Terraform-Ressourcen vom Code bis in die Cloud eigenständig absichern und auch nach dem Deployment für die Sicherheit von Infrastruktur-Konfigurationen sorgen können. Ebenso effektiv führen Sie nicht verwaltete Ressourcen mit dem Toolset zutage und bringen sie unter IaC-Kontrolle, minimieren so das Risiko von Drift direkt vom ersten Moment an.