14 Std vor
Ein Kommentarfeld sieht aus wie ein Feld für Text. Für den Browser ist jede Ausgabe aber erst einmal Teil der Seite, den er liest, nicht reiner Text.
Genau hier werden Eingabe und Ausgabe verwechselt. Viele prüfen, was hereinkommt, und halten die Seite dann für sicher. Ob Cross-Site Scripting (XSS) entsteht, entscheidet sich aber erst bei der Ausgabe.
Eingabefilterung prüft Daten, bevor der Server sie annimmt. Sie blockt etwa HTML-Zeichen im Kommentarfeld oder lehnt verdächtige Werte ab. Das Problem: Ein Filter kann nie alle Fälle kennen. Gibt jemand statt eines Kommentars ein script-Element mit JavaScript ein, entscheidet nicht der Filter, sondern erst die Ausgabe, ob es läuft.
Ausgabekodierung, auch Escaping genannt, greift dort, wo der Schaden entsteht. Sie ersetzt Zeichen mit Sonderbedeutung durch ungefährliche Kürzel. So wird < zu <, und der Browser zeigt spitze Klammern als Text an, statt sie als Tag zu lesen.
Filterung schätzt die Eingabe ein, Kodierung entschärft die Ausgabe. Weil dieselbe Eingabe in HTML-Text, Attribut, URL oder JavaScript-String je eigene Kodierungsregeln braucht, schützt nur kontextgerechtes Escaping an jedem Ausgabeort.
„Faustregel:" Eingaben validieren, um fehlerhafte Daten abzuweisen; für Sicherheit aber jede Ausgabe im passenden Kontext kodieren. Eine Content Security Policy, die vorgibt, von wo Skripte geladen dürfen, ergänzt das als zweite Verteidigungslinie.
XSS heißt nicht, dass jemand den Server knackt, sondern dass fremdes Skript im Browser der Opfer läuft – etwa mit deren Sitzungs-Cookies. Geschlossen wird die Lücke durch Kodierung am Ausgabeort, nicht durchs Filtern allein.
📌 Eingabe prüfen · Ausgabe kodieren · Kontext beachten
📚 Webentwicklung von Grund auf · Tag 5 von 30
#WebSecurity #webdev #javascript
Genau hier werden Eingabe und Ausgabe verwechselt. Viele prüfen, was hereinkommt, und halten die Seite dann für sicher. Ob Cross-Site Scripting (XSS) entsteht, entscheidet sich aber erst bei der Ausgabe.
Eingabefilterung prüft Daten, bevor der Server sie annimmt. Sie blockt etwa HTML-Zeichen im Kommentarfeld oder lehnt verdächtige Werte ab. Das Problem: Ein Filter kann nie alle Fälle kennen. Gibt jemand statt eines Kommentars ein script-Element mit JavaScript ein, entscheidet nicht der Filter, sondern erst die Ausgabe, ob es läuft.
Ausgabekodierung, auch Escaping genannt, greift dort, wo der Schaden entsteht. Sie ersetzt Zeichen mit Sonderbedeutung durch ungefährliche Kürzel. So wird < zu <, und der Browser zeigt spitze Klammern als Text an, statt sie als Tag zu lesen.
Filterung schätzt die Eingabe ein, Kodierung entschärft die Ausgabe. Weil dieselbe Eingabe in HTML-Text, Attribut, URL oder JavaScript-String je eigene Kodierungsregeln braucht, schützt nur kontextgerechtes Escaping an jedem Ausgabeort.
„Faustregel:" Eingaben validieren, um fehlerhafte Daten abzuweisen; für Sicherheit aber jede Ausgabe im passenden Kontext kodieren. Eine Content Security Policy, die vorgibt, von wo Skripte geladen dürfen, ergänzt das als zweite Verteidigungslinie.
XSS heißt nicht, dass jemand den Server knackt, sondern dass fremdes Skript im Browser der Opfer läuft – etwa mit deren Sitzungs-Cookies. Geschlossen wird die Lücke durch Kodierung am Ausgabeort, nicht durchs Filtern allein.
📌 Eingabe prüfen · Ausgabe kodieren · Kontext beachten
📚 Webentwicklung von Grund auf · Tag 5 von 30
#WebSecurity #webdev #javascript
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
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
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
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
9 Monate vor
Container Security: Trivy-Scans in der CI/CD Pipeline haben 12 kritische CVEs in unseren Base-Images gefunden. Drei davon waren Remote Code Execution. Die meisten kamen aus veralteten System-Libraries in den offiziellen Node.js-Images. Lösung: Distroless Images oder Alpine mit explizitem Dependency-Pinning. Seitdem sind unsere Images 80% kleiner und deutlich sicherer. #security #containers #devsecops
10 Monate vor
Maker Faire Vortrag über IoT-Sicherheit: 85% der IoT-Geräte im Publikum hatten keine Firmware-Verschlüsselung, 60% sendeten Credentials im Klartext. Meine Checkliste für sichere IoT-Devices: TLS für alle Verbindungen, Secure Boot mit signierter Firmware, verschlüsselte OTA-Updates, keine Default-Passwörter, automatische Certificate-Rotation. Sicherheit muss beim Sensor anfangen, nicht erst in der Cloud. #iotsecurity #makerfaire #security
10 Monate vor
Zero Trust Network Architecture komplett umgesetzt. Kein implizites Vertrauen mehr, auch nicht innerhalb des Clusters. Jeder Request wird authentifiziert und autorisiert - Service-zu-Service über mTLS, User-Requests über OAuth2-Proxy.
Das hat 4 Monate gedauert und war schmerzhaft. Aber seit der Implementierung hatten wir null laterale Bewegung bei den 3 Penetration-Tests die wir seitdem durchgeführt haben. Security-Audits sind jetzt deutlich entspannter. #zerotrust #security #cloudnative
Das hat 4 Monate gedauert und war schmerzhaft. Aber seit der Implementierung hatten wir null laterale Bewegung bei den 3 Penetration-Tests die wir seitdem durchgeführt haben. Security-Audits sind jetzt deutlich entspannter. #zerotrust #security #cloudnative
10 Monate vor
Infrastructure Drift Detection mit OpenTofu plan im Cron-Job. Jeden Morgen um 6:00 läuft ein Plan gegen alle Environments. Letzte Woche entdeckt: Ein Kollege hatte manuell eine Security Group geöffnet für Debugging und vergessen sie zu schließen. Port 5432 war 3 Tage offen zum Internet. Drift Detection hat es gefunden, automatisches Ticket erstellt. Pflicht für jede IaC-Umgebung. #opentofu #compliance #security
