Cloud-Sicherheit im Überblick

Durch Cloud-Sicherheit (Cloud Security) schützen Sie die Infrastruktur, Anwendungen und Daten, die den Geschäftsbetrieb Ihres Unternehmens in der Cloud unterstützen. 

Sicherheit in der Cloud umfasst Identitätsmanagement, Konfigurationsüberwachung, Workload-Schutz sowie Maßnahmen zur Reaktion auf Risiken – über Cloud Service Provider (CSPs) wie Microsoft Azure, Amazon Web Services (AWS) und Google Cloud Platform (GCP) hinweg.

Definitionsgemäß beinhaltet Cloud-Sicherheit sämtliche Technologien, Richtlinien und Kontrollmechanismen, mit denen cloudbasierte Infrastrukturen, Anwendungen und Daten vor Cyberbedrohungen geschützt werden.

Mit der Einführung einer Multi-Cloud-Strategie vergrößert sich Ihre Angriffsfläche. Dadurch entstehen neue Risiken, wie etwa Identitäten mit übermäßigen Zugriffsrechten, fehlerhaft konfigurierte Ressourcen und offengelegte sensible Daten. 

Eine leistungsstarke Lösung für Cloud-Sicherheit bewertet Ihre Umgebung kontinuierlich, bringt die kritischsten Probleme ans Licht und hilft Ihrem Team, sie schnell zu beheben.

Die Cloud-Angriffsfläche wächst mit jedem neuen Workload und Konto und mit jeder neuen API. Aus Tenable-Studien zum Thema Cloud-Sicherheit wie z. B. dem Cloud Risk Report 2024 (in dem Daten aus dem Zeitraum von Januar bis Juni 2024 analysiert werden) ging Folgendes hervor:

• 84 % der Unternehmen haben riskante Zugriffsschlüssel
• 23 % der Cloud-Identitäten weisen übermäßige Berechtigungen mit hohem oder kritischem Schweregrad auf
• 80 % der Cloud-Workloads enthalten nicht behobene kritische CVEs; so blieb beispielsweise die weit verbreitete Container Escape-Schwachstelle CVE-2024-21626 über längere Zeiträume unbehandelt

Die Erkenntnis daraus? Ohne Sichtbarkeit, Automatisierung und kontextbezogene Priorisierung ist Ihr Unternehmen Gefährdungen ausgesetzt.

Wenn Sie sich über die Rolle im Klaren sind, die Cloud-Sicherheit im Cybersecurity-Bereich spielt, können Sie besser nachvollziehen, aus welchen Gründen klassische Abwehrmechanismen am Perimeter in cloud-nativen Umgebungen nicht ausreichen.

Im Kontext von Cloud-Sicherheit gibt es keinen starren Perimeter – Risikomanagement erfolgt hier über dynamische Services und Infrastrukturen hinweg. 

Ihr Cloud-Provider sichert die physischen und grundlegenden Ebenen ab, doch Sie sind für die Konfiguration Ihrer Workloads, Identitäten und Zugriffskontrollen verantwortlich. Dieses Modell der geteilten Verantwortung in der Cloud – auch als Shared Responsibility-Modell bezeichnet – greift bei allen großen Cloud-Plattformen.

Cybersicherheit im Cloud Computing-Bereich erfordert ein Verständnis davon, welche Risiken Sie selbst managen und welche Sicherheitsaspekte Ihr Cloud-Provider abdeckt. Dies gilt insbesondere in Bezug auf Konfigurationen, Zugriff und sensible Daten.

Ihre Cloud-Sicherheitsplattform muss dieser Komplexität Rechnung tragen und sollte dabei:

• Sichtbarkeit vereinheitlichen – über sämtliche Konten hinweg
• Integrationen mit Ihren Identitätssystemen bieten
• Datenzugriffsmuster überwachen
• Erkennen, was Tenable als toxische Kombinationen bezeichnet – beispielsweise einen öffentlichen Workload, der über eine übermäßig privilegierte Identität eine Verbindung zu sensiblen Daten herstellt 

Wenn Sie diese Risiken frühzeitig identifizieren, können Sie sie beheben, bevor sie von Angreifern ausgenutzt werden.

Darüber hinaus benötigen Sie Tools, die mit sämtlichen Systemen in Ihren Entwicklungs- und Produktionsumgebungen interoperabel sind. 

Dadurch können Sie beispielsweise Infrastructure as Code (IaC) vor der Bereitstellung auf Fehlkonfigurationen scannen und im Anschluss das jeweilige Verhalten dieser Ressourcen überwachen, sobald sie in Betrieb sind. Dieser Shift-Left-Ansatz unterstützt Sie dabei, Sicherheit von Anfang an in Ihre Build-Pipelines einzubetten.

Wenn Sie die besten Cloud-Sicherheitsplattformen miteinander vergleichen, sollten Sie Aspekte berücksichtigen, die über grundlegendes Cloud Security Posture Management (CSPM) hinausgehen. Suchen Sie nach einer Lösung, die Workload-Kontext, Identity Governance und Datensensibilität in einer einheitlichen Ansicht zusammenführt. Auf diese Weise reduzieren Sie tatsächlich bestehende Risiken, nicht nur irrelevante Warnmeldungen.

Die Cloud-Infrastruktur Ihres Unternehmens entwickelt sich in einer Geschwindigkeit weiter, mit der klassische Informationstechnologie (IT) niemals Schritt halten könnte. Dasselbe gilt für Ihre Gefährdung durch Risiken. 

Mit der zunehmenden Nutzung von Multi-Cloud-Architekturen und der Umstellung auf cloud-native Anwendungen in Ihren Teams entstehen unzählige Sicherheitsrisiken in Public Clouds, wie etwa Fehlkonfigurationen, Identitäten mit übermäßigen Zugriffsrechten und nicht überwachte Workloads.

Bei einer modernen Strategie zur Absicherung der Cloud geht es um mehr als nur Perimeterschutz. Sie managen Tausende von unabhängig bereitgestellten Services mit jeweils eigenen Berechtigungen und Richtlinien und unterschiedlichem Drift-Potenzial.

Das Ausmaß dieses Problems wird im Tenable Cloud Risk Report 2024 deutlich. 

Analysten zufolge wiesen 45 % der analysierten Cloud-Assets mindestens ein ausnutzbares Risiko auf. Darüber hinaus waren in 97 % der Unternehmen Cloud-Exposure-Pfade vorhanden, über die Angreifer kritische Assets erreichen können. 

Dies sind keine isolierten Vorkommnisse: Es handelt sich um systemische Schwächen, die kontinuierliche Überwachung und priorisierte Behebungsmaßnahmen erfordern.

Darüber hinaus erhöhen schlecht verwaltete Identitäten das Risiko. 

Jüngste Recherchen von Tenable im Cloud Security Risk Report 2025 zeigen durchweg auf, dass zu laxe Standardeinstellungen, übermäßige Berechtigungen und dauerhafte Zugriffsrechte für Cloud-Identitäten Schlüsselfaktoren für Lateral Movement und Rechteausweitung sind.

Ohne kontextbezogenen Einblick in Identitätsrisiken ist Ihr Team nicht zuverlässig in der Lage, Least-Privilege-Zugriff durchzusetzen oder toxische Kombinationen zu erkennen.

Ein weiterer wichtiger Faktor ist Compliance. 

Eine starke Strategie für Cloud-Compliance ist unerlässlich – unabhängig davon, ob Ihr Team auf Konformität mit FedRAMP, ISO 27001 oder mit branchenspezifischen Standards wie HIPAA hinarbeitet. Fehlkonfigurationen in der Cloud und übermäßige Berechtigungen bringen Zertifizierungen in Gefahr. 

