Auswirkungen der mehrstufigen Authentifizierung auf Azure PowerShell in Automatisierungsszenarien

In diesem Artikel wird erläutert, wie sich die mehrstufige Authentifizierung (MFA) auf Automatisierungsaufgaben auswirkt, die Microsoft Entra Benutzeridentitäten verwenden und Anleitungen zu alternativen Ansätzen für die unterbrechungsfreie Automatisierung bieten.

Important

Die Aktion ist erforderlich, wenn Sie Microsoft Entra Benutzeridentitäten für die Automatisierung verwenden.

MFA-Anforderungen verhindern, dass Sie Microsoft Entra Benutzeridentitäten für die Authentifizierung in Automatisierungsszenarien verwenden. Organisationen müssen zu Authentifizierungsmethoden wechseln, die für die Automatisierung entwickelt wurden, z. B. verwaltete Identitäten oder Dienstprinzipale, die nicht interaktive Automatisierungsanwendungsfälle unterstützen.

Einschränkungen von Benutzeridentitäten mit MFA in der Automatisierung

Note

Möglicherweise tritt die Fehlermeldung auf: Die interaktive Authentifizierung ist erforderlich , wenn Sie eine Benutzeridentität mit Automatisierung verwenden.

  • Interaktive Authentifizierung: MFA wird bei der Verwendung einer Microsoft Entra Benutzeridentität während interaktiver Anmeldungen ausgelöst. Für Automatisierungsskripts, die auf eine Benutzeridentität vertrauen, stört MFA den Prozess, da es zusätzliche Überprüfungsschritte erfordert. Beispiel: Authentifikator-App, Telefonanruf usw., die Sie nicht automatisieren können. Diese Überprüfung verhindert, dass die Automatisierung ausgeführt wird, es sei denn, die Authentifizierung wird nicht interaktiv behandelt, z. B. mit einer verwalteten Identität oder einem Dienstprinzipal.

  • Scripted Login-Fehler: In Automatisierungsszenarien, wie dem unbeaufsichtigten Ausführen von Azure PowerShell-Skripten, führt eine Benutzeridentität mit MFA-Integration dazu, dass das Skript beim Versuch der Authentifizierung fehlschlägt. Da MFA eine Benutzerinteraktion erfordert, ist sie nicht mit nicht interaktiven Skripts kompatibel. Dies bedeutet, dass Sie zu einer verwalteten Identität oder einem Dienstprinzipal wechseln müssen, die beide nicht interaktive Authentifizierung verwenden.

  • Sicherheitsüberlegungen: Während MFA eine zusätzliche Sicherheitsebene hinzufügt, kann sie die Automatisierungsflexibilität einschränken, insbesondere in Produktionsumgebungen, in denen die Automatisierung ohne manuelle Eingriffe ausgeführt werden muss. Die Umstellung auf verwaltete Identitäten, Dienstprinzipale oder Verbundidentitäten, die für Automatisierungszwecke entwickelt wurden und keine MFA erfordern, ist in solchen Umgebungen praktischer und sicherer.

Szenarien, die Updates erfordern

Die folgende Liste enthält Beispielszenarien, in denen Kunden eine Microsoft Entra Benutzeridentität für die Automatisierung mit Azure PowerShell verwenden können. Diese Liste ist nicht vollständig für alle Szenarien.

Warnung

Jedes Automatisierungsszenario, das eine Microsoft Entra Benutzeridentität verwendet, erfordert eine Aktualisierung.

  • Personalisierte oder bestimmte Berechtigungen: Automatisierungsaufgaben, die benutzerspezifische Berechtigungen erfordern, z. B. Aktionen, die an die Rolle einer Person oder bestimmte Microsoft Entra ID Attribute gebunden sind.

  • OAuth 2.0 ROPC-Fluss: Der OAuth 2.0 Resource Owner Password Credentials (ROPC)-Tokengewährungsfluss ist mit MFA nicht kompatibel. Automatisierungsszenarien, die ROPC für die Authentifizierung verwenden, schlagen fehl, wenn MFA erforderlich ist, da MFA nicht in einem nicht interaktiven Fluss abgeschlossen werden kann.

  • Access to resources external to Azure: Automatisierungsszenarien, die Zugriff auf Microsoft 365 Ressourcen erfordern. Beispielsweise SharePoint, Exchange oder andere Clouddienste, die an die Microsoft-Konto eines einzelnen Benutzers gebunden sind.

  • Service-Konten, die von Active Directory mit Microsoft Entra ID: Organisationen, die Dienstkonten verwenden, die von Active Directory (AD) mit Microsoft Entra ID synchronisiert wurden. Es ist wichtig zu beachten, dass diese Konten auch den MFA-Anforderungen unterliegen und dieselben Probleme wie andere Benutzeridentitäten auslösen.

  • Benutzerkontext für Überwachung oder Compliance: Fälle, in denen die Aktionen aus Compliancegründen auf einzelner Benutzerebene überwacht werden müssen.

  • Einfache Konfiguration für kleine oder risikoarme Automatisierung: Für kleine oder risikoarme Automatisierungsaufgaben. Beispielsweise ein Skript, das einige Ressourcen verwaltet.

  • Benutzergesteuerte Automatisierung in Nichtproduktionsumgebungen: Wenn die Automatisierung für persönliche oder nichtproduktion Umgebungen vorgesehen ist, in denen ein einzelner Benutzer für eine Aufgabe verantwortlich ist.

  • Automation innerhalb des eigenen Azure-Abonnements eines Benutzers: Wenn ein Benutzer Aufgaben in seinem eigenen Azure-Abonnement automatisieren muss, in dem der Benutzer bereits über ausreichende Berechtigungen verfügt.

