Sicherheitsarchitektur in der Public Cloud : Prinzipien, Praxis und Fallstricke

Regelmäßige Berechtigungsanalyse

Durch Wechsel bei Personal, Dienstleistern und Zuständigkeiten ist es nicht ungewöhnlich, dass in einem Cloud-Account noch Benutzer, Rollen, Berechtigungen, Richtlinien oder Zugangsdaten existieren, die man nicht mehr benötigt. Ähnlich wie in Betriebssystemen bietet IAM über die Angabe „Last Accessed Information“ die Möglichkeit, nicht länger benötigte Ressourcen zu identifizieren, um sie anschließend zu entfernen. So sind einerseits weniger Objekte zu überwachen, andererseits lassen sich mit diesen Informationen die IAM-Richtlinien besser einstellen, um dem „PoLP-Ziel“ näher zu kommen.

Hilfe bei der Berechtigungsüberprüfung bietet bei AWS der IAM Access Analyzer (https://aws.amazon.com/iam/access-analyzer/): Diese Funktion identifiziert Ressourcen, die unbeabsichtigt extern oder intern zugänglich sind. Sie ist kostenfrei und sollte in jeder produktiven Umgebung aktiviert sein. Die Ergebnisse erfordern allerdings eine Interpretation: Nicht jede gemeldete externe Freigabe ist ein Fehler – manche sind gewollt. Entscheidend ist, dass jede Freigabe eine dokumentierte, bewusste Entscheidung darstellt.

Zudem kann der IAM Access Analyzer bei der Erstellung von IAM-Richtlinien unterstützen. Dazu überprüft das Tool die AWS CloudTrail Logs und analysiert, welche Zugriffe und Aktivitäten in den Diensten durch ein IAM-Objekt (Benutzer oder Rolle) innerhalb eines bestimmten Zeitraums stattgefunden haben. Auf dieser Basis generiert das Werkzeug eine Vorlage für eine Richtlinie, die genau diese Berechtigungen umfasst und anschließend als Basis für eine optimierte Richtlinie dienen kann, die nur noch diejenigen Berechtigungen umfasst, die für den jeweiligen Anwendungsfall wirklich notwendig sind (https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html).

Multi-Faktor-Authentifizierung (MFA) konsequent durchsetzen

Seit 2024 ist eine MFA bei AWS für Root-Accounts verpflichtend. Für alle anderen privilegierten Zugriffe muss man sie organisatorisch erzwingen. FIDO2- basierte Passkeys (z.B. YubiKey) bieten dabei die beste Balance aus Sicherheit und Benutzerfreundlichkeit https://docs.aws.amazon.com/IAM/latest/UserGuide/enablemfa-for-root.html).

Aufwandseinschätzung

Die initiale Einrichtung eines sauberen IAMKonzepts erfordert je nach Komplexität einer Organisation zwischen zwei und acht Wochen. Der laufende Aufwand liegt bei etwa einem halben bis einem Personentag pro Monat für die Analyse und Nachpflege von Berechtigungen. Dieser Aufwand wird oft unterschätzt – er rechnet sich jedoch schnell, wenn man bedenkt, dass kompromittierte Credentials einer der häufigsten Angriffsvektoren in der Cloud sind.

(2) Defense in Depth

Das Prinzip der gestaffelten Verteidigung (Defense in Depth) beschreibt einen mehrschichtigen Sicherheitsansatz mit Maßnahmen auf Anwendungs-, Daten-, Netzwerk- und Infrastruktur-Ebene. Ziel ist sicherzustellen, dass ein etwaiger Angreifer auch beim Durchdringen einer Ebene auf weitere Barrieren stößt und idealerweise keinen Zugriff auf wesentliche Daten erlangt.

Dieses Konzept ist ebenfalls nicht cloudspezifisch, gewinnt aber durch umfangreich verfügbare Werkzeuge in den gängigen Cloud-Umgebungen an Umsetzbarkeit. Die Grundidee: Jede Sicherheitsebene sollte unabhängig von den anderen funktionieren, sodass das Versagen eines einzelnen Kontrollmechanismus nicht zum Totalausfall führt.

^{Abbildung 1: Die Absicherung von Identity-Management und Access-Control (IAM) nach dem „Principle of Least Privilege“ ist ein wichtiger Baustein für jedes Sicherheitskonzept in der Cloud. Zur Zugangsverwaltung aller Mitglieder eines Organisationsaccounts dient bei AWS der Delegated Administrator im IAM Identity Center.}

Anwendungsebene: Web-Application-Firewalls (WAF) filtern bekannte Angriffsmuster wie SQL-Injection oder Cross-Site-Scripting (XSS). Die Managed Rules der Cloud-Anbieter decken dabei üblicherweise die „OWASP Top 10“-Bedrohungen ab und werden kontinuierlich aktualisiert. Für den Einstieg sind sie ausreichend – bei komplexeren Anwendungen empfiehlt sich die Ergänzung durch anwendungsspezifische Regeln.

Datenebene: Grundlegende Konzepte wie Zugriffskontrollen, Datenklassifizierung und Verschlüsselung sind hier kritisch, um Informationen vor unbefugten Zugriff zu schützen – ihre geeignete Einbettung in ein Gesamtkonzept ist überdies entscheidend, um Sicherheitslücken zwischen Ebenen zu vermeiden.

Netzwerkebene: Auf dieser Ebene wirken Security-Groups und Zugangskontrolllisten (Network-ACLs) komplementär. Security-Groups sind zustandsbehaftet und einfacher zu verwalten – Network-ACLs ermöglichen hingegen ausdrückliche Deny-Regeln. In der Praxis genügen Security-Groups für die meisten Anwendungsfälle – Network-ACLs kommen primär bei regulatorischen Anforderungen an explizite Blockierungslisten zum Einsatz.

Infrastrukturebene: Die physische Sicherheit der Rechenzentren liegt vollständig in der Verantwortung des Cloud-Anbieters. Hier müssen Kunden auf Zertifizierungen (z.B. nach ISO 27001 oder SOC 2) sowie entsprechende Auditberichte vertrauen – die eigene Kontrolle beginnt erst auf der logischen Ebene. Nutzer, die für ihre eigenen Audits und regulatorischen Anforderungen eine detaillierte Aufstellung der vom Cloud-Anbieter eingesetzten Sicherheitsmaßnahmen wie Zugangskontrollen, Videoüberwachung oder redundante Energieversorgung benötigen, finden diese im Fall von AWS unter https://aws.amazon.com/trust-center/data-center/our-controls/#topic-4.

Kritische Einordnung

Die Vielzahl verfügbarer Sicherheitsdienste kann allerdings auch selbst zum Problem werden. In Kundenprojekten beobachten die Autoren regelmäßig überkonfigurierte Umgebungen, in denen sich redundante Kontrollen gegenseitig behindern oder inkonsistente Regelwerke zu schwer diagnostizierbaren Problemen führen.

Die Empfehlung lautet daher: Mit den Basisdiensten beginnen und erst bei konkretem Bedarf erweitern – nicht jede verfügbare Funktion muss überall aktiviert werden (siehe auch Abschnitt „Empfehlungen für den Einstieg“).

(3) Automatisierung

Manuelle Konfiguration ist fehleranfällig und schlecht nachvollziehbar – „Infrastructure as Code“ (IaC) verwandelt diese Problematik in eine Stärke: Sicherheitskonfigurationen werden versioniert, überprüfbar und reproduzierbar. Jede Änderung durchläuft idealerweise einen Review-Prozess, bevor sie in die produktive Umgebung gelangt.

Werkzeugwahl

Bei AWS heißt der native Dienst CloudFormation und ermöglicht die engste Integration, erfordert aber die Beschäftigung mit einer proprietären Syntax. Terraform (www.terraform.io) hat sich als Multi-Cloud-Standard etabliert und bietet mehr Flexibilität.

Wer statt „Domain-Specific Languages“ wie HCL (Terraform) gängige Programmiersprachen verwenden möchte, kann alternativ das AWS Cloud Development Kit (CDK) nutzen: Es ermöglicht die Definition von Infrastruktur- und Sicherheitsvorgaben in vertrauten Programmiersprachen und eignet sich besonders für Entwicklerteams ohne dedizierte Infrastruktur-Expertise.

Security-Baselines als Code

Auch bewährte Sicherheitskonfigurationen lassen sich als wiederverwendbare Module paketieren – neue Umgebungen können dann automatisch die definierten Standards erben. Dieses Vorgehen reduziert nicht nur den Aufwand, sondern verhindert gleichzeitig die schleichende Erosion von Sicherheitsstandards, die bei manueller Konfiguration fast unvermeidlich eintritt.

GitOps: Git als Sicherheitsinstanz

IaC entfaltet sein volles Potenzial erst, wenn man es in einen kontrollierten Änderungsprozess einbettet. GitOps etabliert Git als „Single Source of Truth“ für den gesamten Infrastrukturzustand – einschließlich aller Sicherheitskonfigurationen. Jede Änderung an Security-Groups, IAM-Policies oder WAF-Regeln durchläuft dann einen Pull-Request, wird von einem zweiten Augenpaar geprüft und hinterlässt einen unveränderlichen Audit-Trail.

Der Sicherheitsgewinn liegt in der Umkehrung des Kontrollflusses: Statt Administratoren Änderungen direkt in der Cloud-Konsole vornehmen zu lassen, synchronisiert ein GitOps-Operator den tatsächlichen Zustand kontinuierlich mit dem im Repository definierten Soll-Zustand. Abweichungen – egal ob durch manuelle Eingriffe, Fehlkonfigurationen oder Angriffe – sind damit automatisch erkennbar und können wahlweise gemeldet oder korrigiert werden. Diese „Drift-Detection“ schließt eine häufige Lücke: In klassischen IaC-Umgebungen divergieren Ist- und Soll-Zustand oft schleichend, wenn Änderungen außerhalb des definierten Prozesses erfolgen.

Werkzeuge wie ArgoCD oder Flux haben sich als GitOps-Operatoren für Kubernetes-Umgebungen etabliert. Für AWS-native Workloads bietet sich die Nutzung des AWS Cloud Development Kit (AWS CDK) an. Dieses lässt sich in Code-Verwaltungen wie Git integriern erzeugt und AWS CloudFormation Stacks, die auch die Drift-Thematik addressieren. Eine Kombination mit AWS CodePipeline und AWS CodeBuild erzeugt Konstrukte, bei denen das Git-Repository Änderungen triggert. Entscheidend ist letztlich weniger das konkrete Werkzeug als das Prinzip: keine Änderung an sicherheitsrelevanter Infrastruktur ohne dokumentierten, nachvollziehbaren Prozess!

Für Sicherheitsteams eröffnet GitOps zudem die Möglichkeit, „Guardrails“ als Code zu definieren: Policy-as-Code-Werkzeuge wie Open Policy Agent (OPA) oder AWS CloudFormation Guard lassen sich in die CI/CDPipeline integrieren und verhindern, dass nicht-konforme Konfigurationen überhaupt verteilt (deployed) werden. Der Sicherheitsreview verlagert sich damit vom reaktiven Audit zur präventiven Kontrolle im Entwicklungsprozess.

Aufwandseinschätzung

Die Umstellung auf IaC ist eine Investition! Für ein mittelständisches Unternehmen mit überschaubarer Cloud-Nutzung sollte man drei bis sechs Monate für die Migration bestehender Ressourcen einplanen. Der Return on Investment (RoI) zeigt sich in reduziertem Betriebsaufwand, schnellerer Bereitstellung neuer Umgebungen und verbesserter Compliance-Nachweisbarkeit.

Für kleinere Umgebungen mit wenigen, stabilen Workloads kann der Aufwand allerdings den Nutzen übersteigen. In mittleren und großen Umgebungen verspricht die Umsetzung eines GitOps-basierten Ansatzes jedoch erhebliche Vorteile.

(4) Verschlüsselung

Eine Verschlüsselung ruhender Daten ist bei den großen Cloud-Anbietern inzwischen Standard. Bei AWS übernimmt diese Aufgabe für den Objektspeicher S3 die Server-Side Encryption (SSE), mit welcher der Cloud-Anbieter sich um die Ver- und Entschlüsselung aufseiten des Servers kümmert. Die Schlüssel werden dabei im einfachsten Fall von AWS automatisch verwaltet, lassen sich bei Bedarf aber auch über einen Key-Management-Service (KMS) administrieren (vgl. https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html). Wer die Schlüssel kontrolliert, ist naturgemäß eine zentrale Frage der umgesetzten Security:

• Anbieterseitige Schlüsselverwaltung(SSE-S3): Dies ist die einfachste Option – der Cloud-Anbieter verwaltet die Schlüssel vollständig transparent, aus Kundensicht ändert sich nichts an der Anwendung (siehe auch https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html). Der Schutz richtet sich damit allerdings primär gegen einen physischen Diebstahl von Datenträgern – ein Szenario, das bei professionellen Rechenzentren vernachlässigbar ist.
• Kundenseitige Schlüsselkontrolle (SSE-KMS): Dies ist die empfohlene Option für sensitive Daten. Schlüssel werden im Key-Management-Service des Anbieters gespeichert, aber vom Kunden kontrolliert: Jeder Zugriff wird protokolliert, Schlüssel lassen sich rotieren und bei Bedarf widerrufen. Die Integration erfordert einen minimalen Anpassungsaufwand in der Anwendung.
• Vollständige Client-Side-Encryption: Bei der „Königsklasse“ erfolgt die Verschlüsselung außerhalb der Cloud-Infrastruktur – der Anbieter sieht somit zu keinem Zeitpunkt unverschlüsselte Daten. Dies erfüllt höchste Compliance-Anforderungen, etwa für EU-Data-Residency-Vorgaben oder regulierte Branchen. Der Aufwand ist jedoch erheblich: Kryptografische Implementierung, Schlüsselrotation und Algorithmus-Updates liegen vollständig beim Kunden. Für die praktische Umsetzung können AWS-Kunden auf Amazon S3 Encryption Client, AWS Encryption SDK oder eine serverseitige Verschlüsselung selbst-bereitgestellten Keys (SSE-C) zurückgreifen (Details siehe https://aws.amazon.com/blogs/storage/understanding-amazon-s3-client-side-encryption-options/).

AWS European Sovereign Cloud – Feigenblatt oder Gamechanger?

Mit der Verfügbarkeit der AWS European Sovereign Cloud (AWS ESC) seit Mitte Januar 2026 adressiert Amazon einen „Pain Point“, der viele europäische Organisationen bisher von der Cloud-Nutzung abgehalten hat: die Frage der digitalen Souveränität. Die neue Region in Brandenburg ist physisch und logisch vollständig von den übrigen AWS-Regionen getrennt und wird ausschließlich von EU-Bürgern betrieben (vgl. [1,2] sowie https://aws.eu/de/).

Die AWS ESC ist kein Marketing-Label für bestehende Infrastruktur, sondern eine eigenständige Konstruktion: Eine deutsche Muttergesellschaft mit mehreren Tochtergesellschaften betreibt die Infrastruktur unter deutschem Recht. Geschäftsführer sind EU-Bürger, ein Beirat aus EU-Staatsangehörigen – darunter zwei unabhängige externe Vertreter – überwacht Souveränitätsfragen. Selbst IAM, Billing und Metering wurden für die AWS ESC neu entwickelt und laufen nur in der EU.

Für den Ernstfall – etwa eine Unterbrechung der Kommunikation mit der restlichen AWS-Infrastruktur – halten bestimmte ESC-Mitarbeiter eine Replik des Quellcodes vor, um den Betrieb eigenständig aufrechterhalten zu können. Nur autorisierte AWS-Mitarbeiter der AWS ESC haben Zugang zu dieser Quellcode-Replik.

Einordnung für die Praxis

Für Behörden, Gesundheitseinrichtungen und Unternehmen in regulierten Branchen, die bisher aufgrund von Datenschutzbedenken oder regulatorischer Unsicherheit auf Legacy-Infrastruktur verharrten, eröffnet die AWS ESC neue Optionen. Eine BSI-C5-Attestierung, ISO-27001-Zertifizierung sowie SOC-Berichte liegen vor – die formalen Compliance-Anforderungen sind damit erfüllt.

Allerdings sollten Entscheider genau hinschauen: Die AWS ESC ist zum Start mit rund 90 Services verfügbar – nur ein Bruchteil des Gesamtportfolios. Wer auf spezifische Dienste angewiesen ist, muss also prüfen, ob diese bereits angeboten werden oder wann sie folgen. Die geplante Erweiterung durch Local Zones in Belgien, den Niederlanden und Portugal adressiert Anforderungen an In-Country-Data-Residency, erhöht aber auch die Komplexität bei der Architekturplanung.

Die zentrale Frage bleibt: Wie souverän ist eine „Sovereign Cloud“, die von einem US-Konzern betrieben wird? Die technischen und organisatorischen Maßnahmen sind beachtlich, aber Amazon bleibt der wirtschaftliche Eigentümer. Ob die rechtliche Konstruktion im Konfliktfall – etwa bei einem US-Gerichtsbeschluss (siehe auch S.  24) – standhält, ist juristisch nicht abschließend geklärt. Für Workloads mit höchsten Souveränitätsanforderungen – etwa im Verteidigungsbereich oder bei nachrichtendienstlich relevanten Daten – dürfte die AWS ESC allein nicht ausreichen.

Für die meisten regulierten Anwendungsfälle in Behörden und Unternehmen ist die AWS ESC jedoch ein sinnvoller Kompromiss: Sie kombiniert die Leistungsfähigkeit der AWS-Plattform mit substanziellen Souveränitätskontrollen. Organisationen, die bisher zwischen funktionsreduzierter Cloud-Nutzung und On-Premises-Verbleib wählen mussten, sollten diese neue Option ernsthaft prüfen. Eine sorgfältige Risikoanalyse, die auch geopolitische Szenarien einbezieht, bleibt jedoch unerlässlich.

Praxisempfehlung

Für die meisten Anwendungsfälle ist SSE-KMS der richtige Kompromiss aus Sicherheit und Betreibbarkeit. Client-Side-Encryption sollte man nur gezielt für besonders sensitive Datenklassen einsetzen – nicht flächendeckend. Denn der Betriebsaufwand für eine selbstverwaltete Kryptografie-Infrastruktur wird systematisch unterschätzt: Hier übernimmt der Cloud-Kunde die vollständige Verantwortung für die korrekte und umfangreiche Implementierung der kryptografischen Prozesse. Das erfasst auch Themen wie Schlüsselrotation sowie Anpassung von Algorithmen zum Schutz vor Postquantum-Angriffen. Kryptografische Kunden-Programme laufen dazu in einer Compute-Instanz, in welcher der Cloud-Betreiber mittels Confidential Computing vom Zugriff auf Daten im Verarbeitungsvorgang technisch ausgeschlossen ist. Aufgrund der damit verbundenen Komplexität beschränken selbst große SaaS-Anbieter wie SAP den Einsatz von Client-Side-Encryption auf klar definierte Szenarien.

Transport-Verschlüsselung (TLS) für alle Verbindungen ist jedoch nicht verhandelbar! Der AWS Certificate Manager vereinfacht an dieser Stelle die Zertifikatsverwaltung erheblich und eliminiert das Risiko abgelaufener Zertifikate – zudem unterstützt er auch hybride Szenarien, bei denen man Workloads sowohl on-Premises als auch in den AWS betreibt. Für besonders kritische Anwendungsfälle lassen sich Verbindungen zwischen eigenen Rechenzentren und der Cloud durch zusätzliche Verschlüsselungsschichten auf Netzwerkebene integrieren – etwa durch IPsec-basierte VPN-Tunnel oder AWS-Direct-ConnectLeitungen mit MACsec-Verschlüsselung.

(5) Incident-Response

Heutzutage ist klar: Sicherheitsvorfälle werden eintreten – die Frage ist nur, wann und wie gut man darauf vorbereitet ist. Incident-Response- und Wiederherstellungsprozesse sollten daher idealerweise schon im Architekturdesign definiert sein und regelmäßig getestet werden. In der Cloud lässt sich die Reaktionsfähigkeit hierbei deutlich verbessern, weil die Infrastruktur selbst programmierbar ist.

• Dokumentierte Playbooks: Für die häufigsten Szenarien – kompromittierte Credentials, verdächtige API-Aktivitäten, Ransomware-Verdacht – sollten standardisierte Reaktionspläne existieren. Diese Pläne definieren Zuständigkeiten, Eskalationswege und konkrete technische Maßnahmen – denn in der Hektik eines Vorfalls fehlt die Zeit, diese Entscheidungen ad hoc zu treffen.
• Automatisierte Erstreaktion: Bestimmte Maßnahmen lassen sich automatisieren – etwa das Sperren verdächtiger Accounts, das Isolieren kompromittierter Instanzen oder das Sichern von Forensik-Daten. Serverless Functions ermöglichen in Kombination mit Step-Functions komplexe Reaktionsketten, die in Sekunden ablaufen. Eine solche Automatisierung sollte man jedoch konservativ einsetzen: False Positives, die automatisch zu Systemsperrungen führen, können schließlich ebenfalls erheblichen Schaden anrichten.
• Geo-Resilienz: Multi-Region-Architekturen ermöglichen die Fortsetzung des Betriebs auch bei großflächigen Ausfällen. Der Amazon Application Recovery Controller (ARC) bietet hierbei Werkzeuge zur Automatisierung von Failover-Szenarien an (siehe https://aws.amazon.com/application-recovery-controller/). Die Komplexität und die Kosten solcher Architekturen sind allerdings erheblich und nur für geschäftskritische Anwendungen mit hohen Verfügbarkeitsanforderungen gerechtfertigt.

Testbarkeit als Cloud-Vorteil

Ein unterschätzter Vorteil der Cloud liegt darin, Disaster-Recovery-Pläne testen zu können, ohne Produktivsysteme zu gefährden: Im eigenen Rechenzentrum ist ein echter Failover-Test oft mit erheblicher Downtime und Kosten verbunden. In der Cloud lässt sich eine vollständige Testumgebung temporär provisionieren, der Ernstfall simulieren und die Umgebung anschließend wieder abbauen.

(6) Angriffsfläche minimieren

Die einfachste Sicherheitsregel lautet: Was nicht erreichbar ist, lässt sich nicht angreifen. In der Cloud wird diese Regel jedoch oft verletzt, weil die Bereitstellung öffentlicher Endpunkte so trivial ist.

Grundbaustein ist hier der geschickte Einsatz von optimal konfigurierten virtuellen Netzwerkfunktionen des Anbieters, im Falle von AWS der Amazon Virtual Private Cloud (VPC) (https://docs.aws.amazon.com/de_de/vpc/latest/userguide/what-is-amazon-vpc.html).

VPC ermöglicht es, AWS-Ressourcen wie virtuelle Maschinen in einem logisch isolierten Bereich der AWSCloud zu betreiben. Innerhalb einer VPC lässt sich das virtuelle Netzwerk vollständig kontrollieren – inklusive eigener IP-Adressbereich, Subnetze, Routing-Tabellen und Netzwerk-Gateways. So kann man öffentliche Subnetze für Webserver mit Internetzugang vorsehen, während sensible Backend-Systeme in „privaten“ Subnetzen ohne Internetzugang arbeiten – mehrere Sicherheitsebenen, darunter Security-Groups und Netzwerk-ACLs, ermöglichen eine granulare Steuerung des Zugriffs.

• Private Subnetze als Standard: Backend-Systeme, Datenbanken und interne Dienste gehören in private Subnetze ohne Internet-Gateway. Der Zugriff dorthin erfolgt über definierte Einstiegspunkte – Bastion-Hosts, VPN-Verbindungen oder Systems Manager Session Manager, der einen Secure-Shell-(SSH)-Zugriff ohne offene Ports ermöglicht.
• VPC-Endpoints nutzen: Der Zugriff auf CloudDienste kann auch vollständig über das interne Netzwerk erfolgen, ohne den Umweg über das öffentliche Internet – Interface- und Gateway-Endpoints eliminieren die Notwendigkeit öffentlicher IP-Adressen für viele Anwendungsfälle. Die Kosten für Interface-Endpoints sind zwar nicht unerheblich, aber in sensiblen Umgebungen gut investiert.
• API-Zugriffe einschränken: Private API-Gateways machen Schnittstellen nur innerhalb definierter Netzwerke verfügbar. Das eignet sich besonders für interne Microservices oder B2B-Integrationen, die keinen öffentlichen Zugang benötigen.

Praktischer Betrieb

Die beste Sicherheitsarchitektur nützt wenig, wenn sie im Betrieb nicht überwacht wird. Cloud-Anbieter wie AWS stellen hierfür umfangreiche Werkzeuge bereit, deren sinnvolle Kombination aber einiges an Überlegung erfordert.

Werkzeuglandschaft und Einordnung

• Konfigurationsüberwachung: AWS Config Rules prüft kontinuierlich, ob Ressourcen definierten Standards entsprechen und ist unverzichtbar für Compliance-Nachweise und die Erkennung von Configuration-Drift. Die vorgefertigten Regeln decken gängige Best Practices ab – für spezifische Anforderungen lassen sich eigene Regeln entwickeln. Empfehlung: von Anfang an aktivieren, auch in kleineren Umgebungen.
• Bedrohungserkennung: Amazon GuardDuty analysiert CloudTrail-Logs, VPC-Flow-Logs und DNS-Anfragen mittels Machine-Learning (ML) auf verdächtige Muster. Die Erkennung von Anomalien – etwa API-Aufrufe zu ungewöhnlichen Zeiten oder aus unerwarteten Regionen – funktioniert in der Praxis gut. Die Kosten skalieren mit dem Datenvolumen; bei sehr großen Umgebungen sollte man die Kostenentwicklung aufmerksam beobachten. Empfehlung: standardmäßig aktivieren.
• Zentrales Sicherheits-Dashboard: AWS Security Hub aggregiert Findings aus verschiedenen Quellen und normalisiert sie in ein einheitliches Format. Das ist nützlich für die Priorisierung und das Reporting, ersetzt aber nicht die Auseinandersetzung mit Einzelbefunden. Einschätzung: in Multi-Account-Umgebungen unverzichtbar – in einfachen Szenarien optional.
• Forensik und Analyse: Amazon Detective ermöglicht die tiefer gehende Untersuchung von Sicherheitsvorfällen durch eine Visualisierung von Zusammenhängen zwischen Entitäten. Einschätzung: sinnvoll für Organisationen mit eigenem Security-Operations-Team – für kleinere Unternehmen oft überdimensioniert.
• Log-Aggregation: Amazon Security Lake zentralisiert Sicherheitslogs im Open Cybersecurity Schema Framework – OCSF (https://github.com/ocsf) und ermöglicht die Einbindung externer Quellen. Einschätzung: relevant für Unternehmen, die ein übergreifendes SIEM betreiben oder Logs langfristig für Compliance-Zwecke vorhalten müssen.

^{Abbildung 2: Über das Amazon API Gateway bleiben sensible API-Schnittstellen nur innerhalb klar definierter Netzwerke erreichbar.}

Empfehlungen für den Einstieg

Die Versuchung liegt nahe, alle verfügbaren Dienste zu aktivieren. Für den Einstieg empfehlen die Autoren jedoch einen gestaffelten, aufeinander aufbauenden Ansatz:

• Stufe 1 (Basis):CloudTrail für API-Logging, Config für Konfigurationsüberwachung, GuardDuty zur Bedrohungserkennung. Diese drei Dienste bilden das Minimum für eine überwachte Umgebung – die Kosten sind überschaubar, der Betriebsaufwand gering.
• Stufe 2 (Konsolidierung):Security Hub zur Aggregation und Priorisierung (bes. bei mehreren Accounts), automatisierte Reaktionen über Amazon EventBridge sowie AWS Lambda für wiederkehrende Findings.
• Stufe 3 (erweitert): Amazon Detective für Forensik, Amazon Security Lake für zentrale Log-Analyse sowie eine Integration mit externen SIEM-Systemen – diese Stufe erfordert dediziertes Security-Personal.

Kritische Betrachtung: Wo liegen die Grenzen?

Bei aller Leistungsfähigkeit der nativen Sicherheitsdienste sollte man nicht übersehen, dass dennoch einige Einschränkungen verbleiben:

• Shared Responsibility als Verantwortungsdiffusion: Das geteilte Verantwortungsmodell klingt in der Theorie klar, führt in der Praxis aber zu Grauzonen. Wo genau die Verantwortung des Anbieters endet und die des Nutzers beginnt, ist bei manchen Diensten nicht trivial entscheidbar. Die häufigste Ursache von Cloud-Sicherheitsvorfällen liegt zudem mit Fehlkonfigurationen regelmäßig auf der Kundenseite – Werkzeuge zur Erkennung solcher Probleme sind verfügbar, aber der Kunde muss sie aktiv nutzen und interpretieren.
• Komplexität als Risiko: Auch die Vielzahl der Dienste und Konfigurationsoptionen selbst kann zum Sicherheitsrisiko werden. Inkonsistente Regelwerke, vergessene Testkonfigurationen oder schlicht das Nichtverstehen von Dienst-Interaktionen führen zu Lücken. Die Einarbeitung in ein Sicherheitsökosystem erfordert Zeit und Expertise, die nicht in jedem Unternehmen vorhanden ist.
• Vendor-Lock-in bei der Sicherheit: Wer native Sicherheitsdienste intensiv nutzt, bindet sich zusätzlich an den Anbieter – die Migration zu einem anderen Hyperscaler erfordert dann den Neuaufbau der gesamten Sicherheitsarchitektur. Das ist kein Argument gegen die Nutzung solcher Dienste, sollte aber bei strategischen Entscheidungen berücksichtigt werden!
• Überraschende Kosten: Viele Sicherheitsdienste rechnen nach Datenvolumen oder Ereignisanzahl ab. In großen aktiven Umgebungen können sich beispielsweise die Kosten für Amazon GuardDuty, AWS Config oder Amazon CloudTrail durchaus erheblich aufsummieren – eine regelmäßige Kostenüberwachung gehört daher zum Pflichtprogramm!

Fazit

Sicherheit ist kein Zustand, sondern ein Prozess – das gilt umso mehr in der Cloud. Die vorgestellten Architekturprinzipien bilden ein gutes Security-Fundament, erfordern aber kontinuierliche Pflege, Anpassung an neue Bedrohungen und regelmäßige Überprüfung.

Für Unternehmen, die ihre Cloud-Sicherheit systematisch aufbauen wollen, empfiehlt sich ein pragmatischer Ansatz: Mit den Grundlagen beginnen – IAM, Netzwerksegmentierung, Verschlüsselung, Basis-Überwachung – und die Architektur schrittweise erweitern. Die verfügbaren Werkzeuge sind mächtig, aber sie ersetzen nicht das Verständnis der eigenen Bedrohungslandschaft und die organisatorische Verankerung von Sicherheitsverantwortung.

Die Cloud bietet gegenüber eigenen Rechenzentren echte Sicherheitsvorteile: bessere physische Sicherheit, schnellere Patches, umfangreichere Überwachungsmöglichkeiten. Diese Vorteile lassen sich aber nur realisieren, wenn die Konfiguration stimmt und man bereitgestellte Werkzeuge auch nutzt. Die größte Sicherheitslücke in der Cloud ist nicht technischer Natur: Sie liegt in der Annahme, der Anbieter werde sich schon um alles kümmern.

Simon Lehmeyer ist Platform Engineering Consultant bei der Söldner Consult GmbH.

Gerald Boyne ist freier Berater zu IT-Security & Compliance, Resilienz und Souveränität.

Prof. Dr. Jens-Henrik Söldner unterrichtet Wirtschaftsinformatik und IT-Sicherheit an der Hochschule Ansbach und ist Managing Director der Soeldner Consult GmbH.

Literatur

_{[1] Amazon Web Services (AWS), AWS Digital Sovereignty – Mehr Auswahl für Ihre Daten, undatiert, https://aws.amazon.com/de/compliance/europe-digital-sovereignty/}

_{[2] Bundesamt für Sicherheit in der Informationstechnik (BSI), AWS European Sovereign Cloud startet: BSI unterstützt bei Ausgestaltung von Sicherheits- und Souveränitätsmerkmalen, Pressemitteilung, Januar 2026, www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260115_BSI_ AWS_European_Cloud.html}