Häufig sind diese Probleme darauf zurückzuführen, dass kein einheitliches Management der Sicherheitslage erfolgt oder „auditfertige“ Nachweise fehlen (sogenannte Evidence Trails). 

Eine robuste Cloud-Sicherheitsplattform kann Ihnen helfen, Sicherheitsverletzungen frühzeitig zu erkennen, sie schnell zu beheben und Compliance im Rahmen von Audits nachzuweisen.

All das geht über eine Verteidigungsstrategie hinaus und dient zusätzlich als Triebfeder. 

Mit den richtigen Tools für das Risikomanagement in der Cloud können Sie neue Services bereitstellen, Infrastruktur skalieren und Innovationen in sämtlichen Geschäftsbereichen einführen, ohne dass dabei unkontrollierte Risiken entstehen. 

Tenable unterstützt diesen Ansatz mit seiner einheitlichen Plattform. Anstatt Teams mit Warnmeldungen zu überschwemmen, bildet Tenable Cloud Security bestehende Beziehungen zwischen Assets, Nutzern und Daten ab, um dadurch aufzuzeigen, was Ihr Unternehmen tatsächlich gefährdet. 

Beispielsweise wäre eine öffentlich zugängliche Ressource mit Administratorrechten und Direktzugriff auf sensiblen Datenspeicher als kritisch einzustufen, doch dieses Problem ist korrigierbar.

Wenn nachvollziehbar ist, wo Risiken in Cloud-Umgebungen bestehen und aus welchen Gründen diese Risiken von Bedeutung sind, können Sie die Angriffsfläche Ihres Unternehmens verkleinern, Compliance beschleunigen und mit größerer Flexibilität in AWS, Azure und Google Cloud agieren.

Cloud-Sicherheit beginnt mit Agentless-Scans. Hierbei werden zunächst sämtliche Assets wie virtuelle Maschinen, Container, Serverless-Funktionen und Storage-Buckets erfasst und die jeweiligen Konfigurationen anhand von Standards validiert. 

Als Nächstes bewerten Tools wie Tenable Cloud Security Risiken kontinuierlich – über sämtliche Ebenen Ihrer Umgebung hinweg.

Parallel dazu beginnt die Durchsetzung von Cloud-Richtlinien in der Entwicklungsumgebung mithilfe von IaC. 

Sobald Entwickler Terraform- oder CloudFormation-Manifeste einspielen, werden diese durch integrierte Scans noch vor der Bereitstellung auf Fehlkonfigurationen geprüft, z. B. auf „offene“ Netzwerkregeln oder Rollen mit übermäßigen Berechtigungen. Dies ist ein Beispiel für Shift-Left-Sicherheit – hier binden Ihre Teams Sicherheitsvorkehrungen frühzeitiger in den Softwareentwicklungszyklus ein.

Sobald Workloads ausgeführt werden, kommt Identity Governance zum Einsatz. 

Durch kontinuierliches Monitoring und Cloud Infrastructure Entitlement Management (CIEM) werden ungenutzte oder übermäßige Berechtigungen erkannt. Da Least-Privilege-Zugriff durchgesetzt und veraltete Berechtigungen entfernt werden, reduziert sich die Angriffsfläche. 

Wenn Systeme ungewöhnliche Zugriffe erkennen, z. B. durch eine Lambda-Funktion, die eine zugriffsbeschränkte Datenbank abfragt, geben sie Warnmeldungen aus oder entfernen den jeweiligen Zugriff dynamisch.

Treten Schwachstellen auf, wie etwa zugängliche Container-Images oder öffentliche APIs, erzeugen automatisierte Workflows Code-Snippets zu ihrer Behebung – direkt in Ihrer CI/CD-Pipeline. Mit diesen Snippets im Terraform- oder YAML-Format können Sie die jeweiligen Probleme bei der Versionskontrolle beheben und schnell und konsistent zur Neubereitstellung übergehen.

Cloud-Umgebungen befinden sich in ständigem Wandel. 

Mithilfe von Exposure Management in der Cloud ist erkennbar, wie Assets über Identitäten und Berechtigungen miteinander verbunden sind. Ein Exposure-Diagramm (der sogenannte Exposure Graph) bildet mögliche Angriffsketten in Echtzeit ab, die Angreifer z. B. von einem zugänglichen Storage-Bucket über einen ungenutzten Administratorschlüssel zu einer Datenbank führen könnten, und verdeutlicht zudem, wo diese Ketten unterbrochen werden sollten.

Und nicht zuletzt werden durch Continuous Monitoring and Detection (CMD) oder Cloud Detection and Response (CDR) verdächtige Ereignisse in AWS, Azure, GCP und Kubernetes-Clustern nachverfolgt, wie z. B. Änderungen an IAM-Richtlinien, Modifizierungen des Netzwerks oder Verhaltensanomalien bei Containern. 

Sie profitieren von Erkennung, priorisierten Maßnahmen und einer Integration mit Ticketing-Systemen, sodass Remediation-Teams schnell Korrekturen einleiten können.

Dieses Arbeitsmodell:

• Findet sämtliche Assets und prüft die Sicherheitslage durch CSPM, Kubernetes Security Posture Management (KSPM) und Cloud Workload Protection (CWP)
• Stellt sicher, dass Daten durch Data Security Posture Management (DSPM) jederzeit geschützt bleiben
• Steuert den gesamten Identitätszugriff durch CIEM und Just-in-Time-Workflows (JIT)
• Verhindert Drift mithilfe von Policy as Code in CI/CD-Pipelines
• Bietet einen Live-Einblick in Umgebungen – durch Exposure Mapping und CDR

Mit diesem einheitlichen Ansatz können Sie eine Flut von Warnmeldungen vermeiden, sich auf das Wesentliche fokussieren, flexibel bleiben und parallel dazu Compliance-Anforderungen erfüllen.

Cloud-Sicherheit umfasst mehrere Bereiche, die für den Schutz Ihrer Cloud-Umgebung allesamt von entscheidender Bedeutung sind. Dazu zählen:

• Infrastruktursicherheit durch Tools wie CSPM, die Ihre Computing-, Storage- und Serverless-Konfigurationen anhand von Frameworks wie den CIS Benchmarks überprüfen
• Workload-Schutz durch Cloud Workload Protection Platforms (CWPP), die das jeweilige Verhalten von Containern, VMs und Funktionen zur Laufzeit überwachen
• Kubernetes- und Container-Sicherheit – hierzu wird KSPM mit einer entsprechenden Durchsetzung zur Laufzeit kombiniert, um Ihre Cluster und Workloads abzusichern
• Identity Governance, in deren Rahmen der jeweilige Wirkungsradius durch CIEM, JIT-Zugriff und die Durchsetzung des Least-Privilege-Prinzips verringert wird
• DSPM – durch eine Verknüpfung von Zugriffsmustern mit Exposure-Risiken werden sensible Daten über verschiedene Services hinweg erkannt und geschützt
• Netzwerk- und API-Sicherheit – hierbei kommen Segmentierungs- und Gateway-Richtlinien zum Einsatz, um Bewegungen innerhalb der Umgebung und externen Zugriff zu begrenzen
• Cloud Access Security Brokers (CASB) – CASB bieten Einblick in die SaaS-Nutzung, setzen Zugriffsrichtlinien durch und verhindern Datenverlust bei Cloud-Anwendungen
• CDR – in Kombination mit Exposure Mapping verdeutlicht CDR, wie durch das Zusammenspiel von Fehlkonfigurationen, Identitäten und Daten reale Angriffspfade entstehen

Die einzelnen Ebenen verstärken sich hier gegenseitig. Im Verbund bilden sie ein Defense-in-Depth-Modell, das Ihre Cybersecurity-Lage in der Cloud anbieterübergreifend stärkt.

