15. Cloud und moderne Bereitstellungsmodelle

15.1 Cloud und moderne Bereitstellungsmodelle

Cloud beschreibt die Bereitstellung von IT-Ressourcen über ein Netzwerk.

Statt alle Systeme selbst lokal zu betreiben, können Unternehmen Rechenleistung, Speicher, Datenbanken, Anwendungen oder Plattformen bei einem Anbieter nutzen.

Typische Cloud-Ressourcen:

- virtuelle Server
- Speicherplatz
- Datenbanken
- Container
- Anwendungen
- Entwicklungsplattformen
- Backup-Dienste
- Identitätsdienste
- Netzwerkdienste
- Sicherheitsdienste

Merksatz:

Cloud bedeutet:
IT-Ressourcen werden als Dienst bereitgestellt.

Warum ist Cloud wichtig?

Cloud-Dienste sind in modernen IT-Umgebungen sehr verbreitet.

Gründe:

- schnelle Bereitstellung
- flexible Skalierung
- weniger eigene Hardware
- weltweite Erreichbarkeit
- nutzungsabhängige Kosten
- viele fertige Dienste
- hohe Automatisierbarkeit
- gute Integration mit modernen Anwendungen

Aber:

Cloud bedeutet nicht automatisch weniger Verantwortung.

Merksatz:

Cloud vereinfacht Bereitstellung,
ersetzt aber kein Sicherheits- und Betriebskonzept.

Cloud einfach erklärt

Klassisch:

Unternehmen kauft Server.
Server steht im eigenen Gebäude.
IT installiert Betriebssystem.
IT betreibt Anwendung.
IT kümmert sich um Hardware,
Strom,
Kühlung,
Backup
und Ausfallsicherheit.

Cloud:

Anbieter stellt Ressourcen bereit.
Unternehmen nutzt diese Ressourcen über Netzwerk oder Portal.
Abrechnung erfolgt häufig nach Nutzung.
Verantwortung wird je nach Modell zwischen Anbieter und Kunde geteilt.

Merksatz:

Cloud verlagert Teile der IT-Bereitstellung zu einem Anbieter.

On-Premises

On-Premises bedeutet:

IT wird lokal im eigenen Unternehmen oder eigenen Rechenzentrum betrieben.

Beispiele:

eigener Serverraum
eigenes Rechenzentrum
eigene Hardware
eigene Storage-Systeme
eigene Netzwerkgeräte
eigene Virtualisierung

Vorteile:

hohe Kontrolle
direkte Verwaltung
Daten bleiben im eigenen Betrieb
individuelle Anpassung möglich

Nachteile:

Hardwarekosten
Wartungsaufwand
Skalierung langsamer
eigene Verantwortung für Ausfallsicherheit

Merksatz:

On-Premises = lokal selbst betrieben.

Cloud

Cloud bedeutet:

IT-Ressourcen werden über ein Netzwerk als Dienst genutzt.

Beispiele:

virtueller Server beim Cloud-Anbieter
Cloud-Speicher
gehostete Datenbank
E-Mail aus der Cloud
Backup in der Cloud
Cloud-Identitätsdienst
Containerplattform

Merksatz:

Cloud = IT-Ressourcen als Dienst.

Hybrid Cloud

Hybrid Cloud kombiniert lokale IT und Cloud.

Beispiel:

interne Server im eigenen Rechenzentrum
plus
Cloud-Dienste für Backup,
Webanwendungen
oder Skalierung

Typische Einsatzfälle:

schrittweise Migration
sensible Systeme lokal
skalierbare Dienste in Cloud
Backup in Cloud
Cloud-Anbindung per VPN

Merksatz:

Hybrid Cloud kombiniert On-Premises und Cloud.

Multi Cloud

Multi Cloud bedeutet:

Ein Unternehmen nutzt mehrere Cloud-Anbieter.

Beispiel:

Anbieter A für virtuelle Server
Anbieter B für E-Mail
Anbieter C für Backup
Anbieter D für KI-Dienste

Vorteile:

weniger Abhängigkeit von einem Anbieter
passende Dienste pro Anbieter
Ausfallsicherheit durch Verteilung

Nachteile:

höhere Komplexität
unterschiedliche Portale
unterschiedliche Sicherheitsmodelle
schwierigeres Monitoring
mehr Know-how nötig

Merksatz:

Multi Cloud = mehrere Cloud-Anbieter gleichzeitig.

Public Cloud

Public Cloud bedeutet:

Cloud-Ressourcen werden von einem Anbieter für viele Kunden bereitgestellt.

Beispiele:

virtuelle Server
Datenbanken
Speicher
Webdienste
Cloud-Anwendungen

Wichtig:

Kunden teilen sich die Anbieterplattform,
sind aber logisch voneinander getrennt.

Merksatz:

Public Cloud = gemeinsam genutzte Anbieterplattform mit logischer Trennung.

Private Cloud

Private Cloud bedeutet:

Cloud-ähnliche Bereitstellung nur für eine Organisation.

Sie kann laufen:

im eigenen Rechenzentrum
bei einem Dienstleister
in einer dedizierten Umgebung

Typische Merkmale:

Selbstbedienung
Automatisierung
Virtualisierung
Ressourcenpools
interne Abrechnung oder Zuordnung
zentrale Verwaltung

Merksatz:

Private Cloud = Cloud-Prinzipien für eine Organisation.

Community Cloud

Community Cloud bedeutet:

Eine Cloud wird von mehreren Organisationen mit ähnlichen Anforderungen genutzt.

Beispiele:

Behörden
Forschungseinrichtungen
Gesundheitswesen
Bildungseinrichtungen

Ziel:

gemeinsame Anforderungen
gemeinsame Sicherheitsvorgaben
gemeinsame Compliance

Merksatz:

Community Cloud wird von einer bestimmten Gemeinschaft genutzt.

Cloud-Bereitstellungsmodelle

Modell Kurze Erklärung
On-Premises lokal selbst betrieben
Public Cloud Cloud beim öffentlichen Anbieter
Private Cloud Cloud für eine Organisation
Hybrid Cloud Mischung aus lokal und Cloud
Multi Cloud Nutzung mehrerer Cloud-Anbieter
Community Cloud Cloud für bestimmte Organisationengruppe

Merksatz:

Bereitstellungsmodell beschreibt,
wo und für wen Cloud-Ressourcen betrieben werden.

Cloud-Service-Modelle

Die wichtigsten Service-Modelle sind:

- IaaS
- PaaS
- SaaS

Diese Modelle beschreiben, wie viel Verantwortung der Anbieter übernimmt und wie viel der Kunde selbst verwaltet.

Merksatz:

Service-Modell beschreibt,
welche Schichten als Dienst bereitgestellt werden.

IaaS

IaaS steht für:

Infrastructure as a Service

Dabei stellt der Anbieter grundlegende Infrastruktur bereit.

Beispiele:

virtuelle Maschinen
virtuelle Netzwerke
Block Storage
Load Balancer
Firewalls
IP-Adressen

Der Kunde verwaltet meist:

Betriebssystem
Updates im Betriebssystem
Anwendungen
Daten
Benutzer
Konfigurationen

Merksatz:

IaaS = virtuelle Infrastruktur statt eigener Hardware.

PaaS

PaaS steht für:

Platform as a Service

Dabei stellt der Anbieter eine Plattform bereit, auf der Anwendungen betrieben werden können.

Beispiele:

verwaltete Datenbank
App-Plattform
Web-App-Plattform
Containerplattform
Laufzeitumgebung
Entwicklungsplattform

Der Kunde verwaltet meist:

Anwendung
Daten
Konfiguration
Zugriff

Der Anbieter verwaltet mehr vom Betriebssystem, Runtime und Infrastruktur.

Merksatz:

PaaS = Plattform für Anwendungen,
ohne alles darunter selbst zu betreiben.

SaaS

SaaS steht für:

Software as a Service

Dabei nutzt der Kunde eine fertige Anwendung.

Beispiele:

E-Mail-Dienst
Online-Office
CRM-System
Ticketsystem
Cloud-Speicher
Videokonferenzdienst
Projektmanagement-Tool

Der Anbieter betreibt:

Anwendung
Plattform
Infrastruktur
Updates
Verfügbarkeit

Der Kunde kümmert sich vor allem um:

Benutzer
Berechtigungen
Daten
Einstellungen
Sicherheitsrichtlinien

Merksatz:

SaaS = fertige Software aus der Cloud.

IaaS, PaaS und SaaS vergleichen

Modell Anbieter stellt bereit Kunde verwaltet vor allem
IaaS virtuelle Infrastruktur Betriebssystem, Anwendung, Daten
PaaS Plattform und Laufzeitumgebung Anwendung, Daten, Konfiguration
SaaS fertige Anwendung Benutzer, Daten, Einstellungen

Merksatz:

IaaS gibt viel Kontrolle.
SaaS nimmt viel Betrieb ab.
PaaS liegt dazwischen.

Verantwortung bei Cloud

In der Cloud wird Verantwortung geteilt.

Der Anbieter ist nicht für alles verantwortlich.

Der Kunde bleibt verantwortlich für viele Dinge, zum Beispiel:

- Benutzerkonten
- Berechtigungen
- Daten
- sichere Konfiguration
- Passwörter und MFA
- Netzfreigaben
- Zugriffskonzepte
- Compliance
- Backup-Strategie je nach Dienst

Merksatz:

Cloud bedeutet geteilte Verantwortung.

Shared Responsibility Model

Shared Responsibility Model bedeutet:

Anbieter und Kunde teilen sich Sicherheits- und Betriebsverantwortung.

Je nach Service-Modell verändert sich die Aufteilung.

Bei IaaS hat der Kunde mehr Verantwortung.

Bei SaaS übernimmt der Anbieter mehr Betrieb, aber der Kunde bleibt für Benutzer, Daten und Berechtigungen verantwortlich.

Merksatz:

Je fertiger der Dienst,
desto mehr Betrieb übernimmt der Anbieter,
aber Kundendaten und Zugriffe bleiben Kundenthema.

Beispiel Shared Responsibility bei IaaS

Bei einer virtuellen Maschine in der Cloud:

Anbieter verantwortet typischerweise:

physische Hardware
Rechenzentrum
Strom
Kühlung
Virtualisierungsplattform
Grundinfrastruktur

Kunde verantwortet typischerweise:

Betriebssystem
Patches
Firewall-Regeln
Benutzerkonten
Anwendung
Daten
Backup
Sicherheitskonfiguration

Merksatz:

Cloud-VM ist nicht automatisch sicher gepatcht.

Beispiel Shared Responsibility bei SaaS

Bei einer SaaS-Anwendung:

Anbieter verantwortet typischerweise:

Betrieb der Anwendung
Infrastruktur
Plattform
Updates
technische Verfügbarkeit

Kunde verantwortet typischerweise:

Benutzerverwaltung
Rollen
MFA
Datenklassifizierung
Freigaben
Aufbewahrung
Konfiguration
Schulung

Merksatz:

SaaS nimmt Betrieb ab,
aber nicht die Verantwortung für Zugriffe und Daten.

Virtualisierung in der Cloud

Cloud basiert häufig auf Virtualisierung.

Virtualisierung bedeutet:

physische Hardware wird in mehrere virtuelle Ressourcen aufgeteilt.

Beispiele:

virtuelle Maschinen
virtuelle Netzwerke
virtuelle Festplatten
virtuelle Firewalls
virtuelle Load Balancer

Merksatz:

Virtualisierung ist eine technische Grundlage vieler Cloud-Dienste.

Container in der Cloud

Container sind eine moderne Form der Anwendungsbereitstellung.

Container enthalten:

Anwendung
Abhängigkeiten
Laufzeitumgebung

Sie teilen sich aber den Kernel des Hosts.

Cloud-Dienste können Container bereitstellen, orchestrieren und skalieren.

Merksatz:

Container verpacken Anwendungen portabel und leichtgewichtig.

Orchestrierung

Orchestrierung bedeutet:

automatisierte Verwaltung mehrerer Container oder Dienste.

Aufgaben:

Container starten
Container stoppen
Container verteilen
Skalierung
Updates
Health Checks
Netzwerke
Secrets
Rollbacks

Merksatz:

Orchestrierung verwaltet viele Container automatisch.

Kubernetes

Kubernetes ist eine verbreitete Plattform zur Container-Orchestrierung.

Es verwaltet:

Pods
Services
Deployments
Skalierung
Rollouts
Netzwerke
Konfigurationen
Secrets

Für Prüfungen reicht oft:

Kubernetes orchestriert Container.

Merksatz:

Kubernetes verwaltet Container-Anwendungen in Clustern.

Serverless

Serverless bedeutet nicht, dass keine Server existieren.

Es bedeutet:

Der Kunde verwaltet keine einzelnen Server.

Der Anbieter betreibt die Infrastruktur.

Der Kunde stellt Funktionen oder Code bereit.

Beispiele:

Funktionen bei Ereignissen ausführen
automatische Skalierung
Abrechnung nach Ausführung oder Nutzung

Merksatz:

Serverless heißt:
keine Serververwaltung durch den Kunden.

Function as a Service

Function as a Service wird abgekürzt:

FaaS

Dabei wird eine Funktion ausgeführt, wenn ein Ereignis eintritt.

Beispiele:

Datei wird hochgeladen.
Funktion verarbeitet Datei.
API-Aufruf startet Funktion.
Zeitplan löst Funktion aus.

Merksatz:

FaaS führt einzelne Funktionen ereignisgesteuert aus.

Cloud Storage

Cloud Storage ist Speicherplatz aus der Cloud.

Arten:

Objektspeicher
Blockspeicher
Dateispeicher

Typische Nutzung:

Backups
Dateien
Archivierung
Medien
Logs
Daten für Anwendungen
statische Webseiten

Merksatz:

Cloud Storage stellt Speicher als Dienst bereit.

Objektspeicher

Objektspeicher speichert Daten als Objekte.

Ein Objekt besteht typischerweise aus:

Dateiinhalt
Metadaten
eindeutiger Name oder Schlüssel

Typische Nutzung:

Backups
Bilder
Videos
Dokumente
Archivdaten
Logs

Merksatz:

Objektspeicher ist gut für große Mengen unstrukturierter Daten.

Blockspeicher

Blockspeicher stellt Speicherblöcke bereit, ähnlich wie eine Festplatte für einen Server.

Typische Nutzung:

virtuelle Maschinen
Datenbanken
Betriebssystemplatten
Anwendungen mit Dateisystem

Merksatz:

Blockspeicher verhält sich eher wie eine virtuelle Festplatte.

Dateispeicher

Dateispeicher stellt Dateifreigaben bereit.

Typische Nutzung:

gemeinsame Dateisysteme
Anwendungen mit gemeinsamen Dateien
klassische Freigaben
Benutzerdateien

Merksatz:

Dateispeicher arbeitet mit Ordnern und Dateien.

Cloud-Netzwerke

Cloud-Umgebungen haben eigene Netzwerkstrukturen.

Typische Bestandteile:

virtuelle Netzwerke
Subnetze
Routingtabellen
Security Groups
Network Security Groups
Firewalls
Load Balancer
öffentliche IP-Adressen
private IP-Adressen
NAT-Gateways
VPN-Gateways

Merksatz:

Cloud-Netzwerke müssen genauso geplant werden wie lokale Netzwerke.

Virtuelles Netzwerk

Ein virtuelles Netzwerk ist ein logisch getrenntes Netz in der Cloud.

Es enthält:

Subnetze
virtuelle Maschinen
Dienste
Routing
Sicherheitsregeln

Je nach Anbieter heißt es unterschiedlich, zum Beispiel VPC oder VNet.

Merksatz:

Virtuelles Netzwerk ist das Cloud-Gegenstück zum eigenen Netzsegment.

Subnetze in der Cloud

Cloud-Netze werden in Subnetze aufgeteilt.

Beispiele:

Web-Subnetz
App-Subnetz
Datenbank-Subnetz
Management-Subnetz
Public Subnet
Private Subnet

Merksatz:

Subnetze trennen Cloud-Ressourcen logisch.

Public Subnet

Ein Public Subnet enthält Ressourcen, die direkt oder indirekt mit dem Internet verbunden sein können.

Beispiele:

Load Balancer
Bastion Host
öffentlich erreichbarer Webserver

Wichtig:

Nicht jede Ressource sollte öffentlich erreichbar sein.

Merksatz:

Public Subnet nur für wirklich öffentliche Komponenten nutzen.

Private Subnet

Ein Private Subnet enthält interne Ressourcen.

Beispiele:

Datenbankserver
interne Anwendung
Backend
interne APIs
Verarbeitungssysteme

Diese Ressourcen sind normalerweise nicht direkt aus dem Internet erreichbar.

Merksatz:

Private Subnet schützt interne Cloud-Ressourcen vor direktem Internetzugriff.

Security Group

Eine Security Group ist eine virtuelle Firewall-Regelgruppe für Cloud-Ressourcen.

Sie steuert häufig:

eingehenden Verkehr
ausgehenden Verkehr
Ports
Protokolle
Quellen
Ziele

Merksatz:

Security Group ist eine Firewall-Regelgruppe in der Cloud.

Network Security Group

Network Security Group wird oft abgekürzt:

NSG

Sie steuert Netzwerkverkehr auf Subnetz- oder Ressourceneebene, je nach Cloud-Plattform.

Merksatz:

NSG regelt Netzwerkzugriffe in Cloud-Netzen.

Cloud-Firewall

Eine Cloud-Firewall schützt Cloud-Netze oder Cloud-Dienste.

Sie kann filtern nach:

IP-Adresse
Port
Protokoll
Richtung
Anwendung
Bedrohungssignatur
Zone

Merksatz:

Auch in der Cloud braucht man Firewall-Regeln.

Load Balancer

Ein Load Balancer verteilt Anfragen auf mehrere Ziele.

Ziele können sein:

virtuelle Maschinen
Container
Anwendungen
Backends

Vorteile:

höhere Verfügbarkeit
Lastverteilung
Wartung einzelner Systeme möglich
Skalierung

Merksatz:

Load Balancer verteilt Last auf mehrere Systeme.

Auto Scaling

Auto Scaling bedeutet:

Ressourcen werden automatisch erhöht oder reduziert.

Beispiel:

Bei hoher Last werden mehr Instanzen gestartet.
Bei geringer Last werden Instanzen beendet.

Vorteile:

bessere Anpassung an Last
Kostenkontrolle
höhere Verfügbarkeit

Merksatz:

Auto Scaling passt Ressourcen automatisch an Bedarf an.

Cloud und Hochverfügbarkeit

Cloud kann Hochverfügbarkeit unterstützen.

Möglichkeiten:

mehrere Verfügbarkeitszonen
mehrere Regionen
Load Balancer
Auto Scaling
replizierte Daten
Backup
Monitoring
automatische Wiederherstellung

Aber:

Hochverfügbarkeit muss geplant und konfiguriert werden.

Merksatz:

Cloud ist nicht automatisch hochverfügbar.

Verfügbarkeitszone

Eine Verfügbarkeitszone ist ein getrenntes Rechenzentrumssegment innerhalb einer Region.

Ziel:

Ausfall einer Zone soll nicht automatisch alle Dienste betreffen.

Beispiele:

Zone A
Zone B
Zone C

Merksatz:

Verfügbarkeitszonen helfen,
Ausfälle innerhalb einer Region abzufangen.

Region

Eine Region ist ein geografischer Standort eines Cloud-Anbieters.

Beispiele:

Deutschland
Europa
USA
Asien

Regionen sind wichtig für:

Latenz
Datenschutz
Ausfallsicherheit
Kosten
Compliance
Datenstandort

Merksatz:

Region bestimmt,
wo Cloud-Ressourcen geografisch betrieben werden.

Datenstandort

Datenstandort bedeutet:

In welchem Land oder welcher Region Daten gespeichert und verarbeitet werden.

Wichtig wegen:

Datenschutz
rechtlichen Anforderungen
Compliance
Latenz
Kundenanforderungen
Unternehmensrichtlinien

Merksatz:

Datenstandort ist bei Cloud-Diensten sicherheits- und rechtsrelevant.

Cloud-Kosten

Cloud-Kosten entstehen häufig durch:

Rechenleistung
Speicher
Datenübertragung
Datenbanknutzung
Lizenzen
Load Balancer
Backups
Logs
Monitoring
öffentliche IP-Adressen
Support

Wichtig:

Cloud ist flexibel,
aber nicht automatisch günstiger.

Merksatz:

Cloud-Kosten müssen überwacht und geplant werden.

OPEX und CAPEX

CAPEX bedeutet:

Investitionsausgaben

Beispiel:

Server kaufen
Storage kaufen
Netzwerkhardware kaufen

OPEX bedeutet:

Betriebsausgaben

Beispiel:

monatliche Cloud-Nutzung
Mietmodell
nutzungsabhängige Abrechnung

Cloud verschiebt Kosten häufig von CAPEX zu OPEX.

Merksatz:

Cloud macht aus Kaufkosten häufig laufende Nutzungskosten.

Pay as you go

Pay as you go bedeutet:

Man bezahlt nach Nutzung.

Beispiele:

pro Stunde
pro GB
pro Anfrage
pro Benutzer
pro Ausführung
pro übertragenem Datenvolumen

Vorteil:

flexible Abrechnung

Risiko:

unerwartete Kosten bei Fehlkonfiguration oder hoher Nutzung

Merksatz:

Pay as you go ist flexibel,
braucht aber Kostenkontrolle.

Cloud-Sicherheit

Cloud-Sicherheit umfasst:

Identitätsmanagement
MFA
Rollen und Rechte
Netzwerksicherheit
Verschlüsselung
Logging
Monitoring
Backup
Patchmanagement
sichere Konfiguration
Datenklassifizierung
Compliance

Merksatz:

Cloud-Sicherheit ist mehr als Anbieter auswählen.

Identity and Access Management

Identity and Access Management wird oft abgekürzt:

IAM

IAM regelt:

Benutzer
Gruppen
Rollen
Berechtigungen
Servicekonten
API-Schlüssel
MFA
Zugriff auf Ressourcen

Merksatz:

IAM entscheidet,
wer was in der Cloud darf.

Cloud-Rollen

Cloud-Zugriffe sollten über Rollen gesteuert werden.

Beispiele:

Leser
Administrator
Netzwerkadministrator
Sicherheitsadministrator
Datenbankadministrator
Entwickler
Abrechnungszugriff

Merksatz:

Rollen helfen,
Cloud-Rechte nach Aufgabe zu vergeben.

Least Privilege in der Cloud

Auch in der Cloud gilt:

so wenig Rechte wie möglich,
so viele wie nötig.

Nicht gut:

alle Benutzer sind Administratoren
API-Schlüssel mit Vollzugriff
öffentliche Speichercontainer
Datenbank öffentlich erreichbar
Managementport offen im Internet

Merksatz:

Least Privilege ist in der Cloud besonders wichtig.

Cloud-Fehlkonfigurationen

Viele Cloud-Sicherheitsvorfälle entstehen durch Fehlkonfigurationen.

Beispiele:

Speicher öffentlich lesbar
Datenbank öffentlich erreichbar
zu breite Security Group
Adminrechte für zu viele Benutzer
fehlende MFA
offene Managementports
unverschlüsselte Daten
keine Logs
keine Kostenlimits

Merksatz:

Cloud-Fehler entstehen häufig durch falsche Konfiguration,
nicht durch defekte Technik.

Cloud-Logging

Cloud-Logs zeigen:

Anmeldungen
API-Aufrufe
Änderungen an Ressourcen
Netzwerkzugriffe
Firewall-Entscheidungen
Fehlermeldungen
Sicherheitsereignisse
Abrechnungsereignisse

Wichtig:

Logs aktivieren
Logs schützen
Logs zentral auswerten
Aufbewahrung regeln

Merksatz:

Cloud-Logs zeigen,
wer was wann geändert hat.

Cloud-Monitoring

Cloud-Monitoring überwacht:

Verfügbarkeit
CPU
RAM
Speicher
Datenbanklast
Netzwerkverkehr
Fehlerquoten
Antwortzeiten
Kosten
Zertifikate
Sicherheitsereignisse

Merksatz:

Cloud-Monitoring ist für Betrieb,
Sicherheit
und Kostenkontrolle wichtig.

Backup in der Cloud

Cloud-Dienste brauchen Backup-Konzepte.

Wichtig:

Was wird gesichert?
Wie oft?
Wie lange?
Wo wird gespeichert?
Wer darf wiederherstellen?
Wurde Wiederherstellung getestet?
Ist Backup vor Löschung oder Ransomware geschützt?

Merksatz:

Cloud ersetzt nicht automatisch Backup.

Cloud und Datenschutz

Bei Cloud-Diensten müssen Datenschutzanforderungen beachtet werden.

Wichtige Fragen:

Welche Daten werden verarbeitet?
Wo werden Daten gespeichert?
Wer hat Zugriff?
Gibt es Auftragsverarbeitung?
Sind Daten verschlüsselt?
Gibt es Löschkonzepte?
Werden Logs personenbezogen?
Welche Anbieterbedingungen gelten?

Merksatz:

Cloud-Nutzung braucht Datenschutzprüfung.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Was bedeutet Cloud Computing?
- Was ist der Unterschied zwischen On-Premises und Cloud?
- Was ist Public Cloud?
- Was ist Private Cloud?
- Was ist Hybrid Cloud?
- Was ist Multi Cloud?
- Was bedeutet IaaS?
- Was bedeutet PaaS?
- Was bedeutet SaaS?
- Was ist das Shared Responsibility Model?
- Wer ist bei einer Cloud-VM für Betriebssystemupdates verantwortlich?
- Was ist Serverless?
- Was ist Auto Scaling?
- Was ist ein Load Balancer?
- Warum ist IAM in der Cloud wichtig?
- Warum ist Cloud nicht automatisch sicher?
- Warum ist Cloud nicht automatisch günstiger?
- Warum braucht Cloud Backup und Monitoring?

Typische Prüfungsfallen

Cloud bedeutet nicht automatisch Internetseite.

Cloud bedeutet nicht automatisch weniger Verantwortung.

On-Premises ist lokal selbst betrieben.

Public Cloud ist Anbieterplattform für viele Kunden.

Private Cloud ist Cloud-Prinzip für eine Organisation.

Hybrid Cloud kombiniert lokal und Cloud.

Multi Cloud nutzt mehrere Anbieter.

IaaS ist virtuelle Infrastruktur.

PaaS ist Plattform für Anwendungen.

SaaS ist fertige Software.

Shared Responsibility bedeutet geteilte Verantwortung.

Cloud-VM muss der Kunde oft selbst patchen.

SaaS-Benutzerrechte bleiben Kundenthema.

Serverless heißt nicht serverfrei.

Cloud ist nicht automatisch hochverfügbar.

Cloud ist nicht automatisch günstiger.

Pay as you go braucht Kostenkontrolle.

IAM ist zentral für Cloud-Sicherheit.

Öffentliche Speicherfreigaben sind gefährlich.

Cloud braucht Backup,
Logs
und Monitoring.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
Cloud IT-Ressourcen als Dienst
On-Premises lokal selbst betrieben
Public Cloud öffentliche Anbieterplattform
Private Cloud Cloud für eine Organisation
Hybrid Cloud Mischung aus lokal und Cloud
Multi Cloud mehrere Cloud-Anbieter
Community Cloud Cloud für bestimmte Gruppe
IaaS Infrastructure as a Service
PaaS Platform as a Service
SaaS Software as a Service
Shared Responsibility geteilte Verantwortung
Virtualisierung Aufteilen physischer Ressourcen
Container portable Anwendungseinheit
Orchestrierung automatische Verwaltung vieler Dienste
Kubernetes Container-Orchestrierung
Serverless keine Serververwaltung durch Kunden
FaaS Function as a Service
Cloud Storage Speicher aus der Cloud
Objektspeicher Speicher für Objekte mit Metadaten
Blockspeicher virtuelle Festplatte
Dateispeicher Dateifreigabe als Dienst
VPC / VNet virtuelles Cloud-Netz
Public Subnet öffentlich angebundenes Subnetz
Private Subnet internes Cloud-Subnetz
Security Group virtuelle Firewall-Regelgruppe
Load Balancer verteilt Anfragen
Auto Scaling automatische Skalierung
Region geografischer Cloud-Standort
Verfügbarkeitszone getrennte Zone innerhalb Region
IAM Identitäts- und Rechteverwaltung
CAPEX Investitionsausgaben
OPEX Betriebsausgaben

