Maschinenidentitäten effizient und souverän im Griff haben

Die Basis muss stimmen

Bei der Sicherheit der digitalen Identitäten ihrer Belegschaft haben die meisten Unternehmen inzwischen einen akzeptablen Stand erreicht, weil sich Multifaktor-Authentifizierung (MFA) und Passkeys in den letzten Jahren durchgesetzt haben. Sie verfügen über einen Mechanismus, der vergleichsweise resistent gegen Phishing und kryptografisch abgesichert ist.

Idealerweise verwaltet ein und dieselbe IAM-Plattform (Identity and Access Management) die digitalen Identitäten von Personal und Maschinen. Der Registrierungs- und Authentifizierungsprozess sieht im Falle von Maschinenidentitäten allerdings grundlegend anders aus. Die Identität entsteht heute in der Regel aus der umgebenden Infrastruktur heraus. In Kubernetes beispielsweise erhält jeder Workload beim Start eine eindeutige, vom Cluster ausgestellte Identität. Diese wird meist in Form eines zertifikatsbasierten Mechanismus oder eines Service-Account-Tokens umgesetzt. Diese Identität ist signiert, kryptografisch prüfbar und eindeutig dem konkreten Prozess zuzuordnen. Die zentrale IAM-Plattform verknüpft diese Infrastruktur-Identität an ein internes Identitätsobjekt, versieht es mit Metadaten wie einer verantwortlichen Person und Zweck, und übernimmt die automatisierte Verwaltung seines Lebenszyklus‘: Erstellen, Rotieren, Erneuern, Widerrufen und Löschen. Die jeweiligen Berechtigungen sind dabei nicht an das Objekt, zum Beispiel. den Container, gekoppelt, sondern vielmehr an die entsprechende Workload.

Ergänzend zu dieser Art Identitäts- und Berechtigungsvergabe sollte die zentrale IAM-Plattform ein Self Service Onboarding ermöglichen. So kann beispielsweise ein Entwickler einen neuen Client oder Workload über eine fest definierte API registrieren. Dieser neue Client existiert daraufhin im System, erhält aber zunächst keine Berechtigungen. Will der Entwickler spezifische Zugriffe gewähren lassen – etwa auf Finanzdaten für eine Abrechnungsanwendung – startet er einen standardisierten Autorisierungs-Workflow. Diese Entkopplung von Registrierung und Autorisierung bietet erhebliche Vorteile: Sensible technische Daten werden nicht mehr per E-Mail versendet, die Konfiguration erfolgt über standardisierte Schnittstellen, und der gesamte Prozess hinterlässt eine Audit-Spur, was der Governance zugutekommt.

Berechtigungskontrolle

Eine wirksame Sicherheitsarchitektur muss klar trennen zwischen verschiedenen Rollen und Berechtigungen. Und das betrifft nicht nur die Identitäten selbst. Ein Sicherheitsadministrator sollte in der Lage sein, festzulegen, dass nur ausgewählte Personen Maschinenidentitäten löschen dürfen. Ein Entwickler könnte hingegen seinen eigenen Client registrieren und konfigurieren dürfen, ohne die Berechtigung, ihn zu löschen. Diese feingliedrige Rollenverteilung ist nicht nur eine Frage der Sicherheit, sondern auch des Vertrauens und der Auditierbarkeit.

Außerdem sollte die IAM-Plattform dokumentieren, wer wann was geändert hat. Bei tausenden von Maschinenidentitäten in großen Organisationen ist es unmöglich, manuell den Überblick zu behalten. Die Plattform muss die Verantwortlichkeiten transparent machen: Wer hat diesen Service angelegt? Wer ist der aktuelle Owner? Wann wurde die Konfiguration zuletzt geändert, und durch wen? Diese Informationen sind essenziell für Compliance und Incident Response.

Den gesamten Lebenszyklus unter Kontrolle

Schon bei einer kleinen Belegschaft kann eine mangelhafte Verwaltung digitaler Identitäten zu großen Sicherheitslücken führen, wenn zum Beispiel einem ausscheidenden Mitarbeiter oder einem ehemaligen Geschäftspartner seine Berechtigungen nicht entzogen werden. Die enorme Anzahl von Maschinenidentitäten in vielen Unternehmen verschärft das Problem des Lifecycle Management um ein Vielfaches.

Deprovisionierung muss automatisiert sein und bedeutet mehr als nur das Löschen eines Eintrags. Es umfasst einen strukturierten Prozess: Zertifikate müssen zurückgezogen, Secrets entwertet und der gesamte Zugriff beendet werden. Ebenso wichtig ist die regelmäßige Überprüfung: Existiert diese Maschinenidentität noch zu Recht? Ist der Owner noch im Unternehmen tätig? Wird der Service tatsächlich noch verwendet? Diese Fragen müssen regelmäßig – idealerweise automatisiert – gestellt werden.

Ein robustes System speichert nicht nur, welche Maschinenidentität existiert, sondern auch: Wer ist verantwortlich? Wann wurde sie zuletzt aktiv verwendet? Wann muss die nächste Überprüfung stattfinden? Auf diese Weise lässt sich verhindern, dass Systeme unbeobachtet laufen und zu latenten Sicherheitsrisiken werden. Ein echter Lebenszyklusmanagement-Prozess bedeutet, dass Provisioning, Maintenance und Deprovisioning alle gleich wichtig sind – nicht als nachgelagerte Gedanken, sondern als integraler Teil der Identitätsverwaltung.

KI-gestützte Anomalieerkennung

