Sicherheitsprinzipien für Architekten

Sicherheit als Qualität der Struktur

Kapitel 2 hat Sicherheit als Qualitätsmerkmal eingeführt: die Fähigkeit des Systems, Daten und Funktionen vor unbefugter Nutzung zu schützen und zugleich den Befugten zu dienen, ausgedrückt durch testbare Sicherheitsszenarien, die einen Angreifer, einen Angriff, ein Ziel und eine messbare Reaktion benennen. Dieses Kapitel geht den nächsten Schritt und fragt, wie Architektur diese Qualität hervorbringt. Die Antwort lautet: Die meisten Sicherheitseigenschaften werden durch die Struktur entschieden, also dadurch, welche Komponenten es gibt, welche davon welchen anderen vertrauen, wo Daten gespeichert und kopiert werden und durch welche wenigen Punkte jede Anfrage laufen muss.

Betrachten Sie, wie reale Sicherheitsvorfälle entstehen. Ein Angreifer ändert die Bestellnummer in einer URL und sieht die Adresse eines anderen Kunden, weil der Service geprüft hat, ob der Benutzer angemeldet ist, aber nicht, ob die Bestellung ihm gehört. Ein Storage-Bucket mit Datenbankexporten ist aus dem Internet lesbar, weil vor Jahren eine Voreinstellung geändert wurde. Ein interner Reporting-Service akzeptiert jede Anfrage aus dem Netzwerk, sodass ein einziger kompromittierter Laptop jeden Kundendatensatz erreicht. Keiner dieser Fälle braucht raffinierte Kryptografie, um ausgenutzt zu werden; jeder ist eine Designentscheidung über Vertrauen, die niemand ausdrücklich getroffen hat. Security by Design heißt, diese Entscheidungen bewusst, früh und schriftlich zu treffen und es dann schwer zu machen, sie versehentlich zu verletzen.

Sicherheitsarchitektur steht deshalb neben den anderen Querschnittsanliegen aus Abschnitt 8 von arc42: ein Identitätsmodell, ein Autorisierungsmodell, ein Datenschutzkonzept und ein Logging-Konzept, an die sich jedes Team hält. Der Rest dieses Abschnitts legt das Vokabular und die Prinzipien fest, auf denen die übrigen Abschnitte des Kapitels aufbauen.

Vertraulichkeit, Integrität und Verfügbarkeit in einem realen System

Die CIA-Triade ist der Ausgangspunkt. Auf der Essenslieferplattform umfasst Vertraulichkeit die Namen, Adressen, Telefonnummern und Bestellhistorien der Kunden, die Live-Standorte und Ausweisdokumente der Kuriere, die Bankverbindungen der Restaurants für Auszahlungen und die eigenen Secrets der Plattform. Integrität umfasst Preise, Warenkorbsummen, Erstattungen, Kurierauszahlungen und die Speisekarte, die ein Kunde sieht: Ein Angreifer, der den Preis eines Gerichts auf null setzen oder die Auszahlungen eines Restaurants auf sein eigenes Bankkonto umleiten kann, hat nichts Geheimes gelesen, aber ernsten Schaden angerichtet. Verfügbarkeit zählt am meisten während der Abendspitze, wenn ein Denial-of-Service-Angriff oder eine Ransomware-Infektion jede Minute Umsatz kostet.

ISO/IEC 25010:2023 ergänzt Authentizität (Identitäten lassen sich nachweisen), Verantwortlichkeit (Aktionen lassen sich auf den zurückführen, der sie ausgeführt hat), Nichtabstreitbarkeit (es lässt sich nachweisen, dass Aktionen stattgefunden haben) und Widerstandsfähigkeit (das Produkt arbeitet auch unter Angriff wie vorgesehen weiter). Architekten sollten für jedes Asset benennen, welche Eigenschaften zählen, weil sie in verschiedene Richtungen ziehen. Fail-closed schützt Vertraulichkeit und Integrität, kostet aber Verfügbarkeit: Ist der Autorisierungsservice ausgefallen, lehnt ein Fail-closed-Bestellservice Bestellungen ab. Fail-open bewahrt die Verfügbarkeit und setzt alles andere aufs Spiel. Die richtige Wahl unterscheidet sich je Vorgang: Die Anzeige einer öffentlichen Speisekarte kann per Fail-open auf eine zwischengespeicherte Kopie ausweichen, eine Erstattung dagegen muss fail-closed sein.

