Defense in Depth, Least Privilege, Zero Trust — diese Prinzipien klingen abstrakt, haben aber konkrete Auswirkungen auf jede Architekturentscheidung. Wo steht die Datenbank? Wie authentifiziert sich der Microservice? Welche Daten fließen über welche Grenzen? A.8.27 fordert, dass Sicherheitsprinzipien dokumentiert werden und bei der Entwicklung und dem Betrieb aller Informationssysteme angewandt werden.
Die Kontrolle richtet sich an Architekten und Entwicklungsverantwortliche: Sicherheit wird in das Design eingebaut, bevor die erste Zeile Code geschrieben wird.
Was verlangt die Norm?
- Architekturprinzipien definieren. Dokumentierte Richtlinien für die sichere Systemarchitektur auf allen Ebenen (Geschäft, Daten, Anwendung, Infrastruktur).
- Defense in Depth. Mehrere unabhängige Schutzschichten, damit der Ausfall einer Schicht nicht zum Gesamtversagen führt.
- Zero Trust. Kein implizites Vertrauen innerhalb oder außerhalb des Systems — jeder Zugriff wird authentifiziert und autorisiert.
- Regelmäßige Überprüfung. Das Systemdesign wird regelmäßig überprüft, um mit neuen Bedrohungen und technologischen Veränderungen Schritt zu halten.
- Outsourcing einbeziehen. Wenn Entwicklung ausgelagert wird, muss der Lieferant die definierten Architekturprinzipien einhalten.
In der Praxis
Architekturprinzipien-Dokument erstellen. Definiere die verbindlichen Sicherheitsprinzipien: Defense in Depth, Least Privilege, Zero Trust, Fail Secure, Separation of Duties. Für jedes Prinzip konkrete Umsetzungshinweise (z.B. „Jeder Microservice authentifiziert sich mit mTLS”).
Threat Modeling bei neuen Systemen. Vor der Implementierung: Architekturdiagramm erstellen, Vertrauensgrenzen einzeichnen, Datenflüsse analysieren, Bedrohungen identifizieren und Gegenmaßnahmen ableiten. Das Ergebnis ist ein dokumentiertes Bedrohungsmodell.
Architektur-Reviews durchführen. Bei jeder wesentlichen Architekturänderung und mindestens jährlich: Stimmt die Architektur noch mit den Sicherheitsprinzipien überein? Sind neue Bedrohungen aufgetaucht? Gibt es technologische Veränderungen, die das Design beeinflussen?
Cloud-Architektur besonders prüfen. Shared-Responsibility-Modell dokumentieren: Was sichert der Cloud-Anbieter, was liegt in deiner Verantwortung? Cloud-native Sicherheitsdienste (WAF, IAM, KMS, Security Hub) konsequent nutzen.
Typische Audit-Nachweise
- Architekturprinzipien-Dokument — definierte und genehmigte Sicherheitsprinzipien (→ Richtlinie sichere Softwareentwicklung im Starter Kit)
- Threat Models — dokumentierte Bedrohungsanalysen für kritische Systeme
- Architektur-Review-Protokolle — Nachweis regelmäßiger Überprüfungen
- Architekturdiagramme — aktuelle Darstellungen mit Sicherheitszonen und Vertrauensgrenzen
- Cloud-Responsibility-Matrix — dokumentierte Verantwortlichkeitsverteilung bei Cloud-Nutzung
KPI
Anteil der Systeme, die nach dokumentierten sicheren Architekturprinzipien entworfen wurden
Gemessen als Prozentsatz: Wie viele deiner kritischen Systeme haben ein dokumentiertes Bedrohungsmodell und einen Architektur-Review innerhalb der letzten 12 Monate? Ziel: 100%.
Ergänzende KPIs:
- Anteil der neuen Projekte mit Threat Modeling vor Implementierungsbeginn
- Anzahl der Architektur-Findings pro Review (Trend-Indikator)
BSI IT-Grundschutz
- CON.8 (Software-Entwicklung) — sichere Architekturprinzipien als Teil des Entwicklungsprozesses. Verlangt Bedrohungsanalyse, Entwurfsmuster und regelmäßige Reviews.
- APP.6/APP.7 — Architekturanforderungen für allgemeine und webbasierte Anwendungen.
Verwandte Kontrollen
- A.8.25 — Sicherer Entwicklungslebenszyklus: Der Rahmen, in dem die Architekturprinzipien umgesetzt werden.
- A.8.26 — Anwendungssicherheitsanforderungen: Anforderungen, die in der Architektur berücksichtigt werden.
- A.8.22 — Trennung von Netzwerken: Netzwerksegmentierung als Architekturprinzip.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.27 — Sichere Systemarchitektur und Ingenieurprinzipien
- ISO/IEC 27002:2022 Abschnitt 8.27 — Umsetzungshinweise
- BSI IT-Grundschutz, CON.8 — Software-Entwicklung