Konfigurieren Sie die zertifikatlose Authentifizierung mit Microsoft. Identity.Web

In diesem Artikel wird erläutert, wie Sie die zertifikatlose Authentifizierung konfigurieren, damit Ihre Anwendung sich mit Microsoft Entra ID authentifiziert, ohne Zertifikate oder geheime Clientschlüssel zu verwalten. Ihre App verwendet eine Verbundidentitäts-Anmeldeinformation (Federated Identity FIC), die von einer Azure verwalteten Identität unterstützt wird, um Token zu erhalten, wodurch die Drehung von Anmeldeinformationen beseitigt, geheime Sprawl reduziert und Azure Bereitstellungen vereinfacht wird.

Microsoft. Identity.Web unterstützt die zertifikatlose Authentifizierung über den Quelltyp SignedAssertionFromManagedIdentity Anmeldeinformationen, der in Version 2.12.0 und höher verfügbar ist.

Grundlegendes zur zertifikatlosen Authentifizierung

In diesem Abschnitt wird erläutert, wie die zertifikatlose Authentifizierung funktioniert und wann sie verwendet werden soll.

In der Regel beweisen vertrauliche Clientanwendungen ihre Identität gegenüber Microsoft Entra ID, indem sie ein Clientgeheimnis oder ein Zertifikat präsentieren. Beide Ansätze erfordern, dass Sie den Lebenszyklus der Anmeldeinformationen verwalten – Geheimnisse rotieren, bevor sie ablaufen, Zertifikate erneuern und sie sicher speichern.

Verbundidentitätsanmeldeinformationen (Federated Identity Credentials, FIC) ändern dieses Modell. Mit FIC konfigurieren Sie eine Vertrauensstellung zwischen Ihrer App-Registrierung und einer verwalteten Identität. Wenn Ihre Anwendung authentifiziert werden muss:

1. Microsoft. Identity.Web fordert ein Token vom Managed Identity-Endpunkt auf dem Azure-Host an.
2. Die Bibliothek verwendet das Token für verwaltete Identität als signierte Assertion, um sich mit Microsoft Entra ID zu authentifizieren.
3. Microsoft Entra ID überprüft die signierte Assertion anhand der föderierten Berechtigungskonfiguration für die App-Registrierung.
4. Microsoft Entra ID gibt ein Zugriffstoken für die angeforderte Ressource aus.

Das Ergebnis ist eine vollständig anmeldeinformationsfreie Bereitstellung, bei der keine geheimen Schlüssel oder Zertifikate in Ihren Konfigurations-, Code- oder Umgebungsvariablen vorhanden sind.

Auswählen des richtigen Authentifizierungsansatzes

In der folgenden Tabelle können Sie entscheiden, wann die zertifikatlose Authentifizierung die richtige Wahl ist.

Voraussetzungen

Stellen Sie sicher, dass Sie über die folgenden Ressourcen und Tools verfügen, bevor Sie beginnen:

• Ein Azure-Abonnement. Falls Sie nicht über ein Abonnement verfügen, können Sie ein kostenloses Konto erstellen.
• Eine App-Registrierung in Microsoft Entra ID mit den erforderlichen API-Berechtigungen für Ihr Szenario.
• Eine Managed Identity in Azure – entweder systemzugewiesen auf Ihrer Computing-Ressource oder eine eigenständige, vom Benutzer zugewiesene Managed Identity.
• Microsoft. Identity.Web Version 2.12.0 oder höher, die in Ihrem Projekt installiert ist.
• Eine Azure Computeressource, die verwaltete Identität unterstützt, z. B. Azure App Service, Azure Kubernetes Service (AKS), Azure Container Apps oder Azure Virtual Machines.

Schritt 1: Erstellen oder Identifizieren einer verwalteten Identität

Sie können entweder eine vom System zugewiesene oder vom Benutzer zugewiesene verwaltete Identität verwenden. Wenn Sie noch keins erstellt haben, befolgen Sie die Anweisungen für Ihr Szenario.

Option A: Verwenden einer vom System zugewiesenen verwalteten Identität

