Sicherheit, Datenschutz und Compliance by Design

Willkommen zu Kapitel 8: Sicherheit, Datenschutz und Compliance by Design. Die meisten schweren Sicherheitsvorfälle entstehen nicht durch einen exotischen Angriff auf die Kryptografie. Sie entstehen aus strukturellen Entscheidungen. Ein interner Service, der jedem Aufrufer im Netzwerk vertraute. Eine Administrator-API, die eine Autorisierungsprüfung ausließ. Ein Zugriffsschlüssel, der in ein Repository committet wurde. Jede davon war eine Architekturentscheidung darüber, wo Vertrauen liegt, welche Komponente was tun darf und wohin Daten fließen.

Dieses Kapitel richtet sich an Entwicklungsteams und Architekten, die die verteilten Architekturen und Datenarchitekturen aus Kapitel sechs und sieben kennen und sie nun sicher machen müssen. Jede Service-Grenze, jede Queue, jeder Cache, jede Replik und jede Analysekopie vergrößert die Angriffsfläche. Verteilung vervielfacht die Vertrauensgrenzen, und die Datenarchitektur entscheidet, wie viele Kopien personenbezogener Daten existieren und wie lange sie bestehen. Das Kapitel behandelt Sicherheit als Qualitätsmerkmal, das in die Struktur hineinentworfen wird, im Sinne der Sicherheitsszenarien aus Kapitel zwei, und nicht als Liste von Produkten, die man am Ende kauft. Es setzt außerdem den Abschnitt über Netzwerke, HTTPS und TLS aus Kapitel null voraus. Und es führt zu Kapitel neun, das das abgesicherte System auch unter Last schnell und lauffähig hält.

Das durchgehende Beispiel ist die Essenslieferplattform aus dem ganzen Kurs: Kunden, Restaurants und Kuriere, ein API-Gateway, Services für Bestellungen, Zahlungen, Disposition und Benachrichtigungen, ein Event-Stream und ein Data Warehouse. Abschnitt acht Punkt eins legt das Vokabular fest: Vertraulichkeit, Integrität und Verfügbarkeit, die Designprinzipien von Saltzer und Schroeder aus dem Jahr neunzehnhundertfünfundsiebzig, etwa Least Privilege, dann Defense in Depth, sichere Voreinstellungen und die OWASP Top Ten. Abschnitt acht Punkt zwei macht aus diesen Prinzipien eine wiederholbare Designtätigkeit. Sie zeichnen ein Datenflussdiagramm mit seinen Vertrauensgrenzen, fragen mit STRIDE und Angriffsbäumen, was schiefgehen kann, bewerten die Risiken und entscheiden über Gegenmaßnahmen. Abschnitt acht Punkt drei behandelt, wer aufruft: Passwörter, Passkeys, Sessions und Tokens, OAuth mit PKCE, OpenID Connect und die wichtigsten Modelle, mit denen man entscheidet, was jeder Aufrufer tun darf. Abschnitt acht Punkt vier behandelt Verschlüsselung bei der Übertragung und im Ruhezustand, Passwort-Hashing, Schlüsselverwaltung mit Envelope Encryption, Secrets, Tokenisierung und die Entscheidung, was wo verschlüsselt wird.

Hier ist einer der zentralen Gedanken aus Abschnitt acht Punkt eins, Defense in Depth, gezeichnet entlang des Wegs, den eine Bestellung durch die Plattform nimmt. Oben steht die Kunden-App, außerhalb der Vertrauensgrenze. Sie spricht mit der Plattform nur über HTTPS, und nichts auf dem Gerät gilt der Plattform als vertrauenswürdig. Innerhalb der Grenze fügt jede Schicht eigene Kontrollen hinzu. Die Edge fängt Verkehrsfluten ab, wendet Rate Limits an und blockiert bekannte Angriffsmuster. Das API-Gateway prüft jedes Token und lehnt Anfragen ab, die nicht zum API-Schema passen. Der Bestellservice prüft, ob dieser Kunde genau diese Bestellung sehen darf. Die Datenbank nutzt ein Konto mit Least Privilege und ist im Ruhezustand verschlüsselt, die Backups mit eigenen Schlüsseln. Sicherheits-Logging, Erkennung und Alarmierung laufen über alle Schichten. Weil jede Schicht eigene Kontrollen hat, legt eine einzelne umgangene Kontrolle die Daten nicht offen.

