Skip to main content

15.5 Cloud-Sicherheit, IAM und Shared Responsibility

Cloud-Sicherheit bedeutet nicht nur, dass der Cloud-Anbieter sichere Rechenzentren betreibt.

Cloud-Sicherheit umfasst auch:

- Identitäten
- Benutzerkonten
- Rollen
- Berechtigungen
- MFA
- Netzwerksicherheit
- Verschlüsselung
- Logging
- Monitoring
- Backup
- sichere Konfiguration
- Datenschutz
- Compliance

Merksatz:

Cloud-Sicherheit ist gemeinsame Verantwortung von Anbieter und Kunde.

Warum Cloud-Sicherheit wichtig ist

Cloud-Ressourcen sind oft schnell erstellt und über Netzwerke erreichbar.

Dadurch entstehen typische Risiken:

zu breite Berechtigungen
öffentliche Speicherfreigaben
offene Managementports
fehlende MFA
falsch konfigurierte Security Groups
öffentliche Datenbanken
ungeschützte API-Schlüssel
fehlende Logs
keine Kostenkontrolle
falscher Datenstandort

Merksatz:

In der Cloud entstehen viele Risiken durch Fehlkonfiguration.

Shared Responsibility Model

Shared Responsibility Model bedeutet:

Anbieter und Kunde teilen sich die Verantwortung.

Der Anbieter ist je nach Dienst verantwortlich für:

Rechenzentrum
physische Sicherheit
Hardware
Grundinfrastruktur
Plattformbetrieb
Verfügbarkeit der angebotenen Dienste

Der Kunde bleibt je nach Dienst verantwortlich für:

Benutzer
Rollen
Daten
Berechtigungen
sichere Konfiguration
Netzwerkfreigaben
Anwendungssicherheit
Backup-Konzept
Compliance

Merksatz:

Cloud bedeutet geteilte Verantwortung,
nicht abgegebene Verantwortung.

Verantwortung hängt vom Service-Modell ab

Die Verantwortung ist bei IaaS, PaaS und SaaS unterschiedlich verteilt.

Bereich IaaS PaaS SaaS
physisches Rechenzentrum Anbieter Anbieter Anbieter
Hardware Anbieter Anbieter Anbieter
Virtualisierung Anbieter Anbieter Anbieter
Betriebssystem Kunde Anbieter Anbieter
Anwendung Kunde Kunde Anbieter
Daten Kunde Kunde Kunde
Benutzer und Rechte Kunde Kunde Kunde
sichere Konfiguration Kunde Kunde Kunde

Merksatz:

Daten,
Benutzer
und Rechte bleiben fast immer Kundenthema.

Cloud-Irrtum: Anbieter macht alles sicher

Falsch:

Der Anbieter betreibt die Cloud,
also ist automatisch alles sicher.

Richtig:

Der Anbieter schützt die Plattform.
Der Kunde muss seine Nutzung sicher konfigurieren.

Beispiel:

Wenn ein Kunde einen Speicher öffentlich freigibt,
ist das meist ein Konfigurationsfehler des Kunden.

Merksatz:

Sichere Plattform plus falsche Konfiguration bleibt unsicher.

IAM

IAM steht für:

Identity and Access Management

IAM regelt, wer auf welche Cloud-Ressourcen zugreifen darf.

IAM umfasst:

Benutzer
Gruppen
Rollen
Berechtigungen
Richtlinien
Servicekonten
API-Schlüssel
MFA
Zugriffsprotokolle

Merksatz:

IAM entscheidet,
wer was in der Cloud darf.

Identität

Eine Identität ist ein Konto oder Objekt, das Zugriff erhalten kann.

Beispiele:

Benutzerkonto
Administrator
Entwickler
Servicekonto
Anwendung
virtuelle Maschine
Containerdienst
Automatisierungsskript

Merksatz:

Nicht nur Menschen,
auch Dienste können Identitäten haben.

Benutzer

Ein Benutzer ist eine menschliche Identität.

Beispiele:

Administrator
Entwickler
Supportmitarbeiter
Fachbereich
externer Dienstleister

Benutzer sollten:

eindeutig zugeordnet sein
keine Sammelkonten nutzen
MFA verwenden
nur notwendige Rechte erhalten
bei Austritt deaktiviert werden

Merksatz:

Jeder Benutzer braucht ein eigenes Konto.

Gruppen

Gruppen fassen Benutzer zusammen.