In unserem Leitfaden „Types of Cloud Security“ werden die einzelnen Bereiche im Detail behandelt.

Da Sie nun mit den wichtigsten Arten von Cloud-Sicherheit vertraut sind, erfahren Sie in diesem Abschnitt, wie die Implementierung gelingt. 

Diese Best Practices für Cloud-Sicherheit beziehen sich auf AWS-, Azure- und GCP-Umgebungen und funktionieren noch besser, wenn Ihre Plattform den bestehenden Einblick in die Sicherheitslage, Identitäten und Workloads vereinheitlicht. 

Nutzen Sie diese Checkliste als Leitfaden für Ihre nächsten Schritte und rufen Sie die einzelnen Abschnitte für ausführlichere Hilfestellungen auf.

Wenden Sie diese wirkungsvollen Strategien in Ihrer Multi-Cloud-Umgebung an:

• Kontinuierlich auf Fehlkonfigurationen scannen
  • Erkennen und beseitigen Sie Drift in Computing-, Storage- und Serverless-Konfigurationen, bevor sich daraus Gefährdungen entwickeln.
    • Fehlkonfigurationen bei Identitäten und Infrastruktur
• Least Privilege mithilfe von CIEM und JIT-Zugriff durchsetzen
  • Prüfen Sie Berechtigungen, entfernen Sie ungenutzte Zugriffsrechte und legen Sie den Umfang von Rollen dynamisch fest.
    • CIEM
    • JIT-Zugriffssteuerung
• CI/CD-Pipelines frühzeitig absichern
  • Stellen Sie auf einen Shift-Left-Ansatz um, indem Sie IaC- und Container-Scans in Ihren Entwicklungsprozess einbetten.
    • Einbindung in CI/CD-Pipelines und Shift-Left-Sicherheit
• Container- und Workload-Verhalten überwachen
  • Erkennen Sie Anomalien zur Laufzeit, wie z. B. Rechteausweitung oder unbefugte Bewegungen in der Umgebung.
    • Container-Sicherheit
    • CWP
• Exposure-Pfade abbilden und priorisieren
  • Nutzen Sie Exposure-Diagramme, um kritische Angriffsketten über Identitäten, Workloads und Daten hinweg aufzuspüren.
    • Exposure Management im Bereich Cloud-Sicherheit
• Sensible Daten durch DSPM schützen
  • Erfassen, klassifizieren und beschränken Sie den Zugriff auf kritische Datensätze in Ihrer Cloud-Umgebung.
    • DSPM
• Bedrohungen in Echtzeit erkennen und darauf reagieren
  • Binden Sie cloud-native Telemetriedaten in Ihre Abläufe ein und automatisieren Sie Remediation-Workflows.
    • CDR

Bei Cloud-Sicherheit geht es nicht einfach nur darum, Fehlkonfigurationen ausfindig zu machen. Vielmehr muss erkennbar sein, wie Identitäten, Workloads und Daten in Ihrer gesamten Umgebung miteinander interagieren. 

Genau hier kommen Plattformen zum Schutz cloud-nativer Anwendungen (Cloud-Native Application Protection Platforms, CNAPP) ins Spiel.

Anstatt Sicherheitslage, Laufzeit-Verhalten, Berechtigungen und Datensichtbarkeit über verschiedene Tools hinweg zu jonglieren, bietet Ihnen CNAPP eine einzige, einheitliche Plattform. Eine CNAPP führt CSPM, CWPP, KSPM, CIEM und DSPM in einem integrierten Workflow zusammen.

Eine solche Plattform für Cloud-Sicherheit bietet vollständige Sichtbarkeit während des gesamten Lebenszyklus, sodass Sie Risiken über IaC, Runtime-Aktivitäten und Zugriffsberechtigungen hinweg verwalten können. 

Eine CNAPP bietet folgende Vorteile:

• Nachverfolgen des Verhaltens von Containern oder VMs zurück zu falsch konfigurierter Infrastruktur oder offengelegten Secrets
• Aufdecken von Verbindungen zwischen gefährdeten Workloads und sensiblen Daten
• Priorisieren von Warnmeldungen basierend auf der tatsächlichen Gefährdung – nicht nur anhand statischer CVEs

Ist ein Container-Image gefährdet, aber in der Umgebung isoliert, besteht möglicherweise kein Handlungsbedarf. Wenn derselbe Workload aber mit übermäßigen Berechtigungen ausgeführt wird und eine Verbindung zu einer Datenbank in der Produktion herstellt, besteht ein kritisches Risiko. 

Ein CNAPP zeigt Ihnen auf, aus welchen Gründen dies der Fall ist.

Die besten CNAPPs lassen sich in Ihre CI/CD-Pipelines einbinden, setzen Policy as Code durch und analysieren Cloud-Risiken anhand von Exposure-Pfaden – nicht anhand isolierter Feststellungen. Dadurch hat Ihr Team im Blick, auf welche Risiken es in welchen Bereichen wirklich ankommt und wie diese Risiken beseitigt werden können, bevor sie zu einer Sicherheitsverletzung führen.

Best Practices zur Nutzung von CNAPPs in Cloud-Umgebungen

Der Schutz Ihrer Cloud-Umgebung erfordert mehr als nur Warnmeldungen. Sie benötigen Kontext, Kontrollmechanismen und eine skalierbare Strategie. Diese Best Practices unterstützen Sie dabei, CNAPPs effektiv einzusetzen und konkrete Risiken zu reduzieren.

1. Scannen Sie sämtliche Cloud-Services auf Fehlkonfigurationen.
   • Führen Sie kontinuierliche Checks der Sicherheitslage durch – über Computing-, Storage-, Serverless- und Kubernetes-Konfigurationen hinweg.
2. Setzen Sie Least-Privilege-Zugriff durch und beseitigen Sie ungenutzte Zugriffsrechte.
   • Nutzen Sie CIEM-Tools, um nicht genutzte Berechtigungen zu erkennen und zu beseitigen.
3. Achten Sie auf Kombinationen aus Identitäten, Sicherheitsrisiken und Daten.
   • Ein öffentlich zugänglicher Workload mag zunächst sicher erscheinen – bis dann mithilfe von übermäßigen Zugriffsrechten eine Verbindung zu sensiblen Systemen hergestellt wird.
4. Erkennen Sie Drift zwischen Code und Runtime.
   • Stellen Sie sicher, dass Ihre Live-Umgebung mit den festgelegten Richtlinien übereinstimmt. Ist dies nicht der Fall, bestehen möglicherweise Gefährdungen.
5. Integrieren Sie Sicherheit in Ihre CI/CD-Pipeline.
   • Scannen Sie Terraform-, YAML- und Container-Images während der Entwicklung. Beheben Sie Probleme noch vor der Bereitstellung.
6. Bilden Sie Angriffspfade mithilfe von Erkenntnissen zu Assets und Identitäten ab.
   • Priorisieren Sie basierend auf der Art und Weise, wie sich Angreifer zwischen Services hin- und herbewegen könnten – nicht anhand isolierter Feststellungen.
7. Überwachen Sie Container während der Laufzeit.
   • Achten Sie auf ungewöhnliche Aktionen, wie z. B. Änderungen an Berechtigungen oder Lateral Movement innerhalb Ihrer Cluster.
8. Verfolgen Sie nach, wer – und was – auf sensible Daten zugreifen kann.
   • Daten an sich stellen keine Gefahr dar – Risiken entstehen aus dem jeweiligen Zugriffspfad.
