Security by Design: Wie Sie Sicherheit von Anfang an in Ihre Systemarchitektur einbauen

Security by Design heißt, Sicherheitsentscheidungen dort zu treffen, wo sie am billigsten sind: beim Entwurf der Architektur, nicht nach dem ersten Vorfall. Für eine IT-Leitung, die Webanwendungen ohne eigenes Entwicklungsteam verantwortet, ist das der Unterschied zwischen einem System, das sich pflegen lässt, und einem, das jede Woche neue Löcher stopft.

Was Security by Design ist

Security by Design ist ein Architekturprinzip: Jede Komponente und jeder Datenfluss wird von Beginn an mit seinen Sicherheitsanforderungen entworfen. Der Gegenentwurf ist der übliche Ablauf, bei dem Sicherheit am Ende „draufgesetzt“ wird, meist unter Zeitdruck und meist unvollständig. Der Unterschied zeigt sich an einer Schnittstelle: Wer eine API von Anfang an mit Authentifizierung und verschlüsselten Endpunkten entwirft, hat sie einmal gebaut. Wer beides nachrüstet, baut sie zweimal und findet dazwischen heraus, welche Clients unverschlüsselt mitgelesen haben.

Die vier Säulen einer sicheren Architektur

Bedrohungsmodellierung als Startpunkt

Bevor eine Zeile Code entsteht, wird gefragt: Wer könnte dieses System angreifen, worauf hat er es abgesehen, und über welchen Weg kommt er hinein? Ein bewährtes Raster ist STRIDE, das Bedrohungen in sechs Kategorien einteilt, von gefälschten Identitäten bis zur Rechteausweitung. Sie zeichnen die Datenflüsse Ihrer Anwendung auf eine Seite, gehen jede Komponente mit dem Raster durch und priorisieren die Gegenmaßnahmen nach Schaden und Wahrscheinlichkeit. Das Ergebnis passt auf wenige Seiten und ist mehr wert als jeder Sicherheitskatalog, den niemand liest.

Prinzip der geringsten Rechte

Jeder Dienst, jede Komponente und jeder Nutzer bekommt genau die Berechtigungen, die für die Aufgabe nötig sind. Ein Dienst, der nur lesen muss, bekommt keinen Schreibzugriff, auch wenn das die Entwicklung um einen Tag verkürzen würde. Der Grund ist einfach: Wird ein Dienst kompromittiert, bestimmt sein Berechtigungsumfang den Schaden. Ein Zahlungsdienst, der nur die Transaktionstabelle sieht, kann keine Kundendaten abfließen lassen.

Verteidigung in mehreren Schichten

Keine einzelne Maßnahme hält jeden Angriff auf. Eine Web Application Firewall vor der Anwendung filtert automatisierte Angriffe und Bots, Eingabeprüfung in der Anwendung fängt, was durchkommt, Verschlüsselung auf dem Transportweg und in der Datenbank begrenzt den Schaden, wenn beides versagt, und eine getrennte Datenhaltung für sensible Daten sorgt dafür, dass ein Einbruch in den Webshop nicht den Zugriff auf Zahlungsdaten bedeutet. Fällt eine Schicht, greift die nächste. Eine WAF allein ist keine Sicherheitsarchitektur, sie ist deren äußerste Schicht.

Sicherheit als Dauerbetrieb

Security by Design endet nicht mit der Inbetriebnahme. Automatisierte Prüfungen in der Auslieferungspipeline scannen jeden Stand auf bekannte Schwachstellen, bevor er produktiv geht. Abhängigkeiten werden regelmäßig aktualisiert, Penetrationstests decken auf, was die Automatik übersieht. Eine Architektur, die beim Entwurf sicher war und danach zwei Jahre keine Updates bekommen hat, ist nicht mehr sicher.

Sicherheitsupdates und Backups auslagern oder selbst betreiben: die Frage nach dem Betrieb

