Security, Resilienz und Observability

Security, Resilienz und Observability

0:00 Drei Themen in einem Modul — das sieht nach einer Sammelkategorie aus, ist aber eine bewusste Zusammenstellung. Sicherheit, Resilienz und Beobachtbarkeit teilen eine unangenehme Eigenschaft: Sie lassen sich nicht nachrüsten. Man kann eine Funktion nachliefern und ein Frontend austauschen. Vertrauensgrenzen, Ausfallverhalten und Telemetriepfade dagegen sind in die Struktur eingebaut oder sie fehlen. Und das merkt man jeweils genau dann, wenn es am teuersten ist.

Security, Resilienz und Observability

0:28 Fünf Kapitel. Zuerst Security by Design — Vertrauensgrenzen, Identität, Mandantentrennung. Dann der aktuelle Stand der Anwendungssicherheit mit den OWASP Top 10 und dem Prüfstandard ASVS. Drittens die Software-Lieferkette, die in den letzten Jahren stark an Bedeutung gewonnen hat. Viertens Resilienz mit dem Circuit Breaker als Kernmuster.

0:49 Und zum Schluss Observability als Bestandteil der Architektur, nicht des Betriebs.

Security by Design

0:55 Beginnen wir mit der Grundhaltung. Sicherheit anzuentwerfen heißt nicht, mehr Technik einzubauen — es heißt, vier Fragen zu beantworten, bevor die Technik überhaupt zur Debatte steht. Zero Trust ist ein Begriff, der viel Marketing abbekommen hat, und dahinter steht eine einfache Einsicht: Die Annahme, das interne Netz sei sicher, hält nicht mehr.

1:16 Sie hat nie gehalten, aber heute ist offensichtlich, warum — Dienste laufen verteilt, Mitarbeitende arbeiten von überall, und ein einziger übernommener Dienst würde sonst das ganze Haus öffnen. Also wird jeder Zugriff geprüft, unabhängig von seiner Herkunft. Least Privilege ergänzt das: Jede Identität darf nur, was sie gerade braucht.

1:36 Diese vier Quadranten sind Ihr Einstieg in jedes Sicherheitsgespräch, und sie kommen in dieser Reihenfolge. Welche Daten, welcher Schaden bei Verlust — das ist der Schutzbedarf, und ohne ihn ist jede weitere Maßnahme willkürlich. Wo wechselt die Verantwortung — das sind die Vertrauensgrenzen, und dort gehören die Prüfungen hin.

1:56 Wer handelt, und in wessen Namen — die Identitätsfrage, die bei Agenten in Modul elf noch einmal schwieriger wird. Und woran erkennt man später, was geschehen ist. Diese Verwechslung begegnet mir regelmäßig, und sie hat echte Folgen. OAuth 2.0 regelt Autorisierung: Ein Dienst darf im Namen eines Nutzers handeln. OpenID Connect ergänzt die Authentifizierung: wer der Nutzer ist.

2:19 Der dritte Punkt ist der praktisch wichtigste — ein Zugriffstoken ist kein Identitätsnachweis, auch wenn es Angaben über eine Person enthält. Wer es als solchen behandelt, baut eine Lücke ein, die sich nicht wie eine anfühlt. Und die Prüfung gehört an die Vertrauensgrenze, nicht verstreut in jede Funktion. Für Kartenwerk ist das hochrelevant: Jeder Veranstalter ist ein Mandant und darf ausschließlich seine eigenen Daten sehen.

2:46 Drei Varianten stehen zur Wahl, und der dritte Punkt bewertet sie klar: Eine Filterbedingung in der Anwendung ist die schwächste. Ein vergessenes WHERE, und ein Veranstalter sieht die Umsätze eines anderen. Getrennte Schemata oder getrennte Datenbanken machen diesen Fehler strukturell unmöglich — zu höheren Betriebskosten.

3:05 Und der letzte Punkt ist die Warnung: Nachträglich zu wechseln bedeutet Datenmigration im laufenden Betrieb. Der dritte Punkt beschreibt eine gefährliche Arbeitsteilung: Die Web Application Firewall soll ersetzen, was im Code fehlt. Sie kann bekannte Angriffsmuster abfangen, aber keine fehlende Berechtigungsprüfung ersetzen.

3:24 Und der letzte Punkt ist die Frage, an der man einen ernsthaften Sicherheitsentwurf erkennt: Hat der dokumentierte Schutzbedarf jemals eine Entscheidung beeinflusst? Wenn nicht, war er eine Übung für die Ablage.

