Řízení přístupu na základě role pro nástroje DevOps
Při nasazování cloudových řešení pro nasazení infrastruktury by zabezpečení mělo být vždy nejdůležitější. Microsoft udržuje základní cloudovou infrastrukturu zabezpečenou. Zabezpečení nakonfigurujete v Azure DevOps nebo GitHubu.
Požadavky
Jakmile se rozhodnete, které šablony cílové zóny Azure se mají nasadit, naklonujte je do vlastního úložiště. Nastavte kanály CI/CD. Pro GitHub i Azure DevOps je k dispozici několik metod ověřování, jako jsou osobní přístupové tokeny (PAT) a integrace s zprostředkovatelem identity, jako je ID Microsoft Entra. Další informace naleznete v tématu Použití osobních přístupových tokenů.
Doporučujeme integrovat se službou Microsoft Entra ID, abyste mohli používat všechny jeho funkce. Integrace pomáhá zjednodušit proces přiřazování rolí a správu životního cyklu identit. Další informace najdete v tématu Připojení vaší organizaci do Microsoft Entra ID. Pokud používáte GitHub, zvažte integraci GitHubu Enterprise s ID Microsoft Entra.
Obecné aspekty návrhu
Doporučujeme udržovat úzkou kontrolu nad správci a skupinami účtů služeb napříč ID Microsoft Entra a nástrojem DevOps. Zvažte implementaci principu nejnižšího oprávnění pro všechna přiřazení rolí.
Vaše organizace může mít například tým platformy nebo efektivity cloudu, který udržuje šablony Azure Resource Manageru pro cílové zóny Azure. Přiřaďte uživatele v daném týmu ke skupině zabezpečení v MICROSOFT Entra ID za předpokladu, že ho používáte jako zprostředkovatele identity. Přiřaďte této skupině zabezpečení v nástroji DevOps role, aby tito uživatelé mohli provádět své úlohy.
U všech účtů s oprávněními správce nebo vysoce privilegovaných účtů ve službě Active Directory doporučujeme, aby se přihlašovací údaje nesynchronovaly s ID Microsoft Entra a naopak. Tento přístup snižuje hrozbu laterálního pohybu. Pokud dojde k ohrožení zabezpečení správce v Microsoft Entra ID, útočník nebude moct snadno získat přístup k žádným cloudovým prostředkům, jako je Azure DevOps. Tento účet nemůže potenciálně vkládat škodlivé úlohy do kanálů CI/CD. Tento krok je zvlášť důležitý pro všechny uživatele přiřazené zvýšenými oprávněními v prostředí DevOps, jako jsou sestavení nebo projekt nebo kolekce Správa istrátory. Další informace naleznete v tématu Osvědčené postupy zabezpečení v Microsoft Entra ID.
Aspekty přístupu na základě role v Azure DevOps
Správa zabezpečení v Azure DevOps pomocí skupin zabezpečení, zásad a nastavení na úrovni organizace/kolekce, projektu nebo objektu Pokud se chcete integrovat s zprostředkovatelem identity, jako je Id Microsoft Entra, zvažte vytvoření zásad podmíněného přístupu pro vynucení vícefaktorového ověřování pro všechny uživatele. Zásady umožňují přístup k vaší organizaci Azure DevOps a podrobnější omezení týkající se IP adresy, typu zařízení používaného pro přístup a dodržování předpisů zařízením.
Pro většinu členů týmu ve vašem týmu platformy, kteří spravují cílové zóny Azure, by výchozí skupina zabezpečení úrovně základního přístupu a přispěvatele měla poskytnout dostatečný přístup. Skupina zabezpečení Přispěvatel umožňuje upravovat šablony cílové zóny Azure ve vašem úložišti a kanály CI/CD, které je ověřují a nasazují.
Doporučujeme, abyste svůj tým platformy přiřadili skupině zabezpečení Přispěvatel na úrovni projektu Azure DevOps. Tento přístup se řídí principem nejnižšího oprávnění. Tato přiřazení je možné provést prostřednictvím stránky projectu Nastavení níže.
Dalším osvědčeným postupem pro vaše projekty a organizace Azure DevOps je zakázat dědičnost tam, kde je to možné. Uživatelé dědí oprávnění povolená přiřazeními skupin zabezpečení. Vzhledem k výchozí povaze dědičnosti povolení můžou neočekávaní uživatelé získat přístup nebo oprávnění.
Pokud například přiřadíte členství ve skupině zabezpečení Přispěvatel týmu platformy, ověřte jejich oprávnění v úložišti cílových zón Azure. Měli byste mít zavedené zásady větve, abyste ověřili, že skupina zabezpečení nesmí tyto zásady během žádostí o přijetí změn obejít. Ověřte toto nastavení v části Project Nastavení> Repositories.
Po přiřazení oprávnění uživatelům pravidelně kontrolujte události auditu, abyste mohli monitorovat neočekávané vzory použití správců a dalších uživatelů a reagovat na ně. Začněte vytvořením streamu auditu do pracovního prostoru služby Log Analytics. Pokud váš pracovní prostor používá Microsoft Sentinel, vytvořte analytická pravidla, která vás upozorní na události, jako je nesprávné použití oprávnění.
Další informace naleznete v následujících zdrojích:
- Osvědčené postupy zabezpečení Azure DevOps
- Skupiny a oprávnění Azure DevOps
- Úrovně přístupu Azure DevOps
Aspekty přístupu na základě role Na GitHubu
Pokud je vaším primárním nástrojem DevOps GitHub, můžete uživatelům přiřadit přístup k prostředkům tím, že jim udělíte role na úrovni úložiště, na úrovni týmu nebo na úrovni organizace. Po vytvoření forku úložiště cílových zón Azure a integraci se zprostředkovatelem identity, jako je ID Microsoft Entra, zvažte vytvoření týmu na GitHubu. Přiřaďte danému týmu přístup pro zápis do nového úložiště cílové zóny Azure. Pro většinu členů týmu platformy, kteří upravují a nasazují cílové zóny, by měl stačit přístup k zápisu. U projektových manažerů nebo správců Scrumu v týmu může být potřeba jim přiřadit roli údržby k danému úložišti.
Doporučujeme spravovat všechna tato přiřazení rolí prostřednictvím integrovaného zprostředkovatele identity. Můžete například synchronizovat tým platformy pro úložiště cílové zóny Azure, které jste vytvořili na GitHubu, s odpovídající skupinou zabezpečení týmu platformy v Microsoft Entra ID. Když pak přidáte nebo odeberete členy do skupiny zabezpečení Microsoft Entra, projeví se tyto změny v přiřazeních rolí cloudu GitHub Enterprise.
Poznámka
Jakmile připojíte konkrétní tým GitHubu k integrovanému zprostředkovateli identity, omezíte se tím na správu členství v týmu.
Další kroky
Další informace o správě rolí a týmů na GitHubu najdete v těchto zdrojích informací: