Datadog-Report zur Sicherheitslage in Public Clouds Cloud-Security 2025: Daten-Perimeter gewinnen, statische Schlüssel bremsen

Unternehmen rücken Identitäten, Policies und Multi-Account-Strukturen ins Zentrum ihrer Cloud-Security. Der Datadog-Report zeigt zugleich, wie langlebig Zugangsdaten und überpriviligierte Workloads Angriffsflächen offenlassen.

Unternehmen in Deutschland und Europa professionalisieren ihre Cloud-Si­cher­heits­maß­nah­men. Das belegt der „State of Cloud Security 2025“-Report von Datadog: Daten-Perimeter und zentral verwaltete Multi-Account-Umgebungen setzen sich durch, während langlebige Zu­gangs­da­ten und Workloads mit mehr Rechten als nötig weiterhin erhebliche Risiken dar­stel­len.

IT-Awards 2025

Die beliebtesten IAM- und PAM-Anbieter 2025

Daten-Perimeter sind Regeln, die festlegen, wer aus welchem Konto oder Netz auf welche Daten zugreifen darf. Unabhängig davon, wo die Daten liegen. Innerhalb von Unternehmen gibt es eine spürbare Verbreitung von Daten-Perimetern: 40 Prozent der im Report analysierten Or­ga­ni­sa­ti­on­en setzen entsprechende Mechanismen ein.

S3-Bucket-Policies sind am häufigsten betroffen

Am häufigsten geschieht dies über S3-Bucket-Policies (Zugriffsregeln für einen Datenspeicher „Ordner“ in S3), die in rund 32 Prozent der Fälle genutzt werden, und über VPC-Endpoint-Policies (Regeln für Datenverkehr aus isolierten Netzbereichen zu AWS-Diensten), die etwa 13 Prozent erreichen. Service Control Policies (SCPs), als organisationsweite „Leitplanken“, was Accounts nicht dürfen und Resource Control Policies (RCPs), als Leitplanken direkt auf Res­sour­cen­ebene sind seltener, verlagern die Schutzmechanismen aber auf die Or­ga­ni­sa­ti­ons­ebene.

Anhand der Wirkmechanismen werden konkrete Sicherheitsvorteile deutlich. Denn S3-Policies ver­hin­dern Zugriffe von außerhalb eines definierten AWS-Accounts, selbst bei versehentlich öffentlich gemachten Dateien. VPC-Endpoint-Policies erschweren das Hinaustragen von Daten in fremde Konten. Dabei erlauben RCPs (Resource Control Policies) und SCPs (Service Control Policy) es, unternehmensweite Regeln durchzusetzen.

Zero-Trust- und Identity-First-Ansätze können Abhilfe schaffen

Im Rahmen der Sicherheitsarchitektur fügen sich Daten-Perimeter nahtlos in Zero-Trust- und Identity-First-Ansätze ein. Sie bieten, bei reifem Identitäts-, Policy- und Monitoring-Setup, einen klaren Vorteil. Denn durch sie lassen sich Zugriffe über Accounts und Netzgrenzen hin­weg konsistent steuern und Aus­nah­men auf Basis von Standort- oder Netzwerkvertrauen vermeiden. Allerdings sind Daten-Perimeter nicht standardmäßig aktiv und erfordern eine korrekte Konfiguration, da ansonsten unbemerkt Lücken entstehen können. Aktivierungen sollten deshalb stets mit Policy-Simulation, Staging-Tests und anschließender engmaschiger Überwachung erfolgen.

Namespace Bypass

Cyberangreifer können Root-ähnliche Rechte in Ubuntu erlangen

Multi-Account-Umgebungen: Guardrails statt Einzelfall-Tuning

Multi-Account-Setups unter „AWS Organizations“ sind mittlerweile ebenfalls weit verbreitet. 86 Prozent der Unternehmen haben mehrere AWS-Accounts innerhalb einer Organisation und 70 Prozent haben sämtliche Accounts dort organisiert. 40 Prozent dieser Organisationen setzen SCPs ein, 6 Prozent RCPs. Häufig schützen die Policies gemeinsame Infrastruktur und so­ge­nan­nte Landing-Zones sowie zentrale Sicherheitsmechanismen wie „CloudTrail“ und „GuardDuty“.

Eine Herausforderung ergibt sich allerdings beim Management-Account. Da dieser als zentrales Administrationskonto mit weitreichenden Rechten hochprivilegiert ist, erhöhen dort be­trieb­ene Workloads das Risiko. Wird dort ein Dienst kompromittiert, kann sich der Angreifer unbemerkt zu anderen Konten bewegen (Lateral Movement). Gleichwohl betreiben 9 Prozent der analysierten Organisationen „EC2“-Instanzen (kurz für Amazon Elastic Compute Cloud) im Management-Account.

Über alle Anbieter hinweg zeigt sich, dass EC2-Instanzen mit Administratorrechten häufig übermäßig privilegiert sind und damit etwa weitreichenden Zugriff auf S3-Buckets erhalten. Das zeigt, dass Multi-Account-Strukturen klare Leitplanken schaffen und Entwicklung von Produktion trennen, allerdings kein präzises, rollenbasiertes Rechte-Design ersetzen können.

European Sovereign Cloud: Betrieb und Kontrolle in Europa

AWS gründet eigenes EU-Unternehmen für seine Europa-Cloud

Zugangsdaten und Identitäten: Langlebige Schlüssel bleiben ein Hauptproblem

Langlebige Zugangsdaten bleiben weiterhin ein zentrales Risiko. Identity-and-Access-Ma­nage­ment-Benutzer (IAM) verwalten und kontrollieren den Zugriff auf AWS-Ressourcen. 59 Prozent dieser IAM-Benutzer nutzen mindestens einen aktiven Access Key, der älter als ein Jahr ist und viele dieser Schlüssel wurden länger als 90 Tage nicht genutzt.

Exponierte IAM-Schlüssel dienen in AWS häufig als Initialzugang. Immer häufiger aus CI/CD-Pipelines und gemeinsam genutzten Entwicklerarbeitsplätzen. Trotz einer Verbesserung zum Vorjahr weisen in Google Cloud immer noch 55 Prozent der Service-Accounts-Schlüssel mit einem Alter von über einem Jahr auf. Auch bei Microsoft „Entra ID“ sind noch 40 Prozent der App-Registrierungen mit Credentials, die älter als ein Jahr sind, versehen.

RBAC und Least Privilege als Basis für sicheres IAM

IAM in der Cloud braucht Zero Trust und temporäre Zugriffstokens

Zeitgebundene, kurzlebige Zugangsdaten

Parallel setzt sich der föderierte Zugriff für die AWS-Konsole weiter durch: 79 Prozent der Or­ga­ni­sa­ti­on­en nutzen Verfahren wie „IAM Identity Center“ oder „Okta“. Dennoch setzen rund 39 Prozent weiterhin IAM-User ein, etwa 21 Prozent sogar ausschließlich. Stattdessen wäre ein Umstieg auf zeitgebundene, kurzlebige Zugangsdaten empfehlenswert.

Beispielsweise IAM-Rollen für „Elastic Compute Cloud“ oder „Elastic Kubernetes Service“ in AWS, „Managed Identities“ in Azure und „Workload-Identitäten“ in Google Cloud. Darüber hinaus eine Zentralisierung menschlicher Identitäten über Lösungen wie AWS IAM Identity Center, Okta oder Entra ID.

Prioritäten für Sicherheitsverantwortliche

Um die Angriffsfläche zu verkleinern, sollten Unternehmen den Daten-Perimeter konsequent ausweiten. Beginnend bei S3- und VPC-Policies und wo möglich, über RCPs und SCPs auf Or­ga­ni­sa­ti­ons­ebene. Multi-Account-Setups gehören vollständig unter AWS „Organizations“ und produktive Workloads haben im Management-Account nichts zu suchen. Unternehmensweite Sicherheitsregeln lassen sich dabei durch stringent definierte SCPs und RCPs absichern.

Zugänge sollten zudem so kurzlebig wie möglich gestaltet werden. Föderierte Logins sollten zum Standard werden, während Legacy-IAM-User schrittweise und kontrolliert abgebaut werden. Für Workloads sind Rollen beziehungsweise Workload-Identitäten statischen Schlüsseln vorzuziehen, um Rotationen zu erzwingen und Berechtigungen feinzusteuern.

Tool-Tipp 34 Keycloak

Zentrale Verwaltung von Identitäten und Rollen mit Open Source

Drittanbieter-Integrationen verdienen besondere Aufmerksamkeit. Denn Rollen für externe Services sollten auf unnötige Rechte geprüft und durch den verpflichtenden Einsatz von External IDs abgesichert werden. So lassen sich unautorisierte Übernahmen von Ver­trau­ens­be­zieh­ung­en eindämmen.

Fazit

Der Datadog-Report zeichnet ein ambivalentes Bild: Unternehmen professionalisieren ihre Cloud-Sicherheitsarchitektur, doch alte Schwachstellen bleiben eine Gefahr. Daten-Perimeter und zentral gesteuerte Multi-Account-Strukturen sorgen für klarere Leitplanken und stärken Identity-First-Ansätze. Gleichzeitig unterminieren häufig langlebige Zugangsdaten, Workloads mit mehr Rechten als nötig und nicht sauber abgesicherte Drittanbieter-Rollen den Fortschritt.

Der Weg nach vorn ist pragmatisch: Perimeter systematisch ausweiten (S3, VPC, idealerweise RCP/SCP), Workloads aus dem Management-Account verbannen, kurzlebige, föderierte Zugänge zum Standard machen und externe Integrationen mit External-ID-Pflicht absichern. Wer diese Hebel priorisiert, senkt kurzfristig die Angriffsfläche und schafft zugleich die Basis für belastbare Zero-Trust-Umgebungen.

Mit geleakten AWS-Kontodaten

So clever verschlüsselt Codefinger AWS-Speicher

Methodik

Der Bericht analysiert die Sicherheitslage tausender Organisationen, die AWS, Azure oder Google Cloud nutzen und Datadog „Infrastructure Monitoring“, „Logs“ oder „Cloud Security“ im Einsatz haben. Die Zahlen stammen aus Telemetrie (Nutzungsdaten) und Kon­fi­gu­ra­ti­ons­prü­fung­en bei Datadog-Kundinnen und -Kunden. Erhoben wurden die Daten per direkter Messung und Policy- oder Konfigurationsanalyse. Die Nutzung von Daten-Perimetern und Multi-Accounts wurde über Logs, Policies und Konfigurationen verifiziert.

Über den Autor: Emilio Escobar, CISO bei Datadog, zuvor unter anderem bei Hulu und PlayStation, verfügt über zwei Jahrzehnte Erfahrung in den Bereichen Informationssicherheit und Compliance. Er ist für die Bereiche IT, Sicherheit, Governance, Risikomanagement, Compliance sowie Kundenvertrauen und -sicherheit verantwortlich.

(ID:50648136)