Aktuelle Anwendungssicherheit

3:37 Damit zum konkreten Stand. Zwei Dokumente sollten Sie kennen, und sie haben sehr verschiedene Aufgaben: eines schärft das Bewusstsein, das andere ist überprüfbar. Die OWASP Top 10 sind ein Bewusstseinsdokument — das ist die Selbstbeschreibung, und sie ist wichtig, weil die Liste oft als Prüfkatalog missbraucht wird. Die Ausgabe 2025 hat zwei bemerkenswerte Merkmale: Zugriffskontrolle steht an der Spitze, was sie seit Jahren tut, und Fehler in der Software-Lieferkette sind auf Platz drei aufgerückt.

4:07 Das ist neu in dieser Deutlichkeit und der Grund, warum wir gleich ein eigenes Kapitel dafür haben. Die ersten fünf. Broken Access Control an der Spitze — und das ist keine exotische Schwachstelle, sondern meistens eine vergessene Prüfung an einer Stelle, die niemand für kritisch hielt. Security Misconfiguration auf Platz zwei zeigt, wie viel heute an Konfiguration hängt statt an Code.

4:30 Und die Fußzeile ist wichtig: Die Reihenfolge ist datengetrieben und beschreibt die Verbreitung, nicht Ihr Risiko. Für Kartenwerk könnte Platz sieben der gefährlichste sein. Die Liste ersetzt kein Bedrohungsmodell. Auf Platz sechs steht die Kategorie, die mich am meisten interessiert: Insecure Design. Die Fußzeile sagt, warum — kein Werkzeug findet sie.

4:52 Ein Prüfprogramm kann eine fehlende Eingabevalidierung erkennen, aber nicht, dass ein Ablauf grundsätzlich falsch gedacht ist. Diese Kategorie entsteht am Entwurfstisch, also genau dort, wo wir uns in diesem Seminar aufhalten. Und Platz zehn ist neu und lesenswert: der Umgang mit Ausnahmesituationen. Was passiert eigentlich, wenn etwas schiefgeht — welche Informationen verlassen dabei das Haus?

5:17 Und hier das zweite Dokument, der überprüfbare Gegenpart. ASVS ist kein Risikokatalog, sondern ein Anforderungskatalog — Sie können jede Anforderung prüfen und als erfüllt oder nicht erfüllt markieren. Version 5.0.0 ist dabei keine Auffrischung, sondern eine Umstrukturierung: 17 Kapitel, 345 Anforderungen, durchgängig neu nummeriert.

5:39 Wer mit der Vorversion gearbeitet hat, muss also umlernen. Drei Prüfstufen gibt es, und die meisten Anwendungen zielen auf die mittlere. Dasselbe Prinzip wie bei den Modulgrenzen in Modul acht: Was Menschen prüfen sollen, wird irgendwann durchgewinkt. Abhängigkeiten werden bei jedem Bau geprüft, statische Analyse läuft im selben Lauf wie die Tests, und ein Fund oberhalb einer festgelegten Schwelle bricht den Bau.

6:04 Wichtig ist der letzte Punkt, weil er sich nicht automatisieren lässt: Threat Modeling geschieht am Entwurf. Ein Bedrohungsmodell für ein fertiges System ist eine Bestandsaufnahme, keine Gestaltung. Der erste Punkt ist genau das Missverständnis, vor dem die Top 10 selbst warnen: Sie werden als Prüfliste verwendet und gelten dann als abgehakt.

6:25 Der zweite ist der häufigste Fehler bei ASVS — vollständige Erfüllung wird gefordert, ohne eine Stufe festzulegen. Dann ist die Anforderung entweder unerfüllbar oder beliebig. Und der dritte beschreibt den Alltag vieler Teams: Die Werkzeuge melden fleißig, aber niemand ist für die Funde zuständig. Ein Bericht ohne Empfänger ist kein Prozess.

Software Supply Chain

6:45 Zum Thema, das auf Platz drei der Top 10 gelandet ist. Die Frage dahinter ist simpel und überraschend schwer zu beantworten: Wissen Sie, woher das kommt, was Sie ausliefern? Provenance heißt Herkunftsnachweis — wer hat dieses Artefakt gebaut, aus welchen Eingaben, mit welchem Prozess. Das klingt nach Bürokratie und ist die Grundlage dafür, eine Manipulation überhaupt bemerken zu können.

