"Das dauert länger wegen Security." Diesen Satz höre ich oft in Enterprise-Projekten.
In den meisten Fällen liegt die Ursache in der Architektur, nicht in der Sicherheit selbst.
Das Vorurteil
Die Annahme: Enterprise-Sicherheit kostet Zeit. Compliance-Checks, Security-Reviews, Penetration Tests, Audit-Trails. All das braucht Wochen. Also plant man Wochen ein.
Am Ende des Projekts. Wenn der Code fertig ist.
Das Ergebnis: Der Security-Review findet Probleme. Die Probleme erfordern Änderungen. Die Änderungen verzögern den Go-Live. Der Zeitplan platzt. Und alle sagen: "Security hat uns gebremst."
Die eigentliche Ursache: Security als nachträgliche Phase statt als Teil der Architektur.
Security by Design
Security by Design dreht die Reihenfolge um. Security ist keine Phase am Ende. Security ist eine Architekturentscheidung am Anfang.
Konkret:
Least Privilege von Tag 1. Jeder Service, jede Lambda-Funktion, jeder Container bekommt nur die Berechtigungen, die er braucht. Nicht mehr. IAM-Rollen werden vor dem ersten Feature definiert. Nicht danach.
Infrastructure as Code. Jede Security-Konfiguration ist versioniert, reviewbar und reproduzierbar. Kein manuelles Klicken in der AWS Console. Keine Ad-hoc-Änderungen an Security Groups. Alles ist im Code. Alles ist im Git.
Encryption by Default. Data at rest, data in transit. Keine Ausnahmen.
Kein "Das können wir später machen". KMS-Keys werden beim Projekt-Setup angelegt, nicht beim Security-Review.
Network Isolation. VPCs, Security Groups, NACLs. Jeder Service lebt in seinem Netzwerksegment. Kommunikation nur über definierte Pfade. Wer auf etwas zugreifen will, muss es explizit begründen.
Warum Cloud-native das Problem löst
On-Premise-Security war tatsächlich langsam. Firewall-Änderungen brauchten Tickets. Netzwerk-Umbauten brauchten Wartungsfenster. Zertifikate brauchten manuelle Installation.
Cloud-native ist anders. Security-Konfigurationen sind API-Calls. Änderungen sind in Sekunden deployed. Rollbacks sind ein Git-Revert. Die Infrastruktur ist so flexibel wie der Code.
AWS gibt uns die Werkzeuge: GuardDuty für Anomalie-Erkennung. SecurityHub für Compliance-Checks. Config Rules für automatisierte Audits. CloudTrail für lückenlose Protokollierung.
Beim HR Data Hub bei Siemens Energy verarbeitet das System HR-Daten aus über 150 Ländern mit unterschiedlichen Datenschutzanforderungen. Die Security-Freigabe für die Produktionsumgebung kam in Wochen. Nicht weil wir Abkürzungen genommen haben, sondern weil Encryption by Default, Least Privilege und Network Isolation von der ersten Codezeile an in der Architektur steckten.
Das alles automatisiert. Keine manuelle Prüfung. Keine Wartezeiten. Die Sicherheit läuft mit der gleichen Geschwindigkeit wie die Entwicklung.
Beispiel: 1.500 AWS Accounts bei Siemens
Die SE AI Platform bei Siemens Energy läuft in einer Enterprise-Security-Zone mit über 1.500 AWS Accounts. Jeder mit eigenen Security-Anforderungen. Cross-Account-Zugriffe für AI Agents. Multi-Region-Deployments. Compliance-Anforderungen in verschiedenen Jurisdiktionen.
Die Architektur: Zentrale Security-Policies, die über AWS Organizations verteilt werden. Service Control Policies, die bestimmte Aktionen in bestimmten Accounts unmöglich machen, unabhängig von individuellen Berechtigungen. Cross-Account-Rollen mit Session-Policies und minimaler Gültigkeit.
Ergebnis: 120.000 Nutzer arbeiten mit 50 AI-Modellen. Hunderttausende Nachrichten
pro Tag. Keine Security-Incidents. Kein einziger Go-Live wurde durch Security verzögert.
Nicht weil wir Security ignoriert haben. Sondern weil Security von Anfang an Teil der Architektur war.
Self-Healing Security
Bei Siemens Energy geht die Sicherheitsarchitektur einen Schritt weiter: Ein AI Agent überwacht die gesamte Infrastruktur. Er analysiert CloudWatch-Logs, erkennt Anomalien und führt automatisch Root-Cause-Analysen durch.
Wenn eine Lambda-Funktion unerwartete Fehler produziert, analysiert der Agent den Fehler, prüft die Security-Konfiguration und postet die Analyse in Slack. Bevor ein Mensch morgens seinen Laptop aufklappt, weiß das Team bereits, was passiert ist und warum.
Das ist kein Monitoring. Das ist aktive Sicherheit. Ein System, das sich selbst heilt.
Was das für Architektur-Entscheidungen bedeutet
Drei Prinzipien, die sich in Enterprise-Projekten bewährt haben:
-
Security ist ein Feature, kein Gate. Security-Anforderungen gehören in User Stories. Nicht in eine separate Security-Phase.
-
Automatisierung schlägt Prozess. Jede Security-Prüfung, die automatisiert werden kann, wird automatisiert. Compliance-Checks in der CI/CD-Pipeline. Nicht im Review-Meeting.
-
Weniger Vertrauen, mehr Verifikation. Zero Trust ist kein Buzzword. Es ist eine Architekturentscheidung. Jeder Service muss sich authentifizieren. Jeder Zugriff wird geloggt. Keine Ausnahmen.
Fazit
Enterprise-Sicherheit und Geschwindigkeit sind kein Widerspruch. Sie werden nur dann zum Widerspruch, wenn Security als nachträgliche Phase betrachtet wird, statt als Teil der Architektur.
Schnell liefern. Und sicher liefern. Nicht trotzdem. Sondern deswegen.