9. Wenden Sie Kontrollmechanismen in Form von Code an.
   • Definieren Sie Richtlinien in Ihrer Codebasis und setzen Sie sie durch, um konsistente, überprüfbare Schutzvorkehrungen aufrechtzuerhalten.
10. Priorisieren Sie Kontext gegenüber Quantität.
    • Fokussieren Sie Ihre Energie auf Bereiche, in denen es zu Überschneidungen zwischen Workload-Verhalten, Berechtigungen und sensiblen Daten kommt.

Schwachstellenmanagement in der Cloud erfordert präzisen Kontext. Gehen Sie über das Scannen von Code hinaus und machen Sie sich ein Bild davon, wo Code ausgeführt wird, wer darauf zugreift und wie Code eine Verbindung zu sensiblen Ressourcen herstellt.

Probleme, die in Umgebungen ohne Host oder in kurzlebigen Containern auftreten, können von herkömmlichen Schwachstellen-Scannern nicht aufgedeckt werden. 

Aus dem Tenable Cloud Risk Report 2024 ging hervor, dass 42 % der gefährdeten Workloads nur temporär existierten und bereits wieder aufgelöst wurden, bevor herkömmliche Tools diese Workloads überhaupt scannen konnten.

Eine leistungsstarke Vulnerability Management-Lösung für Cloud-Umgebungen funktioniert wie folgt:

• Scannen über mehrere Ebenen hinweg
  • Prüfen Sie ausgeführte Container, virtuelle Maschinen, Serverless-Funktionen und gespeicherte IaC-Dateien. Kennzeichnen Sie gefährdete Basis-Images oder fehlende Patches und verknüpfen Sie diese mit der aktuellen Laufzeitumgebung.
• Ergänzen des Risiko-Scoring durch Kontextdaten
  • Gleichen Sie festgestellte Schwachstellen mit Identitäts- und Exposure-Ebenen ab. Aus einer CVE mit niedrigem Schweregrad entwickelt sich ein hohes Risiko, wenn die Schwachstelle einen über das Internet zugänglichen Workload betrifft und die Authentifizierung über ein ungenutztes Dienstkonto mit hohen Berechtigungen erfolgt.
• Verwendung von CI/CD-Integration
  • Wenden Sie Behebungsvorschläge und Remediation-Snippets direkt in Pull-Requests oder Pipelines an. Entwickler können Schwachstellen beheben, bevor sie Codeänderungen zusammenführen und bereitstellen, wodurch Shift-Left-Sicherheit unterstützt wird.
• Automatisieren der Behebung
  • Generieren Sie cloud-native Patch-Snippets wie Terraform, ARM-Templates und CloudFormation, um Korrekturen nach Möglichkeit automatisch vorzunehmen. Dies senkt die Behebungszeit von mehreren Wochen auf Stunden.
• Priorisieren der Reaktionsmaßnahmen im Rahmen der Ersteinschätzung.
  • Sicherheitsteams erhalten ausschließlich Warnmeldungen mit hoher Priorität. Dadurch können sie sich auf diejenigen Schwachstellen fokussieren, die Angreifer innerhalb Ihres Live-Workflows für das Risikomanagement in der Cloud am ehesten ausnutzen werden.

Dieser Ansatz verhindert, dass nicht erkannte Schwachstellen in die Produktionsumgebung gelangen, und beugt Drift bei Infrastrukturen vor. 

Anstatt auf Warnmeldungen zu reagieren, beseitigt Ihr Team proaktiv Risiken in Containern, APIs und cloud-nativen Kontexten – unterstützt durch Automatisierung und intelligente Priorisierung.

Sie möchten mehr über Schwachstellenmanagement in der Cloud erfahren? Auf dieser Seite zum Thema Cloud Vulnerability Management finden Sie ausführlichere Informationen.

Exposure Management zeigt auf, wie Angreifer über fehlgeschlagene Kontrollmechanismen oder unsichere Berechtigungen von einer Fehlkonfiguration zur nächsten gelangen könnten.

Aus dem Tenable Cloud Risk Report 2024 geht hervor, dass 97 % der Unternehmen mindestens einen ausnutzbaren Angriffspfad aufwiesen, dem eine Kombination aus Zugänglichkeit über das Internet, Identitätsberechtigungen und anfälligen Workloads zugrunde lag.

Hier einige Empfehlungen zur Anwendung von Best Practices für Exposure Management in Cloud-Umgebungen:

• Bilden Sie Ihre Cloud-Angriffsfläche ab.
• Ermitteln Sie, wie Ressourcen, Identitäten, Datenspeicher und Netzwerkrouten in Ihrer gesamten Cloud-Umgebung interagieren. Anhand dieses Kontexts können Sie präzise bestimmen, wo es zu einer Überschneidung von Risiken kommt und wo Angreifer sich lateral durch die Umgebung fortbewegen könnten.
• Identifizieren Sie toxische Kombinationen.
• Risiken sind nicht immer auf einen einzigen Lapsus zurückzuführen. Eine öffentliche API könnte mit einem Container verbunden sein, in dem veralteter Code ausgeführt wird. Wenn dieser Container ein privilegiertes Dienstkonto mit Datenbankzugriff nutzt, besteht bereits eine Exposure-Kette. Exposure Management bedeutet, dass diese gefährlichen Kombinationen aufgespürt werden, bevor Angreifer sie ausnutzen.
• Priorisieren Sie ausnutzbare Schwachstellen, keine irrelevanten Feststellungen.
• Fehlkonfigurationen treten häufig auf, doch nicht alle sind relevant. Fokussieren Sie die Bemühungen Ihres Teams auf Fehlkonfigurationen, durch die Zugriffspfade zu kritischen Daten oder Produktionssystemen entstehen. Bei Exposure-orientierter Priorisierung werden der jeweilige Identitätskontext, die Datensensibilität und die Erreichbarkeit des Netzwerks berücksichtigt – nicht nur die Anzahl der Warnmeldungen.
• Versperren Sie Exposure-Pfade direkt an der Quelle.
• Beseitigen Sie ganze Verkettungen von Risiken, nicht nur einzelne Schwachstellen. Hierzu könnte es notwendig sein, unnötige Berechtigungen zu entfernen, Workloads zu isolieren, Richtlinien im Rahmen der festgelegten Grenzen durchzusetzen oder ungenutzte Zugriffswege zu blockieren. Eine frühzeitige Unterbrechung von Exposure-Pfaden hält Angreifer davon ab, Lücken mit geringem Risiko so miteinander zu verketten, dass größere Sicherheitsverletzungen eintreten.

Der Leitfaden zum Thema Exposure Management in der Cloud enthält ausführlichere Erkenntnisse zu der Frage, wie Exposure Management Ihre Cloud-Sicherheitsstrategie stärkt.

Cloud-Umgebungen wachsen in rasantem Tempo. 

Im Zuge dieser Entwicklung nimmt auch der Wildwuchs bei menschlichen Nutzern, Dienstkonten und Rollen von Drittanbietern zu. 

In zahlreichen Fällen werden übermäßige, veraltete oder nie genutzte Berechtigungen gewährt und beibehalten. 

CIEM-Tools überprüfen diese Berechtigungen kontinuierlich. Sie melden riskante Kombinationen, ungenutzte Berechtigungen sowie Zugriffsrechte, die sich über AWS, Azure, GCP und Kubernetes hinweg erstrecken.

Für eine sichere Cloud müssen Aspekte berücksichtigt werden, die über den Direktzugriff auf Umgebungen hinausgehen. Angenommen, ein Dienstkonto in der Entwicklungsumgebung weist Wildcard-Berechtigungen auf: Wenn Angreifer dieses Konto kompromittieren, könnten sie Zugriff auf Container, Workloads und Produktionsdaten erlangen. 

