Cloud-Sicherheit für KMU: Die häufigsten Fehlkonfigurationen und wie du sie vermeidest

Die Cloud ist sicher, deine Konfiguration nicht

Wenn ein Unternehmen einen Datenverlust in der Cloud erleidet, lautet die erste Reaktion oft: "Die Cloud ist unsicher." Das Gegenteil ist der Fall. Die großen Cloud-Anbieter betreiben ihre Infrastruktur mit einem Sicherheitsniveau, das kein Mittelständler in einem eigenen Rechenzentrum auch nur annähernd erreichen könnte. Tausende Sicherheitsingenieure, physische Sicherheit auf Militärniveau, redundante Rechenzentren auf mehreren Kontinenten, permanentes Monitoring.

Das Problem liegt fast nie bei der Cloud-Infrastruktur selbst. Es liegt bei der Konfiguration. Gartner prognostiziert, dass bis 2027 über 99 Prozent aller Cloud-Sicherheitsvorfälle auf Kundenverschulden zurückgehen werden, und aktuelle Zahlen bestätigen diesen Trend. Offene Speicher-Container, fehlende Multifaktor-Authentifizierung, Administratorrechte für alle Benutzer, deaktiviertes Logging. Das sind keine exotischen Schwachstellen. Das sind Konfigurationsfehler, die jeden Tag passieren und die sich mit überschaubarem Aufwand vermeiden lassen.

Für den Mittelstand ist die Cloud längst Realität: Microsoft 365 ist quasi Standard, Azure-Dienste werden für Hosting, Backup und Anwendungen genutzt, SaaS-Lösungen ersetzen lokale Software. Aber die Sicherheitskompetenz hat mit der Cloud-Adoption nicht immer Schritt gehalten. Viele KMU haben ihre lokale IT-Kompetenz in die Cloud "mitgenommen", ohne zu berücksichtigen, dass Cloud-Sicherheit nach anderen Regeln funktioniert.

Das Shared Responsibility Model verstehen

Das Shared Responsibility Model ist das Fundament der Cloud-Sicherheit, und sein Missverständnis ist die Ursache für die meisten Probleme. Es definiert, wer für welchen Teil der Sicherheit verantwortlich ist.

Der Cloud-Anbieter ist verantwortlich für: Die physische Sicherheit der Rechenzentren, die Sicherheit der Hardware und der Virtualisierungsschicht, die Verfügbarkeit und Resilienz der Infrastruktur, die Sicherheit der Netzwerkinfrastruktur und die grundlegende Plattformsicherheit.

Du bist verantwortlich für: Die Konfiguration aller Dienste, die du nutzt, das Zugangs- und Berechtigungsmanagement, die Sicherheit deiner Daten (Verschlüsselung, Klassifizierung, Backup), die Netzwerkkonfiguration innerhalb deiner Cloud-Umgebung, das Monitoring und die Erkennung von Sicherheitsvorfällen, die Einhaltung regulatorischer Anforderungen und die Absicherung der Endgeräte, die auf Cloud-Dienste zugreifen.

Die Grenze verschiebt sich je nach Service-Modell: Bei Infrastructure as a Service (IaaS) trägst du die meiste Verantwortung. Bei Platform as a Service (PaaS) übernimmt der Anbieter mehr. Bei Software as a Service (SaaS) liegt die Verantwortung des Anbieters am höchsten, aber selbst bei SaaS bleibst du für Zugangsmanagement, Konfiguration und Daten verantwortlich.

Ein Praxisbeispiel: Wenn du Microsoft 365 nutzt, sorgt Microsoft dafür, dass Exchange Online verfügbar ist und die Server sicher betrieben werden. Aber Microsoft sorgt nicht dafür, dass deine Benutzer MFA aktiviert haben, dass die Sharing-Einstellungen in SharePoint nicht die ganze Welt einladen, oder dass ehemalige Mitarbeiter keinen Zugang mehr haben. Das ist deine Aufgabe.

Die zehn häufigsten Fehlkonfigurationen

