Freigeben über

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 enthält Anleitungen zu alternativen Ansätzen für die unterbrechungsfreie Automatisierung.

Von Bedeutung

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

Hinweis

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

  • Interaktive Authentifizierung: MFA wird bei 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.

  • Skriptgesteuerte Anmeldefehler: In Automatisierungsszenarien wie dem unbeaufsichtigten Ausführen von Azure PowerShell-Skripts führt eine MFA-fähige Benutzeridentität dazu, dass das Skript fehlschlägt, wenn versucht wird, sich zu authentifizieren. 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.

  • Zugriff auf Ressourcen außerhalb von Azure: Automatisierungsszenarien, die Zugriff auf Microsoft 365-Ressourcen erfordern. Beispielsweise SharePoint, Exchange oder andere Clouddienste, die an das Microsoft-Konto eines einzelnen Benutzers gebunden sind.

  • Dienstkonten, die von Active Directory zu Microsoft Entra ID synchronisiert wurden: Organisationen, die Dienstkonten verwenden, die aus 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.

  • Automatisierung 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 aufgrund der obligatorischen MFA-Erzwingung für Microsoft Entra-Benutzeridentitäten erforderlich.

So beginnen Sie

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

  1. Ermitteln Sie, welche Workloadidentitä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 in den Schritten zum Zuweisen einer Azure-Rolle. Informationen zum Zuweisen von Rollen mit Azure PowerShell finden Sie unter Zuweisen von Azure-Rollen mithilfe von Azure PowerShell.

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

Schlüsselkonzepte des Dienstprinzipals

  • 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.
  • Betrachtet als flexibler als verwaltete Identitäten, aber weniger sicher.
  • Wird häufig als "Anwendungsobjekt" in einem Azure-Mandanten 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 Anmelden bei Azure mit einem Dienstprinzipal mithilfe von 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 verarbeitet 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.
  • Betrachtet als weniger flexibel als Dienstprinzipale, aber sicherer.
  • Es gibt zwei Arten von verwalteten Identitäten:
    • System zugewiesen: Dieser Typ ist eine 1:1 -Zugriffsverbindung zwischen zwei Azure-Ressourcen.
    • Zugewiesener Benutzer: Dieser Typ verfügt über eine 1:M-Beziehung (eine bis viele), 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 Anmelden bei Azure mit einer verwalteten Identität mithilfe von Azure PowerShell

Schlüsselkonzepte für Verbundidentitäten

  • Eine Verbundidentität ermöglicht Dienstprinzipale (App-Registrierungen) und vom Benutzer zugewiesenen verwalteten Identitäten, Token von einem externen Identitätsanbieter (IdP) zu vertrauen, z. B. GitHub oder Google.
  • Nachdem die Vertrauensstellung erstellt wurde, wechselt Ihre externe Softwarearbeitsauslastung vertrauenswürdige Token aus dem externen IdP für Zugriffstoken von der Microsoft Identity Platform.
  • Ihre Softwarearbeitsauslastung verwendet dieses Zugriffstoken für den Zugriff auf die von Microsoft Entra geschützten Ressourcen, auf die der Workload Zugriff gewährt wird.
  • Verbundidentitäten sind häufig die beste Lösung für die folgenden Szenarien:
    • Workload, die auf einem beliebigen Kubernetes-Cluster ausgeführt wird
    • GitHub-Aktionen
    • Workload, die auf Azure-Computeplattformen mit Anwendungsidentitäten ausgeführt wird
    • Google Cloud
    • Amazon Web Services (AWS)
    • Workload, die auf Computeplattformen außerhalb von Azure ausgeführt wird

Weitere Informationen zu Verbundidentitäten finden Sie unter:

Weitere Informationen zur mehrstufigen Authentifizierung

Die Dokumentationswebsite der Microsoft Entra-ID bietet weitere Details zu MFA.

Siehe auch

  • Last updated on