CIEM-Tools tragen dazu bei, diese indirekten Pfade aufzudecken, durch die reale Gefährdungen entstehen.

Die richtige CIEM-Lösung unterstützt Just-in-Time-Zugriff und die Durchsetzung des Least-Privilege-Prinzips. Wenn erkennbar ist, was die jeweiligen Identitäten tatsächlich nutzen, können knapper bemessene Beschränkungen eingerichtet, ungenutzte Zugriffsrechte widerrufen und Zugangsdaten durch Rotation gewechselt werden, ohne Störungen zu verursachen.

Sie möchten sich eingehender mit spezifischen Anwendungsfällen und Tools befassen? Auf dieser Seite zum Thema CIEM finden Sie ausführlichere Informationen.

Selbst wenn der jeweilige Umfang von Rollen ordnungsgemäß festgelegt wird, entstehen durch dauerhafte Zugriffsrechte weiterhin Risiken. 

In Cloud-Umgebungen werden über lange Zeiträume bestehende Berechtigungen zu leichten Zielen für Angreifer, insbesondere wenn Nutzer oder Dienste Zugriffsrechte behalten, die nicht aktiv genutzt werden. 

JIT-Zugriff minimiert dieses Zeitfenster. Ein Entwickler könnte zu Debugging-Zwecken möglicherweise Administratorrechte für eine Staging-Umgebung benötigen. Kommt JIT-Zugriff zum Einsatz, stellt diese Person eine Zugriffsanfrage und führt dann die jeweilige Aufgabe durch, bevor ihre Berechtigungen am Ende der Sitzung wieder entzogen werden. So wird das Least-Privilege-Prinzip in effektiverer Form durchgesetzt. 

Sie haben die Kontrolle drüber, wie Zugriffsanfragen genehmigt werden, wie lange Zugriffsrechte gelten und welche Bedingungen erfüllt sein müssen. Darüber hinaus werden Angriffspfade minimiert, da jederzeit sichergestellt ist, dass weniger Identitäten Zugriff auf sensible Ressourcen haben.

Damit JIT-Zugriff in großem Maßstab eingeführt werden kann, benötigen Sie Einblick in sämtliche Berechtigungen sowie entsprechende Automatisierungsmechanismen zur Durchsetzung von Richtlinien. Eine leistungsstarke Plattform für Cloud-Sicherheit unterstützt Sie dabei, diese Leitplanken – sogenannte Guardrails – in Ihre CI/CD-Workflows und Audit Trails einzubinden.

Sie möchten sich ein genaueres Bild davon machen, wie JIT-Zugriff sich in Ihre Least-Privilege-Strategie einfügt? Näheres erfahren Sie in unserem umfassenden Leitfaden zum Thema Just-in-Time-Zugriff.

Cloud-Risiken lassen sich nur reduzieren, wenn der Zugriff entsprechend eingeschränkt wird – am Least-Privilege-Prinzip führt hier kein Weg vorbei. Doch ohne Sichtbarkeit und Automatisierung ist dies nur schwer umsetzbar, insbesondere in Multi-Cloud-Umgebungen.

Least-Privilege-Zugriff stellt sicher, dass sämtliche Identitäten von Personen oder Maschinen nur die jeweils benötigten Zugriffsrechte erhalten. 

In AWS-, Azure- und GCP-Umgebungen kann sich eine manuelle Durchsetzung dieses Prinzips als schwierig erweisen. Mit zunehmender Anzahl von Berechtigungen laufen selbst wohlüberlegte Richtlinien ins Leere.

An dieser Stelle helfen CIEM-Tools weiter: Sie analysieren die tatsächliche Nutzung und melden unnötige oder riskante Berechtigungen. Mithilfe von CIEM und entsprechenden Workflows für JIT-Zugriff können Teams übermäßige Berechtigungen einschränken, den Umfang von Rollen definieren und strengere IaC-Kontrollmechanismen entwickeln, die mit den tatsächlichen Erfordernissen auf einer Linie liegen.

Zero Trust in der Cloud bedeutet, dass jede Zugriffsanfrage basierend auf der jeweiligen Identität, dem entsprechenden Kontext und bestehenden Risiken verifiziert wird. 

Unternehmen können nicht davon ausgehen, dass Ressourcen vertrauenswürdig sind, nur weil sie sich innerhalb ihres Perimeters befinden. In der Cloud existiert dieser Perimeter nicht.

Moderne Cloud-Umgebungen erstrecken sich über mehrere Virtual Private Clouds (VPCs), Regionen und Plattformen. Ohne kontinuierliche Verifizierung kann ein Token aus einer Umgebung unbemerkt Zugriff auf eine weitere Umgebung gewähren.

Die Durchsetzung von Zero Trust führt dazu, dass Einblick in Identitäten, Workloads und entsprechende Interaktionen besteht. Folglich kann verdächtiges Verhalten erkannt und eine missbräuchliche Verwendung von Berechtigungen unterbunden werden, bevor es zur Eskalation kommt.

Eine starke Zero-Trust-Strategie erfordert dynamische Zugriffssteuerung, Echtzeit-Kontext und Workload-Überwachung. 

Wenn beispielsweise ein Dienstkonto auf sensible Ressourcen zugreift, mit denen es nie zuvor in Berührung kam, sollte dieses Verhalten eine Untersuchung oder Automatisierung auslösen – anstatt erst eine Eskalation von Warnmeldungen abzuwarten.

Sie möchten sich eingehender mit diesem Thema befassen? In unserem umfassenden Leitfaden zum Thema Zero Trust in der Cloud erfahren Sie, wie dieser Ansatz in Hybrid- und Multi-Cloud-Umgebungen greift.

Ihre Workloads sind nicht die einzigen Assets, auf die es Angreifer abgesehen haben. Sensible Daten sind häufig das eigentliche Ziel. 

Mithilfe von DSPM können Sie diese Daten erfassen, klassifizieren und schützen, bevor es zu einer Offenlegung kommt.

In Ihrer Cloud werden nicht nur Workloads ausgeführt – sie fungiert auch als Datenspeicher. Häufig umfasst dies „regulierte“ Inhalte wie z. B. Finanzdaten, personenbezogene Gesundheitsdaten (PHI) oder geistiges Eigentum. Doch die meisten Unternehmen haben nur unzureichend im Blick, wo sich diese sensiblen Daten befinden oder wie Nutzer und Systeme auf diese Daten zugreifen.

DSPM-Tools scannen Cloud-Umgebungen, um Daten zu erfassen, zu klassifizieren und zu überwachen. Sie verknüpfen diese Daten mit entsprechenden Zugriffspfaden wie Identitäten, Workloads und APIs und helfen dabei, Schutzmaßnahmen basierend auf der jeweiligen Sensibilität und Gefährdung zu priorisieren. 

Dieser Kontext trägt dazu bei, bei der Sicherheit von Cloud-Daten Prioritäten zu setzen. Dadurch kann Ihr Team tatsächliche Cloud-Risiken beseitigen, ohne Zeit mit Warnmeldungen zu verschwenden, die auf geringe Risiken hinweisen.

Einige Beispiele:

• Ein Entwickler könnte eine Sicherungskopie einer Datenbank aus der Produktion anlegen und diese zu Testzwecken in einem unverschlüsselten Storage-Bucket speichern.
• Eine Workload könnte Daten aus einem sensiblen Datensatz abrufen und hierzu eine Identität mit übermäßigen projektübergreifenden Berechtigungen nutzen.
• Eine fehlerhaft konfigurierte IAM-Richtlinie könnte eine Dateifreigabe offenlegen, die Kundeninformationen enthält.