Die folgenden zehn Fehlkonfigurationen begegnen uns bei der Arbeit mit mittelständischen Unternehmen regelmäßig. Jede einzelne kann zu einem Sicherheitsvorfall führen. Zusammen bilden sie ein Bild, das leider typisch ist.

1. Offene Storage-Accounts und Container

Das Problem: Azure Storage Accounts, AWS S3 Buckets oder andere Cloud-Speicher werden mit öffentlichem Zugriff konfiguriert, entweder bewusst ("wir brauchen das für den Datenaustausch") oder versehentlich. Die Folge: Jeder, der die URL kennt, kann auf die gespeicherten Daten zugreifen. Und automatisierte Scanner suchen das Internet permanent nach solchen offenen Containern ab.

Die Liste der Vorfälle ist lang: Millionen von Kundendaten, Patientenakten, Personalausweiskopien und Finanzberichte, die in offenen Cloud-Speichern gefunden wurden. In vielen Fällen waren die Daten monatelang exponiert, bevor der Fehler bemerkt wurde.

Die Lösung: Standardmäßig sollte kein Storage-Account öffentlich zugänglich sein. Azure bietet seit 2023 die Möglichkeit, öffentlichen Blob-Zugriff auf Subscription-Ebene zu deaktivieren. Aktiviere diese Einstellung. Für den Fall, dass tatsächlich Daten extern geteilt werden müssen, nutze Shared Access Signatures (SAS) mit Ablaufdatum und eingeschränkten Berechtigungen oder Azure Private Links.

Regelmäßige Prüfung: Nutze Azure Policy, um Storage-Accounts zu identifizieren, die öffentlichen Zugriff erlauben. Ein monatlicher Scan mit dem Azure Advisor oder einem CSPM-Tool deckt Fehlkonfigurationen automatisch auf.

2. Fehlende Multi-Faktor-Authentifizierung

Das Problem: MFA ist deaktiviert oder nicht für alle Benutzer verpflichtend. Das betrifft sowohl reguläre Benutzerkonten als auch, besonders kritisch, Administratorkonten. Ohne MFA reichen gestohlene oder erratene Zugangsdaten aus, um vollständigen Zugang zu erlangen.

Die Zahlen sprechen eine klare Sprache: Microsoft berichtet, dass über 99,9 Prozent aller kompromittierten Accounts keine MFA aktiviert hatten. MFA ist die einzelne wirksamste Maßnahme gegen Account-Übernahmen.

Die Lösung: Aktiviere MFA für alle Benutzer, ohne Ausnahme. In Microsoft 365 und Azure AD gibt es dafür Security Defaults (kostenlos und mit einem Klick aktivierbar) oder Conditional Access Policies (für differenziertere Anforderungen). Mindeststandard: MFA für alle Administratoren, für alle Zugriffe von außerhalb des Firmennetzwerks und für alle Zugriffe auf sensible Anwendungen.

Für Administratorkonten sollte MFA nicht nur aktiviert, sondern erzwungen sein, also ohne die Möglichkeit, es zu umgehen oder zu verschieben. Und nutze keine SMS als zweiten Faktor für Admin-Accounts, sondern TOTP-Apps oder besser noch FIDO2-Hardware-Keys.

3. Zu breite Berechtigungen

Das Problem: Benutzer und Anwendungen haben mehr Berechtigungen als sie benötigen. Das klassische Muster: Ein Benutzer benötigt Lesezugriff auf eine Ressource und erhält stattdessen die Rolle "Owner" oder "Contributor" auf der gesamten Subscription. Oder ein Service Principal für eine Anwendung bekommt globale Administratorrechte, weil "es damit funktioniert hat".

In Azure und M365 sehen wir regelmäßig zu viele Global Admins (es sollten maximal zwei bis vier sein), breite Rollenzuweisungen auf Subscription- statt auf Ressourcen-Ebene, Service Principals mit überflüssigen Berechtigungen und Gäste-Accounts mit Zugriff auf interne Ressourcen, die längst nicht mehr benötigt werden.