Vom System zugewiesene verwaltete Identitäten sind an den Lebenszyklus einer Azure Ressource gebunden. Wenn Sie eine vom System zugewiesene Identität für eine Ressource wie einen App-Dienst aktivieren, erstellt Azure automatisch eine Identität.

1. Navigieren Sie im portal Azure zu Ihrer Computeressource (z. B. Ihrem App Service).
2. Wählen Sie im linken Navigationsmenü "Identität" aus.
3. Legen Sie auf der Registerkarte System zugewiesen den Status auf Ein fest.
4. Wählen Sie "Speichern" aus, und bestätigen Sie die Aktion.
5. Kopieren Sie nach dem Erstellen der Identität die Objekt-ID (Prinzipal-ID). Sie benötigen diesen Wert beim Konfigurieren der Verbundanmeldeinformationen.

Option B: Erstellen einer vom Benutzer zugewiesenen verwalteten Identität

Vom Benutzer zugewiesene verwaltete Identitäten sind eigenständige Azure Ressourcen, die Sie einer oder mehreren Computeressourcen zuweisen können.

1. Suchen Sie im portal Azure nach Managed Identities und wählen Sie sie aus.
2. Wählen Sie "Erstellen" aus.
3. Wählen Sie Ihre Abonnement-, Ressourcengruppe, Region aus, und geben Sie einen Namen für die Identität ein.
4. Wählen Sie Überprüfen + Erstellen und dann Erstellen aus.
5. Öffnen Sie nach Abschluss der Bereitstellung die neue Ressource für verwaltete Identitäten.
6. Kopieren Sie die Client-ID von der Seite "Übersicht ". Sie benötigen diesen Wert für Ihre Anwendungskonfiguration.

Schritt 2: Konfigurieren der Anmeldeinformationen für Verbundidentitäten im Azure-Portal

Ein Verbundidentitätsnachweis richtet eine Vertrauensstellung zwischen Ihrer App-Registrierung und der verwalteten Identität ein. Führen Sie die folgenden Schritte aus, um eins zu erstellen:

1. Wechseln Sie im portal Azure zu Microsoft Entra ID>App-Registrierungen.

2. Wählen Sie die App-Registrierung aus, die Ihre Anwendung verwendet.

3. Wählen Sie im linken Navigationsmenü Zertifikate und Geheime Schlüssel aus.

4. Wählen Sie die Registerkarte Verbundanmeldeinformationen aus.

5. Wählen Sie Anmeldeinformationen hinzufügen.

6. Wählen Sie im Szenario "Verbundanmeldeinformationen" die Option " Vom Kunden verwaltete Schlüssel " oder "Anderer Aussteller " aus (die verfügbaren Optionen hängen von Ihrer Portalversion ab).

7. Konfigurieren Sie die folgenden Felder:

   Feld	Wert
   Emittent	https://login.microsoftonline.com/{tenant-id}/v2.0 – Ersetzen Sie {tenant-id} durch Ihre Microsoft Entra Mandanten-ID.
   Subjektbezeichner	Die Objekt-ID (Prinzipal-ID) der verwalteten Identität. Suchen Sie dies für vom System zugewiesene Elemente auf der Seite "Identität" der Ressource. Suchen Sie dies für vom Benutzer zugewiesene Elemente auf der Seite "Übersicht" der verwalteten Identität unter "Prinzipal-ID".
   Name	Ein beschreibender Name, z. B fic-managed-identity-prod. .
   Publikum	api://AzureADTokenExchange (Standardwert).

8. Klicken Sie auf Hinzufügen.

Konfigurieren einer Verbundidentitäts-Anmeldeinformation mit Azure CLI

Erstellen Sie alternativ die Verbundanmeldeinformationen mit dem Azure CLI. Mit dem folgenden Befehl werden Anmeldeinformationen für Ihre App-Registrierung erstellt.

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

Aussteller-URLs nach Azure Dienst

Die Aussteller-URL in den Verbundanmeldeinformationen hängt vom Azure Dienst ab, der Ihre Anwendung hostet:

Format des Subjektbezeichners

Das Format des Subjektbezeichners hängt vom Typ der verwalteten Identität ab.

Vom System zugewiesene verwaltete Identität – Verwenden Sie die Objekt-ID (Prinzipal-ID) auf der Seite " Identität " der Ressource. Dies ist ein GUID-Wert, z. B a1b2c3d4-e5f6-7890-abcd-ef1234567890. .

