Cloud-Sicherheit, Identitäten und Compliance

Bei der Cloud-Sicherheit teilen sich Anbieter und Kunde die Arbeit. Ordne die Aufgaben nach der Schicht zu, die die jeweilige Seite betreibt. Berücksichtige dabei auch die Einstellungen, die der Kunde wählt.

Infrastruktur und Kundenentscheidungen unterscheiden

AWS bezeichnet den Schutz der Infrastruktur als Sicherheit der Cloud. Dazu gehören Einrichtungen, physische Server, Speicher, Netzwerkgeräte und der Hypervisor, der virtuelle Maschinen auf einem Host voneinander trennt. Kunden übernehmen die Sicherheit in der Cloud: ihre Daten, Identitäten und Konfiguration. Azure und Google Cloud verwenden dieselbe grundlegende Aufteilung. Googles Ansatz Shared Fate ergänzt sichere Voreinstellungen, Anleitungen und Werkzeuge, die Kunden helfen, ihren Teil abzusichern.

Anbieter kontrollieren den physischen Zutritt, Stromversorgung, Kühlung, Hardwarewartung und die sichere Ausmusterung von Laufwerken. Unabhängige Prüfer untersuchen diese Schichten; Kunden nutzen deren Berichte, um Maßnahmen zu beurteilen, die sie nicht selbst betreiben.

Aufgaben des Kunden zuweisen

Über alle Dienstmodelle hinweg bleibt der Kunde verantwortlich für:

• Daten: Klassifizierung, Zugriff, Schutzentscheidungen und Aufbewahrung.
• Konten: Erstellen, Pflegen und Entfernen von Identitäten.
• Zugriffsverwaltung: Rollen, MFA und Anmelderichtlinien.
• Clientgeräte: Schutz der Laptops und Smartphones, die für die Verbindung genutzt werden.

Vom Kunden gewählte Einstellungen bleiben Aufgabe des Kunden. Ein öffentlicher Bucket, eine Datenbankregel, die Zugriff aus dem Internet erlaubt, oder ein nicht mehr genutztes Administratorkonto können eine Workload offenlegen, selbst wenn die Infrastrukturmaßnahmen des Anbieters korrekt funktionieren.

Einige Maßnahmen werden geteilt, weil jede Seite sie auf ihren eigenen Schichten durchführt. Der Anbieter spielt Patches für die Infrastruktur ein; Kunden patchen die Betriebssysteme und Anwendungen, die sie verwalten. Jede Seite konfiguriert ihre eigenen Systeme und schult ihre eigenen Mitarbeiter. Weise bei einer geteilten Maßnahme beide Seiten zu, damit keine übersehen wird.

Die Aufteilung auf die Rechnungsspeicherung anwenden

Ein Unternehmen speichert Rechnungen in einem Cloud-Bucket. Der Anbieter patcht den Speicherdienst, ersetzt ausgefallene Laufwerke und mustert Datenträger sicher aus. Das Unternehmen stellt den Bucket auf privat, gibt seiner Abrechnungsrolle den benötigten Lesezugriff und verlangt MFA für diese Benutzer. Außerdem wählt es Verschlüsselungseinstellungen, aktiviert die benötigten Zugriffsprotokolle und legt fest, wie lange Rechnungen aufbewahrt werden.

Macht ein Mitarbeiter den Bucket öffentlich, muss der Kunde die Berechtigung korrigieren und die Offenlegung untersuchen. Der Speicherdienst kann als Antwort auf eine vom Kunden erlaubte Anfrage lesbare Inhalte ausgeben; physischer Schutz kann diese Zugriffsgewährung nicht rückgängig machen.

Cloud-Infrastruktur und spezialisierte Sicherheitswerkzeuge können einem kleinen Team Schutz bieten, den es allein nicht aufbauen könnte. Für optionale Funktionen braucht es weiterhin Verantwortliche, die sie konfigurieren und Ergebnisse prüfen. Prüfe bei der Zuweisung dieser Aufgaben die Hinweise zur Verantwortung für jeden Dienst.

Je stärker Dienste verwaltet sind, desto mehr Betriebsarbeit geht an den Anbieter über. Entscheidungen des Kunden über Identitäten, Daten und Einstellungen bleiben bei diesen Veränderungen bestehen.

Die Schichten vergleichen

Bei PaaS können Aufgaben für Anwendungen und Netzwerk geteilt sein. SaaS-Kunden konfigurieren Anwendungsfunktionen, obwohl der Anbieter den Dienst betreibt; auch die Geräteverwaltung kann geteilt sein. Prüfe den jeweiligen Dienst und die jeweilige Funktion auf die genaue Abgrenzung.

Die Dienste durchgehen

Bei einem Webserver auf Amazon EC2, Azure Virtual Machines oder Google Compute Engine installiert der Kunde Sicherheitsupdates für das Gastbetriebssystem und wartet den Webserver. Er beschränkt die Fernadministration mit AWS-Sicherheitsgruppen, Azure-Netzwerksicherheitsgruppen oder Google-Cloud-Firewallregeln und wählt Datenträgerschutz und Datensicherungen.

Bei Amazon RDS, Azure SQL Database oder Google Cloud SQL wartet der Anbieter das zugrunde liegende Betriebssystem und die verwaltete Datenbank-Engine. Der Kunde wählt weiterhin erlaubte Netzwerkwege, Benutzer, Berechtigungen, Verschlüsselungseinstellungen, die Aufbewahrungsdauer von Datensicherungen und verfügbare Wartungsfenster. Die Möglichkeit automatisierter Datensicherungen entscheidet nicht darüber, wie lange das Unternehmen seine Unterlagen benötigt.

Bei AWS Lambda, Azure Functions oder Google Cloud Run functions muss der Kunde dank anbieterverwalteter Laufzeitumgebungen keine Server und Laufzeitumgebungen patchen. Kunden aktualisieren weiterhin mitgelieferte Abhängigkeiten, prüfen Eingaben, schützen Geheimnisse und beschränken Ausführungs- und Aufrufberechtigungen. Benutzerdefinierte Laufzeitumgebungen oder Container bringen zusätzliche Wartungsaufgaben mit sich.

Bei Microsoft 365 oder Google Workspace patcht der Anbieter die Office-Anwendung. Kunden entfernen ausgeschiedene Mitarbeiter, steuern externe Freigaben und legen die Aufbewahrung fest. Einige Organisationen pflegen außerdem eigene SaaS-Datensicherungen.

Eine unbekannte Aufgabe zuweisen

Benenne die Schicht, bestimme das Dienstmodell und sieh dann in dessen dokumentierter Aufteilung nach. Ein ausgefallener physischer Datenträger ist in jedem Modell Aufgabe des Anbieters. Ein Update des Gastbetriebssystems einer VM ist Aufgabe des Kunden; ein Betriebssystemupdate unter einer verwalteten Datenbank ist Aufgabe des Anbieters. Die Berechtigung eines Datenbankbenutzers bleibt eine Entscheidung des Kunden. Führe für jeden Dienst eine Aufgabenliste, wenn eine Organisation mehrere Modelle zusammen nutzt.

Cloud-Zugriff beginnt damit, eine Person oder Anwendung zu identifizieren. Anschließend werden die Berechtigungen dieser Identität geprüft. Wenn du diese Entscheidungen trennst, verstehst du besser, warum auch eine erfolgreiche Anmeldung mit einer Meldung über verweigerten Zugriff enden kann.

Identität nachweisen, dann Berechtigung prüfen

Die Authentifizierung stellt fest, wer oder was eine Anfrage stellt. Die Autorisierung entscheidet, ob diese Identität die angeforderte Aktion ausführen darf. Die Prüfprotokollierung hält fest, was geschehen ist. Ein Passwort und MFA können einen Benutzer authentifizieren; eine Rolle kann diesem Benutzer trotzdem die Berechtigung verweigern, eine Datenbank zu löschen.

In Azure und Google Cloud verbinden Rollenzuweisungen Personen, Gruppen oder Workloads mit Berechtigungen. In AWS entstehen durch das Annehmen einer IAM-Rolle temporäre Sitzungszugangsdaten. Eine Workload sollte diesen unterstützten Identitätsmechanismus nutzen, statt das Passwort einer Person in eine Konfigurationsdatei zu kopieren.

