devops.straight8.de - Benutzerbeiträge [de]

Transparent Data Encryption (TDE)

2026-02-05T15:08:05Z

89.247.173.51: Die Seite wurde neu angelegt: „== Transparent Data Encryption (TDE) == '''Transparent Data Encryption (TDE)''' ist eine Technologie, die von großen Datenbankherstellern (wie Microsoft SQL Server, Oracle und Azure SQL) eingesetzt wird, um ruhende Daten (Data-at-Rest) automatisch zu verschlüsseln. Der Name „transparent“ leitet sich daraus ab, dass die Anwendung, die auf die Datenbank zugreift, von der Verschlüsselung nichts bemerkt. === 1. Funktionsweise === TDE arbeitet auf d…“

== Transparent Data Encryption (TDE) ==

'''Transparent Data Encryption (TDE)''' ist eine Technologie, die von großen Datenbankherstellern (wie Microsoft SQL Server, Oracle und Azure SQL) eingesetzt wird, um ruhende Daten (Data-at-Rest) automatisch zu verschlüsseln. Der Name „transparent“ leitet sich daraus ab, dass die Anwendung, die auf die Datenbank zugreift, von der Verschlüsselung nichts bemerkt.

=== 1. Funktionsweise ===
TDE arbeitet auf der Dateisystemebene. Die Verschlüsselung erfolgt in Echtzeit beim Schreiben der Daten auf die Festplatte und die Entschlüsselung beim Lesen in den Arbeitsspeicher.
* Wenn die Datenbank-Engine eine Seite vom Datenträger liest, wird sie entschlüsselt.
* Wenn eine Seite zurück auf den Datenträger geschrieben wird, wird sie verschlüsselt.
Da dieser Prozess innerhalb der Datenbank-Engine abläuft, bleiben Indizes, Sortierungen und Suchfunktionen voll funktionsfähig.

=== 2. Die Schlüsselhierarchie ===
TDE nutzt in der Regel eine mehrstufige Hierarchie, um die Sicherheit zu erhöhen:
# '''Data Encryption Key (DEK):''' Ein symmetrischer Schlüssel, der die eigentlichen Daten in der Datenbankdatei verschlüsselt.
# '''Key Encryption Key (KEK) / Master Key:''' Der DEK wird wiederum mit einem Master-Key verschlüsselt. Dieser Master-Key wird oft in einem externen Key Management Service (KMS) oder einem Hardware Security Module (HSM) gespeichert.

=== 3. Vorteile von TDE ===

* '''Keine Code-Änderungen:''' Da die Verschlüsselung auf Datenbankebene stattfindet, muss die Anwendung nicht angepasst werden.
* '''Umfassender Schutz:''' Nicht nur die Datenbankdateien (.mdf, .dbf), sondern auch Log-Dateien und Backups werden automatisch mit verschlüsselt.
* '''Geringer Verwaltungsaufwand:''' TDE lässt sich in modernen Cloud-Umgebungen oft per Mausklick aktivieren.
* '''Performance:''' Moderne CPUs verfügen über Befehlssatzerweiterungen (wie AES-NI), wodurch der Performance-Verlust oft im vernachlässigbaren Bereich (unter 3-5%) liegt.

=== 4. Grenzen von TDE ===

* '''Schutz endet an der Datenbank:''' Sobald ein berechtigter Nutzer oder eine kompromittierte Anwendung Daten abfragt, liegen diese im RAM und auf dem Übertragungsweg im Klartext vor (sofern nicht zusätzlich TLS genutzt wird).
* '''Kein Schutz vor DBAs:''' Ein Datenbankadministrator mit entsprechenden Berechtigungen kann die Daten im Klartext sehen, da die Datenbank sie für ihn automatisch entschlüsselt.

=== 5. TDE vs. Application Level Encryption (ALE) ===

{| class="wikitable"
! Merkmal !! Transparent Data Encryption (TDE) !! Application Level Encryption (ALE)
|-
| '''Transparenz''' || Vollständig transparent für die App || App muss Ver-/Entschlüsselung steuern
|-
| '''Suche/Indizes''' || Funktionieren uneingeschränkt || Stark eingeschränkt
|-
| '''Schutzbereich''' || Nur die physische Speicherschicht || Ende-zu-Ende (App bis Speicher)
|-
| '''Komplexität''' || Sehr gering || Hoch
|}

'''Zusammenfassend:''' TDE ist die ideale Basissicherung für Unternehmen, die Compliance-Anforderungen erfüllen müssen, ohne ihre bestehenden Anwendungen umbauen zu wollen. Es schützt effektiv gegen den Diebstahl von Backup-Medien oder Festplatten aus dem Rechenzentrum.

Daten-Verschlüsselung in der Cloud

2026-02-05T15:07:56Z

89.247.173.51: /* 2. Encryption at Rest (Ruhende Daten) */

Dies ist eine kompakte Einführung in die beiden essenziellen Säulen der Datensicherheit: die Verschlüsselung ruhender und übertragener Daten.

== Daten-Verschlüsselung in der Cloud ==

Verschlüsselung ist der wichtigste Schutzmechanismus, um die Vertraulichkeit und Integrität von Informationen sicherzustellen. In der Cloud-Architektur unterscheiden wir grundsätzlich zwischen zwei Zuständen von Daten, die jeweils unterschiedliche Schutzmaßnahmen erfordern.

=== 1. Encryption in Transit (Datenübertragung) ===
'''Encryption in Transit''' schützt Daten, während sie sich über ein Netzwerk bewegen – sei es über das öffentliche Internet oder innerhalb des internen Cloud-Netzwerks.

* '''Ziel:''' Schutz vor "Man-in-the-Middle"-Angriffen und Abhören der Kommunikation.
* '''Technologien:'''
** '''TLS (Transport Layer Security):''' Der Standard für HTTPS-Verbindungen.
** '''mTLS (Mutual TLS):''' In Service Meshes üblich; hier authentifizieren sich sowohl Client als auch Server gegenseitig durch Zertifikate.
** '''IPsec:''' Häufig genutzt für VPN-Verbindungen zwischen On-Premise-Rechenzentren und der Cloud.

=== 2. Encryption at Rest (Ruhende Daten) ===
'''Encryption at Rest''' schützt Daten, die dauerhaft auf einem Speichermedium liegen (Festplatten, Objektspeicher, Datenbanken).

* '''Ziel:''' Schutz der Daten bei physischem Diebstahl der Hardware oder unbefugtem Zugriff auf die Speicherschicht.
* '''Ebenen der Verschlüsselung:'''
** '''Full Disk Encryption (FDE):''' Verschlüsselung der gesamten physikalischen oder virtuellen Festplatte.
** [[Application Level Encryption (ALE)|'''Application Level Encryption''']]: Die Anwendung verschlüsselt sensible Felder (z. B. Kreditkartennummern) selbst, bevor sie in die Datenbank geschrieben werden.
** '''[[Transparent Data Encryption (TDE)]]:''' Datenbank-Feature, bei dem Dateien automatisch beim Schreiben verschlüsselt und beim Lesen entschlüsselt werden.

=== 3. Schlüsselmanagement (KMS) ===
Verschlüsselung ist nur so sicher wie die Aufbewahrung der kryptografischen Schlüssel. Cloud-Anbieter bieten hierfür '''Key Management Services (KMS)''' an:

* '''Customer Master Keys (CMK):''' Der Hauptschlüssel, der oft in einem Hardware Security Module (HSM) sicher aufbewahrt wird.
* '''Envelope Encryption:''' Ein Verfahren, bei dem Daten mit einem Datenschlüssel verschlüsselt werden und dieser Datenschlüssel wiederum mit einem Master-Key verschlüsselt wird. Dies optimiert die Performance bei großen Datenmengen.

=== 4. Vergleich der Zustände ===

{| class="wikitable"
! Merkmal !! Encryption in Transit !! Encryption at Rest
|-
| '''Wann?''' || Während der Bewegung (Netzwerk). || Während der Speicherung (Disk/DB).
|-
| '''Primäre Bedrohung''' || Abfangen von Paketen (Sniffing). || Unbefugter Zugriff auf Datenträger.
|-
| '''Werkzeug''' || SSL/TLS Zertifikate. || AES-256, KMS, Disk Encryption.
|}

=== 5. Zusammenfassung ===
Eine moderne Cloud-Strategie verfolgt den "Zero Trust"-Ansatz: Daten werden an jedem Punkt verschlüsselt. Während TLS die "Röhre" schützt, durch die Daten fließen, sorgt die Verschlüsselung At-Rest dafür, dass die Daten selbst dann wertlos sind, wenn sie in die falschen Hände geraten.

'''Zusammenfassend:''' Verschlüsselung ist in der Cloud heute kein optionales Feature mehr, sondern durch regulatorische Anforderungen (wie DSGVO) und technische Best Practices der Standard für jede Applikation.

Application Level Encryption (ALE)

2026-02-05T15:02:00Z

89.247.173.51: Die Seite wurde neu angelegt: „== Application Level Encryption (ALE) == Während die Standard-Cloud-Verschlüsselung meist auf der Infrastrukturebene (z. B. Festplattenverschlüsselung) stattfindet, setzt die '''Application Level Encryption (ALE)''' direkt beim Entstehen der Daten an. Hierbei verschlüsselt die Anwendung sensible Informationen, ''bevor'' sie über das Netzwerk an eine Datenbank oder einen Speicher gesendet werden. === 1. Funktionsweise === Im Gegensatz zur transpar…“

== Application Level Encryption (ALE) ==

Während die Standard-Cloud-Verschlüsselung meist auf der Infrastrukturebene (z. B. Festplattenverschlüsselung) stattfindet, setzt die '''Application Level Encryption (ALE)''' direkt beim Entstehen der Daten an. Hierbei verschlüsselt die Anwendung sensible Informationen, ''bevor'' sie über das Netzwerk an eine Datenbank oder einen Speicher gesendet werden.

=== 1. Funktionsweise ===
Im Gegensatz zur transparenten Verschlüsselung (TDE), bei der die Datenbank die Verschlüsselung übernimmt, ist bei ALE die Anwendung im Besitz der Logik:
# Die Applikation empfängt einen sensiblen Wert (z. B. eine Sozialversicherungsnummer).
# Die Applikation fordert einen Datenschlüssel von einem Key Management Service (KMS) an.
# Der Wert wird innerhalb des RAMs der Anwendung verschlüsselt.
# Der bereits verschlüsselte Wert (Ciphertext) wird in die Datenbank geschrieben.

=== 2. Warum ALE? (Vorteile) ===

* '''Schutz vor privilegierten Nutzern:''' Selbst ein Datenbankadministrator (DBA) mit vollen Zugriffsrechten kann die Daten nicht lesen, da sie für die Datenbank nur als unleserlicher Zeichensalat erscheinen.
* '''Granularität:''' Es können gezielt einzelne Felder (Field-Level Encryption) verschlüsselt werden, anstatt die gesamte Datenbank zu verlangsamen.
* '''Cloud-Native Sicherheit:''' Da die Daten bereits verschlüsselt die App verlassen, sind sie auch während der Übertragung (In-Transit) und im Falle eines Datenbank-Breachs geschützt.
* '''Compliance:''' Erfüllt höchste Anforderungen (z. B. PCI-DSS oder HIPAA), da der "Cleartext" niemals die Vertrauenszone der Anwendung verlässt.

=== 3. Herausforderungen und Nachteile ===

* '''Komplexität:''' Die Entwickler müssen die Verschlüsselungslogik im Code implementieren und Fehler abfangen.
* '''Verlust von Suchfunktionen:''' Da die Datenbank den Inhalt nicht kennt, sind einfache Suchanfragen (z. B. `WHERE name LIKE 'Schm%'`) oder Sortierungen auf verschlüsselten Feldern nicht mehr ohne Weiteres möglich.
* '''Key Management:''' Die Anwendung benötigt eine sichere und hochverfügbare Verbindung zum Key Management System.

=== 4. ALE vs. Infrastructure Encryption ===

{| class="wikitable"
! Merkmal !! Infrastructure Encryption (TDE/Disk) !! Application Level Encryption (ALE)
|-
| '''Verschlüsselungsort''' || Storage / Datenbank-Engine || Innerhalb des Anwendungscodes
|-
| '''Sichtbarkeit für DBAs''' || Daten sind im Klartext lesbar || Daten sind verschlüsselt
|-
| '''Implementierung''' || "Ein-Klick"-Konfiguration in der Cloud || Erfordert Code-Änderungen
|-
| '''Performance-Impact''' || Minimal (Hardware-beschleunigt) || Höher (CPU-Last in der App)
|}

=== 5. Zusammenfassung ===
Application Level Encryption ist die "Königsdisziplin" des Datenschutzes. Sie folgt dem Prinzip des '''Separation of Duties''': Die Datenbank speichert die Daten zwar, hat aber nicht die Macht, sie zu verstehen. Dies ist insbesondere in Multi-Tenant-Umgebungen oder bei extrem sensiblen personenbezogenen Daten unverzichtbar.

'''Zusammenfassend:''' ALE bietet den stärksten Schutz gegen Datendiebstahl und Insider-Bedrohungen, erkauft diesen jedoch durch eine höhere Komplexität in der Softwareentwicklung.

Daten-Verschlüsselung in der Cloud

2026-02-05T15:01:47Z

89.247.173.51: /* 2. Encryption at Rest (Ruhende Daten) */

Dies ist eine kompakte Einführung in die beiden essenziellen Säulen der Datensicherheit: die Verschlüsselung ruhender und übertragener Daten.

== Daten-Verschlüsselung in der Cloud ==

Verschlüsselung ist der wichtigste Schutzmechanismus, um die Vertraulichkeit und Integrität von Informationen sicherzustellen. In der Cloud-Architektur unterscheiden wir grundsätzlich zwischen zwei Zuständen von Daten, die jeweils unterschiedliche Schutzmaßnahmen erfordern.

=== 1. Encryption in Transit (Datenübertragung) ===
'''Encryption in Transit''' schützt Daten, während sie sich über ein Netzwerk bewegen – sei es über das öffentliche Internet oder innerhalb des internen Cloud-Netzwerks.

* '''Ziel:''' Schutz vor "Man-in-the-Middle"-Angriffen und Abhören der Kommunikation.
* '''Technologien:'''
** '''TLS (Transport Layer Security):''' Der Standard für HTTPS-Verbindungen.
** '''mTLS (Mutual TLS):''' In Service Meshes üblich; hier authentifizieren sich sowohl Client als auch Server gegenseitig durch Zertifikate.
** '''IPsec:''' Häufig genutzt für VPN-Verbindungen zwischen On-Premise-Rechenzentren und der Cloud.

=== 2. Encryption at Rest (Ruhende Daten) ===
'''Encryption at Rest''' schützt Daten, die dauerhaft auf einem Speichermedium liegen (Festplatten, Objektspeicher, Datenbanken).

* '''Ziel:''' Schutz der Daten bei physischem Diebstahl der Hardware oder unbefugtem Zugriff auf die Speicherschicht.
* '''Ebenen der Verschlüsselung:'''
** '''Full Disk Encryption (FDE):''' Verschlüsselung der gesamten physikalischen oder virtuellen Festplatte.
** [[Application Level Encryption (ALE)|'''Application Level Encryption:''']] Die Anwendung verschlüsselt sensible Felder (z. B. Kreditkartennummern) selbst, bevor sie in die Datenbank geschrieben werden.
** '''Transparent Data Encryption (TDE):''' Datenbank-Feature, bei dem Dateien automatisch beim Schreiben verschlüsselt und beim Lesen entschlüsselt werden.

=== 3. Schlüsselmanagement (KMS) ===
Verschlüsselung ist nur so sicher wie die Aufbewahrung der kryptografischen Schlüssel. Cloud-Anbieter bieten hierfür '''Key Management Services (KMS)''' an:

* '''Customer Master Keys (CMK):''' Der Hauptschlüssel, der oft in einem Hardware Security Module (HSM) sicher aufbewahrt wird.
* '''Envelope Encryption:''' Ein Verfahren, bei dem Daten mit einem Datenschlüssel verschlüsselt werden und dieser Datenschlüssel wiederum mit einem Master-Key verschlüsselt wird. Dies optimiert die Performance bei großen Datenmengen.

=== 4. Vergleich der Zustände ===

{| class="wikitable"
! Merkmal !! Encryption in Transit !! Encryption at Rest
|-
| '''Wann?''' || Während der Bewegung (Netzwerk). || Während der Speicherung (Disk/DB).
|-
| '''Primäre Bedrohung''' || Abfangen von Paketen (Sniffing). || Unbefugter Zugriff auf Datenträger.
|-
| '''Werkzeug''' || SSL/TLS Zertifikate. || AES-256, KMS, Disk Encryption.
|}

=== 5. Zusammenfassung ===
Eine moderne Cloud-Strategie verfolgt den "Zero Trust"-Ansatz: Daten werden an jedem Punkt verschlüsselt. Während TLS die "Röhre" schützt, durch die Daten fließen, sorgt die Verschlüsselung At-Rest dafür, dass die Daten selbst dann wertlos sind, wenn sie in die falschen Hände geraten.

'''Zusammenfassend:''' Verschlüsselung ist in der Cloud heute kein optionales Feature mehr, sondern durch regulatorische Anforderungen (wie DSGVO) und technische Best Practices der Standard für jede Applikation.

Daten-Verschlüsselung in der Cloud

2026-02-05T14:56:26Z

89.247.173.51:

Dies ist eine kompakte Einführung in die beiden essenziellen Säulen der Datensicherheit: die Verschlüsselung ruhender und übertragener Daten.

== Daten-Verschlüsselung in der Cloud ==

Verschlüsselung ist der wichtigste Schutzmechanismus, um die Vertraulichkeit und Integrität von Informationen sicherzustellen. In der Cloud-Architektur unterscheiden wir grundsätzlich zwischen zwei Zuständen von Daten, die jeweils unterschiedliche Schutzmaßnahmen erfordern.

=== 1. Encryption in Transit (Datenübertragung) ===
'''Encryption in Transit''' schützt Daten, während sie sich über ein Netzwerk bewegen – sei es über das öffentliche Internet oder innerhalb des internen Cloud-Netzwerks.

* '''Ziel:''' Schutz vor "Man-in-the-Middle"-Angriffen und Abhören der Kommunikation.
* '''Technologien:'''
** '''TLS (Transport Layer Security):''' Der Standard für HTTPS-Verbindungen.
** '''mTLS (Mutual TLS):''' In Service Meshes üblich; hier authentifizieren sich sowohl Client als auch Server gegenseitig durch Zertifikate.
** '''IPsec:''' Häufig genutzt für VPN-Verbindungen zwischen On-Premise-Rechenzentren und der Cloud.

=== 2. Encryption at Rest (Ruhende Daten) ===
'''Encryption at Rest''' schützt Daten, die dauerhaft auf einem Speichermedium liegen (Festplatten, Objektspeicher, Datenbanken).

* '''Ziel:''' Schutz der Daten bei physischem Diebstahl der Hardware oder unbefugtem Zugriff auf die Speicherschicht.
* '''Ebenen der Verschlüsselung:'''
** '''Full Disk Encryption (FDE):''' Verschlüsselung der gesamten physikalischen oder virtuellen Festplatte.
** '''Application Level Encryption:''' Die Anwendung verschlüsselt sensible Felder (z. B. Kreditkartennummern) selbst, bevor sie in die Datenbank geschrieben werden.
** '''Transparent Data Encryption (TDE):''' Datenbank-Feature, bei dem Dateien automatisch beim Schreiben verschlüsselt und beim Lesen entschlüsselt werden.

=== 3. Schlüsselmanagement (KMS) ===
Verschlüsselung ist nur so sicher wie die Aufbewahrung der kryptografischen Schlüssel. Cloud-Anbieter bieten hierfür '''Key Management Services (KMS)''' an:

* '''Customer Master Keys (CMK):''' Der Hauptschlüssel, der oft in einem Hardware Security Module (HSM) sicher aufbewahrt wird.
* '''Envelope Encryption:''' Ein Verfahren, bei dem Daten mit einem Datenschlüssel verschlüsselt werden und dieser Datenschlüssel wiederum mit einem Master-Key verschlüsselt wird. Dies optimiert die Performance bei großen Datenmengen.

=== 4. Vergleich der Zustände ===

{| class="wikitable"
! Merkmal !! Encryption in Transit !! Encryption at Rest
|-
| '''Wann?''' || Während der Bewegung (Netzwerk). || Während der Speicherung (Disk/DB).
|-
| '''Primäre Bedrohung''' || Abfangen von Paketen (Sniffing). || Unbefugter Zugriff auf Datenträger.
|-
| '''Werkzeug''' || SSL/TLS Zertifikate. || AES-256, KMS, Disk Encryption.
|}

=== 5. Zusammenfassung ===
Eine moderne Cloud-Strategie verfolgt den "Zero Trust"-Ansatz: Daten werden an jedem Punkt verschlüsselt. Während TLS die "Röhre" schützt, durch die Daten fließen, sorgt die Verschlüsselung At-Rest dafür, dass die Daten selbst dann wertlos sind, wenn sie in die falschen Hände geraten.

'''Zusammenfassend:''' Verschlüsselung ist in der Cloud heute kein optionales Feature mehr, sondern durch regulatorische Anforderungen (wie DSGVO) und technische Best Practices der Standard für jede Applikation.

Daten-Verschlüsselung in der Cloud

2026-02-05T14:55:48Z

89.247.173.51: Die Seite wurde neu angelegt: „== Daten-Verschlüsselung in der Cloud == Verschlüsselung ist der wichtigste Schutzmechanismus, um die Vertraulichkeit und Integrität von Informationen sicherzustellen. In der Cloud-Architektur unterscheiden wir grundsätzlich zwischen zwei Zuständen von Daten, die jeweils unterschiedliche Schutzmaßnahmen erfordern. === 1. Encryption in Transit (Datenübertragung) === '''Encryption in Transit''' schützt Daten, während sie sich über ein Netzwerk b…“

== Daten-Verschlüsselung in der Cloud ==

Verschlüsselung ist der wichtigste Schutzmechanismus, um die Vertraulichkeit und Integrität von Informationen sicherzustellen. In der Cloud-Architektur unterscheiden wir grundsätzlich zwischen zwei Zuständen von Daten, die jeweils unterschiedliche Schutzmaßnahmen erfordern.

=== 1. Encryption in Transit (Datenübertragung) ===
'''Encryption in Transit''' schützt Daten, während sie sich über ein Netzwerk bewegen – sei es über das öffentliche Internet oder innerhalb des internen Cloud-Netzwerks.

* '''Ziel:''' Schutz vor "Man-in-the-Middle"-Angriffen und Abhören der Kommunikation.
* '''Technologien:'''
** '''TLS (Transport Layer Security):''' Der Standard für HTTPS-Verbindungen.
** '''mTLS (Mutual TLS):''' In Service Meshes üblich; hier authentifizieren sich sowohl Client als auch Server gegenseitig durch Zertifikate.
** '''IPsec:''' Häufig genutzt für VPN-Verbindungen zwischen On-Premise-Rechenzentren und der Cloud.

=== 2. Encryption at Rest (Ruhende Daten) ===
'''Encryption at Rest''' schützt Daten, die dauerhaft auf einem Speichermedium liegen (Festplatten, Objektspeicher, Datenbanken).

* '''Ziel:''' Schutz der Daten bei physischem Diebstahl der Hardware oder unbefugtem Zugriff auf die Speicherschicht.
* '''Ebenen der Verschlüsselung:'''
** '''Full Disk Encryption (FDE):''' Verschlüsselung der gesamten physikalischen oder virtuellen Festplatte.
** '''Application Level Encryption:''' Die Anwendung verschlüsselt sensible Felder (z. B. Kreditkartennummern) selbst, bevor sie in die Datenbank geschrieben werden.
** '''Transparent Data Encryption (TDE):''' Datenbank-Feature, bei dem Dateien automatisch beim Schreiben verschlüsselt und beim Lesen entschlüsselt werden.

=== 3. Schlüsselmanagement (KMS) ===
Verschlüsselung ist nur so sicher wie die Aufbewahrung der kryptografischen Schlüssel. Cloud-Anbieter bieten hierfür '''Key Management Services (KMS)''' an:

* '''Customer Master Keys (CMK):''' Der Hauptschlüssel, der oft in einem Hardware Security Module (HSM) sicher aufbewahrt wird.
* '''Envelope Encryption:''' Ein Verfahren, bei dem Daten mit einem Datenschlüssel verschlüsselt werden und dieser Datenschlüssel wiederum mit einem Master-Key verschlüsselt wird. Dies optimiert die Performance bei großen Datenmengen.

=== 4. Vergleich der Zustände ===

{| class="wikitable"
! Merkmal !! Encryption in Transit !! Encryption at Rest
|-
| '''Wann?''' || Während der Bewegung (Netzwerk). || Während der Speicherung (Disk/DB).
|-
| '''Primäre Bedrohung''' || Abfangen von Paketen (Sniffing). || Unbefugter Zugriff auf Datenträger.
|-
| '''Werkzeug''' || SSL/TLS Zertifikate. || AES-256, KMS, Disk Encryption.
|}

=== 5. Zusammenfassung ===
Eine moderne Cloud-Strategie verfolgt den "Zero Trust"-Ansatz: Daten werden an jedem Punkt verschlüsselt. Während TLS die "Röhre" schützt, durch die Daten fließen, sorgt die Verschlüsselung At-Rest dafür, dass die Daten selbst dann wertlos sind, wenn sie in die falschen Hände geraten.

'''Zusammenfassend:''' Verschlüsselung ist in der Cloud heute kein optionales Feature mehr, sondern durch regulatorische Anforderungen (wie DSGVO) und technische Best Practices der Standard für jede Applikation.

Shared Responsibility Model

2026-02-05T14:55:35Z

89.247.173.51: /* 2. Verantwortung des Kunden */

== Das Shared Responsibility Model ==

Das '''Shared Responsibility Model''' ist eine vertragliche und operative Abgrenzung zwischen einem Cloud-Service-Provider (CSP) wie AWS, Azure oder Google Cloud und dem Kunden. Die goldene Regel lautet: Der Anbieter ist verantwortlich für die Sicherheit '''der''' Cloud, der Kunde ist verantwortlich für die Sicherheit '''in''' der Cloud.

=== 1. Verantwortung des Cloud-Anbieters ===
Der Anbieter schützt die Infrastruktur, die alle in der Cloud angebotenen Dienste ausführt. Dazu gehören:
* '''Physische Sicherheit:''' Schutz der Rechenzentren (Zugangskontrollen, Kameras, Stromversorgung).
* '''Hardware-Infrastruktur:''' Wartung der Server, Speichergeräte und Netzwerkkomponenten.
* '''Software-Infrastruktur:''' Sicherheit der Virtualisierungsschicht (Hypervisor) und der verwalteten Dienste.

=== 2. Verantwortung des Kunden ===
Die Verantwortung des Kunden hängt stark vom gewählten Servicemodell ab, umfasst aber im Kern:
* '''Daten:''' [[Daten-Verschlüsselung in der Cloud|Verschlüsselung (At-Rest und In-Transit)]] sowie Backup der eigenen Daten.
* '''Identitäts- und Zugriffsmanagement (IAM):''' Wer darf auf welche Ressourcen zugreifen? (Passwortrichtlinien, MFA).
* '''Konfiguration:''' Sicherheitsgruppen, Firewalls und Betriebssystem-Updates (bei IaaS).

=== 3. Verschiebung je nach Servicemodell ===
Die Grenze der Verantwortung verschiebt sich, je mehr Management-Aufgaben der Anbieter übernimmt:

{| class="wikitable"
! Modell !! Beispiel !! Wer macht was?
|-
| '''IaaS''' (Infrastructure as a Service) || EC2, Azure VMs || Der Kunde verwaltet fast alles: Betriebssystem, Middleware und Apps.
|-
| '''PaaS''' (Platform as a Service) || App Service, Lambda || Der Anbieter verwaltet das OS; der Kunde nur den Code und die Daten.
|-
| '''SaaS''' (Software as a Service) || Microsoft 365, Salesforce || Der Anbieter verwaltet fast alles; der Kunde nur die Nutzer und Daten.
|}

=== 4. Häufige Missverständnisse ===
Ein weit verbreiteter Irrtum ist, dass Daten in der Cloud automatisch "sicher" und "gesichert" (Backup) sind.
* Wenn ein Nutzer versehentlich Daten löscht (menschliches Versagen), ist das in der Regel kein Fehler des Cloud-Anbieters.
* Die Konfiguration einer Firewall (z. B. "Port 80 für die ganze Welt öffnen") liegt allein in der Hand des Kunden.

=== 5. Zusammenfassung ===
Das Modell hilft Unternehmen zu verstehen, wo ihre Sicherheitsbemühungen enden und wo sie beginnen müssen. Es verhindert "Sicherheitslücken durch Annahme", indem es klare Grenzen zieht.

'''Zusammenfassend:''' Der Cloud-Anbieter liefert die sicheren Bausteine, aber der Kunde ist dafür verantwortlich, diese Bausteine zu einem sicheren Haus zusammenzusetzen.

Shared Responsibility Model

2026-02-05T14:52:07Z

89.247.173.51: Die Seite wurde neu angelegt: „== Das Shared Responsibility Model == Das '''Shared Responsibility Model''' ist eine vertragliche und operative Abgrenzung zwischen einem Cloud-Service-Provider (CSP) wie AWS, Azure oder Google Cloud und dem Kunden. Die goldene Regel lautet: Der Anbieter ist verantwortlich für die Sicherheit '''der''' Cloud, der Kunde ist verantwortlich für die Sicherheit '''in''' der Cloud. === 1. Verantwortung des Cloud-Anbieters === Der Anbieter schützt die Infr…“

== Das Shared Responsibility Model ==

Das '''Shared Responsibility Model''' ist eine vertragliche und operative Abgrenzung zwischen einem Cloud-Service-Provider (CSP) wie AWS, Azure oder Google Cloud und dem Kunden. Die goldene Regel lautet: Der Anbieter ist verantwortlich für die Sicherheit '''der''' Cloud, der Kunde ist verantwortlich für die Sicherheit '''in''' der Cloud.

=== 1. Verantwortung des Cloud-Anbieters ===
Der Anbieter schützt die Infrastruktur, die alle in der Cloud angebotenen Dienste ausführt. Dazu gehören:
* '''Physische Sicherheit:''' Schutz der Rechenzentren (Zugangskontrollen, Kameras, Stromversorgung).
* '''Hardware-Infrastruktur:''' Wartung der Server, Speichergeräte und Netzwerkkomponenten.
* '''Software-Infrastruktur:''' Sicherheit der Virtualisierungsschicht (Hypervisor) und der verwalteten Dienste.

=== 2. Verantwortung des Kunden ===
Die Verantwortung des Kunden hängt stark vom gewählten Servicemodell ab, umfasst aber im Kern:
* '''Daten:''' Verschlüsselung (At-Rest und In-Transit) sowie Backup der eigenen Daten.
* '''Identitäts- und Zugriffsmanagement (IAM):''' Wer darf auf welche Ressourcen zugreifen? (Passwortrichtlinien, MFA).
* '''Konfiguration:''' Sicherheitsgruppen, Firewalls und Betriebssystem-Updates (bei IaaS).

=== 3. Verschiebung je nach Servicemodell ===
Die Grenze der Verantwortung verschiebt sich, je mehr Management-Aufgaben der Anbieter übernimmt:

{| class="wikitable"
! Modell !! Beispiel !! Wer macht was?
|-
| '''IaaS''' (Infrastructure as a Service) || EC2, Azure VMs || Der Kunde verwaltet fast alles: Betriebssystem, Middleware und Apps.
|-
| '''PaaS''' (Platform as a Service) || App Service, Lambda || Der Anbieter verwaltet das OS; der Kunde nur den Code und die Daten.
|-
| '''SaaS''' (Software as a Service) || Microsoft 365, Salesforce || Der Anbieter verwaltet fast alles; der Kunde nur die Nutzer und Daten.
|}

=== 4. Häufige Missverständnisse ===
Ein weit verbreiteter Irrtum ist, dass Daten in der Cloud automatisch "sicher" und "gesichert" (Backup) sind.
* Wenn ein Nutzer versehentlich Daten löscht (menschliches Versagen), ist das in der Regel kein Fehler des Cloud-Anbieters.
* Die Konfiguration einer Firewall (z. B. "Port 80 für die ganze Welt öffnen") liegt allein in der Hand des Kunden.

=== 5. Zusammenfassung ===
Das Modell hilft Unternehmen zu verstehen, wo ihre Sicherheitsbemühungen enden und wo sie beginnen müssen. Es verhindert "Sicherheitslücken durch Annahme", indem es klare Grenzen zieht.