Die Lösung: Wende das Least-Privilege-Prinzip konsequent an. In Azure bedeutet das: Weise Rollen auf der niedrigstmöglichen Ebene zu (Ressourcengruppe statt Subscription). Nutze eingebaute Rollen statt benutzerdefinierter Rollen mit zu breiten Berechtigungen. Reduziere die Anzahl der Global Admins. Führe vierteljährliche Access Reviews durch, die Azure AD nativ unterstützt.

Für Administratoren: Nutze Privileged Identity Management (PIM), um Admin-Rechte nur bei Bedarf und zeitlich begrenzt zu aktivieren (Just-in-Time Access). Ein Administrator, der seine erhöhten Rechte nur bei Bedarf für maximal vier Stunden aktiviert, stellt ein deutlich geringeres Risiko dar als ein permanent privilegierter Account.

4. Deaktiviertes oder unzureichendes Logging

Das Problem: Audit-Logging und Diagnose-Logging sind nicht aktiviert oder die Logs werden nicht aufbewahrt und ausgewertet. Ohne Logs kannst du weder erkennen, ob ein Sicherheitsvorfall stattgefunden hat, noch nachträglich rekonstruieren, was passiert ist.

In Microsoft 365 ist das Unified Audit Log standardmäßig aktiviert, aber die Aufbewahrungsdauer beträgt in der Standardlizenz nur 180 Tage. In Azure sind viele Diagnose-Logs nicht standardmäßig aktiv und müssen pro Ressource konfiguriert werden. Und selbst wenn Logs vorhanden sind, werden sie in vielen KMU nicht ausgewertet, sodass ein Sicherheitsvorfall erst bemerkt wird, wenn der Schaden bereits eingetreten ist.

Die Lösung: Aktiviere als Minimum das Unified Audit Log in Microsoft 365 mit maximaler Aufbewahrungsdauer (365 Tage mit E5-Lizenz, sonst 180 Tage). In Azure aktiviere Azure Activity Log und Diagnose-Logs für alle kritischen Ressourcen (Netzwerk-Security-Groups, Key Vaults, Storage Accounts, SQL-Datenbanken).

Leite die Logs an einen zentralen Speicherort weiter: Azure Log Analytics Workspace, ein SIEM-System oder mindestens einen dedizierten Storage Account mit Immutability-Policy, damit Logs nicht manipuliert oder gelöscht werden können. Definiere grundlegende Alerting-Regeln für die offensichtlichsten Warnsignale: fehlgeschlagene Massenanmeldungen, Admin-Aktionen außerhalb der Geschäftszeiten, Änderungen an Security-Gruppen und Conditional-Access-Policies.

5. Fehlende Verschlüsselung

Das Problem: Daten werden nicht oder unzureichend verschlüsselt, weder in Ruhe (at rest) noch bei der Übertragung (in transit). Azure verschlüsselt zwar standardmäßig Storage-Daten mit Microsoft-managed Keys, aber für viele Compliance-Anforderungen reicht das nicht aus. Und bei der Übertragung zwischen Diensten oder zu externen Partnern wird Verschlüsselung oft vergessen.

Besonders kritisch: Datenbanken ohne Transparent Data Encryption (TDE), VM-Festplatten ohne Azure Disk Encryption, Datenübertragungen über unverschlüsselte Protokolle und Backup-Daten ohne Verschlüsselung.

Die Lösung: Aktiviere Verschlüsselung konsequent auf allen Ebenen. In Azure: TDE für alle SQL-Datenbanken (ist standardmäßig aktiv, sollte aber verifiziert werden), Azure Disk Encryption für alle VMs, Verschlüsselung in Transit erzwingen (HTTPS Only für Storage Accounts, TLS 1.2 Minimum für alle Dienste).

Für höhere Sicherheitsanforderungen oder regulatorische Compliance: Nutze Customer-Managed Keys (CMK) über Azure Key Vault statt Microsoft-Managed Keys. Damit behältst du die Kontrolle über die Verschlüsselungsschlüssel und kannst bei Bedarf den Zugriff widerrufen.

