Drift in der Cloud-Infrastruktur: das Gute, das Schlechte und das Hässliche

Fehlkonfigurationen der Infrastruktur sind die häufigste Ursache für Datenschutzverletzungen in der Cloud. Ein wesentlicher Grund dafür ist Drift in der Infrastrukturkonfiguration – also eine Änderung, die nach der Bereitstellung in einer Cloud-Umgebung auftritt. Wenn Sie für die Sicherheit und Compliance von Cloud-Umgebungen verantwortlich sind, verbringen Sie wahrscheinlich viel Zeit damit, Drift-Ereignisse in der Infrastruktur zu analysieren und zu beheben.

Man kann leicht denken, dass jeder Drift schlecht oder unerwünscht ist. Und keine Frage: Einiges davon ist wirklich schlecht. Sogar hässlich! Doch manche Drift-Ereignisse sind gut und erwünscht. Wenn Sie die Unterschiede zwischen dem Guten, dem Schlechten und dem Hässlichen kennen – und wissen, wie Sie sie erkennen –, ersparen Sie sich und Ihrem Team viel Frust und unnötigen Aufwand.

Guter Drift: Warum wir die Cloud nutzen

Cloud-Infrastrukturen sind elastisch und skalierbar. Unsere Cloud-Umgebungen sollen sich dynamisch an den sekundengenauen Bedarf unserer Anwendungen anpassen – ohne menschliches Eingreifen. Die Zeiten von Kapazitätsplanung und vorab bereitgestellten Ressourcen im Rechenzentrum sind vorbei.

Nach der Bereitstellung gibt es viele erwünschte Änderungen an der Cloud-Infrastruktur. Cloud-Ressourcen wie AWS Autoscaling Groups und DynamoDB können auf Nutzung und Durchsatz reagieren und die Infrastruktur dynamisch an neue Anforderungen anpassen. Anwendungen können im Laufe ihrer Ausführung neue Ressourcen wie SQS Queues, SNS Topics oder S3 Buckets erstellen. ALBs, die mit einem Elastic Container Service oder AWS Fargate verbunden sind, führen Aktionen aus, durch die sich Infrastrukturkonfigurationen ändern.

Jeder Ansatz für Cloud-Sicherheit und Compliance muss solche „guten“ Änderungen berücksichtigen – insbesondere, wenn Sie Drift-Ereignisse automatisch beheben möchten. Schließlich soll Ihr Sicherheitstool keinen Automatisierungs-Wettstreit mit Ihrer Anwendung führen. Natürlich müssen Sie sicherstellen, dass solche „guten“ Änderungen auch wirklich gut sind. Das ist jedoch ein Thema für einen anderen Beitrag.

Schlechter Drift: Unsere App ist ausgefallen!

Konfigurationsdrift macht Ops- und Infrastrukturteams schon seit Langem zu schaffen und führt zu Anwendungsausfällen und fehlgeschlagenen Deployments. Sie tritt auf, wenn sich eine Produktionsumgebung auf irgendeine Weise ändert, ohne dass Ops davon weiß. Vielleicht wird eine Security-Group-Regel gelöscht oder eine IAM-Richtlinie entfernt. Ein einziger falscher Klick in der AWS Console kann eine ganze Anwendung lahmlegen. Dann beginnt eine hektische Fehlersuche. Die Nachbesprechung ist unangenehm.

Wenn Sie Glück haben, handelt es sich lediglich um ein fehlgeschlagenes Deployment und nicht um einen schwerwiegenden Ausfall. In jedem Fall bindet diese Art von schlechtem Drift wertvolle Engineering-Ressourcen. Und bei geschäftskritischen Anwendungen kann schlechter Drift zu Umsatzeinbußen oder einem Vertrauensverlust bei Kunden führen.

Hier können wirksame Ansätze für Cloud-Sicherheit App- und Ops-Teams spürbare Vorteile bringen. Sie mögen es nicht, wenn ihnen jemand den Boden unter den Füßen wegzieht – und das aus gutem Grund. Das Beheben schlechter Drift-Ereignisse trägt dazu bei, Ihre Umgebung zu schützen und die Einhaltung von Compliance-Richtlinien sicherzustellen. Außerdem lassen sich so ungeplante Ausfälle verhindern. Alle profitieren von einer einzigen verlässlichen Informationsquelle darüber, was in Cloud-Umgebungen ausgeführt wird.

Hässlicher Drift: Datenschutzverletzung!

Die letzte Kategorie von Drift in der Cloud-Infrastruktur umfasst Ereignisse, durch die kritische Daten für Exploits oder Datenlecks offenliegen. Solche Vorfälle schaffen es in die Schlagzeilen. Und dafür ist immer der Cloud-Kunde verantwortlich, nicht der Cloud-Anbieter.

Das häufigste „hässliche“ Drift-Ereignis: Eine kritische Objektspeicher-Ressource wird auf öffentlichen Zugriff eingestellt – häufig AWS S3, nicht zuletzt aufgrund der enormen Verbreitung des Dienstes. S3 ist standardmäßig auf privat eingestellt. Trotzdem kommt es immer wieder vor, dass Cloud-Nutzer die Einstellung versehentlich auf öffentlich ändern und dadurch möglicherweise kritische oder vertrauliche Daten offenlegen. Zahlreiche Schlagzeilen zeugen von der Gefahr, die durch Cloud-Sicherheitsverletzungen infolge von Fehlkonfigurationen in S3 entsteht.

Auch Drift in Security-Group-Regeln, VPCs (einschließlich Subnetzen und ACLs), IAM-Richtlinien und Datenbank-Zugriffsrichtlinien muss schnell erkannt und behoben werden. So vermeiden Sie negative Schlagzeilen, hohe Compliance-Strafen und den Verlust des Kundenvertrauens.

Einen Maßnahmenplan entwickeln

Die Behebung und Vermeidung von Fehlkonfigurationen in der Cloud sollte für jedes Cloud-Sicherheits- oder Betriebsteam eines Unternehmens höchste Priorität haben. Drift in den Griff zu bekommen, ist dafür entscheidend. Wenn Sie Drift-Ereignisse kategorisieren, können Sie Ihre begrenzten Ressourcen auf die wirklich wichtigen Fälle konzentrieren und entscheiden, wie Sie sie am besten beheben – manuell oder automatisiert.

• Guter Drift: Ignorieren Sie ihn! Irgendwann sollten Sie jedoch die möglichen Konfigurationsoptionen, die eine Anwendung vornehmen kann, auf ihre Sicherheit hin überprüfen. Darauf gehen wir in einem späteren Beitrag ein.

• Schlechter Drift: Überwachen Sie ihn! Achten Sie darauf, Drift dieser Kategorie kontinuierlich zu überwachen und auf eine schnelle Behebung vorbereitet zu sein. Bei bestimmten Ressourcen, die häufig von Drift betroffen sind, etwa Security Groups, sollten Sie eine Lösung zur automatisierten Behebung einführen, um Systemausfälle zu verhindern.

• Hässlicher Drift: Verhindern Sie ihn! Um Datenschutzverletzungen infolge von Drift in der Infrastruktur zu vermeiden, ist eine Lösung unverzichtbar, die Drift-Ereignisse bei kritischen Ressourcen automatisch erkennt und behebt. Sie können es sich nicht leisten, kritische Daten stunden-, tage- oder noch länger offenzulegen.