'''Zusammenfassend:''' Der Cloud-Anbieter liefert die sicheren Bausteine, aber der Kunde ist dafür verantwortlich, diese Bausteine zu einem sicheren Haus zusammenzusetzen.

Cloud & DevOps Spezialisierung

2026-02-05T14:51:56Z

89.247.173.51: /* Tag 1 – Cloud Computing Grundlagen */

= 2-Monats-Lernplan: Cloud & DevOps Spezialisierung (40 Tage) =

'''Cloud + DevOps''' ist genau die Art Spezialisierung, die vorhandene Web-, Server- und Linux-Skills massiv aufwertet und den Einstieg in ein höherpreisiges Marktsegment ermöglicht.

Ziel am Ende:
Du kannst eine produktionsnahe Webanwendung containerisiert deployen, per Terraform Infrastruktur aufbauen, mit [[CI/CD]] automatisiert ausrollen und grundlegende Cloud-Security umsetzen.

----

== PHASE 1 – Cloud-Grundlagen & Architektur (Tage 1–10) ==

'''Ziel:''' Verstehen, wie moderne Cloud-Infrastruktur aufgebaut ist

=== Tag 1 – Cloud Computing Grundlagen ===
* [[IaaS, PaaS und SaaS|IaaS vs PaaS vs SaaS]]
* Regionen, Zonen, [[Hochverfügbarkeit]]
* [[Shared Responsibility Model]]
'''Praxis:''' Skizziere eine einfache [[Web-App-Architektur]] in der Cloud

=== Tag 2 – AWS & Azure Überblick ===
* AWS: EC2, S3, RDS, IAM
* Azure: VM, Blob Storage, Azure SQL, Entra ID
'''Praxis:''' Accounts erstellen (AWS + Azure Free Tier)

=== Tag 3 – Virtuelle Server ===
* EC2 / Azure VM starten
* SSH-Zugang absichern (Key, Firewall)
'''Praxis:''' Linux-Server deployen und Nginx installieren

=== Tag 4 – Networking Basics ===
* VPC, Subnets, Security Groups
* Public vs Private Subnet
'''Praxis:''' Eigene VPC + Public Subnet einrichten

=== Tag 5 – Storage ===
* Objekt-Storage (S3/Blob)
* Block Storage (EBS)
'''Praxis:''' Statische Website in S3 hosten

=== Tag 6 – Datenbanken in der Cloud ===
* RDS / Azure Database
* Managed vs Self-Hosted
'''Praxis:''' MySQL/Postgres als Managed Service starten

=== Tag 7 – Identity & Access (IAM) ===
* Rollen, Policies, Least Privilege
'''Praxis:''' IAM-User mit eingeschränkten Rechten erstellen

=== Tag 8 – Cloud-Architektur Muster ===
* 3-Tier-Architektur
* Load Balancer + Auto Scaling
'''Praxis:''' Architekturdiagramm für skalierbare Web-App zeichnen

=== Tag 9 – Monitoring Basics ===
* CloudWatch / Azure Monitor
'''Praxis:''' CPU-Alarm konfigurieren

=== Tag 10 – Mini-Projekt 1 ===
Deploye eine einfache Web-App auf einem Cloud-Server mit DB

----

== PHASE 2 – Container & Kubernetes (Tage 11–20) ==

'''Ziel:''' Anwendungen portabel und skalierbar machen

=== Tag 11 – Docker Grundlagen ===
* Images, [[Container-Orchestrierung in der Cloud|Container]], Dockerfile
'''Praxis:''' Eigene Node/PHP/Python App containerisieren

=== Tag 12 – Docker Networking & Volumes ===
'''Praxis:''' DB + App per Docker Compose verbinden

=== Tag 13 – Docker Registry ===
* Docker Hub / GitHub Container Registry
'''Praxis:''' Image pushen

=== Tag 14 – Kubernetes Grundlagen ===
* Pods, Deployments, Services
'''Praxis:''' Minikube oder k3s lokal installieren

=== Tag 15 – Kubernetes Deployments ===
'''Praxis:''' Containerisierte App in Kubernetes deployen

=== Tag 16 – Services & Ingress ===
'''Praxis:''' App über Ingress Controller erreichbar machen

=== Tag 17 – ConfigMaps & Secrets ===
'''Praxis:''' DB-Passwort als Secret speichern

=== Tag 18 – Autoscaling ===
* Horizontal Pod Autoscaler
'''Praxis:''' CPU-basiertes Scaling testen

=== Tag 19 – Managed Kubernetes ===
* EKS / AKS / GKE Überblick
'''Praxis:''' Cluster in AWS EKS oder Azure AKS starten

=== Tag 20 – Mini-Projekt 2 ===
Die Web-App läuft jetzt in Kubernetes in der Cloud

----

== PHASE 3 – Infrastructure as Code (Terraform) (Tage 21–27) ==

'''Ziel:''' Infrastruktur automatisiert bereitstellen

=== Tag 21 – Terraform Grundlagen ===
* Provider, Resources, State
'''Praxis:''' EC2 per Terraform erstellen

=== Tag 22 – Variablen & Outputs ===
'''Praxis:''' Wiederverwendbare Config bauen

=== Tag 23 – Networking mit Terraform ===
'''Praxis:''' VPC + Subnet + Security Group per Code

=== Tag 24 – Datenbank & Storage per Terraform ===

=== Tag 25 – Terraform Module ===

=== Tag 26 – Remote State ===
* S3 Backend + Locking

=== Tag 27 – Mini-Projekt 3 ===
Ganze Infrastruktur per Terraform deployen

----

== PHASE 4 – CI/CD & DevOps Workflows (Tage 28–34) ==

'''Ziel:''' Automatisierte Deployments

=== Tag 28 – DevOps Prinzipien ===
* CI vs CD
* GitOps Grundidee

=== Tag 29 – GitHub Actions Basics ===
'''Praxis:''' Workflow für Build + Test

=== Tag 30 – Docker Build Pipeline ===
'''Praxis:''' Image automatisch bauen & pushen

=== Tag 31 – Kubernetes Deployment per CI/CD ===

=== Tag 32 – Terraform in CI/CD ===

=== Tag 33 – Rollbacks & Versionierung ===

=== Tag 34 – Mini-Projekt 4 ===
Push zu Git → automatisches Deployment in Kubernetes

----

== PHASE 5 – Cloud Security & Best Practices (Tage 35–40) ==

'''Ziel:''' Professionelle, sichere Infrastruktur

=== Tag 35 – Cloud Security Grundlagen ===
* Shared Responsibility
* Angriffsvektoren

=== Tag 36 – IAM Best Practices ===

=== Tag 37 – Netzwerksicherheit ===
* Private Subnets, Bastion Host

=== Tag 38 – Secrets Management ===
* AWS Secrets Manager / Azure Key Vault

=== Tag 39 – Logging & Incident Response ===

=== Tag 40 – Abschlussprojekt ===
'''Finales Projekt:'''
* Komplette Infrastruktur mit Terraform
* Kubernetes Cluster
* CI/CD Pipeline
* Sicherheitskonzept (IAM + Secrets + Private DB)

----

== Ergebnis nach 40 Tagen ==

Du kannst danach:

* Cloud-Infrastruktur planen
* Server & Netzwerke automatisiert aufbauen
* Apps containerisieren
* Kubernetes produktiv nutzen
* CI/CD Pipelines erstellen
* Sicherheitsgrundlagen professionell umsetzen

Das ist exakt das Skillset, das KMU, Agenturen und Startups aktuell nachfragen.

Resilienz-Mechanismen: Rate Limiting & Circuit Breaking

2026-02-05T14:46:37Z

89.247.173.51:

Dies ist eine kompakte Einführung in die Resilienz-Muster Rate Limiting und Circuit Breaking, die in modernen Cloud-Architekturen (oft via Envoy oder API Gateways) implementiert werden.

== Resilienz-Mechanismen: Rate Limiting & Circuit Breaking ==

In verteilten Systemen können Fehler in einem einzelnen Dienst kaskadierende Effekte auslösen, die das gesamte System lahmlegen. Um dies zu verhindern, kommen Schutzmechanismen zum Einsatz, die die Stabilität der Architektur sicherstellen.

=== 1. Rate Limiting (Drosselung) ===
'''Rate Limiting''' kontrolliert die Anzahl der Anfragen, die ein Nutzer oder ein Client innerhalb eines bestimmten Zeitraums an einen Dienst senden darf.

* '''Ziel:''' Schutz vor Überlastung (DoS-Angriffe), Schutz von Ressourcen und faire Verteilung der Kapazitäten zwischen verschiedenen Nutzern.
* '''Funktionsweise:''' Übersteigt die Anzahl der Anfragen ein definiertes Limit (z. B. 100 Requests pro Minute), wird der Zugriff verweigert – meist mit dem HTTP-Statuscode '''429 Too Many Requests'''.
* '''Algorithmen:'''
** ''Token Bucket:'' Ein "Eimer" füllt sich stetig mit Token; jeder Request verbraucht einen. Ist der Eimer leer, wird blockiert.
** ''Fixed Window:'' Einfache Zählung pro Zeitfenster (z. B. Minute).

=== 2. Circuit Breaking (Sicherungsschalter) ===
Der '''Circuit Breaker''' verhindert, dass ein Dienst versucht, eine Operation auszuführen, die höchstwahrscheinlich scheitern wird. Dies schont Ressourcen und verhindert "Staus" im Netzwerk.

* '''Ziel:''' Fehlertoleranz und Vermeidung von kaskadierenden Ausfällen (Cascading Failures).
* '''Die drei Zustände:'''
# '''Closed (Geschlossen):''' Der Normalzustand. Anfragen werden durchgelassen. Wenn Fehler auftreten, wird gezählt.
# '''Open (Offen):''' Bei Erreichen einer Fehlerschwelle "springt die Sicherung raus". Anfragen werden sofort mit einem Fehler beantwortet, ohne den Zieldienst überhaupt zu kontaktieren.
# '''Half-Open (Halboffen):''' Nach einer Wartezeit lässt der Schalter testweise einzelne Anfragen durch. Sind diese erfolgreich, schließt er sich wieder (Normalzustand).

=== 3. Vergleich der Mechanismen ===

{| class="wikitable"
! Merkmal !! Rate Limiting !! Circuit Breaking
|-
| '''Fokus''' || Schützt den Server vor zu vielen Anfragen (Quantität). || Schützt das System vor fehlerhaften Diensten (Qualität).
|-
| '''Auslöser''' || Zu hohe Frequenz durch den Client. || Zu hohe Fehlerrate des Ziel-Services.
|-
| '''Reaktion''' || "Warte bitte, du bist zu schnell." || "Versuche es gar nicht erst, der Dienst ist gerade kaputt."
|}

=== 4. Implementierung in der Cloud ===
Diese Mechanismen werden heute selten im Anwendungscode selbst programmiert, sondern an die Infrastruktur ausgelagert:
* '''Envoy / Service Mesh:''' Konfiguration von Schwellenwerten direkt im Sidecar-Proxy.
* '''API Gateways:''' Zentrales Management von API-Keys und deren Limits.