Vom Benutzer zugewiesene verwaltete Identität – Verwenden Sie die Prinzipal-ID (auch als Objekt-ID bezeichnet) auf der Übersichtsseite der Verwalteten Identitätsressource. Dies ist auch ein GUID-Wert.

Schritt 3: Konfigurieren Der Anwendung

Aktualisieren von appsettings.json

Fügen Sie den ClientCredentials Abschnitt zu Ihrer AzureAd Konfiguration hinzu. Legen Sie SourceType auf SignedAssertionFromManagedIdentity fest:

Für vom Benutzer zugewiesene verwaltete Identität

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Ersetzen Sie die folgenden Platzhalter:

Für vom System zugewiesene verwaltete Identitäten

Wenn Sie eine vom System zugewiesene verwaltete Identität verwenden, lassen Sie die ManagedIdentityClientId Eigenschaft aus. Microsoft. Identity.Web verwendet automatisch die vom System zugewiesene Identität des Hosts:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Registrieren von Diensten in Program.cs

In der Startkonfiguration sind keine speziellen Codeänderungen erforderlich. Der Standard Microsoft. Identity.Web-Registrierungsmethoden lesen den Abschnitt ClientCredentials automatisch.

Im folgenden Beispiel wird die Authentifizierung für eine Web-App registriert, die Benutzer anmeldet und nachgeschaltete APIs aufruft:

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

Im folgenden Beispiel wird die Authentifizierung für eine Web-API registriert, die nachgeschaltete APIs aufruft:

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

Im folgenden Beispiel wird die Authentifizierung für eine Daemonanwendung ohne Benutzerinteraktion registriert:

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft. Identity.Web erkennt den SignedAssertionFromManagedIdentity Quelltyp und verarbeitet den Tokenaustausch transparent.

Vergleichen der vom System zugewiesenen und vom Benutzer zugewiesenen verwalteten Identität

Wählen Sie den Verwalteten Identitätstyp aus, der ihrer Architektur am besten entspricht. In den folgenden Abschnitten werden die Kompromisse beschrieben.

Vom System zugewiesene verwaltete Identität

Eine vom System zugewiesene Identität wird erstellt und automatisch mit der Azure Ressource gelöscht, zu der sie gehört.

Vorteile:

• Es gibt keine separate Ressource, die verwaltet werden soll– der Identitätslebenszyklus entspricht der Computeressource.
• Einfachere Konfiguration für Bereitstellungen mit einer Ressource.
• In der Konfiguration ist kein ManagedIdentityClientId erforderlich.

Überlegungen:

• Sie können die Identität nicht über mehrere Ressourcen hinweg freigeben.
• Wenn Sie die Ressource löschen und neu erstellen, ändert sich die Identität– Sie müssen die Verbundidentitäts-Anmeldeinformationen aktualisieren.

Am besten geeignet für: Bereitstellungen mit einer einzelnen Instanz, bei denen eine Computeressource einer App-Registrierung zugeordnet ist.

Benutzerdefinierte verwaltete Identität

Eine vom Benutzer zugewiesene Identität ist eine eigenständige Azure Ressource mit eigenem Lebenszyklus.

Vorteile:

• Gemeinsame Nutzung einer einzelnen Identität über mehrere Computeressourcen hinweg (z. B. mehrere App Service-Instanzen in verschiedenen Regionen).
• Die Identität wird unabhängig vom Computeressourcenlebenszyklus beibehalten.
• Vorerstellen und vorkonfigurieren, bevor die Rechenressource bereitgestellt wird.

Überlegungen:

• Eine zusätzliche Azure Ressource, die verwaltet werden soll.
• Sie müssen die ManagedIdentityClientId in der Konfiguration angeben.

Am besten geeignet für: Bereitstellungen mit mehreren Instanzen oder Mehreren Regionen, blaugrüne Bereitstellungsmuster und Szenarien, in denen Rechenressourcen häufig neu erstellt werden.

Bereitstellen für Azure Computedienste

