Was ist Workload Identity Federation? Ein vollständiger Leitfaden zur sicheren Maschinenauthentifizierung.

Überlegen Sie einmal, wie sehr sich Entwicklungsumgebungen im Vergleich zu vor einigen Jahren verändert haben. Ihre Anwendungen laufen wahrscheinlich über mehrere Clouds hinweg. CI/CD-Pipelines stellen Code automatisch bereit. KI-Dienste greifen ständig auf APIs, Datenbanken und Cloud-Ressourcen zu.

Viele Maschinenidentitäten basieren jedoch immer noch auf etwas Anfälligem: Geheimnissen, API-Schlüsseln, Dienstkonten und statischen Anmeldeinformationen.

Das Problem ist, dass sie den Anforderungen moderner Infrastrukturen nicht mehr gerecht werden. Statische Anmeldeinformationen lassen sich schwer austauschen. Sie vergrößern die Angriffsfläche, verursachen zusätzlichen Betriebsaufwand und ermöglichen Angreifern bei einem Datenleck den Zugriff auf alle Ressourcen, die mit diesen Anmeldeinformationen erreichbar sind.

Während wir jahrelang die Sicherheit des menschlichen Zugriffs mit Multi-Faktor-Authentifizierung (MFA) und Single Sign-On (SSO)-Lösungen gewährleistet haben , wurden Maschinenidentitäten weitgehend vernachlässigt.

Hier setzt Workload Identity Federation (WIF) an und verändert die Spielregeln. Anstatt Anmeldeinformationen zu speichern, authentifizieren sich Workloads über vertrauenswürdige Identitätsanbieter (IdPs) mithilfe kurzlebiger Token und Standards wie OpenID Connect (OIDC).

Lassen Sie uns aufschlüsseln, wie es funktioniert.

Was ist Workload Identity Federation?

Workload Identity Federation ist ein Authentifizierungsmechanismus, der es Anwendungen, Diensten, Containern, CI/CD-Pipelines, KI-Agenten und Workloads ermöglicht, auf Cloud-Ressourcen zuzugreifen, ohne langfristige Anmeldeinformationen speichern zu müssen.

Anstatt auf einen vorab vereinbarten geheimen Schlüssel zurückzugreifen, basiert eine föderierte Workload-Identität auf Vertrauensbeziehungen zwischen Identitätsanbietern und Cloud-Plattformen.

Wenn eine Arbeitslast auf eine bestimmte Cloud-Ressource zugreifen muss, ruft sie ein Identitätstoken von ihrem vertrauenswürdigen externen Identitätsanbieter (IdP) ab. Dieses Token wird dann an den Ziel-Cloud-Anbieter übermittelt, der die Signatur prüft, die Gültigkeit bestätigt und es gegen ein zeitlich begrenztes Zugriffstoken mit engem Gültigkeitsbereich austauscht. Nach Abschluss des Vorgangs läuft dieses temporäre Token automatisch ab, wodurch die Anzahl langlebiger Anmeldeinformationen, die Angreifer ausnutzen könnten, erheblich reduziert wird.

Einige Hauptmerkmale sind:

• Geheimnislose Authentifizierung: Für die Workloads werden keine gespeicherten Passwörter, API-Schlüssel oder heruntergeladene Dienstkontoschlüsseldateien in Drittanbietertools benötigt.
• OIDC-basierte Vertrauensbeziehungen: Die Authentifizierung basiert ausschließlich auf modernen, kryptografisch signierten Token unter Verwendung von OpenID Connect (OIDC).
• Vorübergehende Zugangsdaten: Die für Ihre Workloads ausgegebenen Tokens sind kurzlebig und verfallen oft innerhalb einer Stunde oder weniger, wodurch das Expositionsrisiko drastisch minimiert wird.
• Keine Stehrechte: Workloads verfügen über keine permanenten, ständig verfügbaren Zugriffspfade; der Zugriff wird dynamisch zur Laufzeit gewährt.
• Multi-Cloud-Unterstützung: Es fungiert als plattformübergreifende Brücke und ermöglicht eine nahtlose Identitätsprüfung über AWS, Azure, Google Cloud und lokale Cluster hinweg.

Warum herkömmliche Servicekonten nicht mehr ausreichen

Lange Zeit war es üblich, ein Dienstkonto in der Cloud-Umgebung zu erstellen, dessen privaten Schlüssel als JSON- oder YAML-Datei zu exportieren und ihn in die Anwendungsumgebungsvariablen einzufügen. Während dies bei einfachen Architekturen gut funktionierte, hat es sich in der heutigen Cloud-nativen Landschaft als Nachteil erwiesen.

Heutzutage sind Anwendungen verteilt und Pipelines automatisiert. Container erscheinen und verschwinden ständig.

Herausforderungen bei statischen Anmeldeinformationen

Bei der Nutzung traditioneller Servicekonten befindet man sich in einem ständigen Kreislauf der Verwaltung langjähriger Geheimnisse:

API-Schlüssel: Statische Zeichenketten, die sofortigen Zugriff auf Softwareplattformen gewähren und sich nach ihrer Erstellung nur selten ändern.

Dienstkontoschlüssel: Kryptografische Dateien, die von Cloud-Konsolen heruntergeladen werden und die uneingeschränkten administrativen oder eingeschränkten programmatischen Zugriff auf unbestimmte Zeit gewähren.

Zugriffstoken: Langlebige Anmeldeinformationen oder unsachgemäß verlängerte Token, die verwendet werden, um den Aufwand für die erneute Authentifizierung zu reduzieren.

Wo Sicherheitsbedenken entstehen

Diese statischen Anmeldeinformationen können sofort Sicherheitslücken verursachen:

Offenlegung von Zugangsdaten: Geheimnisse können unbeabsichtigt in die öffentliche Quellcodeverwaltung gelangen, in Build-Protokollen ausgegeben oder in unsicheren Build-Runnern zwischengespeichert werden.

Ungekannte Infrastruktur: Mit der Erweiterung Ihrer Infrastruktur wird es zunehmend schwieriger, genau nachzuverfolgen, wo jeder einzelne Service-Account-Schlüssel auf Hunderten von Repositories und Servern gespeichert ist.

Belastungen durch manuelle Tastenrotation: Da die manuelle Drehung einer Taste die Aktualisierung mehrerer abhängiger Anwendungen erfordert, führt menschliches Versagen häufig zu unerwarteten Systemausfallzeiten.

Rechteausweitung: Wenn ein Angreifer einen langlebigen Dienstkontoschlüssel mit übermäßig weitreichenden Berechtigungen kompromittiert, erlangt er dauerhaften, unentdeckten lateralen Zugriff auf Ihre Infrastruktur.

Was das für Sie bedeutet

Dies ist nicht nur eine theoretische Sorge. Laut den Untersuchungen von Verizon zu Datenschutzverletzungen im Jahr 2025 bleibt der Missbrauch von Zugangsdaten der häufigste Angriffsvektor. Hinzu kommt, dass Maschinenidentitäten die menschlichen Identitäten um das 144-Fache übertreffen.

Angreifer wissen, dass menschliche Konten durch Multi-Faktor-Authentifizierung (MFA) stark geschützt sind. Sie suchen gezielt nach den unüberwachten, langlebigen Service-Account-Schlüsseln, die sich in Codebasen und CI/CD-Pipelines verbergen, um herkömmliche Sicherheitsvorkehrungen zu umgehen. Deshalb betreffen viele Cloud-Vorfälle heutzutage Anmeldeinformationen von Maschinen und nicht Benutzerkonten.

So funktioniert die Workload-Identitätsföderation

Nachdem Sie nun den Grund kennen, schauen wir uns an, was genau dahinter steckt. Wie genau kann ein externer Dienst seine Identität nachweisen, ohne ein Passwort einzugeben oder ein geheimes Token zu übermitteln?

Schrittweiser Authentifizierungsablauf