'''Zusammenfassend:''' Während Rate Limiting sicherstellt, dass die Last innerhalb der Kapazitätsgrenzen bleibt, sorgt Circuit Breaking dafür, dass Teilausfälle das System nicht komplett zum Einsturz bringen.

Resilienz-Mechanismen: Rate Limiting & Circuit Breaking

2026-02-05T14:45:43Z

89.247.173.51: Die Seite wurde neu angelegt: „== Resilienz-Mechanismen: Rate Limiting & Circuit Breaking == In verteilten Systemen können Fehler in einem einzelnen Dienst kaskadierende Effekte auslösen, die das gesamte System lahmlegen. Um dies zu verhindern, kommen Schutzmechanismen zum Einsatz, die die Stabilität der Architektur sicherstellen. === 1. Rate Limiting (Drosselung) === '''Rate Limiting''' kontrolliert die Anzahl der Anfragen, die ein Nutzer oder ein Client innerhalb eines bestimmte…“

== Resilienz-Mechanismen: Rate Limiting & Circuit Breaking ==

In verteilten Systemen können Fehler in einem einzelnen Dienst kaskadierende Effekte auslösen, die das gesamte System lahmlegen. Um dies zu verhindern, kommen Schutzmechanismen zum Einsatz, die die Stabilität der Architektur sicherstellen.

=== 1. Rate Limiting (Drosselung) ===
'''Rate Limiting''' kontrolliert die Anzahl der Anfragen, die ein Nutzer oder ein Client innerhalb eines bestimmten Zeitraums an einen Dienst senden darf.

* '''Ziel:''' Schutz vor Überlastung (DoS-Angriffe), Schutz von Ressourcen und faire Verteilung der Kapazitäten zwischen verschiedenen Nutzern.
* '''Funktionsweise:''' Übersteigt die Anzahl der Anfragen ein definiertes Limit (z. B. 100 Requests pro Minute), wird der Zugriff verweigert – meist mit dem HTTP-Statuscode '''429 Too Many Requests'''.
* '''Algorithmen:'''
** ''Token Bucket:'' Ein "Eimer" füllt sich stetig mit Token; jeder Request verbraucht einen. Ist der Eimer leer, wird blockiert.
** ''Fixed Window:'' Einfache Zählung pro Zeitfenster (z. B. Minute).

=== 2. Circuit Breaking (Sicherungsschalter) ===
Der '''Circuit Breaker''' verhindert, dass ein Dienst versucht, eine Operation auszuführen, die höchstwahrscheinlich scheitern wird. Dies schont Ressourcen und verhindert "Staus" im Netzwerk.

* '''Ziel:''' Fehlertoleranz und Vermeidung von kaskadierenden Ausfällen (Cascading Failures).
* '''Die drei Zustände:'''
# '''Closed (Geschlossen):''' Der Normalzustand. Anfragen werden durchgelassen. Wenn Fehler auftreten, wird gezählt.
# '''Open (Offen):''' Bei Erreichen einer Fehlerschwelle "springt die Sicherung raus". Anfragen werden sofort mit einem Fehler beantwortet, ohne den Zieldienst überhaupt zu kontaktieren.
# '''Half-Open (Halboffen):''' Nach einer Wartezeit lässt der Schalter testweise einzelne Anfragen durch. Sind diese erfolgreich, schließt er sich wieder (Normalzustand).

=== 3. Vergleich der Mechanismen ===

{| class="wikitable"
! Merkmal !! Rate Limiting !! Circuit Breaking
|-
| '''Fokus''' || Schützt den Server vor zu vielen Anfragen (Quantität). || Schützt das System vor fehlerhaften Diensten (Qualität).
|-
| '''Auslöser''' || Zu hohe Frequenz durch den Client. || Zu hohe Fehlerrate des Ziel-Services.
|-
| '''Reaktion''' || "Warte bitte, du bist zu schnell." || "Versuche es gar nicht erst, der Dienst ist gerade kaputt."
|}

=== 4. Implementierung in der Cloud ===
Diese Mechanismen werden heute selten im Anwendungscode selbst programmiert, sondern an die Infrastruktur ausgelagert:
* '''Envoy / Service Mesh:''' Konfiguration von Schwellenwerten direkt im Sidecar-Proxy.
* '''API Gateways:''' Zentrales Management von API-Keys und deren Limits.

'''Zusammenfassend:''' Während Rate Limiting sicherstellt, dass die Last innerhalb der Kapazitätsgrenzen bleibt, sorgt Circuit Breaking dafür, dass Teilausfälle das System nicht komplett zum Einsturz bringen.

Einführung: Sidecar-Proxy mit Envoy

2026-02-05T14:45:32Z

89.247.173.51: /* 4. Vorteile des Sidecar-Ansatzes */

== Einführung: Sidecar-Proxy mit Envoy ==

Das '''Sidecar-Muster''' ist ein Entwurfsmuster in der Softwarearchitektur, bei dem eine Hilfsanwendung (der Sidecar) neben einer Hauptanwendung platziert wird. Der weltweit am häufigsten eingesetzte Proxy für dieses Muster ist '''Envoy''', ein hochperformanter C++ Open-Source-Proxy.

=== 1. Was ist Envoy? ===
Envoy wurde ursprünglich von Lyft entwickelt und ist heute ein Projekt der Cloud Native Computing Foundation (CNCF). Es wurde speziell für Cloud-native Architekturen entworfen und zeichnet sich durch einen extrem geringen Ressourcenverbrauch sowie enorme Flexibilität aus.

=== 2. Funktionsweise des Sidecars ===
In einem Kubernetes-Cluster wird Envoy im selben '''Pod''' wie der eigentliche Anwendungs-Container betrieben.
* '''Interzeption:''' Der gesamte ein- und ausgehende Netzwerkverkehr der Anwendung wird durch den Envoy-Proxy geleitet.
* '''Abstraktion:''' Die Anwendung kommuniziert nur noch mit "localhost". Envoy kümmert sich um die Komplexität des restlichen Netzwerks (Service Discovery, TLS, Retries).

=== 3. Kernfunktionen von Envoy ===

* '''L3/L4 und L7 Proxy:''' Envoy kann sowohl auf der TCP-Ebene als auch auf der Anwendungsebene (HTTP, gRPC, MongoDB etc.) filtern und routen.
* '''Erweitertes Load Balancing:''' Unterstützt fortgeschrittene Verfahren wie P2C (Power of Two Choices) und Zone-Aware-Routing.
* '''Dynamische Konfiguration:''' Über die sogenannten '''xDS-APIs''' kann Envoy im laufenden Betrieb neu konfiguriert werden, ohne den Proxy neu starten zu müssen.
* '''Observability:''' Envoy generiert detaillierte Statistiken und Tracing-Daten (z. B. für Jaeger oder Zipkin) über jeden einzelnen Request.

=== 4. Vorteile des Sidecar-Ansatzes ===

* '''Sprachunabhängigkeit:''' Da die Netzwerklogik in Envoy ausgelagert ist, müssen Entwickler keine speziellen Bibliotheken für Retries oder Sicherheit in Java, Go oder Python implementieren.
* '''Zentrale Kontrolle:''' Sicherheitsrichtlinien (wie mTLS) können global über alle Services hinweg durchgesetzt werden, ohne den Code der Anwendung zu ändern.
* '''Resilienz:''' Envoy schützt die Anwendung durch Mechanismen wie [[Resilienz-Mechanismen: Rate Limiting & Circuit Breaking|''Rate Limiting'' und ''Circuit Breaking'']] vor Überlastung.

=== 5. Zusammenfassung ===
Envoy als Sidecar fungiert als intelligentes "Netzwerkkabel". Es entkoppelt die Anwendungslogik von der Netzwerklogik und bildet damit das Rückgrat moderner Service Meshes wie Istio oder AWS App Mesh.

'''Zusammenfassend:''' Während die Applikation sich auf ihre Geschäftslogik konzentriert, übernimmt Envoy die "schmutzige Arbeit" der Netzwerkkommunikation – sicher, schnell und beobachtbar.

Einführung: Sidecar-Proxy mit Envoy

2026-02-05T14:41:30Z

89.247.173.51: Die Seite wurde neu angelegt: „== Einführung: Sidecar-Proxy mit Envoy == Das '''Sidecar-Muster''' ist ein Entwurfsmuster in der Softwarearchitektur, bei dem eine Hilfsanwendung (der Sidecar) neben einer Hauptanwendung platziert wird. Der weltweit am häufigsten eingesetzte Proxy für dieses Muster ist '''Envoy''', ein hochperformanter C++ Open-Source-Proxy. === 1. Was ist Envoy? === Envoy wurde ursprünglich von Lyft entwickelt und ist heute ein Projekt der Cloud Native Computing…“

== Einführung: Sidecar-Proxy mit Envoy ==

Das '''Sidecar-Muster''' ist ein Entwurfsmuster in der Softwarearchitektur, bei dem eine Hilfsanwendung (der Sidecar) neben einer Hauptanwendung platziert wird. Der weltweit am häufigsten eingesetzte Proxy für dieses Muster ist '''Envoy''', ein hochperformanter C++ Open-Source-Proxy.

=== 1. Was ist Envoy? ===
Envoy wurde ursprünglich von Lyft entwickelt und ist heute ein Projekt der Cloud Native Computing Foundation (CNCF). Es wurde speziell für Cloud-native Architekturen entworfen und zeichnet sich durch einen extrem geringen Ressourcenverbrauch sowie enorme Flexibilität aus.

=== 2. Funktionsweise des Sidecars ===
In einem Kubernetes-Cluster wird Envoy im selben '''Pod''' wie der eigentliche Anwendungs-Container betrieben.
* '''Interzeption:''' Der gesamte ein- und ausgehende Netzwerkverkehr der Anwendung wird durch den Envoy-Proxy geleitet.
* '''Abstraktion:''' Die Anwendung kommuniziert nur noch mit "localhost". Envoy kümmert sich um die Komplexität des restlichen Netzwerks (Service Discovery, TLS, Retries).

=== 3. Kernfunktionen von Envoy ===

* '''L3/L4 und L7 Proxy:''' Envoy kann sowohl auf der TCP-Ebene als auch auf der Anwendungsebene (HTTP, gRPC, MongoDB etc.) filtern und routen.
* '''Erweitertes Load Balancing:''' Unterstützt fortgeschrittene Verfahren wie P2C (Power of Two Choices) und Zone-Aware-Routing.
* '''Dynamische Konfiguration:''' Über die sogenannten '''xDS-APIs''' kann Envoy im laufenden Betrieb neu konfiguriert werden, ohne den Proxy neu starten zu müssen.
* '''Observability:''' Envoy generiert detaillierte Statistiken und Tracing-Daten (z. B. für Jaeger oder Zipkin) über jeden einzelnen Request.

=== 4. Vorteile des Sidecar-Ansatzes ===