Beispiel:

Cloud-Admins
Entwickler
Leser
Sicherheitsprüfer
Datenbankadministratoren
Netzwerkadministratoren

Vorteil:

Rechte werden nicht einzeln pro Benutzer vergeben,
sondern über Gruppen verwaltet.

Merksatz:

Gruppen vereinfachen Rechteverwaltung.

Rollen

Eine Rolle beschreibt, welche Aufgaben und Berechtigungen eine Identität hat.

Beispiele:

Leser
Administrator
Netzwerkadministrator
Sicherheitsadministrator
Datenbankadministrator
Abrechnungsadministrator
Backup-Operator

Merksatz:

Rollen ordnen Rechte nach Aufgabe.

Berechtigungen

Berechtigungen legen fest, was erlaubt ist.

Beispiele:

virtuelle Maschine starten
virtuelle Maschine löschen
Speicher lesen
Speicher schreiben
Firewall-Regel ändern
Benutzer anlegen
Logs anzeigen
Backup wiederherstellen

Merksatz:

Berechtigungen sind konkrete Erlaubnisse.

Richtlinien

Richtlinien beschreiben, welche Berechtigungen gelten.

Sie können festlegen:

wer etwas darf
was erlaubt ist
auf welche Ressource es gilt
unter welchen Bedingungen es gilt
was verboten ist

Merksatz:

Richtlinien verbinden Identitäten,
Aktionen
und Ressourcen.

Least Privilege

Least Privilege bedeutet:

nur so viele Rechte wie nötig,
so wenige wie möglich.

In der Cloud ist das besonders wichtig, weil viele Aktionen große Auswirkungen haben können.

Beispiele für riskante Rechte:

alle Ressourcen löschen
Firewall-Regeln ändern
Speicher öffentlich freigeben
Benutzerrechte vergeben
API-Schlüssel erstellen
Backups löschen

Merksatz:

Cloud-Rechte immer minimal vergeben.

Need to Know

Need to Know bedeutet:

Zugriff nur auf Daten oder Systeme,
die für die Aufgabe benötigt werden.

Beispiel:

Entwickler braucht Zugriff auf Testsysteme,
aber nicht automatisch auf Produktionsdaten.

Abrechnung braucht Kostenübersicht,
aber keine Server-Adminrechte.

Merksatz:

Rechte nach Aufgabe,
nicht nach Bequemlichkeit vergeben.

Administratorrechte

Administratorrechte sind besonders kritisch.

Risiken:

versehentliches Löschen
falsche Firewall-Regeln
öffentliche Freigaben
Zugriff auf sensible Daten
Rechteausweitung
Änderung von Logs
Manipulation von Backups

Merksatz:

Administratorrechte nur gezielt und kontrolliert vergeben.

Privileged Access Management

Privileged Access Management wird oft abgekürzt:

PAM

PAM bedeutet:

besonders privilegierte Zugriffe werden kontrolliert,
begrenzt
überwacht
und dokumentiert.

Beispiele:

zeitlich begrenzte Adminrechte
Genehmigungsprozess
MFA
Session Logging
Notfallkonto
regelmäßige Rechteprüfung

Merksatz:

PAM schützt besonders mächtige Zugriffe.

Just-in-Time-Zugriff

Just-in-Time-Zugriff bedeutet:

Rechte werden nur für einen begrenzten Zeitraum vergeben.

Beispiel:

Admin braucht für 2 Stunden erhöhte Rechte,
um eine Wartung durchzuführen.

Nach Ablauf werden die Rechte automatisch entzogen.

Merksatz:

Just-in-Time reduziert dauerhafte Adminrechte.

Sammelkonten vermeiden

Sammelkonten sind gemeinsame Konten, die mehrere Personen nutzen.

Problem:

keine eindeutige Zuordnung
schlechte Nachvollziehbarkeit
Passwortweitergabe
schwieriges Offboarding
Sicherheitsvorfälle schwer aufklärbar

Merksatz:

Cloud-Zugriffe müssen personengebunden nachvollziehbar sein.

Servicekonto

Ein Servicekonto ist eine Identität für einen Dienst oder eine Anwendung.

Beispiele:

Backup-Dienst
Automatisierung
CI/CD-Pipeline
Monitoring
Anwendung, die auf Speicher zugreift
Skript, das Ressourcen erstellt

Servicekonten sollten ebenfalls nur minimale Rechte erhalten.