Schritt 1:

Die Workload fordert ein Identitätstoken von ihrem vertrauenswürdigen Identitätsanbieter an.

Schritt 2:

Der Identitätsanbieter stellt ein signiertes OIDC-Token aus.

Dieses Token enthält üblicherweise Ansprüche wie:

• Emittent (iss)
• Betreff (Sub)
• Publikum (aud)
• Repository-Informationen
• Pipeline-Kontext
• Workload-Metadaten

Schritt 3:

Der Cloud-Anbieter bestätigt:

• Aussteller
• Publikum
• Signature
• Schadenregulierung

Wenn die Validierung erfolgreich ist, wird der Arbeitslast vertraut.

Schritt 4:

Statt dauerhafter Zugangsdaten stellt die Plattform temporäre Zugangsdaten aus, die automatisch ablaufen.

Schritt 5:

Die Arbeitslast greift mit den temporären Anmeldeinformationen sicher auf Cloud-Ressourcen zu. Das Token läuft nach Ablauf der konfigurierten Gültigkeitsdauer automatisch ab.

Workload Identity Federation und OIDC

Man kann nicht über Maschinenidentität sprechen, ohne OIDC zu erwähnen. Die gesamte Architektur basiert auf der Integration von Workload Identity Federation und OIDC, um Vertrauen zu gewährleisten.

Was ist OIDC?

OIDC ist eine Identitätsschicht, die auf OAuth 2.0 aufbaut.

Während OAuth 2.0 die Autorisierung übernimmt, führt OIDC die standardisierte Authentifizierung mit JSON Web Tokens (JWTs) ein. Diese signierten Tokens enthalten Identitätsansprüche und Metadaten, die es entfernten Systemen ermöglichen, Zusicherungen zu überprüfen.

Warum OIDC in WIF verwendet wird

Die Integration der Workload-Identitätsföderation mit OpenID Connect löst mehrere Herausforderungen, die traditionelle Anmeldeinformationsmodelle mit sich bringen:

• Standardisiert

OIDC ist weit verbreitet in IAM Anbieter und Cloud-Anbieter.

• und geschützt

Die Token sind durch Public/Private-Key-Kryptographie geschützt.

• Token-basiert

Kein Austausch gemeinsamer Geheimnisse erforderlich.

• Vielfältig unterstützt

Nahezu jedes wichtige Entwicklertool, CI/CD-Dienstprogramm und jede Infrastrukturumgebung unterstützt OIDC nativ.

• Eliminiert gemeinsame Geheimnisse

Es gibt keine gemeinsamen Passwörter, die gestohlen werden könnten.

Häufige OIDC-Anbieter

Es stehen verschiedene native OIDC-Anbieter zur Verfügung, die Workload-Identitäten direkt gegenüber Cloud-Ressourcen bestätigen können:

• GitHub-Aktionen
• Azure-DevOps
• Cumolocity
• Kubernetes
• Okta
• Entra-ID
• Gitlab

Erklärung der direkten Workload-Identitätsföderation

Mit der Weiterentwicklung der Identitätsarchitektur haben Cloud-Anbieter einen optimierten Ansatz eingeführt, der als Direct Workload Identity Federation bekannt ist.

In einem traditionellen Modell authentifizieren sich Workloads häufig über einen zwischengeschalteten Cloud-nativen Dienstkontoschlüssel. Cloud-Anbieter können diesen Zwischenschritt durch direkte Workload-Identitätsföderation eliminieren. Externe Identitätstoken werden direkt innerhalb der Ziel-Cloud als vertrauenswürdig eingestuft. Identitäts- und Zugriffsmanagement (IAM) Rahmen.

Vorteile der direkten Workload-Identitätsföderation

• Reduzierte Komplexität

Es ist nicht erforderlich, zusätzliche Servicekonten in Ihrer Cloud-Konsole zu verwalten, nur um die Föderation zu unterstützen.

• Bessere Sicherheit

Die Belichtungsfläche wird drastisch reduziert, da keine dauerhaften Artefakte durch Anmeldeinformationen vorhanden sind.

