Wer Sicherheit erst am Ende des Entwicklungsprozesses denkt, hat sie schon verloren. IT-Sicherheit ist kein Add-on – sie ist eine fundamentale Entwurfsentscheidung. Warum nachträgliche Absicherung strukturell scheitert und was Security-by-Design konkret bedeutet.
Sicherheit als Architekturprinzip: Warum nachträgliche Absicherung systematisch scheitert
IT-Sicherheit wird in vielen Unternehmen noch immer als separate Schicht behandelt, die sich nachträglich über bestehende Systeme legen lässt. Diese Denkweise erzeugt strukturelle Schwachstellen, die sich durch konsequentes Security-by-Design vermeiden ließen – ein Thema, das Architekten und Sicherheitsverantwortliche zunehmend gemeinsam adressieren müssen.
Das strukturelle Problem: Sicherheit als Zusatz
Wenn Sicherheitsanforderungen erst nach der Systemgestaltung berücksichtigt werden, entstehen Risiken, die sich nicht mehr vollständig beheben lassen. Architekturentscheidungen – etwa wie Komponenten miteinander kommunizieren, wie Daten fließen oder wie Vertrauen zwischen Diensten organisiert ist – legen den Grundstein für das spätere Angriffspotenzial eines Systems.
Ein nachträglich aufgesetztes Sicherheitskonzept kann fundamentale Entwurfsentscheidungen allenfalls kaschieren, aber nicht korrigieren.
Das Kernproblem ist dabei nicht mangelnder Wille, sondern eine organisatorische Trennung: Softwarearchitekten und Sicherheitsteams arbeiten häufig in getrennten Silos, mit unterschiedlichen Zielen, Metriken und Zeitplänen. Sicherheitsreviews finden oft erst kurz vor dem Deployment statt – zu einem Zeitpunkt, an dem grundlegende Änderungen wirtschaftlich kaum mehr vertretbar sind.
Systemische Schwachstellen entstehen durch Entwurfsentscheidungen
Viele der in der Praxis beobachteten Sicherheitsvorfälle lassen sich auf Entwurfsentscheidungen zurückführen, die ursprünglich keinen offensichtlichen Sicherheitsbezug hatten. Breite Berechtigungsmodelle, fehlende Isolation zwischen Diensten oder unzureichendes Logging sind oft keine Versehen, sondern das Ergebnis von Architekturentscheidungen, bei denen Sicherheitsaspekte nicht Teil der Abwägung waren.
Die folgenden Prinzipien sind keine reinen Sicherheitsmaßnahmen – sie sind Architekturpraktiken:
- Least Privilege – minimale Rechtevergabe für jeden Dienst und jede Komponente
- Trust Boundaries – explizite Segmentierung von Vertrauensbereichen
- Threat Modeling – strukturierte Modellierung von Angriffsflächen bereits im Entwurf
Werden sie nicht von Beginn an in den Entwurfsprozess integriert, entstehen systemische Schwachstellen, die sich durch nachgelagerte Kontrollen nicht vollständig schließen lassen.
Threat Modeling als gemeinsame Sprache
Ein zentrales Werkzeug zur Überbrückung der Lücke zwischen Architektur und Sicherheit ist das strukturierte Threat Modeling. Es zwingt Teams dazu, potenzielle Angreifer, ihre Ziele und mögliche Angriffswege bereits in frühen Designphasen zu durchdenken.
Das Framework STRIDE klassifiziert Bedrohungen nach sechs Kategorien:
| Kürzel | Bedrohungstyp |
|---|---|
| S | Spoofing |
| T | Tampering |
| R | Repudiation |
| I | Information Disclosure |
| D | Denial of Service |
| E | Elevation of Privilege |
Entscheidend ist dabei nicht die Vollständigkeit der Analyse, sondern die Etablierung eines gemeinsamen Vokabulars zwischen Entwicklungs-, Architektur- und Sicherheitsteams.
Organisatorische Konsequenzen
Die technische Integration von Sicherheit in die Architekturarbeit erfordert auch organisatorische Anpassungen. Zwei Modelle haben sich in der Praxis bewährt:
- Security-Champions-Programme: Einzelne Entwickler bringen Sicherheitskompetenz gezielt in ihre Teams ein.
- Architecture Review Boards: Die Einbindung von Sicherheitsexperten sorgt dafür, dass Sicherheitsanforderungen früh im Entscheidungsprozess sichtbar werden.
Für deutsche Unternehmen kommt eine zusätzliche regulatorische Dimension hinzu: Die NIS2-Richtlinie, seit Oktober 2024 in nationales Recht überführt, verpflichtet betroffene Organisationen explizit dazu, Sicherheit in ihre Entwicklungs- und Betriebsprozesse zu integrieren.
Unternehmen, die Sicherheit strukturell in ihre Systemarchitektur einbetten, erfüllen diese Anforderungen nicht nur einfacher – sie reduzieren gleichzeitig ihr tatsächliches Risikoprofil nachhaltig.
Quelle: InfoQ – Security Architecture & Systemic Vulnerabilities
