Aspekty správy identit a přístupu pro akcelerátor cílové zóny Azure Integration Services
Tento článek vychází z pokynů uvedených v článku o cílové zóně Azure v oblasti návrhu cílové zóny Azure pro správu identit a přístupu. Pokyny uvedené v následujícím článku vám pomůžou identifikovat aspekty návrhu a doporučení týkající se správy identit a přístupu specifické pro nasazení služby Azure Integration Services (AIS). Pokud je AIS nasazená pro podporu důležitých platforem, měly by být do návrhu zahrnuty také pokyny týkající se oblastí návrhu cílových zón Azure.
Přehled správy identit a přístupu (IAM)
Pro účely tohoto článku se správa identit a přístupu (IAM) týká možností ověřování a autorizace, které jsou k dispozici pro nasazení nebo údržbu prostředků v Rámci Azure. V praxi to zahrnuje identifikaci identit, které mají oprávnění k vytváření, aktualizaci, odstraňování a správě prostředků prostřednictvím webu Azure Portal nebo prostřednictvím rozhraní API Resource Manageru.
IAM je samostatná pozornost od zabezpečení koncových bodů, která definuje, které identity můžou volat a přistupovat k vašim službám. Zabezpečení koncových bodů je popsáno v samostatném článku Zabezpečení v této sérii. To znamená, že se někdy dvě oblasti návrhu překrývají: u některých služeb v Azure se přístup ke koncovému bodu konfiguruje prostřednictvím stejných ovládacích prvků RBAC, které se používají ke správě přístupu k prostředkům.
Aspekty návrhu
Určete hranice správy prostředků Azure pro prostředky, které nasazujete, a zvažte oddělení povinností a provozní efektivity.
Projděte si aktivity správy a správy Azure, které vyžadují, aby vaše týmy prováděly. Zvažte prostředky AIS, které nasadíte a jak je budete používat. Určete nejlepší možnou distribuci zodpovědností v rámci vaší organizace.
Doporučení k návrhu
Použití spravovaných identit pro prostředky integračních služeb – podrobný popis tohoto doporučení najdete v článku Zabezpečení v této sérii.
K ověřování prostředků integračních služeb použijte ID Microsoft Entra.
Zvažte úroveň přístupu potřebnou rolemi ve vaší organizaci a použijte zásadu nejnižších oprávnění podle rolí. Mezi tyto role patří vlastníci platforem, vlastníci úloh, technici devops a správci systému, například.
Při použití principu nejnižších oprávnění zvažte, jaké role budete potřebovat ke správě a údržbě aplikací AIS. Otázky týkající se tohoto ohledu:
Kdo bude potřeba zobrazit soubory protokolů ze zdrojů, jako jsou application Přehledy, Log Analytics a účty úložiště?
Potřebuje někdo zobrazit původní data žádosti (včetně citlivých dat)?
Odkud se dají zobrazit původní data žádosti (například jenom z podnikové sítě)?
Kdo může zobrazit historii spuštění pracovního postupu?
Kdo může znovu odeslat neúspěšné spuštění?
Kdo potřebuje přístup ke klíčům předplatného služby API Management?
Kdo může zobrazit obsah tématu nebo předplatného služby Service Bus nebo zobrazit metriky fronty nebo tématu?
Kdo musí být schopná spravovat službu Key Vault?
Kdo musí být možné přidávat, upravovat nebo odstraňovat klíče, tajné kódy a certifikáty ve službě Key Vault?
Kdo musí být schopná zobrazit a číst klíče, tajné kódy nebo certifikáty ve službě Key Vault?
Budou stávající předdefinované role a skupiny Microsoft Entra zahrnovat požadavky, které jste identifikovali?
Vytvořte vlastní role, které omezí přístup nebo zajistí větší členitost oprávnění, když předdefinované role nebudou dostatečně zamknout přístup. Například přístup k adrese URL zpětného volání pro aplikaci logiky vyžaduje jedno oprávnění, ale pro tento typ přístupu neexistuje žádná předdefinovaná role, která je jiná než "Přispěvatel" nebo "Vlastník", což je příliš široké.
Podívejte se na použití Azure Policy k omezení přístupu k určitým prostředkům nebo k vynucení dodržování předpisů se zásadami společnosti. Můžete například vytvořit zásadu, která umožňuje pouze nasazení rozhraní API služby API Management, která používají šifrované protokoly.
Zkontrolujte běžné aktivity spojené se správou a správou AIS v Azure a odpovídajícím způsobem přiřaďte oprávnění RBAC. Další podrobnosti o dostupných oprávněních najdete v tématu Operace poskytovatele prostředků.
Mezi příklady běžných aktivit správy Azure patří:
| Prostředek Azure | Poskytovatel prostředků Azure | Aktivity |
|---|---|---|
| Plán služby App Service | Microsoft.Web/serverfarms | Čtení, připojení, restartování, získání Připojení virtuální sítě |
| Připojení API | Microsoft.Web/connections | Aktualizovat, potvrdit |
| Logic Apps a funkce | Microsoft.Web/sites | Čtení, spuštění, zastavení, restartování, prohození, konfigurace aktualizace, diagnostika čtení, získání Připojení virtuální sítě |
| Účet pro integraci | Microsoft.Logic/integrationAccounts | Čtení, přidání, aktualizace/ odstranění sestavení, čtení, přidání, aktualizace/ odstranění Mapy, čtení/ přidání, aktualizace, odstranění schémat, čtení/ přidání, aktualizace/ odstranění smluv, čtení/ přidání, aktualizace/ odstranění partnerů |
| Service Bus | Microsoft.ServiceBus | Čtení, získání Připojení ionového řetězce, aktualizace konfigurace zotavení po havárii, čtení front, čtení témat, čtení předplatných |
| Účet úložiště | Microsoft.Storage/storageAccounts | Čtení, změna (například historie spuštění pracovního postupu) |
| API Management | Microsoft.ApiManagement | Registrace nebo odstranění uživatele, rozhraní API pro čtení, správa autorizací, správa mezipaměti |
| KeyVault | Microsoft.KeyVault/vaults | Vytvoření trezoru, úprava zásad přístupu |
Další krok
Projděte si důležité oblasti návrhu a projděte si kompletní aspekty a doporučení pro vaši architekturu.