DSPM bringt diese Probleme im Handumdrehen ans Licht und zeigt auf, welche Änderungen eine Risikoreduzierung bewirken, ohne Services zu stören.

Darüber hinaus unterstützt DSPM die Einhaltung von Vorschriften (Compliance), indem Unstimmigkeiten bei der Datenklassifizierung identifiziert werden. Dies trägt dazu bei, Speicher- und Zugriffskontrollen mit entsprechenden Standards in Einklang zu bringen.

Kubernetes bietet immense Flexibilität, geht aber auch mit zusätzlicher Komplexität einher. Zur Absicherung von Clustern müssen Unternehmen im Blick haben, wie Workloads ausgeführt werden, wie sich Identitäten verhalten und wie Richtlinien auf jeder einzelnen Ebene durchgesetzt werden.

Kubernetes orchestriert Container in großem Maßstab, führt aber auch zu neuen Ebenen mit Konfigurations- und Identitätsrisiken. 

Jeder Cluster enthält Nodes, Pods, Dienstkonten, Rollenbindungen und Netzwerkrichtlinien. All das muss verwaltet werden, um unbefugten Zugriff und Lateral Movement zu verhindern.

Eine starke Kubernetes-Sicherheitsstrategie beginnt mit Sichtbarkeit. Unternehmen muss klar sein, welche Ressourcen bereitgestellt werden, wie diese miteinander kommunizieren und wer auf Steuerungs- und Workload-Ebene Zugriff darauf hat. Dies umfasst menschliche Nutzer, CI/CD-Pipelines und automatisierte Services, die innerhalb des Clusters ausgeführt werden.

KSPM bewältigt diese Aufgabe, indem Cluster kontinuierlich auf Fehlkonfigurationen und Berechtigungspfade überwacht werden. 

Dabei wird u.a. Folgendes erkannt:

• Workloads, die mit Root-Berechtigungen oder privilegierten Containern ausgeführt werden
• Missbräuchlich verwendete Dienstkonten, die mit umfangreichen Berechtigungen auf die Kubernetes-API zugreifen
• Unsichere Konfigurationen der rollenbasierten Zugriffskontrolle (RBAC), die Eskalationen ermöglichen
• Fehlende Netzsegmentierung zwischen Namespaces

Durch die Kombination von KSPM mit Workload- und Identitätsüberwachung können Sie Least-Privilege-Zugriff durchsetzen, gefährliches Verhalten zur Laufzeit blockieren und Compliance mit Frameworks wie MITRE ATT&CK for Containers, sicherheitsrelevanten Best Practices der CNCF und branchenspezifischen Richtlinien wie NIST 800-190 aufrechterhalten.

Container sorgen für schnelle und portable Cloud-Workloads. Doch ohne entsprechende Leitplanken erweisen sie sich als einfach zugängliche Einstiegspunkte. 

Container-Sicherheit schützt Workloads während des gesamten Lebenszyklus – von der Entwicklung bis zur Laufzeit – und bildet zusammen mit CWPP- und KSPM-Strategien eine wichtige Sicherheitsebene für Cloud-Workloads. 

Diese Sicherheit beginnt mit Ihrer Pipeline. Tools scannen Docker-Dateien und IaC, um Probleme wie veraltete Pakete, eingebettete Secrets oder offene Ports noch vor der Bereitstellung zu erkennen.

Angenommen, in Ihrer CI/CD-Pipeline wird ein Container bereitgestellt, der auf einem veralteten Node.js-Image aufbaut. Für sich genommen stellt dies noch keine Sicherheitsverletzung dar. Doch wenn der Container zudem mit Root-Zugriff ausgeführt wird und eine Verbindung zu einem Backend mit Kundendaten herstellt, besteht bereits eine kritische eine Exposure-Kette.

Sobald Workloads in Betrieb sind, greift kontinuierliches Monitoring. 

Dadurch können unbefugte Änderungen an Dateien, verdächtige Verhaltensweisen bei Prozessen oder Lateral Movement-Versuche erkannt werden. 

Und da sich containerisierte Umgebungen schnell verändern, ist Sichtbarkeit in Echtzeit von entscheidender Bedeutung. Drift kann innerhalb kürzester Zeit auftreten, insbesondere wenn mehrere Orchestratoren wie Kubernetes und ECS in den Prozess eingebunden sind.

Container-Sicherheit zeigt ihre größte Stärke, wenn sie in einer breiter angelegten Strategie für Cloud-Risikomanagement eingebunden ist. Sie trägt dazu bei, Least-Privilege-Zugriff durchzusetzen, Konfigurationen anhand von Compliance-Frameworks zu validieren und Workloads zu kennzeichnen, die außerhalb ihres vorgesehenen Anwendungsbereichs agieren.

In unserem Leitfaden zum Thema Container-Sicherheit erfahren Sie, wie Risiken in Runtime-Umgebungen reduziert werden können, ohne die Entwicklung auszubremsen.

Eine Cloud Workload Protection Platform (CWPP) schützt die Workloads, die in Ihren Cloud-Umgebungen bereits ausgeführt werden. Der Fokus liegt hier auf dem „Live-Verhalten“, nicht einfach nur auf Ergebnissen von statischen Scans. 

Eine CWPP erkennt Bedrohungen zum Zeitpunkt ihres Auftretens – basierend auf der jeweiligen Interaktion von Workloads mit Identitäten, Netzwerken und Daten.

Unter Umständen besteht ein Container sämtliche Sicherheitschecks während der Bereitstellung, kann dann aber auf internen Speicher zugreifen oder Dateien verschlüsseln, sobald er ausgeführt wird. Dies könnte sich als Problem erweisen. 

Eine CWPP erkennt dieses Verhalten, meldet es entsprechend und liefert Teams den nötigen Kontext, um schnell zu handeln.

Hierzu setzt die Plattform Richtlinien durch, überwacht Umgebungen auf Bedrohungen wie Rechteausweitung oder unerwartete Dateizugriffe und zeigt auf, inwiefern eine einzelne Schwachstelle zu schwerwiegenderen Konsequenzen führen könnte. 

Mit einer CWPP können Sie priorisieren, was wirklich wichtig ist, auf Laufzeitangriffe reagieren und Ihre Cloud-Sicherheitsstrategie stärken.

Shift-Left-Sicherheit stärkt Ihre Abwehrmaßnahmen in der Cloud, indem Probleme früher erkannt werden. Shift-Left-Sicherheit lässt sich unmittelbar in CI/CD-Pipelines einbinden, um IaC, Container-Images und Cloud-Konfigurationen während der Entwicklung zu scannen.

Sicherheitstools scannen Terraform-, CloudFormation- und Kubernetes-Manifeste im Rahmen von Pull-Requests oder während der Build-Phase. Sie melden Risiken wie beispielsweise:

• IAM-Rollen mit übermäßigen Berechtigungen
• Offene Ports oder unsichere Netzwerkeinstellungen
• Gefährdete Basis-Images
• Drift zwischen vorgesehenen Richtlinien und tatsächlichen Verhaltensweisen

Anstatt erst Warnmeldungen zur Laufzeit abzuwarten, erhalten Entwickler umgehend Feedback. Behebungsvorschläge erscheinen direkt in der Versionskontrolle, sodass Probleme schnell und präzise gelöst werden können. Dies beschleunigt die Behebung und stellt sicher, dass Infrastruktur stets mit internen Richtlinien und externen Frameworks übereinstimmt.

Effektive Shift-Left-Sicherheit umfasst:

• Kontinuierliches Scannen von Infrastructure as Code (IaC)
• Behebungsempfehlungen auf Code-Basis
• Richtliniendurchsetzung in Form von Git-basierten Workflows
• Drifterkennung in Entwicklungs- und Produktionsumgebungen
• Kontextbezogenes Risiko-Scoring, das der tatsächlichen Gefährdung entspricht