Die zweiten vier Abschnitte weiten den Blick. Abschnitt acht Punkt fünf ersetzt die Vorstellung eines vertrauenswürdigen internen Netzwerks durch Authentifizierung und Autorisierung bei jeder Anfrage zwischen Services, mit Mutual TLS, Zertifikaten und getrennten Stellen, an denen Policies entschieden und durchgesetzt werden. Abschnitt acht Punkt sechs behandelt Abhängigkeiten, Build-Systeme und Container-Images als Teil der Angriffsfläche, mit Software Bills of Materials, Signaturen und der Cyberresilienz-Verordnung der EU. Abschnitt acht Punkt sieben erklärt, wie die DSGVO und die UK GDPR die Architektur prägen: Datenminimierung, Pseudonymisierung, die Rechte der betroffenen Personen, Aufbewahrung und Löschung über Backups und Event-Logs hinweg. Und Abschnitt acht Punkt acht schließt den Kreis mit Sicherheits-Logging, Erkennung, Schwachstellenmanagement, Incident Response und der Meldung von Sicherheitsverletzungen.

Dieses Diagramm aus Abschnitt acht Punkt fünf zeigt, was Zero Trust verändert. Vorher, in einem flachen internen Netzwerk, kann jeder Host jeden Port erreichen, und alle Services teilen sich eine Datenbank. Wird der Speisekarten-Service kompromittiert, kann der Angreifer direkt zu den Zahlungen gehen. Nachher hat jeder Service seine eigene Datenbank, und nur benannte Identitäten dürfen erlaubte Aufrufe machen. Der Bestellservice ruft den Zahlungsservice über Mutual TLS auf, geregelt durch eine Policy. Versucht der kompromittierte Speisekarten-Service, den Zahlungsservice aufzurufen, wird er abgewiesen. Beachten Sie, was Zero Trust nicht leistet. Es verhindert nicht, dass ein Service kompromittiert wird. Es begrenzt, was der kompromittierte Service erreichen kann.

Ein Architekt muss weder Penetrationstester noch Kryptograf sein und sollte keine eigene Kryptografie erfinden. Der Architekt trifft die Entscheidungen, die teuer zu ändern sind: wo die Vertrauensgrenzen verlaufen und welchen Identity Provider und welches Token-Modell die ganze Plattform nutzt. Außerdem, welche Daten als vertraulich eingestuft und mit welchen Schlüsseln verschlüsselt werden und wie Services einander ihre Identität nachweisen. Diese Entscheidungen gehören in Architecture Decision Records, wie jede andere wichtige Entscheidung. Entwicklungsteams verantworten ebenso wichtige Aufgaben: Eingaben validieren, Ausgaben kodieren, die Sicherheitsbibliotheken der Plattform richtig nutzen, Fehler ohne Fail-open behandeln und Abhängigkeiten aktuell halten. Beide treffen sich in der Bedrohungsmodellierung, in Reviews des sicheren Designs und in automatisierten Prüfungen in der Delivery-Pipeline.

Sicherheit und Datenschutz sind voller nummerierter Normen und Rechtsvorschriften. Das Kapitel benennt sie präzise, nennt die zum Zeitpunkt des Schreibens aktuelle Fassung, Oktober zweitausendsechsundzwanzig, und verweist auf die maßgebliche Quelle. Die Ausführungen zur Regulierung erklären, wie sich das Recht auf die Architektur auswirkt. Sie sind Information, keine Rechtsberatung. Für eine konkrete Situation bleiben die Juristen und der Datenschutzbeauftragte der eigenen Organisation die richtigen Ansprechpartner.

Wenn Sie sich aus diesem Kapitel nur eines merken, dann dies. Entscheiden Sie, wem und was Ihr System vertraut, wofür und warum. Entscheiden Sie es bewusst, früh und schriftlich, statt es implizit zu lassen. Und machen Sie jede dieser Vertrauensentscheidungen überprüfbar. Bedrohungsmodelle, Least Privilege, OAuth-Scopes, Envelope Encryption, Mutual TLS, signierte Builds und Audit-Logs sind alles Wege, implizites Vertrauen durch explizites, überprüfbares Vertrauen zu ersetzen. Ein so entworfenes System begrenzt den Schaden des Sicherheitsvorfalls, der irgendwann kommen wird, und kann seinen Kunden, Prüfern und Aufsichtsbehörden zeigen, wie es sie schützt.

Am besten lesen Sie die Abschnitte der Reihe nach. Jeder steht aber auch für sich, sodass Sie direkt zu dem Abschnitt gehen können, den Sie brauchen. Planen Sie für das ganze Kapitel etwa dreieinhalb Stunden Lesezeit ein. Am Ende jedes Abschnitts stehen Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie sich die Antworten ansehen. Wenn Sie so weit sind, gibt es einen freiwilligen Kapiteltest, der etwa fünfundvierzig Minuten dauert. Er hat zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten. Die Bestehensgrenze liegt bei achtzig Prozent.

So ist das Kapitel aufgebaut. Beginnen Sie mit Abschnitt acht Punkt eins, Sicherheitsprinzipien für Architekten, wo das Vokabular für alles Weitere festgelegt wird. Bis gleich.