Security by Design

Security by Design ist ein Gestaltungsprinzip, bei dem Sicherheitsaspekte von Beginn an in die Architektur eines Systems eingebaut werden — nicht nachträglich aufgesetzt. In der Softwareentwicklung bedeutet das: Jede Entwurfsentscheidung berücksichtigt potenzielle Angriffsvektoren, Zugriffsrechte und Datenflüsse. Das Prinzip ist eng verwandt mit Privacy by Design und wird durch Normen wie ISO 27001 operationalisiert.

1. Was bedeutet Security by Design?
2. Die Kernprinzipien
3. Security by Design vs. Security by Default
4. Security by Design und DSGVO
5. Umsetzung in der Praxis
6. Weiterführende Informationen

Was bedeutet Security by Design?

Die Grundidee ist älter als das Internet selbst. Jerome Saltzer und Michael Schroeder formulierten 1975 in ihrem Aufsatz „The Protection of Information in Computer Systems” Designprinzipien für sichere Systeme, die bis heute Gültigkeit haben. Ihr zentraler Gedanke: Sicherheit ist keine Funktion, die man einem System hinzufügt. Sie ist eine Eigenschaft, die aus der Architektur folgt — oder eben nicht.

In der modernen App-Entwicklung bedeutet Security by Design, dass Sicherheitsüberlegungen jede Entwurfsentscheidung begleiten: Wie werden Daten gespeichert? Wer darf auf welche Endpunkte zugreifen? Wie werden Eingaben validiert? Welche Kommunikationswege sind verschlüsselt? Diese Fragen werden nicht im Nachhinein beantwortet, sondern bestimmen die Architektur von Anfang an.

Der Gegenentwurf — erst entwickeln, dann absichern — produziert Software mit strukturellen Schwächen. Wenn die Berechtigungslogik nachträglich über eine bestehende Architektur gelegt wird, entstehen Lücken, die sich durch Patches nicht schließen lassen. Security by Design vermeidet diese Lücken, indem es sie gar nicht erst entstehen lässt.

Die Kernprinzipien

Saltzer und Schroeders Arbeit hat eine Reihe von Prinzipien hervorgebracht, die unter dem Begriff Security by Design zusammengefasst werden. Sie sind abstrakt formuliert, lassen sich aber direkt in Softwarearchitektur übersetzen.

Least Privilege — minimale Berechtigungen.
Jede Komponente, jeder Benutzer und jeder Prozess erhält nur die Rechte, die für die jeweilige Aufgabe nötig sind. In der Praxis bedeutet das: Ein Microservice, der Bestelldaten liest, hat keinen Schreibzugriff auf die Benutzerdatenbank. Ein API-Token für den Reporting-Dienst kann keine Konfigurationsänderungen vornehmen.
Defense in Depth — gestaffelte Verteidigung.
Kein einzelner Schutzmechanismus ist perfekt. Security by Design setzt deshalb auf mehrere unabhängige Sicherheitsschichten. Wenn die Web Application Firewall eine SQL Injection nicht erkennt, fängt die parametrisierte Datenbankabfrage den Angriff ab. Wenn der Angreifer Zugangsdaten erbeutet, verhindert die Zwei-Faktor-Authentifizierung den Zugriff.
Fail Secure — sicheres Versagen.
Wenn ein System ausfällt oder eine Komponente in einen unerwarteten Zustand gerät, darf das Ergebnis kein offener Zugang sein. Ein Beispiel: Wenn der Authentifizierungsdienst nicht erreichbar ist, verweigert das System den Zugang — es gewährt ihn nicht pauschal.
Separation of Concerns — Trennung der Zuständigkeiten.
Sicherheitskritische Funktionen werden von der Geschäftslogik getrennt. Die Authentifizierung läuft über einen eigenen Dienst. Die Verschlüsselung wird über eine zentrale Bibliothek gesteuert, nicht in jedem Modul neu implementiert. Dadurch lassen sich Sicherheitskomponenten unabhängig testen, aktualisieren und auditieren.
Attack Surface Minimization — Angriffsfläche reduzieren.
Jede Schnittstelle, jeder offene Port, jede API-Route ist ein potenzieller Eintrittspunkt. Security by Design fragt: Welche Endpunkte sind wirklich nötig? Welche Dienste müssen öffentlich erreichbar sein? Welche Funktionen können entfernt oder deaktiviert werden? Eine kleinere Angriffsfläche bedeutet weniger Möglichkeiten für Angreifer.