Die beste Architektur nützt nichts, wenn niemand die Sicherheitsupdates einspielt und niemand prüft, ob die Backups zurückgespielt werden können. Genau hier scheitern viele Webanwendungen im Mittelstand: Sie wurden einmal sauber gebaut und dann sich selbst überlassen, weil die IT-Leitung neben dem Tagesgeschäft keine Kapazität für den Dauerbetrieb hat.

Sie haben zwei ehrliche Optionen. Entweder Sie betreiben die Anwendung selbst, mit einem festen Zeitbudget für Updates, Backup-Tests und Überwachung. Oder Sie geben den Betrieb an einen Partner mit Wartungsvertrag, der Überwachung rund um die Uhr, Sicherheitsupdates, Backups und verbindliche Reaktionszeiten zusagt. Was ein seriöser Partner nicht zusagen kann, ist die Lösungszeit für jeden denkbaren Vorfall. Reaktionszeit garantiert, Lösung nach bestem Bemühen: Wer Ihnen mehr verspricht, hat den Vertrag nicht zu Ende gedacht.

Methoden, die sich in der Praxis bewähren

Datenflussdiagramm mit Bedrohungsraster. Eine Seite, alle Komponenten, alle Datenflüsse, jede Komponente gegen die STRIDE-Kategorien geprüft. Die Gegenmaßnahmen wandern direkt in die Architekturbeschreibung.

Sicherheit als nicht-funktionale Anforderung. Sicherheitsanforderungen werden wie Antwortzeiten oder Lastgrenzen formuliert und im Architektur-Review geprüft. Der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik liefert dafür brauchbare Bausteine, ohne dass Sie eine Zertifizierung anstreben müssen.

Architektur-Reviews mit Sicherheitsfokus. Bevor ein neuer Dienst gebaut wird, prüft jemand mit Sicherheitsblick, ob die Kommunikation authentifiziert ist, ob Berechtigungen minimal sind und ob sensible Daten getrennt liegen. Eine Stunde vor dem Bau spart Wochen danach.

Typische Fehler

Der häufigste Fehler ist, Security by Design mit vielen Sicherheitswerkzeugen gleichzusetzen. Werkzeuge finden bekannte Lücken; eine falsche Architektur finden sie nicht. Der zweite Fehler ist der Zeitpunkt: Sicherheitsentscheidungen fallen erst, wenn das System fast fertig ist, und werden dann teuer. Der dritte betrifft die Cloud: Ein Cloud-Anbieter liefert Bausteine für Identitäten, Verschlüsselung und Netztrennung, konfiguriert sie aber nicht für Sie. Die Cloud ist so sicher, wie Sie sie eingerichtet haben.

Häufige Fragen zu Security by Design

Was ist der Unterschied zu Security by Default? Security by Design betrifft den Entwurf, Security by Default die Auslieferung: Ein System ist in seiner Standardeinstellung sicher, ohne dass der Nutzer etwas umstellen muss. Das eine liefert die Grundlage für das andere.

Ist das nur für große Unternehmen relevant? Im Gegenteil. Ein mittelständisches Unternehmen hat selten die Kapazität, Sicherheit nachträglich einzubauen. Die DSGVO und die europäischen Vorgaben zur Netz- und Informationssicherheit verlangen ohnehin einen vorausschauenden Ansatz.

Wie passt das zu agiler Entwicklung? Bedrohungsmodellierung wird für jede neue Funktion eingeplant, automatisierte Sicherheitsprüfungen laufen mit jeder Auslieferung. Sicherheit wird ein Teil der Definition von „fertig“, kein Termin am Ende.

Der nächste Schritt: eine Anwendung auf einer Seite durchspielen

Nehmen Sie Ihre am stärksten exponierte Webanwendung und zeichnen Sie ihre Datenflüsse auf eine Seite: Wo kommt eine Anfrage herein, wo wird sie authentifiziert, wo liegen die Daten, wer spielt Updates ein, wann wurde das letzte Backup zurückgespielt? Bleiben dabei weiße Flecken, gehen wir das Blatt in einer halben Stunde gemeinsam durch und klären, was davon Architektur ist und was Betrieb: Potenzial-Check buchen.