Die Designprinzipien von Saltzer und Schroeder

1975 veröffentlichten Jerome Saltzer und Michael Schroeder, gestützt auf ihre Erfahrung mit dem Betriebssystem Multics am MIT, in The Protection of Information in Computer Systems acht Designprinzipien für Schutzmechanismen. Ein halbes Jahrhundert später sind sie noch immer die meistzitierte Grundlage sicheren Designs, weil es in ihnen um Struktur geht und nicht um Technologie. Die Tabelle formuliert jedes Prinzip neu und gibt ein modernes Beispiel von der Essenslieferplattform.

Defense in Depth

Defense in Depth bedeutet, mehrere unabhängige Kontrollen übereinanderzuschichten, sodass das Versagen oder Umgehen einer einzelnen das Asset nicht offenlegt. Die Idee stammt aus dem militärischen Festungsbau und ist in der funktionalen Sicherheit ebenso Standardpraxis wie in der IT-Sicherheit. Ihr Wert hängt ganz am Wort unabhängig: Zwei Schichten, die aus demselben Grund versagen, etwa zwei Services, die beide einem gefälschten Header vertrauen, sind eine Schicht, die zweimal gezeichnet wurde.

Das Diagramm zeigt die Schichten auf dem Bestellpfad der Essenslieferplattform. Hat die Token-Validierung des Gateways einen Bug, verhindert die Prüfung auf Objektebene im Bestellservice trotzdem, dass ein Kunde die Bestellung eines anderen liest. Stiehlt ein Angreifer die Disk-Snapshots der Datenbank, schützt sie die Verschlüsselung im Ruhezustand mit Schlüsseln, die anderswo liegen. Versagt all das, sollte das Monitoring das ungewöhnliche Anfragemuster bemerken, und jemand sollte reagieren. Defense in Depth ist auch die ehrliche Antwort auf die Frage „Was, wenn diese Kontrolle versagt?“, die jedes Bedrohungsmodell stellt.

Secure by Default und Security by Design

Ein Produkt ist Secure by Default, wenn seine Konfiguration im Auslieferungszustand die sichere ist, sodass jede Schwächung des Schutzes eine bewusste Handlung erfordert. Viele große Sicherheitsvorfälle gingen auf unsichere Voreinstellungen zurück, die nie geändert wurden: Datenbanken, die ohne Passwort im Internet erreichbar waren, Administratorkonsolen mit Werkszugangsdaten, Storage-Buckets, die sich mit einer einzigen Einstellung öffentlich machen ließen. Die Anbieter haben reagiert: Seit April 2023 werden zum Beispiel neue Amazon-S3-Buckets mit eingeschaltetem Block Public Access und deaktivierten Access Control Lists angelegt. 2023 veröffentlichten die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) und Partnerbehörden aus mehreren Ländern gemeinsame Leitlinien, die Hersteller drängen, Produkte Secure by Design und Secure by Default zu gestalten, und 2024 startete die CISA eine freiwillige Secure-by-Design-Selbstverpflichtung für Softwarehersteller.

Für Architekten gilt Secure by Default für die Plattform ebenso wie für Produkte. Enthält die gemeinsame Service-Vorlage bereits Token-Validierung, strukturiertes Sicherheits-Logging, einen Container-Benutzer ohne Root-Rechte und ein Datenbankkonto mit Least Privilege, startet jeder neue Service sicher, und Teams müssen sich ausdrücklich dagegen entscheiden, was im Review sichtbar wird. Das nennen manche Organisationen eine Paved Road: Der einfachste Weg ist zugleich der sichere.