6. Default-Credentials und schwache Passwörter

Das Problem: Neu bereitgestellte Dienste behalten ihre Standard-Zugangsdaten, oder es werden schwache Passwörter vergeben. Das betrifft besonders VMs, Datenbanken, Netzwerkgeräte und IoT-Devices, die in der Cloud betrieben werden. Automatisierte Scanner testen permanent bekannte Default-Credentials und finden regelmäßig offene Türen.

Die Lösung: Erzwinge starke Passwörter durch Azure AD Password Protection, die bekannte schwache Passwörter und Custom Banned Passwords blockiert. Für Service Accounts und Anwendungen: Nutze Managed Identities in Azure, die keine Passwörter benötigen und automatisch rotiert werden. Für den Fall, dass Passwörter oder Secrets unvermeidbar sind: Speichere sie in Azure Key Vault mit automatischer Rotation, nicht in Code, Konfigurationsdateien oder Dokumenten.

Erstelle ein Inventar aller Dienste und prüfe, ob Standard-Zugangsdaten geändert wurden. Besonders bei schnell bereitgestellten Test- oder Entwicklungsumgebungen, die dann versehentlich produktiv werden, ist dieses Risiko hoch.

7. Fehlende Netzwerk-Policies

Das Problem: Network Security Groups (NSGs) sind zu offen konfiguriert, Dienste sind aus dem Internet erreichbar, die es nicht sein sollten, und die Netzwerksegmentierung ist unzureichend. Der Klassiker: Eine VM mit offenem RDP-Port (3389) oder SSH-Port (22) zum Internet, die innerhalb von Stunden von automatisierten Angriffen gefunden und attackiert wird.

Die Lösung: Kein Dienst sollte ohne Notwendigkeit direkt aus dem Internet erreichbar sein. Nutze Azure Bastion für den administrativen Zugang zu VMs statt offener RDP/SSH-Ports. Konfiguriere NSGs nach dem Deny-All-Prinzip und öffne nur die tatsächlich benötigten Ports und Protokolle. Nutze Service Endpoints und Private Endpoints, um Azure-Dienste (Storage, SQL, Key Vault) vom öffentlichen Internet zu isolieren.

Für die Netzwerksegmentierung in Azure: Trenne Workloads in verschiedene Virtual Networks oder Subnets und kontrolliere den Datenverkehr zwischen ihnen über NSGs und Azure Firewall. Produktions-, Entwicklungs- und Testumgebungen sollten in separaten Subscriptions oder zumindest in getrennten Netzwerken betrieben werden.

8. Ungenutzte und vergessene Ressourcen

Das Problem: Testumgebungen, die nach dem Test nicht abgebaut wurden. VMs, die für ein Projekt erstellt und nach Projektende vergessen wurden. Service Principals und App Registrations, die nicht mehr benötigt werden. Storage Accounts mit alten Daten, die niemand mehr kennt. Jede ungenutzte Ressource ist eine potenzielle Angriffsfläche, die nicht gewartet, nicht gepatcht und nicht überwacht wird.

Die Lösung: Führe ein regelmäßiges Inventar aller Cloud-Ressourcen durch. Azure Resource Graph ermöglicht Abfragen über alle Subscriptions hinweg und hilft, vergessene Ressourcen zu identifizieren. Nutze Tags, um Ressourcen einem Owner, einem Projekt und einem Ablaufdatum zuzuordnen. Ressourcen ohne Owner oder mit abgelaufenem Datum werden geprüft und gegebenenfalls gelöscht.

Azure Advisor identifiziert ungenutzte Ressourcen automatisch (ungenutzte VMs, leere Ressourcengruppen, verwaiste Netzwerkinterfaces) und gibt Empfehlungen. Mache den Azure-Advisor-Review zu einem festen Bestandteil deines monatlichen Cloud-Reviews.

9. Fehlende oder ungetestete Backups