* '''Sprachunabhängigkeit:''' Da die Netzwerklogik in Envoy ausgelagert ist, müssen Entwickler keine speziellen Bibliotheken für Retries oder Sicherheit in Java, Go oder Python implementieren.
* '''Zentrale Kontrolle:''' Sicherheitsrichtlinien (wie mTLS) können global über alle Services hinweg durchgesetzt werden, ohne den Code der Anwendung zu ändern.
* '''Resilienz:''' Envoy schützt die Anwendung durch Mechanismen wie ''Rate Limiting'' und ''Circuit Breaking'' vor Überlastung.

=== 5. Zusammenfassung ===
Envoy als Sidecar fungiert als intelligentes "Netzwerkkabel". Es entkoppelt die Anwendungslogik von der Netzwerklogik und bildet damit das Rückgrat moderner Service Meshes wie Istio oder AWS App Mesh.

'''Zusammenfassend:''' Während die Applikation sich auf ihre Geschäftslogik konzentriert, übernimmt Envoy die "schmutzige Arbeit" der Netzwerkkommunikation – sicher, schnell und beobachtbar.

Hochverfügbarkeit

2026-02-05T14:41:18Z

89.247.173.51: /* 1. Das Sidecar-Prinzip */

== Hochverfügbarkeit (HA) in der Cloud-nativen Orchestrierung ==

'''Hochverfügbarkeit''' (High Availability, HA) beschreibt das Ziel, ein System so zu gestalten, dass es trotz des Ausfalls einzelner Komponenten (Server, Netzwerke, Rechenzentren) für den Nutzer unterbrechungsfrei erreichbar bleibt. In einer Container-Umgebung wird dies nicht nur durch Hardware-Redundanz, sondern primär durch intelligente Software-Steuerung erreicht.

=== 1. Die drei Säulen der HA in Container-Clustern ===

* '''Redundanz (Replikation):''' Ein Dienst läuft nie nur einmal. Die Orchestrierung (z. B. Kubernetes) sorgt dafür, dass mehrere Instanzen (Pods) desselben Dienstes über verschiedene physische Server verteilt sind.
* '''Health Checking:''' Der Orchestrator prüft kontinuierlich den Zustand ("Liveness") der Container. Reagiert ein Container nicht mehr, wird er automatisch terminiert und durch einen neuen ersetzt.
* '''Failover:''' Fällt ein ganzer Worker-Node (Server) aus, werden alle darauf befindlichen Workloads sofort auf andere, gesunde Knoten im Cluster verschoben.

=== 2. Multi-Zone & Multi-Region Deployments ===

Echte Hochverfügbarkeit in der Cloud nutzt die geografische Verteilung der Anbieter:
* '''Availability Zones (AZs):''' Ein Cluster erstreckt sich über mehrere separate Rechenzentren innerhalb einer Region. Fällt ein Rechenzentrum (z. B. durch Stromausfall) aus, übernehmen die anderen Zonen.
* '''Multi-Region:''' Für extrem kritische Anwendungen wird die Applikation in verschiedenen geografischen Regionen (z. B. Frankfurt und Dublin) gespiegelt, um selbst großflächige Katastrophen abzufangen.

=== 3. Die Rolle der Orchestrierung beim Lastmanagement ===

Die Hochverfügbarkeit wird durch zwei Skalierungsmechanismen unterstützt:
# '''Horizontal Pod Autoscaler (HPA):''' Erhöht die Anzahl der Container-Kopien bei steigender Last, um Überlastung zu vermeiden.
# '''Cluster Autoscaler:''' Fügt der Infrastruktur automatisch neue virtuelle Maschinen hinzu, wenn der Platz im Cluster für weitere Container nicht mehr ausreicht.

=== 4. Daten-Konsistenz als Herausforderung ===

Während zustandslose (stateless) Web-Server leicht zu replizieren sind, erfordern Datenbanken in HA-Szenarien besondere Konzepte:
* '''Read Replicas:''' Kopien der Datenbank für Lesezugriffe.
* '''Leader-Election:''' Ein automatisierter Prozess, der bei Ausfall des Haupt-Datenbankknotens sofort einen Nachfolger bestimmt.

'''Zusammenfassend:''' Hochverfügbarkeit in der Cloud ist kein statischer Zustand, sondern ein dynamischer Prozess. Die Container-Orchestrierung fungiert als automatischer Operator, der 24/7 sicherstellt, dass die Differenz zwischen dem "Soll-Zustand" (z. B. 5 laufende Instanzen) und dem "Ist-Zustand" immer Null beträgt.

= Service Mesh =

Ein '''Service Mesh''' ist die logische Fortführung der Container-Orchestrierung. Während Kubernetes verwaltet, wo Container laufen, verwaltet ein Service Mesh (wie '''Istio''' oder '''Linkerd'''), wie diese Container sicher und zuverlässig miteinander kommunizieren.

Man spricht hier oft von der Trennung zwischen der '''Data Plane''' (dem tatsächlichen Datenfluss) und der '''Control Plane''' (der Konfiguration).

== Erweiterung: Service Mesh Architektur ==

In einer komplexen Microservices-Landschaft reicht einfaches Load Balancing oft nicht mehr aus. Ein '''Service Mesh''' wird als dedizierte Infrastrukturschicht eingebaut, um die Kommunikation zwischen den Diensten (East-West-Traffic) zu steuern.

=== 1. Das Sidecar-Prinzip ===
Die wichtigste Komponente eines Service Mesh ist der '''[[Einführung: Sidecar-Proxy mit Envoy|Sidecar-Proxy]]''' (z. B. Envoy).
* Jedem Anwendungs-Container wird ein kleiner Proxy-Container zur Seite gestellt.
* Der Anwendungscode selbst weiß nichts vom Netzwerk; er sendet Anfragen einfach an "localhost".
* Der Sidecar übernimmt Aufgaben wie Verschlüsselung, Retries und Telemetrie.

=== 2. Zentrale Funktionen eines Service Mesh ===

* '''Mutual TLS (mTLS):''' Automatische Verschlüsselung der gesamten Kommunikation zwischen Services, ohne dass die Entwickler Zertifikate im Code verwalten müssen.
* '''Traffic Management:''' Feingranulare Steuerung, z. B. "Sende 5% des Traffics an die neue Version v2" (Canary Deployment).
* '''Resilience (Resilienz):'''
** ''Circuit Breaking:'' Wenn ein Service überlastet ist, kappt das Mesh die Verbindung kurzzeitig, um eine Kettenreaktion zu verhindern.
** ''Retries & Timeouts:'' Automatische Wiederholungsversuche bei Netzwerkfehlern.
* '''Observability:''' Detaillierte Einblicke, welcher Service wie lange braucht, um auf einen anderen zu antworten (Distributed Tracing).

=== 3. Vergleich: API Gateway vs. Service Mesh ===

{| class="wikitable"
! Merkmal !! API Gateway !! Service Mesh
|-
| '''Fokus''' || North-South (Nutzer zu App) || East-West (Service zu Service)
|-
| '''Aufgabe''' || Authentifizierung, Rate Limiting || Sicherheit, Zuverlässigkeit, Tracing
|-
| '''Ort''' || Am Rand des Netzwerks (Edge) || Überall im Cluster verteilt
|}

=== 4. Bekannte Implementierungen ===
* '''Istio:''' Sehr mächtig, hoher Funktionsumfang, aber komplex in der Verwaltung.
* '''Linkerd:''' Fokus auf Leichtgewichtigkeit und einfache Bedienung.
* '''Consul Connect:''' Gut geeignet für hybride Umgebungen (Cloud + On-Premise).

'''Zusammenfassend:''' Ein Service Mesh entlastet Entwickler von Netzwerk-Logik. Es sorgt dafür, dass die Kommunikation in einer Cloud-Native-Architektur genauso sicher und beobachtbar ist wie ein Monolith, trotz hunderter verteilter Einzelteile.

Hochverfügbarkeit

2026-02-05T14:34:02Z

89.247.173.51: Die Seite wurde neu angelegt: „== Hochverfügbarkeit (HA) in der Cloud-nativen Orchestrierung == '''Hochverfügbarkeit''' (High Availability, HA) beschreibt das Ziel, ein System so zu gestalten, dass es trotz des Ausfalls einzelner Komponenten (Server, Netzwerke, Rechenzentren) für den Nutzer unterbrechungsfrei erreichbar bleibt. In einer Container-Umgebung wird dies nicht nur durch Hardware-Redundanz, sondern primär durch intelligente Software-Steuerung erreicht. === 1. Die drei S…“

== Hochverfügbarkeit (HA) in der Cloud-nativen Orchestrierung ==

'''Hochverfügbarkeit''' (High Availability, HA) beschreibt das Ziel, ein System so zu gestalten, dass es trotz des Ausfalls einzelner Komponenten (Server, Netzwerke, Rechenzentren) für den Nutzer unterbrechungsfrei erreichbar bleibt. In einer Container-Umgebung wird dies nicht nur durch Hardware-Redundanz, sondern primär durch intelligente Software-Steuerung erreicht.

=== 1. Die drei Säulen der HA in Container-Clustern ===

* '''Redundanz (Replikation):''' Ein Dienst läuft nie nur einmal. Die Orchestrierung (z. B. Kubernetes) sorgt dafür, dass mehrere Instanzen (Pods) desselben Dienstes über verschiedene physische Server verteilt sind.
* '''Health Checking:''' Der Orchestrator prüft kontinuierlich den Zustand ("Liveness") der Container. Reagiert ein Container nicht mehr, wird er automatisch terminiert und durch einen neuen ersetzt.
* '''Failover:''' Fällt ein ganzer Worker-Node (Server) aus, werden alle darauf befindlichen Workloads sofort auf andere, gesunde Knoten im Cluster verschoben.

=== 2. Multi-Zone & Multi-Region Deployments ===

Echte Hochverfügbarkeit in der Cloud nutzt die geografische Verteilung der Anbieter:
* '''Availability Zones (AZs):''' Ein Cluster erstreckt sich über mehrere separate Rechenzentren innerhalb einer Region. Fällt ein Rechenzentrum (z. B. durch Stromausfall) aus, übernehmen die anderen Zonen.
* '''Multi-Region:''' Für extrem kritische Anwendungen wird die Applikation in verschiedenen geografischen Regionen (z. B. Frankfurt und Dublin) gespiegelt, um selbst großflächige Katastrophen abzufangen.

=== 3. Die Rolle der Orchestrierung beim Lastmanagement ===

Die Hochverfügbarkeit wird durch zwei Skalierungsmechanismen unterstützt:
# '''Horizontal Pod Autoscaler (HPA):''' Erhöht die Anzahl der Container-Kopien bei steigender Last, um Überlastung zu vermeiden.
# '''Cluster Autoscaler:''' Fügt der Infrastruktur automatisch neue virtuelle Maschinen hinzu, wenn der Platz im Cluster für weitere Container nicht mehr ausreicht.

=== 4. Daten-Konsistenz als Herausforderung ===

Während zustandslose (stateless) Web-Server leicht zu replizieren sind, erfordern Datenbanken in HA-Szenarien besondere Konzepte:
* '''Read Replicas:''' Kopien der Datenbank für Lesezugriffe.
* '''Leader-Election:''' Ein automatisierter Prozess, der bei Ausfall des Haupt-Datenbankknotens sofort einen Nachfolger bestimmt.