Eng damit verwandt ist die Frage, wie sich ein System verhält, wenn etwas schiefgeht. Die OWASP Top 10:2025 haben eine Kategorie für den fehlerhaften Umgang mit Ausnahmesituationen aufgenommen, zu der auch Fail-open gehört: ein Fehler in einer Berechtigungsprüfung, der abgefangen und ignoriert wird, ein Timeout, das standardmäßig „erlaubt“ ergibt, ein Parsing-Fehler, der die Validierung überspringt. Ausfallsichere Standardwerte, im Code angewendet, bedeuten, dass jeder Ausnahmepfad in einer Sicherheitsentscheidung in einer Ablehnung endet.

Angriffsfläche und Vertrauensgrenzen

Die Angriffsfläche ist alles, was ein Angreifer erreichen und beeinflussen kann: öffentliche Endpoints und ihre Parameter, offene Ports, Datei-Uploads, Message Queues, die Eingaben von Partnern annehmen, Webhooks, Administratorkonsolen, mobile Apps, die sich dekompilieren lassen, sowie der Code von Drittanbietern und die Menschen, denen das System vertraut. Michael Howard bei Microsoft machte Anfang der 2000er-Jahre die Idee bekannt, sie zu messen; die praktische Regel lautet, sie so klein wie möglich zu halten und genau zu wissen, was dazugehört. Einen ungenutzten Endpoint zu entfernen, einen Administratorport zum Internet hin zu schließen oder ein Feature abzuschalten, das niemand nutzt, senkt das Risiko günstiger als jede zusätzliche Kontrolle. Jede Wahl eines Architekturstils in Kapitel 6 hat hier einen Sicherheitspreis: Jeder neue, über das Netzwerk erreichbare Service bringt Endpoints, Zugangsdaten und Datenverkehr hinzu, die geschützt werden müssen.

Eine Vertrauensgrenze ist die Stelle, an der Daten oder Steuerung zwischen Teilen mit unterschiedlichem Vertrauens- oder Berechtigungsniveau wechseln. Die offensichtlichste liegt zwischen dem Internet und der Plattform, aber es gibt viele weitere: zwischen der Kunden-App und der API, zwischen dem Tablet eines Restaurants und dem Speisekarten-Service, zwischen Services verschiedener Teams, zwischen der Plattform und einem Zahlungsanbieter, zwischen Anwendungscode und Datenbank sowie zwischen normalen Benutzern und Administratoren. Vertrauensgrenzen sind wichtig, weil dort die Prüfungen hingehören: Authentifizierung, Autorisierung, Eingabevalidierung und Ausgabekodierung finden statt, wenn Daten eine Grenze überqueren, nie unter der Annahme, die andere Seite habe es schon erledigt. Die Vertrauensgrenzen in ein Datenflussdiagramm einzuzeichnen, ist der erste Schritt der Bedrohungsmodellierung.

Die OWASP Top 10 als Sensibilisierungsliste

Die OWASP Top 10 sind die Rangliste der kritischsten Sicherheitsrisiken für Webanwendungen des Open Worldwide Application Security Project, zusammengestellt aus eingereichten Schwachstellendaten und einer Umfrage in der Community. Die aktuelle Ausgabe, die OWASP Top 10:2025, ist die achte. Gegenüber der Ausgabe von 2021 bleibt Broken Access Control auf Platz eins und umfasst nun auch Server-Side Request Forgery, Security Misconfiguration steigt auf Platz zwei, die frühere Kategorie Vulnerable and Outdated Components wird zu Software Supply Chain Failures erweitert, und eine neue Kategorie behandelt Mishandling of Exceptional Conditions.

Behandeln Sie die Liste als das, was sie laut OWASP ist: ein Dokument zur Sensibilisierung, keine Norm. Sie ist nützlich für Schulungen, um zu prüfen, ob ein Bedrohungsmodell nicht eine ganze Klasse von Problemen übersehen hat, und für Gespräche mit Stakeholdern. Sie ist keine vollständige Sammlung von Anforderungen, und „Wir sind OWASP-Top-10-konform“ bedeutet wenig. Für überprüfbare Anforderungen listet der Application Security Verification Standard (ASVS) von OWASP testbare Kontrollen auf drei Strengestufen auf, und die separate OWASP API Security Top 10 behandelt API-spezifische Risiken wie Broken Object Level Authorization.