Das Problem: Es gibt kein Backup-Konzept für Cloud-Daten, oder die Backups existieren zwar, wurden aber nie getestet. Viele Unternehmen gehen davon aus, dass der Cloud-Anbieter für Backups sorgt, was ein gefährliches Missverständnis des Shared Responsibility Models ist.

Microsoft 365 bietet zwar Papierkörbe und Versionierung, aber die Aufbewahrungsfristen sind begrenzt und für eine echte Backup-Strategie unzureichend. Azure-VMs werden nicht automatisch gesichert. Und Daten in SaaS-Anwendungen unterliegen dem Shared Responsibility Model: Der Anbieter sorgt für die Verfügbarkeit der Plattform, du sorgst für die Sicherung deiner Daten.

Die Lösung: Implementiere eine explizite Backup-Strategie für alle Cloud-Daten. Für Azure-VMs: Azure Backup mit definierten Backup-Policies (Häufigkeit, Aufbewahrungsdauer, Geo-Redundanz). Für Microsoft 365: Eine dedizierte M365-Backup-Lösung (Veeam, AvePoint, Microsoft 365 Backup), die Exchange, SharePoint, OneDrive und Teams sichert.

Und der wichtigste Punkt: Teste die Wiederherstellung regelmäßig. Ein Backup, das im Ernstfall nicht funktioniert, ist wertlos. Plane vierteljährliche Restore-Tests für die kritischsten Daten und dokumentiere die Ergebnisse.

10. Kein aktives Monitoring und Alerting

Das Problem: Cloud-Dienste werden bereitgestellt und laufen, aber niemand schaut aktiv auf Sicherheitsereignisse. Es gibt keine Alerts, keine Dashboards und keinen definierten Prozess, um auf Sicherheitshinweise zu reagieren. Microsofts Security-Funktionen (Defender for Cloud, Secure Score, Alerts) sind zwar vorhanden, werden aber nicht genutzt.

Die Lösung: Aktiviere als ersten Schritt Microsoft Defender for Cloud (kostenloser Tier) und prüfe die Empfehlungen. Der Microsoft Secure Score gibt dir eine Zahl, die den aktuellen Sicherheitsstatus deiner M365-Umgebung zusammenfasst, und konkrete Verbesserungsvorschläge.

Definiere Alerting-Regeln für die kritischsten Ereignisse: neue Global-Admin-Zuweisungen, Änderungen an Conditional-Access-Policies, Massenanmeldeversuche, verdächtige Anmeldeaktivitäten (unmögliche Reisen, Anmeldungen aus bekannten Angreifernetzen) und Änderungen an Firewall-Regeln. Diese Alerts sollten an ein definiertes Team gehen, das zeitnah reagieren kann.

Für den Mittelstand ohne dediziertes SOC: Ein wöchentlicher Review der Sicherheitsereignisse und monatliche Prüfung der Security-Empfehlungen in Defender for Cloud und Azure Advisor ist ein realistischer, praktikabler Ansatz.

Cloud Security Posture Management (CSPM)

Cloud Security Posture Management beschreibt den kontinuierlichen Prozess, die Sicherheitskonfiguration deiner Cloud-Umgebung zu bewerten, Abweichungen von Best Practices zu identifizieren und Fehlkonfigurationen zu beheben. Es ist im Grunde die Antwort auf die Frage: "Wie stelle ich sicher, dass meine Cloud-Konfiguration dauerhaft sicher bleibt?"

Werkzeuge für den Mittelstand

Microsoft Secure Score: Kostenlos in jeder M365-Umgebung verfügbar. Bewertet die Sicherheitskonfiguration deiner M365-Dienste und gibt priorisierte Empfehlungen. Der Score reicht von 0 bis 100 Prozent. Ein realistisches Ziel für den Mittelstand liegt bei 70 bis 80 Prozent.

