Wenn Ausnahmezugänge zum Dauerzustand werden Technische Accounts brauchen die­sel­be Kontrolle wie Benutzerkonten

Anbieter zum Thema

Dynatrace GmbH

cidaas by Widas ID GmbH

Fujitsu Technology Solutions GmbH

FTAPI Software GmbH

Unternehmen investieren in Zero Trust, doch meist nur für menschliche Identitäten. In Cloud-, Hybrid- und DevOps-Umgebungen wuchern tech­ni­sche Accounts, lokale Sonderkonten und nicht-menschliche Identitäten (NHI) unkontrolliert. Weil sie außerhalb etablierter Prozesse entstehen, sind sie ein blinder Fleck für Sicherheit, Compliance und Resilienz.

Wer über moderne IT-Sicherheit spricht, denkt meist an Benutzerkonten, IAM-Rollen und Zugriffsrichtlinien für menschliche Nutzer. Die Aufmerksamkeit richtet sich auf Mitarbeitende, Partner und Administratoren. Doch in vielen Unternehmen verlagert sich die Angriffsfläche längst in einen weniger sichtbaren Bereich: Service-Zugänge, systemnahe Konten und Identitäten für Anwendungen, Skripte, Schnittstellen und Automatisierungsprozesse.

Diese Konten sind nicht neu. Neu sind ihre Anzahl, ihre Verteilung und ihre Bedeutung für den laufenden Betrieb. In cloud-nativen Architekturen entstehen fortlaufend neue Verbindungen zwischen Workloads, Plattformdiensten, APIs, Pipelines und Sicherheitswerkzeugen. Jeder dieser Zugriffe benötigt eine Identität. So entsteht eine Schicht von Zugängen, die oft kritischer ist als viele klassische Benutzerkonten und zugleich deutlich schwerer kontrollierbar bleibt.

Auch maschinelle Identitäten brauchen Schutz!

Sieben Arten nicht-menschlicher Identitäten und wie man sie schützt

Warum technische Identitäten durchs Raster fallen

Mit jeder zusätzlichen Cloud-Plattform, jeder weiteren Automatisierungsstufe und jeder neuen Entwicklungsumgebung steigt die Zahl nicht-menschlicher Identitäten. Service-Accounts verbinden Anwendungen mit Datenbanken, Build-Pipelines kommunizieren mit Repositories, Integrationen tauschen Daten mit Drittplattformen aus, lokale Konten sichern Zugriffe in Sonderfällen. Ohne diese Zugänge funktionieren moderne IT-Prozesse kaum.

Das Problem liegt jedoch nicht nur in der Zahl dieser Konten, sondern in ihrer Entstehungslogik. Viele Unternehmen haben ihre Identity-Strategie in den vergangenen Jahren vor allem auf menschliche Identitäten ausgerichtet. Zentralisierte Identity Provider, Single Sign-on und standardisierte Rollenzuweisungen schaffen Kontrolle für Mitarbeitende, Partner und Administratoren. Technische Identitäten folgen jedoch einer anderen Logik. Sie orientieren sich nicht am Lebenszyklus von Personen, sondern am Lebenszyklus von Anwendungen, Workloads, Integrationen und betrieblichen Sonderfällen.

Genau deshalb entstehen sie häufig dort, wo klassische Identity-Prozesse nur begrenzt greifen: in Deployments, in Projekten, an Schnittstellen oder im Rahmen kurzfristiger betrieblicher Anforderungen. Was zunächst Flexibilität und Geschwindigkeit schafft, führt mit der Zeit zu einer wachsenden Lücke zwischen tatsächlicher Nutzung und wirksamer Governance. Technische Identitäten geraten so leichter aus dem Blick, obwohl sie tief in kritische Prozesse eingebettet sind.

Benutzerkonten im Active Directory härten

Privilegierte AD-Konten mit „Protected Users“ schützen

Wenn Ausnahmezugänge zum Dauerzustand werden

Besonders kritisch wird es dort, wo Sonderfälle nicht mehr als Ausnahme behandelt werden. Lokale Konten bleiben bestehen, weil sie für Notfälle, Sonderrollen oder externe Beteiligte vorgesehen sind. Anwendungen bringen eigene Systemidentitäten mit. Integrationen arbeiten mit langlebigen Secrets oder Tokens, deren ursprünglicher Zweck später oft kaum noch nachvollziehbar ist. Hinzu kommen Testsysteme oder Admin-Zugänge, die für einen konkreten Anlass eingerichtet wurden und danach im Betrieb verbleiben.

Solche Zugänge sind aus Sicht der Fachbereiche oft plausibel. Aus Sicht der Security entsteht daraus jedoch eine strukturelle Schwachstelle. Denn technische Accounts verfügen häufig über weitreichende Rechte. Sie verbinden Systeme, automatisieren Prozesse und stabilisieren Abläufe. Gerade deshalb verfügen sie oft über genau jene Berechtigungen, die im Angriffsfall besonders sensibel sind: Zugriff auf produktive Ressourcen, Konfigurationsrechte, Leserechte für sensible Daten oder die Möglichkeit, weitere Prozesse anzustoßen.