Ein sicherer Entwicklungslebenszyklus und Shift Left

Ein sicherer Entwicklungslebenszyklus baut Sicherheitsaktivitäten in jede Phase der Auslieferung ein, statt sich auf einen Test kurz vor dem Release zu verlassen. Microsoft machte seinen Security Development Lifecycle 2004 verbindlich, nach dem Trustworthy-Computing-Memo von Bill Gates aus dem Jahr 2002, und die Idee verbreitete sich in der ganzen Branche. Die aktuelle Referenz ist das Secure Software Development Framework (SSDF) von NIST, SP 800-218, dessen Version 1.1 im Februar 2022 veröffentlicht wurde; im Dezember 2025 legte NIST einen Entwurf einer Überarbeitung (Version 1.2) zur Kommentierung vor, der zum Zeitpunkt des Schreibens noch nicht final war. Das SSDF gliedert die Praktiken in vier Gruppen: die Organisation vorbereiten (Rollen, Schulung, Toolchains, Sicherheitsanforderungen), die Software schützen (Code und Build-Integrität schützen, Herkunftsnachweise aufbewahren), gut gesicherte Software produzieren (so entwerfen, dass die Sicherheitsanforderungen erfüllt werden, Bedrohungsmodelle erstellen, prüfen und testen, standardmäßig sicher konfigurieren) und auf Schwachstellen reagieren (erkennen, beheben und die Grundursachen analysieren, damit dieselbe Klasse nicht wiederkehrt). Es beschreibt Ergebnisse, statt Werkzeuge vorzuschreiben, und ist deshalb eine gute Checkliste für einen Architekten, der einen Auslieferungsprozess bewertet.

Shift Left heißt, Sicherheitsarbeit nach vorn zu verlagern: Sicherheitsanforderungen und Missbrauchsfälle zusammen mit den User Stories, Bedrohungsmodellierung im Design, statische Analyse und Secret-Scanning bei jedem Commit, Abhängigkeitsprüfungen in der Pipeline. Das wirtschaftliche Argument kennen Sie aus Kapitel 1: Eine fehlende Autorisierungsprüfung, die im Design-Review gefunden wird, kostet eine Stunde; derselbe Fehler, nach einem Sicherheitsvorfall gefunden, kostet eine Meldung an die Aufsichtsbehörden. Fachleute sind uneins, wie weit man das treiben sollte. Befürworter sagen, Entwickler, die Sicherheit verstehen, schreiben weniger Schwachstellen. Kritiker weisen darauf hin, dass es Entwicklungsteams mit minderwertigen Befunden überflutet, wenn man ihnen einfach Sicherheitswerkzeuge vorschaltet, und Sicherheit zur Teilzeitaufgabe aller und zur Expertise von niemandem macht; sie plädieren für sichere Voreinstellungen in der Plattform (die Paved Road), damit der sichere Weg keinen Zusatzaufwand erfordert, und für Sicherheitsfachleute, die dort eingebunden sind, wo das Risiko am höchsten ist. Die meisten reifen Organisationen tun beides und testen und überwachen außerdem weiterhin in der Produktion, weshalb manche inzwischen davon sprechen, Sicherheit überall hin zu verlagern („Shift Everywhere“).

Was Architekten verantworten und was Entwicklungsteams verantworten

Sicherheitsarbeit ist geteilt, und Unklarheit darüber, wer was verantwortet, ist selbst eine Schwachstelle. Der Architekt verantwortet Entscheidungen, die Teamgrenzen überschreiten und teuer zu ändern sind; die Teams verantworten deren korrekte Anwendung. Ein verbreitetes Muster ist ein kleines zentrales Sicherheitsteam, das Standards setzt und die Sicherheitsdienste der Plattform betreibt, Security Champions in jedem Produktteam, die Bedrohungsmodellierung und Reviews leiten, und Architekten, die dafür sorgen, dass die strukturellen Entscheidungen getroffen und festgehalten werden.