IHK-sichere Kurzformulierung

Cloud Computing bedeutet, dass IT-Ressourcen wie Rechenleistung, Speicher, Datenbanken, Plattformen oder Anwendungen über ein Netzwerk als Dienst bereitgestellt werden. Bei On-Premises betreibt ein Unternehmen seine IT lokal selbst, während Public Cloud von einem Anbieter für viele Kunden bereitgestellt wird. Private Cloud nutzt Cloud-Prinzipien für eine Organisation, Hybrid Cloud kombiniert lokale IT und Cloud, und Multi Cloud nutzt mehrere Anbieter. Die wichtigsten Service-Modelle sind IaaS, PaaS und SaaS. Beim Shared Responsibility Model teilen sich Anbieter und Kunde die Verantwortung. Der Anbieter betreibt je nach Modell Teile der Infrastruktur, der Kunde bleibt aber für Benutzer, Daten, Berechtigungen, sichere Konfiguration, Backup, Monitoring und Compliance verantwortlich.


Merksätze

Cloud = IT-Ressourcen als Dienst.

On-Premises = lokal selbst betrieben.

Public Cloud = Anbieterplattform für viele Kunden.

Private Cloud = Cloud für eine Organisation.

Hybrid Cloud = lokal plus Cloud.

Multi Cloud = mehrere Anbieter.

IaaS = virtuelle Infrastruktur.

PaaS = Plattform für Anwendungen.

SaaS = fertige Software.

Shared Responsibility = geteilte Verantwortung.

Je fertiger der Dienst,
desto mehr Betrieb übernimmt der Anbieter.

Kundendaten und Zugriffe bleiben Kundenthema.

Cloud-VM ist nicht automatisch gepatcht.

SaaS braucht Benutzer- und Rechteverwaltung.

Virtualisierung ist Grundlage vieler Cloud-Dienste.

Container verpacken Anwendungen.

Kubernetes orchestriert Container.

Serverless heißt nicht serverfrei.

FaaS führt Funktionen ereignisgesteuert aus.

Cloud Storage kann Objekt,
Block
oder Datei sein.

Cloud-Netze müssen geplant werden.

Security Groups sind virtuelle Firewall-Regeln.

Load Balancer verteilt Last.

Auto Scaling passt Ressourcen automatisch an.

Cloud ist nicht automatisch hochverfügbar.

Region bestimmt Datenstandort.

Cloud ist nicht automatisch günstiger.

Pay as you go braucht Kostenkontrolle.

IAM ist zentral für Cloud-Sicherheit.

Least Privilege gilt auch in der Cloud.

Cloud-Fehlkonfigurationen sind häufige Risiken.

Cloud braucht Logs,
Monitoring,
Backup
und Datenschutzprüfung.

15.2 IaaS, PaaS und SaaS im Detail

IaaS, PaaS und SaaS sind die wichtigsten Cloud-Service-Modelle.

Sie beschreiben, welche Teile der IT vom Anbieter bereitgestellt werden und welche Teile der Kunde selbst verwaltet.

Die drei Begriffe stehen für:

IaaS:
Infrastructure as a Service

PaaS:
Platform as a Service

SaaS:
Software as a Service

Merksatz:

IaaS,
PaaS
und SaaS unterscheiden sich vor allem durch die Verantwortungsverteilung.

Warum sind Service-Modelle wichtig?

In Prüfungen und in der Praxis muss man erkennen können:

Was betreibt der Anbieter?

Was betreibt der Kunde?

Wer ist für Updates verantwortlich?

Wer kümmert sich um Benutzer?

Wer sichert Daten?

Wer konfiguriert die Anwendung?

Wer schützt Zugänge?

Das ist wichtig, weil Cloud nicht bedeutet, dass der Anbieter automatisch alles übernimmt.

Merksatz:

Cloud-Nutzung heißt nicht:
keine eigene Verantwortung mehr.

Grundidee der drei Modelle

Vereinfacht:

IaaS:
Der Anbieter liefert die technische Infrastruktur.

PaaS:
Der Anbieter liefert zusätzlich die Plattform für Anwendungen.

SaaS:
Der Anbieter liefert die fertige Anwendung.

Je weiter man von IaaS zu SaaS geht, desto mehr übernimmt der Anbieter.

Merksatz:

IaaS = viel Kontrolle.
SaaS = viel fertiger Dienst.
PaaS = dazwischen.

Vergleich in Kurzform

Modell Kunde bekommt Kunde verwaltet vor allem
IaaS virtuelle Infrastruktur Betriebssystem, Anwendung, Daten
PaaS Plattform für Anwendungen Anwendung, Daten, Konfiguration
SaaS fertige Anwendung Benutzer, Rechte, Daten, Einstellungen

Merksatz:

Je fertiger der Dienst,
desto weniger technische Basis verwaltet der Kunde selbst.

IaaS im Detail

IaaS bedeutet:

Infrastructure as a Service

Der Anbieter stellt grundlegende Infrastruktur bereit.

Dazu gehören zum Beispiel:

- virtuelle Maschinen
- virtuelle Netzwerke
- virtuelle Festplatten
- Firewalls
- Load Balancer
- öffentliche IP-Adressen
- private IP-Adressen
- Snapshots
- Storage
- Routingtabellen

Der Kunde baut darauf seine Systeme auf.

Merksatz:

IaaS ist wie ein gemieteter virtueller Serverraum.

Typische IaaS-Beispiele

Typische IaaS-Ressourcen:

virtuelle Server
virtuelle Router
virtuelle Firewalls
virtuelle Netzwerke
Block Storage
Object Storage
Load Balancer
VPN-Gateway
Backup-Speicher

Typische Nutzung:

eigene Anwendungen betreiben
eigene Server migrieren
Testumgebungen aufbauen
Entwicklungsumgebungen bereitstellen
Disaster Recovery vorbereiten

Merksatz:

IaaS eignet sich,
wenn man viel Kontrolle über Server und Netzwerk braucht.

Was übernimmt der Anbieter bei IaaS?

Der Anbieter übernimmt typischerweise:

Rechenzentrum
physische Server
Stromversorgung
Kühlung
physische Netzwerkanbindung
Hardwarewartung
Virtualisierungsplattform
Grundverfügbarkeit der Infrastruktur

Der Kunde muss sich nicht selbst um physische Hardware kümmern.

Merksatz:

Bei IaaS übernimmt der Anbieter vor allem die physische und virtuelle Basis.

Was übernimmt der Kunde bei IaaS?

Der Kunde übernimmt typischerweise:

Betriebssysteminstallation
Betriebssystemupdates
Benutzerkonten
Firewall-Konfiguration
Anwendungsinstallation
Anwendungskonfiguration
Daten
Backups
Monitoring
Sicherheitskonfiguration
Patches innerhalb der VM

Merksatz:

Eine Cloud-VM muss der Kunde meistens selbst administrieren.

IaaS-Vorteile

Vorteile:

hohe Kontrolle
flexible Servergrößen
schnelle Bereitstellung
keine eigene Hardwarebeschaffung
gut für Migration vorhandener Server
gut für individuelle Anwendungen
skalierbare Infrastruktur
netzwerktechnisch flexibel

Merksatz:

IaaS bietet viel Flexibilität und Kontrolle.

IaaS-Nachteile

Nachteile:

Kunde muss viel selbst verwalten
Betriebssystempflege bleibt notwendig
Sicherheitskonfiguration bleibt Kundenthema
Fehlkonfigurationen möglich
Kosten können steigen
Monitoring und Backup müssen geplant werden
Know-how für Betrieb nötig

Merksatz:

IaaS nimmt Hardware ab,
aber nicht den Serverbetrieb.

IaaS-Prüfungsbeispiel

Aufgabe:

Ein Unternehmen betreibt eine virtuelle Linux-VM in der Cloud.
Darauf läuft eine eigene Webanwendung.

Frage:

Wer ist für Betriebssystemupdates verantwortlich?

Antwort:

In der Regel der Kunde.

Warum?

Der Anbieter stellt die Infrastruktur.
Der Kunde betreibt Betriebssystem und Anwendung.

Merksatz:

Cloud-VM heißt nicht:
Anbieter patcht automatisch das Betriebssystem.

PaaS im Detail

PaaS bedeutet:

Platform as a Service

Der Anbieter stellt eine Plattform bereit, auf der Anwendungen betrieben werden können.

Der Kunde muss sich nicht direkt um die darunterliegende Infrastruktur kümmern.

Typische Bestandteile:

Laufzeitumgebung
Web-App-Plattform
verwaltete Datenbank
Middleware
Build- und Deployment-Funktionen
Skalierungsfunktionen
Monitoring-Grundfunktionen

Merksatz:

PaaS ist eine fertige Plattform für eigene Anwendungen.

Typische PaaS-Beispiele

Typische PaaS-Angebote:

verwaltete Datenbank
Web-App-Service
App-Plattform
Containerplattform als Dienst
Entwicklungsplattform
API-Plattform
Message Queue als Dienst
Cache-Dienst
Laufzeitumgebung für Code

Typische Nutzung:

eigene Anwendung bereitstellen,
ohne Serverbetrieb im Detail zu übernehmen.

Merksatz:

PaaS ist gut,
wenn man Anwendung betreiben will,
aber weniger Serververwaltung möchte.

Was übernimmt der Anbieter bei PaaS?

Der Anbieter übernimmt typischerweise:

physische Infrastruktur
Virtualisierung
Betriebssystembasis
Laufzeitumgebung
Plattformupdates
Skalierungsmechanismen
Teile des Monitorings
Hochverfügbarkeitsfunktionen je nach Dienst

Merksatz:

Bei PaaS übernimmt der Anbieter mehr als bei IaaS.

Was übernimmt der Kunde bei PaaS?

Der Kunde übernimmt typischerweise:

Anwendungscode
Anwendungskonfiguration
Daten
Benutzer und Rollen
Zugriffsschlüssel
API-Konfiguration
sichere Einstellungen
fachliche Backups je nach Dienst
Berechtigungen
Datenschutz und Compliance

Merksatz:

Bei PaaS bleibt die Anwendung Kundenthema.

PaaS-Vorteile

Vorteile:

weniger Serveradministration
schnellere Entwicklung
einfachere Skalierung
integrierte Plattformfunktionen
weniger Betriebssystempflege
oft automatische Updates der Plattform
gut für moderne Anwendungen
häufig gute Integration in DevOps-Prozesse

Merksatz:

PaaS entlastet vom Betrieb der technischen Basis.

PaaS-Nachteile

Nachteile:

weniger Kontrolle über darunterliegende Systeme
Abhängigkeit von Plattformfunktionen
mögliche Anbieterbindung
Einschränkungen bei Spezialkonfigurationen
Kostenmodell muss verstanden werden
Fehlkonfigurationen weiterhin möglich

Merksatz:

PaaS nimmt Arbeit ab,
kann aber stärker an den Anbieter binden.

PaaS-Prüfungsbeispiel

Aufgabe:

Ein Unternehmen nutzt eine verwaltete Datenbank in der Cloud.

Frage:

Muss das Unternehmen den Datenbankserver selbst installieren?

Antwort:

Nein.

Aber das Unternehmen bleibt verantwortlich für:

Daten
Benutzerrechte
Zugriffskonfiguration
Backup-Einstellungen je nach Dienst
sichere Konfiguration

Merksatz:

Verwaltete Datenbank bedeutet nicht:
keine Datenverantwortung.

SaaS im Detail

SaaS bedeutet:

Software as a Service

Der Kunde nutzt eine fertige Anwendung, die vom Anbieter betrieben wird.

Typische Beispiele:

E-Mail
Online-Office
CRM
Ticketsystem
Videokonferenzdienst
Projektmanagement
Cloud-Speicher
Buchhaltungssystem
Lernplattform

Merksatz:

SaaS ist fertige Software aus der Cloud.

Was übernimmt der Anbieter bei SaaS?

Der Anbieter übernimmt typischerweise:

Anwendung
Plattform
Infrastruktur
Updates
Wartung
Grundverfügbarkeit
technische Skalierung
technische Sicherheitsmaßnahmen
Betrieb der Datenbank
Betrieb der Server

Merksatz:

Bei SaaS übernimmt der Anbieter den größten Teil des technischen Betriebs.

Was übernimmt der Kunde bei SaaS?

Der Kunde übernimmt typischerweise:

Benutzerkonten
Rollen
Berechtigungen
MFA-Einstellungen
Datenklassifizierung
Freigaben
Aufbewahrungsrichtlinien
Löschkonzepte
Schulung der Benutzer
sichere Konfiguration
Vertrags- und Datenschutzprüfung

Merksatz:

SaaS nimmt Betrieb ab,
aber nicht Benutzer-,
Rechte-
und Datenverantwortung.

SaaS-Vorteile

Vorteile:

schnell nutzbar
keine eigene Serverinstallation
automatische Updates durch Anbieter
ortsunabhängiger Zugriff
einfache Skalierung nach Benutzern
oft geringe Einstiegshürde
gute Zusammenarbeit
weniger technischer Betrieb

Merksatz:

SaaS ist schnell einsatzbereit und reduziert Betriebsaufwand.

SaaS-Nachteile

Nachteile:

weniger technische Kontrolle
Abhängigkeit vom Anbieter
Datenstandort prüfen
Datenschutz prüfen
Lizenzkosten beachten
Internetabhängigkeit
eingeschränkte Anpassbarkeit
falsche Freigaben können Daten offenlegen

Merksatz:

SaaS ist bequem,
braucht aber sorgfältige Rechte- und Datenschutzkontrolle.

SaaS-Prüfungsbeispiel

Aufgabe:

Ein Unternehmen nutzt einen Cloud-E-Mail-Dienst.

Frage:

Wer ist für Benutzerrechte,
MFA
und Postfachfreigaben verantwortlich?

Antwort:

Der Kunde.

Der Anbieter betreibt den Dienst, aber der Kunde verwaltet Zugriffe und Einstellungen.

Merksatz:

SaaS-Anbieter betreibt die Software,
der Kunde verwaltet Nutzung und Zugriff.

Verantwortungsschichten

Man kann IT grob in Schichten betrachten:

Daten
Anwendung
Laufzeitumgebung
Middleware
Betriebssystem
Virtualisierung
Server
Speicher
Netzwerk
Rechenzentrum

Je nach Service-Modell verschiebt sich Verantwortung.

Merksatz:

Service-Modelle verschieben Verantwortung zwischen Anbieter und Kunde.

Verantwortung grob vergleichen

Schicht IaaS PaaS SaaS
Daten Kunde Kunde Kunde
Benutzer und Rechte Kunde Kunde Kunde
Anwendung Kunde Kunde Anbieter
Laufzeitumgebung Kunde Anbieter Anbieter
Betriebssystem Kunde Anbieter Anbieter
Virtualisierung Anbieter Anbieter Anbieter
Physische Server Anbieter Anbieter Anbieter
Rechenzentrum Anbieter Anbieter Anbieter

Merksatz:

Daten,
Benutzer
und Rechte bleiben fast immer Kundenthema.

Shared Responsibility Model

Das Shared Responsibility Model beschreibt, wie sich Anbieter und Kunde Verantwortung teilen.

Wichtig:

Es gibt keine pauschale Antwort für alle Dienste.

Die genaue Verantwortung hängt ab von:

Service-Modell
Anbieter
Vertrag
Dienstkonfiguration
Sicherheitsoptionen
Unternehmensrichtlinien

Merksatz:

Shared Responsibility immer konkret für den genutzten Dienst prüfen.

Typischer Denkfehler

Falsch:

Das ist Cloud,
also kümmert sich der Anbieter um Sicherheit.

Richtig:

Der Anbieter kümmert sich je nach Modell um Teile der Sicherheit.
Der Kunde bleibt für sichere Nutzung,
Konfiguration,
Daten,
Identitäten
und Berechtigungen verantwortlich.

Merksatz:

Cloud-Sicherheit ist gemeinsame Verantwortung.

Beispiel: Unsichere IaaS-Konfiguration

Ein Unternehmen betreibt eine VM in der Cloud.

Fehler:

SSH offen für das gesamte Internet
schwaches Passwort
keine Updates
keine Host-Firewall
keine Backups
keine Logs

Obwohl die Cloud-Infrastruktur sicher betrieben wird, ist die VM unsicher konfiguriert.

Merksatz:

IaaS-Fehlkonfigurationen liegen oft beim Kunden.

Beispiel: Unsichere PaaS-Konfiguration

Ein Unternehmen nutzt eine verwaltete Datenbank.

Fehler:

Datenbank öffentlich erreichbar
zu breite IP-Freigabe
schwache Zugangsdaten
keine Verschlüsselung erzwungen
keine Backups aktiviert
Adminzugang für zu viele Benutzer

Merksatz:

PaaS muss sicher konfiguriert werden.

Beispiel: Unsichere SaaS-Konfiguration

Ein Unternehmen nutzt Cloud-Speicher.

Fehler:

Ordner öffentlich freigegeben
Gastzugriff zu breit erlaubt
MFA nicht aktiviert
alte Benutzerkonten aktiv
externe Freigaben nicht geprüft
keine Aufbewahrungsrichtlinien

Merksatz:

SaaS-Fehler entstehen oft durch falsche Freigaben und Rechte.

Lift and Shift

Lift and Shift bedeutet:

bestehende Server oder Anwendungen werden möglichst unverändert in die Cloud verschoben.

Beispiel:

lokaler Windows-Server
wird als Cloud-VM betrieben.

Vorteil:

schnelle Migration

Nachteil:

Cloud-Vorteile wie PaaS,
Skalierung
und Automatisierung werden oft nur teilweise genutzt.

Merksatz:

Lift and Shift verschiebt Systeme,
modernisiert sie aber nicht automatisch.

Cloud-native

Cloud-native bedeutet:

Anwendungen werden speziell für Cloud-Umgebungen entwickelt oder angepasst.

Typische Merkmale:

Skalierbarkeit
Automatisierung
Container
Microservices
API-orientierte Architektur
Monitoring
schnelle Bereitstellung
Resilienz

Merksatz:

Cloud-native nutzt Cloud-Prinzipien bewusst aus.

Managed Service

Ein Managed Service ist ein Dienst, bei dem der Anbieter Betrieb und Wartung teilweise übernimmt.

Beispiele:

verwaltete Datenbank
verwalteter Kubernetes-Cluster
verwalteter Cache
verwaltete Firewall
verwaltetes Backup

Merksatz:

Managed Service reduziert Betriebsaufwand,
aber nicht automatisch Kundenverantwortung.

Self-Managed

Self-Managed bedeutet:

Der Kunde betreibt und verwaltet einen Dienst selbst.

Beispiel:

Datenbank selbst auf einer Cloud-VM installieren.

Der Kunde ist dann verantwortlich für:

Installation
Updates
Backup
Sicherheit
Monitoring
Skalierung
Wiederherstellung

Merksatz:

Self-Managed gibt Kontrolle,
aber auch Betriebsverantwortung.

Managed und Self-Managed vergleichen

Merkmal Managed Service Self-Managed
Betrieb Anbieter übernimmt mehr Kunde übernimmt mehr
Kontrolle etwas geringer höher
Wartung geringer für Kunden höher
Flexibilität abhängig vom Dienst oft höher
Verantwortung geteilt stärker beim Kunden
Beispiel Cloud-Datenbank Datenbank auf eigener VM

Merksatz:

Managed spart Betrieb.
Self-Managed gibt Kontrolle.

As-a-Service-Prinzip

As a Service bedeutet:

Eine IT-Funktion wird als Dienst bereitgestellt.

Neben IaaS, PaaS und SaaS gibt es weitere Begriffe.

Beispiele:

Backup as a Service
Database as a Service
Desktop as a Service
Security as a Service
Function as a Service
Network as a Service

Merksatz:

As a Service bedeutet:
Nutzung als Dienst statt vollständig eigener Betrieb.

DaaS

DaaS kann je nach Kontext bedeuten:

Desktop as a Service

oder:

Database as a Service

In Prüfungen muss man auf den Kontext achten.

Desktop as a Service:

virtuelle Desktops aus der Cloud

Database as a Service:

verwaltete Datenbank als Cloud-Dienst

Merksatz:

DaaS immer im Kontext lesen.

FaaS

FaaS steht für:

Function as a Service

Dabei werden einzelne Funktionen ausgeführt, wenn ein Ereignis eintritt.

Beispiel:

Datei wird hochgeladen.
Funktion startet automatisch.
Datei wird verarbeitet.

FaaS gehört oft zum Serverless-Bereich.

Merksatz:

FaaS führt Code ereignisgesteuert aus.

BaaS

BaaS kann bedeuten:

Backup as a Service

oder:

Backend as a Service

Backup as a Service:

Backups werden als Cloud-Dienst bereitgestellt.

Backend as a Service:

Backend-Funktionen für Anwendungen werden bereitgestellt,
zum Beispiel Authentifizierung,
Datenbank
oder Push-Benachrichtigungen.

Merksatz:

BaaS ebenfalls immer im Kontext verstehen.

XaaS

XaaS steht für:

Anything as a Service

oder:

Everything as a Service

Es ist ein Sammelbegriff für viele Dienste, die als Cloud-Service bereitgestellt werden.

Merksatz:

XaaS ist ein Oberbegriff für Dienste aus der Cloud.

Typische Einordnung von Beispielen

Beispiel Service-Modell
virtuelle Maschine IaaS
virtueller Datenträger IaaS
virtuelles Netzwerk IaaS
verwaltete Datenbank PaaS
Web-App-Plattform PaaS
Containerplattform als Dienst PaaS
fertiges E-Mail-System SaaS
Online-Office SaaS
CRM aus der Cloud SaaS
Ticketsystem aus der Cloud SaaS
einzelne Funktion bei Ereignis FaaS / Serverless

Merksatz:

Frage immer:
Nutze ich Infrastruktur,
Plattform
oder fertige Software?

Entscheidungshilfe

Ziel passendes Modell
maximale Kontrolle über Server IaaS
eigene Anwendung ohne Serverbetrieb PaaS
fertige Anwendung schnell nutzen SaaS
Ereignisgesteuerte kleine Funktionen FaaS
klassische Servermigration IaaS / Lift and Shift
moderne skalierbare Anwendung PaaS / Container / Serverless

Merksatz:

Das Modell richtet sich nach Kontrolle,
Aufwand
und Anwendungszweck.

Kostenunterschiede

IaaS, PaaS und SaaS haben unterschiedliche Kostenmodelle.

IaaS:

VM-Laufzeit
Speicher
Netzwerkverkehr
Backups

PaaS:

Dienstgröße
Nutzung
Datenbankleistung
Anfragen
Speicher

SaaS:

Benutzerlizenzen
Funktionspakete
Speicher
Zusatzmodule

Merksatz:

Cloud-Kosten entstehen je nach Service-Modell unterschiedlich.

Sicherheitsunterschiede

IaaS:

Kunde muss Server stark selbst absichern.

PaaS:

Kunde muss Anwendung,
Daten
und Zugriff absichern.

SaaS:

Kunde muss Benutzer,
Rollen,
Freigaben
und Daten absichern.

Merksatz:

Sicherheit verlagert sich,
verschwindet aber nicht.

Betriebsunterschiede

IaaS:

viel Betrieb beim Kunden

PaaS:

mittlerer Betrieb beim Kunden

SaaS:

wenig technischer Betrieb beim Kunden

Aber:

Fachliche Administration bleibt bei allen Modellen wichtig.

Merksatz:

Weniger technischer Betrieb heißt nicht keine Administration.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Was bedeutet IaaS?
- Was bedeutet PaaS?
- Was bedeutet SaaS?
- Worin unterscheiden sich IaaS, PaaS und SaaS?
- Wer ist bei IaaS für Betriebssystemupdates verantwortlich?
- Wer verwaltet bei SaaS Benutzer und Rechte?
- Was bedeutet Shared Responsibility?
- Warum ist eine Cloud-VM nicht automatisch sicher?
- Was ist ein Managed Service?
- Was ist Self-Managed?
- Was bedeutet Lift and Shift?
- Was bedeutet Cloud-native?
- Was ist FaaS?
- Warum ist Hashing oder Verschlüsselung allein kein Ersatz für Rechteverwaltung?
- Warum bleibt der Kunde auch bei SaaS für Daten verantwortlich?

Typische Prüfungsfallen

IaaS ist nicht fertige Software.

SaaS ist nicht eigener Server.

PaaS liegt zwischen IaaS und SaaS.

Cloud-VMs muss der Kunde oft selbst patchen.

Verwaltete Datenbank heißt nicht:
Daten sind automatisch korrekt geschützt.

SaaS heißt nicht:
alle Benutzerrechte sind automatisch sicher.

Shared Responsibility gilt immer konkret je Dienst.

Daten bleiben Kundenthema.

Benutzer und Rechte bleiben Kundenthema.

Backup muss geprüft werden.

Cloud ist nicht automatisch sicher.

Cloud ist nicht automatisch günstiger.

Managed Service reduziert Betrieb,
aber nicht Verantwortung.

Lift and Shift modernisiert nicht automatisch.

Serverless heißt nicht,
dass keine Server existieren.

FaaS führt Funktionen ereignisgesteuert aus.

DaaS und BaaS im Kontext lesen.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
IaaS Infrastructure as a Service
PaaS Platform as a Service
SaaS Software as a Service
Shared Responsibility geteilte Verantwortung zwischen Anbieter und Kunde
Cloud-VM virtuelle Maschine in der Cloud
Managed Service Anbieter übernimmt Teile des Betriebs
Self-Managed Kunde betreibt Dienst selbst
Lift and Shift bestehendes System in Cloud verschieben
Cloud-native speziell für Cloud-Prinzipien entwickelt
FaaS Function as a Service
DaaS je nach Kontext Desktop oder Database as a Service
BaaS je nach Kontext Backup oder Backend as a Service
XaaS Sammelbegriff für Dienste als Service
Plattform Umgebung zum Ausführen von Anwendungen
Runtime Laufzeitumgebung für Anwendungscode
Middleware Software zwischen Betriebssystem und Anwendung
Service-Modell beschreibt Verantwortungsverteilung
Anbieter Cloud-Provider oder Dienstleister
Kunde nutzende Organisation
Rechteverwaltung Steuerung von Zugriffen
Konfiguration technische und fachliche Einstellung eines Dienstes

IHK-sichere Kurzformulierung

IaaS, PaaS und SaaS sind Cloud-Service-Modelle, die beschreiben, welche IT-Schichten vom Anbieter bereitgestellt werden und welche der Kunde selbst verwaltet. Bei IaaS stellt der Anbieter virtuelle Infrastruktur wie Server, Speicher und Netzwerke bereit, während der Kunde Betriebssystem, Anwendungen, Daten und Sicherheit innerhalb der Systeme verwaltet. Bei PaaS stellt der Anbieter zusätzlich Plattform und Laufzeitumgebung bereit, sodass der Kunde sich stärker auf Anwendung und Daten konzentriert. Bei SaaS nutzt der Kunde eine fertige Anwendung, bleibt aber für Benutzer, Rollen, Berechtigungen, Daten, Freigaben und sichere Konfiguration verantwortlich. Das Shared Responsibility Model beschreibt diese geteilte Verantwortung.


Merksätze

IaaS = Infrastructure as a Service.

PaaS = Platform as a Service.