Merksatz:

Servicekonten sind Maschinenidentitäten und brauchen genauso Rechtebegrenzung.

API-Schlüssel

API-Schlüssel erlauben Programmen oder Skripten Zugriff auf Cloud-Dienste.

Risiken:

Schlüssel wird versehentlich veröffentlicht
Schlüssel liegt im Quellcode
Schlüssel hat zu viele Rechte
Schlüssel wird nie rotiert
Schlüssel wird nach Projektende nicht gelöscht

Merksatz:

API-Schlüssel wie Passwörter behandeln.

Secrets

Secrets sind geheime Informationen.

Beispiele:

Passwörter
API-Schlüssel
private Schlüssel
Tokens
Datenbankzugangsdaten
Zertifikate

Secrets sollten nicht liegen in:

Quellcode
öffentlichen Repositories
Klartextdateien
Chatnachrichten
ungeschützten Wikiseiten
unverschlüsselten Backups

Merksatz:

Secrets gehören in geschützte Secret-Verwaltung.

Secret Management

Secret Management bedeutet:

geheime Informationen sicher speichern,
verteilen
rotieren
und widerrufen.

Wichtig:

Zugriff begrenzen
Nutzung protokollieren
Rotation ermöglichen
keine Klartextspeicherung
Notfallzugriff regeln
alte Secrets entfernen

Merksatz:

Secret Management verhindert unkontrollierten Umgang mit Zugangsdaten.

MFA in der Cloud

MFA steht für:

Multi-Faktor-Authentifizierung

MFA sollte besonders gelten für:

Administratoren
externe Benutzer
Zugriff auf sensible Daten
Zugriff auf Abrechnung
Zugriff auf IAM
Zugriff auf Produktion
Zugriff von unbekannten Geräten

Merksatz:

Cloud-Adminzugänge ohne MFA sind ein hohes Risiko.

Conditional Access

Conditional Access bedeutet:

Zugriff wird von Bedingungen abhängig gemacht.

Bedingungen können sein:

Benutzerrolle
Gerätetyp
Gerätezustand
Standort
Risiko des Logins
Anwendung
MFA erfüllt
Uhrzeit
Netzwerk

Beispiel:

Adminzugriff nur mit MFA und verwaltetem Gerät.

Merksatz:

Conditional Access prüft Kontext vor Zugriff.

Zero Trust in der Cloud

Zero Trust bedeutet:

keinem Zugriff automatisch vertrauen.

Auch innerhalb der Cloud wird geprüft:

Wer greift zu?
Von welchem Gerät?
Auf welche Ressource?
Mit welchem Risiko?
Mit welcher Rolle?
Ist MFA erfüllt?
Ist Zugriff ungewöhnlich?

Merksatz:

Zero Trust prüft jeden Zugriff kontextbezogen.

Rollenbasierte Zugriffskontrolle

Rollenbasierte Zugriffskontrolle wird oft abgekürzt:

RBAC

RBAC bedeutet:

Rechte werden über Rollen vergeben.

Beispiel:

Rolle Leser:
darf Ressourcen ansehen

Rolle Netzwerkadministrator:
darf Netzwerke verwalten

Rolle Besitzer:
darf fast alles verwalten

Merksatz:

RBAC macht Rechteverwaltung strukturierter.

Attributbasierte Zugriffskontrolle

Attributbasierte Zugriffskontrolle wird oft abgekürzt:

ABAC

ABAC entscheidet anhand von Attributen.

Beispiele für Attribute:

Abteilung
Projekt
Umgebung
Datenklasse
Standort
Gerätestatus
Tag
Uhrzeit

Merksatz:

ABAC nutzt Eigenschaften für Zugriffsentscheidungen.

RBAC und ABAC vergleichen

Merkmal RBAC ABAC
Grundlage Rollen Attribute
Beispiel Admin, Leser, Entwickler Projekt, Tag, Standort, Datenklasse
Vorteil übersichtlich sehr flexibel
Nachteil Rollen können zu grob werden komplexer zu planen
Einsatz klassische Rechtevergabe feinere Kontextregeln

Merksatz:

RBAC arbeitet mit Rollen.
ABAC arbeitet mit Eigenschaften.

Mandant und Tenant

Ein Tenant ist ein logisch getrennter Bereich in einer Cloud- oder SaaS-Plattform.

Er enthält typischerweise:

Benutzer
Gruppen
Rollen
Richtlinien
Anwendungen
Einstellungen
Ressourcen
Abrechnung

Merksatz:

Tenant = eigener Verwaltungsbereich in einer Cloud-Plattform.

Mandantentrennung

Mandantentrennung bedeutet:

Daten und Ressourcen verschiedener Kunden oder Organisationseinheiten werden logisch getrennt.

Wichtig bei:

Public Cloud
SaaS
Hosting
Multi-Tenant-Anwendungen
Dienstleisterplattformen

Merksatz:

Mandantentrennung verhindert Vermischung fremder Kundenbereiche.

Single Sign-On

Single Sign-On wird abgekürzt:

SSO

SSO bedeutet:

Benutzer melden sich einmal an
und können mehrere Dienste nutzen.

Vorteile:

weniger Passwörter
zentrale Anmeldung
bessere Kontrolle
einfacheres Offboarding
MFA zentral möglich

Merksatz:

SSO vereinfacht Anmeldung und zentrale Zugriffskontrolle.

Identity Provider

Identity Provider wird oft abgekürzt:

IdP

Ein Identity Provider stellt Identitäten und Anmeldungen bereit.

Er prüft zum Beispiel:

Benutzername
Passwort
MFA
Richtlinien
Gruppen
Rollen

Merksatz:

IdP ist die zentrale Stelle für Anmeldung.

Föderation

Föderation bedeutet:

Eine Organisation vertraut der Anmeldung einer anderen Identitätsquelle.

Beispiel:

Benutzer meldet sich mit Unternehmensidentität bei einem Cloud-Dienst an.

Der Cloud-Dienst muss das Passwort nicht selbst verwalten, sondern vertraut dem Identity Provider.

Merksatz:

Föderation verbindet Identitätswelten.

SAML

SAML steht für:

Security Assertion Markup Language

SAML wird häufig für Single Sign-On genutzt.

Grundidee:

Identity Provider bestätigt dem Dienst,
dass der Benutzer erfolgreich angemeldet ist.

Merksatz:

SAML ermöglicht SSO zwischen Identitätsanbieter und Dienst.

OAuth 2.0

OAuth 2.0 ist ein Autorisierungsstandard.

Er wird genutzt, damit Anwendungen Zugriff auf Ressourcen erhalten können, ohne direkt das Benutzerpasswort zu kennen.

Beispiel:

Eine Anwendung darf auf Kalenderdaten zugreifen,
nachdem der Benutzer zugestimmt hat.

Merksatz:

OAuth 2.0 regelt delegierte Autorisierung.

OpenID Connect

OpenID Connect baut auf OAuth 2.0 auf und ergänzt Authentifizierung.

Es wird häufig für moderne Logins genutzt.

Merksatz:

OpenID Connect ergänzt OAuth 2.0 um Identitätsinformationen.

Authentifizierung und Autorisierung in der Cloud

Authentifizierung:

Wer bist du?

Autorisierung:

Was darfst du?

Beispiele:

Benutzer meldet sich erfolgreich an.
Das ist Authentifizierung.

Benutzer darf eine VM löschen.
Das ist Autorisierung.

Merksatz:

Anmeldung und Berechtigung immer unterscheiden.

Cloud-Netzwerksicherheit

Cloud-Netzwerksicherheit umfasst:

VPC oder VNet
Subnetze
Security Groups
NSGs
Firewalls
private Endpunkte
VPN
Peering
Routing
DNS
WAF
DDoS-Schutz

Merksatz:

Cloud-Sicherheit besteht aus IAM und Netzwerkschutz.

Private Endpoint

Ein Private Endpoint macht einen Cloud-Dienst über eine private IP im eigenen Cloud-Netz erreichbar.

Vorteil:

Zugriff muss nicht über das öffentliche Internet erfolgen.

Beispiel:

Anwendung greift auf Cloud-Datenbank über private Adresse zu.

Merksatz:

Private Endpoint hält Cloud-Dienste intern erreichbar.

Public Endpoint

Ein Public Endpoint ist öffentlich über das Internet erreichbar.

Beispiele:

öffentliche API
Webanwendung
öffentliches SaaS-Portal
Storage-URL mit öffentlichem Zugriff

Wichtig:

Public Endpoints brauchen starke Zugriffskontrolle,
TLS,
Logging
und Schutzregeln.

Merksatz:

Public Endpoint nur bewusst und abgesichert nutzen.

WAF

WAF steht für:

Web Application Firewall

Eine WAF schützt Webanwendungen vor typischen Angriffen.

Beispiele:

SQL Injection
Cross-Site Scripting
bösartige Requests
ungewöhnliche Muster
bekannte Angriffssignaturen

Merksatz:

WAF schützt Webanwendungen auf Anwendungsebene.

DDoS-Schutz

DDoS steht für:

Distributed Denial of Service

Dabei versuchen viele Systeme, einen Dienst durch massenhafte Anfragen zu überlasten.

Cloud-Anbieter bieten oft Schutzfunktionen gegen DDoS-Angriffe.

Merksatz:

DDoS-Schutz soll Dienste trotz Massenangriffen verfügbar halten.

Verschlüsselung in der Cloud

Verschlüsselung ist wichtig für:

Daten bei Übertragung
Daten im Ruhezustand
Backups
Datenbanken
Speicher
Logs
Schlüsselverwaltung

Merksatz:

Verschlüsselung schützt Daten,
ersetzt aber keine Rechteverwaltung.

Verschlüsselung während der Übertragung

Daten während der Übertragung sollten verschlüsselt werden.

Typische Technik:

TLS

Beispiele:

HTTPS
API-Aufrufe
Datenbankverbindungen
Verwaltungsschnittstellen
SaaS-Zugriffe

Merksatz:

Daten unterwegs mit TLS schützen.

Verschlüsselung im Ruhezustand

Daten im Ruhezustand sind gespeicherte Daten.

Beispiele:

Datenbankdaten
Dateien im Storage
Backups
Snapshots
Logs
virtuelle Festplatten

Diese Daten sollten verschlüsselt gespeichert werden.

Merksatz:

Gespeicherte Daten ebenfalls verschlüsseln.

Schlüsselverwaltung

Verschlüsselung braucht Schlüssel.

Wichtige Fragen:

Wer erstellt Schlüssel?
Wer verwaltet Schlüssel?
Wer darf Schlüssel nutzen?
Werden Schlüssel rotiert?
Wo werden Schlüssel gespeichert?
Was passiert bei Schlüsselverlust?
Wer kann Daten entschlüsseln?

Merksatz:

Verschlüsselung ist nur so sicher wie die Schlüsselverwaltung.

KMS

KMS steht für:

Key Management Service

Ein KMS verwaltet kryptografische Schlüssel.

Aufgaben:

Schlüssel erzeugen
Schlüssel speichern
Schlüssel rotieren
Zugriff auf Schlüssel steuern
Nutzung protokollieren
Schlüssel deaktivieren oder löschen

Merksatz:

KMS verwaltet Schlüssel für Cloud-Verschlüsselung.

Kundenverwaltete Schlüssel

Bei kundenverwalteten Schlüsseln kontrolliert der Kunde stärker, welche Schlüssel für Verschlüsselung genutzt werden.

Vorteile:

mehr Kontrolle
eigene Richtlinien
Schlüsselrotation steuerbar
Zugriff besser begrenzbar

Risiko:

Schlüsselverlust kann Daten unbrauchbar machen.

Merksatz:

Mehr Schlüsselhoheit bedeutet auch mehr Verantwortung.

Cloud-Logging

Cloud-Logging ist sicherheitskritisch.

Wichtige Logarten:

Anmeldungen
API-Aufrufe
Rechteänderungen
Netzwerkzugriffe
Firewall-Entscheidungen
Datenzugriffe
Adminaktionen
Fehlermeldungen
Sicherheitsereignisse
Kostenereignisse

Merksatz:

Cloud-Logs zeigen,
wer was wann getan hat.

Audit-Logs

Audit-Logs dokumentieren administrative und sicherheitsrelevante Aktionen.

Beispiele:

Benutzer erstellt
Rolle geändert
Firewall geöffnet
VM gelöscht
Speicher öffentlich gemacht
API-Schlüssel erstellt
MFA deaktiviert
Backup gelöscht

Merksatz:

Audit-Logs sind wichtig für Nachvollziehbarkeit.

Cloud-Monitoring

Cloud-Monitoring überwacht Betrieb und Sicherheit.

Wichtige Werte:

Verfügbarkeit
CPU
RAM
Speicher
Datenbanklast
Netzwerkverkehr
Loginfehler
ungewöhnliche Zugriffe
Kosten
Zertifikatsablauf
Backupstatus

