Dopad vícefaktorového ověřování na Azure PowerShell ve scénářích automatizace

Tento článek popisuje, jak vícefaktorové ověřování (MFA) ovlivňuje úlohy automatizace, které používají Microsoft Entra identit uživatelů, a poskytuje pokyny k alternativním přístupům pro nepřerušenou automatizaci.

Important

Pokud pro automatizaci používáte Microsoft Entra identity uživatelů, je potřeba provést akci.

Požadavky vícefaktorového ověřování vám brání v používání Microsoft Entra identit uživatelů pro ověřování ve scénářích automatizace. Organizace musí přejít na metody ověřování navržené pro automatizaci, jako jsou spravované identity nebo instanční objekty, které podporují neinteraktivní případy použití automatizace.

Omezení identit uživatelů s vícefaktorovým ověřováním v automatizaci

Note

Při použití identity uživatele s automatizací se může zobrazit chybová zpráva: Interaktivní ověřování je potřeba .

  • Interactive authentication: Vícefaktorové ověřování se aktivuje při interaktivním přihlašování při použití identity uživatele Microsoft Entra. U automatizačních skriptů, které spoléhají na identitu uživatele, MFA proces přeruší, protože vyžaduje další ověřovací kroky. Například ověřovací aplikace, telefonní hovor atd., které nemůžete automatizovat. Toto ověření brání spuštění automatizace, pokud není ověření zpracováno neinteraktivním způsobem, jako je spravovaná identita nebo služební účet.

  • Selhání přihlášení skriptem: Ve scénářích automatizace, jako je bezobslužné spuštění skriptů Azure PowerShell, způsobí identita uživatele s povoleným vícefaktorovým ověřováním selhání skriptu při pokusu o ověření. Vzhledem k tomu, že vícefaktorové ověřování vyžaduje interakci uživatele, není kompatibilní s neinteraktivními skripty. To znamená, že musíte přepnout na spravovanou identitu nebo služební principál, přičemž obě možnosti používají neinteraktivní ověřování.

  • Aspekty zabezpečení: Zatímco vícefaktorové ověřování přidává další vrstvu zabezpečení, může omezit flexibilitu automatizace, zejména v produkčních prostředích, kde musí automatizace běžet bez ručního zásahu. Přechod na spravované identity, instanční objekty nebo federované identity, které jsou navržené pro účely automatizace a nevyžadují vícefaktorové ověřování, je v takových prostředích praktičtější a bezpečnější.

Scénáře, které vyžadují aktualizace

Následující seznam obsahuje ukázkové scénáře, kdy zákazníci můžou pro automatizaci s Azure PowerShell používat identitu uživatele Microsoft Entra. Tento seznam není vyčerpávající pro všechny scénáře.

Warning

Jakýkoli scénář automatizace, který používá Microsoft Entra identitu uživatele, vyžaduje aktualizaci.

  • Personalized or specific permissions: Úlohy automatizace, které vyžadují oprávnění specifická pro uživatele, například akce vázané na roli jednotlivce nebo konkrétní atributy Microsoft Entra ID.

  • OAuth 2.0 ROPC tok: Tok pro udělení přístupových údajů vlastníka prostředku OAuth 2.0 (ROPC) není kompatibilní s vícefaktorovým ověřováním (MFA). Scénáře automatizace využívající ROPC pro ověřování selžou, když je potřeba vícefaktorové ověřování, protože vícefaktorové ověřování nejde dokončit v neinteraktivním toku.

  • Přístup k prostředkům externím vůči Azure: Scénáře automatizace, které vyžadují přístup k prostředkům Microsoft 365. Například SharePoint, Exchange nebo jiné cloudové služby svázané s účet Microsoft jednotlivých uživatelů.

  • Uživatelské účty služby synchronizované z služba Active Directory do Microsoft Entra ID: Organizace používající uživatelské účty služby synchronizované z služba Active Directory (AD) do Microsoft Entra ID. Je důležité si uvědomit, že tyto účty podléhají také požadavkům na vícefaktorové ověřování a aktivují stejné problémy jako jiné identity uživatelů.

  • Kontext uživatele pro auditování nebo dodržování předpisů: Případy, kdy je potřeba provést auditování na úrovni jednotlivých uživatelů z důvodů dodržování předpisů.

  • Jednoduchá konfigurace pro automatizaci s malými nebo nízkými riziky: Pro úlohy automatizace s malými nebo nízkými riziky. Například skript, který spravuje několik prostředků.

  • Automatizace řízená uživatelem v neprodukčních prostředích: Pokud je automatizace určená pro osobní nebo neprodukční prostředí, kde je za úkol zodpovědný jednotlivý uživatel.

  • Automatizace ve vlastním předplatném Azure uživatele: Pokud uživatel potřebuje automatizovat úlohy ve svém předplatném Azure, kde již má dostatečná oprávnění.

