Sdílet prostřednictvím


Osvědčené postupy pro zabezpečení rozšiřitelnosti vlastních rozšíření do Azure Logic Apps

Tento článek popisuje osvědčené postupy pro zabezpečení rozšiřitelnosti vlastních rozšíření správy identit Microsoft Entra ID do Azure Logic Apps. Pokyny jsou specifické pro správu nároků, pracovní postupy životního cyklu a doplňují obecné pokyny zabezpečení publikované pro Azure Logic Apps.

Mezi osvědčené postupy popsané v tomto článku patří:

  • Zabezpečení přístupu správce k předplatnému
  • Zakázání sdíleného přístupového podpisu (SAS)
  • Použití spravovaných identit pro ověřování
  • Autorizace s nejnižšími privilegovanými oprávněními
  • Zajištění použití důkazu o vlastnictví (PoP)

Zabezpečení přístupu správce k předplatnému

Přístup správce k předplatným Azure hostujícím vaše Logic Apps by měl být zabezpečený. Doporučujeme postupovat podle architektury přechodu na cloud a pokud je to možné, umístit Logic Apps do předplatného identity. Další informace najdete v tématu:Co je cílová zóna Azure?

Zakázání sdíleného přístupového podpisu (SAS)

Příchozí volání do Logic Apps můžou používat pouze jedno schéma autorizace, přístupové tokeny Microsoft Entra ID nebo sdílený přístupový podpis (SAS). Použití jednoho schématu však nezakazuje druhé schéma. Volání ze správy Microsoft Entra ID do Logic Apps jsou autorizována prostřednictvím schématu autorizace přístupového tokenu Microsoft Entra ID.

Důrazně doporučujeme zakázat schéma autorizace sdíleného přístupového podpisu (SAS) ve službě Logic Apps, protože to není vyžadováno správou Microsoft Entra ID. Zakázání schématu autorizace sdíleného přístupového podpisu (SAS) eliminuje riziko zveřejnění podpisu nebo předmětu neoprávněného přístupu.

Všechny Logic Apps vytvořené prostřednictvím uživatelských rozhraní vlastní rozšíření Microsoft Entra ID Governance po 29. dubnu 2024 mají ve výchozím nastavení zakázané schéma autorizace sdíleného přístupového podpisu (SAS).

Pokud jste vytvořili Logic App prostřednictvím vlastních rozšíření zásad správného řízení Microsoft Entra ID, nejpozději do 29. dubna 2024, postupujte podle pokynů a zakažte schéma autorizace sdíleného přístupového podpisu (SAS), které najdete tady: Zakázání ověřování sdíleného přístupového podpisu (SAS) (pouze spotřeba).

Použití spravovaných identit pro ověřování

Běžnou výzvou je správa tajných kódů, přihlašovacích údajů, certifikátů a klíčů používaných k zabezpečení komunikace mezi službami. Spravované identity eliminují potřebu správy těchto přihlašovacích údajů. Pokud používáte vlastní model spuštění a čekání rozšíření (reference ke správě nároků; Referenční informace k pracovnímu postupu životního cyklu), důrazně doporučujeme, abyste spravované identitě Azure Logic Apps povolili ověřování volání životopisu (taskProcessingResult: resume; accessPackageAssignmentRequest: resume) do zásad správného řízení Microsoft Entra ID. Pokud váš scénář vyžaduje, aby aplikace logiky volala jiné koncové body Microsoft Graphu nebo dokonce jiné integrované služby Microsoft Entra, můžete spravovanou identitu použít také k ověřování volání těchto služeb.

Nastavení oprávnění: Spravovanou identitu musíte povolit sami. Informace o tomto procesu najdete v tématu: Povolení identity přiřazené systémem na webu Azure Portal a jeho následné autorizace.

Pracovní postupy životního cyklu: Spravovaná identita je automaticky povolená a autorizována pro vlastní rozšíření "spuštění a čekání". Pokud vaše Logic App potřebuje volat jiné služby, můžete použít a autorizovat stejnou spravovanou identitu. U vlastních rozšíření „spustit a pokračovat“ je třeba povolit spravovanou identitu sami.

Postup použití spravované identity s akcí Logic Apps najdete v tématu: Ověření přístupu pomocí spravované identity.

Autorizace s nejnižšími privilegovanými oprávněními

Volání obnovení z Logic Apps do správy Microsoft Entra ID lze autorizovat přímo v rámci workflow životního cyklu a správy nároků. Pokud máte oprávnění přímo, nemusíte přiřazovat oprávnění aplikace spravované identity, jako je LifecycleWorkflows.ReadWrite.All nebo Entitlement Management.ReadWrite.All.

Pokyny pro přiřazení nejnižších privilegovaných oprávnění:

Přiřazení nejméně privilegovaných oprávnění pomocí správy nároků

Přiřaďte spravované identitě roli Správce přiřazení přístupového balíčku pro daný katalog, aby bylo možné autorizovat volání životopisu. Obecné pokyny k přiřazování rolí pro katalog najdete v tématu: Jako vlastník katalogu delegujte odpovědnosti správci přístupových balíčků.