Die Bezeichnungen der Anbieter erkennen

AWS IAM stellt Benutzer, Gruppen und Rollen bereit. IAM Identity Center unterstützt den Zugriff von Mitarbeitern über AWS-Konten hinweg. Microsoft Entra ID, früher Azure Active Directory, ist das Cloud-Verzeichnis von Azure mit Benutzern, Gruppen, Dienstprinzipalen und verwalteten Identitäten. Google Cloud verwendet Konten und Gruppen in Cloud Identity oder Google Workspace sowie Dienstkonten für Workloads.

Eine EC2-Instanz kann eine IAM-Rolle erhalten, eine Azure-Ressource eine verwaltete Identität und eine Google-Cloud-VM ein zugewiesenes Dienstkonto. Die Plattform stellt für unterstützte Zugriffe kurzlebige Zugangsdaten bereit, sodass kein langfristiges Passwort gespeichert werden muss.

Der AWS-Root-Benutzer hat weitreichende Rechte im gesamten Konto. Azure und Google Cloud verteilen weitreichenden Zugriff über Rollen wie Entra Global Administrator, Abonnement-Owner und Projekt-Owner. Diese Rollen haben unterschiedliche Geltungsbereiche: Die Rolle eines Verzeichnisadministrators ist nicht mit der eines Ressourcenadministrators austauschbar.

Zentral anmelden

Mit Single Sign-on (SSO) kann eine Person eine Anmeldung für mehrere Anwendungen nutzen. Die Identitätsföderation ist die Vertrauensbeziehung, durch die eine Cloud oder Anwendung Identitätsinformationen eines anderen Identitätsanbieters akzeptieren kann, häufig über SAML 2.0 oder OpenID Connect.

Ein Unternehmen verwendet Entra ID für 200 Mitarbeiter und richtet den föderierten Zugriff auf AWS und Google Cloud ein. Verlässt eine Fachkraft das Unternehmen, verhindert das Deaktivieren des zentralen Kontos neue Anmeldungen. Das Unternehmen muss außerdem aktive Sitzungen widerrufen und unabhängige lokale Konten und Zugriffsschlüssel entfernen. Diese Zugangswege können ohne erneute zentrale Anmeldung weiter funktionieren.

Partner können externe Identitäten verwenden: Entra-B2B-Gastzugriff, eine kontoübergreifende AWS-Rolle oder Google-Cloud-Rollen für externe Prinzipale. Ihr Arbeitgeber verwaltet ihre Identität bei der eigenen Organisation; deine Organisation steuert ihren Zugriff auf deine Ressourcen.

Ältere Anwendungen benötigen möglicherweise Domänenbeitritt, Kerberos, NTLM oder LDAP. Zu den verwalteten Verzeichnisangeboten gehören Entra Domain Services, AWS Directory Service und Google Cloud Managed Service for Microsoft Active Directory. Sie erfüllen andere Anwendungsanforderungen als eine moderne Cloud-Anmeldung allein.

Eine Berechtigung verbindet eine Aktion mit einer Ressource. „Objekte in diesem Bucket lesen“ ist genauer als „Speicher nutzen“. Anbieter bündeln Berechtigungen in Rollen oder Richtlinienanweisungen und weisen sie dann Identitäten oder Ressourcen zu.

Wer, was und wo zuordnen

Die rollenbasierte Zugriffssteuerung (RBAC) vergibt Berechtigungen über Rollen, die zu beruflichen Aufgaben passen. Eine Azure-Rollenzuweisung besteht aus drei Teilen: dem Sicherheitsprinzipal, der Rollendefinition und dem Geltungsbereich. Die Geltungsbereiche reichen von der Verwaltungsgruppe über das Abonnement und die Ressourcengruppe bis zur einzelnen Ressource. Zuweisungen werden an Ressourcen innerhalb ihres Geltungsbereichs nach unten vererbt.

Priya hat Reader für das Abonnement Prod und Contributor für dessen Ressourcengruppe web-rg. Sie kann Ressourcen in ganz Prod anzeigen und Ressourcen in web-rg ändern. Sie kann weder db-rg ändern noch über Contributor einer anderen Person Zugriff gewähren. Azure addiert die Berechtigungen aus den Zuweisungen; unterstützte Azure-Funktionen können Verweigerungszuweisungen erstellen, die ansonsten erlaubte Aktionen blockieren.

Google-Cloud-Erlaubnisrichtlinien binden Prinzipale an Rollen für Ressourcen. Der Zugriff wird über Organisation, Ordner, Projekte und Ressourcen hinweg vererbt. Anstelle der weitreichenden Basisrollen Owner, Editor und Viewer sollten passende dienstspezifische vordefinierte oder benutzerdefinierte Rollen treten. Das Bearbeiten der Erlaubnisrichtlinie einer untergeordneten Ebene entfernt keinen Zugriff, der auf der übergeordneten Ebene gewährt wurde. Ändere die Berechtigung auf der übergeordneten Ebene oder wende gegebenenfalls eine unterstützte Verweigerungsrichtlinie an.

Eine AWS-Anfrage auswerten

Eine AWS-IAM-Richtlinie ist ein JSON-Dokument mit Anweisungen, die einen Effect, eine Action, einen Resource-ARN und optionale Bedingungen enthalten. Richtlinien können Identitäten zugewiesen werden; eine Ressourcenrichtlinie wie eine Bucket-Richtlinie wird an die Ressource gebunden. Von AWS verwaltete Richtlinien werden vom Anbieter gepflegt, kundenverwaltete Richtlinien sind wiederverwendbare Dokumente des Kunden und Inline-Richtlinien gehören zu einer Identität.

Für eine grundlegende Entscheidung über eine Anfrage:

1. Beginne mit der impliziten Verweigerung: Es gibt noch keine Berechtigung.
2. Suche eine anwendbare ausdrückliche Erlaubnis und prüfe jede anwendbare Berechtigungsgrenze.
3. Wende jede ausdrückliche Verweigerung an: Sie hat Vorrang vor Erlaubnissen.

Eine Service-Kontrollrichtlinie (SCP) von AWS Organizations begrenzt die maximal verfügbaren Berechtigungen. Sie gewährt selbst keine Berechtigungen. Eine Anfrage außerhalb der von der SCP erlaubten Grenze scheitert, selbst wenn eine Identitätsrichtlinie sie erlaubt.