In unserem Leitfaden zum Thema Shift-Left-Sicherheit und CI/CD-Integration erfahren Sie, wie dies in realen Umgebungen funktioniert.

Einige SIEM-Tools (Security Information and Event Management) greifen in der Cloud zu kurz, da sie ursprünglich für On-Prem-Umgebungen konzipiert wurden. Wichtige cloud-native Verhaltensweisen werden von diesen Tools nicht erkannt, insbesondere wenn sich Bedrohungen über Services, Identitäten und Workloads hinweg erstrecken.

Genau hier kommt Cloud Detection and Response (CDR) ins Spiel. 

CDR-Tools überwachen Cloud-Aktivitäten auf Anzeichen einer Kompromittierung, Lateral Movement, Rechteausweitung und Datendiebstahl. Sie nehmen Protokolle von Cloud-Anbietern, Signale zur Laufzeit und Identity-Aktivitäten auf. Anschließend korrelieren sie diese Signale, um reale Bedrohungen zu ermitteln.

Eine leistungsstarke CDR-Plattform verknüpft die Erkennung mit Kontextinformationen: Anstatt isolierte Warnmeldungen auszugeben, verdeutlicht sie, was vorgefallen ist, aus welchen Gründen es darauf ankommt und wie reagiert werden sollte. 

Ihr Team könnte beispielsweise Folgendes ans Licht bringen:

• Ein Dienstkonto, das auf ungewöhnliche Ressourcen zugreift
• Einen Workload, der über mehrere Cloud-Konten hinweg nicht autorisierte API-Calls vornimmt
• Ein Muster von Änderungen, das bekannten Angriffstechniken entspricht

Die besten CDR-Tools zeigen auf, wie jede Erkennung mit Identitäten, Asset-Sicherheitslücken oder Konfigurationsrisiken zusammenhängt. Dies trägt dazu bei, Kontext in Reaktionsmaßnahmen zu berücksichtigen.

Darüber hinaus ist es möglich, Maßnahmen auszulösen, wie z. B. Zugangsdaten zu widerrufen, Ressourcen zu isolieren oder Änderungen rückgängig zu machen. 

Durch Integrationen mit Systemen wie Jira, ServiceNow und Slack und cloud-native Remediation-Tools ist dieser Prozess schnell und reproduzierbar.

CDR-Tools unterstützen darüber hinaus Untersuchungen. Sie können Protokolle überprüfen, Aktionen zurückverfolgen und Identity-Zeitleisten erstellen, um das volle Ausmaß eines Vorfalls nachzuvollziehen. Dies hilft Ihrem Team, aus sämtlichen Ereignissen zu lernen und diese zu Audit- oder Compliance-Zwecken zu dokumentieren.

Die meisten Cloud-Angriffe beginnen nicht mit Malware, sondern mit Fehlkonfigurationen. Diese „übersehenen“ Einstellungen gewähren übermäßige Zugriffsrechte, legen Workloads offen oder deaktivieren die Protokollierung. Für sich genommen mag eine solche Fehlkonfiguration harmlos erscheinen, doch in Kombination bilden sie Angriffspfade, auf die es Bedrohungsakteure abgesehen haben.

Fehlkonfiguration bei Identitäten und Infrastruktur zählen zu den gängigsten Risiken in der Cloud. Eine IAM-Rolle könnte ohne ordnungsgemäße Kontrolle auf Storage-, Computing- und Drittsysteme zugreifen. 

Ein Workload könnte unter Umständen über das Internet zugänglich sein, ohne dass Runtime-Schutz besteht. Dadurch besteht die Möglichkeit, dass es zu Lateral Movement und Datenkompromittierung kommt.

Kontinuierliches Monitoring über IaC und bereitgestellte Ressourcen hinweg ist unerlässlich und muss Folgendes beinhalten:

• Rollen mit übermäßigen Berechtigungen oder ungenutzte Zugangsdaten
• Öffentlich zugängliche Workloads in Verbindung mit sensiblen Systemen
• Firewall-Regeln ohne entsprechende Beschränkung oder missbräuchlich verwendete Dienstkonten
• Fehlende Verschlüsselung oder deaktivierte Prüfprotokolle
• Vertrauensstellungen, die sich über mehrere Konten oder Projekte erstrecken

Diese Risiken sind gefährlich, wenn es zu Überschneidungen kommt. Angenommen eine virtuelle Maschine weist eine öffentliche IP-Adresse auf. Es mag den Anschein haben, als handele es sich hier um ein Problem von geringer Priorität. Doch wenn diese Instanz eine Rolle mit erhöhten Zugriffsrechten nutzt, bei der keine Protokollierung erfolgt, ergibt sich daraus ein klarer Weg zu einer Kompromittierung.

Fehlkonfigurationen wirken häufig auf eine Art und Weise zusammen, die von Standard-Tools nicht erkannt wird.

Nähere Informationen finden Sie in unserem Leitfaden zur Erkennung und Behebung von Cloud-Fehlkonfigurationen.

Zur Absicherung von Cloud-Umgebungen muss zunächst klar sein, wie die Services der einzelnen Anbieter funktionieren. AWS, GCP und Azure verfolgen allesamt ein Shared Responsibility-Modell, doch bei Tools, Identitätsmodellen und Standardkonfigurationen bestehen wichtige Unterschiede. 

Was auf einer Plattform eine unbedeutende Einstellung zu sein scheint, kann sich auf einer anderen Plattform zu einer schwerwiegenden Sicherheitslücke entwickeln.

Beispielsweise bereiten IAM-Rollen in AWS häufig Probleme, wenn Richtlinien bestimmte Aktionen zulassen oder Vertrauensstellungen nicht verwaltet werden.

In Azure bestehen Risiken häufig in zu weit gefassten Zugriffsrechten, die sich über mehrere Subscriptions hinweg erstrecken, oder in fehlenden Regeln für Netzwerksicherheitsgruppen (Network Security Group, NSG). 

In GCP entstehen Komplexitäten häufig durch Wildwuchs bei Dienstkonten sowie projektübergreifende Zugriffsrechte, die nicht „straff“ genug definiert sind.

Werden diese Unterschiede in manueller Form verwaltet, führt dies zu fragmentierten Richtlinien, blinden Flecken und nicht erkannten Gefährdungen. 

Eine einheitliche Cloud-Sicherheitslösung trägt dazu dabei, Feststellungen anbieterübergreifend zu normalisieren, konsistente Richtlinien durchzusetzen und Probleme basierend auf dem jeweiligen Risiko zu priorisieren.

Einen ausführlichen Vergleich von CNAPP-Plattformen finden Sie in unserem umfassenden, nach Anbieter geordneten Leitfaden zum Thema Cloud-Sicherheit.

Cloud-Umgebungen entwickeln sich ständig weiter. Neue Services werden hochgefahren, Berechtigungen ändern sich und Workloads werden zwischen Regionen und Konten verschoben. 

Ohne zentralisierte Sichtbarkeit lässt sich nur schwer herausfinden, ob Infrastruktur im Zeitverlauf sicher und konform bleibt.

CSPM löst dieses Problem, indem Cloud-Konfigurationen kontinuierlich anhand von Sicherheits- und Compliance-Richtlinien überprüft werden. CSPM-Tools überwachen Umgebungen auf Fehlkonfigurationen, Drift und nicht konforme Assets – über Computing-, Storage-, Networking- und Identity-Services hinweg.

Doch effektives CSPM leistet mehr, als nur Fehlkonfigurationen zu melden. Sicherheitsverletzungen sollten auch mit dem bestehenden Zugriff von Identitäten und der jeweiligen Datensensibilität verknüpft werden. 