'''Zusammenfassend:''' Hochverfügbarkeit in der Cloud ist kein statischer Zustand, sondern ein dynamischer Prozess. Die Container-Orchestrierung fungiert als automatischer Operator, der 24/7 sicherstellt, dass die Differenz zwischen dem "Soll-Zustand" (z. B. 5 laufende Instanzen) und dem "Ist-Zustand" immer Null beträgt.

= Service Mesh =

Ein '''Service Mesh''' ist die logische Fortführung der Container-Orchestrierung. Während Kubernetes verwaltet, wo Container laufen, verwaltet ein Service Mesh (wie '''Istio''' oder '''Linkerd'''), wie diese Container sicher und zuverlässig miteinander kommunizieren.

Man spricht hier oft von der Trennung zwischen der '''Data Plane''' (dem tatsächlichen Datenfluss) und der '''Control Plane''' (der Konfiguration).

== Erweiterung: Service Mesh Architektur ==

In einer komplexen Microservices-Landschaft reicht einfaches Load Balancing oft nicht mehr aus. Ein '''Service Mesh''' wird als dedizierte Infrastrukturschicht eingebaut, um die Kommunikation zwischen den Diensten (East-West-Traffic) zu steuern.

=== 1. Das Sidecar-Prinzip ===
Die wichtigste Komponente eines Service Mesh ist der '''Sidecar-Proxy''' (z. B. Envoy).
* Jedem Anwendungs-Container wird ein kleiner Proxy-Container zur Seite gestellt.
* Der Anwendungscode selbst weiß nichts vom Netzwerk; er sendet Anfragen einfach an "localhost".
* Der Sidecar übernimmt Aufgaben wie Verschlüsselung, Retries und Telemetrie.

=== 2. Zentrale Funktionen eines Service Mesh ===

* '''Mutual TLS (mTLS):''' Automatische Verschlüsselung der gesamten Kommunikation zwischen Services, ohne dass die Entwickler Zertifikate im Code verwalten müssen.
* '''Traffic Management:''' Feingranulare Steuerung, z. B. "Sende 5% des Traffics an die neue Version v2" (Canary Deployment).
* '''Resilience (Resilienz):'''
** ''Circuit Breaking:'' Wenn ein Service überlastet ist, kappt das Mesh die Verbindung kurzzeitig, um eine Kettenreaktion zu verhindern.
** ''Retries & Timeouts:'' Automatische Wiederholungsversuche bei Netzwerkfehlern.
* '''Observability:''' Detaillierte Einblicke, welcher Service wie lange braucht, um auf einen anderen zu antworten (Distributed Tracing).

=== 3. Vergleich: API Gateway vs. Service Mesh ===

{| class="wikitable"
! Merkmal !! API Gateway !! Service Mesh
|-
| '''Fokus''' || North-South (Nutzer zu App) || East-West (Service zu Service)
|-
| '''Aufgabe''' || Authentifizierung, Rate Limiting || Sicherheit, Zuverlässigkeit, Tracing
|-
| '''Ort''' || Am Rand des Netzwerks (Edge) || Überall im Cluster verteilt
|}

=== 4. Bekannte Implementierungen ===
* '''Istio:''' Sehr mächtig, hoher Funktionsumfang, aber komplex in der Verwaltung.
* '''Linkerd:''' Fokus auf Leichtgewichtigkeit und einfache Bedienung.
* '''Consul Connect:''' Gut geeignet für hybride Umgebungen (Cloud + On-Premise).

'''Zusammenfassend:''' Ein Service Mesh entlastet Entwickler von Netzwerk-Logik. Es sorgt dafür, dass die Kommunikation in einer Cloud-Native-Architektur genauso sicher und beobachtbar ist wie ein Monolith, trotz hunderter verteilter Einzelteile.

Cloud & DevOps Spezialisierung

2026-02-05T14:28:28Z

89.247.173.51: /* Tag 1 – Cloud Computing Grundlagen */

= 2-Monats-Lernplan: Cloud & DevOps Spezialisierung (40 Tage) =

'''Cloud + DevOps''' ist genau die Art Spezialisierung, die vorhandene Web-, Server- und Linux-Skills massiv aufwertet und den Einstieg in ein höherpreisiges Marktsegment ermöglicht.

Ziel am Ende:
Du kannst eine produktionsnahe Webanwendung containerisiert deployen, per Terraform Infrastruktur aufbauen, mit [[CI/CD]] automatisiert ausrollen und grundlegende Cloud-Security umsetzen.

----

== PHASE 1 – Cloud-Grundlagen & Architektur (Tage 1–10) ==

'''Ziel:''' Verstehen, wie moderne Cloud-Infrastruktur aufgebaut ist

=== Tag 1 – Cloud Computing Grundlagen ===
* [[IaaS, PaaS und SaaS|IaaS vs PaaS vs SaaS]]
* Regionen, Zonen, [[Hochverfügbarkeit]]
* Shared Responsibility Model
'''Praxis:''' Skizziere eine einfache [[Web-App-Architektur]] in der Cloud

=== Tag 2 – AWS & Azure Überblick ===
* AWS: EC2, S3, RDS, IAM
* Azure: VM, Blob Storage, Azure SQL, Entra ID
'''Praxis:''' Accounts erstellen (AWS + Azure Free Tier)

=== Tag 3 – Virtuelle Server ===
* EC2 / Azure VM starten
* SSH-Zugang absichern (Key, Firewall)
'''Praxis:''' Linux-Server deployen und Nginx installieren

=== Tag 4 – Networking Basics ===
* VPC, Subnets, Security Groups
* Public vs Private Subnet
'''Praxis:''' Eigene VPC + Public Subnet einrichten

=== Tag 5 – Storage ===
* Objekt-Storage (S3/Blob)
* Block Storage (EBS)
'''Praxis:''' Statische Website in S3 hosten

=== Tag 6 – Datenbanken in der Cloud ===
* RDS / Azure Database
* Managed vs Self-Hosted
'''Praxis:''' MySQL/Postgres als Managed Service starten

=== Tag 7 – Identity & Access (IAM) ===
* Rollen, Policies, Least Privilege
'''Praxis:''' IAM-User mit eingeschränkten Rechten erstellen

=== Tag 8 – Cloud-Architektur Muster ===
* 3-Tier-Architektur
* Load Balancer + Auto Scaling
'''Praxis:''' Architekturdiagramm für skalierbare Web-App zeichnen

=== Tag 9 – Monitoring Basics ===
* CloudWatch / Azure Monitor
'''Praxis:''' CPU-Alarm konfigurieren

=== Tag 10 – Mini-Projekt 1 ===
Deploye eine einfache Web-App auf einem Cloud-Server mit DB

----

== PHASE 2 – Container & Kubernetes (Tage 11–20) ==

'''Ziel:''' Anwendungen portabel und skalierbar machen

=== Tag 11 – Docker Grundlagen ===
* Images, [[Container-Orchestrierung in der Cloud|Container]], Dockerfile
'''Praxis:''' Eigene Node/PHP/Python App containerisieren

=== Tag 12 – Docker Networking & Volumes ===
'''Praxis:''' DB + App per Docker Compose verbinden

=== Tag 13 – Docker Registry ===
* Docker Hub / GitHub Container Registry
'''Praxis:''' Image pushen

=== Tag 14 – Kubernetes Grundlagen ===
* Pods, Deployments, Services
'''Praxis:''' Minikube oder k3s lokal installieren

=== Tag 15 – Kubernetes Deployments ===
'''Praxis:''' Containerisierte App in Kubernetes deployen

=== Tag 16 – Services & Ingress ===
'''Praxis:''' App über Ingress Controller erreichbar machen

=== Tag 17 – ConfigMaps & Secrets ===
'''Praxis:''' DB-Passwort als Secret speichern

=== Tag 18 – Autoscaling ===
* Horizontal Pod Autoscaler
'''Praxis:''' CPU-basiertes Scaling testen

=== Tag 19 – Managed Kubernetes ===
* EKS / AKS / GKE Überblick
'''Praxis:''' Cluster in AWS EKS oder Azure AKS starten

=== Tag 20 – Mini-Projekt 2 ===
Die Web-App läuft jetzt in Kubernetes in der Cloud

----

== PHASE 3 – Infrastructure as Code (Terraform) (Tage 21–27) ==

'''Ziel:''' Infrastruktur automatisiert bereitstellen

=== Tag 21 – Terraform Grundlagen ===
* Provider, Resources, State
'''Praxis:''' EC2 per Terraform erstellen

=== Tag 22 – Variablen & Outputs ===
'''Praxis:''' Wiederverwendbare Config bauen

=== Tag 23 – Networking mit Terraform ===
'''Praxis:''' VPC + Subnet + Security Group per Code

=== Tag 24 – Datenbank & Storage per Terraform ===

=== Tag 25 – Terraform Module ===

=== Tag 26 – Remote State ===
* S3 Backend + Locking

=== Tag 27 – Mini-Projekt 3 ===
Ganze Infrastruktur per Terraform deployen

----

== PHASE 4 – CI/CD & DevOps Workflows (Tage 28–34) ==

'''Ziel:''' Automatisierte Deployments

=== Tag 28 – DevOps Prinzipien ===
* CI vs CD
* GitOps Grundidee

=== Tag 29 – GitHub Actions Basics ===
'''Praxis:''' Workflow für Build + Test

=== Tag 30 – Docker Build Pipeline ===
'''Praxis:''' Image automatisch bauen & pushen

=== Tag 31 – Kubernetes Deployment per CI/CD ===

=== Tag 32 – Terraform in CI/CD ===

=== Tag 33 – Rollbacks & Versionierung ===

=== Tag 34 – Mini-Projekt 4 ===
Push zu Git → automatisches Deployment in Kubernetes

----

== PHASE 5 – Cloud Security & Best Practices (Tage 35–40) ==

'''Ziel:''' Professionelle, sichere Infrastruktur

=== Tag 35 – Cloud Security Grundlagen ===
* Shared Responsibility
* Angriffsvektoren

=== Tag 36 – IAM Best Practices ===

=== Tag 37 – Netzwerksicherheit ===
* Private Subnets, Bastion Host

=== Tag 38 – Secrets Management ===
* AWS Secrets Manager / Azure Key Vault

=== Tag 39 – Logging & Incident Response ===

=== Tag 40 – Abschlussprojekt ===
'''Finales Projekt:'''
* Komplette Infrastruktur mit Terraform
* Kubernetes Cluster
* CI/CD Pipeline
* Sicherheitskonzept (IAM + Secrets + Private DB)

----

== Ergebnis nach 40 Tagen ==

Du kannst danach:

* Cloud-Infrastruktur planen
* Server & Netzwerke automatisiert aufbauen
* Apps containerisieren
* Kubernetes produktiv nutzen
* CI/CD Pipelines erstellen
* Sicherheitsgrundlagen professionell umsetzen

Das ist exakt das Skillset, das KMU, Agenturen und Startups aktuell nachfragen.

Container-Orchestrierung in der Cloud

