Sdílet prostřednictvím

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

  • Článek

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

Důležitý

Akce se vyžaduje, pokud pro automatizaci používáte identity uživatelů Microsoft Entra.

Požadavky vícefaktorového ověřování vám brání v používání identit uživatelů Microsoft Entra 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

Poznámka

Může se zobrazit chybová zpráva: je vyžadováno interaktivní ověřování při použití identity uživatele v rámci automatizace.

  • interaktivní ověřování: 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í automatizaci ve spuštění, pokud není ověřování zpracováno neinteraktivním způsobem, jako je spravovaná identita nebo aplikační identita.

  • selhání skriptovaného přihlášení: Ve scénářích automatizace, jako je bezobslužné spouštění skriptů Azure PowerShellu, identita uživatele s podporou vícefaktorového ověřování způsobí 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, které obě 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, ve kterých zákazníci můžou pro automatizaci pomocí Azure PowerShellu používat identitu uživatele Microsoft Entra. Tento seznam není vyčerpávající pro všechny scénáře.

Varování

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

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

  • tok OAuth 2.0 ROPC: Tok udělení tokenu pomocí hesla vlastníka prostředku OAuth 2.0 (ROPC) není vhodný pro vícefaktorové ověřování. 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 pro Azure: Scénáře automatizace, které vyžadují přístup k prostředkům Microsoftu 365. Například SharePoint, Exchange nebo jiné cloudové služby vázané na účet Microsoft jednotlivého uživatele.

  • Účty služby synchronizované z Active Directory do Microsoft Entra ID: Organizace používající účty služeb synchronizované ze služby 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ádět 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 v rámci vlastního předplatného Azure uživatele: Pokud 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í objekt se vyžaduje 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 PowerShellu z používání Connect-AzAccount s uživatelským účtem a heslem Microsoft Entra ID, postupujte takto:

  1. Určete, která identita pracovního zatížení je pro vás nejvhodnější.

    • Principál služby
    • 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 přiřazení role Azure. Pokud chcete přiřadit role pomocí Azure PowerShellu, přečtěte si téma Přiřazení rolí Azure pomocíAzure PowerShellu.

  5. Aktualizujte skripty Azure PowerShellu tak, aby se přihlašovaly pomocí principála služby nebo spravované identity.

Klíčové koncepty hlavního objektu služby

  • Nelidská identita, která má přístup k více prostředkům Azure. Instanční objekt používá mnoho prostředků Azure a není svázaný s jedním prostředkem Azure.
  • Podle potřeby můžete změnit vlastnosti a přihlašovací údaje instančního objektu.
  • Ideální pro aplikace, které potřebují přístup k více prostředkům Azure napříč různými předplatnými.
  • 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 viz:

Informace o přihlášení k Azure pomocí Azure PowerShellu a služebního principálu najdete v tématu Přihlášení k Azure pomocí služebního principálu s Azure PowerShellem

Klíčové koncepty spravovaných identit

  • Svázaná s konkrétním prostředkem Azure, který umožňuje, aby tento jeden prostředek přistupoval k jiným aplikacím Azure.
  • 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 prostředky Azure, které potřebují přístup k dalším prostředkům Azure v rámci jednoho předplatného.
  • Považuje se za méně flexibilní než služební principy, ale bezpečnější.
  • Existují dva typy spravovaných identit:
    • systém přiřazený: Tento typ je 1:1 (jeden až jeden) přístupový odkaz mezi dvěma prostředky Azure.
    • přiřazené uživatelem: Tento typ má vztah 1:M (jeden k mnoha), ve kterém 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 tom, jak se přihlásit k Azure pomocí Azure PowerShellu a spravované identity, najdete v tématu Přihlášení k Azure pomocí spravované identity pomocí azure PowerShellu

Klíčové koncepty federované identity

  • Federovaná identita umožňuje instančním objektům (registrace 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í důvěryhodného vztahu vaše externí softwarové úlohy vyměňují si důvěryhodné tokeny od externího poskytovatele identity za přístupové tokeny z platformy Microsoft Identity.
  • Vaše softwarová úloha používá tento přístupový token pro přístup k prostředkům chráněným Microsoft Entra, 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í

Další podrobnosti o vícefaktorovém ověřování najdete na webu dokumentace k Microsoft Entra ID.

Viz také