Der Wechsel zu einer verwalteten Identität oder einem Dienstprinzipal ist für Automatisierungsszenarien erforderlich, da Multi-Faktor-Authentifizierung (MFA) zwingend für Microsoft Entra-Benutzeridentitäten durchgesetzt wird.

So beginnen Sie

Führen Sie die folgenden Schritte aus, um Ihre Azure PowerShell-Skripts von der Verwendung von Connect-AzAccount mit einem Microsoft Entra ID menschlichen Benutzerkonto und Kennwort zu migrieren:

  1. Ermitteln Sie, welche Workload-Identität für Sie am besten geeignet ist.

    • Service Principal
    • Verwaltete Identität
    • Verbundidentität

  2. Rufen Sie die erforderlichen Berechtigungen zum Erstellen einer neuen Workload-Identität ab, oder wenden Sie sich an Ihren Azure-Administrator, um Unterstützung zu erhalten.

  3. Erstellen Sie die Workload-Identität.

  4. Weisen Sie der neuen Identität Rollen zu. Weitere Informationen zu Azure Rollenzuweisungen finden Sie unter Steps zum Zuweisen einer Azure Rolle. Informationen zum Zuweisen von Azure-Rollen mit Azure PowerShell finden Sie unter Azure-Rollen mit Azure PowerShell zuweisen.

  5. Aktualisieren Sie Ihre Azure PowerShell Skripts, um sich mit einem Dienstprinzipal oder einer verwalteten Identität anzumelden.

Schlüsselkonzepte des Service Principals

  • Eine nicht menschliche Identität, die auf mehrere Azure Ressourcen zugreifen kann. Ein Dienstprinzipal wird von vielen Azure Ressourcen verwendet und ist nicht an eine einzelne Azure Ressource gebunden.
  • Sie können die Eigenschaften und Anmeldeinformationen eines Dienstprinzipals nach Bedarf ändern.
  • Ideal für Anwendungen, die auf mehrere Azure Ressourcen in verschiedenen Abonnements zugreifen müssen.
  • Wird im Allgemeinen als flexibler angesehen als verwaltete Identitäten, aber weniger sicher.
  • Wird häufig als "Anwendungsobjekt" in einem Azure-Mandant oder Microsoft Entra ID-Verzeichnis bezeichnet.

Weitere Informationen zu Dienstprinzipalen finden Sie unter:

Informationen zum Anmelden bei Azure mithilfe von Azure PowerShell und einem Dienstprinzipal finden Sie unter Sign into Azure with a service principal using Azure PowerShell

Schlüsselkonzepte für verwaltete Identitäten

  • Gebunden an eine bestimmte Azure Ressource, sodass diese einzelne Ressource auf andere Azure Anwendungen zugreifen kann.
  • Anmeldeinformationen sind für Sie nicht sichtbar. Azure behandelt Geheime Schlüssel, Anmeldeinformationen, Zertifikate und Schlüssel.
  • Ideal für Azure Ressourcen, die innerhalb eines einzigen Abonnements auf andere Azure Ressourcen zugreifen müssen.
  • Wird als weniger flexibel als Dienstprinzipien angesehen, aber sicherer.
  • Es gibt zwei Arten von verwalteten Identitäten:
    • System assigned: Dieser Typ ist eine 1:1-Zugriffsverbindung (1 bis 1) zwischen zwei Azure Ressourcen.
    • User assigned: Dieser Typ verfügt über eine 1:M(1:M)-Beziehung, in der die verwaltete Identität auf mehrere Azure Ressourcen zugreifen kann.

Weitere Informationen zu verwalteten Identitäten finden Sie unter Verwaltete Identitäten für Azure-Ressourcen.

Informationen zum Anmelden bei Azure mithilfe von Azure PowerShell und einer verwalteten Identität finden Sie unter Sign into Azure with a managed identity using Azure PowerShell

Schlüsselkonzepte für Verbundidentitäten

  • Eine Verbundidentität ermöglicht es Dienstprinzipalen (App-Registrierungen) und vom Benutzer zugewiesenen verwalteten Identitäten, Tokens von einem externen Identitätsanbieter (IdP), wie z. B. GitHub oder Google, zu vertrauen.
  • Nachdem die Vertrauensstellung erstellt wurde, tauscht Ihre externe Arbeitslast vertrauenswürdige Token vom externen IdP gegen Zugriffstoken der Microsoft Identity Platform aus.
  • Ihre Software-Workload verwendet dieses Zugriffstoken, um auf die Microsoft-Entra-geschützten Ressourcen zuzugreifen, auf die die Workload Zugriff hat.
  • Verbundidentitäten sind häufig die beste Lösung für die folgenden Szenarien:
    • Arbeitslast, die auf einem beliebigen Kubernetes-Cluster ausgeführt wird.
    • GitHub-Aktionen
    • Workload, die auf Azure Compute-Plattformen unter Verwendung von Anwendungsidentitäten ausgeführt wird
    • Google Cloud
    • Amazon Web Services (AWS)
    • Arbeitsauslastung, die auf Computeplattformen außerhalb von Azure ausgeführt wird

Weitere Informationen zu Verbundidentitäten finden Sie unter:

Weitere Informationen zur mehrstufigen Authentifizierung

Die Microsoft Entra ID-Dokumentationswebsite bietet ausführlichere Informationen zu MFA.

Siehe auch

  • Last updated on