SaaS = Software as a Service.

IaaS liefert virtuelle Infrastruktur.

PaaS liefert Plattform für Anwendungen.

SaaS liefert fertige Software.

IaaS gibt viel Kontrolle.

SaaS nimmt viel Betrieb ab.

PaaS liegt dazwischen.

Cloud-VM muss Kunde meist selbst patchen.

PaaS-Anwendung bleibt Kundenthema.

SaaS-Rechte bleiben Kundenthema.

Daten bleiben fast immer Kundenthema.

Benutzer und Rollen bleiben fast immer Kundenthema.

Shared Responsibility konkret prüfen.

Cloud-Sicherheit ist gemeinsame Verantwortung.

Managed Service reduziert Betriebsaufwand.

Self-Managed erhöht Verantwortung.

Lift and Shift verschiebt,
modernisiert aber nicht automatisch.

Cloud-native nutzt Cloud-Prinzipien.

Serverless heißt keine Serververwaltung durch Kunden.

FaaS führt Funktionen bei Ereignissen aus.

XaaS ist Sammelbegriff.

Frage immer:
Infrastruktur,
Plattform
oder fertige Anwendung?

Weniger technischer Betrieb heißt nicht:
keine Administration.

Cloud ist nicht automatisch sicher.

Cloud ist nicht automatisch günstiger.

15.3 Public Cloud, Private Cloud, Hybrid Cloud und Multi Cloud

Cloud kann unterschiedlich bereitgestellt werden.

Die wichtigsten Cloud-Bereitstellungsmodelle sind:

- Public Cloud
- Private Cloud
- Hybrid Cloud
- Multi Cloud
- Community Cloud

Diese Modelle beschreiben, wo die Cloud betrieben wird, wer sie nutzt und wie stark sie vom Unternehmen selbst kontrolliert wird.

Merksatz:

Service-Modelle beschreiben,
was bereitgestellt wird.
Bereitstellungsmodelle beschreiben,
wo und für wen es bereitgestellt wird.

Warum Bereitstellungsmodelle wichtig sind

Nicht jede Cloud ist gleich aufgebaut.

Ein Unternehmen muss entscheiden:

Sollen Dienste beim öffentlichen Anbieter laufen?
Sollen sensible Systeme intern bleiben?
Sollen lokale Systeme mit Cloud verbunden werden?
Sollen mehrere Anbieter genutzt werden?
Gibt es Datenschutz- oder Compliance-Anforderungen?
Wie wichtig sind Kontrolle,
Kosten,
Skalierung
und Verfügbarkeit?

Merksatz:

Das passende Cloud-Modell hängt von Technik,
Sicherheit,
Kosten
und Anforderungen ab.

Public Cloud

Public Cloud bedeutet:

Ein Cloud-Anbieter stellt Ressourcen für viele Kunden bereit.

Die Kunden nutzen dieselbe Anbieterplattform, sind aber logisch voneinander getrennt.

Typische Ressourcen:

virtuelle Maschinen
Speicher
Datenbanken
Webdienste
Containerdienste
KI-Dienste
Identitätsdienste
Monitoring
Backup
SaaS-Anwendungen

Merksatz:

Public Cloud ist Cloud beim öffentlichen Anbieter für viele Kunden.

Public Cloud einfach erklärt

Beispiel:

Ein Unternehmen mietet virtuelle Server bei einem Cloud-Anbieter.

Die Server laufen nicht im eigenen Serverraum, sondern im Rechenzentrum des Anbieters.

Das Unternehmen verwaltet seine Ressourcen über:

Webportal
API
Kommandozeile
Automatisierung
Infrastructure as Code

Merksatz:

Public Cloud wird über Anbieterplattformen bereitgestellt und verwaltet.

Typische Public-Cloud-Eigenschaften

Typische Eigenschaften:

schnelle Bereitstellung
hohe Skalierbarkeit
nutzungsabhängige Abrechnung
große Auswahl an Diensten
weltweite Regionen
standardisierte Plattform
Self-Service
API-Steuerung
viele Automatisierungsmöglichkeiten

Merksatz:

Public Cloud ist schnell,
flexibel
und dienstorientiert.

Public Cloud: Vorteile

Vorteile:

keine eigene Hardwarebeschaffung
schnelle Bereitstellung
flexible Skalierung
viele fertige Dienste
weltweite Verfügbarkeit
nutzungsabhängige Kosten
moderne Sicherheitsfunktionen
Automatisierung gut möglich
geeignet für wechselnde Last

Merksatz:

Public Cloud bietet Flexibilität und schnelle Bereitstellung.

Public Cloud: Nachteile

Nachteile:

Abhängigkeit vom Anbieter
laufende Kosten können unübersichtlich werden
Datenschutz und Datenstandort prüfen
Internetabhängigkeit
weniger Kontrolle über physische Infrastruktur
Fehlkonfigurationen möglich
Anbieteränderungen können Auswirkungen haben
Know-how für sichere Nutzung nötig

Merksatz:

Public Cloud braucht Kostenkontrolle,
Sicherheitskonzept
und klare Verantwortlichkeiten.

Public Cloud und Mandantentrennung

In der Public Cloud nutzen viele Kunden dieselbe Plattform.

Damit Kunden getrennt bleiben, gibt es Mandantentrennung.

Mandantentrennung bedeutet:

Ressourcen eines Kunden sind logisch von anderen Kunden getrennt.

Beispiele:

eigene Benutzerverwaltung
eigene virtuelle Netzwerke
eigene Speicherbereiche
eigene Zugriffsrechte
eigene Abrechnung

Merksatz:

Public Cloud ist gemeinsam genutzt,
aber logisch getrennt.

Private Cloud

Private Cloud bedeutet:

Cloud-Prinzipien werden für eine einzelne Organisation bereitgestellt.

Sie kann betrieben werden:

im eigenen Rechenzentrum
bei einem Dienstleister
in einer dedizierten Umgebung

Wichtig:

Die Plattform wird nicht allgemein von vielen unabhängigen Kunden geteilt,
sondern ist für eine Organisation bestimmt.

Merksatz:

Private Cloud ist Cloud für eine Organisation.

Private Cloud einfach erklärt

Beispiel:

Ein Unternehmen betreibt im eigenen Rechenzentrum eine virtualisierte Plattform.

Fachbereiche können dort selbst Ressourcen anfordern:

virtuelle Maschinen
Speicher
Netzwerke
Datenbanken
Testumgebungen

Die Bereitstellung erfolgt automatisiert und zentral verwaltet.

Merksatz:

Private Cloud nutzt Cloud-Prinzipien,
aber in kontrollierter Umgebung.

Typische Private-Cloud-Eigenschaften

Typische Eigenschaften:

mehr Kontrolle
dedizierte Umgebung
interne Sicherheitsvorgaben
eigene Netzstruktur
eigene Compliance-Vorgaben
Automatisierung
Self-Service
Ressourcenpools
interne Verrechnung möglich

Merksatz:

Private Cloud verbindet Cloud-Funktionen mit stärkerer Kontrolle.

Private Cloud: Vorteile

Vorteile:

hohe Kontrolle über Umgebung
besser an interne Vorgaben anpassbar
Daten können im eigenen Betrieb bleiben
eigene Sicherheitsarchitektur möglich
geeignet für sensible Systeme
Integration in bestehende Infrastruktur
weniger Abhängigkeit von Public-Cloud-Anbieter

Merksatz:

Private Cloud ist interessant,
wenn Kontrolle und Anpassung wichtig sind.

Private Cloud: Nachteile

Nachteile:

eigene Hardware oder Dienstleister nötig
höhere Betriebsverantwortung
Skalierung begrenzter als Public Cloud
Investitionskosten möglich
eigenes Fachwissen nötig
Wartung bleibt stärker beim Unternehmen
Verfügbarkeit muss selbst geplant werden

Merksatz:

Private Cloud gibt Kontrolle,
aber auch mehr Betriebsaufwand.

Private Cloud ist nicht automatisch Cloud

Nur weil Server virtualisiert sind, ist es noch nicht automatisch eine Private Cloud.

Cloud-typische Merkmale sind zum Beispiel:

Self-Service
Automatisierung
Ressourcenpooling
schnelle Bereitstellung
messbare Nutzung
standardisierte Dienste
zentrale Verwaltung

Merksatz:

Virtualisierung allein ist noch keine vollständige Private Cloud.

Public Cloud und Private Cloud vergleichen

Merkmal Public Cloud Private Cloud
Betreiber öffentlicher Anbieter Unternehmen oder Dienstleister
Nutzerkreis viele Kunden eine Organisation
Kontrolle geringer über physische Basis höher
Skalierung sehr hoch abhängig von eigener Kapazität
Kostenmodell oft nutzungsabhängig oft Investition plus Betrieb
Anpassbarkeit begrenzt durch Anbieter höher
Datenstandort Anbieterregion wählen stärker selbst bestimmbar

Merksatz:

Public Cloud ist flexibler skalierbar.
Private Cloud ist stärker kontrollierbar.

Hybrid Cloud

Hybrid Cloud bedeutet:

Lokale IT oder Private Cloud wird mit Public Cloud kombiniert.

Beispiele:

internes Rechenzentrum
plus
Public-Cloud-Dienste

Oder:

Private Cloud
plus
Public Cloud

Merksatz:

Hybrid Cloud kombiniert lokale oder private IT mit Public Cloud.

Hybrid Cloud einfach erklärt

Beispiel:

Kundendatenbank läuft lokal.

Webfrontend läuft in der Public Cloud.

Backup wird zusätzlich in der Cloud gespeichert.

Verbindung erfolgt über VPN oder dedizierte Leitung.

So nutzt das Unternehmen lokale Kontrolle und Cloud-Flexibilität gleichzeitig.

Merksatz:

Hybrid Cloud verbindet zwei Welten.

Typische Hybrid-Cloud-Szenarien

Typische Szenarien:

lokales Active Directory mit Cloud-Diensten verbinden
lokale Server mit Cloud-Backup sichern
Cloud-Webanwendung greift auf lokale Datenbank zu
lokale Anwendung nutzt Cloud-Speicher
Cloud als Ausweichstandort
schrittweise Migration in die Cloud
Lastspitzen in Cloud auslagern
sensible Daten lokal,
skalierbare Dienste in Cloud

Merksatz:

Hybrid Cloud wird oft für schrittweise Migration und flexible Erweiterung genutzt.

Hybrid Cloud: Vorteile

Vorteile:

Kombination aus Kontrolle und Skalierung
schrittweise Migration möglich
sensible Systeme können lokal bleiben
Cloud-Dienste ergänzen lokale IT
Backup und Notfallkonzepte möglich
flexible Lastverteilung
bestehende Investitionen weiter nutzbar

Merksatz:

Hybrid Cloud ermöglicht Übergang und Kombination.

Hybrid Cloud: Nachteile

Nachteile:

höhere Komplexität
Netzwerkanbindung muss stabil sein
VPN oder Direktverbindung nötig
Identitätsmanagement muss zusammenpassen
Monitoring über mehrere Umgebungen nötig
Sicherheitsregeln müssen abgestimmt werden
Datenflüsse müssen dokumentiert werden
Fehlersuche wird komplexer

Merksatz:

Hybrid Cloud ist flexibel,
aber technisch anspruchsvoller.

Hybrid Cloud und Netzwerk

Hybrid Cloud braucht eine sichere Verbindung zwischen Umgebungen.

Möglichkeiten:

Site-to-Site-VPN
dedizierte Leitung
Cloud-VPN
SD-WAN
private Verbindung zum Anbieter

Wichtig:

Routing
DNS
Firewall-Regeln
Latenz
Bandbreite
Verschlüsselung
Redundanz

Merksatz:

Hybrid Cloud steht und fällt mit sauberer Netzwerkanbindung.

Hybrid Cloud und Identitäten

Benutzer sollen oft sowohl lokale als auch Cloud-Dienste nutzen.

Dafür braucht man ein Identitätskonzept.

Beispiele:

lokale Benutzerverwaltung
Cloud-Verzeichnisdienst
Synchronisierung
Single Sign-On
MFA
Rollen
Conditional Access

Merksatz:

Hybrid Cloud braucht einheitliche Identitäten und Zugriffskonzepte.

Hybrid Cloud und Datenflüsse

Bei Hybrid Cloud muss klar sein:

Welche Daten liegen lokal?
Welche Daten liegen in der Cloud?
Welche Daten werden übertragen?
Wer darf zugreifen?
Wo werden Backups gespeichert?
Welche Systeme kommunizieren miteinander?
Welche Schnittstellen gibt es?

Merksatz:

Hybrid Cloud braucht dokumentierte Datenflüsse.

Multi Cloud

Multi Cloud bedeutet:

Ein Unternehmen nutzt mehrere Cloud-Anbieter gleichzeitig.

Beispiel:

Anbieter A für virtuelle Server

Anbieter B für E-Mail und Office

Anbieter C für Backup

Anbieter D für KI- oder Datenanalyse

Merksatz:

Multi Cloud bedeutet mehrere Cloud-Anbieter parallel.

Multi Cloud ist nicht dasselbe wie Hybrid Cloud

Hybrid Cloud:

Kombination aus lokaler IT und Cloud

Multi Cloud:

Nutzung mehrerer Cloud-Anbieter

Beispiel:

Nur Anbieter A und Anbieter B,
ohne lokale Systeme:
Multi Cloud,
aber nicht zwingend Hybrid Cloud.

Merksatz:

Hybrid beschreibt lokal plus Cloud.
Multi Cloud beschreibt mehrere Anbieter.

Multi Cloud: Vorteile

Vorteile:

weniger Abhängigkeit von einem Anbieter
passende Dienste je Anbieter nutzbar
bessere Verhandlungsposition möglich
Ausweichmöglichkeiten
regulatorische oder regionale Anforderungen leichter erfüllbar
Spezialdienste verschiedener Anbieter nutzbar

Merksatz:

Multi Cloud kann Anbieterabhängigkeit verringern.

Multi Cloud: Nachteile

Nachteile:

höhere Komplexität
unterschiedliche Bedienkonzepte
unterschiedliche Sicherheitsmodelle
mehrere IAM-Systeme
schwierigeres Monitoring
höhere Anforderungen an Know-how
Kostenkontrolle komplizierter
Datenübertragung zwischen Anbietern kann teuer sein

Merksatz:

Multi Cloud reduziert Abhängigkeit,
erhöht aber Komplexität.

Multi Cloud und Vendor Lock-in

Vendor Lock-in bedeutet:

Ein Unternehmen wird stark abhängig von einem Anbieter.

Ursachen:

proprietäre Dienste
spezielle APIs
spezielle Datenformate
komplexe Migration
hohe Ausstiegskosten
Mitarbeitende kennen nur eine Plattform

Multi Cloud kann Vendor Lock-in verringern, aber nicht automatisch verhindern.

Merksatz:

Vendor Lock-in bedeutet starke Anbieterabhängigkeit.

Multi Cloud und Portabilität

Portabilität bedeutet:

Anwendungen oder Daten können leichter zwischen Umgebungen verschoben werden.

Möglichkeiten:

Container
offene Standards
standardisierte APIs
Infrastructure as Code
portable Datenformate
automatisierte Deployments

Aber:

vollständig einfache Portabilität ist selten.

Merksatz:

Portabilität muss geplant werden.

Community Cloud

Community Cloud bedeutet:

Eine Cloud wird von mehreren Organisationen mit ähnlichen Anforderungen genutzt.

Beispiele:

Behörden
Forschung
Bildung
Gesundheitswesen
bestimmte Branchen
Verbände

Gemeinsam sind oft:

Sicherheitsanforderungen
Datenschutzvorgaben
Compliance-Regeln
fachliche Anforderungen

Merksatz:

Community Cloud ist Cloud für eine bestimmte Gemeinschaft.

Community Cloud: Vorteile

Vorteile:

gemeinsame Anforderungen können besser berücksichtigt werden
branchenspezifische Vorgaben möglich
Kosten können geteilt werden
gemeinsame Standards
spezielle Sicherheits- und Compliance-Anforderungen

Merksatz:

Community Cloud bündelt ähnliche Anforderungen mehrerer Organisationen.

Community Cloud: Nachteile

Nachteile:

weniger flexibel als Public Cloud
begrenzter Nutzerkreis
Abstimmung zwischen Organisationen nötig
Governance komplexer
Angebot möglicherweise kleiner
Verantwortlichkeiten müssen klar geregelt sein

Merksatz:

Community Cloud braucht klare gemeinsame Regeln.

Cloud-Modelle im Vergleich

Modell Kerngedanke
Public Cloud Anbieterplattform für viele Kunden
Private Cloud Cloud für eine Organisation
Hybrid Cloud lokale/private IT plus Public Cloud
Multi Cloud mehrere Cloud-Anbieter
Community Cloud Cloud für Organisationen mit gemeinsamen Anforderungen

Merksatz:

Jedes Modell löst andere Anforderungen.

Typische Entscheidungskriterien

Wichtige Kriterien:

Datenschutz
Datenstandort
Kosten
Skalierbarkeit
Kontrolle
Verfügbarkeit
Compliance
Latenz
vorhandene Systeme
Know-how
Sicherheitsanforderungen
Anbieterabhängigkeit
Integrationsaufwand

Merksatz:

Cloud-Modell nach Anforderungen auswählen,
nicht nach Modewort.

Datenstandort

Datenstandort bedeutet:

Wo werden Daten gespeichert und verarbeitet?

Wichtig für:

Datenschutz
rechtliche Anforderungen
Kundenanforderungen
Latenz
Compliance
Vertragsbedingungen

Beispiel:

Daten müssen innerhalb der EU gespeichert werden.

Merksatz:

Datenstandort ist bei Cloud-Auswahl entscheidend.

Compliance

Compliance bedeutet:

Einhaltung von Regeln,
Gesetzen,
Standards
und internen Vorgaben.

Bei Cloud relevant:

Datenschutz
Informationssicherheit
Branchenvorgaben
Auditierbarkeit
Aufbewahrungsfristen
Löschkonzepte
Zugriffsnachweise
Vertragsanforderungen

Merksatz:

Cloud muss zu rechtlichen und organisatorischen Vorgaben passen.

Cloud und Latenz

Latenz ist die Verzögerung bei der Datenübertragung.

Sie ist wichtig bei:

Echtzeitanwendungen
Datenbankzugriffen
Remote Desktop
VoIP
Produktionssystemen
verteilten Anwendungen

Ein weit entfernter Cloud-Standort kann höhere Latenz verursachen.

Merksatz:

Cloud-Region beeinflusst Latenz.

Cloud und Bandbreite

Cloud-Dienste brauchen passende Bandbreite.

Relevant bei:

Backups
Dateiübertragung
Videodaten
Datenbankreplikation
Migration
Synchronisation
Hybrid-Cloud-Anbindung

Merksatz:

Cloud-Nutzung kann viel Netzwerkverkehr erzeugen.

Cloud und Datenübertragungskosten

Bei Cloud können Datenübertragungen Kosten verursachen.

Besonders wichtig:

ausgehender Datenverkehr aus der Cloud
Daten zwischen Regionen
Daten zwischen Anbietern
große Backups
Replikation
Downloads durch Benutzer

Merksatz:

Cloud-Traffic kann Kosten verursachen.

Cloud und Verfügbarkeit

Cloud-Anbieter stellen viele Möglichkeiten für Verfügbarkeit bereit.

Aber:

Der Kunde muss sie nutzen und konfigurieren.

Beispiele:

mehrere Zonen
mehrere Regionen
Load Balancer
Replikation
Backup
Auto Scaling
Monitoring

Merksatz:

Cloud bietet Möglichkeiten für Hochverfügbarkeit,
aber nicht automatisch fertige Hochverfügbarkeit.

Cloud und Ausfallsicherheit

Ausfallsicherheit bedeutet:

Ein Dienst bleibt trotz Störung nutzbar
oder kann schnell wiederhergestellt werden.

Wichtige Konzepte:

Redundanz
Backup
Wiederherstellung
Notfallplan
mehrere Zonen
mehrere Regionen
regelmäßige Tests

Merksatz:

Ausfallsicherheit muss geplant,
umgesetzt
und getestet werden.

Cloud und Verantwortung

Auch beim Bereitstellungsmodell gilt:

Verantwortung verschwindet nicht.

Der Kunde muss prüfen:

Wer betreibt was?
Wer sichert was?
Wer patcht was?
Wer darf zugreifen?
Wer überwacht?
Wer reagiert bei Störung?
Wer ist Ansprechpartner?
Was steht im Vertrag?

Merksatz:

Cloud-Verantwortung muss klar geregelt sein.

Cloud und Verträge

Cloud-Nutzung braucht klare vertragliche Regelungen.

Wichtige Punkte:

Leistungsumfang
Verfügbarkeit
Supportzeiten
Datenschutz
Datenstandort
Auftragsverarbeitung
Kündigung
Datenexport
Wiederherstellung
Sicherheitsmaßnahmen
Haftung

Merksatz:

Cloud ist auch ein organisatorisches und vertragliches Thema.

Service Level Agreement

Service Level Agreement wird abgekürzt:

SLA

Ein SLA beschreibt zugesicherte Serviceleistungen.

Beispiele:

Verfügbarkeit
Reaktionszeit
Wiederherstellungszeit
Supportzeit
Leistungswerte

Wichtig:

SLA genau lesen.
Hohe Prozentwerte bedeuten trotzdem mögliche Ausfallzeit.

Merksatz:

SLA beschreibt zugesicherte Servicequalität.

SLA und Verfügbarkeit

Verfügbarkeit wird oft in Prozent angegeben.

Beispiele:

Verfügbarkeit grobe Bedeutung
99 % deutlich mehr mögliche Ausfallzeit als 99,9 %
99,9 % höher verfügbar
99,99 % sehr hohe Verfügbarkeit
99,999 % extrem hohe Verfügbarkeit

Wichtig:

Je höher die Verfügbarkeit,
desto aufwendiger und teurer ist sie meist.

Merksatz:

Mehr Neunen bedeuten weniger erlaubte Ausfallzeit,
aber meist mehr Aufwand.

Cloud und Exit-Strategie

Eine Exit-Strategie beschreibt, wie man einen Cloud-Dienst wieder verlassen kann.

Fragen:

Wie exportiere ich Daten?
In welchem Format bekomme ich Daten zurück?
Wie lange dauert Migration?
Welche Kosten entstehen?
Welche Abhängigkeiten gibt es?
Wie werden Daten beim Anbieter gelöscht?
Gibt es Alternativen?

Merksatz:

Cloud-Einstieg braucht auch Cloud-Ausstiegsplan.

Cloud und Datenportabilität

Datenportabilität bedeutet:

Daten können in ein anderes System oder zu einem anderen Anbieter übertragen werden.

Wichtig:

offene Formate
Exportfunktionen
dokumentierte Schnittstellen
keine unnötigen proprietären Abhängigkeiten
regelmäßige Exporttests

Merksatz:

Daten sollten nicht in einem Dienst gefangen sein.

Cloud und Schatten-IT

Schatten-IT bedeutet:

Fachbereiche nutzen IT-Dienste ohne Wissen oder Freigabe der IT-Abteilung.

Beispiele:

private Cloud-Speicher
nicht freigegebene SaaS-Tools
eigene KI-Dienste
externe Projektplattformen
private Messenger

Risiken:

Datenschutzprobleme
Datenabfluss
fehlende Backups
keine Rechtekontrolle
keine Löschung bei Austritt
keine Vertragsprüfung

Merksatz:

Schatten-IT entsteht oft,
wenn offizielle Lösungen fehlen oder zu unpraktisch sind.

Cloud Governance

Cloud Governance beschreibt Regeln und Steuerung für Cloud-Nutzung.

Dazu gehören:

wer darf Cloud-Ressourcen erstellen?
welche Dienste sind erlaubt?
welche Regionen sind erlaubt?
welche Sicherheitsstandards gelten?
wie werden Kosten überwacht?
wie werden Daten klassifiziert?
wie werden Zugriffe geprüft?
wie werden Änderungen dokumentiert?

Merksatz:

Cloud Governance sorgt für kontrollierte Cloud-Nutzung.

Tagging

Tagging bedeutet:

Cloud-Ressourcen werden mit Schlagworten oder Metadaten markiert.

Beispiele:

Projekt
Kostenstelle
Verantwortlicher
Umgebung
Kritikalität
Ablaufdatum
Datenschutzklasse

Vorteile:

Kosten zuordnen
Ressourcen finden
Verantwortliche erkennen
Aufräumen erleichtern
Automatisierung ermöglichen

Merksatz:

Tags machen Cloud-Ressourcen verwaltbar.

Cloud-Kostenkontrolle

Kostenkontrolle ist wichtig, weil Cloud-Ressourcen schnell erstellt werden können.

Maßnahmen:

Budgets
Alarme
Tags
Kostenstellen
Rechtebegrenzung
Abschalten ungenutzter Ressourcen
passende Größen wählen
Reservierungen prüfen
Datenverkehr beobachten

Merksatz:

Cloud-Flexibilität braucht Kostenkontrolle.

Typische Cloud-Fehlentscheidungen

Häufige Fehler:

Cloud-Modell ohne Anforderungen auswählen
Datenschutz nicht prüfen
Kosten nicht überwachen
keine Exit-Strategie planen
kein Backup-Konzept erstellen
keine Rollen definieren
Ressourcen öffentlich freigeben
Multi Cloud ohne Know-how einführen
Hybrid Cloud ohne Netzplanung starten
SLA falsch verstehen

Merksatz:

Cloud muss geplant werden,
nicht nur gebucht.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Was ist Public Cloud?
- Was ist Private Cloud?
- Was ist Hybrid Cloud?
- Was ist Multi Cloud?
- Was ist Community Cloud?
- Was ist der Unterschied zwischen Hybrid Cloud und Multi Cloud?
- Welche Vorteile hat Public Cloud?
- Welche Vorteile hat Private Cloud?
- Warum ist Hybrid Cloud komplexer?
- Was bedeutet Vendor Lock-in?
- Was bedeutet Datenstandort?
- Was ist ein SLA?
- Warum braucht Cloud eine Exit-Strategie?
- Was ist Cloud Governance?
- Warum ist Tagging sinnvoll?
- Warum ist Cloud-Kostenkontrolle wichtig?

Typische Prüfungsfallen

Public Cloud ist nicht automatisch unsicher.

Private Cloud ist nicht automatisch günstiger.

Hybrid Cloud ist nicht einfach nur irgendeine Cloud.

Multi Cloud ist nicht dasselbe wie Hybrid Cloud.

Community Cloud ist für bestimmte Organisationengruppen.

Virtualisierung allein ist noch keine Private Cloud.

Cloud ist nicht automatisch hochverfügbar.

Cloud ist nicht automatisch günstiger.

Datenstandort prüfen.

SLA genau lesen.

Hohe Verfügbarkeit muss konfiguriert werden.

Multi Cloud erhöht Komplexität.

Hybrid Cloud braucht gute Netzplanung.

Vendor Lock-in früh beachten.

Exit-Strategie vor dem Wechsel planen.

Schatten-IT ist ein Sicherheitsrisiko.

Governance verhindert unkontrollierte Cloud-Nutzung.

Tagging hilft bei Kosten und Verwaltung.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
Public Cloud Cloud-Plattform für viele Kunden
Private Cloud Cloud für eine Organisation
Hybrid Cloud lokale/private IT plus Public Cloud
Multi Cloud mehrere Cloud-Anbieter
Community Cloud Cloud für Organisationen mit gemeinsamen Anforderungen
Mandantentrennung logische Trennung verschiedener Kunden
Vendor Lock-in starke Anbieterabhängigkeit
Portabilität Übertragbarkeit von Daten oder Anwendungen
Datenstandort Ort der Speicherung und Verarbeitung
Compliance Einhaltung von Regeln und Vorgaben
SLA Service Level Agreement
Exit-Strategie Plan zum Verlassen eines Dienstes
Datenportabilität Daten in anderes System übertragen können
Schatten-IT nicht offiziell freigegebene IT-Nutzung
Cloud Governance Regeln für Cloud-Nutzung
Tagging Metadaten für Ressourcen
Kostenkontrolle Überwachung und Steuerung von Cloud-Kosten
Verfügbarkeit Dienst ist nutzbar
Ausfallsicherheit Dienst bleibt trotz Störung verfügbar oder wird wiederhergestellt