Azure Advisor: Kostenlos und in jedem Azure-Portal verfügbar. Gibt Empfehlungen in den Kategorien Sicherheit, Zuverlässigkeit, Leistung, Kosten und Betriebsexzellenz. Die Sicherheitsempfehlungen basieren auf Azure Security Benchmark und decken die häufigsten Fehlkonfigurationen ab.

Microsoft Defender for Cloud: Der kostenlose Tier bietet grundlegende Sicherheitsbewertungen. Die kostenpflichtigen Pläne (Defender for Servers, Defender for Storage etc.) erweitern den Schutz um Schwachstellenscanning, Bedrohungserkennung und erweiterte Empfehlungen. Für KMU mit einer begrenzten Anzahl an Azure-Ressourcen halten sich die Kosten in einem vertretbaren Rahmen.

Azure Policy: Ermöglicht die Durchsetzung von Konfigurationsstandards auf Subscription-Ebene. Du kannst Policies definieren, die bestimmte Konfigurationen erzwingen (zum Beispiel: alle Storage Accounts müssen HTTPS erfordern) oder verhindern (zum Beispiel: keine VMs ohne Disk Encryption). Azure Policy wirkt präventiv und verhindert Fehlkonfigurationen, bevor sie entstehen.

Der monatliche Cloud-Security-Review

Für KMU ohne dediziertes Cloud-Security-Team empfehlen wir einen monatlichen strukturierten Review, der folgende Punkte umfasst:

1. Secure Score prüfen: Hat sich der Score verändert? Gibt es neue Empfehlungen? Welche Quick Wins lassen sich sofort umsetzen?
2. Azure Advisor Sicherheitsempfehlungen prüfen: Gibt es neue Empfehlungen? Welche haben hohe Priorität?
3. Access Review durchführen: Gibt es neue Admin-Accounts? Haben ausgeschiedene Mitarbeiter noch Zugang? Gibt es Gäste-Accounts, die nicht mehr benötigt werden?
4. Sicherheitsereignisse auswerten: Gab es verdächtige Anmeldeaktivitäten? Wurden Sicherheitsalerts ausgelöst? Wurden Konfigurationsänderungen vorgenommen, die nicht geplant waren?
5. Ressourcen-Inventar prüfen: Gibt es neue Ressourcen, die nicht getaggt sind? Gibt es ungenutzte Ressourcen, die abgebaut werden sollten?
6. Backup-Status prüfen: Laufen alle Backup-Jobs erfolgreich? Wann war der letzte Restore-Test?

Dieser Review bindet etwa zwei bis vier Stunden pro Monat und ist damit auch für kleine IT-Teams realistisch umsetzbar. Dokumentiere die Ergebnisse und die eingeleiteten Maßnahmen für dein ISMS. In ISMS Lite lassen sich Cloud-Security-Reviews als wiederkehrende Aufgaben anlegen und die Ergebnisse direkt im Risikoregister verknüpfen.

Praxistipps für Microsoft 365 und Azure

Die folgenden Maßnahmen lassen sich in den meisten M365- und Azure-Umgebungen innerhalb weniger Stunden umsetzen und adressieren die häufigsten Risiken.

Microsoft 365

• Security Defaults aktivieren (falls noch nicht geschehen): Ein Klick im Azure AD Portal aktiviert MFA für alle Benutzer, blockiert Legacy-Authentifizierung und erzwingt MFA für Administratoren.
• Externe Freigaben in SharePoint einschränken: Standardmäßig können Benutzer Inhalte mit jedermann teilen. Schränke die Freigabe auf authentifizierte Gäste ein und deaktiviere die anonyme Freigabe über Links.
• Audit Log Aufbewahrung verlängern: In den Compliance-Einstellungen die maximale Aufbewahrungsdauer für Audit Logs einstellen.
• Safe Attachments und Safe Links aktivieren: Diese Defender-for-Office-365-Funktionen prüfen Anhänge in einer Sandbox und URLs in Echtzeit. Verfügbar ab dem Business-Premium-Plan.
• Conditional Access einrichten (falls P1- oder P2-Lizenz vorhanden): MFA erzwingen für Zugriffe von außerhalb des Firmennetzwerks, Legacy-Protokolle blockieren, Anmeldungen aus Risikoländern einschränken.

