21 Std vor
Die Konfiguration beschreibt, was sein soll. Der State merkt sich, was bereits echt existiert.
Beide sind Dateien mit Ressourcen drin, deshalb hält man sie für dasselbe. Doch sie beantworten verschiedene Fragen: den Soll-Zustand und den Ist-Stand.
Die Konfiguration ist der Bauplan: In Terraform-Dateien steht in deklarativer Sprache, was entstehen soll, etwa eine Security-Group, also eine Firewall-Regelgruppe in AWS. Sie beschreibt Eigenschaften, aber keine konkreten Cloud-Objekte. Ein Beispiel: eine Regel, die einen Port für HTTPS freigibt. Terraform liest sie bei jedem Lauf neu ein.
Der State ist das Gedächtnis von Terraform: eine Datei, die für jede Ressource der Konfiguration festhält, welche echte Ressource in der Cloud dazugehört, etwa über deren konkrete ID. Steht dort eine Security-Group mit einer ID, kennt Terraform genau dieses Objekt. Fehlt der State, kann Terraform bestehende Ressourcen nicht mehr verwalten.
Die Konfiguration ist der Wunsch, der State die Zuordnung zur Wirklichkeit. Beim Plan vergleicht Terraform drei Dinge – Konfiguration, State und reale Ressourcen – und leitet daraus die Änderungen ab.
Faustregel: Wer Änderungen plant, braucht zuerst einen aktuellen State, sonst sind Plan und Wirklichkeit auseinander. Deshalb liegt der State zentral in einem Remote-Backend wie S3, einem Speicher, den alle Beteiligten gemeinsam nutzen.
Vorsicht: Der State kann Passwörter im Klartext enthalten und ist wie ein Geheimnis zu schützen. Löschen ist keine Aufräumlösung, sondern verwirft nur das Gedächtnis und erzeugt Duplikate.
Der State ist nicht die Konfiguration, sondern das Gedächtnis, das beide verbindet. Ohne ihn weiß Terraform nicht, was es selbst angelegt hat.
📌 Konfiguration · State · Remote-Backend
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops #CloudSecurity
Beide sind Dateien mit Ressourcen drin, deshalb hält man sie für dasselbe. Doch sie beantworten verschiedene Fragen: den Soll-Zustand und den Ist-Stand.
Die Konfiguration ist der Bauplan: In Terraform-Dateien steht in deklarativer Sprache, was entstehen soll, etwa eine Security-Group, also eine Firewall-Regelgruppe in AWS. Sie beschreibt Eigenschaften, aber keine konkreten Cloud-Objekte. Ein Beispiel: eine Regel, die einen Port für HTTPS freigibt. Terraform liest sie bei jedem Lauf neu ein.
Der State ist das Gedächtnis von Terraform: eine Datei, die für jede Ressource der Konfiguration festhält, welche echte Ressource in der Cloud dazugehört, etwa über deren konkrete ID. Steht dort eine Security-Group mit einer ID, kennt Terraform genau dieses Objekt. Fehlt der State, kann Terraform bestehende Ressourcen nicht mehr verwalten.
Die Konfiguration ist der Wunsch, der State die Zuordnung zur Wirklichkeit. Beim Plan vergleicht Terraform drei Dinge – Konfiguration, State und reale Ressourcen – und leitet daraus die Änderungen ab.
Faustregel: Wer Änderungen plant, braucht zuerst einen aktuellen State, sonst sind Plan und Wirklichkeit auseinander. Deshalb liegt der State zentral in einem Remote-Backend wie S3, einem Speicher, den alle Beteiligten gemeinsam nutzen.
Vorsicht: Der State kann Passwörter im Klartext enthalten und ist wie ein Geheimnis zu schützen. Löschen ist keine Aufräumlösung, sondern verwirft nur das Gedächtnis und erzeugt Duplikate.
Der State ist nicht die Konfiguration, sondern das Gedächtnis, das beide verbindet. Ohne ihn weiß Terraform nicht, was es selbst angelegt hat.
📌 Konfiguration · State · Remote-Backend
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #devops #CloudSecurity
1 Tag vor
Terraform funktioniert wie ein Stadtplaner mit einem Grundbuch. Ohne das Grundbuch wüsste er nicht, welche Grundstücke ihm überhaupt gehören.
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
Das Grundbuch verzeichnet jedes Grundstück mit Nummer, Besitzer und aktuellem Zustand. Will der Planer ein Haus umbauen, schlägt er erst nach: Ist das Grundstück bereits eingetragen? Ist der Zustand dort noch aktuell? Erst dann entscheidet er, ob gebaut, umgebaut oder abgerissen wird.
Bei Terraform heißt das Grundbuch State: eine Datei mit der Zuordnung zwischen dem Namen in der Konfiguration, also den Textdateien, die Infrastruktur beschreiben, und der realen Ressource in der Cloud. Bei jedem terraform plan oder terraform apply vergleicht Terraform drei Dinge: den gewünschten Zustand, den gespeicherten Ist-Zustand und die echte Cloud. Aus der Differenz ergibt sich, was erstellt, geändert oder gelöscht wird.
Konkret: In der Konfiguration steht eine EC2-Instanz (virtuelle Maschine bei AWS) mit dem Namen webserver. Im State liegt dazu die ID der realen Instanz, etwa i-abc123. Nur über diese Zuordnung findet Terraform die Instanz wieder, wenn sie verkleinert oder gelöscht werden soll. Löscht jemand die Instanz in der Konsole, meldet terraform plan die Abweichung und schlägt vor, sie neu zu erstellen.
Das Bild hat eine Grenze: Ein Grundbuch kann von Hand weitergeschrieben werden, der State nicht. Jede manuelle Änderung zerstört die Zuordnung. Deshalb gilt in der Praxis: State im verschlüsselten Backend (zentraler Ablageort) speichern, Zugriff strikt begrenzen.
Der State ist Terraforms Gedächtnis, kein Protokoll. Er wird geschützt, geteilt und nie von Hand editiert.
📌 State · Backend · Zuordnung
📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #CloudSecurity
2 Tage vor
Viele halten einen festen Zugangsschlüssel in der Konfigurationsdatei für eine ganz normale Lösung. Dabei ist genau das der schwerwiegendste Fehler beim Cloud-Zugriff.
Viele denken, der Schlüssel gehöre in die Konfiguration wie einst ein Datenbankpasswort. Plausibel, weil der Access Key (ein dauerhaftes Schlüsselpaar für den Zugriff per Programm) bequem ist: einmal eintragen, die Anwendung läuft.
Tatsächlich gilt: Ein geleakter fester Schlüssel bleibt gültig, bis jemand ihn widerruft. IAM (Identity and Access Management) regelt zwar, wer welche Handlungen auf welchen Ressourcen ausführen darf – ein hinterlegter Schlüssel umgeht jede kurzlebige Kontrolle. Stattdessen vergeben IAM-Rollen temporäre Anmeldeinformationen über den Dienst STS (Security Token Service, der kurzlebige Zugangsdaten ausstellt). Anwendungen auf EC2, ECS oder Lambda erhalten ihre Rechte über zugewiesene Rollen, nicht über fest hinterlegte Schlüssel.
Der Irrtum entsteht, weil die Rollen-Lösung unsichtbar arbeitet: Temporäre Zugangsdaten kommen automatisch über die Instanzmetadaten-Adresse. Der feste Schlüssel steht sichtbar da und funktioniert – bis er in einem Repository landet.
Ein typischer Fall: Eine Anwendung auf einem EC2-Server braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel zu hinterlegen, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Langlebige Schlüssel, die unvermeidbar bleiben, werden rotiert und möglichst durch Rollen oder Identity Center ersetzt.
Woran man es erkennt: In Konfigurationsdateien oder Umgebungsvariablen stehen dauerhafte Schlüsselpaare, deren letzte Prüfung niemand kennt.
Feste Schlüssel sind nicht der praktische Standard, sondern ein stehendes Restrisiko. Rollen geben kurzlebige Zugangsdaten – und was kurzlebig ist, ist nach dem Ablauf wertlos.
📚 Cloud von Grund auf · Tag 4 von 30
#aws #CloudSecurity #devops
Viele denken, der Schlüssel gehöre in die Konfiguration wie einst ein Datenbankpasswort. Plausibel, weil der Access Key (ein dauerhaftes Schlüsselpaar für den Zugriff per Programm) bequem ist: einmal eintragen, die Anwendung läuft.
Tatsächlich gilt: Ein geleakter fester Schlüssel bleibt gültig, bis jemand ihn widerruft. IAM (Identity and Access Management) regelt zwar, wer welche Handlungen auf welchen Ressourcen ausführen darf – ein hinterlegter Schlüssel umgeht jede kurzlebige Kontrolle. Stattdessen vergeben IAM-Rollen temporäre Anmeldeinformationen über den Dienst STS (Security Token Service, der kurzlebige Zugangsdaten ausstellt). Anwendungen auf EC2, ECS oder Lambda erhalten ihre Rechte über zugewiesene Rollen, nicht über fest hinterlegte Schlüssel.
Der Irrtum entsteht, weil die Rollen-Lösung unsichtbar arbeitet: Temporäre Zugangsdaten kommen automatisch über die Instanzmetadaten-Adresse. Der feste Schlüssel steht sichtbar da und funktioniert – bis er in einem Repository landet.
Ein typischer Fall: Eine Anwendung auf einem EC2-Server braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel zu hinterlegen, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Langlebige Schlüssel, die unvermeidbar bleiben, werden rotiert und möglichst durch Rollen oder Identity Center ersetzt.
Woran man es erkennt: In Konfigurationsdateien oder Umgebungsvariablen stehen dauerhafte Schlüsselpaare, deren letzte Prüfung niemand kennt.
Feste Schlüssel sind nicht der praktische Standard, sondern ein stehendes Restrisiko. Rollen geben kurzlebige Zugangsdaten – und was kurzlebig ist, ist nach dem Ablauf wertlos.
📚 Cloud von Grund auf · Tag 4 von 30
#aws #CloudSecurity #devops
2 Tage vor
Die meisten Anfänger tippen los und wundern sich über langsame Builds. Dabei ist ein Dockerfile ein Rezept mit fester Anweisungsreihenfolge.
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
Ein Dockerfile beschreibt Schritt für Schritt, wie ein Container-Image entsteht. Das Image ist die unveränderliche Vorlage, aus der Container gestartet werden.
Zuerst steht die FROM-Anweisung: Sie legt ein Basis-Image fest, etwa eine schlanke Linux-Distribution mit Python. Jede Anweisung erzeugt dabei eine Schicht, und die Reihenfolge entscheidet über den Build-Cache. Selten geänderte Schritte wie Abhängigkeiten gehören deshalb vor häufig geänderten wie dem Quellcode.
Dann folgt COPY. Es kopiert Dateien aus dem Build-Kontext in das Image, also aus dem Verzeichnis, das dem Build mitgegeben wird. Ein häufiger Irrtum: Dateien außerhalb dieses Kontexts sind schlicht nicht verfügbar. Bewährt hat sich, zuerst nur die Datei mit den Abhängigkeiten zu kopieren und zu installieren, dann erst den Quellcode.
Danach kommen RUN für Installationsbefehle sowie USER. Ohne USER läuft der Prozess im Container als root, also mit vollen Rechten. Die Anweisung USER setzt einen unprivilegierten Benutzer und senkt das Risiko, falls der Container kompromittiert wird.
Zuletzt legen CMD den Startbefehl und EXPOSE den Port fest. EXPOSE dokumentiert nur, welchen Port die Anwendung im Container erreicht; geöffnet wird er erst beim Start mit docker run. Der Befehl docker build arbeitet das Dockerfile ab und erzeugt das Image, versehen mit einem Tag wie 1.2. Solche Tags sind beweglich; ein Digest wie sha256:… identifiziert dagegen genau einen Inhalt.
Ein Dockerfile ist also kein Skript, sondern ein Rezept: Jede Anweisung baut eine Schicht, und deren Reihenfolge bestimmt Tempo und Sicherheit des Images.
📌 Schichten und Build-Cache · COPY und Build-Kontext · USER statt root
📚 Cloud von Grund auf · Tag 3 von 30
#docker #devops #CloudSecurity
3 Tage vor
Der Schlüssel in der Konfigurationsdatei funktioniert monatelang, ohne dass jemand ihn prüft. Genau das ist das Problem.
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.
Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.
Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.
So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.
Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.
📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Die meisten denken bei Cloud-Sicherheit zuerst an Firewalls. Dabei entscheidet viel früher, wer im Konto überhaupt welche Aktion ausführen darf.
Wer hier falsch liegt, öffnet Fremden die Tür. Deshalb lohnt es sich, die drei Bausteine zu kennen.
📦 Ein Principal ist die Identität, die handelt. Das kann ein IAM-Benutzer sein, eine dauerhafte Anmeldung für eine Person, oder eine IAM-Rolle. Den Root-Benutzer, das Hauptkonto der Verwaltung, nur für Ausnahmen nutzen: AWS empfiehlt, ihn nicht für tägliche Aufgaben zu verwenden, MFA (Multi-Faktor-Authentifizierung) zu aktivieren und keine Zugangsschlüssel für ihn anzulegen.
🔑 Eine Richtlinie (Policy) ist ein Dokument mit Rechten. Sie beschreibt erlaubte oder verbotene Aktionen auf benannten Ressourcen, etwa Lesen eines bestimmten S3-Buckets, eines Speicherbehälters im AWS-Dienst S3. Nach Least Privilege erlaubt sie nur die Aktionen, die eine Aufgabe braucht. Eine Policy mit Action "*" und Resource "*" widerspricht diesem Grundsatz.
📈 Die Zuordnung verknüpft Identität und Rechte. Wird eine Richtlinie an einen Benutzer angehängt, erhält er deren Rechte. Beim Auswerten mehrerer Richtlinien gilt: Fehlt eine Erlaubnis, wird der Zugriff verweigert. Eine ausdrückliche Deny-Anweisung schlägt jede Allow-Anweisung. Rollen vergeben temporäre Anmeldeinformationen über den Security Token Service (STS), der kurzbewehrte Schlüssel ausgibt, und wechseln deshalb den Inhaber; Anwendungen auf EC2, ECS oder Lambda erhalten Rechte so statt über fest hinterlegte Schlüssel. Langlebige Schlüssel von IAM-Benutzern regelmäßig rotieren oder durch Rollen oder das Identity Center, die zentrale Benutzer- und Rechteverwaltung in AWS, ersetzen.
Eine Rolle heißt nicht die Person selbst, sondern eine Identität, die man nur für die Dauer einer Aufgabe übernimmt.
📌 Principal · Richtlinie · Zuordnung
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Wer hier falsch liegt, öffnet Fremden die Tür. Deshalb lohnt es sich, die drei Bausteine zu kennen.
📦 Ein Principal ist die Identität, die handelt. Das kann ein IAM-Benutzer sein, eine dauerhafte Anmeldung für eine Person, oder eine IAM-Rolle. Den Root-Benutzer, das Hauptkonto der Verwaltung, nur für Ausnahmen nutzen: AWS empfiehlt, ihn nicht für tägliche Aufgaben zu verwenden, MFA (Multi-Faktor-Authentifizierung) zu aktivieren und keine Zugangsschlüssel für ihn anzulegen.
🔑 Eine Richtlinie (Policy) ist ein Dokument mit Rechten. Sie beschreibt erlaubte oder verbotene Aktionen auf benannten Ressourcen, etwa Lesen eines bestimmten S3-Buckets, eines Speicherbehälters im AWS-Dienst S3. Nach Least Privilege erlaubt sie nur die Aktionen, die eine Aufgabe braucht. Eine Policy mit Action "*" und Resource "*" widerspricht diesem Grundsatz.
📈 Die Zuordnung verknüpft Identität und Rechte. Wird eine Richtlinie an einen Benutzer angehängt, erhält er deren Rechte. Beim Auswerten mehrerer Richtlinien gilt: Fehlt eine Erlaubnis, wird der Zugriff verweigert. Eine ausdrückliche Deny-Anweisung schlägt jede Allow-Anweisung. Rollen vergeben temporäre Anmeldeinformationen über den Security Token Service (STS), der kurzbewehrte Schlüssel ausgibt, und wechseln deshalb den Inhaber; Anwendungen auf EC2, ECS oder Lambda erhalten Rechte so statt über fest hinterlegte Schlüssel. Langlebige Schlüssel von IAM-Benutzern regelmäßig rotieren oder durch Rollen oder das Identity Center, die zentrale Benutzer- und Rechteverwaltung in AWS, ersetzen.
Eine Rolle heißt nicht die Person selbst, sondern eine Identität, die man nur für die Dauer einer Aufgabe übernimmt.
📌 Principal · Richtlinie · Zuordnung
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Eine neue Regel in der Security Group setzen, und trotzdem kommt kein Traffic durch. Meistens fehlt nicht die Regel, sondern sie zeigt auf die falsche Quelle.
Eine Security Group ist eine Firewall, die direkt an der Netzwerkschnittstelle einer Instanz hängt und jeden ein- und ausgehenden Datenverkehr prüft. Sie entscheidet in der Cloud, ob ein Server überhaupt erreichbar ist.
Zuerst denkt man an die Quelle einer Regel, also an die Frage, wer sich verbinden darf. Dort muss keine einzelne IP-Adresse stehen: Wenn die Anwendungsschicht eine eigene Security Group hat, kann genau diese Gruppe als Quelle eingetragen werden. So erhalten nur diese Instanzen Zugriff auf die Datenbank.
Dann wird die Richtung festgelegt. Regeln sind nur Erlaubnisse, nie Verbote. Wer HTTPS von überall erlaubt, lässt genau dieses herein; alles andere bleibt draußen. Die Gruppe gilt je Netzwerkschnittstelle, und Instanzen können mehrere Gruppen haben, deren Regeln sich addieren.
Danach folgt der Punkt, der Einsteiger verwirrt: Security Groups sind zustandsbehaftet. Ruft der Server eine Außenstelle auf, wird die Antwort automatisch eingelassen. Eine zusätzliche Regel für die Rückrichtung ist unnötig und ein häufiger Irrtum.
Zuletzt die Grenze: Öffentlich heißt nicht ungefiltert. Auch in einem öffentlichen Subnetz entscheidet die Security Group, was durchgeht. Eine Adresse gezielt blocken kann sie nicht; dafür braucht es die zustandslose Network ACL auf Subnetzebene.
Security Groups sperren niemanden aus, sondern lassen gewolltes herein. Die Antwort auf eine erlaubte Anfrage läuft immer mit.
📌 Zustandsbehaftet · Nur Erlaubnisregeln · Quelle kann Gruppe sein
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
Eine Security Group ist eine Firewall, die direkt an der Netzwerkschnittstelle einer Instanz hängt und jeden ein- und ausgehenden Datenverkehr prüft. Sie entscheidet in der Cloud, ob ein Server überhaupt erreichbar ist.
Zuerst denkt man an die Quelle einer Regel, also an die Frage, wer sich verbinden darf. Dort muss keine einzelne IP-Adresse stehen: Wenn die Anwendungsschicht eine eigene Security Group hat, kann genau diese Gruppe als Quelle eingetragen werden. So erhalten nur diese Instanzen Zugriff auf die Datenbank.
Dann wird die Richtung festgelegt. Regeln sind nur Erlaubnisse, nie Verbote. Wer HTTPS von überall erlaubt, lässt genau dieses herein; alles andere bleibt draußen. Die Gruppe gilt je Netzwerkschnittstelle, und Instanzen können mehrere Gruppen haben, deren Regeln sich addieren.
Danach folgt der Punkt, der Einsteiger verwirrt: Security Groups sind zustandsbehaftet. Ruft der Server eine Außenstelle auf, wird die Antwort automatisch eingelassen. Eine zusätzliche Regel für die Rückrichtung ist unnötig und ein häufiger Irrtum.
Zuletzt die Grenze: Öffentlich heißt nicht ungefiltert. Auch in einem öffentlichen Subnetz entscheidet die Security Group, was durchgeht. Eine Adresse gezielt blocken kann sie nicht; dafür braucht es die zustandslose Network ACL auf Subnetzebene.
Security Groups sperren niemanden aus, sondern lassen gewolltes herein. Die Antwort auf eine erlaubte Anfrage läuft immer mit.
📌 Zustandsbehaftet · Nur Erlaubnisregeln · Quelle kann Gruppe sein
📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops
3 Tage vor
Öffentliches und privates Subnetz klingen wie zwei verschiedene Bausteine. Dabei entscheidet nur eine Zeile in der Routing-Tabelle, welches Subnetz welches ist.
Die Verwechslung entsteht, weil der Name wie eine Sicherheitseigenschaft klingt. Tatsächlich ist „privat“ nur eine Aussage über Routen, nicht über einen Filter.
Ein Subnetz ist ein abgegrenzter IP-Adressbereich innerhalb einer VPC, des privaten Netzwerks in der Cloud. Jedes Subnetz hängt an einer Routing-Tabelle, die anhand des Ziel-IP-Bereichs entscheidet, wohin jedes Paket geleitet wird. Ein öffentliches Subnetz hat eine Route „Ziel 0.0.0.0/0, Ziel Internet Gateway“ – das Gateway ist die Verbindung zwischen VPC und Internet. Ein Webserver, der aus dem Internet erreichbar sein soll, gehört hierhin.
Ein privates Subnetz ist dasselbe Konstrukt, nur ohne Route zum Internet Gateway. Eine RDS-Datenbank (ein verwalteter Datenbankdienst) läuft typischerweise im privaten Subnetz. Der Zugriff wird über eine Security Group erlaubt, eine Firewall an der Netzwerkschnittstelle, die nur die Anwendungsschicht als Quelle nennt.
Der entscheidende Unterschied liegt nicht im Namen, sondern in der Route. Unerreichbarkeit von außen entsteht durch die fehlende Route, nicht durch eine Sperre. Für ausgehenden Internetzugang stellt ein NAT Gateway im öffentlichen Subnetz die Verbindung her, ohne dass jemand von außen hineinkann.
Faustregel: Alles, das direkt aus dem Internet erreichbar sein muss, gehört ins öffentliche Subnetz; alles andere, etwa Datenbanken, ins private.
Öffentlich heißt also nicht ungefiltert, und privat heißt nicht gesperrt. Beide Begriffe beschreiben nur, ob eine Route zum Internet Gateway existiert.
📌 Route entscheidet · 0.0.0.0/0 · Angriffsfläche trennen
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
Die Verwechslung entsteht, weil der Name wie eine Sicherheitseigenschaft klingt. Tatsächlich ist „privat“ nur eine Aussage über Routen, nicht über einen Filter.
Ein Subnetz ist ein abgegrenzter IP-Adressbereich innerhalb einer VPC, des privaten Netzwerks in der Cloud. Jedes Subnetz hängt an einer Routing-Tabelle, die anhand des Ziel-IP-Bereichs entscheidet, wohin jedes Paket geleitet wird. Ein öffentliches Subnetz hat eine Route „Ziel 0.0.0.0/0, Ziel Internet Gateway“ – das Gateway ist die Verbindung zwischen VPC und Internet. Ein Webserver, der aus dem Internet erreichbar sein soll, gehört hierhin.
Ein privates Subnetz ist dasselbe Konstrukt, nur ohne Route zum Internet Gateway. Eine RDS-Datenbank (ein verwalteter Datenbankdienst) läuft typischerweise im privaten Subnetz. Der Zugriff wird über eine Security Group erlaubt, eine Firewall an der Netzwerkschnittstelle, die nur die Anwendungsschicht als Quelle nennt.
Der entscheidende Unterschied liegt nicht im Namen, sondern in der Route. Unerreichbarkeit von außen entsteht durch die fehlende Route, nicht durch eine Sperre. Für ausgehenden Internetzugang stellt ein NAT Gateway im öffentlichen Subnetz die Verbindung her, ohne dass jemand von außen hineinkann.
Faustregel: Alles, das direkt aus dem Internet erreichbar sein muss, gehört ins öffentliche Subnetz; alles andere, etwa Datenbanken, ins private.
Öffentlich heißt also nicht ungefiltert, und privat heißt nicht gesperrt. Beide Begriffe beschreiben nur, ob eine Route zum Internet Gateway existiert.
📌 Route entscheidet · 0.0.0.0/0 · Angriffsfläche trennen
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
4 Tage vor
Eine VPC funktioniert wie ein Firmengelände mit Zaun, Wegen und einem einzigen Tor. Wer keinem Weg folgt, kommt nirgendwo hin – auch nicht ans Tor.
Das Gelände hat klare Grenzen, doch innen bestimmt der Eigentümer die Wege. Manche Wege führen zum Tor, andere enden an einem verschlossenen Gebäudeteil. Wer keine Zufahrt zum Tor hat, bleibt außen.
In der Cloud entspricht das Gelände der VPC (Virtual Private Cloud), also einem logisch abgegrenzten, privaten Netzwerkbereich, in dem man IP-Adressbereiche, Subnetze und Routing selbst festlegt. Die Wege sind die Routing-Tabellen: Sie leiten jedes Paket anhand des Ziel-IP-Bereichs, und ohne passende Route verlässt kein Paket das Subnetz. Das Tor ist das Internet Gateway, das öffentliche Subnetze per Route mit dem Internet verbindet; alle übrigen Subnetze sind privat.
Ein Beispiel: Eine VPC erhält beim Anlegen einen CIDR-Block (Classless Inter-Domain Routing), also einen Bereich zusammenhängender IP-Adressen mit Netzpräfix. Darin liegen zwei Subnetze – im öffentlichen läuft ein NAT-fähiger Dienst, im privaten eine Datenbank, die nur Anfragen aus dem öffentlichen Subnetz annimmt. Die Datenbank gehört dorthin und erlaubt über eine Security Group (eine Firewall-Regelliste) nur die Anwendungsschicht als Quelle.
Das Bild hat eine Grenze: „Privates Subnetz“ klingt nach einem Filter, ist aber nur eine fehlende Route. Sicherheit entsteht hier durchs Routing, nicht durch eine Mauer – Filter wie Security Groups kommen separat dazu.
Private Unerreichbarkeit ist also ein Wegproblem, kein Schloss. Wer das Routing plant, plant die Sicherheit gleich mit.
📌 VPC · Subnetze · Routing
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
Das Gelände hat klare Grenzen, doch innen bestimmt der Eigentümer die Wege. Manche Wege führen zum Tor, andere enden an einem verschlossenen Gebäudeteil. Wer keine Zufahrt zum Tor hat, bleibt außen.
In der Cloud entspricht das Gelände der VPC (Virtual Private Cloud), also einem logisch abgegrenzten, privaten Netzwerkbereich, in dem man IP-Adressbereiche, Subnetze und Routing selbst festlegt. Die Wege sind die Routing-Tabellen: Sie leiten jedes Paket anhand des Ziel-IP-Bereichs, und ohne passende Route verlässt kein Paket das Subnetz. Das Tor ist das Internet Gateway, das öffentliche Subnetze per Route mit dem Internet verbindet; alle übrigen Subnetze sind privat.
Ein Beispiel: Eine VPC erhält beim Anlegen einen CIDR-Block (Classless Inter-Domain Routing), also einen Bereich zusammenhängender IP-Adressen mit Netzpräfix. Darin liegen zwei Subnetze – im öffentlichen läuft ein NAT-fähiger Dienst, im privaten eine Datenbank, die nur Anfragen aus dem öffentlichen Subnetz annimmt. Die Datenbank gehört dorthin und erlaubt über eine Security Group (eine Firewall-Regelliste) nur die Anwendungsschicht als Quelle.
Das Bild hat eine Grenze: „Privates Subnetz“ klingt nach einem Filter, ist aber nur eine fehlende Route. Sicherheit entsteht hier durchs Routing, nicht durch eine Mauer – Filter wie Security Groups kommen separat dazu.
Private Unerreichbarkeit ist also ein Wegproblem, kein Schloss. Wer das Routing plant, plant die Sicherheit gleich mit.
📌 VPC · Subnetze · Routing
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #devops
4 Tage vor
Die Seite ist plötzlich nicht mehr erreichbar, der Browser zeigt eine Warnseite statt der Anwendung. Dabei hat sich am Code nichts geändert – nur ein Zertifikat ist still abgelaufen.
Die Nutzer sehen eine Fehlermeldung, die wie ein Sicherheitsproblem aussieht. Auch API-Aufrufe scheitern, weil Clients die Verbindung verweigern. Abgelaufene Zertifikate gehören zu den häufigsten vermeidbaren Ausfallursachen.
Der Grundbegriff dahinter ist das TLS-Zertifikat: eine digitale Bescheinigung, die eine Domain einem öffentlichen Schlüssel des Servers zuordnet. Sie ist von einer Zertifizierungsstelle unterschrieben, also einer anerkannten Ausstellerin, der der Browser vertraut. Ohne gültiges Zertifikat kann der Browser nicht ausschließen, dass sich ein fremder Server für den echten ausgibt – ein sogenannter Man-in-the-Middle.
Ein konkretes Beispiel: Zertifikate von Lets Encrypt sind 90 Tage gültig; die Erneuerung wird nach 60 Tagen empfohlen. Wer von Hand erneuert, vergisst es irgendwann. Die Erneuerung soll deshalb automatisiert laufen, etwa mit dem ACME-Protokoll (RFC 8555) und einem Client wie certbot. Bei der HTTP-Challenge legt der Client eine vom Server gestellte Datei unter einer bekannten URL auf dem Webserver ab; wer sie liefern kann, beweist die Kontrolle über die Domain.
So prüft man es: Das Monitoring sollte die Restlaufzeit jedes öffentlichen Zertifikats überwachen und Alarm schlagen, bevor sie abläuft. Zusätzlich gehört die Erneuerung in einen Timer oder Cron-Dienst, der automatisch läuft.
Ein Zertifikat beweist dem Browser nicht die Echtheit einer Seite, sondern dass eine anerkannte Stelle die Kontrolle über die Domain geprüft hat. Deshalb gilt: Erneuerung automatisieren, Restlaufzeit überwachen – sonst wird der Ablauf zum Ausfall.
📌 TLS-Zertifikat · Zertifizierungsstelle · Automatische Erneuerung
📚 Cloud von Grund auf · Tag 2 von 30
#CloudSecurity #monitoring #devops
Die Nutzer sehen eine Fehlermeldung, die wie ein Sicherheitsproblem aussieht. Auch API-Aufrufe scheitern, weil Clients die Verbindung verweigern. Abgelaufene Zertifikate gehören zu den häufigsten vermeidbaren Ausfallursachen.
Der Grundbegriff dahinter ist das TLS-Zertifikat: eine digitale Bescheinigung, die eine Domain einem öffentlichen Schlüssel des Servers zuordnet. Sie ist von einer Zertifizierungsstelle unterschrieben, also einer anerkannten Ausstellerin, der der Browser vertraut. Ohne gültiges Zertifikat kann der Browser nicht ausschließen, dass sich ein fremder Server für den echten ausgibt – ein sogenannter Man-in-the-Middle.
Ein konkretes Beispiel: Zertifikate von Lets Encrypt sind 90 Tage gültig; die Erneuerung wird nach 60 Tagen empfohlen. Wer von Hand erneuert, vergisst es irgendwann. Die Erneuerung soll deshalb automatisiert laufen, etwa mit dem ACME-Protokoll (RFC 8555) und einem Client wie certbot. Bei der HTTP-Challenge legt der Client eine vom Server gestellte Datei unter einer bekannten URL auf dem Webserver ab; wer sie liefern kann, beweist die Kontrolle über die Domain.
So prüft man es: Das Monitoring sollte die Restlaufzeit jedes öffentlichen Zertifikats überwachen und Alarm schlagen, bevor sie abläuft. Zusätzlich gehört die Erneuerung in einen Timer oder Cron-Dienst, der automatisch läuft.
Ein Zertifikat beweist dem Browser nicht die Echtheit einer Seite, sondern dass eine anerkannte Stelle die Kontrolle über die Domain geprüft hat. Deshalb gilt: Erneuerung automatisieren, Restlaufzeit überwachen – sonst wird der Ablauf zum Ausfall.
📌 TLS-Zertifikat · Zertifizierungsstelle · Automatische Erneuerung
📚 Cloud von Grund auf · Tag 2 von 30
#CloudSecurity #monitoring #devops
4 Tage vor
Die meisten Anfänger denken, ein Bucket sei ein Ordner wie auf dem Desktop. Dabei ist er der zentrale Sicherheitspunkt des gesamten Cloud-Speichers.
Ein offen stehender Bucket gibt Daten an das ganze Internet frei. Ein einziger falsch gesetzter Haken genügt dafür.
📦 Ein Bucket ist der oberste Speichercontainer in einem Objektspeicher, nicht ein Laufwerk. Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten, also beschreibenden Angaben zum Objekt, ab, nicht als Dateien auf einem Datenträger. Jeder Bucket hat einen weltweit einmaligen Namen und enthält beliebig viele Objekte.
🔑 Jedes Objekt liegt unter einem Schlüssel, der wie ein Dateipfad aufgebaut ist. Ein Beispiel ist „backup/2026/db.sql“. Der Schlüssel adressiert das Objekt eindeutig, ganz ohne Ordnerstruktur. Zugriffsrechte steuert man nicht über Betriebssystemrechte, sondern über Richtlinien, die den Zugriff pro Bucket und Objekt erlauben oder verweigern.
📈 Block Public Access gehört auf jeden Bucket, vom ersten Tag an. Diese Schutzebene sperrt alle vier Arten öffentlichen Zugriffs und überstimmt öffentliche Bucket-Policies und ACLs. Seit April 2023 ist sie für neue Buckets standardmäßig aktiviert; ACLs, ältere Zugriffslisten, sind dabei sogar deaktiviert. Ein öffentlicher Bucket erlaubt jedem Internetnutzer, Objekte aufzulisten oder herunterzuladen. Wer Dateien wirklich verteilen will, nutzt dafür gezielter einen CDN-Dienst, ein Content-Delivery-Netzwerk für Dateien aus Rechenzentren nahe beim Nutzer, oder vorsignierte URLs.
Ein Bucket heißt nicht „öffentlicher Ordner“, sondern ein weltweit einmaliger Speichercontainer, den man standardmäßig verschlossen hält.
📌 Bucket · Objektspeicher · Block Public Access
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #Backup
Ein offen stehender Bucket gibt Daten an das ganze Internet frei. Ein einziger falsch gesetzter Haken genügt dafür.
📦 Ein Bucket ist der oberste Speichercontainer in einem Objektspeicher, nicht ein Laufwerk. Objektspeicher wie S3 legt Daten als Objekte mit Schlüssel und Metadaten, also beschreibenden Angaben zum Objekt, ab, nicht als Dateien auf einem Datenträger. Jeder Bucket hat einen weltweit einmaligen Namen und enthält beliebig viele Objekte.
🔑 Jedes Objekt liegt unter einem Schlüssel, der wie ein Dateipfad aufgebaut ist. Ein Beispiel ist „backup/2026/db.sql“. Der Schlüssel adressiert das Objekt eindeutig, ganz ohne Ordnerstruktur. Zugriffsrechte steuert man nicht über Betriebssystemrechte, sondern über Richtlinien, die den Zugriff pro Bucket und Objekt erlauben oder verweigern.
📈 Block Public Access gehört auf jeden Bucket, vom ersten Tag an. Diese Schutzebene sperrt alle vier Arten öffentlichen Zugriffs und überstimmt öffentliche Bucket-Policies und ACLs. Seit April 2023 ist sie für neue Buckets standardmäßig aktiviert; ACLs, ältere Zugriffslisten, sind dabei sogar deaktiviert. Ein öffentlicher Bucket erlaubt jedem Internetnutzer, Objekte aufzulisten oder herunterzuladen. Wer Dateien wirklich verteilen will, nutzt dafür gezielter einen CDN-Dienst, ein Content-Delivery-Netzwerk für Dateien aus Rechenzentren nahe beim Nutzer, oder vorsignierte URLs.
Ein Bucket heißt nicht „öffentlicher Ordner“, sondern ein weltweit einmaliger Speichercontainer, den man standardmäßig verschlossen hält.
📌 Bucket · Objektspeicher · Block Public Access
📚 Cloud von Grund auf · Tag 2 von 30
#aws #CloudSecurity #Backup
4 Tage vor
Eine vermietete Wohnung funktioniert wie Cloud Computing: Der Vermieter liefert das Haus, der Mieter sichert die Tür. Bei Cloud-Sicherheit ist es genauso geteilt – und die meisten Mieter vergessen den Türschlosskauf.
Der Vermieter sichert das Grundstück: Zäune, Alarmanlage, Strom, Wasser, Heizung. Er sorgt dafür, dass kein Fremder in den Keller kommt. Die Wände trennen die Wohnungen voneinander, ohne dass jeder Mieter sein eigenes Haus baut. Was in der Wohnung passiert, sieht der Vermieter nicht.
Der Anbieter übernimmt die Sicherheit der Cloud: Rechenzentren mit Zutrittskontrolle, Hardware, Strom, Kühlung, Netz und die Virtualisierungsschicht, die Kunden voneinander trennt. Der Kunde verantwortet die Sicherheit in der Cloud: Daten verschlüsseln, Zugriffsrechte per IAM (Identity and Access Management, das Rechtesystem von AWS) vergeben, Netzregeln wie Security Groups setzen, Patches auf eigenen Servern einspielen. Jede Konfiguration gehört ihm.
Konkret: In einer AWS-Region laufen mehrere Rechenzentren als Availability Zones, jede mit eigener Stromversorgung. Die trennende Virtualisierung pflegt AWS; ein offener S3-Speicher durch falsche Rechte ist dagegen Kundensache. In der Praxis gilt: Offene Konfiguration ist Kundensache, der Ausfall einer Zone ist Sache des Anbieters.
Das Bild hat eine Grenze: Der Vermieter kann meist noch vorbeikommen, der Anbieter sieht Kundendaten nicht. Und der Mietvertrag deckt Möbel ab, in der Cloud bleiben Daten und Rechte immer beim Kunden.
Als Prüffrage gilt: Kann ich die Schicht selbst konfigurieren? Dann ist sie meine Verantwortung. Geteilte Verantwortung heißt nicht geteilte Haftung für jedes Detail, sondern klare Zuständigkeit je Schicht.
📌 Shared Responsibility Model · Sicherheit der Cloud vs. in der Cloud · Fehlkonfiguration
📚 Cloud von Grund auf · Tag 1 von 30
#CloudSecurity #aws #devops
Der Vermieter sichert das Grundstück: Zäune, Alarmanlage, Strom, Wasser, Heizung. Er sorgt dafür, dass kein Fremder in den Keller kommt. Die Wände trennen die Wohnungen voneinander, ohne dass jeder Mieter sein eigenes Haus baut. Was in der Wohnung passiert, sieht der Vermieter nicht.
Der Anbieter übernimmt die Sicherheit der Cloud: Rechenzentren mit Zutrittskontrolle, Hardware, Strom, Kühlung, Netz und die Virtualisierungsschicht, die Kunden voneinander trennt. Der Kunde verantwortet die Sicherheit in der Cloud: Daten verschlüsseln, Zugriffsrechte per IAM (Identity and Access Management, das Rechtesystem von AWS) vergeben, Netzregeln wie Security Groups setzen, Patches auf eigenen Servern einspielen. Jede Konfiguration gehört ihm.
Konkret: In einer AWS-Region laufen mehrere Rechenzentren als Availability Zones, jede mit eigener Stromversorgung. Die trennende Virtualisierung pflegt AWS; ein offener S3-Speicher durch falsche Rechte ist dagegen Kundensache. In der Praxis gilt: Offene Konfiguration ist Kundensache, der Ausfall einer Zone ist Sache des Anbieters.
Das Bild hat eine Grenze: Der Vermieter kann meist noch vorbeikommen, der Anbieter sieht Kundendaten nicht. Und der Mietvertrag deckt Möbel ab, in der Cloud bleiben Daten und Rechte immer beim Kunden.
Als Prüffrage gilt: Kann ich die Schicht selbst konfigurieren? Dann ist sie meine Verantwortung. Geteilte Verantwortung heißt nicht geteilte Haftung für jedes Detail, sondern klare Zuständigkeit je Schicht.
📌 Shared Responsibility Model · Sicherheit der Cloud vs. in der Cloud · Fehlkonfiguration
📚 Cloud von Grund auf · Tag 1 von 30
#CloudSecurity #aws #devops