• Schnellere Authentifizierung

Ein kürzerer Authentifizierungspfad reduziert den operativen Aufwand.

• Keine Schlüsselverwaltung

Es gibt keinen Schlüsselgenerierungs- oder Rotationsplan.

Workload Identity Federation vs. Service Principal

Bei der Bewertung Ihrer Sicherheitsarchitektur werden Sie möglicherweise eine Workload-Identitätsföderation mit einer Dienstprinzipalkonfiguration vergleichen. Obwohl beide programmatischen Zugriff auf Anwendungskomponenten ermöglichen, unterscheiden sich ihre zugrunde liegenden Ausführungsmodelle grundlegend.

Workforce Identity Federation vs. Workload Identity Federation

Es kommt häufig vor, dass Teams die Begriffe „Arbeitskräfteföderation“ und „Arbeitslastföderation“ verwechseln. Obwohl sie fast identisch klingen, dienen sie zwei völlig unterschiedlichen Bereichen. IAM.

Hier ein Beispiel zur Verdeutlichung des Unterschieds:

Bei der Identitätsföderation für Mitarbeiter meldet sich ein Mitarbeiter mit seiner Microsoft Entra ID bei AWS an. Bei der Workload-Föderation greift eine GitHub-Pipeline ohne gespeicherte Anmeldeinformationen auf AWS zu.

Häufige Anwendungsfälle für die Identitätsföderation von Arbeitslasten

Lassen Sie uns untersuchen, wie WIF seinen Nutzen im täglichen Entwicklungsbetrieb unter Beweis stellt. Hier sind vier wichtige Anwendungsfälle in der Architektur.

1. CI/CD-Pipelines

CI/CD-Systeme benötigen ständigen Cloud-Zugriff. Traditionell wurde dies durch gespeicherte Geheimnisse gelöst. Heute nutzen Teams jedoch Federation, um Software dynamisch bereitzustellen, ohne langlebige Cloud-Schlüssel in ihren Code-Repositories zu speichern.

Gängige Plattformen sind:

• GitHub-Aktionen: Nutzen Sie OIDC, um Build-Artefakte direkt in die Cloud-Infrastruktur zu übertragen.
• Azure DevOps: Nutzen Sie eine Azure DevOps-Konfiguration für föderierte Workload-Identitäten, um mehrstufige Release-Pipelines sicher und direkt mit Ihren Ziel-Multi-Cloud-Umgebungen zu verbinden.
• GitLab CI/CD: Verwenden Sie kurzlebige Runner, die sich dynamisch authentifizieren, um die Architektur mithilfe von Code-Engines bereitzustellen.

2. Multi-Cloud-Authentifizierung

Wenn Sie Anwendungen über mehrere Clouds hinweg betreiben, kann die Verwaltung von Anmeldeinformationen über verschiedene Anbieter hinweg schnell sehr aufwendig werden.

Die föderierte Authentifizierung vereinfacht die Cloud-übergreifende Vertrauensstellung. Sie ermöglicht es einer Anwendung, die nativ in einer Cloud gehostet wird, in einer anderen Cloud als vertrauenswürdige Entität zu agieren. Sie können sich über AWS, Azure und die Google Cloud Platform hinweg authentifizieren, ohne mehrere Geheimnisse verwalten zu müssen.

3. Kubernetes-Workloads

Container sind sehr dynamisch, und das Einbetten von Anmeldeinformationen in Pods birgt Risiken. Durch die Verwendung von WIF ermöglichen Sie Ihren Kubernetes-Pods die sichere Interaktion mit Datenbanken, Speichern und APIs, ohne statische Anmeldeinformationen einzubetten.

4. Arbeitsbelastung im Bereich KI und LLM

