Keine Hintertür für Hacker: Fünf Fakten zu Security by Design

München, 9. November 2026 - Cybersecurity beginnt nicht mit der Abwehr eines Angriffs, sondern mit der Architektur. Wer Sicherheit erst im laufenden Betrieb nachrüstet, riskiert unnötige Gefahren. NTT DATA , ein weltweit führender Anbieter von KI-, digitalen Business- und Technologie-Services, erklärt, warum Security by Design heute Pflichtprogramm ist.

Ein Hacker benötigt keine spektakuläre Zero-Day-Lücke, wenn ein vergessener Account, eine alte Schnittstelle oder ein überprivilegierter Zugang die Tür bereits weit offenstehen lassen. Die meisten Sicherheitsrisiken liegen in der Architektur, bei Berechtigungen und in gewachsenen IT-Strukturen. Die Herausforderung wird durch die zunehmende Automatisierung noch größer. Denn ein kompromittierter oder manipulierter Agent kann großen Schaden anrichten. Fünf Fakten zeigen, warum Security by Design so wichtig ist.

• Fakt 1: Wer Sicherheit erst beim Pentest entdeckt, ist zu spät dran. Ein geplanter, simulierter Cyberangriff ist ein wichtiges Instrument, um die Widerstandsfähigkeit einer IT-Umgebung zu überprüfen. Er sollte jedoch nicht der Moment sein, in dem ein Unternehmen erstmals erfährt, wie und wo seine Systeme miteinander verbunden sind. Genau das passiert jedoch häufig: Über Jahre gewachsene Berechtigungen, vergessene Accounts oder alte Schnittstellen bleiben unbemerkt, weil sie im Tagesgeschäft funktionieren und deshalb niemand einen Anlass sieht, sie zu hinterfragen.Security by Design setzt früher an: Bereits bei der Architektur einer Anwendung, der Definition einer Schnittstelle oder der Einführung eines neuen Services müssen Sicherheitsanforderungen berücksichtigt werden. Welche Identität darf worauf zugreifen? Welche Daten werden tatsächlich benötigt? Welche Aktionen sind erforderlich? Was passiert, wenn ein Zugang kompromittiert wird? Werden diese Fragen erst nach der Implementierung gestellt, sind Fehlentscheidungen häufig bereits in Abhängigkeiten und Berechtigungsmodellen verankert.
• Fakt 2: Vertraue niemandem, auch nicht dem eigenen Netzwerk. Ein Angreifer benötigt keinen vollständigen Zugriff auf die IT. Ein einziger kompromittierter Zugang reicht aus, um sich schrittweise weiterzubewegen, Rechte auszubauen und zusätzliche Systeme zu erreichen. Genau deshalb darf die Zugehörigkeit zu einem Unternehmensnetzwerk kein Vertrauensvorschuss sein.Das Zero-Trust-Prinzip setzt an diesem Punkt an: Jede Anfrage muss anhand seines konkreten Kontexts bewertet werden. Dabei ist insbesondere zu klären, wer auf welche Ressource für wie lange von welchem Gerät aus zugreifen darf. Eine erfolgreiche Authentifizierung allein sollte nicht automatisch weitreichende Rechte bedeuten.Dabei darf Zero Trust nicht bei Netzwerksegmentierung und VPN-Zugängen enden. Das Prinzip muss bis in die Anwendungen reichen. Eine Cloud-Applikation sollte beispielsweise nicht allein deshalb öffentlich erreichbar sein, weil Mitarbeitende mobil darauf zugreifen. Auch die Unterscheidung zwischen "intern" und "extern" ist nicht zielführend. Ein kompromittiertes Notebook im Büro kann genauso gefährlich sein wie ein gestohlenes Benutzerkonto im Homeoffice. Entscheidend ist nicht, aus welchem Netz ein Zugriff kommt, sondern welche Identität auf welche Ressource zugreifen möchte und was sie dort tun darf.
• Fakt 3: Ein kompromittierter Account ist gefährlich, einer mit zu vielen Rechten eine Katastrophe. Zero Trust reduziert das implizite Vertrauen. Least Privilege begrenzt anschließend den möglichen Schaden. Beides gehört zusammen: Selbst wenn ein Angreifer einen Account übernimmt, sollte er nur auf die Ressourcen zugreifen können, die für die jeweilige Aufgabe tatsächlich notwendig sind. Dies gilt nicht nur für Benutzer, sondern für sämtliche Identitäten innerhalb einer modernen IT-Architektur. In Microservice-Umgebungen beispielsweise darf ein Service nicht automatisch mit weitreichenden Rechten auf einen anderen zugreifen, nur weil beide Teil derselben Anwendung sind. Authentifizierung und Autorisierung müssen entlang der gesamten Kommunikationskette nachvollziehbar bleiben. Gerade in historisch gewachsenen Umgebungen ist das nicht trivial. Legacy-Systeme lassen sich nicht immer vollständig nach modernen Prinzipien umbauen. Trotzdem sind klar definierte Rollen, minimale Berechtigungen und nachvollziehbare Accounts dem historisch gewachsenen "Das funktioniert doch" eindeutig überlegen.
• Fakt 4: KI-Agenten brauchen dieselben Sicherheitsregeln wie ihre menschlichen Kollegen. KI-Agenten verschärfen das Berechtigungsproblem, weil sie nicht nur lesen, sondern auch handeln. Dafür benötigen sie Zugriff auf Anwendungen, Datenbanken, Dokumente, APIs und Geschäftsprozesse. Genau darin liegt jedoch ein gefährlicher Zielkonflikt: Je größer der Handlungsspielraum eines Agenten ist, desto größer ist der potenzielle Schaden im Falle einer Manipulation oder Kompromittierung.Deshalb muss Least Privilege auch für nicht-menschliche Identitäten gelten. Ein Agent, der Kundendaten analysiert, benötigt keinen automatischen Zugriff auf Finanzinformationen. Ein Agent, der Support-Tickets klassifiziert, muss nicht eigenständig Tickets schließen oder Prozesse verändern können. Und ein Agent, der Informationen aus einem ERP-System liest, sollte nicht ohne zusätzliche Kontrolle Stammdaten verändern dürfen. Unternehmen müssen bereits vor dem produktiven Einsatz definieren, welche Daten ein Agent sehen, welche Systeme er aufrufen und welche Aktionen er autonom ausführen darf. Zusätzlich sollten mögliche adversariale Angriffe und Manipulationsmöglichkeiten Bestandteil der Sicherheitsanalyse sein.
• Fakt 5: Wenn Security funktionieren soll, muss sie einfach sein. In der Praxis scheitern Sicherheitsmaßnahmen nicht selten an ihrer mangelnden Nutzerfreundlichkeit. Je komplizierter ein Verfahren ist, desto größer ist die Wahrscheinlichkeit, dass Mitarbeitende nach alternativen Lösungen suchen. Security by Design muss deshalb Sicherheit und Usability gemeinsam betrachten.Ein durchgängiges Identity- und Access-Management kann beispielsweise nicht nur Risiken reduzieren, sondern auch die Nutzung der IT vereinfachen. Single Sign-on verringert die Zahl unterschiedlicher Anmeldungen, Multi-Faktor-Authentifizierung schützt kritische Zugriffe und passwortlose Verfahren können die Abhängigkeit von leicht zu kompromittierenden Zugangsdaten reduzieren.Entscheidend ist dabei ein konsistentes Modell über Endpunkte, Netzwerke und Anwendungen hinweg. Nutzer sollten nicht mit immer neuen Sicherheitsmechanismen konfrontiert werden, sondern möglichst nur dann zusätzliche Nachweise erbringen müssen, wenn Risiko und Kontext dies rechtfertigen.

"Eine vollständige Security-by-Design-Transformation kann schnell zum Mammutprojekt werden. Sämtliche Systeme müssten inventarisiert, Abhängigkeiten dokumentiert, Berechtigungen überprüft und Richtlinien neu definiert werden. Das Ergebnis ist ein umfangreicher Report, aber nicht zwangsläufig eine deutlich sicherere IT. Deshalb ist Priorisierung entscheidend. Ein zielgerichtetes Security Assessment kann zunächst zeigen, wo die größten Risiken liegen und welche Maßnahmen den größten Effekt versprechen. Entscheidend ist dabei nicht allein die technische Kritikalität eines Systems, sondern dessen Bedeutung für das Geschäft", sagt Matthias Straub, Senior Vice President Cybersecurity Consulting bei NTT DATA DACH. "Hinzu kommt: Die IT verändert sich kontinuierlich. Neue Schnittstellen entstehen, Berechtigungen ändern sich oder es kommen weitere Cloud-Services hinzu. Deshalb muss Sicherheit Bestandteil des gesamten Lebenszyklus sein: von der Architektur über Entwicklung und Testing bis zu Change-Prozessen und Betrieb."