IHK-sichere Kurzformulierung

Public Cloud bezeichnet Cloud-Dienste eines öffentlichen Anbieters, die von vielen Kunden genutzt werden, wobei die Kunden logisch voneinander getrennt sind. Private Cloud stellt Cloud-Funktionen für eine einzelne Organisation bereit und bietet mehr Kontrolle, aber auch mehr Betriebsverantwortung. Hybrid Cloud kombiniert lokale oder private IT mit Public Cloud, während Multi Cloud die Nutzung mehrerer Cloud-Anbieter beschreibt. Community Cloud wird von Organisationen mit gemeinsamen Anforderungen genutzt. Bei der Auswahl eines Cloud-Modells müssen Datenschutz, Datenstandort, Compliance, Kosten, Skalierbarkeit, Kontrolle, Verfügbarkeit, Latenz, Anbieterabhängigkeit und Exit-Strategie berücksichtigt werden.


Merksätze

Bereitstellungsmodell beschreibt,
wo und für wen Cloud läuft.

Public Cloud = Anbieterplattform für viele Kunden.

Private Cloud = Cloud für eine Organisation.

Hybrid Cloud = lokal oder privat plus Public Cloud.

Multi Cloud = mehrere Anbieter.

Community Cloud = gemeinsame Anforderungen.

Public Cloud ist flexibel.

Private Cloud gibt mehr Kontrolle.

Hybrid Cloud kombiniert Welten.

Multi Cloud reduziert Anbieterabhängigkeit,
erhöht aber Komplexität.

Hybrid ist nicht automatisch Multi Cloud.

Multi Cloud ist nicht automatisch Hybrid.

Virtualisierung allein ist keine Private Cloud.

Mandantentrennung trennt Kunden logisch.

Vendor Lock-in früh beachten.

Portabilität planen.

Datenstandort prüfen.

Compliance beachten.

Cloud-Region beeinflusst Latenz.

Cloud-Traffic kann Kosten verursachen.

Cloud ist nicht automatisch hochverfügbar.

Hochverfügbarkeit muss geplant werden.

SLA genau lesen.

Exit-Strategie vor Nutzung bedenken.

Datenportabilität ist wichtig.

Schatten-IT vermeiden.

Cloud Governance schafft Regeln.

Tagging hilft bei Verwaltung und Kosten.

Cloud-Kosten aktiv überwachen.

Cloud muss geplant werden,
nicht nur gebucht.

15.4 Cloud-Netzwerke, VPC, Subnetze und Security Groups

Cloud-Dienste brauchen genau wie lokale Systeme ein Netzwerk.

In der Cloud werden Netzwerke aber nicht mit physischen Switches und Routern aufgebaut, sondern überwiegend virtuell.

Typische Bestandteile eines Cloud-Netzwerks:

- virtuelles Netzwerk
- Subnetze
- Routingtabellen
- Security Groups
- Network Security Groups
- virtuelle Firewalls
- Load Balancer
- öffentliche IP-Adressen
- private IP-Adressen
- NAT-Gateways
- VPN-Gateways
- DNS
- Peering

Merksatz:

Cloud-Netzwerke sind virtuell,
müssen aber genauso sauber geplant werden wie lokale Netzwerke.

Warum Cloud-Netzwerke wichtig sind

Viele Cloud-Fehler entstehen nicht durch die Anwendung, sondern durch Netzwerk- oder Sicherheitskonfiguration.

Beispiele:

virtuelle Maschine nicht erreichbar
Datenbank öffentlich erreichbar
Webserver hat falsche Security Group
Subnetz hat keine passende Route
Cloud-Dienst kann Backend nicht erreichen
VPN zur Cloud funktioniert nicht
DNS zeigt auf falsches Ziel
Load Balancer erreicht keine Instanz

Merksatz:

Cloud-Probleme sind oft Netzwerk-,
Routing-
oder Firewall-Probleme.

Virtuelles Netzwerk

Ein virtuelles Netzwerk ist ein logisch getrenntes Netzwerk in der Cloud.

Je nach Anbieter heißt es zum Beispiel:

VPC
VNet
Virtual Network
Virtual Private Cloud

Es enthält Cloud-Ressourcen wie:

virtuelle Maschinen
Subnetze
Datenbanken
Load Balancer
Container
VPN-Gateways
NAT-Gateways

Merksatz:

Virtuelles Netzwerk = eigenes logisch getrenntes Cloud-Netz.

VPC

VPC steht für:

Virtual Private Cloud

Eine VPC ist ein virtuelles, logisch isoliertes Netzwerk innerhalb einer Public Cloud.

In einer VPC legt man fest:

IP-Adressbereich
Subnetze
Routing
Sicherheitsregeln
Gateways
Verbindungen zu anderen Netzen

Merksatz:

VPC ist ein privater Netzwerkbereich innerhalb der Cloud.

VNet

VNet steht für:

Virtual Network

Der Begriff wird in manchen Cloud-Plattformen für virtuelle Netzwerke verwendet.

Die Grundidee ist ähnlich wie bei VPC:

eigener IP-Bereich
Subnetze
Routing
Sicherheitsregeln
Cloud-Ressourcen
Verbindungen zu anderen Netzen

Merksatz:

VNet und VPC beschreiben ähnliche Cloud-Netzwerk-Konzepte.

IP-Adressbereich im Cloud-Netz

Beim Anlegen eines Cloud-Netzes wird ein IP-Adressbereich festgelegt.

Beispiel:

10.20.0.0/16

Daraus können mehrere Subnetze gebildet werden.

Beispiele:

10.20.1.0/24 Web-Subnetz

10.20.2.0/24 App-Subnetz

10.20.3.0/24 Datenbank-Subnetz

Wichtig:

Der Adressbereich darf sich nicht ungewollt mit lokalen Netzen überschneiden.

Merksatz:

Cloud-IP-Planung muss zu lokaler Netzplanung passen.

Subnetze in der Cloud

Subnetze teilen ein virtuelles Netzwerk in kleinere Bereiche auf.

Typische Subnetze:

Web-Subnetz
App-Subnetz
Datenbank-Subnetz
Management-Subnetz
Public Subnet
Private Subnet
Gateway-Subnetz

Vorteile:

bessere Struktur
gezielte Sicherheitsregeln
getrennte Routingtabellen
Trennung von öffentlichen und internen Ressourcen

Merksatz:

Subnetze strukturieren Cloud-Netze.

Public Subnet

Ein Public Subnet ist ein Subnetz, das direkt oder indirekt Zugang zum Internet haben kann.

Typische Ressourcen:

Load Balancer
öffentlich erreichbarer Webserver
Bastion Host
NAT-Gateway
Reverse Proxy

Wichtig:

Nicht jede Ressource in der Cloud gehört in ein Public Subnet.

Merksatz:

Public Subnet nur für Komponenten,
die wirklich öffentlich erreichbar sein müssen.

Private Subnet

Ein Private Subnet enthält interne Ressourcen, die nicht direkt aus dem Internet erreichbar sein sollen.

Typische Ressourcen:

Datenbanken
interne Backends
interne APIs
Anwendungssysteme
Verarbeitungssysteme
Container-Worker
interne Dienste

Merksatz:

Private Subnet schützt interne Cloud-Ressourcen vor direktem Internetzugriff.

Public und Private Subnet vergleichen

Merkmal Public Subnet Private Subnet
Internetzugriff eingehend möglich normalerweise nicht direkt
typische Systeme Load Balancer, Bastion Host Datenbank, Backend
Schutzbedarf hoch sehr hoch
Routing oft zum Internet Gateway oft über NAT oder interne Routen
Ziel öffentliche Erreichbarkeit interne Verarbeitung

Merksatz:

Öffentlich erreichbare Systeme nach außen,
interne Systeme nach innen trennen.

Internet Gateway

Ein Internet Gateway verbindet ein Cloud-Netz mit dem Internet.

Es ermöglicht:

eingehende Verbindungen aus dem Internet

ausgehende Verbindungen ins Internet

Ob eine Ressource wirklich erreichbar ist, hängt zusätzlich ab von:

öffentlicher IP-Adresse
Routingtabelle
Security Group
Firewall-Regeln
Dienststatus

Merksatz:

Internet Gateway allein macht eine Ressource nicht automatisch erreichbar.

NAT-Gateway

Ein NAT-Gateway erlaubt internen Ressourcen, Verbindungen ins Internet aufzubauen, ohne selbst direkt aus dem Internet erreichbar zu sein.

Beispiel:

Datenbankserver im Private Subnet
lädt Updates herunter

aber:
Internet kann nicht direkt zur Datenbank verbinden

Merksatz:

NAT-Gateway erlaubt ausgehenden Internetzugriff für private Ressourcen.

Internet Gateway und NAT-Gateway vergleichen

Merkmal Internet Gateway NAT-Gateway
Zweck Verbindung Cloud-Netz ↔ Internet ausgehender Zugriff aus privaten Netzen
eingehend aus Internet möglich, wenn erlaubt normalerweise nicht
typischer Einsatz Public Subnet Private Subnet
Schutzwirkung keine alleinige Schutzmaßnahme versteckt private Ressourcen vor direktem Zugriff

Merksatz:

Internet Gateway verbindet öffentlich.
NAT-Gateway ermöglicht ausgehend.

Routingtabellen in der Cloud

Routingtabellen legen fest, wohin Pakete gesendet werden.

Typische Ziele:

lokales Cloud-Netz
Internet Gateway
NAT-Gateway
VPN-Gateway
Peering-Verbindung
Firewall-Appliance
andere Subnetze
lokales Unternehmensnetz

Merksatz:

Routingtabellen bestimmen Wege im Cloud-Netz.

Lokale Route

Jedes Cloud-Netz hat normalerweise eine lokale Route.

Diese erlaubt Kommunikation innerhalb des virtuellen Netzwerks.

Beispiel:

10.20.0.0/16
local

Damit können Subnetze innerhalb des Cloud-Netzes grundsätzlich miteinander kommunizieren, sofern Sicherheitsregeln es erlauben.

Merksatz:

Lokale Route erlaubt Kommunikation innerhalb des Cloud-Netzes.

Route ins Internet

Für Internetzugriff braucht ein Public Subnet typischerweise eine Route wie:

0.0.0.0/0
über Internet Gateway

Für Private Subnets kann die Standardroute über ein NAT-Gateway gehen:

0.0.0.0/0
über NAT-Gateway

Merksatz:

Standardroute entscheidet,
wohin unbekannte Ziele gehen.

Route zum Firmennetz

Bei Hybrid Cloud braucht die Cloud eine Route zum lokalen Unternehmensnetz.

Beispiel:

lokales Firmennetz:
192.168.10.0/24

Route in Cloud:
192.168.10.0/24
über VPN-Gateway

Gleichzeitig braucht das Firmennetz eine Rückroute zum Cloud-Netz.

Merksatz:

Hybrid Cloud braucht Hin- und Rückroute.

Rückroute in Cloud-Szenarien

Viele Fehler entstehen, weil nur der Hinweg geplant wurde.

Beispiel:

Cloud-Server erreicht lokales System nicht.

Oder:

lokaler Client erreicht Cloud-Server,
aber Antwort kommt nicht zurück.

Mögliche Ursache:

Rückroute fehlt
Firewall blockiert Rückverkehr
NAT verändert Adressen
asymmetrisches Routing

Merksatz:

Auch in der Cloud gilt:
Ohne Rückweg keine funktionierende Verbindung.

Security Group

Eine Security Group ist eine virtuelle Firewall-Regelgruppe für Cloud-Ressourcen.

Sie steuert meist:

eingehenden Verkehr
ausgehenden Verkehr
Protokolle
Ports
Quellen
Ziele

Security Groups werden oft direkt einer Ressource zugeordnet, zum Beispiel einer virtuellen Maschine.

Merksatz:

Security Group = Firewall-Regeln direkt an der Cloud-Ressource.

Inbound und Outbound

Inbound bedeutet:

eingehender Verkehr zur Ressource

Outbound bedeutet:

ausgehender Verkehr von der Ressource

Beispiel Webserver:

Inbound:
TCP 443 von Internet erlaubt

Outbound:
Verbindung zur Datenbank oder zu Updateservern erlaubt

Merksatz:

Inbound und Outbound getrennt prüfen.

Stateful Security Group

Viele Security Groups arbeiten stateful.

Stateful bedeutet:

Wenn eine Verbindung erlaubt wurde,
ist der Rückverkehr automatisch erlaubt.

Beispiel:

Client verbindet zu Webserver TCP 443.

Antwortpakete des Webservers zurück zum Client
werden automatisch zugeordnet.

Merksatz:

Stateful-Regeln merken sich Verbindungen.

Network ACL

Eine Network ACL ist eine Zugriffsliste auf Netzwerk- oder Subnetzebene.

Je nach Cloud-Plattform kann sie:

eingehende Regeln prüfen
ausgehende Regeln prüfen
stateless arbeiten
Regelreihenfolge beachten

Stateless bedeutet:

Rückverkehr muss separat erlaubt werden.

Merksatz:

Network ACLs wirken oft näher am Subnetz und können stateless sein.

Security Group und Network ACL vergleichen

Merkmal Security Group Network ACL
Ebene Ressource oder Instanz Subnetz oder Netzwerkebene
Zustand oft stateful oft stateless
Rückverkehr häufig automatisch erlaubt häufig separat nötig
Einsatz feine Ressourcenregeln zusätzliche Netzgrenze
Fehlerquelle falsche Quelle oder Port fehlender Rückverkehr oder Regelreihenfolge

Merksatz:

Security Group und Network ACL können beide blockieren.

Network Security Group

Network Security Group wird oft abgekürzt:

NSG

Eine NSG ist eine Regelgruppe, die Netzwerkverkehr auf Subnetz- oder Ressourceneebene steuern kann.

Typische Angaben:

Quelle
Ziel
Port
Protokoll
Richtung
Priorität
Aktion
Beschreibung

Merksatz:

NSG ist eine Cloud-Regelgruppe für Netzwerkzugriffe.

Regelreihenfolge und Priorität

Manche Cloud-Regelwerke arbeiten mit Prioritäten.

Dabei gilt:

Regel mit höherer Priorität oder niedrigerer Nummer
wird zuerst geprüft

Je nach Plattform ist die genaue Logik unterschiedlich.

Wichtig:

spezifische Regeln vor allgemeinen Regeln
Deny-Regeln beachten
Standardregeln verstehen

Merksatz:

Regelreihenfolge kann entscheiden,
ob Verkehr erlaubt oder blockiert wird.

Quelle und Ziel in Cloud-Regeln

In Cloud-Regeln können Quellen und Ziele sein:

IP-Adressen
Subnetze
Security Groups
Tags
Service Accounts
Load Balancer
Cloud-Dienste
Internet

Beispiel:

Webserver-Security-Group darf zur Datenbank-Security-Group auf TCP 5432.

Das ist oft besser als:

gesamtes Netz darf zur Datenbank.

Merksatz:

Cloud-Regeln möglichst gezielt formulieren.

Öffentliche IP-Adresse

Eine öffentliche IP-Adresse macht eine Ressource grundsätzlich aus dem Internet adressierbar.

Aber erreichbar ist sie nur, wenn zusätzlich passen:

Routing
Security Group
Firewall
Dienst
Betriebssystem-Firewall
DNS
Load Balancer
Zertifikat

Merksatz:

Öffentliche IP allein reicht nicht für funktionierenden Zugriff.

Private IP-Adresse

Private IP-Adressen werden innerhalb des Cloud-Netzes genutzt.

Typisch für:

interne Kommunikation
Datenbanken
Backends
interne APIs
Server-zu-Server-Kommunikation
Hybrid-Cloud-Verbindungen

Merksatz:

Private IPs sind für interne Kommunikation im Cloud-Netz.

Öffentliche und private IP vergleichen

Merkmal öffentliche IP private IP
Erreichbarkeit aus Internet möglich nur intern oder über Verbindung
Einsatz Webzugriff, Load Balancer Backend, Datenbank, interne Dienste
Risiko höher geringer, aber nicht risikofrei
Schutz Firewall, Security Group, TLS Segmentierung, Regeln, IAM

Merksatz:

Öffentlich nur,
wenn es wirklich nötig ist.

Load Balancer in der Cloud

Ein Load Balancer verteilt Anfragen auf mehrere Ziele.

Ziele können sein:

virtuelle Maschinen
Container
App-Instanzen
Backends
Servergruppen

Aufgaben:

Lastverteilung
Health Checks
Hochverfügbarkeit
TLS-Terminierung
Weiterleitung
Skalierung unterstützen

Merksatz:

Load Balancer verteilt Anfragen und erhöht Verfügbarkeit.

Health Check

Ein Health Check prüft, ob ein Backend gesund ist.

Beispiele:

TCP-Port erreichbar?
HTTP-Status 200?
bestimmter Pfad antwortet?
Anwendung meldet gesund?
Antwortzeit akzeptabel?

Wenn ein Backend ungesund ist, leitet der Load Balancer keinen Verkehr mehr dorthin.

Merksatz:

Health Check entscheidet,
ob ein Backend Verkehr bekommt.

Typische Load-Balancer-Fehler

Häufige Fehler:

Backend-Port falsch
Health Check falscher Pfad
Security Group blockiert Load Balancer
Backend-Dienst läuft nicht
TLS-Zertifikat falsch
falscher Host-Header
falsches Protokoll
Backend in falschem Subnetz
keine gesunden Ziele

Merksatz:

502 oder 503 in der Cloud hängt oft mit Load Balancer oder Backend zusammen.

Cloud-DNS

Cloud-DNS verwaltet Namen für Cloud-Ressourcen.

Typische Aufgaben:

öffentliche DNS-Zonen
private DNS-Zonen
interne Namen
Load-Balancer-Namen
Service Discovery
Hybrid-DNS
Weiterleitung zu lokalen DNS-Servern

Merksatz:

Cloud-DNS verbindet Namen mit Cloud-Ressourcen.

Private DNS-Zone

Eine Private DNS-Zone ist nur innerhalb bestimmter Netzwerke sichtbar.

Beispiel:

app.internal.cloud

Nur Systeme im Cloud-Netz oder verbundenen Netzen können diesen Namen auflösen.

Merksatz:

Private DNS ist für interne Cloud-Namen.

Public DNS-Zone

Eine Public DNS-Zone ist öffentlich abfragbar.

Beispiel:

www.firma.de

Sie wird für öffentlich erreichbare Dienste genutzt.

Wichtig:

Öffentlicher DNS-Eintrag bedeutet nicht,
dass Zugriff auch erlaubt ist.

Merksatz:

Public DNS ist sichtbar,
Zugriff hängt trotzdem von Routing und Regeln ab.

Cloud Peering

Peering verbindet zwei virtuelle Netzwerke miteinander.

Beispiel:

VPC A
↔
VPC B

Oder:

VNet A
↔
VNet B

Ziel:

private Kommunikation zwischen Cloud-Netzen

Wichtig:

Routen
Security Groups
DNS
Überschneidung von IP-Netzen
Berechtigungen

Merksatz:

Peering verbindet Cloud-Netze privat miteinander.

Peering ist kein Transit automatisch

Ein häufiger Denkfehler:

Wenn Netz A mit B verbunden ist
und B mit C verbunden ist,
kann A automatisch C erreichen.

Das stimmt nicht immer.

Viele Peering-Verbindungen sind nicht automatisch transitiv.

Merksatz:

Peering bedeutet nicht automatisch Durchleitung zu dritten Netzen.

Transit Gateway oder Hub-and-Spoke

In größeren Cloud-Netzen nutzt man oft zentrale Netzwerkarchitekturen.

Beispiel:

Hub-Netz
mit Firewall,
VPN,
Internetzugang
und zentralen Diensten

Spoke-Netze
für Anwendungen,
Abteilungen
oder Umgebungen

Vorteil:

zentrale Kontrolle
einheitliches Routing
bessere Segmentierung
übersichtliche Sicherheitsregeln

Merksatz:

Hub-and-Spoke ordnet viele Cloud-Netze zentral.

Cloud-VPN

Cloud-VPN verbindet Cloud-Netze mit anderen Netzen.

Beispiele:

Cloud ↔ lokales Rechenzentrum

Cloud ↔ Niederlassung

Cloud ↔ andere Cloud

Wichtig:

passende IP-Netze
Routing auf beiden Seiten
Firewall-Regeln
Verschlüsselung
Monitoring
Redundanz

Merksatz:

Cloud-VPN braucht Planung auf Cloud-Seite und lokaler Seite.

Direktverbindung zur Cloud

Neben VPN kann es direkte private Verbindungen zu Cloud-Anbietern geben.

Eigenschaften:

private Verbindung
meist stabilere Leistung
geringere Latenz möglich
höhere Bandbreite möglich
kein normaler Internetweg
oft teurer und aufwendiger

Merksatz:

Direktverbindung kann für kritische Hybrid-Cloud-Szenarien sinnvoll sein.

Bastion Host in der Cloud

Ein Bastion Host ist ein besonders geschützter Sprungserver.

Zweck:

Adminzugriffe auf private Cloud-Ressourcen ermöglichen,
ohne diese direkt ins Internet zu stellen.

Beispiel:

Admin
→ Bastion Host
→ private VM

Wichtig:

MFA
Logging
beschränkte Quellen
regelmäßige Updates
keine Dauerzugänge
starke Härtung

Merksatz:

Bastion Host reduziert direkte öffentliche Adminzugriffe.

Managementports nicht öffentlich öffnen

Kritische Managementports sollten nicht offen im Internet liegen.

Beispiele:

SSH TCP 22
RDP TCP 3389
Datenbankports
Admin-Weboberflächen
Kubernetes-API
Storage-Adminzugänge

Besser:

VPN
Bastion Host
Zero-Trust-Zugang
private Subnetze
eingeschränkte Quell-IP
MFA

Merksatz:

Managementzugänge gehören nicht breit ins Internet.

Cloud-Firewall

Eine Cloud-Firewall kann zentrale Filterung übernehmen.

Sie schützt zum Beispiel:

Internetzugang
Verbindungen zwischen Subnetzen
Verbindung zu lokalen Netzen
Cloud-zu-Cloud-Verkehr
DMZ-ähnliche Bereiche

Funktionen können sein:

Paketfilter
Stateful Inspection
Anwendungskontrolle
IDS/IPS
URL-Filter
Logging

Merksatz:

Cloud-Firewall ergänzt Security Groups und Netzsegmentierung.

Cloud-Netzsegmentierung

Auch in der Cloud sollte man Systeme trennen.

Beispiele:

Web-Schicht
App-Schicht
Datenbank-Schicht
Management-Schicht
Entwicklungsumgebung
Testumgebung
Produktionsumgebung
DMZ-ähnliche Zone

Merksatz:

Cloud braucht Segmentierung wie lokale Netze.

Drei-Schichten-Architektur in der Cloud

Ein typisches Muster:

Web-Schicht:
öffentlich erreichbar über Load Balancer

App-Schicht:
nur intern vom Webserver erreichbar

Datenbank-Schicht:
nur von App-Servern erreichbar

Vorteil:

bessere Sicherheit
klare Kommunikationswege
weniger Angriffsfläche

Merksatz:

Datenbanken gehören normalerweise nicht direkt ins Internet.

Umgebungen trennen

Cloud-Ressourcen sollten nach Umgebung getrennt werden.

Typische Umgebungen:

Entwicklung
Test
Staging
Produktion

Warum?

Testfehler sollen Produktion nicht stören.
Rechte können getrennt werden.
Kosten können getrennt werden.
Änderungen werden kontrollierter.
Sicherheitsregeln sind klarer.

Merksatz:

Entwicklung,
Test
und Produktion sauber trennen.

Cloud-Netzwerk und IAM

Netzwerkregeln allein reichen nicht.

Auch Identitäten und Rechte sind wichtig.

Beispiel:

Benutzer darf Security Group ändern.
Benutzer darf öffentliche IP vergeben.
Benutzer darf Route zum Internet setzen.
Benutzer darf Firewall-Regel öffnen.

Diese Rechte können sicherheitskritisch sein.

Merksatz:

Wer Cloud-Netzwerke ändern darf,
kann Sicherheit stark beeinflussen.

Cloud-Netzwerk-Fehlkonfigurationen

Häufige Fehler:

Datenbank öffentlich erreichbar
SSH offen für das ganze Internet
RDP offen für das ganze Internet
Security Group zu breit
falsche Route ins Internet
Private Subnet versehentlich öffentlich
fehlende Rückroute
falscher Load-Balancer-Health-Check
keine Logs
veraltete Bastion Hosts
Peering ohne Sicherheitsprüfung

Merksatz:

Viele Cloud-Sicherheitsprobleme sind Netzwerk-Fehlkonfigurationen.

Cloud-Netzwerk-Logging

Wichtige Logquellen:

Flow Logs
Firewall-Logs
Load-Balancer-Logs
DNS-Logs
VPN-Logs
IAM-Logs
Routing-Änderungen
Security-Group-Änderungen
WAF-Logs

Merksatz:

Netzwerklogs zeigen,
welcher Verkehr erlaubt oder blockiert wurde.

Flow Logs

Flow Logs zeigen Netzwerkverbindungen auf Ebene von Metadaten.

Sie enthalten typischerweise:

Quelle
Ziel
Port
Protokoll
Aktion
Zeit
Datenmenge
Interface oder Ressource

Sie zeigen normalerweise nicht den vollständigen Paketinhalt.

Merksatz:

Flow Logs zeigen Verbindungsdaten,
aber keinen kompletten Paketmitschnitt.

Cloud-Netzwerk-Monitoring

Überwacht werden sollten:

VPN-Tunnelstatus
Load Balancer
Backend-Gesundheit
Paketverlust
Latenz
Bandbreite
Firewall-Drops
DNS-Fehler
öffentliche IPs
ungewöhnlicher Datenverkehr
Kosten durch Traffic

Merksatz:

Cloud-Netzwerk-Monitoring schützt Betrieb und Kosten.

Cloud-Netzwerk-Fehlersuche

Sinnvolle Reihenfolge:

1. Quelle und Ziel bestimmen.
2. IP-Adressen prüfen.
3. DNS prüfen.
4. Subnetz prüfen.
5. Routingtabelle prüfen.
6. Security Group prüfen.
7. Network ACL oder NSG prüfen.
8. Load Balancer prüfen.
9. Zielsystem und Dienst prüfen.
10. Host-Firewall prüfen.
11. Logs prüfen.
12. Rückweg prüfen.

Merksatz:

Auch in der Cloud gilt:
DNS,
Route,
Firewall,
Dienst
und Rückweg prüfen.

Fehlerbild: Cloud-VM nicht per SSH erreichbar

Mögliche Ursachen:

keine öffentliche IP
DNS zeigt falsch
Routing zum Internet fehlt
Security Group blockiert TCP 22
Network ACL blockiert
SSH-Dienst läuft nicht
Host-Firewall blockiert
falscher Benutzer oder Schlüssel
Bastion Host nötig
Quell-IP nicht erlaubt

Merksatz:

SSH-Fehler in Cloud mit IP,
Route,
Security Group,
Dienst
Schlüssel
und Bastion prüfen.

Fehlerbild: Webdienst in Cloud nicht erreichbar

Mögliche Ursachen:

DNS falsch
Load Balancer falsch
Zertifikat falsch
Security Group blockiert TCP 443
Backend ungesund
Health Check falsch
Anwendung läuft nicht
falscher Port
private Ressource ohne öffentliche Freigabe
WAF blockiert

