12 Secure by Design Prinzipien: Ein Praxisleitfaden für Security Manager

Die meisten Sicherheitsprinzipien klingen in der Theorie selbstverständlich. Doch zwischen dem Kennen dieser Prinzipien und ihrer konsequenten Anwendung in realen Systemen liegen Welten. Zwölf Prinzipien prägen, wie Secure by Design in der Praxis funktioniert. Die eigentliche Herausforderung liegt nicht darin, sie zu kennen, sondern sie systemübergreifend konsequent umzusetzen ohne in den üblichen Ausnahmen, Workarounds und vergessenen Service Accounts zu versinken.

Einige dieser Prinzipien zielen darauf ab, Angriffe zu verhindern, bevor sie überhaupt entstehen. Andere stellen sicher, dass Schutzmaßnahmen nach dem Deployment nicht stillschweigend erodieren. In der Praxis verschwimmt diese Unterscheidung, ist aber ein nützlicher Ausgangspunkt, wenn man verstehen möchte, wo die eigene Organisation bereits gut aufgestellt ist und wo noch blinde Flecken liegen.

Was Secure by Design bedeutet und warum es wichtig ist

Die zwölf Prinzipien in unserem Leitfaden bauen auf der Grundlagenarbeit von Saltzer und Schroeder auf, die 1975 in ihrem Paper The Protection of Information in Computer Systems viele davon erstmals definiert haben, darunter Least Privilege, Complete Mediation und Open Design. Jahrzehnte später sind diese Prinzipien nach wie vor relevant.

Secure by Design verankert Sicherheit in jeder Schicht des System-Designs, von Architektur und Code bis hin zu Betrieb und Governance. Es setzt auf sichere Defaults, Least Privilege, minimale Attack Surfaces und kontinuierliche Assurance. Das Ziel: Systeme, die unter Druck standhalten, anstatt Systeme, die nach dem Deployment ständig nachgebessert werden müssen. Während nachträgliche Sicherheitsmaßnahmen Kontrollen einführen, nachdem Risiken bereits bestehen, verhindert SbD Schwachstellen an ihrer Quelle und reduziert damit Kosten, Komplexität und operativen Aufwand.

Präventive Sicherheitsprinzipien: Angriffswege schließen

Diese Prinzipien reduzieren Wahrscheinlichkeit und Auswirkung von Angriffen, indem sie begrenzen, was ungeschützt ist, wer darauf zugreifen kann und wie sich das System bei Fehlern verhält.

Least Privilege: Wer braucht diesen Zugriff wirklich – und genau jetzt?

Jede*r Nutzer*In, jeder Prozess und jedes System erhält nur die Berechtigungen, die für die jeweilige Aufgabe tatsächlich benötigt werden und nicht mehr. Die Beschränkung auf das absolute Minimum reduziert das Risiko, dass Fehler, Fehlkonfigurationen oder Kompromittierungen weitreichenden Schaden anrichten. Dadurch wird der Blast Radius eines Breaches kleiner, Privilege Escalation wird verhindert, und Audits werden vereinfacht, weil Zugriffsgrenzen klar definiert sind.

In der Praxis:

• Role-based Access Control (RBAC) weist Berechtigungen Rollen zu, nicht Einzelpersonen.
• Just-in-time (JIT) Access gewährt erhöhte Privilegien temporär für spezifische Aufgaben und entzieht sie danach automatisch.
• Service Account Scoping beschränkt System- und API-Accounts auf die Ressourcen, die sie tatsächlich benötigen.

Worauf zu achten ist: Privilege Creep bei Rollenwechseln – hier helfen regelmäßige Access Reviews und IGA-Tooling –, übermäßig weitreichende Default-Berechtigungen in SaaS-Plattformen, geteilte Admin-Accounts, die Accountability eliminieren, sowie vernachlässigte Service Accounts mit statischen oder hardcodierten Credentials.

Fail Securely: Wenn etwas ausfällt, fällt es sicher aus?

Ein sicheres System fällt bei Ausfällen, Degradierungen oder Fehlern standardmäßig in einen Zustand der Ablehnung oder Eindämmung zurück. Zugriff wird explizit gewährt, nie implizit angenommen, weil etwas schiefgelaufen ist. Ausfälle sind unvermeidbar. Wer aber für sicheres Versagen entwickelt, verhindert, dass Ausfälle, Bugs oder Fehlkonfigurationen zu Security Incidents werden.