Merksatz:

Monitoring erkennt technische und sicherheitsrelevante Probleme.

SIEM

SIEM steht für:

Security Information and Event Management

Ein SIEM sammelt und analysiert Sicherheitslogs aus verschiedenen Quellen.

Ziel:

Angriffe erkennen
Auffälligkeiten korrelieren
Alarmierungen erzeugen
Sicherheitsvorfälle untersuchen
Nachweise bereitstellen

Merksatz:

SIEM hilft,
Sicherheitsereignisse zentral auszuwerten.

Cloud-Backup

Auch Cloud-Dienste brauchen Backup.

Wichtige Fragen:

Welche Daten werden gesichert?
Wie oft?
Wie lange?
Wo werden Backups gespeichert?
Wer darf wiederherstellen?
Sind Backups verschlüsselt?
Sind Backups vor Löschung geschützt?
Wurde Wiederherstellung getestet?

Merksatz:

Cloud ist kein Ersatz für Backup.

Ransomware-Schutz in der Cloud

Auch Cloud-Daten können durch Ransomware betroffen sein.

Risiken:

synchronisierte verschlüsselte Dateien
gelöschte Backups
kompromittierte Adminzugänge
manipulierte Datenbanken
missbrauchte API-Schlüssel

Schutz:

MFA
getrennte Adminrollen
unveränderliche Backups
Versionierung
Least Privilege
Monitoring
schnelles Offboarding

Merksatz:

Ransomware-Schutz braucht Backup,
Rechtebegrenzung
und Monitoring.

Immutable Backup

Immutable bedeutet:

unveränderlich

Ein Immutable Backup kann für einen festgelegten Zeitraum nicht verändert oder gelöscht werden.

Vorteil:

Schutz vor versehentlicher Löschung
Schutz vor Ransomware
bessere Wiederherstellungschancen

Merksatz:

Unveränderliche Backups schützen vor Manipulation und Löschung.

Datenschutz in der Cloud

Cloud-Datenschutz fragt:

Welche Daten werden verarbeitet?
Wo werden Daten gespeichert?
Wer hat Zugriff?
Gibt es Auftragsverarbeitung?
Sind Daten verschlüsselt?
Gibt es Löschkonzepte?
Wie werden Betroffenenrechte erfüllt?
Werden Logs personenbezogen?
Welche Unterauftragnehmer gibt es?

Merksatz:

Cloud-Dienste brauchen Datenschutzprüfung.

Datenklassifizierung

Datenklassifizierung bedeutet:

Daten werden nach Schutzbedarf eingeteilt.

Beispiele:

öffentlich
intern
vertraulich
streng vertraulich
personenbezogen
geschäftskritisch

Je höher der Schutzbedarf, desto strenger müssen Zugriff, Verschlüsselung, Logging und Speicherort geregelt sein.

Merksatz:

Schutzmaßnahmen richten sich nach Datenklasse.

Compliance in der Cloud

Compliance bedeutet:

Einhaltung von Regeln,
Gesetzen,
Standards
und internen Vorgaben.

Cloud-relevant:

Datenschutz
Informationssicherheit
Aufbewahrung
Löschung
Auditierbarkeit
Zugriffskontrolle
Datenstandort
Vertragsprüfung
Branchenvorgaben

Merksatz:

Cloud muss zu rechtlichen und organisatorischen Vorgaben passen.

Cloud-Sicherheitsrichtlinie

Eine Cloud-Sicherheitsrichtlinie sollte festlegen:

erlaubte Dienste
erlaubte Regionen
Rollenmodell
MFA-Pflicht
Logging-Pflicht
Verschlüsselung
Backup-Vorgaben
Tagging
Kostenkontrolle
Freigabeprozesse
Umgang mit externen Benutzern
Lösch- und Aufbewahrungsregeln

Merksatz:

Cloud-Sicherheit braucht klare Regeln.

Cloud-Governance

Cloud Governance bedeutet:

Steuerung und Kontrolle der Cloud-Nutzung.

Ziele:

Sicherheit
Kostenkontrolle
Compliance
Standardisierung
klare Verantwortlichkeiten
Vermeidung von Schatten-IT
Nachvollziehbarkeit
Ordnung in Ressourcen

Merksatz:

Governance sorgt dafür,
dass Cloud kontrolliert genutzt wird.

Typische Cloud-Sicherheitsfehler