Azure

• Azure Security Benchmark aktivieren: Die Initiative "Azure Security Benchmark" in Azure Policy zuweisen. Sie prüft automatisch die Einhaltung von Microsoft-Sicherheitsempfehlungen und zeigt den Compliance-Status.
• Management Locks auf kritische Ressourcen: CanNotDelete-Locks auf Produktions-Ressourcengruppen verhindern versehentliches Löschen.
• Diagnostic Settings für alle kritischen Ressourcen konfigurieren: NSGs, Key Vaults, Storage Accounts und Application Gateways sollten ihre Logs an einen Log Analytics Workspace senden.
• Just-in-Time VM Access aktivieren: Statt VMs permanent mit offenen Management-Ports zu betreiben, öffnet JIT den Zugang nur bei Bedarf und nur für die anfragende IP-Adresse.
• Budget-Alerts konfigurieren: Ungewöhnliche Kostenspitzen können auf kompromittierte Ressourcen hindeuten (zum Beispiel Cryptomining auf gekaperten VMs). Budget-Alerts warnen bei unerwartetem Kostenanstieg.

Cloud-Sicherheit im ISMS

ISO 27001 adressiert Cloud-Sicherheit explizit im Control A.5.23 (Informationssicherheit bei Nutzung von Cloud-Diensten). Darüber hinaus sind zahlreiche weitere Controls für die Cloud-Umgebung relevant:

• A.5.15 bis A.5.18 (Zugangssteuerung): Berechtigungsmanagement in Azure AD
• A.8.1 (Endgeräte): Absicherung der Geräte, die auf Cloud-Dienste zugreifen
• A.8.9 (Konfigurationsmanagement): Sicherheitskonfiguration der Cloud-Dienste
• A.8.10 (Informationslöschung): Datenlöschung in der Cloud und bei Vertragsende
• A.8.11 (Datenmaskierung): Schutz sensibler Daten in Cloud-Umgebungen
• A.8.13 (Informationssicherung): Backup-Strategie für Cloud-Daten
• A.8.15 und A.8.16 (Logging und Monitoring): Überwachung der Cloud-Umgebung

Die Integration der Cloud-Sicherheit in dein ISMS erfordert, dass du dein Risikoregister um Cloud-spezifische Szenarien erweiterst, die Verantwortlichkeiten gemäß dem Shared Responsibility Model dokumentierst, die Konfigurationsstandards für Cloud-Dienste in deine Richtlinien aufnimmst und den regelmäßigen Cloud-Security-Review als Prozess im ISMS verankerst.

Für den Mittelstand empfiehlt sich ein pragmatischer Ansatz: Starte mit den zehn Fehlkonfigurationen aus diesem Artikel als Checkliste. Behebe die kritischsten Punkte zuerst. Etabliere den monatlichen Review. Und erweitere die Maßnahmen schrittweise, wenn du Erfahrung sammelst und die Cloud-Nutzung wächst.

Cloud-Sicherheit ist kein Projekt mit einem Enddatum, sondern ein kontinuierlicher Prozess. Die Cloud-Landschaft verändert sich ständig: Neue Dienste kommen hinzu, Konfigurationsoptionen ändern sich, und neue Bedrohungen erfordern angepasste Maßnahmen. Ein ISMS, das Cloud-Sicherheit als festen Bestandteil integriert, gibt dir das Framework, um diese Veränderungen strukturiert und nachweisbar zu managen.

Weiterführende Artikel

• Zero Trust im Mittelstand: Prinzipien und praktische Umsetzung
• Berechtigungskonzept erstellen: Von der Planung bis zur Umsetzung
• Backup-Strategie und Restore-Tests: So sicherst du deine Daten richtig
• Logging und Monitoring: Strategie für den Mittelstand
• Self-hosted vs. Cloud: Was passt besser zu deinen Compliance-Anforderungen?