Nachdem Sie Ihre Anwendung konfiguriert haben, stellen Sie sie in einem Azure Computedienst bereit, der verwaltete Identität unterstützt.

Azure App Service

1. Aktivieren der verwalteten Identität in Ihrem App-Dienst (siehe Schritt 1).

2. Stellen Sie Ihre Anwendung mithilfe Ihrer bevorzugten Methode (Visual Studio, Azure CLI, GitHub Actions) im App-Dienst bereit.

3. Stellen Sie sicher, dass der AzureAd Abschnitt in Ihrer bereitgestellten Konfiguration den Einstellungen in Schritt 3 entspricht.

4. Wenn Sie eine vom Benutzer zugewiesene verwaltete Identität verwenden, weisen Sie sie dem App-Dienst zu:

   az webapp identity assign \
     --resource-group <resource-group> \
     --name <app-service-name> \
     --identities <managed-identity-resource-id>
   

5. Starten Sie den App Service neu, um die Identitätszuweisung zu übernehmen.

Azure Kubernetes-Dienst (AKS)

Verwenden Sie für AKS die Workload-Identität, um ein Kubernetes-Dienstkonto der verwalteten Identität zuzuordnen. Führen Sie die folgenden Schritte aus:

1. Aktivieren Sie das Workload-Identitätsfeature auf Ihrem AKS-Cluster:

   az aks update \
     --resource-group <resource-group> \
     --name <aks-cluster-name> \
     --enable-oidc-issuer \
     --enable-workload-identity
   

2. Erstellen Sie ein Kubernetes-Dienstkonto, das mit der Client-ID für verwaltete Identität versehen ist:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-app-sa
     namespace: default
     annotations:
       azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"
   

3. Erstellen Sie eine Verbundanmeldeinformation, die den AKS OIDC-Aussteller mit der verwalteten Identität verknüpft.

4. Konfigurieren Sie Ihren Pod für die Verwendung des Dienstkontos:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
     namespace: default
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: my-app-sa
     containers:
       - name: my-app
         image: <your-container-image>
   

5. Stellen Sie den Pod bereit. Der Workload-Identitätswebhook fügt die erforderlichen Umgebungsvariablen für den Endpunkt für verwaltete Identitätstoken ein.

Azure Container Apps

1. Erstellen oder Aktualisieren Ihrer Container-App mit einer verwalteten Identität:

   az containerapp identity assign \
     --resource-group <resource-group> \
     --name <container-app-name> \
     --user-assigned <managed-identity-resource-id>
   

2. Stellen Sie Ihr Containerimage mit der entsprechenden AzureAd Konfiguration bereit.

3. Der Endpunkt für verwaltete Identitätstoken ist automatisch innerhalb des Containers verfügbar.

Migrieren von Zertifikaten zur zertifikatlosen Authentifizierung

Wenn Ihre Anwendung derzeit zertifikatbasierte Authentifizierung verwendet, können Sie mit minimalen Konfigurationsänderungen zur zertifikatlosen Authentifizierung migrieren.

Ausführen der Migrationsschritte

1. Erstellen Sie eine Managed Identity für Ihre Azure-Compute-Ressource (siehe Schritt 1).

2. Fügen Sie Ihrer App-Registrierung Verbundidentitätsanmeldeinformationen hinzu (siehe Schritt 2).

3. Aktualisieren Sie Ihre Konfiguration , um die SignedAssertionFromManagedIdentity Anmeldeinformationen hinzuzufügen. Sie können die vorhandenen Zertifikatanmeldeinformationen während der Migration als Fallback beibehalten:

   {
     "AzureAd": {
       "Instance": "https://login.microsoftonline.com/",
       "TenantId": "YOUR_TENANT_ID",
       "ClientId": "YOUR_CLIENT_ID",
       "ClientCredentials": [
         {
           "SourceType": "SignedAssertionFromManagedIdentity",
           "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
         },
         {
           "SourceType": "KeyVault",
           "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
           "KeyVaultCertificateName": "your-cert-name"
         }
       ]
     }
   }
   

   Microsoft.Identity.Web versucht Anmeldeinformationsquellen der Reihe nach. Wenn sie auf Azure ausgeführt wird, ist die erste Anmeldeinformation (SignedAssertionFromManagedIdentity) erfolgreich. Wenn der Fehler auftritt (z. B. während der lokalen Entwicklung), greift die Bibliothek auf das Zertifikat zurück.