Das eigentliche Risiko liegt in der stillen Dauerverfügbarkeit privilegierter Zugänge. Ein kompromittierter Service-Account bleibt oft länger unentdeckt als ein kompromittiertes Benutzerkonto. Ein lokales Ausnahmekonto fällt seltener in reguläre Reviews. Ein technischer Zugang mit statischem Geheimnis wird weiter genutzt, obwohl niemand seine Legitimation noch aktiv prüft. Gerade weil diese Identitäten im Hintergrund arbeiten, erzeugen sie weniger Aufmerksamkeit und damit geringere Hürden für Angreifer.

Privileged Access Management als Schlüssel zur digitalen Resilienz

Best Practices für eine erfolgreiche PAM-Einführung

Sicherheit, Resilienz und Compliance hängen an demselben Thema

Wer technische Accounts nur als Randnotiz des Identity Managements betrachtet, unterschätzt ihre Wirkung auf die gesamte Sicherheitsarchitektur. In modernen Anwendungen übernehmen sie systemische Funktionen, in Cloud-Umgebungen steuern sie Zugriffe auf Plattformdienste, Konfigurationen und Automatisierungsprozesse. Damit sind sie nicht nur ein Thema der Zugriffsverwaltung, sondern auch der Application Security und der Cloud Security.

Hinzu kommt eine zweite Ebene, die häufig unterschätzt wird: operative Resilienz. Technische Identitäten sichern nicht nur Zugriff, sondern oft auch die Handlungsfähigkeit. Wenn im Störfall unklar ist, welche Konten für welche Prozesse benötigt werden, welche Rechte aktiv sind und wo kritische Abhängigkeiten bestehen, wird aus einer Sicherheitslücke schnell ein Betriebsrisiko. Sichtbarkeit ist deshalb nicht nur für Prävention wichtig, sondern auch für Wiederherstellung, Priorisierung und belastbare Reaktion.

Gerade in regulierten Branchen verschärft sich diese Lage. Wer Sicherheitsvorfälle bewerten, Belastbarkeit sicherstellen und Kontrollen gegenüber Aufsicht und Audit belegen muss, kann sich unsichtbare technische Identitäten nicht leisten. Jede unklare Berechtigung, jeder nicht dokumentierte Ausnahmezugang und jede fehlende Überprüfung schwächt das Kontrollniveau. Das Thema reicht damit weit über klassische Identity-Fragen hinaus und betrifft Sicherheit, Compliance und digitale Belastbarkeit zugleich.

Best Practice versus Realität

Identitätsrisiko Shadow-Admins

Wo Unternehmen jetzt ansetzen sollten

Die zentrale Aufgabe besteht deshalb nicht darin, technische Accounts pauschal stärker einzuschränken, sondern sie systematisch sichtbar und steuerbar zu machen. Der erste Schritt ist Transparenz. Unternehmen müssen nachvollziehen können, welche nicht-menschlichen Identitäten existieren, welchem Zweck sie dienen, welche Systeme sie verbinden, welche Rechte sie besitzen und ob diese Rechte noch erforderlich sind. Ohne diesen Kontext bleibt jede Kontrolle unvollständig.

Ebenso wichtig sind klare Verantwortlichkeiten. Technische Identitäten dürfen nicht anonym im Betrieb weiterlaufen. Jedes Konto, jeder Token und jeder systemnahe Zugang braucht eine fachliche und technische Ownership. Nur dann lässt sich entscheiden, ob ein Zugriff legitim, überdimensioniert oder längst überholt ist. Diese Zuordnung kostet Aufwand, schafft aber die Grundlage, Rechte zu reduzieren, Ausnahmen zu begrenzen und veraltete Zugänge gezielt zu entfernen.

Hinzu kommt die kontinuierliche Überprüfung. In dynamischen IT-Landschaften verändern sich Anwendungen, Zuständigkeiten und Architekturen laufend. Ein Zugang, der heute notwendig ist, kann morgen zu weit reichen oder seinen Zweck verloren haben. Sicherheit entsteht deshalb nicht durch eine einmalige Bereinigung, sondern durch die fortlaufende Bewertung der tatsächlichen Nutzung, der vergebenen Rechte und auffälliger Veränderungen im Systemverhalten.

Wenn Maschinen zu Zielen werden

Hacker hacken nicht mehr, sie loggen sich einfach ein

Technische Accounts gehören damit ins Zentrum moderner Sicherheitsstrategien. Unter­neh­men, die ihre digitale Angriffsfläche realistisch bewerten wollen, müssen nicht-menschliche Identitäten mit derselben Konsequenz behandeln wie privilegierte Benutzer­konten. Denn die nächste kritische Lücke entsteht oft nicht dort, wo ein Angreifer erst eindringen muss, sondern dort, wo ein privilegierter Zugang längst vorhanden ist und niemand mehr genau sagen kann, wofür er noch gebraucht wird.

Über den Autor: Bojan Magusic ist als Director Product Manager bei Dynatrace für die Markt­einführung im Bereich Anwendungssicherheit verantwortlich. Zuvor war er bei Microsoft in verschiedenen Funktionen tätig, unter anderem als Technologieexperte für Fortune-500-Unternehmen. Bojan engagiert sich leidenschaftlich für Cybersicherheit, die Förderung von Frauen in der Tech-Branche und berufliche Weiterentwicklung. Neben verschiedenen Zer­ti­fi­zie­rungen (CISSP, CCSP) hat er Zertifizierungen von INSEAD und der Kellogg School of Management erhalten.

(ID:50920493)