Přiřazení nejméně privilegovaných oprávnění pomocí pracovních postupů životního cyklu

Spravovanou identitu je možné přímo autorizovat pro volání životopisu v nastavení vlastního rozšíření. Pracovní postupy životního cyklu pro vás automaticky nastaví během procesu vytváření vlastního rozšíření. Další informace najdete v tématu: Autorizace odpovědi.

Přiřazení nejméně privilegovaných oprávnění k jiným službám a scénářům

Pokud potřebujete aplikaci logiky autorizovat tak, aby volala další služby integrované s ID Microsoft Entra, jako jsou jiná rozhraní Microsoft Graph API, zvažte, že spravovaná identita může také získat oprávnění prostřednictvím přiřazení rolí v různých systémech řízení přístupu na základě role, které často umožňují dodržovat zásadu nejnižšího oprávnění. Následující seznam příkladů není vyčerpávající:

  • Pokud vlastní rozšíření správy nároků potřebuje dotazovat další informace ze správy nároků, můžete aplikaci logiky přiřadit jednu z rolí správy nároků, jako je například čtenář katalogu, pro daný katalog. To umožňuje snížit oprávnění a rozsah v porovnání s oprávněními aplikace na úrovni tenanta EntitlementManagement.Read.All a/nebo EntitlementManagement.ReadWrite.All.
  • Pokud chcete použít vlastní rozšíření Pracovního postupu životního cyklu k vygenerování dočasného přístupového kódu místo předdefinované úlohy, můžete přiřadit spravovanou identitu správcům ověřování Microsoft Entra předdefinovanou roli s omezením na správní jednotku, místo přiřazení oprávnění aplikace UserAuthenticationMethod.ReadWrite.All, což by výrazně zvýšilo rozsah rizika, pokud by došlo ke kompromitaci Logické aplikace.

Další informace o autorizaci Microsoft Graphu najdete v tématu: Získání přístupu bez uživatele.

Zajištění použití důkazu o vlastnictví (PoP)

Logic Apps podporuje buď typ přístupových tokenů nosný (bearer), nebo důkaz vlastnictví (proof-of-possession) v rámci autorizačního schématu přístupového tokenu Microsoft Entra ID. Na začátku veřejné ukázky vlastních rozšíření Microsoft Entra ID Governance se k autorizaci volání z Microsoft Entra ID Governance do Logic Apps používaly nosné přístupové tokeny, na rozdíl od tokenů ověření vlastnictví (PoP).

Od chvíle, kdy se přesunuly do obecné dostupnosti, všechna vlastní rozšíření vytvořená prostřednictvím uživatelských rozhraní správy Microsoft Entra ID a koncových bodů Microsoft Graphu v1.0 ve výchozím nastavení používají schéma autorizace přístupových tokenů pro ověření vlastnictví.

Pokud vaše prostředí stále obsahuje vlastní rozšíření, která se spoléhají na přístupové tokeny nosného typu, doporučujeme přepnout na přístupové tokeny typu proof-of-possession.

Pokud chcete určit schéma autorizace, které aktuálně používá vaše vlastní rozšíření, přečtěte si sloupec zabezpečení tokenu zobrazený v Centru pro správu Microsoft Entra:

Snímek obrazovky se seznamem úkolů a viditelnou sekcí tokenů

Typ přístupového tokenu Sloupec zabezpečení tokenů v Centru pro správu Microsoft Entra
Nosič Regulární
Důkaz o vlastnictví (PoP) Doklad o vlastnictví

Vlastní rozšíření pracovního postupu životního cyklu nelze migrovat z nosných přístupových tokenů na tokeny typu dokazující vlastnictví. Musíte vytvořit nová vlastní rozšíření a nakonfigurovat je v odpovídajících pracovních postupech.

Pro podmnožinu vlastních rozšíření správy nároků můžete použít možnost Aktualizovat na nový typ rozšíření, která je dostupná prostřednictvím uživatelského rozhraní správy nároků. Pokud chcete aktualizovat na nový typ rozšíření, postupujte následovně:

  1. Přihlaste se do Centra pro správu Microsoft Entra jako alespoň správce zásad správného řízení identit.

  2. Přejděte do zásad správného řízení ID>správy nároků>katalogů.

  3. Vyberte katalog s vlastním rozšířením, které chcete aktualizovat.

  4. Na stránce s přehledem katalogu vyberte Vlastní rozšíření.

  5. Na stránce vlastních rozšíření vyhledejte vlastní rozšíření, jehož zabezpečení tokenu říká Regular , a vyberte tři řádky vedle něj. Snímek obrazovky s aktualizací na nový typ zabezpečení tokenu

  6. Vyberte Aktualizovat na nový typ rozšíření.

Poznámka:

Pokud funkce aktualizace selže, musí se vytvořit a nakonfigurovat nové vlastní rozšíření v odpovídajících zásadách přiřazení přístupového balíčku.