Darüber hinaus unterstützt CSPM auch Policy--as-Code. Ihr Team kann Baseline-Konfigurationen in Code definieren und durchsetzen und dann während der Bereitstellung sowie zur Laufzeit validieren. Dies verhindert, dass nicht konforme Änderungen in die Produktionsumgebung gelangen, und stellt sicher, dass sich sämtliche Cloud-Assets stets innerhalb akzeptabler Grenzen bewegen.

Multi-Cloud- und Hybrid-Umgebungen erhöhen die Komplexität für Sicherheitsteams. 

Jeder Anbieter verwendet eigene Identitätsmodelle, Richtlinien-Engines und Standardkonfigurationen. 

Durch On-Prem-Systeme kommt häufig eine weitere Ebene mit isolierten Tools, Protokollen und Kontrollmechanismen hinzu. 

Das Ergebnis: Fragmentierte Sichtbarkeit, inkonsistente Richtlinien und Exposure-Lücken, die Angreifer ausnutzen können.

Diese Herausforderungen bremsen die Erkennung und Reaktion aus. Wenn sich Identitätsprotokolle in einem Dashboard, sicherheitsrelevante Feststellungen (sogenannte Posture Findings) in einem weiteren und Workload-Ereignisse an ganz anderer Stelle befinden, nimmt die Korrelation von Problemen zu viel Zeit in Anspruch – vorausgesetzt, Teams können Probleme überhaupt erkennen.

Sichtbarkeit stellt hier die größte Herausforderung dar, denn andernfalls wird es Unternehmen schwerfallen, einfache Fragen wie die folgenden zu beantworten:

• Wer hat worauf Zugriff – über verschiedene Clouds und Konten hinweg?
• Sind Konfigurationen plattform- und regionsübergreifend konsistent?
• Wo überschreiten Cloud-Identitäten Grenzen bzw. wo weisen sie ungenutzte Berechtigungen auf?

Effektives Risikomanagement in der Cloud erfordert Normalisierung – über sämtliche Umgebungen hinweg. Hierzu muss IaC vor der Bereitstellung gescannt und Policy-as-Code anbieterübergreifend angewendet werden. Hinzu kommen Exposure-orientierte Tools, die Konfigurationsdrift, Identitätsrisiken und das jeweilige Verhalten zur Laufzeit in Zusammenhang bringen.

Hybrid Cloud-Compliance geht mit ganz eigenen Zwängen einher. 

Frameworks wie ISO/IEC 27001, FedRAMP und NIST 800-53 sehen vor, dass Zugriffskontrollen, Verschlüsselung und Audit-Protokollierung konsistent nachgewiesen werden – völlig unabhängig davon, wo ein Service ausgeführt wird. Folglich muss Einblick in Cloud- und On-Prem-Systeme bestehen, die miteinander verbunden sind.

In unserem Leitfaden zum Thema Multi-Cloud- und Hybrid-Cloud-Sicherheit erfahren Sie, wie zusammenhängende Erkenntnisse Sicherheit und Compliance Readiness verbessern.

Was ist Cloud-Sicherheit im Cybersecurity-Bereich?

Cloud-Sicherheit, auch als Cloud Computing-Sicherheit bezeichnet, umfasst Richtlinien, Technologien und Prozesse, mit denen Cloud-Infrastruktur, Anwendungen und Daten auf Plattformen wie AWS, Azure und Google Cloud vor Bedrohungen geschützt werden. Cloud-Sicherheit deckt sämtliche Aspekte ab, angefangen bei der Verwaltung von Fehlkonfigurationen und Zugriffssteuerung bis hin zu Runtime-Schutz und Schwachstellenmanagement. 

Warum ist Cloud-Sicherheit wichtig?

Durch Cloud-Infrastruktur entstehen neue Risiken, wie etwa kurzlebige Workloads, dezentralisierte Identitäten und sich schnell verändernde Services. Ohne Sichtbarkeit und Kontrolle nutzen Angreifer Fehlkonfigurationen und Rollen mit übermäßigen Zugriffsrechten aus. Starke Cloud-Sicherheit hilft Teams, Sicherheitsverletzungen zu verhindern, Compliance durchzusetzen und Verfügbarkeit (Uptime) über verteilte Systeme hinweg aufrechtzuerhalten.

Welche Beispiele gibt es für Sicherheitsrisiken in der Cloud?

Gängige Cloud-Risiken sind:

• Öffentlich zugängliche Storage-Buckets
• IAM-Rollen mit übermäßigen Berechtigungen
• Inaktive Dienstkonten mit hinterlegten Zugangsdaten
• Mit ausgeweiteten Zugriffsrechten ausgeführte Container
• Cloud-übergreifende, nicht ordnungsgemäß begrenzte Vertrauensstellungen

Tenable bringt diese Risiken ans Licht und priorisiert sie – durch Erkennung von Fehlkonfigurationen in Echtzeit und entsprechende Analysen von Identitätsrisiken.

Welche Services fallen in den Anwendungsbereich von Cloud-Sicherheit?

• Echtzeit-Risikobewertung in AWS, Azure und GCP
• Analysen von Rollen und Richtlinien
• CIEM zur Steuerung von Berechtigungen und Identitäten
• Image- und Container-Scanning in CI/CD-Pipelines
• Compliance-Reporting in Abstimmung mit Frameworks wie SOC 2, ISO 27001 und FedRAMP

Worin bestehen die größten Herausforderungen im Bereich Cloud-Sicherheit?

Zu den größten Herausforderungen im Bereich Cloud-Sicherheit zählen:

• Mangelnde einheitliche Sichtbarkeit über Multi-Cloud-Bereitstellungen hinweg
• Ungenutzte oder übermäßige Berechtigungen, die Angreifer ausnutzen
• Drift zwischen vorgesehenen und tatsächlichen Infrastrukturkonfigurationen
• Schatten-IT und nicht verwaltete Assets
• Compliance-Durchsetzung in sich schnell verändernden Umgebungen

Wie hoch ist das Durchschnittsgehalt eines Cloud-Sicherheitsexperten?

In den USA verdient ein Cloud-Sicherheitsingenieur (Cloud Security Engineer) in der Regel zwischen 140.000 und 180.000 USD. Architekten und DevSecOps-Verantwortliche hingegen können je nach Berufserfahrung, Standort und Plattformkenntnissen zwischen 170.000 und 220.000 USD verdienen. Kompetenzen in den Bereichen Kubernetes, CNAPP und CIEM führen zu einer entsprechend höheren Vergütung.

Cloud-Umgebungen werden ihre rasante Entwicklung fortsetzen, genau wie damit verbundene Risiken. 

Durch Fehlkonfigurationen, Identitäten mit übermäßigen Zugriffsrechten und gefährdete Workloads entstehen dynamische Exposure-Pfade in Multi-Cloud-Infrastrukturen. Sicherheitsteams benötigen Sichtbarkeit und Kontrolle.

Über eine integrierte, für cloud-native Umgebungen konzipierte Plattform bietet Tenable Unternehmen genau dieses Maß an Kontrolle. Tenable Cloud Security führt Daten zu Fehlkonfigurationen, Identitätsrisiken und das jeweilige Workload-Verhalten in einheitlichem Kontext zusammen, sodass Teams Reaktionsmaßnahmen basierend auf der tatsächlichen Cloud-Exposure ergreifen können.

Ob Sie eine Shift-Left-Strategie entwickeln, sich auf Compliance-Audits vorbereiten oder die Komplexität von IAM entwirren möchten – Tenable hilft Ihnen, Risiken zu erkennen und entsprechende Maßnahmen zu ergreifen.