Mit der vollständigen Lebenszyklus-Verwaltung ist die Notwendigkeit effizienten Monitorings eng verwoben. Mit tausenden oder zehntausenden Maschinenidentitäten in großen Organisationen wird manuelles Monitoring rasch unmöglich. Zudem sind manuelle Kontrollen fehleranfällig. Deshalb sollte die IAM-Plattform eine flexible Schnittstelle für KI-Modelle enthalten, die ihre Stärken bei der Mustererkennung ausspielen können. KI-basierte Systeme können beispielsweise lernen, wie sich Maschinenidentitäten normalerweise verhalten. Ein Service, der täglich zwischen 9 und 17 Uhr aktiv ist und auf spezifische APIs zugreift, zeigt ein vorhersagbares Muster. Wenn dieser Service plötzlich nachts aktiv wird, auf unerwartete Datenbanken zugreift oder eine ungewöhnliche Menge an Anfragen generiert, kann das System dies als Anomalie erkennen und Alarm schlagen. Solche Muster könnten auf einen Missbrauch hindeuten – etwa, wenn eine Maschinenidentität kompromittiert wurde oder wenn jemand unautorisierte Änderungen vorgenommen hat.

Ein weiteres KI-Anwendungsfeld liegt in der Erkennung von Überprovisionierung (Overprovisioning): Wenn ein Entwickler plötzlich hunderte von Clients registriert oder wenn eine Organisation tausende von Services hat, die vermutlich inaktiv sind, können Algorithmen diese verdächtigen Aktivitäten automatisch erkennen und melden. Dies ermöglicht es den Verantwortlichen, schnell zu reagieren und unnötige oder gefährliche Identitäten zu bereinigen.

Eine solche KI-Funktionalität sollte flexibel konfigurierbar sein. Nicht alle Organisationen haben die gleichen Anforderungen. Beispielsweise könnte ein Finanzdienstleister mit strikten Compliance-Anforderungen aggressive Anomalie-Erkennungsschwellen setzen, während ein Tech-Startup möglicherweise flexiblere Parameter wählt. Die IAM-Plattform sollte es ermöglichen, die KI-Modelle an die organisationsspezifischen Anforderungen anzupassen, ohne dabei in proprietären Lösungen verfangen zu sein. Sorgfalt bei der Wahl der KI-Modelle sollte dabei selbstverständlich sein. Aus regulatorischer Sicht ist vor allem darauf zu achten, dass viele KI-Modelle nicht für die Verarbeitung sensibler Daten geeignet sind. Aus technischer Perspektive ist Modellen der Vorzu zu geben, die domänenspezifisch trainiert wurden und deshalb verlässlichere Ergebnisse liefern als Allzweck-KIs.

„Ein effizientes Management von Maschinenidentitäten ist nicht zuletzt durch die regulatorischen Anforderungen weit oben auf der Cybersecurity-Agenda angelangt. Das Inkrafttreten von NIS2 inklusive persönlicher Haftung von Geschäftsführern für IT-Sicherheitsvorfälle ist eine der treibenden Kräfte hinter dieser Entwicklung.“

Elmar Eperiesi-Beck, Bare.ID

Standards und Open Source

Je größer die Menge der zu verwaltenden Maschinenidentitäten ist, desto wichtiger wird ein weiterer Aspekt: Die Unterstützung wichtiger Standards, die zum Einsatz kommen, um Maschinen zu registrieren. Im Identitätsmanagement spielt beispielsweise OpenID Connect (OIDC) eine zentrale Rolle. Es handelt sich um ein offenes Authentifizierungsprotokoll, das auf OAuth 2.0 aufbaut und Identitäten von Nutzern und Maschinen standardisiert überprüft. Es ermöglicht Single Sign-On (SSO), indem es ID-Token (JSON Web Tokens, JWT) ausstellt, die grundlegende Profilinformationen enthalten.

Tatsächlich scheinen viele Hersteller OIDC zu unterstützen. Schaut man etwas tiefer unter die Motorhaube, zeigt sich allerdings, dass die Umsetzung häufig nicht komplett standardkonform erfolgt und dadurch proprietäre Schnittstellen entstehen. In diesen Fällen erhöht sich der Verwaltungsaufwand beträchtlich, und Unternehmen werden vom jeweiligen Anbieter abhängig, weil sich die IAM-Plattform nur noch mit erheblichem Aufwand ersetzen lässt.

Größtmögliche Unabhängigkeit und digitale Souveränität bietet eine IAM-Plattform auf Open-Source-Basis. Diese erlaubt bei Bedarf nicht nur die vergleichsweise unkomplizierte Migration zu einem anderen Anbieter, sondern die Kontrolle des Quellcodes durch die Community sorgt für ein zusätzliches Maß an Sicherheit.

Ernst machen mit Maschinenidentitäten

Ein effizientes Management von Maschinenidentitäten ist nicht zuletzt durch die regulatorischen Anforderungen weit oben auf der Cybersecurity-Agenda angelangt. Das Inkrafttreten von NIS2 inklusive persönlicher Haftung von Geschäftsführern für IT-Sicherheitsvorfälle ist eine der treibenden Kräfte hinter dieser Entwicklung. Mit einer leistungsfähigen, standardkonformen IAM-Plattform auf Open-Source-Basis lassen sich die regulatorischen Vorgaben glücklicherweise recht einfach erfüllen. Kommt der Anbieter dieser Plattform aus Europa, setzt auf eine vollständig europäische Liefer- beziehungsweise Leistungskette und hostet seine Dienste ausschließlich auf diesem Kontinent, ist zudem für ein Höchstmaß an digitaler Souveränität gesorgt.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.