Security by Design ist das Prinzip, Sicherheitsanforderungen von Anfang an in die Konzeption und Architektur eines Systems zu integrieren – anstatt sie nachträglich als Ergänzung aufzusetzen. Ein System, das von Grund auf sicher entworfen wurde, ist strukturell sicherer, günstiger zu betreiben und weniger anfällig für Fehler als eines, bei dem Sicherheit als nachträgliche Schicht hinzugefügt wurde. Das Gegenteil – Sicherheit als Afterthought – führt zu teuren Retrofits, inhärenten Schwachstellen und der fortwährenden Jagd auf neue Angriffsflächen.
Das eng verwandte Prinzip Privacy by Design (DSGVO Art. 25) überträgt dasselbe Konzept auf den Datenschutz: Datenschutzfreundliche Voreinstellungen und minimale Datenerhebung sind von Beginn an in das System eingebaut, nicht nachträglich konfiguriert. Beide Prinzipien zusammen – Security by Design und Privacy by Design – sind der Qualitätsstandard für moderne Automatisierungsarchitekturen.
Security-by-Design-Prinzipien in der Praxis
Least Privilege by Default
Jede neue Komponente startet mit minimalen Rechten. Erweiterung nur auf explizite, dokumentierte Begründung. Kein „erstmal Admin, dann einschränken“.
Defense in Depth
Mehrere unabhängige Schutzschichten. Kein einzelner Punkt, dessen Kompromittierung das gesamte System gefährdet. Authentifizierung, Verschlüsselung, Monitoring – alle unabhängig.
Fail Secure
Bei Fehler oder Ausfall: sicherer Zustand, nicht offener Zustand. Eine fehlgeschlagene Authentifizierungsprüfung verweigert den Zugang – nicht gewährt ihn aus Fehlertoleranz.
Separation of Concerns
Sicherheitskritische Komponenten (Auth, Secrets, Logging) sind von Geschäftslogik getrennt. Fehler in der Geschäftslogik können keine Sicherheitskomponenten beeinflussen.
Secure Defaults
Alle sicherheitsrelevanten Einstellungen sind standardmäßig auf den sichersten Wert gesetzt. Öffnung nur auf expliziten Bedarf, nicht Schließung nach Problemerkennung.
Auditierbarkeit eingebaut
Logging, Audit-Trails und Monitoring sind nicht optional und nicht nachträglich hinzugefügt. Jede sicherheitsrelevante Aktion ist von Anfang an protokolliert.
Praxisbeispiel
Ein Automationsdienstleister definiert Security-by-Design-Checkliste für jeden neuen Workflow. Muss vor Go-Live beantwortet werden: Least Privilege – hat der Service-Account nur die minimal notwendigen Rechte? (minimale API-Scopes definiert?) Secrets – sind alle Credentials im Secret-Manager, kein Klartext in Konfiguration? Verschlüsselung – sind alle Verbindungen TLS 1.3, alle gespeicherten Daten verschlüsselt? Logging – werden alle sicherheitsrelevanten Ereignisse protokolliert, keine sensitiven Daten in Logs? Fehlerbehandlung – liefert kein Fehler-Response sensible Systeminformationen zurück? Input-Validierung – werden alle externen Eingaben validiert und sanitized? DSGVO – welche personenbezogenen Daten, welche Rechtsgrundlage, welche Aufbewahrungsfrist? Diese 7 Punkte nehmen 30 Minuten pro Workflow. Sie verhindern, dass ein Workflow mit bekannten Schwachstellen in Produktion geht.