In der Praxis:

• Eine Deny-by-Default-Policy gewährt Zugriff nur nach erfolgreicher Authentifizierung und Autorisierung.
• Graceful Degradation hält wesentliche Sicherheitsfunktionen aufrecht, anstatt das System abstürzen oder sich öffnen zu lassen.
• Sicheres Exception Handling fängt Fehler sauber ab und vermeidet, dass Stack Traces, Tokens oder sensible Daten in Logs oder Nutzermeldungen erscheinen.

Worauf zu achten ist: Fail-open-Controls wie Firewalls, die bei Nichtverfügbarkeit standardmäßig auf „Allow” schalten, ausführliche Fehlermeldungen, die Implementierungsdetails preisgeben, sowie im Produktivbetrieb aktive Debug-Modi.

 

Complete Mediation: Autorisieren wir jede einzelne Anfrage, jedes Mal?

Jeder Zugriff auf eine Ressource wird jedes Mal geprüft. Autorisierungsprüfungen finden nicht nur einmalig beim Login statt. Kein*e Nutzer*In, kein Prozess, keine Anfrage schlüpft aufgrund von Caching, Abkürzungen oder veralteten Vertrauensannahmen durch. Dies ist eine der Grundlagen, auf denen Zero Trust aufbaut: kontinuierlich verifizieren, nicht einmalig.

In der Praxis:

• Zentralisierte Access Control leitet alle Anfragen durch einen einzigen Policy Enforcement Point.
• Kurzlebige Tokens laufen ab und erfordern eine Neuausstellung; aktive Sessions werden in regelmäßigen Abständen re-validiert, anstatt auf langlebige Credentials zu setzen.
• API Gateways und Service Meshes wenden Autorisierungsprüfungen an jeder Microservice-Grenze an.

Worauf zu achten ist: alleinige Abhängigkeit von der initialen Login-Validierung, gecachte Autorisierungen, die veralten sobald sich Privilegien ändern, sowie Shadow APIs oder undokumentierte Endpoints, die die Autorisierungslogik umgehen.

Economy of Mechanism: Würde ein einfacheres Design dieselbe Aufgabe erfüllen?

Komplexität ist der Feind der Sicherheit. Jede zusätzliche Komponente, jedes Konfigurations-Flag und jeder Code Path ist eine potenzielle Quelle für Fehlkonfigurationen, Missverständnisse oder Exploits. Komplexe Systeme lassen sich zudem kaum vollständig verifizieren oder auditieren. Gut verstandene Building Blocks sind proprietären Designs vorzuziehen, überlappende Controls sollten konsolidiert statt gestapelt werden, und toter Code sowie ungenutzte Features sind konsequent zu entfernen.

Minimize the Attack Surface: Wo können wir heute sicher Dinge abschalten?

Jeder offene Port, jedes exponierte API und jede übermäßige Berechtigung ist eine Angriffsmöglichkeit. Service Minimization schaltet ungenutzte Ports und Netzwerk-Listener ab. Network Segmentation isoliert sensible Systeme und erschwert Lateral Movement. Zero Trust validiert kontinuierlich jede*n Nutzer*In und jedes Gerät. Zu beachten sind Feature Creep, Legacy-Systeme, die „nur für den Fall” weiterlaufen, und Schatten-IT, die niemand im Blick hat.

Defense in Depth: Welche Schichten stoppen einen Angriff, wenn eine Kontrolle versagt?

Keine einzelne Kontrolle hält jede Bedrohung auf. Mehrere unabhängige Maßnahmen wirken zusammen, um Angriffe zu verzögern, zu erkennen und einzudämmen. Multi-Factor Authentication schützt den Zugang, selbst wenn Credentials gestohlen wurden. Mehrschichtige Netzwerksicherheit kombiniert Perimeter Firewalls, interne Segmentierung und Endpoint-Schutz. Entscheidend ist, dass die Schichten unabhängig und wirksam sind. Doch mehr Schichten sind nicht automatisch besser. Jede erhöht die Komplexität und die zu triagierenden Alerts. Daher gilt: sinnvolle Abdeckung unterschiedlicher Angriffspfade anstelle von Überlappungen, die das Team erschöpfen.