Häufige Fehler:

MFA nicht aktiviert
Adminrechte zu breit
öffentliche Speicherfreigaben
Datenbank öffentlich erreichbar
Security Group erlaubt 0.0.0.0/0 auf Adminport
API-Schlüssel im Quellcode
Servicekonto mit Vollzugriff
Logs deaktiviert
Backups nicht getestet
alte Benutzerkonten aktiv
keine Kostenalarme
kein Offboarding
falsche Region
keine Verschlüsselung
keine Rechteprüfung

Merksatz:

Cloud-Sicherheitsfehler sind oft Konfigurationsfehler.

Checkliste: Cloud-IAM sicher gestalten

MFA für Admins erzwingen.
Keine Sammelkonten nutzen.
Benutzer eindeutig zuordnen.
Gruppen und Rollen verwenden.
Least Privilege umsetzen.
Adminrechte zeitlich begrenzen.
Servicekonten minimal berechtigen.
API-Schlüssel schützen.
Secrets nicht im Quellcode speichern.
Regelmäßige Rechteprüfung durchführen.
Offboarding konsequent umsetzen.
Audit-Logs aktivieren.

Merksatz:

IAM ist die wichtigste Sicherheitsbasis in der Cloud.

Checkliste: Cloud-Ressourcen sicher konfigurieren

Öffentliche Erreichbarkeit prüfen.
Managementports nicht öffentlich öffnen.
Datenbanken privat bereitstellen.
Security Groups eng setzen.
Verschlüsselung aktivieren.
Backups einrichten.
Logs aktivieren.
Monitoring einrichten.
Tags setzen.
Kostenalarme setzen.
Region bewusst auswählen.
Änderungen dokumentieren.

Merksatz:

Cloud-Ressourcen sicher konfigurieren,
bevor sie produktiv genutzt werden.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Was bedeutet Shared Responsibility Model?
- Was ist IAM?
- Warum ist IAM in der Cloud wichtig?
- Was ist der Unterschied zwischen Authentifizierung und Autorisierung?
- Was bedeutet Least Privilege?
- Was ist RBAC?
- Was ist ABAC?
- Was ist ein Tenant?
- Was ist Mandantentrennung?
- Warum sollte MFA für Cloud-Admins Pflicht sein?
- Warum sind API-Schlüssel kritisch?
- Was ist Secret Management?
- Was ist ein Private Endpoint?
- Was ist eine WAF?
- Was ist ein KMS?
- Warum ersetzt Verschlüsselung keine Rechteverwaltung?
- Warum braucht Cloud Logging und Monitoring?
- Warum ist Cloud kein Ersatz für Backup?
- Was ist ein Immutable Backup?
- Warum ist Datenklassifizierung wichtig?

Typische Prüfungsfallen

Cloud-Sicherheit ist gemeinsame Verantwortung.

Anbieter ist nicht automatisch für Kundendatenrechte verantwortlich.

Daten,
Benutzer
und Rechte bleiben fast immer Kundenthema.

IAM ist zentral für Cloud-Sicherheit.

Authentifizierung ist nicht Autorisierung.

MFA für Admins ist besonders wichtig.

Adminrechte nicht dauerhaft und breit vergeben.

Servicekonten sind ebenfalls Identitäten.

API-Schlüssel wie Passwörter behandeln.

Secrets nicht im Quellcode speichern.

RBAC arbeitet mit Rollen.

ABAC arbeitet mit Attributen.

Tenant ist ein Verwaltungsbereich.

Mandantentrennung schützt Kundenbereiche.

SSO vereinfacht zentrale Anmeldung.

OAuth 2.0 ist Autorisierung.

OpenID Connect ergänzt Authentifizierung.

Private Endpoint vermeidet öffentlichen Zugriff.

Public Endpoint braucht besonderen Schutz.

WAF schützt Webanwendungen.

Verschlüsselung ersetzt keine Zugriffsrechte.

KMS verwaltet Schlüssel.

Cloud-Logs müssen aktiv sein.

Backup muss auch in der Cloud geplant werden.

Immutable Backup schützt vor Löschung und Manipulation.