4. Bereitstellen und Überprüfen in einer Stagingumgebung vor der Anwendung auf die Produktion.

5. Entfernen Sie die Zertifikatanmeldeinformationen aus der Konfiguration, nachdem Sie bestätigt haben, dass die zertifikatlose Authentifizierung in der Produktion funktioniert.

6. Delete das Zertifikat aus Azure Key Vault und der App-Registrierung, wenn es nicht mehr benötigt wird.

Vergleichen vor und nach der Konfiguration

Die folgenden Beispiele zeigen die Konfigurationsänderung von zertifikatbasierter zu zertifikatloser Authentifizierung.

Vorher (zertifikatbasiert):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

Nach (zertifikatlos):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Häufige Fehler beheben

Verwenden Sie die folgenden Anleitungen, um Probleme mit der zertifikatlosen Authentifizierung zu diagnostizieren und zu beheben.

AADSTS70021: Es wurden keine übereinstimmenden Verbundidentitätsdatensätze gefunden.

Ursache: Der Subjektbezeichner im Verbundidentitätsnachweis stimmt nicht mit der Objekt-ID der Managed Identity (Prinzipal) überein.

Lösung:

1. Navigieren Sie im Azure-Portal zur Ressource "Verwaltete Identität", und kopieren Sie die Principal-ID (auch als Objekt-ID bezeichnet) von der Seite Overview.
2. Navigieren Sie zu Ihrer App-Registrierung >Zertifikate und Geheimnisse>Verbundanmeldeinformationen.
3. Überprüfen Sie, ob das Feld "Subjektbezeichner" genau mit der Prinzipal-ID übereinstimmt.
4. Wenn die Werte nicht übereinstimmen, löschen Sie die Zugangsdaten und erstellen Sie sie mit dem richtigen Subjektkennzeichen neu.

AADSTS700024: Die Client-Assertion liegt außerhalb ihres gültigen Zeitrahmens

Ursache: Das verwaltete Identitätstoken, das als signierte Assertion verwendet wird, ist abgelaufen, oder die Systemuhr ist schief.

Lösung:

• Überprüfen Sie, ob die Systemuhr auf Ihrer Azure Ressource korrekt ist.
• Starten Sie die Anwendung neu, um eine neue Tokenanforderung für verwaltete Identitäten zu erzwingen.
• Wenn Sie in einem Container arbeiten, gewährleisten Sie, dass die Zeit des Containers mit der des Hosts synchronisiert ist.

ManagedIdentityException: Managed Identity-Endpunkt nicht verfügbar

Cause: Die Anwendung kann nicht den Azure Instanzmetadatendienst (IMDS) oder den Endpunkt für verwaltete Identitätstoken erreichen.

Lösung:

• Vergewissern Sie sich, dass die Anwendung auf einer Azure Computeressource ausgeführt wird, die verwaltete Identität unterstützt.
• Überprüfen Sie, ob die verwaltete Identität aktiviert ist und der Computeressource zugewiesen ist.
• Überprüfen Sie bei AKS, ob der Workload-Identitätswebhook ausgeführt wird und der Pod über die richtige Dienstkontoanmerkung verfügt.
• Für die lokale Entwicklung wird dieser Fehler erwartet. Verwenden Sie eine Fallback-Quelle für Anmeldeinformationen (siehe Migrationsschritte).

AADSTS700016: Anwendung im Verzeichnis nicht gefunden

Ursache: Die ClientId in Ihrer Konfiguration stimmt nicht mit einer gültigen App-Registrierung im angegebenen Mandanten überein.

Lösung:

• Überprüfen Sie, ob ClientId mit der Anwendungs-ID (Client) Ihrer App-Registrierung übereinstimmt.
• Überprüfen Sie, ob TenantId mit dem Mandanten übereinstimmt, bei dem die App registriert ist.

Debugprotokollierung aktivieren

Ursache: Die Reihenfolge oder Konfiguration der Anmeldeinformationen kann dazu führen, dass die Bibliothek die FIC-Anmeldeinformationen überspringt.