Merksatz:

Webfehler in Cloud mit DNS,
Load Balancer,
Security Group,
TLS
und Backend prüfen.

Fehlerbild: Cloud-Datenbank öffentlich erreichbar

Das ist meistens ein Sicherheitsproblem.

Mögliche Ursachen:

Datenbank in Public Subnet
öffentliche IP vergeben
Security Group zu breit
Firewall-Regel erlaubt 0.0.0.0/0
Authentifizierung schwach
kein Private Endpoint
falsches Routing

Besser:

Private Subnet
Zugriff nur von App-Schicht
Security Group gezielt
keine öffentliche IP
Verschlüsselung
starke Authentifizierung

Merksatz:

Datenbanken gehören normalerweise nicht öffentlich ins Internet.

Fehlerbild: Cloud und On-Premises erreichen sich nicht

Mögliche Ursachen:

VPN-Tunnel down
Route in Cloud fehlt
Route lokal fehlt
Firewall blockiert
Security Group blockiert
IP-Netze überschneiden sich
DNS falsch
NAT falsch
Rückroute fehlt
Cloud-Gateway falsch konfiguriert

Merksatz:

Hybrid-Verbindungen brauchen Regeln und Routen auf beiden Seiten.

Checkliste: Cloud-Netzwerk sicher planen

IP-Adressbereich eindeutig wählen.
Subnetze sauber trennen.
Public und Private Subnets unterscheiden.
Datenbanken nicht öffentlich bereitstellen.
Managementzugänge nicht breit öffnen.
Security Groups eng setzen.
Rückwege planen.
Hybrid-Routen dokumentieren.
DNS-Konzept erstellen.
Logging aktivieren.
Monitoring einrichten.
Änderungen dokumentieren.
Rechte zur Netzwerkänderung begrenzen.

Merksatz:

Cloud-Netzwerk zuerst planen,
dann Ressourcen bereitstellen.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Was ist ein virtuelles Netzwerk in der Cloud?
- Was bedeutet VPC?
- Was ist ein Subnetz in der Cloud?
- Was ist der Unterschied zwischen Public Subnet und Private Subnet?
- Was ist ein Internet Gateway?
- Was ist ein NAT-Gateway?
- Wofür nutzt man Routingtabellen in der Cloud?
- Was ist eine Security Group?
- Was ist eine Network ACL?
- Was ist eine NSG?
- Was ist der Unterschied zwischen öffentlicher und privater IP?
- Wofür nutzt man einen Load Balancer?
- Was ist ein Health Check?
- Was ist Cloud Peering?
- Warum ist Peering nicht automatisch transitiv?
- Warum sollte eine Datenbank nicht öffentlich erreichbar sein?
- Wie geht man bei Cloud-Netzwerk-Fehlersuche vor?

Typische Prüfungsfallen

Cloud-Netzwerke sind virtuell,
aber echte Netzplanung bleibt nötig.

VPC und VNet beschreiben virtuelle Cloud-Netze.

Public Subnet ist nicht für alle Systeme geeignet.

Private Subnet schützt vor direkter öffentlicher Erreichbarkeit.

Internet Gateway allein reicht nicht für Zugriff.

NAT-Gateway erlaubt typischerweise ausgehende Verbindungen.

Routingtabellen bestimmen Wege.

Rückroute nicht vergessen.

Security Groups wirken wie virtuelle Firewalls.

Network ACLs können zusätzlich blockieren.

Stateful und stateless unterscheiden.

Öffentliche IP bedeutet höheres Risiko.

Datenbanken nicht öffentlich freigeben.

Load Balancer braucht gesunde Backends.

Health Check muss zum Dienst passen.

Peering ist nicht automatisch transitiv.

Cloud-Firewall ersetzt nicht saubere Segmentierung.

Managementports nicht breit ins Internet öffnen.

Cloud-Netzwerkänderungen sind sicherheitskritisch.

Flow Logs zeigen Metadaten,
nicht vollständige Pakete.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
virtuelles Netzwerk logisch getrenntes Cloud-Netz
VPC Virtual Private Cloud
VNet Virtual Network
Subnetz Teilbereich eines Cloud-Netzes
Public Subnet öffentlich angebundenes Subnetz
Private Subnet internes Subnetz ohne direkte öffentliche Erreichbarkeit
Internet Gateway Verbindung eines Cloud-Netzes zum Internet
NAT-Gateway ausgehender Internetzugriff für private Ressourcen
Routingtabelle Wege zu Zielnetzen
lokale Route Route innerhalb des Cloud-Netzes
Security Group virtuelle Firewall-Regelgruppe
Network ACL Zugriffsliste auf Netzwerk- oder Subnetzebene
NSG Network Security Group
Stateful Rückverkehr wird automatisch zugeordnet
Stateless Rückverkehr muss separat erlaubt werden
öffentliche IP aus dem Internet adressierbare IP
private IP interne Adresse im Cloud-Netz
Load Balancer verteilt Anfragen auf Ziele
Health Check Prüfung der Backend-Gesundheit
Cloud-DNS Namensauflösung für Cloud-Ressourcen
Private DNS-Zone interne DNS-Zone
Public DNS-Zone öffentlich sichtbare DNS-Zone
Peering Verbindung zwischen Cloud-Netzen
Hub-and-Spoke zentrale Netzwerkarchitektur
Cloud-VPN VPN-Verbindung zu Cloud-Netz
Bastion Host gehärteter Sprungserver
Flow Logs Metadaten zu Netzwerkverbindungen

IHK-sichere Kurzformulierung

Cloud-Netzwerke bestehen aus virtuellen Netzwerken wie VPC oder VNet, Subnetzen, Routingtabellen, Security Groups, Network ACLs, Gateways, Load Balancern und DNS. Public Subnets sind für öffentlich erreichbare Komponenten wie Load Balancer oder Bastion Hosts gedacht, während Private Subnets interne Ressourcen wie Datenbanken oder Backends schützen. Ein Internet Gateway verbindet ein Cloud-Netz mit dem Internet, während ein NAT-Gateway privaten Ressourcen ausgehenden Internetzugriff ermöglicht. Security Groups und NSGs wirken als virtuelle Firewall-Regeln. Bei Cloud-Netzwerk-Fehlern müssen DNS, IP-Adressen, Routing, Security Groups, Network ACLs, Load Balancer, Zielsysteme, Host-Firewalls und Rückwege geprüft werden.


Merksätze

Cloud-Netzwerke sind virtuell,
aber echte Netzplanung bleibt nötig.

VPC = Virtual Private Cloud.

VNet = Virtual Network.

Virtuelles Netzwerk ist logisch getrennt.

IP-Bereiche sauber planen.

Cloud-Netze dürfen sich nicht ungewollt überschneiden.

Subnetze strukturieren Cloud-Ressourcen.

Public Subnet für öffentliche Komponenten.

Private Subnet für interne Komponenten.

Datenbank nicht öffentlich erreichbar machen.

Internet Gateway verbindet zum Internet.

NAT-Gateway ermöglicht ausgehenden Zugriff.

Routingtabellen bestimmen Wege.

Standardroute entscheidet bei unbekannten Zielen.

Hybrid Cloud braucht Hin- und Rückrouten.

Security Group ist virtuelle Firewall.

Inbound und Outbound getrennt prüfen.

Stateful merkt sich Verbindungen.

Stateless braucht separate Rückregeln.

Network ACL kann zusätzlich blockieren.

NSG steuert Netzwerkzugriffe.

Öffentliche IP nur wenn nötig.

Private IP für interne Kommunikation.

Load Balancer verteilt Anfragen.

Health Check prüft Backend-Gesundheit.

Cloud-DNS kann öffentlich oder privat sein.

Peering verbindet Cloud-Netze.

Peering ist nicht automatisch transitiv.

Hub-and-Spoke schafft zentrale Kontrolle.

Cloud-VPN braucht Routen beidseitig.

Bastion Host schützt Adminzugriffe.

Managementports nicht breit öffnen.

Segmentierung gilt auch in der Cloud.

IAM beeinflusst Netzwerksicherheit.

Flow Logs zeigen Verbindungsmetadaten.

Cloud-Fehlersuche:
DNS,
Route,
Security Group,
Dienst,
Rückweg.

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.

15.6 Cloud-Speicher, Backup und Datenmanagement

Cloud-Speicher ist Speicherplatz, der als Dienst über ein Netzwerk bereitgestellt wird.

Er wird genutzt für:

- Dateien
- Backups
- Datenbanken
- Archive
- Logs
- Medien
- virtuelle Festplatten
- Anwendungsdaten
- Dokumente
- Wiederherstellung nach Ausfällen

Merksatz:

Cloud-Speicher ist Speicher als Dienst,
aber kein automatisches Backup-Konzept.

Warum Cloud-Speicher wichtig ist

Daten sind für Unternehmen oft wichtiger als die Systeme selbst.

Ein Server kann neu installiert werden.

Aber verlorene Daten können kritisch sein.

Cloud-Speicher hilft bei:

zentraler Speicherung
Skalierung
weltweiter Verfügbarkeit
Backup
Archivierung
Zusammenarbeit
Datenanalyse
Notfallwiederherstellung

Merksatz:

Cloud-Speicher muss nach Datenart,
Zugriff,
Schutzbedarf
und Kosten geplant werden.

Arten von Cloud-Speicher

Die wichtigsten Speicherarten sind:

- Objektspeicher
- Blockspeicher
- Dateispeicher
- Archivspeicher
- Datenbankspeicher
- Backup-Speicher

Merksatz:

Nicht jeder Cloud-Speicher ist für denselben Zweck geeignet.

Objektspeicher

Objektspeicher speichert Daten als Objekte.

Ein Objekt besteht typischerweise aus:

Dateiinhalt
Metadaten
eindeutigem Namen oder Schlüssel

Typische Nutzung:

Backups
Bilder
Videos
Dokumente
Logs
Archivdaten
statische Webseiten
große unstrukturierte Datenmengen

Merksatz:

Objektspeicher eignet sich gut für viele unstrukturierte Dateien.

Objektspeicher einfach erklärt

Bei Objektspeicher denkt man nicht zuerst an Ordner und Laufwerke, sondern an Objekte in einem Speicherbereich.

Beispiel:

Objekt:
rechnung-2026-07.pdf

Metadaten:
Dateityp,
Erstellungsdatum,
Besitzer,
Speicherklasse,
Verschlüsselung

Schlüssel:
kunden/2026/rechnung-2026-07.pdf

Merksatz:

Objektspeicher arbeitet mit Objekten,
Schlüsseln
und Metadaten.

Bucket

Ein Bucket ist ein Speicherbehälter im Objektspeicher.

Darin liegen Objekte.

Beispiele:

backup-produktiv

dokumente-intern

logs-archiv

bilder-webseite

Wichtig:

Bucket-Berechtigungen sind sicherheitskritisch.

Merksatz:

Bucket = Speicherbehälter für Objekte.

Bucket-Berechtigungen

Ein häufiger Cloud-Fehler:

Bucket ist öffentlich lesbar.

Mögliche Folgen:

vertrauliche Daten werden öffentlich
personenbezogene Daten werden offengelegt
Backups können heruntergeladen werden
interne Dokumente sind sichtbar
Angreifer finden Zugangsdaten oder Logs

Merksatz:

Öffentliche Buckets sind ein großes Sicherheitsrisiko.

Objektspeicher: Vorteile

Vorteile:

sehr skalierbar
gut für große Datenmengen
Metadaten möglich
oft hohe Haltbarkeit
verschiedene Speicherklassen
gut für Backup und Archiv
Zugriff über APIs
Versionierung möglich

Merksatz:

Objektspeicher ist stark bei Skalierung und unstrukturierten Daten.

Objektspeicher: Nachteile

Nachteile:

nicht wie eine klassische Festplatte
nicht ideal für jede Anwendung
Latenz kann höher sein
Zugriff meist über API
Rechte müssen sauber gesetzt werden
Kosten für Zugriff und Datenübertragung beachten

Merksatz:

Objektspeicher ist kein direkter Ersatz für jedes Dateisystem.

Blockspeicher

Blockspeicher stellt Speicherblöcke bereit, ähnlich wie eine Festplatte.

Typische Nutzung:

virtuelle Maschinen
Betriebssystemplatten
Datenbankserver
Anwendungen mit Dateisystem
leistungsabhängige Workloads

Beispiele:

virtuelle Systemplatte
virtuelle Datenplatte
Datenbankvolume

Merksatz:

Blockspeicher verhält sich wie eine virtuelle Festplatte.

Blockspeicher: Vorteile

Vorteile:

gut für Betriebssysteme
gut für Datenbanken
geringe Latenz möglich
Dateisystem frei wählbar
an virtuelle Maschinen anbindbar
Leistung oft wählbar

Merksatz:

Blockspeicher eignet sich für VMs und leistungsabhängige Anwendungen.

Blockspeicher: Nachteile

Nachteile:

meist an einzelne Instanzen gebunden
Verwaltung von Dateisystem bleibt nötig
falsche Größe oder Leistung kann Kosten erzeugen
Backup muss geplant werden
nicht ideal für einfache Dateifreigaben zwischen vielen Systemen

Merksatz:

Blockspeicher braucht Administration wie eine Festplatte.

Dateispeicher

Dateispeicher stellt Speicher als Dateifreigabe bereit.

Typische Nutzung:

gemeinsame Dateien
klassische Ordnerstrukturen
Benutzerdateien
Anwendungen mit gemeinsamem Dateisystem
zentrale Ablagen

Typische Protokolle:

SMB
NFS

Merksatz:

Dateispeicher arbeitet mit Ordnern,
Dateien
und Freigaben.

Dateispeicher: Vorteile

Vorteile:

bekannte Ordnerstruktur
gemeinsame Nutzung möglich
geeignet für klassische Anwendungen
SMB oder NFS möglich
einfache Integration in viele Systeme

Merksatz:

Dateispeicher passt gut zu klassischen Freigaben.

Dateispeicher: Nachteile

Nachteile:

Berechtigungen müssen sauber geplant werden
Performance abhängig von Dienst und Netzwerk
nicht immer so skalierbar wie Objektspeicher
Kosten für Kapazität und Leistung beachten
Backup und Versionierung prüfen

Merksatz:

Cloud-Dateifreigaben brauchen Rechtekonzept und Backup.

Objekt-, Block- und Dateispeicher vergleichen

Speicherart Typischer Einsatz Vergleich
Objektspeicher Backups, Medien, Archive, Logs Objekt mit Metadaten
Blockspeicher VM-Festplatten, Datenbanken virtuelle Festplatte
Dateispeicher gemeinsame Dateien, klassische Freigaben Ordner und Dateien

Merksatz:

Objekt für große Datenmengen,
Block für VM und Datenbank,
Datei für Freigaben.

Archivspeicher

Archivspeicher ist für Daten gedacht, die selten benötigt werden.

Beispiele:

alte Backups
Langzeitarchive
gesetzliche Aufbewahrung
abgeschlossene Projekte
alte Logs
historische Dokumente

Vorteil:

oft günstiger für langfristige Speicherung

Nachteil:

Wiederherstellung kann länger dauern
Zugriff kann teurer sein
Mindestaufbewahrungszeiten möglich

Merksatz:

Archivspeicher ist günstig für selten genutzte Daten,
aber langsamer beim Zugriff.

Hot, Cool und Archive Storage

Viele Cloud-Anbieter unterscheiden Speicherklassen.

Typische Idee:

Speicherklasse Nutzung
Hot häufig genutzte Daten
Cool selten genutzte Daten
Archive sehr selten genutzte Langzeitdaten

Merksatz:

Je seltener der Zugriff,
desto günstiger oft die Speicherung,
aber desto teurer oder langsamer der Zugriff.

Lifecycle Management

Lifecycle Management bedeutet:

Daten werden automatisch nach Regeln verschoben oder gelöscht.

Beispiele:

Logs nach 30 Tagen in günstigere Speicherklasse verschieben.

Backups nach 1 Jahr archivieren.

temporäre Dateien nach 7 Tagen löschen.

alte Versionen nach 90 Tagen entfernen.

Merksatz:

Lifecycle-Regeln steuern den Lebenszyklus von Daten.

Versionierung

Versionierung bedeutet:

ältere Versionen einer Datei oder eines Objekts werden aufbewahrt.

Vorteile:

Wiederherstellung nach versehentlicher Änderung
Schutz vor Überschreiben
Hilfe bei Ransomware
Nachvollziehbarkeit

Aber:

Versionen verbrauchen Speicher
Kosten können steigen
Löschregeln müssen geplant werden

Merksatz:

Versionierung schützt vor Änderungen,
braucht aber Speicher- und Löschkonzept.

Snapshots

Ein Snapshot ist eine Momentaufnahme eines Systems oder Speichers.

Typische Nutzung:

VM-Zustand sichern
Volume-Zustand sichern
vor Update erstellen
schnelle Wiederherstellung
Testumgebung aus Produktivdaten erzeugen

Wichtig:

Snapshots sind nicht immer vollständiger Backup-Ersatz.

Merksatz:

Snapshot ist Momentaufnahme,
aber nicht automatisch Backup-Strategie.

Backup

Backup bedeutet:

Daten werden zusätzlich gesichert,
damit sie bei Verlust wiederhergestellt werden können.

Backup schützt vor:

versehentlichem Löschen
Hardwareausfall
Fehlkonfiguration
Ransomware
Datenkorruption
Benutzerfehler
fehlerhaften Updates
Ausfall eines Dienstes

Merksatz:

Backup ist nur wertvoll,
wenn Wiederherstellung funktioniert.

Cloud ist kein Backup

Ein häufiger Denkfehler:

Die Daten liegen in der Cloud,
also brauche ich kein Backup.

Das ist falsch.

Auch in der Cloud können Daten verloren gehen durch:

Benutzerfehler
falsche Synchronisation
Ransomware
gelöschte Benutzer
kompromittierte Adminzugänge
Fehlkonfiguration
abgelaufene Aufbewahrung
defekte Anwendung
Anbieterproblem

Merksatz:

Cloud-Speicherung ersetzt kein Backup-Konzept.

Backup-Ziele

Ein Backup-Konzept muss klären:

Was wird gesichert?
Wie oft wird gesichert?
Wie lange wird gesichert?
Wo wird gesichert?
Wer darf wiederherstellen?
Wie wird Wiederherstellung getestet?
Wie wird Backup geschützt?
Wie schnell muss Wiederherstellung sein?
Wie viel Datenverlust ist tolerierbar?

Merksatz:

Backup ohne Wiederherstellungsziel ist unvollständig.

RPO

RPO steht für:

Recovery Point Objective

RPO beschreibt, wie viel Datenverlust maximal akzeptabel ist.

Beispiel:

RPO = 24 Stunden

Bedeutung:

Im schlimmsten Fall dürfen Daten der letzten 24 Stunden verloren gehen.

Merksatz:

RPO fragt:
Wie viel Datenverlust ist erlaubt?

RTO

RTO steht für:

Recovery Time Objective

RTO beschreibt, wie schnell ein System wiederhergestellt sein muss.

Beispiel:

RTO = 4 Stunden

Bedeutung:

Das System soll innerhalb von 4 Stunden wieder verfügbar sein.

Merksatz:

RTO fragt:
Wie lange darf Wiederherstellung dauern?

RPO und RTO vergleichen

Begriff Frage Beispiel
RPO Wie viel Datenverlust ist erlaubt? maximal 1 Stunde Datenverlust
RTO Wie lange darf Ausfall dauern? Wiederherstellung in 4 Stunden

Merksatz:

RPO betrifft Datenverlust.
RTO betrifft Ausfallzeit.

Backup-Arten

Wichtige Backup-Arten:

Vollbackup
inkrementelles Backup
differentielles Backup
Snapshot
Replikation
Archivierung

Merksatz:

Backup-Art beeinflusst Speicherbedarf,
Dauer
und Wiederherstellung.

Vollbackup

Ein Vollbackup sichert alle ausgewählten Daten vollständig.

Vorteile:

einfache Wiederherstellung
vollständiger Sicherungsstand
unabhängig von vielen Zwischenschritten

Nachteile:

hoher Speicherbedarf
längere Sicherungsdauer
mehr Last

Merksatz:

Vollbackup ist vollständig,
aber aufwendiger.

Inkrementelles Backup

Ein inkrementelles Backup sichert nur Änderungen seit dem letzten Backup.

Vorteile:

weniger Speicherbedarf
schneller als Vollbackup
weniger Datenübertragung

Nachteile:

Wiederherstellung kann mehrere Sicherungen benötigen
Backup-Kette muss intakt sein

Merksatz:

Inkrementell sichert nur neue Änderungen seit dem letzten Backup.

Differentielles Backup

Ein differentielles Backup sichert Änderungen seit dem letzten Vollbackup.

Vorteile:

Wiederherstellung einfacher als bei langen inkrementellen Ketten
weniger aufwendig als tägliches Vollbackup

Nachteile:

wächst bis zum nächsten Vollbackup
braucht mehr Speicher als inkrementell

Merksatz:

Differentiell sichert Änderungen seit dem letzten Vollbackup.

Replikation

Replikation bedeutet:

Daten werden auf ein anderes System oder in eine andere Region kopiert.

Ziel:

höhere Verfügbarkeit
schnellere Umschaltung
Schutz vor Standortausfall

Aber:

Replikation ist nicht automatisch Backup.

Warum?

Fehler,
Löschungen
oder Ransomware können mit repliziert werden.

Merksatz:

Replikation schützt Verfügbarkeit,
Backup schützt Wiederherstellung.

Backup und Replikation vergleichen

Merkmal Backup Replikation
Zweck Wiederherstellung alter Stände Verfügbarkeit und Kopie
schützt vor Löschen ja, wenn richtig aufbewahrt nicht unbedingt
schützt vor Ransomware ja, wenn isoliert oder unveränderlich nicht unbedingt
Zugriff meist Wiederherstellung nötig oft direkt nutzbar
Risiko Backup zu alt Fehler wird mitkopiert

Merksatz:

Replikation ist kein Ersatz für Backup.

3-2-1-Regel

Die 3-2-1-Regel ist eine bekannte Backup-Grundregel.

Sie bedeutet:

3 Kopien der Daten

2 unterschiedliche Speichermedien oder Speicherarten

1 Kopie außer Haus oder getrennt vom Hauptsystem

Für Cloud kann man ergänzen:

eine Kopie unveränderlich oder besonders geschützt

Merksatz:

Mehrere getrennte Kopien schützen besser vor Datenverlust.

Immutable Backup

Immutable bedeutet:

unveränderlich

Ein Immutable Backup kann für eine festgelegte Zeit nicht verändert oder gelöscht werden.

Vorteile:

Schutz vor Ransomware
Schutz vor versehentlicher Löschung
Schutz vor kompromittierten Konten
bessere Wiederherstellungschance

Merksatz:

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

Air Gap

Air Gap bedeutet:

Eine Sicherung ist vom produktiven System getrennt.

Klassisch:

offline gelagertes Backup

In Cloud-Konzepten:

logisch getrennte Konten
getrennte Berechtigungen
unveränderliche Backups
getrennte Regionen
separate Backup-Tenants

Merksatz:

Air Gap bedeutet Trennung vom normalen Zugriffspfad.

Backup-Verschlüsselung

Backups enthalten oft sehr sensible Daten.

Deshalb sollten Backups verschlüsselt werden.

Wichtig:

Schlüssel sicher verwalten
Zugriff begrenzen
Wiederherstellung testen
Schlüsselverlust vermeiden
Schlüsselrotation planen

Merksatz:

Verschlüsseltes Backup ist nur nutzbar,
wenn Schlüssel verfügbar sind.

Backup-Zugriffsrechte

Nicht jeder Administrator sollte Backups löschen dürfen.

Wichtige Regeln:

getrennte Backup-Adminrolle
Wiederherstellung nur berechtigte Personen
Löschung stark begrenzen
MFA für Backupverwaltung
Protokollierung
Genehmigung bei kritischen Aktionen

Merksatz:

Wer Backups löschen kann,
kann Wiederherstellung verhindern.

Restore

Restore bedeutet:

Daten werden aus einem Backup wiederhergestellt.

Mögliche Arten:

einzelne Datei wiederherstellen
gesamtes Verzeichnis wiederherstellen
Datenbank wiederherstellen
VM wiederherstellen
Anwendung wiederherstellen
System in anderer Region wiederherstellen

Merksatz:

Backup ohne getesteten Restore ist unsicher.

Restore-Test

Ein Restore-Test prüft, ob eine Wiederherstellung wirklich funktioniert.

Warum wichtig?

Backup könnte unvollständig sein.
Rechte könnten fehlen.
Schlüssel könnten fehlen.
Wiederherstellung dauert zu lange.
Anwendung startet nicht.
Daten sind inkonsistent.

Merksatz:

Erst Restore-Test zeigt,
ob Backup wirklich brauchbar ist.

Datenkonsistenz

Datenkonsistenz bedeutet:

Daten sind logisch korrekt und zusammenpassend.

Problem:

Wenn eine Datenbank während des Backups verändert wird,
kann ein einfaches Dateibackup inkonsistent sein.

Lösung:

anwendungskonsistente Backups
Datenbank-Dumps
Snapshots mit Quiescing
Transaktionslogs
passende Backup-Agenten

Merksatz:

Datenbanken brauchen konsistente Backups.

Datenbank-Backup

Datenbanken brauchen besondere Backup-Verfahren.

Wichtige Punkte:

konsistenter Zustand
Transaktionslogs
Point-in-Time-Recovery
regelmäßige Restore-Tests
Verschlüsselung
Aufbewahrung
Rechtekontrolle

Merksatz:

Datenbankdateien einfach kopieren reicht oft nicht.

Point-in-Time-Recovery

Point-in-Time-Recovery bedeutet:

Wiederherstellung auf einen bestimmten Zeitpunkt.

Beispiel:

Datenbankzustand von gestern 14:35 Uhr wiederherstellen.

Nützlich bei:

versehentlicher Löschung
fehlerhaftem Import
falschem Update
Ransomware
Datenkorruption

Merksatz:

Point-in-Time-Recovery stellt gezielt einen Zeitpunkt wieder her.

Aufbewahrungsfrist

Aufbewahrungsfrist bedeutet:

Wie lange Daten oder Backups gespeichert werden.

Beispiele:

tägliche Backups 30 Tage
monatliche Backups 12 Monate
Jahresarchive 10 Jahre

Wichtig:

technische Anforderungen
rechtliche Vorgaben
Datenschutz
Speicherplatz
Kosten

Merksatz:

Aufbewahrung muss fachlich,
rechtlich
und technisch passen.

Löschkonzept

Ein Löschkonzept beschreibt, wann Daten gelöscht werden.

Wichtig bei:

personenbezogenen Daten
alten Backups
Projektarchiven
Logs
temporären Dateien
Testdaten
Benutzerkonten

Merksatz:

Daten dürfen nicht unbegrenzt ohne Zweck gespeichert werden.

Datenklassifizierung

Datenklassifizierung bedeutet:

Daten werden nach Schutzbedarf eingeteilt.

Beispiele:

öffentlich
intern
vertraulich
streng vertraulich
personenbezogen
geschäftskritisch

Die Klasse bestimmt:

Speicherort
Verschlüsselung
Zugriff
Backup
Aufbewahrung
Logging
Freigaben

Merksatz:

Datenklasse bestimmt Schutzmaßnahmen.

Personenbezogene Daten

Personenbezogene Daten sind Daten, die sich auf eine identifizierte oder identifizierbare Person beziehen.

Beispiele:

Name
Adresse
E-Mail-Adresse
Kundennummer
Personalnummer
IP-Adresse je nach Kontext
Gesundheitsdaten
Bewerbungsdaten

Merksatz:

Personenbezogene Daten brauchen besonderen Schutz.

Datenminimierung

