Build, Buy oder Partner: die Rechnung davor
Eva Mickler
7 Min. Lesezeit Die teuerste Build-vs-Buy-Entscheidung ist die, die niemand bewusst getroffen hat. In ...
Zum Beitrag
8 Min. Lesezeit
Zero Trust steht auf jeder Sicherheitsfolie, doch die Umsetzung scheitert selten an der Technik. Sie scheitert daran, dass kaum jemand weiß, wer im Unternehmen welchen Zugriff für welchen Arbeitsschritt wirklich braucht. Least Privilege lässt sich nicht raten, es setzt voraus, dass die tatsächlichen Prozesse bekannt sind. Genau diese Lücke schließt Process-Mining, und ohne sie bleibt jede Zero-Trust-Architektur ein Versprechen ohne Fundament.
Das Wichtigste in Kürze
- Least Privilege braucht Prozesswissen. Wer Rechte vergibt, ohne die realen Abläufe zu kennen, vergibt zu viel oder bricht die Arbeit. Beides untergräbt Zero Trust.
- Über-Berechtigung ist die Regel, nicht die Ausnahme. Ein verschwindend kleiner Teil der vergebenen Zugriffe wird tatsächlich genutzt. Der Rest ist offene Angriffsfläche.
- Process-Mining macht Rechte überprüfbar. Wer die echten Datenflüsse sichtbar macht, kann Zugriffe an Prozessen ausrichten statt an Vermutungen.
Verwandt:Agentic AI ohne Halter: Wer haftet/Cloud-Souveränität wird Vorstandssache
Warum Zero Trust an der Praxis hängenbleibt
Das Prinzip ist bestechend einfach: niemandem trauen, jeden Zugriff prüfen, nur so viel Recht vergeben, wie eine Aufgabe verlangt. In der Theorie schließt das die meisten Einfallstore. In der Praxis aber stößt die Idee auf eine unbequeme Frage, die selten sauber beantwortet wird. Was genau braucht eine Rolle, eine Anwendung oder ein Dienstkonto wirklich, um seine Arbeit zu tun?
Ohne belastbare Antwort entstehen zwei Fehler. Entweder werden Rechte großzügig vergeben, damit nichts hakt, dann ist Least Privilege nur ein Etikett. Oder die Rechte werden eng gesetzt, ohne die echten Abläufe zu kennen, dann bricht plötzlich ein Prozess, den niemand auf dem Schirm hatte. Beide Wege enden dort, wo Zero Trust eigentlich verhindern sollte: bei zu viel Zugriff oder bei umgangenen Kontrollen.
Was ist Least Privilege? Least Privilege bedeutet, jeder Identität nur die minimalen Rechte zu geben, die sie für ihre konkrete Aufgabe braucht. Ziel ist, den Schaden zu begrenzen, falls ein Konto kompromittiert wird. Das Prinzip steht und fällt mit der Frage, was die Aufgabe tatsächlich erfordert.
2,6 %
der einer Workload-Identität gewährten Berechtigungen werden im Schnitt tatsächlich genutzt. Der große Rest ist ungenutzte Angriffsfläche.
Quelle: Branchenanalyse zu Cloud-Identitäten 2026
Über-Berechtigung ist der Normalzustand
Die Zahl ist kein Ausreißer, sie beschreibt einen Dauerzustand. Über die Jahre sammeln Mitarbeitende Zugriffe an, die sie längst nicht mehr brauchen, Dienstkonten wachsen still in ihren Rechten, und Altanwendungen verlangen weite Berechtigungen, nur um überhaupt zu laufen. Branchenübergreifend gilt fehlerhafte Zugriffskontrolle als das verbreitetste Sicherheitsrisiko überhaupt, mit Befunden in der überwiegenden Mehrheit geprüfter Anwendungen.
Verschärft wird die Lage durch KI-Agenten. Sie verhalten sich nicht wie feste Anwendungen oder einzelne Nutzer, sondern verfolgen ein Ziel über mehrere Systeme hinweg, verketten Werkzeuge und versuchen Schritte erneut. Wer einem solchen Agenten pauschal weite Rechte gibt, vervielfacht das Problem der stehenden Privilegien. Auch hier hilft nur, den Prozess zu kennen, den der Agent abbilden soll.
Was Process-Mining für die Sicherheit leistet
Process-Mining rekonstruiert aus den Protokollen der Systeme, wie Arbeit tatsächlich abläuft, nicht wie sie laut Handbuch ablaufen sollte. Es zeigt, welche Rolle auf welches System zugreift, in welcher Reihenfolge, an welcher Stelle es Umwege und Sonderpfade gibt. Genau diese Sicht fehlt den meisten Zugriffsmodellen, die auf Annahmen und Organigrammen beruhen.
Rechte ohne Prozesswissen
- Vergabe nach Organigramm statt nach echtem Bedarf
- Stehende Privilegien, die niemand zurücknimmt
- Enge Regeln brechen unbekannte Sonderpfade
Rechte auf Prozessbasis
- Zugriffe an realen Datenflüssen ausgerichtet
- Ungenutzte Rechte werden sichtbar und entzogen
- Ausnahmen sind bekannt statt überraschend
Für die Führungsebene verschiebt das die Reihenfolge der Investitionen. Bevor eine weitere Zero-Trust-Komponente eingekauft wird, lohnt die Frage, ob die eigenen Prozesse überhaupt sichtbar sind. Eine Zugriffsstrategie, die auf gemessenen Abläufen beruht, lässt sich begründen, prüfen und im Audit verteidigen. Eine, die auf Annahmen steht, erzeugt vor allem das gute Gefühl, etwas getan zu haben.
Häufige Fragen
Warum reicht ein Rollenkonzept nicht für Least Privilege?
Weil Rollen aus Organigrammen stammen, nicht aus den echten Abläufen. Eine Rolle bündelt oft Rechte für viele Tätigkeiten, von denen eine konkrete Person nur einen Teil braucht. Erst der Blick auf den tatsächlichen Prozess zeigt, was wirklich nötig ist.
Was hat Process-Mining mit Cybersicherheit zu tun?
Es liefert die Faktenbasis für Zugriffsentscheidungen. Process-Mining rekonstruiert aus Systemprotokollen, wer wann auf welches System zugreift. Diese Sicht macht über-berechtigte Konten und ungenutzte Rechte sichtbar, die ein Zero-Trust-Modell sonst übersieht.
Verschärfen KI-Agenten das Problem der Berechtigungen?
Ja. KI-Agenten verfolgen Ziele über mehrere Systeme, verketten Werkzeuge und wiederholen Schritte. Pauschal weite Rechte machen sie zu einem beweglichen Risiko. Auch hier braucht es das Prozesswissen, um zu begrenzen, worauf ein Agent zugreifen darf.
Womit sollte ein Zero-Trust-Programm beginnen?
Mit Sichtbarkeit, nicht mit dem nächsten Werkzeug. Wer zuerst die realen Prozesse und Zugriffe misst, kann Rechte begründet setzen. Erst auf dieser Grundlage zahlen weitere Zero-Trust-Bausteine wirklich ein.
Wie überzeugt man den Vorstand von dieser Reihenfolge?
Mit der Prüfbarkeit. Eine Zugriffsstrategie auf Basis gemessener Abläufe lässt sich im Audit belegen und gegenüber Aufsicht und Versicherern begründen. Das ist ein härteres Argument als die bloße Anschaffung weiterer Sicherheitstechnik.
Mehr aus dem MBF Media Netzwerk
cloudmagazinCloud-native reift: Was Knative und Kubernetes 1.34 für KI-Workloads bedeuten mybusinessfutureDer KI-Engpass im Mittelstand sitzt in den Altsystemen securitytodayNIS2 ist in der Vollstreckung: Erste Verfahren, persönliche HaftungBildquelle: KI-generiert (Juni 2026)