Die Gruppe von Lena darf sales-reports/* lesen, und keine Leitplanke schränkt diesen Lesezugriff ein. Ein Download ist erlaubt. Ein Upload scheitert, weil keine Erlaubnis für s3:PutObject vorliegt. Eine separate Richtlinie verweigert das Löschen ausdrücklich; auch wenn später s3:* hinzugefügt wird, kann das Löschen nicht erlaubt werden. Für das Lesen eines anderen Buckets fehlt ebenfalls eine Erlaubnis.

Ressourcenverwaltung und Datenzugriff unterscheiden

Ein Administrator kann ein Speicherkonto über die Steuerungsebene verwalten, ohne eine Entra-Datenrolle zum Lesen seiner Blobs über die Datenebene zu erhalten. Für diesen Lesezugriff ist eine Rolle wie Storage Blob Data Reader nötig. Prüfe Aktion und Geltungsbereich, statt anzunehmen, dass eine weitreichende Ressourcenverwaltungsrolle jede Frage zum Datenzugriff beantwortet.

Das Prinzip der geringsten Rechte gibt einer Identität die Aktionen, Ressourcen und Zeit, die ihre Aufgabe benötigt. Es verringert den Schadensradius: das Ausmaß des Schadens, den ein Fehler oder gestohlene Zugangsdaten verursachen können.

Eine gezielte Berechtigung erstellen

Liste zuerst die Arbeit auf, wähle eine eng gefasste Rolle oder Richtlinie, lege den kleinsten sinnvollen Geltungsbereich fest und verwalte Personen über Gruppen oder Rollen. Begrenze privilegierten Zugriff zeitlich und überprüfe ihn regelmäßig. Ein externer Auftragnehmer, der 30 Tage lang Protokolle in einen Bucket hochlädt, benötigt dort Uploadzugriff, keinen Lesezugriff auf den gesamten Speicher und keine dauerhafte Administratoridentität.

Just-in-Time-Zugriff begrenzt, wann jemand erweiterte Berechtigungen erhalten kann. Entra Privileged Identity Management kann für eine zeitlich begrenzte Aktivierung Genehmigung und MFA verlangen. Google Privileged Access Manager gewährt auf Anfrage temporäre Rollen. AWS-Rollen geben über Security Token Service zeitlich begrenzte Zugangsdaten aus. Das dauerhafte Recht, eine Administratorrolle anzunehmen, ermöglicht jedoch wiederholt neue Sitzungen. Kurzlebige Zugangsdaten allein beseitigen keine dauerhaften Privilegien.

Die Funktionstrennung gibt verschiedenen Personen die Kontrolle über sensible Teile eines Prozesses. Wer eine Änderung beantragt, sollte sie nicht selbst genehmigen; auch Schlüsselverwaltung und Datenlesen sollten getrennt sein.

Privilegierte Identitäten schützen

Aktiviere MFA für den AWS-Root-Benutzer, gib ihm ein starkes, einzigartiges Passwort und erstelle keine Root-Zugriffsschlüssel. Nutze ihn nur für Aufgaben, die Root erfordern. Beispiele sind das Ändern seiner E-Mail-Adresse oder seines Passworts, das Schließen eines eigenständigen Kontos, die Wiederherstellung nach dem Aussperren eines IAM-Administrators, das Aktivieren des IAM-Abrechnungszugriffs, die Registrierung als Verkäufer im EC2 Reserved Instance Marketplace und das Aktivieren von S3 MFA Delete. Organisationen können Root-Zugangsdaten von Mitgliedskonten zentral entfernen.

Halte Rollen mit weitreichenden Berechtigungen in Entra und Google Cloud streng begrenzt. Microsoft empfiehlt weniger als fünf Global Administrators. Administratoren benötigen getrennte Identitäten für den Alltag und für privilegierte Aufgaben sowie phishingresistente MFA. Die Entra-Planung für Notfallzugriff sieht zwei sicher aufbewahrte und überwachte Notfallkonten (Break-Glass) vor, damit bei einem Ausfall der normalen Anmeldung nicht alle ausgesperrt werden. Die Gestaltung der Notfallkonten folgt den eigenen Vorgaben des Anbieters.

Kurzlebigen Zugriff und verwaltete Geheimnisse bevorzugen

Langfristige Zugriffsschlüssel bleiben nutzbar, bis sie deaktiviert oder gelöscht werden. Bevorzuge Workload-Identitäten, Rollen und SSO. Rotiere unvermeidbare Schlüssel und halte sie aus dem Quellcode heraus. Wird ein Schlüssel offengelegt, entziehe den damit möglichen Zugriff; das Löschen eines sichtbaren Codefragments widerruft die Zugangsdaten nicht.

Speichere Datenbankpasswörter, API-Schlüssel und Zertifikate in AWS Secrets Manager oder Systems Manager Parameter Store, Azure Key Vault oder Google Cloud Secret Manager. Anwendungen rufen benötigte Geheimnisse zur Laufzeit über Workload-Identitäten ab. Konfiguriere bei Bedarf die Erfassung von Auditprotokollen, etwa über Diagnoseeinstellungen von Azure Key Vault.

Die NIST-Empfehlung von 2025 verlangt für verbleibende Passwörter mindestens 15 Zeichen bei Verwendung als einziger Faktor oder mindestens 8 als Teil von MFA sowie die Unterstützung von mindestens 64 Zeichen. Sie verlangt den Abgleich mit häufig verwendeten und kompromittierten Passwörtern, lehnt vorgeschriebene Zeichenkombinationen und regelmäßige geplante Änderungen ab und verlangt eine Änderung bei Verdacht auf Kompromittierung.

Nutze Nachweise, um Zugriffe zu reduzieren: AWS IAM Access Analyzer, Zugangsdatenberichte und Daten zum letzten Zugriff; Entra-Zugriffsüberprüfungen; und Google-IAM-Rollenempfehlungen. Erlaubt eine Rolle 40 Dienste, von denen in 90 Tagen nur 3 genutzt wurden, überprüfe die Berechtigungen für die anderen 37 Dienste. Prüfe vor dem Entfernen anstehende berechtigte Aufgaben; Inaktivität zeigt Kandidaten für eine Prüfung, aber nicht den gesamten betrieblichen Bedarf.

Die Mehrfaktorauthentifizierung (MFA) verlangt mindestens zwei verschiedene Faktorkategorien: etwas, das eine Person weiß oder besitzt, oder eine Eigenschaft der Person. Ein Passwort und die Antwort auf eine Sicherheitsfrage sind beides Wissensfaktoren und bleiben eine Einfaktorauthentifizierung.

Authentifizierungsverfahren vergleichen

NIST schränkt die Zustellung über das Telefonnetz ein. Eine verbreitete TOTP-Konfiguration verwendet sechs Ziffern, die sich alle 30 Sekunden ändern: Eine Million mögliche Werte ergeben bei einem einzigen blinden Versuch eine Chance von eins zu einer Million. Implementierungen können andere Längen oder Intervalle verwenden.

Eine Phishingseite kann ein Passwort und einen aktuellen Code vor dessen Ablauf an die echte Website weiterleiten. Der an die Domain gebundene Nachweis eines Passkeys kann von der gefälschten Domain nicht für den echten Dienst wiederverwendet werden. Windows Hello for Business und unterstützte zertifikatbasierte Verfahren bieten ebenfalls phishingresistente Optionen.

Bei einem MFA-Ermüdungsangriff werden wiederholt Push-Anfragen gesendet, in der Hoffnung, dass jemand zustimmt. Der Zahlenabgleich verknüpft die Bestätigung mit einem Anmeldebildschirm und verringert so unbeabsichtigte Zustimmungen; er bietet nicht dieselbe Domainbindung wie ein phishingresistentes Verfahren.

Faktoren bei kennwortloser Anmeldung prüfen

Bei kennwortloser Anmeldung entfällt das Passwort. Ein auf einem Gerät gespeicherter Berechtigungsnachweis, der mit einer überprüften PIN oder einem biometrischen Merkmal entsperrt wird, kombiniert Besitz mit einem zweiten Faktor. Die PIN wird lokal geprüft und nicht an den Dienst gesendet. Prüfe, welche Faktoren das konkrete Verfahren überprüft, bevor du es als MFA einordnest. Google nennt seinen MFA-Dienst 2-Step Verification.

Anbieter setzen MFA für einige administrative Zugriffe durch, darunter AWS Root und die Anmeldung am Azure-Portal. Kunden legen weiterhin Anforderungen für ihre eigenen Benutzer und Anwendungen fest und verwenden die stärksten Verfahren für privilegierten Zugriff.

Kontext berücksichtigen und Wiederherstellung schützen

Entra Conditional Access bewertet Benutzer, Anwendung, Gerätezustand, Standort und Anmelderisiko. Es kann erlauben, eine stärkere Authentifizierung oder ein regelkonformes Gerät verlangen oder blockieren. Verlange für die Gehaltsabrechnung ein verwaltetes Gerät und phishingresistente Authentifizierung; blockiere Anmeldungen mit hohem Risiko. AWS-IAM-Bedingungen und kontextbasierter Zugriff von Google bieten verwandte Maßnahmen mit unterschiedlichem Dienstverhalten.

Schütze die Kontowiederherstellung mit ähnlicher Sorgfalt: Ein schwacher Wiederherstellungsweg kann ein starkes Authentifizierungsverfahren ersetzen. Lehne unerwartete Bestätigungsaufforderungen ab und melde sie über den Prozess deiner Organisation. Das Prinzip der geringsten Rechte und Überwachung begrenzen weiterhin das Risiko, falls eine authentifizierte Sitzung gestohlen wird.

Verschlüsselung wandelt lesbaren Klartext mithilfe eines Schlüssels in Geheimtext um. Der richtige Schlüssel ermöglicht die Entschlüsselung. Sie schützt die Vertraulichkeit; authentifizierte Verschlüsselung erkennt außerdem Manipulationen. Sie verhindert weder eine berechtigte Löschung noch hält sie eine ausgefallene Anwendung in Betrieb.

Drei Umwandlungen unterscheiden

Base64-Text wie „aGVsbG8=“ kann von jedem zu „hello“ dekodiert werden. Er bietet keine Vertraulichkeit. Für die Passwortspeicherung ist eine bewusst langsame Passwort-Hashingfunktion mit Salt nötig, etwa Argon2, bcrypt, scrypt oder PBKDF2. Ein einzelner schneller SHA-256-Hash ist dafür ungeeignet.

Die symmetrische Verschlüsselung verwendet denselben Schlüssel zum Ver- und Entschlüsseln. AES-256 ist für große Cloud-Datenmengen verbreitet. Die asymmetrische Kryptografie verwendet ein Schlüsselpaar aus einem öffentlichen und einem privaten Schlüssel für Vorgänge wie Schlüsselaustausch und digitale Signaturen; welche Vorgänge unterstützt werden, hängt vom Algorithmus ab. Mit der Verschlüsselung durch einen öffentlichen Schlüssel kann ein Absender Daten für einen Empfänger schützen, der sie mit seinem privaten Schlüssel entschlüsselt. Eine digitale Signatur ermöglicht anderen, eine mit dem privaten Schlüssel erstellte Signatur zu prüfen.

Ein symmetrischer 256-Bit-Schlüssel hat $2^{256}\approx \mathrm{1,16}\times {10}^{77}$ mögliche Werte. Selbst bei ${10}^{18}$ Versuchen pro Sekunde dauert es etwa $\mathrm{3,7}\times {10}^{51}$ Jahre, alle zu prüfen. In der Praxis ist es viel wichtiger, den Zugriff auf Schlüssel zu schützen, als zu planen, diesen Suchraum zu überwinden.

Verschlüsselung auf gespeicherte Daten anwenden

Ruhende Daten umfassen Objekte, Datenträger, Datenbanken, Datensicherungen und Snapshots. Verschlüsselung schützt gespeicherte Rohdaten, wenn jemand ein Laufwerk erhält oder Speicher ohne den benötigten Schlüssel kopiert. Serverseitige Verschlüsselung erfolgt innerhalb des Dienstes vor dem Schreiben der Daten. Clientseitige Verschlüsselung erfolgt vor dem Upload, sodass der Anbieter Geheimtext erhält. Geht ein unersetzbarer Clientschlüssel verloren, werden die Inhalte unlesbar.

Standardeinstellungen unterscheiden sich je nach Dienst. Amazon S3 verschlüsselt seit dem 5. Januar 2023 alle neuen Objekt-Uploads standardmäßig. Azure Storage verschlüsselt gespeicherte Daten, und dies lässt sich nicht deaktivieren. Google Cloud verschlüsselt ruhende Kundendaten standardmäßig. Die standardmäßige Amazon-EBS-Verschlüsselung ist eine Kontoeinstellung, die der Kunde in jeder Region aktiviert.

Einen erlaubten Lesezugriff verfolgen

Ein Rechnungsobjekt ist auf dem Datenträger verschlüsselt. Ein Benutzer fordert es über den Speicherdienst an. Der Dienst prüft die Berechtigungen, entschlüsselt das Objekt über den konfigurierten Schlüsselmechanismus und gibt den lesbaren Inhalt an den berechtigten Benutzer zurück. Erlaubt der Kunde öffentliche Lesezugriffe, kann dieser Vorgang auch Außenstehende bedienen.

Die Verschlüsselung ruhender Daten wirkt daher mit privaten Zugriffseinstellungen und Aktivitätsprotokollierung zusammen. Beginne mit der Datenklassifizierung: öffentlich, intern, vertraulich oder streng vertraulich. Die Klassifizierung leitet Entscheidungen darüber, wer den Inhalt lesen darf, welche Anforderungen an die Schlüsselkontrolle gelten und wie lange Daten aufbewahrt werden. Datensicherungen benötigen dieselbe Aufmerksamkeit, denn auch eine geschützte Datenbank kann eine ungeschützte Kopie haben.

Ein Datensatz kann bei der Speicherung verschlüsselt und dennoch bei der Übertragung über ein Netzwerk oder bei der Verarbeitung offengelegt sein. Verfolge seinen Weg, um festzustellen, wo welcher Schutz nötig ist.

Übertragene Daten mit TLS verschlüsseln

Daten bei der Übertragung bewegen sich zwischen Browsern, Anwendungen, Datenbanken, Büros oder Regionen. Transport Layer Security (TLS) schützt eine Verbindung vor Mitlesen und Veränderung und authentifiziert den Server über ein Zertifikat. HTTPS ist HTTP über TLS, üblicherweise auf Port 443. Verwende unterstützte Konfigurationen von TLS 1.2 oder 1.3; SSL sowie TLS 1.0 und 1.1 sind veraltet.

Ein digitales Zertifikat verknüpft eine Domain mit einem öffentlichen Schlüssel. Eine vertrauenswürdige Zertifizierungsstelle signiert es, damit der Browser die Zuordnung prüfen kann. Zu den Zertifikatsdiensten gehören AWS Certificate Manager, Zertifikatsfunktionen von Azure Key Vault oder App Service und Google Cloud Certificate Manager. Eine verwaltete Erneuerung verringert das Ablaufrisiko, wenn sie unterstützt und konfiguriert wird. Ein abgelaufenes Zertifikat kann Verbindungen verhindern und einen Dienst unterbrechen.

Eine gültige HTTPS-Verbindung bestätigt den Schutz der Verbindung zu dieser Domain. Auch eine Phishingseite kann ein gültiges Zertifikat für ihre eigene Domain besitzen. Das Schloss allein sagt daher nichts darüber aus, ob das Unternehmen oder die Seite Vertrauen verdient.

Eine Browseranfrage verfolgen

1. Der Browser stellt eine HTTPS-Verbindung zu einem Load Balancer her und prüft dessen Zertifikat.
2. Der Load Balancer terminiert diese TLS-Verbindung und sieht die Anfrage im Klartext.
3. Eine separate TLS-Verbindung schützt den nächsten Abschnitt zum Anwendungsserver.
4. Die Anwendung nutzt eine verschlüsselte Datenbankverbindung; die Datenbank ist so konfiguriert, dass sie diese verlangt.

HTTPS am Eingang schützt nur seine eigene Verbindung. Prüfe jeden weiteren Abschnitt. Eine S3-Richtlinie kann Anfragen verweigern, wenn aws:SecureTransport falsch ist; Azure Storage bietet die Einstellung für erforderliche sichere Übertragung; Cloud SQL kann TLS verlangen. Auch interne Netzwerke benötigen Schutz des Datenverkehrs, weil ein Angreifer sie bereits erreicht haben könnte.

Privaten Übertragungsweg und Verschlüsselung unterscheiden

Ein Site-to-Site-IPsec-VPN verschlüsselt Datenverkehr zwischen einem Büronetzwerk und einem Cloud-Netzwerk über das Internet. Zu den Diensten gehören AWS Site-to-Site VPN, Azure VPN Gateway und Google Cloud VPN.

Dedizierte Verbindungen wie AWS Direct Connect, Azure ExpressRoute und Google Cloud Interconnect umgehen das öffentliche Internet, aber ihr privater Übertragungsweg allein bietet standardmäßig keine Ende-zu-Ende-Verschlüsselung. Verwende bei Bedarf geeigneten Schutz durch TLS, IPsec oder unterstütztes MACsec. MACsec schützt den jeweils unterstützten Verbindungsabschnitt; prüfe auch den Schutz für den gesamten Übertragungsweg der Anwendung.

Daten während der Verarbeitung schützen

Daten bei der Verarbeitung werden verarbeitet, häufig in entschlüsseltem Arbeitsspeicher. Confidential Computing ergänzt hardwaregestützte Isolation und bei unterstützten Technologien Speicherverschlüsselung. Vertrauliche Azure-VMs und Google Confidential VMs verschlüsseln den Arbeitsspeicher mit Schlüsseln, die im Prozessor aufbewahrt werden. AWS Nitro Enclaves isoliert Arbeitsspeicher und CPUs von der übergeordneten Instanz und deren Administratoren.

Bei einer Patientenakte schützt Datenbankverschlüsselung die Speicherung, TLS schützt die Übermittlung an einen Arzt und eine vertrauliche VM kann einen sensiblen Analyseauftrag während seiner Ausführung schützen. Diese Maßnahmen decken unterschiedliche Gefährdungen ab. Die Anwendung benötigt weiterhin die Berechtigung zur Verarbeitung der Akte und bleibt für ihre Ausgaben verantwortlich.

Wer die Schlüssel besitzt, beeinflusst sowohl die Sicherheitskontrolle als auch das Betriebsrisiko. Ein Kunde, der die Möglichkeit erhält, einen Schlüssel zu deaktivieren, erhält damit auch eine Möglichkeit, jeden davon abhängigen Dienst zu unterbrechen.

Kontrollmöglichkeiten vergleichen

Zu den Cloud-Schlüsseldiensten gehören AWS KMS, Azure Key Vault und Google Cloud KMS. Sie steuern kryptografische Vorgänge und können die Schlüsselverwendung protokollieren. Aktiviere die erforderlichen Protokolle, einschließlich Azure-Diagnoseeinstellungen und Data-Access-Auditprotokollierung für Google Cloud KMS.

Beispiele für vom Kunden bereitgestellte Schlüssel sind unterstützte Abläufe mit Amazon S3 SSE-C und Google CSEK. Zu den externen Optionen gehören AWS KMS External Key Stores und Google Cloud External Key Manager. Diese Funktionen sind dienstspezifisch; der gewählte Datendienst muss die Option unterstützen.

Ein Hardware-Sicherheitsmodul (HSM) schützt Schlüssel in spezialisierter Hardware. AWS CloudHSM, Azure Managed HSM und Google Cloud HSM bieten Hardwareschutz. HSM beschreibt, wie Schlüssel geschützt werden; Anbieter-, Kunden- oder externe Kontrolle beschreibt, wer ihre Verwendung steuert. Das sind unterschiedliche Entscheidungen.

Envelope-Verschlüsselung verstehen

Cloud-Speicher verschlüsselt große Inhalte häufig mit einem Datenschlüssel. Anschließend verschlüsselt er diesen kleineren Schlüssel mit einem Schlüsselverschlüsselungsschlüssel, der in einem Schlüsseldienst aufbewahrt wird. Der verpackte Datenschlüssel kann neben dem Geheimtext gespeichert werden. Das ist Envelope-Verschlüsselung: Große Datenmengen müssen nicht für jeden kryptografischen Vorgang an KMS gesendet werden.

Um den Inhalt zu lesen, benötigt der Dienst die Berechtigung, den Datenschlüssel zu entschlüsseln. Die Deaktivierung des schützenden Schlüssels blockiert diesen Weg. Die dauerhafte Vernichtung des Schlüssels kann alle davon abhängigen Daten unlesbar machen, einschließlich älterer Datensicherungen.

Die Entscheidung eines Krankenhauses durchgehen

Ein Krankenhaus wählt für Bildaufnahmen einen kundenverwalteten AWS-KMS-Schlüssel. Seine Anwendungsrolle darf entschlüsseln; das Sicherheitsteam verwaltet den Schlüssel, ohne eine reguläre Berechtigung zum Lesen der Aufnahmen zu haben. Das trennt die Datennutzung von der Schlüsselverwaltung. Auditnachweise müssen die vorgesehenen Berechtigungen und die Schlüsselverwendung belegen.

Der Schlüssel rotiert jährlich. Rotation liefert neues Material für künftige Verschlüsselungen und behält ältere Versionen, die zum Lesen vorhandener Inhalte benötigt werden. Sie bedeutet nicht, dass jede alte Aufnahme sofort neu verschlüsselt wird.

Am Ende der Dienstnutzung prüft das Krankenhaus alle verbliebenen Daten und Abhängigkeiten von Datensicherungen, bevor es die Schlüssellöschung plant. AWS KMS verwendet eine Wartefrist von 7 bis 30 Tagen. Nach der Löschung kann abhängiger Geheimtext über diesen Schlüssel nicht wiederhergestellt werden. Den Zugriff durch die Vernichtung des Schlüssels zu zerstören, heißt kryptografisches Löschen.

Kontrolle auf eine Anforderung abstimmen

Wähle kundenverwaltete oder externe Schlüssel, wenn ein Vertrag, eine Vorschrift, eine Anforderung zum Zugriffsentzug, eine Prüfungsanforderung oder die Funktionstrennung diese Kontrolle verlangt. Derselbe Verschlüsselungsalgorithmus kann Daten in jedem dieser Verwaltungsmodelle schützen. Zusätzliche Schlüsselkontrolle verändert Verantwortung, Verfügbarkeitsplanung und Nachweise; sie macht AES mathematisch nicht stärker.

Die gestaffelte Verteidigung kombiniert unabhängige Sicherheitsmaßnahmen. Versagt eine, kann eine andere die nächste Aktion blockieren, deren Schaden begrenzen oder den Angriff aufdecken.

Maßnahmen in Schichten anordnen

Die Sieben-Schichten-Sicht von Microsoft reicht von physischer Sicherheit über Identität und Zugriff, Perimeter, Netzwerk, Rechenressourcen und Anwendung bis zu den Daten in der Mitte.

Die Zuständigkeit folgt der geteilten Verantwortung. Anbieter betreiben physische Sicherheitsmaßnahmen; Kunden kontrollieren Identitäten und Daten. Wer die Rechenressourcen wartet, hängt davon ab, ob es sich um eine Kunden-VM oder eine verwaltete Plattform handelt.

Eine Kontoübernahme verfolgen

Ein Angreifer erhält das Passwort eines Shopentwicklers. MFA kann eine neue Anmeldung blockieren. Angenommen, der Angreifer stiehlt stattdessen eine bereits authentifizierte Sitzung. Die nächsten Maßnahmen müssen berücksichtigen, was diese Sitzung tun darf.

Die Rolle des Entwicklers erlaubt das Lesen von Protokollen, aber keine Datenbankabfragen. Daher verweigert die Autorisierung eine direkte Anfrage nach Kundendaten. Netzwerkregeln beschränken Datenbankverbindungen unabhängig davon auf den erlaubten Weg der Anwendung. Die Überwachung kann ungewöhnliche Aktivitäten melden. Geschützte Datensicherungen erhalten die Wiederherstellungsmöglichkeit, falls ein Angreifer später Zugriff für zerstörerische Aktionen erhält.

Datenträgerverschlüsselung schützt Rohdaten im Speicher, wenn der Schlüssel fehlt. Sie würde lesbare Inhalte nicht blockieren, die an eine kompromittierte Identität mit regulärer Lese- und Entschlüsselungsberechtigung zurückgegeben werden. Prüfe den tatsächlichen Weg, bevor du einer Maßnahme zuschreibst, dass sie ihn blockiert.

Blockierung und Erkennung kombinieren

Eine präventive Maßnahme stoppt eine Anfrage, etwa zur Erstellung öffentlichen Speichers. Eine detektierende Maßnahme meldet ein Ereignis oder einen Zustand, etwa ungewöhnliche Aktivität oder übermäßigen Zugriff. Lege eine Reaktion fest, die das Erkannte untersucht, eindämmt und korrigiert.

Zwei Firewalls mit derselben fehlerhaften Regel können gemeinsam versagen. Eine separate Identitätsprüfung, Anwendungsvalidierung und eng gefasste Datenrolle greifen an unterschiedlichen Schritten des Angriffs. Verfolge eine Anfrage vom Benutzer bis zu den Daten, bestimme die Maßnahmen auf diesem Weg und benenne Verantwortliche für ihre Einstellungen und Warnungen.

Zero Trust gewährt keine automatische Erlaubnis aufgrund des Netzwerkstandorts. Eine interne Adresse begründet keine Berechtigung, eine Anwendung zu nutzen oder deren Daten zu lesen.

Drei Prinzipien anwenden

Explizit überprüfen: Identität und Kontext bewerten, einschließlich Gerätezustand, Standort, angefordertem Dienst, Sensibilität der Daten und ungewöhnlichem Verhalten.

Das Prinzip der geringsten Rechte anwenden: genau den Zugriff gewähren, der für die Aufgabe nötig ist, bei Bedarf mit einer zeitlich begrenzten Rechteerweiterung. Auch ein authentifizierter Benutzer benötigt eine Berechtigung für die Aktion.

Von einer Kompromittierung ausgehen: Bewegungsmöglichkeiten einschränken, Datenverkehr verschlüsseln und Aktivitäten überwachen, damit eine kompromittierte Identität oder ein kompromittiertes Gerät nicht ungehindert alles erreichen kann.

NIST SP 800-207 beschreibt den Architekturansatz. Microsoft formuliert ihn mit diesen drei Prinzipien. Organisationen setzen die Strategie durch aufeinander abgestimmte Maßnahmen um und können sie schrittweise einführen.

Die Zugriffsgrenze verändern

Ein herkömmliches Perimetermodell neigt dazu, Geräten nach ihrem Eintritt ins Netzwerk zu vertrauen. Eine weitreichende VPN-Verbindung kann dann einem infizierten Laptop den Zugriff auf viele Systeme ermöglichen. Arbeit aus der Ferne, SaaS und Multicloud machen den Standort allein zu einer ungeeigneten Zugriffsgrenze.

Ein identitätsbasierter Proxy bewertet den Zugriff auf eine bestimmte Anwendung. Google Identity-Aware Proxy, AWS Verified Access und Microsoft Entra Private Access bieten verwandte Funktionen. Googles BeyondCorp-Ansatz ist ein Beispiel dafür, wie automatisches Vertrauen innerhalb des Netzwerks durch bewerteten Zugriff ersetzt wird.

Segmentierung und Firewalls begrenzen weiterhin die Reichweite, wenn eine andere Maßnahme versagt. Verschlüssele auch interne Verbindungen: Ein Angreifer könnte bereits in die Umgebung eingedrungen sein.

Die Anfrage einer Pflegekraft bewerten

Eine Pflegekraft fordert von zu Hause aus Zugriff auf die Dienstplanungsanwendung an. Ein Zugriffsdienst überprüft die Identität mit phishingresistenter Authentifizierung, prüft, ob der Laptop verwaltet und aktuell ist, und bestätigt die Dienstplanungsrolle. Er gewährt eine Sitzung für diese Anwendung.

Eine Anfrage an die Gehaltsabrechnung benötigt eine eigene Berechtigungsentscheidung. Die Dienstplanungssitzung gewährt keinen Zugriff auf die Gehaltsabrechnung. Meldet die Überwachung den Laptop später als infiziert, kann eine Richtlinie den betroffenen Zugriff blockieren oder widerrufen. Die Authentifizierung am Morgen klärt nicht den Gerätezustand am Nachmittag.

Identitätsdienste stellen fest, wer die Anfrage stellt; Geräteprüfungen und bedingter Zugriff bewerten den Kontext. Rollen begrenzen Aktionen, Proxys und Segmente begrenzen die Reichweite und TLS schützt Verbindungen. Die Überwachung liefert neue Erkenntnisse für spätere Entscheidungen. Auch nach dem Kauf eines Produkts muss die Organisation diese Zugriffsregeln und Entscheidungen zur Reaktion selbst festlegen.

Beginne mit der Aufgabe, die die Sicherheitsmaßnahme erfüllen muss. Die großen Anbieter bieten überlappende Sicherheitskategorien an, und ein einzelnes Produkt kann mehrere Arten von Ergebnissen liefern. Eine erkannte Softwareschwäche verlangt eine andere Reaktion als eine Datenverkehrsflut.

Datenverkehrsfluten und Webangriffe blockieren

DDoS-Schutz richtet sich gegen Datenverkehr, der einen Dienst überlasten soll. AWS Shield Standard bietet automatischen Basisschutz; Shield Advanced ergänzt kostenpflichtige Funktionen und Unterstützung bei der Reaktion. Azure bietet standardmäßigen Infrastrukturschutz und kostenpflichtige Stufen von Azure DDoS Protection. Google Cloud Armor schützt unterstützte Anwendungen hinter einem Load Balancer.

Eine Web Application Firewall (WAF) prüft Webanfragen auf Angriffe wie SQL-Injection, Cross-Site-Scripting und schädliche Bots. AWS WAF, Azure Web Application Firewall und Cloud-Armor-Sicherheitsrichtlinien gehören zu dieser Kategorie. Sie können Anwendungsanfragen filtern oder die Anfragerate begrenzen. Eine Netzwerkfirewall steuert Netzwerkverkehr auf einer anderen Ebene: AWS Network Firewall, Azure Firewall und Google Cloud Next Generation Firewall sind Beispiele. AWS Firewall Manager hilft, unterstützte Schutzmaßnahmen kontenübergreifend anzuwenden.

Bedrohungen und bekannte Schwachstellen erkennen

Die Bedrohungserkennung untersucht Aktivitäten auf Anzeichen einer Kompromittierung. Eine VM, die einen bekannten Dienst zum Schürfen von Kryptowährung kontaktiert, ist ein verhaltensbasierter Warnhinweis. GuardDuty analysiert unter anderem API-, Netzwerkfluss- und DNS-Informationen. Eine SIEM-Plattform wie Microsoft Sentinel oder Google Security Operations führt Sicherheitsereignisse aus vielen Quellen zur Analyse und Untersuchung zusammen.

Die Schwachstellenverwaltung erkennt bekannte Schwächen in installierter Software oder Images. Inspector bewertet unterstützte EC2-, Container- und Lambda-Workloads. Ein anfälliges Paket kann vorhanden sein, bevor eine Angreiferaktivität beobachtet wird; seine Entdeckung sollte zu einem Update oder einer anderen geeigneten Gegenmaßnahme führen.

Cloud Security Posture Management (CSPM) prüft Konfigurationen anhand von Verfahren und Standards. Eine öffentlich erreichbare Speicherressource ist ein Problem der Sicherheitslage, auch wenn kein böswilliger Zugriff erkannt wurde. AWS Security Hub führt Ergebnisse zusammen; Security Hub CSPM stellt Konfigurationsprüfungen bereit. Defender for Cloud und Security Command Center bieten ebenfalls eine Bewertung der Sicherheitslage.

Sensible Daten finden und auf Ergebnisse reagieren

Macie kann sensible Inhalte in S3 finden. Purview erkennt, klassifiziert und kennzeichnet Daten einer Organisation. Google Sensitive Data Protection kann sensible Inhalte erkennen, klassifizieren und de-identifizieren. Findet ein Team Reisepassnummern in einem vergessenen Export, erkennt es, wo strengere Zugriffs- oder Aufbewahrungsmaßnahmen nötig sind; das Auffinden allein ändert nicht jede Berechtigung.

Ordne bei einem Onlinedienst das Symptom der Kategorie zu. Nutze DDoS-Schutz bei einer Datenverkehrsflut, eine WAF für bösartige Webeingaben, eine Schwachstellenbewertung für eine veraltete Bibliothek, Bedrohungserkennung für verdächtige Aktivitäten zur Laufzeit und CSPM für riskante Ressourceneinstellungen. Mehrere davon können gleichzeitig nötig sein.

AWS Trusted Advisor, Azure Advisor und Google Recommender liefern zusätzliche Empfehlungen; verfügbare Prüfungen und kostenpflichtige Pläne unterscheiden sich. Die Marktplätze der Anbieter bieten Produkte von Drittanbietern. Offizielle Sicherheitsdokumentation, Reaktionszentren, Blogs und Bulletins helfen Teams, bei Änderungen auf dem Laufenden zu bleiben. Weise Verantwortliche für Ergebnisse zu und aktiviere die passenden Dienstpläne: Ein Dashboard voller ungeprüfter Warnungen lässt die zugrunde liegende Gefährdung bestehen.

Protokolle beantworten Fragen zu Ereignissen; Überwachung macht aus Beobachtungen Handlungen. Gute Nachweise setzen voraus, dass die richtigen Ereignisse frühzeitig erfasst, lange genug aufbewahrt und vor Veränderung geschützt werden.

Den passenden Nachweis für die Frage wählen

Audit- oder Aktivitätsprotokolle zeigen, wer Aktionen über Konsole oder API ausgeführt hat. Der Konfigurationsverlauf zeigt, wie sich die Einstellungen einer Ressource verändert haben. Metriken messen Zustand und Leistung. Datenzugriffsprotokolle erfassen relevante Inhaltszugriffe und Netzwerk-Datenflussprotokolle beschreiben Datenverkehrsflüsse.

Der CloudTrail-Ereignisverlauf bewahrt Verwaltungsereignisse der letzten 90 Tage pro Region auf. Erstelle einen Trail, um Aufzeichnungen zur längeren Aufbewahrung an S3 und optional auch an CloudWatch Logs zu liefern. CloudWatch-Leistungsmetriken sind ein anderer Nachweis als die CloudTrail-Aufzeichnung darüber, wer eine Richtlinie geändert hat.

Das Azure-Aktivitätsprotokoll bewahrt standardmäßig ebenfalls 90 Tage auf. Diagnoseeinstellungen können Aufzeichnungen an Speicher, Log Analytics oder Event Hubs senden. Google-Admin-Activity-Protokolle sind immer aktiviert und können nicht deaktiviert werden. Data-Access-Protokolle müssen für die meisten Dienste aktiviert werden; bei BigQuery gelten wichtige abweichende Standardeinstellungen. Auch Key-Vault-Zugriffsprotokolle und Google-KMS-Datenaktivitäten benötigen die passenden Erfassungseinstellungen.

Nachweise sichern, bevor eine Untersuchung sie benötigt

Ein Bucket wird am 2. März 2026 öffentlich. Die Untersuchung beginnt am 1. Juli, 121 Tage später. Das Ereignis liegt außerhalb des standardmäßigen 90-Tage-Zeitraums. Ein zuvor konfigurierter Export kann festhalten, wer die Einstellung wann und von welcher IP-Adresse aus geändert hat; ein jetzt aktivierter Export kann eine abgelaufene Aufzeichnung nicht wiederherstellen.

Der Konfigurationsverlauf kann die Einstellung vor und nach dem Ereignis zeigen. Nutze beide Aufzeichnungen, um die Änderung zu verstehen, die Offenlegung rückgängig zu machen und Datenzugriffe anhand der passend aktivierten Protokolle zu untersuchen. Ein Verwaltungsereignis allein ist keine vollständige Liste gelesener Dateien.

Änderungen verhindern und Ausnahmen erkennen

Präventive Leitplanken blockieren eine nicht erlaubte Aktion: Azure Policy Deny, unterstützte SCP-Einschränkungen und Google-Organisationseinschränkungen sind Beispiele. Detektierende Leitplanken erkennen einen Zustand, nachdem er eingetreten ist: AWS-Config-Regeln, Azure Policy Audit und Ergebnisse zur Sicherheitslage.

Eine Standortrichtlinie kann neue Ressourcen in nicht erlaubten Regionen blockieren. Eine Konfigurationsprüfung kann Ressourcen melden, die gegen eine Regel verstoßen. Letzteres erfordert eine Reaktion und macht eine Änderung nicht allein durch eine Meldung rückgängig.

Beschränke den Zugriff auf Protokolle, sammle Nachweise in einem separaten Konto oder Projekt und nutze bei Bedarf Maßnahmen für Integrität oder Unveränderlichkeit. Die CloudTrail-Protokolldateivalidierung kann veränderte gelieferte Dateien aufdecken. Lege die Aufbewahrungsdauer gemäß der geltenden Anforderung fest; PCI DSS verlangt mindestens 12 Monate Auditverlauf, wobei die jüngsten 3 Monate kurzfristig verfügbar sein müssen. Richte Warnungen für Ereignisse wie Root-Anmeldungen oder Änderungen an privilegierten Rollen ein und benenne eine Person, die darauf reagiert.

Compliance bedeutet, geltende Anforderungen zu erfüllen und Nachweise vorzulegen. Geprüfte Maßnahmen eines Cloud-Anbieters können deine Pflichten unterstützen, aber deine Organisation muss auch die Maßnahmen durchführen und dokumentieren, für die sie selbst verantwortlich ist.

Die Art der Anforderung bestimmen

ISO/IEC 27001 behandelt ein Informationssicherheitsmanagementsystem, kurz ISMS. Akkreditierte Zertifizierungsstellen stellen Zertifikate üblicherweise in einem Dreijahreszyklus mit Überwachungsaudits aus. ISO/IEC 27017 ergänzt Cloud-Sicherheitsmaßnahmen. ISO/IEC 27018 behandelt den Schutz personenbezogener Daten für Auftragsverarbeiter in Public Clouds; die aktuelle Ausgabe stammt aus 2025.

Den passenden SOC-Bericht für die Frage wählen

SOC 1 betrifft Maßnahmen, die für die Finanzberichterstattung der Kunden relevant sind. SOC 2 behandelt die anwendbaren Trust Services Criteria: Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. Es ist ein ausführlicher Bericht, der üblicherweise unter Vertraulichkeitsbedingungen weitergegeben wird. SOC 3 ist ein allgemein nutzbarer Bericht, der sich zur öffentlichen Verbreitung eignet.

Ein Type-1-Bericht bewertet die Gestaltung von Maßnahmen zu einem bestimmten Zeitpunkt. Ein Type-2-Bericht prüft zusätzlich ihre Wirksamkeit im Betrieb über einen angegebenen Zeitraum. Wenn du nachweisen möchtest, dass die relevanten Maßnahmen eines Lieferanten über Monate funktioniert haben, frage nach einem aktuellen SOC 2 Type 2-Bericht und prüfe dessen tatsächlichen Geltungsbereich. SOC 2 ist eine Attestierung, keine Zertifizierung.

Anforderungen von Branchen und Behörden erkennen

PCI DSS gilt für Organisationen, die Karteninhaberdaten speichern, verarbeiten oder übertragen. Neben der Gestaltung und den Maßnahmen für Zahlungen beim Kunden ist der Geltungsbereich des Cloud-Dienstes wichtig.

HIPAA schützt PHI in seinem Geltungsbereich: bei erfassten Gesundheitsorganisationen und ihren Geschäftspartnern. Ein Anbieter, der elektronische PHI im Auftrag einer erfassten Einrichtung verwaltet, ist ein solcher Geschäftspartner, auch wenn er verschlüsselte Daten ohne den Schlüssel speichert. Ein Business Associate Agreement (BAA) muss vorliegen. Es gibt keine offizielle HIPAA-Zertifizierung, die diese Pflichten ersetzt.

FedRAMP betrifft die Prüfung und laufende Aufsicht von Cloud-Diensten für erfasste Nutzungen durch US-Bundesbehörden. Anwendungsfälle der Behörden und Ausnahmen sind entscheidend; der bloße Verkauf installierbarer Software an eine Behörde löst dies nicht aus. Weitere Prüfprogramme sind Deutschlands C5, Spaniens ENS, Australiens IRAP und Japans ISMAP. CSA STAR veröffentlicht Cloud-Selbstbewertungen und Informationen über unabhängige Prüfungen.

Vor der Nutzung von Nachweisen den Geltungsbereich prüfen

Eine Klinik prüft sowohl ihr BAA als auch die Liste geeigneter Dienste des Anbieters, bevor sie elektronische PHI in einem Dienst speichert. Ein Einzelhändler, der Karteninhaberdaten verarbeitet, prüft die Anforderungen von PCI DSS und hat möglicherweise auch DSGVO-Pflichten für personenbezogene Daten. Eine Pflicht ersetzt die andere nicht.

Ein Zertifikat oder Bericht benennt eine Abgrenzung: Dienste, Standorte und Prüfungsdaten. Halte fest, welche Maßnahmen des Anbieters deine Workload erbt, und setze dann eigene Berechtigungen, Konfigurationen, Verfahren und Nachweise um. Ein allgemeines Unternehmenssiegel des Anbieters kann nicht beantworten, ob ein bestimmter neuer Dienst oder eine bestimmte neue Region eingeschlossen ist.

Compliance-Nachweise sind nützlich, wenn sie zum Dienst, zum Standort und zum Zeitraum passen, auf die du dich verlässt. Das Herunterladen eines Dokuments ist der Beginn der Prüfung; sein Inhalt bestimmt, auf welche Bestätigung du dich verlassen kannst.

Die Dokumente des Anbieters finden

Ausführliche SOC-Berichte erfordern häufig die Annahme von Vertraulichkeitsbedingungen oder einer Geheimhaltungsvereinbarung. Allgemein nutzbare SOC-3-Berichte und viele Zertifikate sind öffentlich. Öffentliche Compliance-Seiten helfen, verfügbare Programme und erfasste Dienste zu ermitteln.

Einen SOC 2 Type 2-Bericht der Reihe nach lesen

1. Lies das Prüfungsurteil. Ein uneingeschränktes Urteil bietet eine Bestätigung ohne Beanstandung innerhalb des genannten Geltungsbereichs; ein eingeschränktes Urteil nennt eine Einschränkung, die du verstehen musst.
2. Gleiche Systembeschreibung und Geltungsbereich mit deinen gewählten Diensten und Standorten ab.
3. Prüfe den Berichtszeitraum und wie lange sein Ende zurückliegt.
4. Lies die geprüften Maßnahmen und Ausnahmen, einschließlich ihrer Auswirkungen auf deine Nutzung.
5. Ermittle die ergänzenden Kontrollen beim Anwenderunternehmen (CUECs): Maßnahmen, die deine Organisation durchführen muss.
6. Prüfe die Rolle und Behandlung von Unterdienstleistern, auf die sich der Anbieter stützt.

Ein Bericht kann günstig ausfallen und dennoch verlangen, dass deine Organisation Benutzerzugriffe verwaltet, Protokolle prüft oder eine Einstellung konfiguriert. Übernimm diese Aufgaben in deinen eigenen Maßnahmenplan und weise Verantwortliche zu.

Am 15. März 2026 prüft ein Team einen Bericht für den Zeitraum vom 1. Oktober 2024 bis zum 30. September 2025. Der zwölfmonatige Prüfzeitraum endete 166 Tage zuvor. Ein Bridge Letter enthält die Erklärung des Anbieters zu relevanten Änderungen seit diesem Enddatum. Er ist keine neue unabhängige Prüfung jedes Tages in der Lücke. Beschaffe den nächsten Bericht, sobald er verfügbar ist.

Verträge zusammen mit den Nachweisen aufbewahren

Die DSGVO verlangt einen geeigneten Vertrag zwischen Verantwortlichem und Auftragsverarbeiter, der üblicherweise als Auftragsverarbeitungsvertrag oder Zusatzvereinbarung bereitgestellt wird. Beispiele der Anbieter sind das AWS GDPR Addendum, Microsofts Products and Services Data Protection Addendum und Googles Cloud Data Processing Addendum. Für Geschäftspartnerbeziehungen nach HIPAA ist ein BAA erforderlich.

Ein Bericht beschreibt geprüfte Maßnahmen. Eine Vereinbarung begründet die jeweiligen vertraglichen Verpflichtungen. Kein Dokument kann die Aufgabe des anderen übernehmen. Sorge dafür, dass die geltenden Vereinbarungen für die genutzten Dienste angenommen und aktuell sind.

Auch Maßnahmen des Kunden verfolgen

Erfasse Maßnahmen des Anbieters als geerbt und sammle dann gegebenenfalls eigene Zugriffsüberprüfungen, Konfigurationsergebnisse, Protokolle, Richtlinien und Schulungsnachweise. AWS-Config-Konformitätspakete bündeln technische Konfigurationsprüfungen; sie bewerten nicht jede Richtlinie oder jedes Mitarbeiterverfahren. Purview Compliance Manager liefert Verbesserungsmaßnahmen und eine Compliance-Bewertung. Google Assured Workloads wendet unterstützte Maßnahmen für regulierte Workloads an, einschließlich Standort- und Zugriffsbeschränkungen.

Behandle Bewertungen und Ergebnisse als Aufgabenliste mit Nachweisen, die zu prüfen sind. Kläre Lücken im Geltungsbereich oder bei den Daten, bevor du die Dokumente einem Käufer oder Prüfer vorlegst, und prüfe, ob ein neu eingeführter Dienst oder eine neue Region eine erneute Prüfung erfordert.

Datenschutz verbindet Entscheidungen über Zweck, Zugriff, Standort und die Rechte von Menschen. Das Verschieben von Datensätzen in eine gewählte Region beantwortet nur die Frage nach dem Standort.

Rollen und Pflichten kennen

Die seit dem 25. Mai 2018 anwendbare DSGVO regelt die Verarbeitung personenbezogener Daten in ihrem Geltungsbereich in der EU und im EWR. Sie erfasst auch Organisationen außerhalb der EU, die Menschen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten dort beobachten. Sie ist nicht auf EU-Bürger beschränkt.

Der Verantwortliche entscheidet über Zwecke und Mittel der Verarbeitung. Der Auftragsverarbeiter handelt im Auftrag des Verantwortlichen. Bei gehosteten Kundendatensätzen ist der Kunde häufig der Verantwortliche und der Cloud-Anbieter sein Auftragsverarbeiter. Artikel 28 verlangt einen schriftlichen Verarbeitungsvertrag. Die Rollen richten sich nach dem tatsächlichen Verarbeitungsverhältnis, nicht allein nach der Bezeichnung eines Unternehmens in der Cloud.

Zu den für die Cloud relevanten Pflichten gehören eine Rechtsgrundlage, das Erheben nur benötigter Daten (Datenminimierung), dem Risiko angemessene Sicherheit, Auskunfts- und Löschrechte der Betroffenen sowie die geltende Meldung von Datenschutzverletzungen. Artikel 32 nennt Verschlüsselung und Pseudonymisierung als Beispiele für Sicherheitsmaßnahmen.

Nach Artikel 33 meldet ein Verantwortlicher eine Verletzung des Schutzes personenbezogener Daten seiner Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, es sei denn, ein Risiko für die Rechte und Freiheiten von Menschen ist unwahrscheinlich. Ein Auftragsverarbeiter informiert seinen Verantwortlichen unverzüglich. Wird die Verletzung am Montag um 09:00 Uhr bekannt, enden 72 Stunden am Donnerstag um 09:00 Uhr; das ist keine Erlaubnis zu warten, wenn eine frühere Meldung möglich ist. Eine verspätete Meldung an die Behörde muss die Verzögerung begründen.

Die obere Bußgeldstufe nach Artikel 83 erlaubt höchstens 20 Millionen € oder 4 % des weltweit erzielten Jahresumsatzes des Vorjahres, je nachdem, welcher Betrag höher ist. Bei 1,5 Milliarden € Umsatz sind 4 % gleich 60 Millionen €; bei 300 Millionen € sind es 12 Millionen €, sodass die Obergrenze von 20 Millionen € höher ist. Tatsächliche Bußgelder hängen vom Verstoß und seiner Bewertung ab.

Standortanforderungen unterscheiden

Prüfe die Standortzusagen eines Dienstes, Datensicherungen, Replikate und Supportzugriffe. Die Wahl einer Region ist keine pauschale Zusage für jede Dienstfunktion. Government- und Sovereign-Angebote wie AWS GovCloud (US), Azure Government und europäische souveräne Angebote erfüllen bestimmte Anforderungen mit festgelegten Zulassungsvoraussetzungen und Geltungsbereichen.

Übermittlungen außerhalb des EWR benötigen eine anwendbare Rechtsgrundlage, etwa einen Angemessenheitsbeschluss, Standardvertragsklauseln oder verbindliche interne Datenschutzvorschriften. Der Weg über den Angemessenheitsbeschluss zum EU–US Data Privacy Framework gilt für erfasste Übermittlungen an teilnehmende zertifizierte Organisationen. Auch der Zugriff durch Mitarbeiter in einem anderen Land kann eine Prüfung der Übermittlung erfordern, selbst wenn die Speicherung in einer EU-Region bleibt.

Ein Versicherer, der Schadensdaten in der EU hält, wählt EU-Regionen für Speicherung und Datensicherung, wendet unterstützte Standortleitplanken an, steuert den Schlüsselzugriff und prüft seinen Auftragsverarbeitungsvertrag und die Übermittlungsbedingungen. Kundenverwaltete Schlüssel allein erfüllen nicht alle Pflichten zu Datenresidenz oder Übermittlung.

Verschlüsselte personenbezogene Daten bleiben für eine Partei, die sie entschlüsseln kann, personenbezogene Daten. Wirksame Verschlüsselung kann die Pflicht zur Benachrichtigung Betroffener nach Artikel 34 entfallen lassen, wenn dessen Voraussetzungen erfüllt sind; für die Meldung an die Behörde gilt eine eigene Prüfung. Andere Gesetze, darunter der kalifornische CCPA in der durch den CPRA geänderten Fassung und das brasilianische LGPD, haben eigene Geltungsbereiche und Pflichten.