Datenminimierung bedeutet:

Nur Daten speichern,
die wirklich benötigt werden.

Cloud-Bezug:

keine unnötigen Kopien
keine unnötigen Exporte
keine unnötigen Logs mit Personendaten
keine ewigen Testdaten
keine Vollkopien für einfache Tests

Merksatz:

Weniger unnötige Daten bedeuten weniger Risiko.

Datenresidenz

Datenresidenz bedeutet:

Daten müssen in einem bestimmten Land oder einer bestimmten Region gespeichert werden.

Beispiel:

Speicherung innerhalb der EU

Wichtig für:

Datenschutz
Compliance
Verträge
Kundenanforderungen
Branchenvorgaben

Merksatz:

Datenresidenz beschreibt,
wo Daten liegen dürfen.

Datenhoheit

Datenhoheit bedeutet:

Wer Kontrolle über Daten hat.

Fragen:

Wer darf Daten lesen?
Wer darf Daten löschen?
Wer darf Daten exportieren?
Wer verwaltet Schlüssel?
Wer kann Zugriff technisch erzwingen?
Was passiert bei Anbieterwechsel?

Merksatz:

Datenhoheit ist Kontrolle über Zugriff,
Nutzung
und Verbleib von Daten.

Datenportabilität

Datenportabilität bedeutet:

Daten können in ein anderes System übertragen werden.

Wichtig:

Exportfunktion
offenes Format
vollständige Daten
Metadaten
Berechtigungen
Dokumentation
Wiederimport möglich

Merksatz:

Datenportabilität ist wichtig für Anbieterwechsel und Exit-Strategie.

Exit-Strategie für Daten

Eine Exit-Strategie beschreibt, wie Daten aus einem Cloud-Dienst wieder herauskommen.

Fragen:

Wie werden Daten exportiert?
In welchem Format?
Wie lange dauert Export?
Welche Kosten entstehen?
Werden Metadaten mit exportiert?
Werden Berechtigungen mit exportiert?
Wie wird Löschung beim Anbieter bestätigt?

Merksatz:

Cloud-Einstieg braucht auch Daten-Ausstiegsplan.

Cloud-Synchronisation

Cloud-Synchronisation hält Daten zwischen Geräten oder Diensten auf gleichem Stand.

Beispiele:

Datei auf Notebook geändert
Änderung wird in Cloud synchronisiert
andere Geräte erhalten Änderung

Risiko:

versehentliche Löschung wird synchronisiert
Ransomware verschlüsselt Dateien und Änderung wird synchronisiert
falsche Version überschreibt richtige Version

Merksatz:

Synchronisation ist kein Backup.

Cloud-Speicher und Ransomware

Ransomware kann auch Cloud-Speicher betreffen.

Beispiele:

verschlüsselte Dateien werden synchronisiert
Angreifer löscht Backups
kompromittiertes Konto löscht Daten
API-Schlüssel wird missbraucht
Versionen werden entfernt

Schutz:

MFA
Versionierung
Immutable Backup
getrennte Backup-Konten
Least Privilege
Monitoring
Restore-Tests

Merksatz:

Cloud-Speicher braucht Ransomware-Schutz.

Freigaben in Cloud-Speicher

Cloud-Speicher bietet oft einfache Freigaben.

Risiken:

Merksatz:

Cloud-Freigaben regelmäßig prüfen.

Externe Freigaben

Externe Freigaben erlauben Zugriff außerhalb der Organisation.

Sicherheitsregeln:

nur bei Bedarf
zeitlich begrenzen
Empfänger prüfen
Passwort oder MFA nutzen
Download einschränken
Protokollierung aktivieren
Freigaben regelmäßig entfernen

Merksatz:

Externe Freigaben sind kontrollierter Extranet-Zugriff.

Cloud-Speicher und Berechtigungen

Berechtigungen sollten festlegen:

Wer darf lesen?
Wer darf schreiben?
Wer darf löschen?
Wer darf freigeben?
Wer darf externe Benutzer einladen?
Wer darf Versionen löschen?
Wer darf Aufbewahrung ändern?

Merksatz:

Speicherrechte müssen genauer sein als nur „Zugriff erlaubt“.

Cloud-Speicher und Logs

Wichtige Logs:

Datei gelesen
Datei geändert
Datei gelöscht
Datei geteilt
externer Zugriff
Download
Adminänderung
Berechtigung geändert
Version gelöscht
Aufbewahrung geändert

Merksatz:

Speicherlogs helfen,
Datenzugriffe nachvollziehbar zu machen.

Cloud-Speicher und Kosten

Kosten entstehen durch:

Speichergröße
Speicherklasse
Anzahl der Zugriffe
Datenübertragung
Wiederherstellung aus Archiv
Versionen
Snapshots
Backups
Replikation
Logs

Merksatz:

Cloud-Speicher ist skalierbar,
aber nicht automatisch billig.

Typische Cloud-Speicherfehler

Häufige Fehler:

Bucket öffentlich lesbar
keine Versionierung
keine Backups
keine Restore-Tests
zu lange Aufbewahrung
keine Löschregeln
falsche Speicherklasse
alte Snapshots vergessen
API-Schlüssel im Speicher
externe Freigaben nicht geprüft
Backups im gleichen Konto wie Produktivdaten ungeschützt
keine Verschlüsselung
keine Logs

Merksatz:

Cloud-Speicherfehler entstehen oft durch Rechte,
Freigaben,
Aufbewahrung
und fehlende Tests.

Checkliste: Cloud-Speicher sicher nutzen

Speicherart passend auswählen.
Daten klassifizieren.
Öffentliche Zugriffe vermeiden.
Berechtigungen minimal vergeben.
MFA für Admins erzwingen.
Versionierung prüfen.
Backup einrichten.
Immutable Backup prüfen.
Wiederherstellung testen.
Verschlüsselung aktivieren.
Schlüsselverwaltung klären.
Aufbewahrungsfristen festlegen.
Löschkonzept erstellen.
Lifecycle-Regeln nutzen.
Logs aktivieren.
Kosten überwachen.
Externe Freigaben regelmäßig prüfen.

Merksatz:

Cloud-Speicher braucht Technik,
Rechte,
Backup
und Kostenkontrolle.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Was ist Objektspeicher?
- Was ist Blockspeicher?
- Was ist Dateispeicher?
- Wofür nutzt man Archivspeicher?
- Was ist ein Bucket?
- Warum sind öffentliche Buckets gefährlich?
- Was bedeutet Versionierung?
- Was ist ein Snapshot?
- Warum ist Cloud-Speicher kein automatisches Backup?
- Was ist der Unterschied zwischen Backup und Replikation?
- Was bedeutet RPO?
- Was bedeutet RTO?
- Was ist die 3-2-1-Regel?
- Was ist ein Immutable Backup?
- Warum sind Restore-Tests wichtig?
- Was ist Point-in-Time-Recovery?
- Was bedeutet Datenklassifizierung?
- Was bedeutet Datenresidenz?
- Warum ist Synchronisation kein Backup?
- Warum müssen externe Freigaben geprüft werden?

Typische Prüfungsfallen

Cloud-Speicher ist nicht automatisch Backup.

Synchronisation ist kein Backup.

Replikation ist kein Backup.

Snapshot ist nicht immer vollständiger Backup-Ersatz.

Backup ohne Restore-Test ist unsicher.

Objektspeicher ist nicht dasselbe wie Blockspeicher.

Blockspeicher ist eher virtuelle Festplatte.

Dateispeicher ist eher klassische Freigabe.

Bucket-Berechtigungen sind sicherheitskritisch.

Öffentliche Buckets vermeiden.

RPO betrifft Datenverlust.

RTO betrifft Wiederherstellungszeit.

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

Backups müssen verschlüsselt und geschützt sein.

Datenbanken brauchen konsistente Backups.

Datenklassifizierung bestimmt Schutzmaßnahmen.

Datenresidenz beschreibt Speicherort.

Datenportabilität ist wichtig für Anbieterwechsel.

Externe Freigaben regelmäßig prüfen.

Cloud-Speicher verursacht auch Zugriffskosten,
Versionierungskosten
und Wiederherstellungskosten.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
Cloud-Speicher Speicher als Dienst
Objektspeicher Speicher für Objekte mit Metadaten
Blockspeicher Speicher wie virtuelle Festplatte
Dateispeicher Speicher als Ordner- und Dateifreigabe
Archivspeicher Speicher für selten genutzte Langzeitdaten
Bucket Speicherbehälter für Objekte
Metadaten beschreibende Zusatzinformationen
Speicherklasse Kosten- und Zugriffskategorie
Lifecycle Management automatische Regeln für Verschieben oder Löschen
Versionierung Aufbewahrung früherer Dateiversionen
Snapshot Momentaufnahme eines Systems oder Speichers
Backup zusätzliche Sicherung zur Wiederherstellung
Restore Wiederherstellung aus Backup
Restore-Test Prüfung der Wiederherstellung
RPO maximal akzeptabler Datenverlust
RTO maximal akzeptable Wiederherstellungszeit
Vollbackup vollständige Sicherung
inkrementelles Backup Änderungen seit letztem Backup
differentielles Backup Änderungen seit letztem Vollbackup
Replikation Kopie auf anderes System oder Region
3-2-1-Regel drei Kopien, zwei Medien, eine getrennte Kopie
Immutable Backup unveränderliches Backup
Air Gap getrennte Sicherung
Point-in-Time-Recovery Wiederherstellung auf bestimmten Zeitpunkt
Aufbewahrungsfrist Speicherdauer von Daten
Löschkonzept Regelung zur Datenlöschung
Datenklassifizierung Einteilung nach Schutzbedarf
Datenresidenz Ort der Datenspeicherung
Datenhoheit Kontrolle über Daten
Datenportabilität Übertragbarkeit von Daten
Exit-Strategie Plan zum Verlassen eines Dienstes
Synchronisation Abgleich von Datenständen

IHK-sichere Kurzformulierung

Cloud-Speicher stellt Speicherplatz als Dienst bereit. Man unterscheidet vor allem Objektspeicher, Blockspeicher und Dateispeicher. Objektspeicher eignet sich für unstrukturierte Daten wie Backups, Medien, Logs und Archive. Blockspeicher wird häufig wie eine virtuelle Festplatte für virtuelle Maschinen oder Datenbanken genutzt. Dateispeicher stellt klassische Datei- und Ordnerfreigaben bereit. Cloud-Speicher ersetzt kein Backup-Konzept, da Löschungen, Fehlkonfigurationen, Ransomware oder falsche Synchronisation auch Cloud-Daten betreffen können. Wichtige Backup-Kennzahlen sind RPO für maximal tolerierbaren Datenverlust und RTO für maximal tolerierbare Wiederherstellungszeit. Backups müssen geschützt, verschlüsselt, regelmäßig getestet und passend aufbewahrt werden.


Merksätze

Cloud-Speicher = Speicher als Dienst.

Nicht jeder Speicher passt zu jedem Zweck.

Objektspeicher speichert Objekte mit Metadaten.

Bucket = Speicherbehälter.

Öffentliche Buckets sind gefährlich.

Blockspeicher = virtuelle Festplatte.

Dateispeicher = klassische Freigabe.

Archivspeicher für selten genutzte Daten.

Hot Storage für häufige Zugriffe.

Archive Storage für seltene Zugriffe.

Lifecycle-Regeln steuern Datenlebenszyklus.

Versionierung schützt vor Überschreiben.

Snapshot ist Momentaufnahme.

Snapshot ist nicht automatisch Backup-Strategie.

Cloud ist kein Backup.

Synchronisation ist kein Backup.

Replikation ist kein Backup.

Backup schützt Wiederherstellung.

Replikation schützt eher Verfügbarkeit.

RPO = erlaubter Datenverlust.

RTO = erlaubte Wiederherstellungszeit.

Vollbackup sichert alles.

Inkrementell sichert Änderungen seit letztem Backup.

Differentiell sichert Änderungen seit letztem Vollbackup.

3-2-1-Regel schützt besser vor Datenverlust.

Immutable Backup schützt vor Löschung.

Air Gap trennt Backup vom Hauptsystem.

Backup-Schlüssel sicher verwalten.

Restore-Test ist Pflicht.

Datenbanken brauchen konsistente Backups.

Point-in-Time-Recovery stellt Zeitpunkt wieder her.

Aufbewahrung und Löschung planen.

Datenklassifizierung bestimmt Schutz.

Datenresidenz beschreibt Speicherort.

Datenportabilität für Anbieterwechsel beachten.

Cloud-Freigaben regelmäßig prüfen.

Speicherlogs aktivieren.

Cloud-Speicher-Kosten überwachen.

15.7 Cloud-Betrieb, Monitoring, Skalierung und Kostenkontrolle

Cloud-Dienste müssen auch nach der Einrichtung betrieben, überwacht und optimiert werden.

Cloud bedeutet nicht:

einmal erstellen
und nie wieder anfassen

Cloud-Betrieb umfasst:

- Monitoring
- Logging
- Alarmierung
- Kostenkontrolle
- Skalierung
- Patchmanagement
- Backup-Prüfung
- Sicherheitsprüfung
- Rechteprüfung
- Dokumentation
- Automatisierung
- Störungsbehandlung

Merksatz:

Cloud-Ressourcen brauchen laufenden Betrieb wie lokale IT-Systeme.

Warum Cloud-Betrieb wichtig ist

Cloud-Ressourcen lassen sich schnell erstellen.

Das ist ein Vorteil, kann aber auch ein Risiko sein.

Typische Probleme:

Ressourcen werden vergessen.
Kosten steigen unbemerkt.
Logs sind nicht aktiviert.
Backups werden nicht getestet.
Sicherheitsregeln sind zu breit.
Benutzerrechte bleiben zu lange bestehen.
Dienste laufen dauerhaft,
obwohl sie nicht mehr gebraucht werden.

Merksatz:

Cloud-Flexibilität braucht Kontrolle.

Cloud-Betrieb einfach erklärt

Beim Cloud-Betrieb geht es darum, Cloud-Dienste dauerhaft zuverlässig, sicher und wirtschaftlich zu betreiben.

Dazu gehören Fragen wie:

Läuft der Dienst?
Ist der Dienst erreichbar?
Ist die Leistung ausreichend?
Gibt es Sicherheitsereignisse?
Werden Kosten eingehalten?
Funktionieren Backups?
Sind Ressourcen richtig dimensioniert?
Sind Rechte korrekt?
Gibt es unnötige Ressourcen?

Merksatz:

Cloud-Betrieb verbindet Technik,
Sicherheit
und Kosten.

Monitoring

Monitoring bedeutet:

Systeme und Dienste werden laufend überwacht.

Ziel:

Probleme früh erkennen,
bevor Benutzer stark betroffen sind.

Überwacht werden zum Beispiel:

Verfügbarkeit
CPU-Auslastung
RAM-Auslastung
Speicherplatz
Netzwerkverkehr
Antwortzeiten
Fehlerquoten
Datenbanklast
Zertifikatsablauf
Backupstatus
Kosten

Merksatz:

Monitoring zeigt,
ob Systeme gesund laufen.

Metriken

Metriken sind messbare Werte.

Beispiele:

CPU in Prozent
RAM-Verbrauch
freier Speicherplatz
Anfragen pro Sekunde
Antwortzeit in Millisekunden
Fehlerrate
Netzwerkdurchsatz
Anzahl aktiver Benutzer
Datenbankverbindungen
Warteschlangenlänge

Merksatz:

Metriken liefern messbare Zustandswerte.

Logs

Logs sind Ereignisprotokolle.

Sie zeigen, was in einem System passiert ist.

Beispiele:

Benutzeranmeldung
API-Aufruf
Fehler in Anwendung
Firewall blockiert Verbindung
Admin ändert Rolle
Backup schlägt fehl
Datenbank meldet Fehler
Ressource wird gelöscht

Merksatz:

Logs zeigen Ereignisse und helfen bei Fehlersuche.

Monitoring und Logging unterscheiden

Begriff Frage Beispiel
Monitoring Wie geht es dem System gerade? CPU 90 %, Dienst nicht erreichbar
Logging Was ist passiert? Benutzer hat Firewall-Regel geändert

Merksatz:

Monitoring zeigt Zustand.
Logs zeigen Ereignisse.

Alarmierung

Alarmierung bedeutet:

Bei bestimmten Ereignissen oder Grenzwerten wird automatisch gewarnt.

Beispiele:

CPU über 90 %
Speicher fast voll
Dienst nicht erreichbar
Backup fehlgeschlagen
viele fehlgeschlagene Logins
Kostenlimit fast erreicht
Zertifikat läuft bald ab
ungewöhnlich viel Datenverkehr

Merksatz:

Alarmierung macht Probleme sichtbar,
bevor sie übersehen werden.

Schwellwert

Ein Schwellwert ist ein Grenzwert, ab dem eine Aktion ausgelöst wird.

Beispiel:

Wenn CPU länger als 10 Minuten über 85 % liegt,
Alarm auslösen.

Oder:

Wenn Monatskosten 80 % des Budgets erreichen,
Warnung senden.

Merksatz:

Schwellwerte steuern,
wann gewarnt oder reagiert wird.

Alert Fatigue

Alert Fatigue bedeutet:

Es gibt so viele Alarme,
dass wichtige Alarme übersehen werden.

Ursachen:

zu niedrige Schwellwerte
zu viele unwichtige Alarme
keine Priorisierung
Alarme ohne Handlungsempfehlung
wiederholte Fehlalarme

Schutz:

Alarme sinnvoll priorisieren
nur relevante Alarme erstellen
klare Zuständigkeiten festlegen
Alarme regelmäßig überprüfen

Merksatz:

Zu viele schlechte Alarme sind selbst ein Problem.

Dashboard

Ein Dashboard zeigt wichtige Betriebswerte übersichtlich an.

Beispiele:

Verfügbarkeit
Auslastung
Fehlerquote
Kosten
offene Alarme
Backupstatus
Zertifikate
Sicherheitsereignisse
aktive Ressourcen

Merksatz:

Dashboard = Überblick über wichtige Zustände.

Cloud-Logging aktivieren

Viele Cloud-Dienste erzeugen Logs nur dann vollständig, wenn Logging aktiviert oder richtig konfiguriert ist.

Wichtig:

Audit-Logs aktivieren
Netzwerklogs aktivieren
Anwendungslogs aktivieren
Firewall-Logs aktivieren
Load-Balancer-Logs aktivieren
Aufbewahrung festlegen
Zugriff auf Logs schützen

Merksatz:

Nicht vorhandene Logs helfen im Fehlerfall nicht.

Audit-Logs

Audit-Logs dokumentieren administrative Aktionen.

Beispiele:

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

Merksatz:

Audit-Logs zeigen,
wer was wann geändert hat.

Flow Logs

Flow Logs zeigen Netzwerkverbindungen als Metadaten.

Typische Angaben:

Quelle
Ziel
Port
Protokoll
Zeit
Aktion
Datenmenge
Schnittstelle

Wichtig:

Flow Logs zeigen meist nicht den vollständigen Inhalt der Pakete.

Merksatz:

Flow Logs helfen bei Netzwerk- und Firewall-Analyse.

Log-Aufbewahrung

Logs sollten nicht beliebig kurz oder beliebig lange gespeichert werden.

Zu klären:

Wie lange werden Logs benötigt?
Gibt es rechtliche Vorgaben?
Enthalten Logs personenbezogene Daten?
Wer darf Logs lesen?
Wie werden Logs geschützt?
Wann werden Logs gelöscht?

Merksatz:

Log-Aufbewahrung braucht Sicherheits- und Datenschutzkonzept.

Zentrales Logging

Bei mehreren Cloud-Diensten sollten Logs zentral gesammelt werden.

Vorteile:

bessere Übersicht
einfachere Suche
Korrelation von Ereignissen
Sicherheitsanalyse
Nachvollziehbarkeit
Alarmierung
weniger Insellösungen

Merksatz:

Zentrales Logging erleichtert Betrieb und Sicherheitsanalyse.

SIEM

SIEM steht für:

Security Information and Event Management

Ein SIEM sammelt Sicherheitslogs aus verschiedenen Quellen und wertet sie aus.

Ziel:

Angriffe erkennen
verdächtige Muster finden
Alarme erzeugen
Ereignisse korrelieren
Nachweise liefern

Merksatz:

SIEM hilft bei zentraler Sicherheitsüberwachung.

Cloud-Kostenkontrolle

Cloud-Kosten können schnell steigen, wenn Ressourcen unkontrolliert genutzt werden.

Kosten entstehen zum Beispiel durch:

laufende virtuelle Maschinen
Speicher
Datenbanken
Backups
Snapshots
Netzwerkverkehr
Load Balancer
öffentliche IP-Adressen
Logs
Monitoring
Lizenzen
Support
Datenübertragung zwischen Regionen

Merksatz:

Cloud-Kosten entstehen nicht nur durch Server.

Pay as you go

Pay as you go bedeutet:

bezahlt wird nach Nutzung.

Beispiele:

pro Stunde
pro Sekunde
pro GB
pro Anfrage
pro Benutzer
pro Datenübertragung
pro Ausführung

Vorteil:

flexibel

Risiko:

Fehlkonfiguration oder Dauerbetrieb kann teuer werden.

Merksatz:

Pay as you go braucht Überwachung.

Budget

Ein Budget legt fest, wie viel Geld für Cloud-Ressourcen geplant ist.

Beispiele:

Monatsbudget für Projekt
Budget für Testumgebung
Budget für Abteilung
Budget für gesamte Cloud-Plattform

Wichtig:

Budget allein stoppt nicht immer automatisch Kosten.
Oft braucht man zusätzlich Alarme oder Sperren.

Merksatz:

Budget macht Kosten sichtbar und planbar.

Kostenalarm

Ein Kostenalarm warnt, wenn Kosten einen bestimmten Wert erreichen.

Beispiele:

50 % des Monatsbudgets erreicht

80 % des Monatsbudgets erreicht

ungewöhnlicher Kostenanstieg

unerwarteter Dienst verursacht Kosten

Merksatz:

Kostenalarme verhindern nicht alles,
aber sie machen Kosten früh sichtbar.

Kostenstelle

Eine Kostenstelle ordnet Kosten einem Bereich zu.

Beispiele:

Projekt
Abteilung
Kunde
Umgebung
Team
Anwendung

In der Cloud erfolgt diese Zuordnung oft über:

Tags
Labels
Ressourcengruppen
Abonnements
Accounts
Projekte

Merksatz:

Kosten müssen verursachergerecht zugeordnet werden.

Tagging

Tagging bedeutet:

Ressourcen werden mit Metadaten markiert.

Beispiele:

Projekt = CRM

Umgebung = Produktion

Verantwortlicher = IT-Betrieb

Kostenstelle = 4711

Ablaufdatum = 2026-12-31

Schutzbedarf = vertraulich

Vorteile:

Kosten zuordnen
Ressourcen finden
Verantwortliche erkennen
Automatisierung ermöglichen
Aufräumen erleichtern

Merksatz:

Tags machen Cloud-Ressourcen verwaltbar.

Untagged Resources

Untagged Resources sind Ressourcen ohne Tags.

Problem:

Verantwortlicher unklar
Kostenstelle unklar
Zweck unklar
Aufräumen schwierig
Sicherheitsbewertung schwieriger
Lebenszyklus unklar

Merksatz:

Ressourcen ohne Tags sind im Betrieb schwer kontrollierbar.

Rightsizing

Rightsizing bedeutet:

Ressourcen passend dimensionieren.

Beispiel:

Eine VM hat 16 vCPU und 64 GB RAM,
nutzt aber dauerhaft nur 5 %.

Dann ist sie wahrscheinlich zu groß.

Maßnahmen:

kleinere Instanz wählen
Datenbankklasse anpassen
Speicherklasse ändern
ungenutzte Ressourcen löschen
Lastverhalten prüfen

Merksatz:

Rightsizing senkt Kosten durch passende Größe.

Overprovisioning

Overprovisioning bedeutet:

Ressourcen sind größer bereitgestellt,
als tatsächlich benötigt.

Beispiele:

zu große VM
zu teure Datenbankklasse
zu viel reservierter Speicher
zu viele laufende Instanzen
unnötig hohe Performanceklasse

Merksatz:

Overprovisioning kostet unnötig Geld.

Underprovisioning

Underprovisioning bedeutet:

Ressourcen sind zu klein dimensioniert.

Folgen:

langsame Anwendung
Ausfälle
hohe Antwortzeiten
Datenbankengpässe
Fehler bei Lastspitzen
schlechte Benutzererfahrung

Merksatz:

Zu klein spart kurzfristig Geld,
kann aber Betrieb stören.

Auto Scaling

Auto Scaling bedeutet:

Ressourcen werden automatisch erhöht oder reduziert.

Beispiel:

Bei hoher Last werden zusätzliche Instanzen gestartet.

Bei geringer Last werden Instanzen beendet.

Vorteile:

bessere Anpassung an Last
weniger manuelle Eingriffe
bessere Verfügbarkeit
Kosten können optimiert werden

Merksatz:

Auto Scaling passt Ressourcen automatisch an Last an.

Horizontale Skalierung

Horizontale Skalierung bedeutet:

Es werden mehr Instanzen hinzugefügt.

Beispiel:

statt 1 Webserver
laufen 3 Webserver

Vorteil:

Last kann verteilt werden
Ausfallsicherheit steigt
gut mit Load Balancer kombinierbar

Merksatz:

Horizontal skalieren = mehr Systeme.

Vertikale Skalierung

Vertikale Skalierung bedeutet:

Ein einzelnes System wird größer gemacht.

Beispiel:

VM bekommt mehr CPU
VM bekommt mehr RAM
Datenbank bekommt größere Leistungsklasse

Vorteil:

oft einfacher

Nachteil:

Grenze durch maximale Größe
eventuell Neustart nötig
einzelnes System bleibt kritischer

Merksatz:

Vertikal skalieren = stärkeres System.

Horizontale und vertikale Skalierung vergleichen

Skalierungsart Bedeutung Beispiel
horizontal mehr Instanzen drei Webserver statt einer
vertikal größere Instanz mehr CPU und RAM für eine VM

Merksatz:

Horizontal = mehr.
Vertikal = stärker.

Scale Out und Scale Up

Scale Out bedeutet:

horizontal skalieren

Scale Up bedeutet:

vertikal skalieren

Beispiele:

Scale Out:
mehr App-Instanzen starten

Scale Up:
größere Datenbankklasse wählen

Merksatz:

Scale Out = mehr Instanzen.
Scale Up = größere Instanz.

Scale In und Scale Down

Scale In bedeutet:

Instanzen reduzieren

Scale Down bedeutet:

einzelne Instanz verkleinern

Beispiele:

Scale In:
von 5 Webservern auf 2 Webserver reduzieren

Scale Down:
VM von großer auf kleinere Größe ändern

Merksatz:

Scale In reduziert Anzahl.
Scale Down reduziert Größe.

Skalierungsregel

Eine Skalierungsregel legt fest, wann skaliert wird.

Beispiele:

Wenn CPU länger als 10 Minuten über 70 %,
dann eine Instanz hinzufügen.

Wenn Warteschlange mehr als 100 Nachrichten hat,
dann Worker erhöhen.

Wenn CPU länger niedrig,
dann Instanz entfernen.

Merksatz:

Skalierung braucht sinnvolle Regeln.

Skalierung ist nicht nur CPU

Skalierung kann abhängig sein von:

CPU
RAM
Anzahl Anfragen
Antwortzeit
Warteschlangenlänge
Datenbankverbindungen
Netzwerkdurchsatz
Fehlerrate
Benutzerzahl
Zeitplan

Merksatz:

CPU ist nur eine mögliche Skalierungsmetrik.

Load Balancer und Skalierung

Bei horizontaler Skalierung verteilt ein Load Balancer den Verkehr.

Ablauf:

neue Instanz startet
Health Check prüft Instanz
Load Balancer nimmt Instanz auf
Verkehr wird verteilt

Wenn Instanz ungesund ist, wird sie nicht genutzt.

Merksatz:

Auto Scaling und Load Balancer arbeiten oft zusammen.

Health Check im Betrieb

Ein Health Check prüft, ob ein Dienst gesund ist.

Beispiele:

HTTP 200 auf /health
TCP-Port erreichbar
Datenbankverbindung möglich
Anwendung meldet Status „ok“

Merksatz:

Health Check sollte echte Dienstfähigkeit prüfen,
nicht nur offenen Port.

Hochverfügbarkeit

Hochverfügbarkeit bedeutet:

Ein Dienst bleibt möglichst verfügbar,
auch wenn einzelne Komponenten ausfallen.

Mittel:

mehrere Instanzen
mehrere Zonen
Load Balancer
Replikation
automatischer Neustart
Monitoring
Backup
Notfallplan

Merksatz:

Hochverfügbarkeit muss geplant und getestet werden.

Verfügbarkeitszone

Eine Verfügbarkeitszone ist ein getrenntes Rechenzentrumssegment innerhalb einer Region.

Vorteil:

Fällt eine Zone aus,
können andere Zonen weiterarbeiten.

Cloud-Dienste sollten für hohe Verfügbarkeit oft über mehrere Zonen verteilt werden.

Merksatz:

Mehrere Zonen erhöhen Ausfallsicherheit innerhalb einer Region.

Region

Eine Region ist ein geografischer Standort eines Cloud-Anbieters.

Regionen beeinflussen:

Latenz
Datenstandort
Verfügbarkeit
Kosten
Datenschutz
Compliance

Merksatz:

Region bewusst nach Technik,
Recht
und Kosten auswählen.

Disaster Recovery

Disaster Recovery bedeutet:

Wiederherstellung nach schwerem Ausfall.

Beispiele:

Region fällt aus
Datenbank beschädigt
Ransomware-Angriff
Fehlkonfiguration löscht Ressourcen
kritischer Dienst fällt aus

Dazu braucht man:

Backups
Wiederherstellungsplan
Ersatzumgebung
Dokumentation
Tests
klare Zuständigkeiten

Merksatz:

Disaster Recovery muss vor dem Notfall geplant werden.

RTO im Cloud-Betrieb

RTO steht für:

Recovery Time Objective

Es beschreibt, wie lange ein Dienst maximal ausfallen darf.

Beispiel:

RTO = 2 Stunden

Dann soll der Dienst innerhalb von 2 Stunden wieder verfügbar sein.

Merksatz:

RTO beschreibt erlaubte Wiederherstellungszeit.

RPO im Cloud-Betrieb

RPO steht für:

Recovery Point Objective

Es beschreibt, wie viel Datenverlust maximal akzeptiert wird.

Beispiel:

RPO = 15 Minuten

Dann dürfen höchstens Daten der letzten 15 Minuten verloren gehen.

Merksatz:

RPO beschreibt erlaubten Datenverlust.

RTO und RPO im Betrieb vergleichen

Begriff Frage
RTO Wie lange darf der Dienst ausfallen?
RPO Wie viele Daten dürfen verloren gehen?

Merksatz:

RTO = Zeit bis Wiederherstellung.
RPO = Datenverlust bis Wiederherstellungspunkt.

Patchmanagement in der Cloud

Auch Cloud-Systeme brauchen Updates.

Wer verantwortlich ist, hängt vom Service-Modell ab.

IaaS:

Kunde patcht Betriebssystem und Anwendung.

PaaS:

Anbieter patcht Plattform,
Kunde patcht Anwendung und Abhängigkeiten.

SaaS:

Anbieter patcht Anwendung,
Kunde prüft Einstellungen,
Benutzer
und Sicherheit.

Merksatz:

Patchverantwortung hängt vom Cloud-Modell ab.

Wartungsfenster

Ein Wartungsfenster ist ein geplanter Zeitraum für Änderungen oder Updates.

Ziel:

Änderungen kontrolliert durchführen
Benutzer informieren
Ausfallzeit planen
Rollback vorbereiten
Risiken reduzieren

Merksatz:

Wartungsfenster schaffen planbare Änderungen.

Change Management

Change Management bedeutet:

Änderungen werden geplant,
geprüft,
freigegeben,
umgesetzt
und dokumentiert.

Cloud-Beispiele:

neue Firewall-Regel
größere Datenbankklasse
neue Region
neue Rolle
neue Backup-Regel
neue Skalierungsregel
neues Deployment

Merksatz:

Cloud-Änderungen brauchen Kontrolle und Dokumentation.

Rollback

Rollback bedeutet:

Eine Änderung wird zurückgenommen.

Beispiele:

vorherige Anwendungsversion wiederherstellen
alte Konfiguration laden
Snapshot zurücksetzen
Firewall-Regel zurücknehmen
Deployment rückgängig machen

Merksatz:

Jede kritische Änderung braucht einen Rückweg.

Automatisierung im Cloud-Betrieb

Cloud-Betrieb wird häufig automatisiert.

Beispiele:

Ressourcen automatisch bereitstellen
Backups automatisch erstellen
Skalierung automatisch durchführen
Alarme automatisch auslösen
Tests automatisch starten
Deployments automatisch ausrollen
ungenutzte Ressourcen automatisch stoppen

Merksatz:

Automatisierung reduziert manuelle Fehler,
braucht aber gute Regeln.

Infrastructure as Code

Infrastructure as Code wird oft abgekürzt:

IaC

Dabei wird Infrastruktur nicht manuell im Portal zusammengeklickt, sondern als Code beschrieben.

Beispiele:

Netzwerke
Subnetze
Firewall-Regeln
virtuelle Maschinen
Datenbanken
Rollen
Speicher
Load Balancer

Vorteile:

wiederholbar
dokumentiert
versionierbar
prüfbar
automatisierbar

Merksatz:

IaC beschreibt Infrastruktur als Code.

Configuration Drift

Configuration Drift bedeutet:

Die tatsächliche Konfiguration weicht von der geplanten Konfiguration ab.

Ursachen:

manuelle Änderungen
Notfalländerungen
unterschiedliche Umgebungen
unvollständige Dokumentation
fehlende Automatisierung

Problem:

Fehlersuche wird schwieriger.
Sicherheit kann unbemerkt schlechter werden.

Merksatz:

Configuration Drift entsteht durch ungeplante Abweichungen.

CI/CD im Cloud-Betrieb

CI/CD steht für:

Continuous Integration
Continuous Delivery
oder
Continuous Deployment

Ziel:

Änderungen werden automatisiert gebaut,
getestet
und bereitgestellt.

Cloud-Bezug:

Anwendungen werden schneller und kontrollierter ausgeliefert.
Rollbacks können einfacher werden.
Tests werden automatisiert.
Infrastruktur kann mitbereitgestellt werden.

Merksatz:

CI/CD automatisiert Entwicklung,
Test
und Bereitstellung.

Blue-Green Deployment

Blue-Green Deployment bedeutet:

Es gibt zwei Umgebungen.

Blue:
aktuelle produktive Version

Green:
neue Version

Nach erfolgreichem Test wird der Verkehr auf die neue Umgebung umgeschaltet.

Vorteil:

schneller Rollback möglich

Merksatz:

Blue-Green reduziert Risiko bei neuen Versionen.

Canary Deployment

Canary Deployment bedeutet:

Eine neue Version wird zuerst nur für einen kleinen Teil der Benutzer freigegeben.

Wenn keine Probleme auftreten, wird der Anteil erhöht.

Vorteil:

Fehler betreffen zunächst nur wenige Benutzer.

Merksatz:

Canary testet neue Versionen schrittweise im Echtbetrieb.

Cloud-Betriebsdokumentation

Dokumentiert werden sollten:

Zweck der Ressource
Verantwortlicher
Kostenstelle
Umgebung
Datenklasse
Netzverbindungen
Backup-Regeln
Monitoring
Alarme
Wiederherstellungsplan
Sicherheitsregeln
Änderungen
Abhängigkeiten

Merksatz:

Was nicht dokumentiert ist,
ist im Betrieb schwer beherrschbar.

Runbook

Ein Runbook ist eine Schritt-für-Schritt-Anleitung für wiederkehrende Betriebsaufgaben.

Beispiele:

Dienst neu starten
Backup wiederherstellen
Zertifikat erneuern
Alarm bearbeiten
Instanz skalieren
Failover auslösen
Benutzerzugriff prüfen

Merksatz:

Runbooks helfen,
im Betrieb einheitlich zu handeln.

Incident Response

Incident Response bedeutet:

Vorgehen bei Sicherheitsvorfällen oder größeren Störungen.

Schritte:

erkennen
bewerten
eindämmen
beseitigen
wiederherstellen
dokumentieren
verbessern

Cloud-Beispiele:

kompromittierter API-Schlüssel
öffentlich freigegebener Speicher
ungewöhnliche Kosten
Adminzugang missbraucht
Datenabfluss
Ransomware

Merksatz:

Incident Response muss vorbereitet sein,
bevor ein Vorfall passiert.

Service Level Agreement

Service Level Agreement wird abgekürzt:

SLA

Ein SLA beschreibt zugesicherte Servicequalität.

Beispiele:

Verfügbarkeit
Reaktionszeit
Supportzeit
Wiederherstellungszeit
Leistungswerte

Merksatz:

SLA beschreibt,
welche Leistung zugesichert wird.

SLO

SLO steht für:

Service Level Objective

Ein SLO ist ein internes oder technisches Ziel für einen Dienst.

Beispiel:

99,9 % erfolgreiche Anfragen pro Monat

Antwortzeit unter 300 ms für 95 % der Anfragen

Merksatz:

SLO beschreibt ein Ziel für Servicequalität.

SLI

SLI steht für:

Service Level Indicator

Ein SLI ist ein Messwert, mit dem ein SLO bewertet wird.

Beispiele:

Verfügbarkeit
Fehlerrate
Antwortzeit
Durchsatz
Latenz

Merksatz:

SLI ist der Messwert,
SLO ist das Ziel.

SLA, SLO und SLI vergleichen

Begriff Bedeutung
SLA vertragliche Zusage
SLO Zielwert für Dienstqualität
SLI Messwert zur Bewertung

Merksatz:

SLI misst.
SLO setzt Ziel.
SLA ist Zusage.

Cloud-Fehlersuche im Betrieb

Bei Cloud-Störungen systematisch prüfen:

Was ist betroffen?
Seit wann?
Wurde etwas geändert?
Welche Region?
Welche Zone?
Welche Ressource?
Welche Logs?
Welche Metriken?
Welche Abhängigkeiten?
Welche Kostenänderung?
Welche Alarme?
Welche Benutzer betroffen?

Merksatz:

Störungen immer mit Zeit,
Änderung
Metriken
Logs
und Abhängigkeiten prüfen.

Typische Betriebsprobleme in der Cloud

Häufige Probleme:

Dienst nicht erreichbar
Zertifikat abgelaufen
Speicher voll
Datenbank überlastet
Kosten steigen plötzlich
Backup fehlgeschlagen
Load Balancer hat keine gesunden Ziele
Security Group falsch geändert
API-Schlüssel kompromittiert
Rechte zu breit vergeben
Region oder Zone gestört
Skalierung greift nicht

Merksatz:

Cloud-Betrieb betrifft Verfügbarkeit,
Sicherheit
Leistung
und Kosten.

Checkliste: Cloud-Betrieb

Monitoring aktivieren.
Logs aktivieren.
Alarme einrichten.
Kostenalarme setzen.
Tags pflegen.
Verantwortliche dokumentieren.
Backups prüfen.
Restore-Tests durchführen.
Rechte regelmäßig prüfen.
Ressourcen richtig dimensionieren.
ungenutzte Ressourcen löschen.
Patchverantwortung klären.
Runbooks erstellen.
Änderungen dokumentieren.
Incident Response vorbereiten.

Merksatz:

Cloud-Betrieb braucht regelmäßige Kontrolle.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Warum braucht Cloud Monitoring?
- Was ist der Unterschied zwischen Monitoring und Logging?
- Was ist ein Kostenalarm?
- Warum ist Tagging sinnvoll?
- Was bedeutet Rightsizing?
- Was ist Overprovisioning?
- Was ist Auto Scaling?
- Was ist horizontale Skalierung?
- Was ist vertikale Skalierung?
- Was ist ein Health Check?
- Was ist der Unterschied zwischen RTO und RPO?
- Was ist Infrastructure as Code?
- Was bedeutet Configuration Drift?
- Was ist ein Runbook?
- Was bedeutet Incident Response?
- Was ist der Unterschied zwischen SLA, SLO und SLI?
- Warum ist Cloud nicht automatisch wartungsfrei?

Typische Prüfungsfallen

Cloud ist nicht wartungsfrei.

Monitoring zeigt Zustand.

Logs zeigen Ereignisse.

Ohne Logs keine gute Fehlersuche.

Zu viele Alarme können schaden.

Kosten entstehen auch durch Speicher,
Traffic,
Logs
und Snapshots.

Pay as you go braucht Kontrolle.

Tags helfen bei Kosten und Verantwortung.

Untagged Resources sind problematisch.

Rightsizing spart Kosten.

Overprovisioning kostet unnötig Geld.

Underprovisioning stört Betrieb.

Auto Scaling braucht sinnvolle Regeln.

Horizontal bedeutet mehr Instanzen.

Vertikal bedeutet größere Instanz.

Hochverfügbarkeit muss geplant werden.

Cloud ist nicht automatisch hochverfügbar.

RTO betrifft Wiederherstellungszeit.

RPO betrifft Datenverlust.

Patchverantwortung hängt vom Service-Modell ab.

Change Management gilt auch in der Cloud.

Rollback vor Änderung planen.

IaC macht Infrastruktur wiederholbar.

Configuration Drift vermeiden.

Runbooks helfen im Betrieb.

SLA,
SLO
und SLI nicht verwechseln.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
Cloud-Betrieb laufende Verwaltung von Cloud-Diensten
Monitoring Überwachung von Zuständen
Metrik messbarer Wert
Logging Protokollierung von Ereignissen
Audit-Log Protokoll administrativer Aktionen
Flow Log Netzwerkverbindungsdaten
Alarmierung automatische Warnung
Schwellwert Grenzwert für Alarm oder Aktion
Alert Fatigue Überforderung durch zu viele Alarme
Dashboard Übersicht wichtiger Werte
SIEM zentrale Sicherheitslog-Auswertung
Kostenkontrolle Überwachung und Steuerung von Kosten
Pay as you go Abrechnung nach Nutzung
Budget geplanter Kostenrahmen
Kostenalarm Warnung bei Kostenüberschreitung
Kostenstelle Zuordnung von Kosten
Tagging Metadaten an Ressourcen
Rightsizing passende Ressourcengröße
Overprovisioning zu große Ressourcen
Underprovisioning zu kleine Ressourcen
Auto Scaling automatische Anpassung von Ressourcen
horizontale Skalierung mehr Instanzen
vertikale Skalierung größere Instanz
Scale Out horizontal erweitern
Scale Up vertikal vergrößern
Health Check Prüfung der Dienstgesundheit
Hochverfügbarkeit hohe Verfügbarkeit trotz Fehler
Disaster Recovery Wiederherstellung nach schwerem Ausfall
RTO maximale Wiederherstellungszeit
RPO maximaler Datenverlust
Patchmanagement Verwaltung von Updates
Change Management kontrollierte Änderungen
Rollback Änderung zurücknehmen
IaC Infrastructure as Code
Configuration Drift Abweichung von Soll-Konfiguration
CI/CD automatisierte Bereitstellung
Runbook Betriebsanleitung
Incident Response Reaktion auf Vorfälle
SLA vertragliche Servicezusage
SLO Zielwert für Servicequalität
SLI Messwert für Servicequalität

IHK-sichere Kurzformulierung

Cloud-Betrieb umfasst die laufende Überwachung, Protokollierung, Alarmierung, Kostenkontrolle, Skalierung, Wartung, Sicherheitsprüfung und Dokumentation von Cloud-Diensten. Monitoring zeigt den aktuellen Zustand eines Systems, während Logging Ereignisse und Änderungen nachvollziehbar macht. Kostenkontrolle ist wichtig, weil Cloud-Ressourcen nach Nutzung abgerechnet werden und auch Speicher, Netzwerkverkehr, Backups, Logs, Snapshots und Lizenzen Kosten verursachen können. Auto Scaling passt Ressourcen automatisch an Last an. Horizontale Skalierung bedeutet mehr Instanzen, vertikale Skalierung bedeutet größere Instanzen. Für Ausfallsicherheit sind Hochverfügbarkeit, Backups, RTO, RPO, Runbooks, Change Management und Incident Response wichtig.


Merksätze

Cloud ist nicht wartungsfrei.

Cloud-Betrieb braucht Monitoring.

Monitoring zeigt Zustand.

Logs zeigen Ereignisse.

Audit-Logs zeigen Adminaktionen.

Flow Logs zeigen Netzwerkverbindungen.

Alarmierung macht Probleme sichtbar.

Zu viele Alarme können wichtige Alarme verdecken.

Dashboard gibt Überblick.

SIEM wertet Sicherheitslogs zentral aus.

Cloud-Kosten aktiv überwachen.

Pay as you go braucht Kontrolle.

Kosten entstehen auch durch Traffic,
Speicher,
Logs
und Snapshots.

Budget planen.

Kostenalarme setzen.

Tags pflegen.

Untagged Resources vermeiden.

Rightsizing spart Kosten.

Overprovisioning kostet unnötig.

Underprovisioning gefährdet Betrieb.

Auto Scaling passt Ressourcen an.

Horizontal = mehr Instanzen.

Vertikal = stärkere Instanz.

Scale Out = mehr.

Scale Up = größer.

Load Balancer verteilt Last.

Health Check prüft Dienstgesundheit.

Hochverfügbarkeit planen.

Cloud ist nicht automatisch hochverfügbar.

Region und Zone bewusst wählen.

Disaster Recovery vorher planen.

RTO = Wiederherstellungszeit.

RPO = Datenverlust.

Patchverantwortung hängt vom Service-Modell ab.

Änderungen dokumentieren.

Rollback vor Änderung planen.

IaC beschreibt Infrastruktur als Code.

Configuration Drift vermeiden.

CI/CD automatisiert Bereitstellung.

Runbooks helfen im Betrieb.

Incident Response vorbereiten.

SLI misst.

SLO setzt Ziel.

SLA ist Zusage.

15.8 Merksätze und Prüfungswissen zu Cloud und modernen Bereitstellungsmodellen

Diese Seite fasst die wichtigsten Inhalte zu Cloud, Bereitstellungsmodellen, Service-Modellen, Cloud-Netzwerken, Cloud-Sicherheit, Cloud-Speicher, Backup, Monitoring, Skalierung und Kostenkontrolle zusammen.

Cloud ist prüfungsrelevant, weil sie viele Themen verbindet:

- Netzwerktechnik
- Serverbetrieb
- Virtualisierung
- Sicherheit
- Datenschutz
- Backup
- Kosten
- Rechteverwaltung
- Hochverfügbarkeit
- Monitoring

Merksatz:

Cloud ist kein einzelnes Produkt,
sondern ein Betriebs- und Bereitstellungsmodell für IT-Ressourcen.

Cloud-Grundidee

Cloud bedeutet:

IT-Ressourcen werden über ein Netzwerk als Dienst bereitgestellt.

Beispiele:

virtuelle Server
Speicher
Datenbanken
Anwendungen
Plattformen
Container
Backup
Identitätsdienste
Netzwerkdienste
Sicherheitsdienste

Merksatz:

Cloud = IT-Ressourcen als Dienst.

Cloud ist nicht automatisch weniger Verantwortung

Ein häufiger Denkfehler:

Alles liegt in der Cloud,
also kümmert sich der Anbieter um alles.

Das ist falsch.

Der Anbieter übernimmt je nach Modell bestimmte Aufgaben.

Der Kunde bleibt verantwortlich für:

Benutzer
Rollen
Berechtigungen
Daten
sichere Konfiguration
Datenschutz
Zugriffsschutz
Backup-Konzept
Kostenkontrolle
Monitoring
Compliance

Merksatz:

Cloud verlagert Verantwortung,
sie beseitigt Verantwortung nicht.

On-Premises

On-Premises bedeutet:

IT wird lokal selbst betrieben.

Beispiele:

eigener Serverraum
eigenes Rechenzentrum
eigene Hardware
eigene Virtualisierung
eigene Netzwerkinfrastruktur

Vorteile:

hohe Kontrolle
direkte Verwaltung
eigene Vorgaben

Nachteile:

Hardwarekosten
Wartungsaufwand
eigene Verantwortung für Ausfallsicherheit

Merksatz:

On-Premises = lokal selbst betrieben.

Public Cloud

Public Cloud bedeutet:

Ein Anbieter stellt Cloud-Ressourcen für viele Kunden bereit.

Eigenschaften:

Anbieterplattform
viele Kunden
logische Mandantentrennung
nutzungsabhängige Abrechnung
schnelle Bereitstellung
hohe Skalierbarkeit

Merksatz:

Public Cloud = öffentliche Anbieterplattform für viele Kunden.

Private Cloud

Private Cloud bedeutet:

Cloud-Prinzipien werden für eine einzelne Organisation bereitgestellt.

Sie kann laufen:

im eigenen Rechenzentrum
bei einem Dienstleister
in einer dedizierten Umgebung

Wichtig:

Virtualisierung allein ist noch keine vollständige Private Cloud.

Typische Cloud-Merkmale sind:

Self-Service
Automatisierung
Ressourcenpooling
schnelle Bereitstellung
messbare Nutzung
zentrale Verwaltung

Merksatz:

Private Cloud = Cloud für eine Organisation.

Hybrid Cloud

Hybrid Cloud kombiniert lokale oder private IT mit Public Cloud.

Beispiele:

lokale Datenbank plus Cloud-Webanwendung

lokales Rechenzentrum plus Cloud-Backup

lokale Benutzerverwaltung plus Cloud-SaaS

lokale Systeme plus Cloud-Skalierung

Merksatz:

Hybrid Cloud = lokal oder privat plus Public Cloud.

Multi Cloud

Multi Cloud bedeutet:

Ein Unternehmen nutzt mehrere Cloud-Anbieter gleichzeitig.

Beispiel:

Anbieter A für virtuelle Maschinen

Anbieter B für Office und E-Mail

Anbieter C für Backup

Anbieter D für Datenanalyse

Merksatz:

Multi Cloud = mehrere Cloud-Anbieter parallel.

Hybrid Cloud und Multi Cloud unterscheiden

Begriff Kerngedanke
Hybrid Cloud lokale/private IT plus Public Cloud
Multi Cloud mehrere Cloud-Anbieter
Hybrid und Multi Cloud kombiniert lokale IT plus mehrere Cloud-Anbieter

Merksatz:

Hybrid beschreibt die Verbindung lokal plus Cloud.
Multi Cloud beschreibt mehrere Anbieter.

Community Cloud

Community Cloud bedeutet:

Eine Cloud wird von mehreren Organisationen mit ähnlichen Anforderungen genutzt.

Beispiele:

Behörden
Bildung
Forschung
Gesundheitswesen
bestimmte Branchen

Merksatz:

Community Cloud = Cloud für eine bestimmte Gemeinschaft.

Bereitstellungsmodelle im Überblick

Modell Kurze Erklärung
On-Premises lokal selbst betrieben
Public Cloud Anbieterplattform für viele Kunden
Private Cloud Cloud für eine Organisation
Hybrid Cloud lokale/private IT plus Public Cloud
Multi Cloud mehrere Cloud-Anbieter
Community Cloud Cloud für Organisationen mit gemeinsamen Anforderungen

Merksatz:

Bereitstellungsmodell beschreibt,
wo und für wen Cloud betrieben wird.

Service-Modelle

Die wichtigsten Cloud-Service-Modelle sind:

- IaaS
- PaaS
- SaaS

Sie beschreiben, welche IT-Schichten der Anbieter bereitstellt und welche der Kunde selbst verwaltet.

Merksatz:

Service-Modell beschreibt,
was als Dienst bereitgestellt wird.

IaaS

IaaS steht für:

Infrastructure as a Service

Der Anbieter stellt virtuelle Infrastruktur bereit.

Beispiele:

virtuelle Maschinen
virtuelle Netzwerke
virtuelle Festplatten
Load Balancer
Firewalls
IP-Adressen
Storage

Der Kunde verwaltet typischerweise:

Betriebssystem
Anwendungen
Daten
Patches innerhalb der VM
Benutzer
Sicherheitskonfiguration

Merksatz:

IaaS = virtuelle Infrastruktur statt eigener Hardware.

PaaS

PaaS steht für:

Platform as a Service

Der Anbieter stellt eine Plattform bereit, auf der Anwendungen laufen können.

Beispiele:

Web-App-Plattform
verwaltete Datenbank
Laufzeitumgebung
Containerplattform
API-Plattform
Entwicklungsplattform

Der Kunde verwaltet typischerweise:

Anwendung
Daten
Konfiguration
Benutzer
Berechtigungen

Merksatz:

PaaS = Plattform für eigene Anwendungen.

SaaS

SaaS steht für:

Software as a Service

Der Kunde nutzt eine fertige Anwendung.

Beispiele:

E-Mail
Online-Office
CRM
Ticketsystem
Cloud-Speicher
Videokonferenzdienst
Projektmanagement

Der Kunde verwaltet typischerweise:

Benutzer
Rollen
Berechtigungen
Daten
Freigaben
Einstellungen
MFA

Merksatz:

SaaS = fertige Software aus der Cloud.

IaaS, PaaS und SaaS vergleichen

Modell Anbieter stellt bereit Kunde verwaltet vor allem
IaaS virtuelle Infrastruktur Betriebssystem, Anwendung, Daten
PaaS Plattform und Laufzeitumgebung Anwendung, Daten, Konfiguration
SaaS fertige Anwendung Benutzer, Rechte, Daten, Einstellungen

Merksatz:

IaaS gibt viel Kontrolle.
SaaS nimmt viel Betrieb ab.
PaaS liegt dazwischen.

Shared Responsibility Model

Shared Responsibility Model bedeutet:

Anbieter und Kunde teilen sich die Verantwortung.

Je nach Service-Modell verschiebt sich diese Verantwortung.

Bei IaaS:

Kunde hat viel technische Verantwortung.

Bei PaaS:

Anbieter übernimmt Plattform,
Kunde bleibt für Anwendung und Daten verantwortlich.

Bei SaaS:

Anbieter betreibt Anwendung,
Kunde bleibt für Nutzung,
Benutzer,
Rechte
und Daten verantwortlich.

Merksatz:

Cloud-Sicherheit ist gemeinsame Verantwortung.

Wichtigste Regel zur Verantwortung

Daten, Benutzer und Rechte bleiben fast immer Kundenthema.

Auch bei SaaS muss der Kunde prüfen:

Wer darf zugreifen?
Welche Rollen gibt es?
Ist MFA aktiv?
Welche Daten liegen im Dienst?
Welche Freigaben existieren?
Wie werden Benutzer deaktiviert?
Wie werden Daten gesichert oder exportiert?

Merksatz:

Je fertiger der Dienst,
desto weniger Technikbetrieb,
aber Daten und Zugriffe bleiben wichtig.

Virtualisierung

Virtualisierung bedeutet:

physische Ressourcen werden in virtuelle Ressourcen aufgeteilt.

Beispiele:

virtuelle Maschinen
virtuelle Netzwerke
virtuelle Festplatten
virtuelle Firewalls
virtuelle Load Balancer

Merksatz:

Virtualisierung ist eine technische Grundlage vieler Cloud-Dienste.

Container

Container verpacken Anwendungen mit ihren Abhängigkeiten.

Sie enthalten typischerweise:

Anwendung
Bibliotheken
Laufzeitumgebung
Konfiguration