Dies ist ein aufkommender Anwendungsfall, da wir verstärkt auf autonome künstliche Intelligenz und den Einsatz großer Sprachmodelle (LLM) setzen. Diese Systeme sind größtenteils von externen APIs und Cloud-Ressourcen abhängig. Die Workload-Identitätsföderation gewährleistet die sichere Authentifizierung dieser intelligenten, agentenbasierten Systeme, ohne dass Entwickler statische Anmeldeinformationen fest codieren müssen.

Vorteile der Workload-Identitätsföderation

Die Migration von einer altmodischen, auf Geheimnissen basierenden Architektur zu einem föderierten Modell ist sowohl aus Sicherheits- als auch aus Betriebssicht eine kluge Wahl.

Sicherheitsvorteile

• Langjährige Geheimnisse beseitigen

Sie eliminieren vollständig das operationelle Risiko, dass Anmeldeinformationen statisch im Quellcode der Anwendung, in Produktionscontainern oder in Bereitstellungspipelines gespeichert sind.

• Reduzierte Angriffsfläche

Ihr Risikoprofil ändert sich vollständig. Angreifer können keine Zugangsdaten stehlen, die nicht existieren.

• Bessere Compliance

Die Workload-Federation gleicht Ihre Architektur standardmäßig mit strengen Sicherheitsrahmenwerken wie SOC 2, ISO 27001 und HIPAA ab.

Operative Vorteile

• Einfachere Verwaltung von Anmeldeinformationen

Die Verwaltung der Zugangsdaten ist unkompliziert, da diese nicht regelmäßig ausgetauscht, ihr Ablaufdatum nicht überwacht und keine sicheren, geheimen Verteilungskanäle eingerichtet werden müssen.

• Verbesserte Entwicklerproduktivität

Entwickler können sich voll und ganz auf das Schreiben von Funktionscode konzentrieren, anstatt sich Gedanken über die Konfiguration von Tresoren, das Abrufen von Zugriffszeichenfolgen oder die Behebung von Fehlern in Builds aufgrund abgelaufener API-Schlüssel machen zu müssen.

Unterstützte Identitätsanbieter und Plattformen

Einer der größten Vorteile der Workload Identity Federation ist ihre tiefe Integration in moderne Plattformen. Sie wird breit unterstützt und ihre Verbreitung wird stetig ausgebaut.

Identitätsanbieter

• Microsoft Entra-ID
• Okta
• Auth0
• GitHub-Aktionen
• Azure-DevOps
• Gitlab

Cloud-Anbieter

• AWS
• Azure
• Google Cloud Platform
• Schneeflocke
• HashiCorp Cloud-Plattform

Dies deutet darauf hin, dass die föderierte Maschinenauthentifizierung immer mehr zum Standard wird.

Best Practices für die Workload-Identitätsföderation

Die Umstellung auf Föderation verbessert zwar Ihre Sicherheitslage erheblich, ist aber kein Allheilmittel. Sie müssen Ihre Vertrauensbeziehungen weiterhin sorgfältig konfigurieren, um die Sicherheit Ihrer Systeme zu gewährleisten.

1. Kurzlebige Token verwenden

Um das potenzielle Sicherheitsrisiko zu minimieren, sollten Token-Lebensdauern so kurz wie möglich gehalten werden. Idealerweise sollten sie auf das exakte Ausführungsfenster beschränkt werden, das Ihre Arbeitslast erfordert.

2. Prinzip der minimalen Berechtigungen anwenden

Gewähren Sie Ihren föderierten Identitäten keinen vollständigen Zugriff auf Ihre gesamte Cloud-Umgebung. Beschränken Sie die Berechtigungen strikt auf die spezifischen Ressourcen und Vorgänge, die für die jeweilige Aufgabe erforderlich sind.

3. OIDC-Ansprüche prüfen

Stellen Sie sicher, dass Ihr Cloud-Anbieter spezifische Angaben wie den genauen Aussteller, die eindeutige Zielgruppenbezeichnung und das spezifische Betrefffeld überprüft.

4. Überwachung der Aktivitäten des Verbandes

Token-Austausche kontinuierlich verfolgen, fehlgeschlagene Authentifizierungsanfragen protokollieren und den Ressourcenzugriff nach dem Austausch prüfen.