2026-02-05T14:22:57Z

89.247.173.51: Die Seite wurde neu angelegt: „== Container-Orchestrierung in der Cloud == Während ein einzelner Container (z. B. Docker) eine Anwendung verpackt, kümmert sich die '''Orchestrierung''' um das Management von hunderten oder tausenden dieser Container über einen Cluster von Servern hinweg. Der Marktführer in diesem Bereich ist zweifellos '''Kubernetes (K8s)'''. Hier sind die zentralen Konzepte und Aufgaben einer Orchestrierungslösung: === 1. Kernaufgaben der Orchestrierung === Ein…“

== Container-Orchestrierung in der Cloud ==

Während ein einzelner Container (z. B. Docker) eine Anwendung verpackt, kümmert sich die '''Orchestrierung''' um das Management von hunderten oder tausenden dieser Container über einen Cluster von Servern hinweg. Der Marktführer in diesem Bereich ist zweifellos '''Kubernetes (K8s)'''.

Hier sind die zentralen Konzepte und Aufgaben einer Orchestrierungslösung:

=== 1. Kernaufgaben der Orchestrierung ===
Ein Orchestrator übernimmt Aufgaben, die manuell kaum zu bewältigen wären:

* '''Scheduling:''' Die Entscheidung, auf welchem physischen oder virtuellen Server ein Container gestartet werden soll (basierend auf verfügbaren Ressourcen wie CPU und RAM).
* '''Self-Healing:''' Wenn ein Container abstürzt oder ein Server ausfällt, startet der Orchestrator automatisch neue Instanzen auf gesunden Knoten.
* '''Horizontal Scaling:''' Automatisches Hinzufügen oder Entfernen von Container-Instanzen je nach aktueller Last.
* '''Service Discovery & Load Balancing:''' Container erhalten eine feste Netzwerkadresse und der Datenverkehr wird intelligent verteilt.

=== 2. Zentrale Architektur-Konzepte ===
In der Welt von Kubernetes arbeitet man mit folgenden Abstraktionen:

* '''Pods:''' Die kleinste Einheit. Ein Pod kapselt einen oder mehrere Container, die sich ein Netzwerk und Speicher teilen.
* '''Nodes:''' Die tatsächlichen Server (Worker), auf denen die Pods laufen.
* '''Control Plane (Master):''' Das Gehirn des Clusters, das den Soll-Zustand überwacht und Befehle an die Nodes gibt.

=== 3. Deployment-Strategien ===
Orchestrierung ermöglicht es, Software ohne Ausfallzeiten (Zero Downtime) zu aktualisieren:

* '''Rolling Updates:''' Ein alter Container nach dem anderen wird durch einen neuen ersetzt.
* '''Blue-Green Deployment:''' Eine komplett neue Version wird parallel zur alten hochgefahren; wenn alles läuft, wird der gesamte Traffic umgeschaltet.

=== 4. Cloud-Native Lösungen ===
Die großen Cloud-Anbieter bieten "Managed Kubernetes"-Dienste an, bei denen sie sich um die Wartung der Control Plane kümmern:

{| class="wikitable"
! Anbieter !! Dienstname
|-
| '''AWS''' || Elastic Kubernetes Service (EKS)
|-
| '''Azure''' || Azure Kubernetes Service (AKS)
|-
| '''Google Cloud''' || Google Kubernetes Engine (GKE)
|}

=== 5. Warum ist das wichtig? ===
Ohne Orchestrierung wäre eine '''Microservices-Architektur''' nicht wartbar. Sie ermöglicht es Entwicklern, sich auf den Code zu konzentrieren, während die Infrastruktur sich selbst verwaltet und bei Bedarf skaliert.

'''Zusammenfassend:''' Wenn Container die Zutaten sind, dann ist die Orchestrierung der Chefkoch, der sicherstellt, dass alle Gerichte gleichzeitig und in der richtigen Qualität beim Gast ankommen.

Cloud & DevOps Spezialisierung

2026-02-05T14:22:43Z

89.247.173.51: /* Tag 11 – Docker Grundlagen */

= 2-Monats-Lernplan: Cloud & DevOps Spezialisierung (40 Tage) =

'''Cloud + DevOps''' ist genau die Art Spezialisierung, die vorhandene Web-, Server- und Linux-Skills massiv aufwertet und den Einstieg in ein höherpreisiges Marktsegment ermöglicht.

Ziel am Ende:
Du kannst eine produktionsnahe Webanwendung containerisiert deployen, per Terraform Infrastruktur aufbauen, mit [[CI/CD]] automatisiert ausrollen und grundlegende Cloud-Security umsetzen.

----

== PHASE 1 – Cloud-Grundlagen & Architektur (Tage 1–10) ==

'''Ziel:''' Verstehen, wie moderne Cloud-Infrastruktur aufgebaut ist

=== Tag 1 – Cloud Computing Grundlagen ===
* [[IaaS, PaaS und SaaS|IaaS vs PaaS vs SaaS]]
* Regionen, Zonen, Hochverfügbarkeit
* Shared Responsibility Model
'''Praxis:''' Skizziere eine einfache [[Web-App-Architektur]] in der Cloud

=== Tag 2 – AWS & Azure Überblick ===
* AWS: EC2, S3, RDS, IAM
* Azure: VM, Blob Storage, Azure SQL, Entra ID
'''Praxis:''' Accounts erstellen (AWS + Azure Free Tier)

=== Tag 3 – Virtuelle Server ===
* EC2 / Azure VM starten
* SSH-Zugang absichern (Key, Firewall)
'''Praxis:''' Linux-Server deployen und Nginx installieren

=== Tag 4 – Networking Basics ===
* VPC, Subnets, Security Groups
* Public vs Private Subnet
'''Praxis:''' Eigene VPC + Public Subnet einrichten

=== Tag 5 – Storage ===
* Objekt-Storage (S3/Blob)
* Block Storage (EBS)
'''Praxis:''' Statische Website in S3 hosten

=== Tag 6 – Datenbanken in der Cloud ===
* RDS / Azure Database
* Managed vs Self-Hosted
'''Praxis:''' MySQL/Postgres als Managed Service starten

=== Tag 7 – Identity & Access (IAM) ===
* Rollen, Policies, Least Privilege
'''Praxis:''' IAM-User mit eingeschränkten Rechten erstellen

=== Tag 8 – Cloud-Architektur Muster ===
* 3-Tier-Architektur
* Load Balancer + Auto Scaling
'''Praxis:''' Architekturdiagramm für skalierbare Web-App zeichnen

=== Tag 9 – Monitoring Basics ===
* CloudWatch / Azure Monitor
'''Praxis:''' CPU-Alarm konfigurieren

=== Tag 10 – Mini-Projekt 1 ===
Deploye eine einfache Web-App auf einem Cloud-Server mit DB

----

== PHASE 2 – Container & Kubernetes (Tage 11–20) ==

'''Ziel:''' Anwendungen portabel und skalierbar machen

=== Tag 11 – Docker Grundlagen ===
* Images, [[Container-Orchestrierung in der Cloud|Container]], Dockerfile
'''Praxis:''' Eigene Node/PHP/Python App containerisieren

=== Tag 12 – Docker Networking & Volumes ===
'''Praxis:''' DB + App per Docker Compose verbinden

=== Tag 13 – Docker Registry ===
* Docker Hub / GitHub Container Registry
'''Praxis:''' Image pushen

=== Tag 14 – Kubernetes Grundlagen ===
* Pods, Deployments, Services
'''Praxis:''' Minikube oder k3s lokal installieren

=== Tag 15 – Kubernetes Deployments ===
'''Praxis:''' Containerisierte App in Kubernetes deployen

=== Tag 16 – Services & Ingress ===
'''Praxis:''' App über Ingress Controller erreichbar machen

=== Tag 17 – ConfigMaps & Secrets ===
'''Praxis:''' DB-Passwort als Secret speichern

=== Tag 18 – Autoscaling ===
* Horizontal Pod Autoscaler
'''Praxis:''' CPU-basiertes Scaling testen

=== Tag 19 – Managed Kubernetes ===
* EKS / AKS / GKE Überblick
'''Praxis:''' Cluster in AWS EKS oder Azure AKS starten

=== Tag 20 – Mini-Projekt 2 ===
Die Web-App läuft jetzt in Kubernetes in der Cloud

----

== PHASE 3 – Infrastructure as Code (Terraform) (Tage 21–27) ==

'''Ziel:''' Infrastruktur automatisiert bereitstellen

=== Tag 21 – Terraform Grundlagen ===
* Provider, Resources, State
'''Praxis:''' EC2 per Terraform erstellen

=== Tag 22 – Variablen & Outputs ===
'''Praxis:''' Wiederverwendbare Config bauen

=== Tag 23 – Networking mit Terraform ===
'''Praxis:''' VPC + Subnet + Security Group per Code

=== Tag 24 – Datenbank & Storage per Terraform ===

=== Tag 25 – Terraform Module ===

=== Tag 26 – Remote State ===
* S3 Backend + Locking

=== Tag 27 – Mini-Projekt 3 ===
Ganze Infrastruktur per Terraform deployen

----

== PHASE 4 – CI/CD & DevOps Workflows (Tage 28–34) ==

'''Ziel:''' Automatisierte Deployments

=== Tag 28 – DevOps Prinzipien ===
* CI vs CD
* GitOps Grundidee

=== Tag 29 – GitHub Actions Basics ===
'''Praxis:''' Workflow für Build + Test

=== Tag 30 – Docker Build Pipeline ===
'''Praxis:''' Image automatisch bauen & pushen

=== Tag 31 – Kubernetes Deployment per CI/CD ===

=== Tag 32 – Terraform in CI/CD ===

=== Tag 33 – Rollbacks & Versionierung ===

=== Tag 34 – Mini-Projekt 4 ===
Push zu Git → automatisches Deployment in Kubernetes

----

== PHASE 5 – Cloud Security & Best Practices (Tage 35–40) ==

'''Ziel:''' Professionelle, sichere Infrastruktur

=== Tag 35 – Cloud Security Grundlagen ===
* Shared Responsibility
* Angriffsvektoren

=== Tag 36 – IAM Best Practices ===

=== Tag 37 – Netzwerksicherheit ===
* Private Subnets, Bastion Host

=== Tag 38 – Secrets Management ===
* AWS Secrets Manager / Azure Key Vault

=== Tag 39 – Logging & Incident Response ===

=== Tag 40 – Abschlussprojekt ===
'''Finales Projekt:'''
* Komplette Infrastruktur mit Terraform
* Kubernetes Cluster
* CI/CD Pipeline
* Sicherheitskonzept (IAM + Secrets + Private DB)

----

== Ergebnis nach 40 Tagen ==

Du kannst danach:

* Cloud-Infrastruktur planen
* Server & Netzwerke automatisiert aufbauen
* Apps containerisieren
* Kubernetes produktiv nutzen
* CI/CD Pipelines erstellen
* Sicherheitsgrundlagen professionell umsetzen

Das ist exakt das Skillset, das KMU, Agenturen und Startups aktuell nachfragen.