7:09 SLSA ordnet das in Stufen mit wachsenden Garantien und unterscheidet dabei zwei Spuren: den Build Track für den Bauvorgang und einen Source Track für die Quellcodeseite. Wir schauen uns gleich den Build Track an, weil er der greifbarere von beiden ist. Diese vier Stufen sind gut gestuft und deshalb praktisch verwendbar. Stufe eins verlangt nur, dass Provenance überhaupt existiert — das ist mit einer modernen Bauplattform schnell erreicht.

7:35 Der eigentliche Sprung liegt bei Stufe zwei: Die Plattform erzeugt und signiert die Provenance selbst, und erst damit schützt sie vor nachträglicher Manipulation. Stufe drei ist die anspruchsvolle — Läufe isoliert, Signaturschlüssel für Bauschritte unerreichbar. Setzen Sie sich ein Ziel auf dieser Leiter, statt über Lieferkettensicherheit im Allgemeinen zu sprechen.

7:56 Das Bild dazu ist die Zutatenliste auf einer Lebensmittelverpackung. Ohne sie wissen Sie nicht, was Sie ausliefern — und wenn eine Schwachstelle gemeldet wird, können Sie nicht sagen, ob sie Sie betrifft. Genau das ist der praktische Wert: Der zweite Punkt nennt die transitiven Abhängigkeiten, also die Zutaten Ihrer Zutaten.

8:15 Die machen den größeren Teil aus und stehen auf keiner Liste, die jemand von Hand pflegt. Und Aktualisierungsstrategie ist eine Entscheidung — wer nur reagiert, reagiert immer zu spät. Der erste und der zweite Punkt beschreiben dieselbe Halbherzigkeit: Etwas wird erzeugt und nirgends benutzt. Eine Stückliste, die niemand auswertet.

8:35 Eine Signatur, die beim Einspielen niemand prüft. Beides erzeugt ein Gefühl von Sicherheit ohne ihre Wirkung. Der dritte Punkt ist der, der in Bedrohungsmodellen fast immer fehlt: Die Bauplattform hat mehr Rechte als jeder Mensch im Haus — sie darf in die Produktion ausliefern. Wer sie übernimmt, braucht keinen weiteren Zugang.

Resilienz verteilter Systeme

8:55 Damit zur Frage, wie sich ein System verhält, wenn Teile davon nicht mehr antworten. Und zwar nicht als Ausnahmefall gedacht, sondern als Normalbetrieb. Der Name führt in die Irre, deshalb das Bild dahinter: Ein Circuit Breaker ist eine Sicherung im Stromkasten. Wenn zu viel Strom fließt, trennt sie — nicht um zu strafen, sondern um zu verhindern, dass das ganze Haus in Mitleidenschaft gezogen wird. Genauso hier.

9:20 Ein langsamer Fremddienst ist gefährlicher als ein ausgefallener, denn jeder wartende Aufruf bindet Speicher, einen Thread und vielleicht eine Datenbankverbindung. Ohne Sicherung reicht ein hängender Fremddienst, um Ihr eigenes System lahmzulegen. Die Kette zeigt den Weg durch die Zustände — und der letzte Pfeil zurück nach Closed ist der interessante. Das System muss selbst herausfinden, wann es wieder sicher ist.

9:45 Genau dafür gibt es den mittleren Zustand: eine vorsichtige Rückkehr, keine sofortige. Ohne ihn hätten Sie nur ein Ein und ein Aus — und müssten jemanden wecken, der den Schalter umlegt. Die dritte Zeile ist die durchdachteste und wird beim Selbstbau am häufigsten weggelassen. Nach Ablauf der Zeitsperre gehen nur begrenzt viele Versuche durch.

10:06 Gelingen sie, schließt der Schalter; scheitert einer, öffnet er wieder. Die Fußzeile nennt den Grund: Ein Dienst, der sich gerade erholt, verträgt zunächst nur wenig Last. Wer ihn sofort mit der vollen Menge wartender Anfragen trifft, wirft ihn zurück in den Ausfall — und das wiederholt sich dann im Takt der Zeitsperre.

10:25 Die Abgrenzung steht so ausdrücklich in der Dokumentation, weil sie oft verwechselt wird. Retry erwartet, dass es beim nächsten Mal klappt — richtig bei kurzen Störungen. Der Circuit Breaker verhindert Aufrufe, die voraussichtlich scheitern. Kombiniert werden sie so, dass über den Schalter wiederholt wird, nicht gegen ihn: Meldet der Schalter, dass der Fehler nicht vorübergehend ist, hören die Wiederholungen auf.