Lösung:

1. Aktivieren Sie die Protokollierung in Microsoft. Identity.Web, um detaillierte Tokenakquisitionsschritte anzuzeigen. Der folgende Code konfiguriert die Protokollierung auf Debug-Ebene für die Identitätsbibliotheken.

   builder.Services.AddLogging(logging =>
   {
       logging.AddConsole();
       logging.SetMinimumLevel(LogLevel.Debug);
       logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
   });
   

2. Überprüfen Sie die Protokolle auf Nachrichten darüber, welche Anmeldeinformationsquelle die Bibliothek versucht hat zu verwenden, sowie alle zurückgegebenen Fehler.

Die vom Benutzer zugewiesene verwaltete Identität wurde nicht erkannt.

Ursache: Wenn einer Computeressource mehrere vom Benutzer zugewiesene verwaltete Identitäten zugewiesen werden, verwendet die Bibliothek möglicherweise das falsche, wenn ManagedIdentityClientId nicht angegeben ist.

Lösung:

• Geben Sie immer die ManagedIdentityClientId Eigenschaft an, wenn Sie eine vom Benutzer zugewiesene verwaltete Identität verwenden.
• Überprüfen Sie, ob die Client-ID mit der Identität übereinstimmt, für die Sie die Verbundidentitäts-Anmeldeinformationen konfiguriert haben.

Überprüfen der Sicherheitsvorteile

Zertifikatlose Authentifizierung mit FIC bietet gegenüber herkömmlichen anmeldeinformationsbasierten Ansätzen erhebliche Sicherheitsvorteile:

Keine Geheimnisse zu verraten

Da keine Zertifikatdateien, PFX-Kennwörter oder geheimen Clientschlüssel in Ihren Konfigurations- oder Bereitstellungsartefakten vorhanden sind, gibt es nichts für einen Angreifer zu extrahieren. Auch wenn ein Angreifer Lesezugriff auf Ihre Konfigurationsdateien erhält, kann er die Identität Ihrer Anwendung nicht von außerhalb Azure imitieren.

Kein Wechsel der Anmeldeinformationen

Verwaltete Identitätstoken sind kurzlebig und werden von der Azure-Plattform automatisch aktualisiert. Sie müssen keine Rotationspläne implementieren, Ablaufdaten überwachen oder Anmeldeinformationen über verschiedene Bereitstellungen hinweg koordinieren.

Reduzierte Angriffsfläche

Auf den Endpunkt für verwaltete Identitäten kann nur über die spezifische Azure Ressource zugegriffen werden, der die Identität zugewiesen ist. Ein Angreifer kann die Anmeldeinformationen nicht aus einer anderen Host-, Netzwerk- oder Cloudumgebung verwenden.

Vereinfachung der Compliance

Ohne dauerhafte Anmeldeinformationen beseitigen Sie mehrere Kategorien von Compliance-Bedenken.

• Keine geheimen Schlüssel, die in Quellcodeverwaltungs-, Umgebungsvariablen oder Konfigurationsdateien gespeichert sind.
• Kein Schlüsselmaterial zur Überprüfung, zum Rotieren oder zum Zurückziehen vorhanden.
• Keine Zertifikatsinfrastruktur (Zertifizierungsstelle, Erneuerungsprozesse) zu verwalten.

Defense in Depth

Kombinieren Sie die zertifikatlose Authentifizierung mit anderen Azure Sicherheitsfeatures für mehrschichtigen Schutz:

• Azure RBAC: Steuern, welche Identitäten auf welche Ressourcen zugreifen können.
• Bedingter Zugriff: Anwenden von Richtlinien basierend auf Identitätsrisiko, Standort und Gerätestatus.
• Private-Endpunkte: Einschränken des Netzwerkzugriffs auf Azure Ressourcen.
• Microsoft Defender for Cloud: Überwachen auf verdächtige Authentifizierungsmuster.

Verwandte Inhalte

• Übersicht über Anmeldeinformationen
• Zertifikate
• Geheime Clientschlüssel
• Azure-Dokumentation zu Managed Identities
• Dokumentation zu föderierten Identitätsanmeldeinformationen
• Microsoft. Identity.Web GitHub Repository