5. Aktivieren Sie bedingte Zugriffsrichtlinien

Erhöhen Sie die Sicherheit Ihrer Arbeitslast weiter, indem Sie kontextbezogene Kontrollen und Richtlinienbeschränkungen anwenden, sofern Ihre Plattform dies unterstützt.

Zukunft der Workload-Identitätsföderation

Mit Blick auf die Zukunft lassen sich mehrere Trends erkennen, die die Verbreitung von WIF fördern. Die Branche bewegt sich stetig in Richtung passwortloser und geheimnisloser Authentifizierungsmodelle.

1. Zero-Trust-Sicherheit

Unternehmen erkennen, dass Perimetersicherheit allein nicht mehr ausreicht. Sie setzen auf Zero-Trust-Sicherheit, und die föderierte Maschinenauthentifizierung treibt diese Entwicklung naturgemäß voran.

2. Cloud-native Architekturen

Die schiere Anzahl serverloser Plattformen und Container macht die Verwaltung statischer Schlüssel in großem Umfang nahezu unmöglich. Sie unterstützen kurzlebige Identitätsmodelle.

3. Sicherheit von KI-Agenten

Da KI-Agenten zunehmend autonom agieren und die Verarbeitung realer Daten übernehmen, benötigen sie sichere Maschinenidentitäten. Deren Absicherung durch verifizierbare Vertrauenspfade wird daher immer wichtiger.

4. Maschinenidentitätsmanagement (MIM)

Organisationen wünschen sich eine zentralisierte Steuerung nicht-menschlicher Identitäten . Die Föderation unterstützt diese Richtung.

5. Passwortlose Infrastruktur

Unternehmen stufen Maschinenidentitäten auf dieselbe Verwaltungsebene wie menschliche Konten ein. Das bedeutet, dass wir uns von statischen Anmeldeinformationen verabschieden müssen. Die Identitätsföderation von Arbeitslasten ist Teil dieses Übergangs.

Wie miniOrange zur Sicherung von Workload-Identitäten beiträgt

Die Verwaltung fragmentierter Maschinenidentitäten über mehrere Clouds hinweg kann mit wachsender Infrastruktur schnell zur Herausforderung werden. In einem modernen, Cloud-nativen Ökosystem lassen sie sich mit veralteten Tools nicht schützen. Hier kommt miniOrange ins Spiel.

miniOrange bietet Ihnen eine Reihe von Dienstleistungen und Produkten, die die Lücke zwischen menschlicher und maschineller Identität schließen.

Verbundauthentifizierung

Ermöglichen Sie die föderierte Authentifizierung über Anwendungen, Workloads und Identitätssysteme hinweg. Wir unterstützen die gängigen Protokolle, einschließlich SAML und OAuth/OIDC.

OIDC-Anbieterunterstützung

Optimieren Sie Ihre Token-Austauschprozesse. Geben Sie Ihrem Team eine standardisierte, passwortlose Methode zur Maschinenauthentifizierung in Ihrer gesamten IT-Infrastruktur.

Identitätslebenszyklus-Management

Automatisieren Sie den gesamten Lebenszyklus Ihrer Serviceprofile und Maschinenkonten. Stellen Sie Maschinenidentitäten automatisch bereit, überwachen und deaktivieren Sie sie, wodurch das Risiko verwaister Anmeldeinformationen eliminiert wird.

Zentralisierte Zugangskontrolle

Verwalten Sie Anwendungsberechtigungen und setzen Sie detaillierte Zugriffsrichtlinien konsistent über ein einziges Dashboard durch.

Zero Trust IAM

Zero Trust folgt dem Prinzip „Vertrauen ist gut, Kontrolle ist besser“. Wir unterstützen dies durch kontinuierliche Authentifizierung und kontextbezogene Sicherheitsrichtlinien bei jedem einzelnen Datenaustausch zwischen Maschinen.

Maschinenidentitätsverwaltung