Přepnutí na spravovanou identitu nebo služební principál je vyžadováno pro scénáře automatizace kvůli povinnému vynucení vícefaktorového ověřování pro uživatelské identity Microsoft Entra.

Jak začít

Pokud chcete migrovat skripty Azure PowerShell z používání Connect-AzAccount s účtem uživatele a heslem Microsoft Entra ID na jinou konfiguraci, postupujte takto:

  1. Určete, která identita pracovní zátěže je pro vás nejvhodnější.

    • Hlavní služba
    • Spravovaná identita
    • Federovaná identita

  2. Získejte potřebná oprávnění k vytvoření nové identity úlohy nebo požádejte o pomoc správce Azure.

  3. Vytvořte identitu úlohy.

  4. Přiřaďte nové identitě role. Další informace o přiřazení rolí Azure najdete v tématu Kroky pro přiřazení role Azure. Pokud chcete přiřadit role pomocí Azure PowerShell, přečtěte si téma Přiřazování rolí Azure pomocí Azure PowerShell.

  5. Aktualizujte skripty Azure PowerShell tak, aby se přihlásily pomocí služebního objektu nebo spravované identity.

Klíčové koncepty služby principal

  • Nelidská identita, která má přístup k více Azure prostředkům. Instanční objekt "služební principál" používá mnoho prostředků Azure a není svázán s jedním konkrétním prostředkem.
  • Podle potřeby můžete změnit vlastnosti a přihlašovací údaje služebního účtu.
  • Ideální pro aplikace, které potřebují přístup k více Azure prostředkům v různých předplatných.
  • Zvažované flexibilnější než spravované identity, ale méně bezpečné.
  • Často se označuje jako "objekt aplikace" v tenantovi Azure nebo v adresáři Microsoft Entra ID.

Další informace o aplikačních objektech najdete zde:

Chcete-li se dozvědět, jak se přihlásit k Azure pomocí Azure PowerShell a aplikačního objektu, naleznete další informace v tématu Přihlášení k Azure s aplikačním objektem pomocí Azure PowerShell

Klíčové koncepty spravovaných identit

  • Svázaný s konkrétním Azure prostředkem, který umožňuje, aby jeden prostředek přistupoval k jiným Azure aplikacím.
  • Přihlašovací údaje nejsou pro vás viditelné. Azure zpracovává tajné kódy, přihlašovací údaje, certifikáty a klíče.
  • Ideální pro Azure prostředky, které potřebují přístup k dalším Azure prostředkům v rámci jednoho předplatného.
  • Jsou považovány za méně flexibilní než služební principy, ale bezpečnější.
  • Existují dva typy spravovaných identit:
    • Systémově přiřazeno: Tento typ je přístupový odkaz 1:1 (jeden až jeden) mezi dvěma prostředky Azure.
    • Uživateli přiřazené: Tento typ má vztah 1:M (jeden až mnoho), kde má spravovaná identita přístup k více prostředkům Azure.

Další informace o spravovaných identitách najdete v tématu Spravované identity pro prostředky Azure.

Informace o přihlášení k Azure pomocí Azure PowerShell a spravované identity najdete v tématu Sign into Azure with a managed identity using Azure PowerShell

Klíčové koncepty federované identity

  • Federovaná identita umožňuje instančním objektům (registrací aplikací) a spravovaným identitám přiřazeným uživatelem důvěřovat tokenům od externího zprostředkovatele identity (IDP), jako je GitHub nebo Google.
  • Po vytvoření vztahu důvěryhodnosti vaše externí softwarové úlohy vyměňují důvěryhodné tokeny z externího zprostředkovatele identity za přístupové tokeny z platformy Microsoft identity.
  • Vaše softwarová úloha používá tento přístupový token pro přístup k Microsoft Entra chráněným prostředkům, ke kterým má úloha udělený přístup.
  • Federované identity jsou často nejlepším řešením pro následující scénáře:
    • Úloha spuštěná v jakémkoli clusteru Kubernetes
    • GitHub Actions
    • Úlohy spuštěné na výpočetních platformách Azure s využitím identit aplikací
    • Google Cloud
    • Amazon Web Services (AWS)
    • Úloha spuštěná na výpočetních platformách mimo Azure

Další informace o federovaných identitách najdete tady:

Další informace o vícefaktorové ověřování

Web dokumentace Microsoft Entra ID nabízí podrobnější informace o vícefaktorovém ověřování.

Viz také

  • Last updated on