10:48 Und der letzte Punkt ist der, der Ausfälle verlängert: Wiederholungen ohne exponentielles Warten und Streuung erzeugen Lastwellen im Gleichtakt. Vier weitere Werkzeuge, und Graceful Degradation ist das, an das ich Sie am meisten erinnern möchte. Eine kleinere Antwort ist besser als keine. Wenn bei Kartenwerk die Empfehlungen ausfallen, kann die Veranstaltungsseite trotzdem erscheinen — ohne Empfehlungen.

11:12 Das muss man allerdings entwerfen: Es braucht einen definierten Ersatzinhalt und eine Oberfläche, die damit umgehen kann. Bulkheads trennen Ressourcen, damit ein Bereich den anderen nicht aufzehrt, und Load Shedding wirft Last bewusst ab, bevor alles zusammenbricht. Der zweite Punkt ist der tückischste: Wiederholungen laufen auf jeder Ebene — in der Bibliothek, im Dienst, im Gateway, im Client.

11:36 Drei Ebenen mit je drei Versuchen sind siebenundzwanzig Aufrufe für eine einzige Anfrage. So entsteht aus einer kleinen Störung ein Ausfall. Legen Sie fest, auf welcher Ebene wiederholt wird, und nur dort. Und der letzte Punkt: Ein Schalter für mehrere unabhängige Ziele sperrt gesunde Ziele mit, weil er nicht unterscheiden kann.

Observability

11:56 Zum letzten Kapitel dieses Moduls. Und zur These, dass Telemetrie keine Betriebsangelegenheit ist, sondern etwas, das Sie beim Entwurf festlegen — oder eben nicht. Der Unterschied zwischen Monitoring und Observability lässt sich an den Fragen festmachen. Monitoring beantwortet Fragen, die Sie vorher kannten — deshalb gibt es Anzeigen dafür.

12:17 Observability zielt darauf, auch die Frage beantworten zu können, die Sie sich erst um drei Uhr nachts stellen: Warum ist die Antwortzeit für Kunden mit mehr als zehn Tickets seit dem letzten Rollout schlechter? Dafür braucht es Telemetrie, die reich genug ist, um im Nachhinein neue Zusammenhänge zu bilden. OpenTelemetry liefert dafür die herstellerneutrale Grundlage.

12:38 Fünf Signale, und Profiles ist das jüngste — eine Aufzeichnung des Ressourcenverbrauchs auf Codeebene. Baggage ist das am wenigsten bekannte und praktisch sehr nützliche: Kontextinformation, die zwischen Signalen weitergereicht wird. Damit können Sie zum Beispiel die Mandantenkennung durch die ganze Kette tragen. Und die Fußzeile nennt den Punkt, auf den es ankommt: Die Signale wirken erst gemeinsam.

13:03 Eine Kennzahl zeigt Ihnen, dass etwas langsam ist. Die zugehörige Spur zeigt, wo. Context Propagation ist die unscheinbare Mechanik, ohne die verteilte Ablaufverfolgung nicht funktioniert. Der Context trägt die Kennungen, über die sich Signale einander zuordnen lassen. Ein Propagator serialisiert ihn beim Senden und liest ihn beim Empfangen — als Standard dient dafür die W3C-TraceContext-Spezifikation mit einem Header namens traceparent.

13:29 Merken Sie sich diesen Namen: Wenn eine Spur irgendwo abreißt, ist dieser Header meistens der Grund, weil ihn jemand nicht weitergereicht hat. Genau das sagt der erste Punkt: Jede Grenze muss den Kontext weiterreichen, auch über Warteschlangen. Bei synchronen Aufrufen erledigen das die Bibliotheken meist von selbst. Bei Nachrichten nicht — dort müssen Sie den Kontext ausdrücklich in die Nachricht legen.

13:53 Der dritte Punkt ist der, den Datenschutzbeauftragte stellen werden: Telemetrie kann personenbezogene Daten enthalten. Und der vierte ist der, den die Finanzabteilung stellt — Aufbewahrung und Abtastrate sind ein Kostenposten mit spürbarer Größe. Der erste Punkt ist genau der Fall von eben, und er ist ausgesprochen häufig: Die Spur endet an der Warteschlange.

14:15 Der zweite ist der Klassiker — protokolliert wird alles, ausgewertet nichts; das kostet Geld und hilft niemandem. Und der dritte ist der, der Auswertung unmöglich macht: Jeder Dienst benennt dieselbe Sache anders. Dagegen helfen die semantischen Konventionen von OpenTelemetry. Im nächsten Modul kommt eine Komponente dazu, die alle drei Themen dieses Moduls noch einmal verschärft.