Security by Design vs. Security by Default

Beide Begriffe werden häufig zusammen genannt, beschreiben aber unterschiedliche Konzepte.

Security by Design bezieht sich auf den Entwicklungsprozess. Es geht um Architekturentscheidungen, die während der Konzeption und Implementierung getroffen werden: Wie ist das System aufgebaut? Welche Sicherheitsmechanismen sind strukturell verankert?

Security by Default bezieht sich auf die Auslieferungskonfiguration. Es geht um die Frage: Wie sicher ist das System im Auslieferungszustand, ohne dass der Betreiber manuelle Anpassungen vornimmt? Sind unnötige Dienste deaktiviert? Sind Standardpasswörter erzwungen zu ändern? Ist die restriktivste Konfiguration die Standardkonfiguration?

Ein konkretes Beispiel verdeutlicht den Unterschied: Ein System mit Security by Design hat eine rollenbasierte Zugriffskontrolle in seiner Architektur verankert. Security by Default stellt sicher, dass ein neu angelegter Benutzer die minimalen Rechte erhält — nicht die maximalen. Das eine betrifft die Bauweise, das andere die Voreinstellungen. Beide ergänzen sich, keines ersetzt das andere.

Security by Design und DSGVO

Art. 25 der Datenschutz-Grundverordnung fordert „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen”. Der Gesetzgeber hat damit Security by Design und Security by Default — bezogen auf personenbezogene Daten — zur rechtlichen Pflicht gemacht.

Für Softwareentwickler bedeutet das konkret: Wer Anwendungen baut, die personenbezogene Daten verarbeiten, muss die Schutzmaßnahmen bereits in der Konzeptionsphase festlegen. Datenminimierung, Zweckbindung, Löschroutinen und Zugriffskontrollen sind keine optionalen Extras, sondern Pflichtbestandteile der Architektur.

Die Verbindung zu ISO 27001 liegt auf der Hand: Die Norm liefert das Managementsystem, das die technischen Maßnahmen der DSGVO strukturiert. Wer ein ISMS nach ISO 27001 betreibt, hat die organisatorischen Voraussetzungen für Privacy by Design bereits geschaffen.

Umsetzung in der Praxis

Security by Design bleibt ein leeres Prinzip, wenn es nicht in konkrete Entwicklungspraktiken übersetzt wird.

Threat Modeling im Entwurf.
Vor dem Coding steht die Analyse: Welche Bedrohungen sind für diese Anwendung realistisch? Methoden wie STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) helfen, Angriffsvektoren systematisch zu identifizieren. Das Ergebnis ist kein Dokument für die Schublade, sondern eine Checkliste für die Implementierung.
Security Architecture Reviews.
Bei komplexen Systemen prüft ein erfahrener Entwickler oder externer Experte die Architektur auf Schwachstellen — bevor sie implementiert wird. Das ist kostengünstiger als jede nachträgliche Korrektur.
Secure Coding Standards.
Dokumentierte Regeln für den Umgang mit Eingabevalidierung, Authentifizierung, Kryptografie und Fehlerbehandlung schaffen eine gemeinsame Basis im Team. Die Annex-A-Controls der ISO 27001 machen solche Standards für zertifizierte Organisationen verbindlich.
Automatisierte Sicherheitstests.
SAST, DAST und Dependency Scanning sind in die CI/CD-Pipeline integriert. Jede Änderung wird automatisch geprüft. Sicherheit wird damit Teil des normalen Entwicklungsworkflows — nicht eine separate Aktivität vor dem Release.