Sie teilen sich den Kernel des Hosts.

Merksatz:

Container sind leichtgewichtige,
portable Anwendungseinheiten.

Kubernetes

Kubernetes ist eine Plattform zur Container-Orchestrierung.

Es verwaltet:

Container
Pods
Services
Deployments
Skalierung
Rollouts
Netzwerke
Konfigurationen

Merksatz:

Kubernetes orchestriert Container in Clustern.

Serverless

Serverless bedeutet nicht, dass keine Server existieren.

Es bedeutet:

Der Kunde verwaltet keine einzelnen Server.

Der Anbieter betreibt die Infrastruktur.

Der Kunde stellt Code, Funktionen oder Konfiguration bereit.

Merksatz:

Serverless = keine Serververwaltung durch den Kunden.

FaaS

FaaS steht für:

Function as a Service

Dabei werden einzelne Funktionen ereignisgesteuert ausgeführt.

Beispiele:

Datei hochgeladen
API-Aufruf
Zeitplan
Nachricht in Warteschlange

Merksatz:

FaaS führt Funktionen bei Ereignissen aus.

Cloud-Netzwerke

Cloud-Netzwerke bestehen aus virtuellen Netzwerkkomponenten.

Typische Bestandteile:

VPC
VNet
Subnetze
Routingtabellen
Security Groups
Network ACLs
NSGs
Internet Gateway
NAT-Gateway
VPN-Gateway
Load Balancer
DNS
Peering

Merksatz:

Cloud-Netzwerke sind virtuell,
brauchen aber echte Netzplanung.

VPC und VNet

VPC steht für:

Virtual Private Cloud

VNet steht für:

Virtual Network

Beide beschreiben ein logisch getrenntes Cloud-Netzwerk.

Darin werden festgelegt:

IP-Bereich
Subnetze
Routen
Sicherheitsregeln
Gateways
Ressourcen

Merksatz:

VPC oder VNet = eigenes virtuelles Cloud-Netz.

Public Subnet und Private Subnet

Subnetztyp Zweck
Public Subnet öffentlich erreichbare Komponenten
Private Subnet interne Komponenten ohne direkten Internetzugriff

Beispiele:

Public Subnet:
Load Balancer,
Bastion Host,
Reverse Proxy

Private Subnet:
Datenbank,
Backend,
interne API,
Verarbeitungssystem

Merksatz:

Öffentlich nur,
was wirklich öffentlich sein muss.

Internet Gateway und NAT-Gateway

Internet Gateway:

verbindet Cloud-Netz mit dem Internet

NAT-Gateway:

erlaubt privaten Ressourcen ausgehenden Internetzugriff,
ohne direkt eingehend erreichbar zu sein

Merksatz:

Internet Gateway verbindet öffentlich.
NAT-Gateway erlaubt ausgehend für private Ressourcen.

Security Group

Eine Security Group ist eine virtuelle Firewall-Regelgruppe.

Sie steuert:

eingehenden Verkehr
ausgehenden Verkehr
Ports
Protokolle
Quellen
Ziele

Merksatz:

Security Group = Firewall-Regeln an Cloud-Ressourcen.

Network ACL und NSG

Network ACL:

Zugriffsliste auf Netzwerk- oder Subnetzebene

NSG:

Network Security Group,
Regelgruppe für Netzwerkzugriffe

Wichtig:

Je nach Plattform können Regeln stateful oder stateless sein.

Merksatz:

Security Groups,
ACLs
und NSGs können alle Zugriff beeinflussen.

Stateful und Stateless

Stateful bedeutet:

Rückverkehr zu erlaubten Verbindungen wird automatisch zugeordnet.

Stateless bedeutet:

Rückverkehr muss separat erlaubt werden.

Merksatz:

Stateful merkt sich Verbindungen.
Stateless prüft jedes Paket einzeln.

Load Balancer

Ein Load Balancer verteilt Anfragen auf mehrere Ziele.

Vorteile:

Lastverteilung
höhere Verfügbarkeit
Skalierung
Wartung einzelner Backends
Health Checks

Merksatz:

Load Balancer verteilt Verkehr auf gesunde Ziele.

Health Check

Ein Health Check prüft, ob ein Backend gesund ist.

Beispiele:

TCP-Port erreichbar
HTTP-Status 200
Anwendung meldet gesund
Antwortzeit akzeptabel

Merksatz:

Health Check entscheidet,
ob ein Backend Verkehr erhält.

Peering

Peering verbindet zwei Cloud-Netze privat miteinander.

Wichtig:

IP-Netze dürfen sich nicht überschneiden.
Routen müssen passen.
Sicherheitsregeln müssen passen.
Peering ist nicht automatisch transitiv.

Merksatz:

Peering verbindet Netze,
leitet aber nicht automatisch zu dritten Netzen weiter.

Cloud-VPN

Cloud-VPN verbindet Cloud-Netze mit anderen Netzen.

Beispiele:

Cloud ↔ lokales Rechenzentrum

Cloud ↔ Niederlassung

Cloud ↔ andere Cloud

Wichtig:

IP-Planung
Routing
Firewall-Regeln
Verschlüsselung
Monitoring
Rückrouten

Merksatz:

Cloud-VPN braucht Regeln und Routen auf beiden Seiten.

Cloud-Speicherarten

Die wichtigsten Cloud-Speicherarten sind:

- Objektspeicher
- Blockspeicher
- Dateispeicher
- Archivspeicher

Merksatz:

Speicherart nach Einsatzzweck auswählen.

Objektspeicher

Objektspeicher speichert Daten als Objekte.

Ein Objekt enthält:

Inhalt
Metadaten
eindeutigen Schlüssel

Typische Nutzung:

Backups
Bilder
Videos
Logs
Archive
Dokumente
große unstrukturierte Datenmengen

Merksatz:

Objektspeicher eignet sich für viele unstrukturierte Daten.

Bucket

Ein Bucket ist ein Speicherbehälter für Objekte.

Wichtig:

Bucket-Berechtigungen sind sicherheitskritisch.

Fehler:

Bucket öffentlich lesbar

Folge:

vertrauliche Daten können offenliegen.

Merksatz:

Öffentliche Buckets vermeiden.

Blockspeicher

Blockspeicher verhält sich wie eine virtuelle Festplatte.

Typische Nutzung:

virtuelle Maschinen
Betriebssystemplatten
Datenbanken
Anwendungen mit Dateisystem

Merksatz:

Blockspeicher = virtuelle Festplatte.

Dateispeicher

Dateispeicher stellt klassische Datei- und Ordnerfreigaben bereit.

Typische Protokolle:

SMB
NFS

Typische Nutzung:

gemeinsame Dateien
Benutzerdateien
klassische Anwendungen
zentrale Ablagen

Merksatz:

Dateispeicher = Freigabe mit Dateien und Ordnern.

Backup in der Cloud

Cloud ersetzt kein Backup.

Auch Cloud-Daten können verloren gehen durch:

Benutzerfehler
Ransomware
Fehlkonfiguration
falsche Synchronisation
gelöschte Benutzer
kompromittierte Adminzugänge
Anbieterproblem
fehlerhafte Anwendung

Merksatz:

Cloud ist kein Backup.

RPO und RTO

RPO steht für:

Recovery Point Objective

Frage:

Wie viel Datenverlust ist maximal erlaubt?

RTO steht für:

Recovery Time Objective

Frage:

Wie lange darf Wiederherstellung dauern?

Merksatz:

RPO = Datenverlust.
RTO = Wiederherstellungszeit.

Backup und Replikation

Backup:

dient der Wiederherstellung alter oder gesicherter Zustände

Replikation:

kopiert Daten auf ein anderes System oder in eine andere Region

Wichtig:

Replikation ist kein vollständiger Backup-Ersatz,
weil Fehler und Löschungen mitkopiert werden können.

Merksatz:

Backup schützt Wiederherstellung.
Replikation schützt eher Verfügbarkeit.

3-2-1-Regel

Die 3-2-1-Regel bedeutet:

3 Kopien der Daten

2 unterschiedliche Speichermedien oder Speicherarten

1 Kopie außer Haus oder getrennt vom Hauptsystem

Merksatz:

Mehrere getrennte Kopien schützen besser.

Immutable Backup

Immutable bedeutet:

unveränderlich

Ein Immutable Backup kann für eine festgelegte Zeit nicht verändert oder gelöscht werden.

Vorteile:

Schutz vor Ransomware
Schutz vor versehentlicher Löschung
Schutz vor kompromittierten Konten

Merksatz:

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

IAM

IAM steht für:

Identity and Access Management

IAM regelt:

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

Merksatz:

IAM entscheidet,
wer was in der Cloud darf.

Authentifizierung und Autorisierung

Authentifizierung:

Wer bist du?

Autorisierung:

Was darfst du?

Beispiel:

Benutzer meldet sich an:
Authentifizierung

Benutzer darf eine VM löschen:
Autorisierung

Merksatz:

Anmeldung und Berechtigung unterscheiden.

MFA

MFA steht für:

Multi-Faktor-Authentifizierung

MFA ist besonders wichtig für:

Administratoren
externe Benutzer
Cloud-Portale
IAM
Abrechnung
Produktion
sensible Daten

Merksatz:

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

Least Privilege

Least Privilege bedeutet:

nur die Rechte vergeben,
die wirklich benötigt werden.

In der Cloud besonders wichtig, weil einzelne Rechte große Auswirkungen haben können.

Beispiele:

Speicher öffentlich machen
Firewall öffnen
VM löschen
Backup löschen
Rollen vergeben
API-Schlüssel erstellen

Merksatz:

Cloud-Rechte minimal vergeben.

Servicekonten und API-Schlüssel

Servicekonten sind Identitäten für Dienste oder Anwendungen.

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

Risiken:

zu viele Rechte
Schlüssel im Quellcode
keine Rotation
keine Löschung nach Projektende
Veröffentlichung in Repositories

Merksatz:

Servicekonten und API-Schlüssel wie kritische Zugangsdaten behandeln.

Secrets

Secrets sind geheime Informationen.

Beispiele:

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

Merksatz:

Secrets gehören nicht in Quellcode,
Tickets,
Chats
oder ungeschützte Dokumente.

RBAC und ABAC

RBAC:

rollenbasierte Zugriffskontrolle

ABAC:

attributbasierte Zugriffskontrolle
Modell Grundlage
RBAC Rollen
ABAC Attribute

Merksatz:

RBAC arbeitet mit Rollen.
ABAC arbeitet mit Eigenschaften.

Tenant und Mandantentrennung

Ein Tenant ist ein logisch getrennter Verwaltungsbereich.

Mandantentrennung bedeutet:

Daten und Ressourcen verschiedener Kunden oder Organisationseinheiten werden logisch getrennt.

Merksatz:

Tenant = eigener Cloud-Verwaltungsbereich.

SSO, SAML, OAuth 2.0 und OpenID Connect

SSO:

einmal anmelden,
mehrere Dienste nutzen

SAML:

häufig für Single Sign-On genutzt

OAuth 2.0:

delegierte Autorisierung

OpenID Connect:

ergänzt OAuth 2.0 um Authentifizierung

Merksatz:

OAuth 2.0 ist Autorisierung.
OpenID Connect ergänzt Authentifizierung.

Verschlüsselung

Cloud-Daten sollten geschützt werden:

bei Übertragung

und

im Ruhezustand

Bei Übertragung:

TLS

Im Ruhezustand:

Speicherverschlüsselung
Datenbankverschlüsselung
Backup-Verschlüsselung

Merksatz:

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

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 steuern
Nutzung protokollieren
Schlüssel deaktivieren

Merksatz:

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

Logging und Monitoring

Monitoring:

zeigt aktuelle Zustände und Messwerte

Logging:

zeigt Ereignisse und Änderungen

Beispiele für Logs:

Audit-Logs
Flow Logs
Firewall-Logs
Anwendungslogs
IAM-Logs
Load-Balancer-Logs

Merksatz:

Monitoring zeigt Zustand.
Logging zeigt Ereignisse.

SIEM

SIEM steht für:

Security Information and Event Management

Ein SIEM sammelt und analysiert Sicherheitslogs.

Ziele:

Angriffe erkennen
Alarme erzeugen
Ereignisse korrelieren
Nachweise liefern

Merksatz:

SIEM hilft bei zentraler Sicherheitsüberwachung.

Kostenkontrolle

Cloud-Kosten entstehen durch:

Rechenleistung
Speicher
Datenbanken
Backups
Snapshots
Logs
Monitoring
Netzwerkverkehr
Load Balancer
Lizenzen
öffentliche IP-Adressen
Support

Merksatz:

Cloud-Kosten entstehen nicht nur durch Server.

Pay as you go

Pay as you go bedeutet:

Abrechnung nach Nutzung.

Vorteil:

flexibel

Risiko:

Fehlkonfiguration,
Dauerbetrieb
oder unerwartete Last können teuer werden.

Merksatz:

Pay as you go braucht Kostenüberwachung.

Tagging

Tagging bedeutet:

Cloud-Ressourcen werden mit Metadaten markiert.

Beispiele:

Projekt
Kostenstelle
Verantwortlicher
Umgebung
Ablaufdatum
Schutzbedarf

Merksatz:

Tags helfen bei Kosten,
Verantwortung
Ordnung
und Automatisierung.

Rightsizing

Rightsizing bedeutet:

Ressourcen passend dimensionieren.

Zu groß:

unnötige Kosten

Zu klein:

schlechte Leistung oder Ausfälle

Merksatz:

Rightsizing sucht die passende Ressourcengröße.

Auto Scaling

Auto Scaling passt Ressourcen automatisch an die Last an.

Beispiel:

mehr Instanzen bei hoher Last

weniger Instanzen bei geringer Last

Merksatz:

Auto Scaling skaliert automatisch nach Regeln.

Horizontale und vertikale Skalierung

Skalierung Bedeutung
horizontal mehr Instanzen
vertikal größere Instanz

Merksatz:

Horizontal = mehr Systeme.
Vertikal = stärkeres System.

Hochverfügbarkeit

Hochverfügbarkeit bedeutet:

Dienste bleiben möglichst verfügbar,
auch wenn einzelne Komponenten ausfallen.

Mittel:

mehrere Instanzen
mehrere Verfügbarkeitszonen
Load Balancer
Replikation
Monitoring
Auto Scaling
Backup
Notfallplan

Merksatz:

Cloud ist nicht automatisch hochverfügbar.

Region und Verfügbarkeitszone

Region:

geografischer Standort des Cloud-Anbieters

Verfügbarkeitszone:

getrenntes Rechenzentrumssegment innerhalb einer Region

Merksatz:

Region beeinflusst Datenstandort und Latenz.
Zone beeinflusst Ausfallsicherheit innerhalb einer Region.

SLA, SLO und SLI

Begriff Bedeutung
SLA vertragliche Servicezusage
SLO Zielwert für Servicequalität
SLI Messwert für Servicequalität

Merksatz:

SLI misst.
SLO setzt Ziel.
SLA ist Zusage.

Infrastructure as Code

Infrastructure as Code wird abgekürzt:

IaC

Dabei wird Infrastruktur als Code beschrieben.

Beispiele:

Netzwerke
Subnetze
Firewalls
Rollen
VMs
Datenbanken
Load Balancer
Speicher

Vorteile:

wiederholbar
versionierbar
dokumentiert
automatisierbar
prüfbar

Merksatz:

IaC beschreibt Infrastruktur als Code.

Configuration Drift

Configuration Drift bedeutet:

Die echte Konfiguration weicht von der geplanten Konfiguration ab.

Ursachen:

manuelle Änderungen
Notfalländerungen
fehlende Dokumentation
unterschiedliche Umgebungen

Merksatz:

Configuration Drift erschwert Betrieb und Sicherheit.

Change Management und Rollback

Change Management bedeutet:

Änderungen werden geplant,
geprüft,
freigegeben,
umgesetzt
und dokumentiert.

Rollback bedeutet:

Änderung zurücknehmen.

Merksatz:

Jede kritische Änderung braucht Dokumentation und Rückweg.

Runbook

Ein Runbook ist eine Schritt-für-Schritt-Anleitung für Betriebsaufgaben.

Beispiele:

Backup wiederherstellen
Alarm bearbeiten
Zertifikat erneuern
Dienst neu starten
Failover auslösen
Benutzerzugriff prüfen

Merksatz:

Runbooks helfen bei wiederholbaren Betriebsabläufen.

Incident Response

Incident Response bedeutet:

Vorgehen bei Sicherheitsvorfällen oder größeren Störungen.

Schritte:

erkennen
bewerten
eindämmen
beseitigen
wiederherstellen
dokumentieren
verbessern

Merksatz:

Incident Response muss vor dem Vorfall vorbereitet sein.

Datenschutz und Compliance

Cloud-Nutzung muss rechtliche und organisatorische Vorgaben beachten.

Wichtige Fragen:

Welche Daten werden verarbeitet?
Wo werden Daten gespeichert?
Wer hat Zugriff?
Gibt es Auftragsverarbeitung?
Sind Daten verschlüsselt?
Gibt es Löschkonzepte?
Werden Logs personenbezogen?
Welche Verträge gelten?

Merksatz:

Cloud braucht Datenschutz- und Compliance-Prüfung.

Datenklassifizierung

Datenklassifizierung bedeutet:

Daten werden nach Schutzbedarf eingeteilt.

Beispiele:

öffentlich
intern
vertraulich
streng vertraulich
personenbezogen
geschäftskritisch

Merksatz:

Datenklasse bestimmt Schutzmaßnahmen.

Datenresidenz

Datenresidenz bedeutet:

Daten müssen in einem bestimmten Land oder einer bestimmten Region gespeichert werden.

Beispiel:

Speicherung innerhalb der EU

Merksatz:

Datenresidenz beschreibt,
wo Daten liegen dürfen.

Vendor Lock-in

Vendor Lock-in bedeutet:

starke Abhängigkeit von einem Anbieter.

Ursachen:

proprietäre Dienste
spezielle APIs
spezielle Datenformate
hohe Migrationskosten
fehlende Portabilität
Mitarbeitende kennen nur eine Plattform

Merksatz:

Vendor Lock-in früh beachten.

Exit-Strategie

Eine Exit-Strategie beschreibt, wie man einen Cloud-Dienst wieder verlassen kann.

Fragen:

Wie exportiere ich Daten?
In welchem Format?
Wie lange dauert Migration?
Welche Kosten entstehen?
Wie werden Daten beim Anbieter gelöscht?
Gibt es Alternativen?

Merksatz:

Cloud-Einstieg braucht auch Cloud-Ausstiegsplan.

Typische IHK-Fragen

In AP1 und AP2 kann zum Beispiel gefragt werden:

- Was bedeutet Cloud Computing?
- Was ist On-Premises?
- Was ist Public Cloud?
- Was ist Private Cloud?
- Was ist Hybrid Cloud?
- Was ist Multi Cloud?
- Was ist der Unterschied zwischen Hybrid Cloud und Multi Cloud?
- Was bedeutet IaaS?
- Was bedeutet PaaS?
- Was bedeutet SaaS?
- Was ist das Shared Responsibility Model?
- Wer ist bei IaaS für Betriebssystemupdates verantwortlich?
- Wer verwaltet bei SaaS Benutzer und Rechte?
- Was ist eine VPC?
- Was ist ein Public Subnet?
- Was ist ein Private Subnet?
- Was ist eine Security Group?
- Was ist ein Load Balancer?
- Was ist IAM?
- Was bedeutet Least Privilege?
- Was ist MFA?
- Was ist ein API-Schlüssel?
- Was ist ein Secret?
- Was ist Objektspeicher?
- Was ist Blockspeicher?
- Was ist Dateispeicher?
- Warum ist Cloud-Speicher kein Backup?
- Was bedeutet RPO?
- Was bedeutet RTO?
- Was ist Auto Scaling?
- Was ist horizontale Skalierung?
- Was ist vertikale Skalierung?
- Was ist ein SLA?
- Warum ist Cloud nicht automatisch sicher?
- Warum ist Cloud nicht automatisch günstiger?

Typische Prüfungsfallen

Cloud ist nicht automatisch günstiger.

Cloud ist nicht automatisch sicher.

Cloud ist nicht automatisch hochverfügbar.

Cloud ist nicht automatisch Backup.

Anbieter übernimmt nicht automatisch alles.

Daten,
Benutzer
und Rechte bleiben Kundenthema.

Public Cloud ist nicht automatisch unsicher.

Private Cloud ist nicht automatisch günstiger.

Hybrid Cloud ist nicht Multi Cloud.

Multi Cloud ist nicht automatisch Hybrid.

Virtualisierung allein ist keine Private Cloud.

IaaS ist Infrastruktur.

PaaS ist Plattform.

SaaS ist fertige Software.

Cloud-VM muss Kunde oft selbst patchen.

SaaS-Rechte bleiben Kundenthema.

Serverless heißt nicht serverfrei.

VPC und VNet sind virtuelle Cloud-Netze.

Public Subnet nicht für Datenbanken nutzen.

Private Subnet schützt vor direkter öffentlicher Erreichbarkeit.

Security Group ist virtuelle Firewall.

Öffentliche Buckets vermeiden.

Synchronisation ist kein Backup.

Replikation ist kein Backup.

Snapshot ist nicht immer Backup.

Backup ohne Restore-Test ist unsicher.

RPO und RTO nicht verwechseln.

IAM ist zentral für Cloud-Sicherheit.

Authentifizierung ist nicht Autorisierung.

MFA für Admins ist wichtig.

API-Schlüssel wie Passwörter behandeln.

Secrets nicht im Code speichern.

Verschlüsselung ersetzt keine Rechteverwaltung.

Monitoring und Logging unterscheiden.

Pay as you go braucht Kostenkontrolle.

Tags helfen bei Kosten und Verantwortung.

Horizontal und vertikal unterscheiden.

SLA,
SLO
und SLI nicht verwechseln.

Exit-Strategie früh planen.

Wichtige Begriffe kurz erklärt

Begriff Kurze Erklärung
Cloud IT-Ressourcen als Dienst
On-Premises lokal selbst betrieben
Public Cloud Anbieterplattform für viele Kunden
Private Cloud Cloud für eine Organisation
Hybrid Cloud lokale/private IT plus Cloud
Multi Cloud mehrere Cloud-Anbieter
Community Cloud Cloud für bestimmte Gemeinschaft
IaaS Infrastructure as a Service
PaaS Platform as a Service
SaaS Software as a Service
Shared Responsibility geteilte Verantwortung
Virtualisierung Aufteilung physischer Ressourcen
Container portable Anwendungseinheit
Kubernetes Container-Orchestrierung
Serverless keine Serververwaltung durch Kunden
FaaS Function as a Service
VPC Virtual Private Cloud
VNet Virtual Network
Public Subnet öffentlich angebundenes Subnetz
Private Subnet internes Subnetz
Security Group virtuelle Firewall-Regelgruppe
Load Balancer verteilt Anfragen
Health Check prüft Dienstgesundheit
Peering Verbindung zwischen Cloud-Netzen
Cloud-VPN VPN zu Cloud-Netz
Objektspeicher Speicher für Objekte
Bucket Speicherbehälter
Blockspeicher virtuelle Festplatte
Dateispeicher Datei- und Ordnerfreigabe
Backup zusätzliche Sicherung
Restore Wiederherstellung
RPO maximaler Datenverlust
RTO maximale Wiederherstellungszeit
Immutable Backup unveränderliches Backup
IAM Identity and Access Management
MFA Multi-Faktor-Authentifizierung
Least Privilege minimale notwendige Rechte
API-Schlüssel Zugriffsschlüssel für Programme
Secret geheime Information
RBAC rollenbasierte Zugriffskontrolle
ABAC attributbasierte Zugriffskontrolle
Tenant Cloud-Verwaltungsbereich
SSO Single Sign-On
OAuth 2.0 delegierte Autorisierung
OpenID Connect Authentifizierungserweiterung
KMS Key Management Service
Monitoring Zustandsüberwachung
Logging Ereignisprotokollierung
SIEM Sicherheitslog-Auswertung
Pay as you go Abrechnung nach Nutzung
Tagging Metadaten für Ressourcen
Rightsizing passende Ressourcengröße
Auto Scaling automatische Skalierung
SLA vertragliche Servicezusage
SLO Serviceziel
SLI Servicemesswert
IaC Infrastructure as Code
Configuration Drift Abweichung von Soll-Konfiguration
Runbook Betriebsanleitung
Incident Response Reaktion auf Vorfälle
Compliance Einhaltung von Vorgaben
Datenresidenz erlaubter Speicherort
Vendor Lock-in Anbieterabhängigkeit
Exit-Strategie Plan zum Verlassen eines Dienstes

IHK-sichere Gesamtformulierung

Cloud Computing bedeutet, dass IT-Ressourcen wie Rechenleistung, Speicher, Netzwerke, Plattformen oder Anwendungen über ein Netzwerk als Dienst bereitgestellt werden. Bei On-Premises betreibt ein Unternehmen seine IT lokal selbst. Public Cloud wird von einem Anbieter für viele Kunden bereitgestellt, Private Cloud für eine einzelne Organisation, Hybrid Cloud kombiniert lokale oder private IT mit Public Cloud, und Multi Cloud nutzt mehrere Cloud-Anbieter. Die wichtigsten Service-Modelle sind IaaS, PaaS und SaaS. Das Shared Responsibility Model beschreibt die geteilte Verantwortung zwischen Anbieter und Kunde. Auch in der Cloud bleiben Benutzer, Rechte, Daten, sichere Konfiguration, Backup, Monitoring, Kostenkontrolle, Datenschutz und Compliance wichtige Aufgaben des Kunden.


Wichtigste Merksätze

Cloud = IT-Ressourcen als Dienst.

Cloud ist kein einzelnes Produkt.

Cloud ist nicht automatisch sicher.

Cloud ist nicht automatisch günstig.

Cloud ist nicht automatisch hochverfügbar.

Cloud ist kein Backup.

On-Premises = lokal selbst betrieben.

Public Cloud = Anbieterplattform für viele Kunden.

Private Cloud = Cloud für eine Organisation.

Hybrid Cloud = lokal plus Cloud.

Multi Cloud = mehrere Anbieter.

IaaS = Infrastruktur.

PaaS = Plattform.

SaaS = fertige Software.

Shared Responsibility = geteilte Verantwortung.

Daten bleiben Kundenthema.

Benutzer bleiben Kundenthema.

Rechte bleiben Kundenthema.

Cloud-VM muss Kunde oft selbst patchen.

SaaS braucht Rechteverwaltung.

Serverless heißt keine Serververwaltung durch Kunden.

VPC und VNet sind virtuelle Cloud-Netze.

Public Subnet nur für öffentliche Komponenten.

Private Subnet für interne Ressourcen.

Datenbanken nicht öffentlich bereitstellen.

Security Groups sind virtuelle Firewall-Regeln.

Cloud-VPN braucht Routen beidseitig.

Objektspeicher für unstrukturierte Daten.

Blockspeicher für VMs und Datenbanken.

Dateispeicher für Freigaben.

Öffentliche Buckets vermeiden.

Backup regelmäßig testen.

RPO = Datenverlust.

RTO = Wiederherstellungszeit.

IAM entscheidet,
wer was darf.

MFA für Admins erzwingen.

Least Privilege immer beachten.

API-Schlüssel schützen.

Secrets sicher verwalten.

Verschlüsselung ersetzt keine Rechte.

Monitoring zeigt Zustand.

Logging zeigt Ereignisse.

Kosten aktiv überwachen.

Tags pflegen.

Auto Scaling braucht Regeln.

Horizontal = mehr Instanzen.

Vertikal = größere Instanz.

IaC macht Infrastruktur wiederholbar.

Configuration Drift vermeiden.

Runbooks helfen im Betrieb.

Incident Response vorbereiten.

Datenschutz und Compliance prüfen.

Exit-Strategie früh planen.