Sicherheit nachhaltig verankern: Sichtbarkeit, Accountability und Kontrolle

Prävention allein reicht nicht aus. Diese Prinzipien stellen sicher, dass Sicherheitsentscheidungen transparent und wirksam bleiben, während sich Systeme und Organisationen verändern.

Psychological Acceptability: Sicheres Verhalten zum einfachsten Weg machen

Sicherheit funktioniert am besten, wenn sie sich natürlich anfühlt. Wenn Kontrollen in den Arbeitsalltag passen, hören Nutzer*Innen auf, nach Abkürzungen zu suchen. SSO und Passwordless Authentication vereinfachen den Zugang, ohne die Sicherheit zu kompromittieren. Das Principle of Least Astonishment bedeutet, dass Interfaces und Workflows vorhersehbar funktionieren. Wenn sicheres Verhalten das einfachste Verhalten ist, folgt Compliance von selbst.

Open Design: Transparente Sicherheit schlägt Security through Obscurity

Ein sicheres System bleibt sicher, selbst wenn alle wissen, wie es funktioniert. Echter Schutz basiert auf gut gehüteten Geheimnissen wie Encryption Keys und nicht auf versteckten Mechanismen. Security Architecture Diagrams sollten aktuell und versioniert gehalten, Datenflüsse klar dokumentiert und Infrastructure-as-Code für konsistente, auditierbare Konfigurationen eingesetzt werden.

 

Separation of Duties: Welche kritischen Schritte erfordern ein zweites Augenpaar?

Keine einzelne Person sollte End-to-End-Kontrolle über einen sensiblen Prozess haben. Die Aufteilung von Verantwortlichkeiten auf verschiedene Personen oder Systeme schafft natürliche Kontrollpunkte, macht Kollusion zur Voraussetzung für Missbrauch und gibt Reviewer*Innen eine faire Chance, Fehler zu erkennen, bevor sie Schaden anrichten.

Auditability und Traceability: Können wir nachweisen, wer was getan hat und wann?

Jede wesentliche Aktion, Entscheidung und Änderung muss zu ihrer Quelle nachverfolgbar sein. Umfassendes Logging erfasst Authentication Events, Autorisierungsentscheidungen und Konfigurationsänderungen. Immutable Log Storage verhindert die Manipulation von Beweisen. Zentralisiertes Log Management ermöglicht Korrelation und Echtzeit-Analyse für schnellere Threat Detection.

Continuous Assurance: Wie stellen wir sicher, dass Controls jederzeit funktionieren?

Assurance ist kein einmaliges Audit. Continuous Compliance Monitoring prüft die Einhaltung von Frameworks wie ISO 27001, NIST oder CIS Benchmarks. Security-as-Code verankert Policies direkt in CI/CD-Pipelines. Breach-and-Attack Simulation (BAS) testet, ob Abwehrmaßnahmen tatsächlich wie geplant performen und macht Sicherheit von einer periodischen Inspektion zu einem kontinuierlichen Prozess.

Least Common Mechanism: Was sollten wir aufhören zu teilen, um das Risiko zu reduzieren?

Jede geteilte Komponente – Datenbanken, Caches, Identity-Systeme – schafft potenzielle Pfade für unbeabsichtierten Informationsfluss oder Privilege Escalation. Dedizierte Ressourcen für kritische Workloads verhindern Cross-Tenant-Exposure. Microservices und Container Isolation reduzieren das Cross-Contamination-Risiko. Per-Service IAM Roles und separate Encryption Keys gewährleisten starke Isolation auch in geteilter Infrastruktur.

Secure by Design Prinzipien in der Praxis anwenden

Secure by Design ist keine Checkliste, die man einmal abarbeitet. Die präventiven Prinzipien schließen Angriffswege auf Architekturebene, während die nachhaltigen Prinzipien sicherstellen, dass diese Schutzmaßnahmen sichtbar und wirksam bleiben, wenn sich Systeme und Organisationen verändern. Wenn Sicherheitskontrollen intuitiv, mehrschichtig und automatisiert sind, hören sie auf, als Zusatzaufwand wahrgenommen zu werden und werden stattdessen zur Selbstverständlichkeit.