Stellen Sie sicher, dass alle Ihre nicht-menschlichen Identitäten (NHIs) durch klare Eigentumsverhältnisse, detaillierte rollenbasierte Berechtigungen, kontinuierliche Aktivitätsüberwachung und automatisierte Anmeldeinformationsrotation geschützt sind.

Häufig gestellte Fragen

Was ist Workload Identity Federation?

Workload Identity Federation ist ein Maschinenauthentifizierungsmodell, das Anwendungen, automatisierten Pipelines, Containern und Diensten den sicheren Zugriff auf Cloud-Ressourcen ermöglicht, indem externe Identitätstoken (wie OIDC-Assertions) gegen kurzlebige Cloud-Anmeldeinformationen ausgetauscht werden. Dadurch entfällt die Notwendigkeit gespeicherter, langlebiger Zugriffsschlüssel oder Passwörter vollständig.

Wie funktioniert die Identitätsföderation von Arbeitslasten?

Die Workload-Identitätsföderation funktioniert über einen programmatischen Vertrauensaustausch: Ein Workload fordert ein Identitätstoken von seinem eigenen lokalen Identitätsanbieter an, übergibt dieses signierte Token an einen Ziel-Cloud-Anbieter, der die kryptografische Signatur und die Token-Ansprüche validiert und im Gegenzug ein kurzlebiges Zugriffstoken für die sichere Ressourcennutzung ausstellt.

Ist die Identitätsföderation von Arbeitslasten sicherer als Dienstprinzipale?

Ja, es ist deutlich sicherer. Während herkömmliche Dienstprinzipale auf statischen Clientgeheimnissen oder Zertifikaten basieren, die durchgesickert oder gestohlen werden können, verwendet die Workload-Identitätsföderation kurzlebige, dynamisch ausgetauschte Anmeldeinformationen und hinterlässt keine persistenten Geheimnisse, die ausgenutzt werden könnten.

Was ist Workload Identity Federation (OIDC)?

Dies bezieht sich auf die Nutzung des OpenID Connect (OIDC)-Protokollstandards zur Steuerung der Föderationsarchitektur. OIDC verwendet kryptografisch signierte JSON Web Tokens (JWTs), um Identitätsnachweise von Maschinen sicher zwischen unabhängigen Infrastrukturumgebungen zu übertragen, ohne sensible Masterpasswörter oder gemeinsame Schlüssel weiterzugeben.

Worin besteht der Unterschied zwischen einer Föderation der Mitarbeiteridentitäten und einer Föderation der Arbeitslastidentitäten?

Die Identitätsföderation für Mitarbeiter konzentriert sich ausschließlich auf menschliche Benutzer und ermöglicht es Mitarbeitern, sich über unternehmensweites Single Sign-On (SSO) in ihre Cloud-Management-Portale einzuloggen. Die Identitätsföderation für Arbeitslasten hingegen fokussiert sich ausschließlich auf die Interaktion zwischen Maschinen und ermöglicht Anwendungen, CI/CD-Tools und Software-Skripten den sicheren Zugriff auf Backend-Cloud-APIs.

Kann Azure DevOps die Workload-Identitätsföderation nutzen?

Ja, absolut. Azure DevOps unterstützt die Workload-Identitätsföderation vollständig, sodass Sie native Dienstverbindungen konfigurieren können, die direkt mit Cloud-Anbietern über sichere, kurzlebige OIDC-Token kommunizieren, anstatt sich auf permanente geheime Schlüssel zu verlassen, die in Ihre Build-Pipelines eingebettet sind.

Unterstützt die Workload-Identitätsföderation KI-Agenten?

Ja, es handelt sich um ein ideales Sicherheitsmodell für autonome KI-Agenten, LLM-Integrationen und automatisierte Betriebsabläufe. Es ermöglicht diesen modernen Systemen die sichere Verbindung zu Cloud-APIs, Datenspeichern und externen Ressourcen mithilfe föderierter Identitäten und verhindert so das Ausspähen von Anmeldeinformationen innerhalb der KI-Codebasis.