Datenschutz und Compliance müssen geprüft werden.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
Shared Responsibility geteilte Verantwortung zwischen Anbieter und Kunde
IAM Identity and Access Management
Identität Konto oder Dienst mit Zugriff
Benutzer menschliche Identität
Gruppe Zusammenfassung von Benutzern
Rolle Aufgabenbezogene Rechte
Berechtigung konkrete Erlaubnis
Richtlinie Regel für Zugriff
Least Privilege minimale notwendige Rechte
Need to Know Zugriff nur bei Bedarf
PAM Kontrolle privilegierter Zugriffe
Just-in-Time zeitlich begrenzte Rechte
Servicekonto Identität für Dienst oder Anwendung
API-Schlüssel Zugriffsschlüssel für Programme
Secret geheime Information
Secret Management Verwaltung geheimer Informationen
MFA Multi-Faktor-Authentifizierung
Conditional Access Zugriff abhängig von Bedingungen
Zero Trust kein automatisches Vertrauen
RBAC rollenbasierte Zugriffskontrolle
ABAC attributbasierte Zugriffskontrolle
Tenant logisch getrennter Verwaltungsbereich
Mandantentrennung Trennung verschiedener Kundenbereiche
SSO Single Sign-On
IdP Identity Provider
Föderation Vertrauen zwischen Identitätsquellen
SAML SSO-Standard
OAuth 2.0 delegierte Autorisierung
OpenID Connect Authentifizierung auf Basis von OAuth 2.0
Private Endpoint privater Zugriff auf Cloud-Dienst
Public Endpoint öffentlicher Zugriffspunkt
WAF Web Application Firewall
DDoS Überlastungsangriff
KMS Key Management Service
Audit-Log Nachweis sicherheitsrelevanter Aktionen
SIEM zentrale Sicherheitslog-Auswertung
Immutable Backup unveränderliches Backup
Datenklassifizierung Einteilung nach Schutzbedarf
Compliance Einhaltung von Vorgaben
Cloud Governance Steuerung der Cloud-Nutzung

IHK-sichere Kurzformulierung

Cloud-Sicherheit basiert auf dem Shared Responsibility Model. Der Anbieter schützt je nach Service-Modell die Plattform, Infrastruktur und den Dienstbetrieb, während der Kunde für Benutzer, Rollen, Berechtigungen, Daten, sichere Konfiguration, Zugriffsschutz, Backup, Logging, Monitoring und Compliance verantwortlich bleibt. IAM, also Identity and Access Management, ist ein zentraler Bestandteil der Cloud-Sicherheit, da es regelt, wer welche Ressourcen nutzen oder verändern darf. Wichtige Prinzipien sind MFA, Least Privilege, rollenbasierte Rechtevergabe, sichere Servicekonten, Schutz von API-Schlüsseln, Secret Management, Logging, Verschlüsselung und regelmäßige Rechteprüfung. Cloud-Sicherheit entsteht durch Technik, Prozesse und klare Verantwortlichkeiten.


Merksätze

Cloud-Sicherheit ist gemeinsame Verantwortung.

Anbieter schützt Plattform,
Kunde schützt Nutzung und Daten.

Daten,
Benutzer
und Rechte bleiben fast immer Kundenthema.

IAM entscheidet,
wer was darf.

Nicht nur Menschen haben Identitäten.

Servicekonten brauchen minimale Rechte.

API-Schlüssel wie Passwörter behandeln.

Secrets nicht im Quellcode speichern.

MFA für Admins erzwingen.

Authentifizierung = Wer bist du?

Autorisierung = Was darfst du?

Least Privilege gilt immer.

Adminrechte zeitlich und fachlich begrenzen.

Sammelkonten vermeiden.

RBAC nutzt Rollen.

ABAC nutzt Attribute.

Tenant ist ein Cloud-Verwaltungsbereich.

SSO vereinfacht zentrale Anmeldung.

IdP prüft Identitäten.

OAuth 2.0 ist Autorisierung.

OpenID Connect ergänzt Authentifizierung.

Private Endpoint hält Zugriff intern.

Public Endpoint besonders schützen.

WAF schützt Webanwendungen.

DDoS-Schutz schützt Verfügbarkeit.

Verschlüsselung ersetzt keine Rechte.

KMS verwaltet Schlüssel.

Audit-Logs zeigen Adminaktionen.

SIEM wertet Sicherheitsereignisse zentral aus.

Cloud ist kein Ersatz für Backup.

Immutable Backup schützt vor Manipulation.

Datenklassifizierung bestimmt Schutzbedarf.

Cloud Governance schafft Regeln.

Fehlkonfiguration ist eines der größten Cloud-Risiken.