Celkové řízení v Azure při používání CI/CD

Při vývoji modelu zásad správného řízení pro vaši organizaci je důležité si uvědomit, že Azure Resource Manager je jen jedním ze způsobů správy prostředků. Automatizace nástrojů Azure DevOps a kontinuální integrace a průběžného doručování (CI/CD) mohou být neúmyslná zadní vrátka v zabezpečení, pokud nejsou správně zabezpečená. Tyto prostředky by měly být chráněné zrcadlením modelu řízení přístupu na základě role (RBAC) používaného pro Resource Manager.

Koncept komplexních zásad správného řízení je nezávislý na dodavateli. Implementace popsaná zde používá Azure DevOps, ale stručně se zde uvádí i alternativy.

Potenciální případy použití

Tato referenční implementace a ukázka je open source a je určená k použití jako výukový nástroj pro organizace, které s DevOps začíná, a potřebují vytvořit model zásad správného řízení pro nasazení do Azure. Přečtěte si tento scénář pečlivě, abyste pochopili rozhodnutí za modelem používaným v tomto ukázkovém úložišti.

Každý model zásad správného řízení musí být svázán s obchodními pravidly organizace, které se odrážejí v jakékoli technické implementaci řízení přístupu. Tento ukázkový model používá fiktivní společnost s následujícím běžným scénářem (s obchodními požadavky):

• Skupiny Microsoft Entra, které odpovídají obchodním doménám a modelům oprávnění
  Organizace má mnoho vertikálních obchodních domén, jako jsou "ovoce" a "zelenina", které fungují z velké části nezávisle. V každé obchodní doméně existují dvě úrovně nebo oprávnění, která se mapují na odlišné *-admins skupiny nebo *-devs skupiny Microsoft Entra. To umožňuje vývojářům cílit při konfiguraci oprávnění v cloudu.

• Prostředí nasazení
  Každý tým má dvě prostředí:

  • Výroba. Pouze správci mají zvýšená oprávnění.
  • Neprodukční. Všichni vývojáři mají zvýšená oprávnění (pro podporu experimentování a inovací).

• Cíle automatizace
  Každá aplikace by měla implementovat Azure DevOps nejen pro kontinuální integraci (CI), ale také pro průběžné nasazování (CD). Nasazení se například dají automaticky aktivovat změnami úložiště Git.

• Cesta ke cloudu zatím
  Organizace začala s izolovaným projektovým modelem, aby urychlila cestu ke cloudu. Nyní však zkoumají možnosti, jak překonat bariéry a podpořit spolupráci pomocí projektů "spolupráce" a "supermarket".

Tento zjednodušený diagram znázorňuje, jak větve v úložišti Git mapují na vývoj, přípravu a produkční prostředí:

Stáhněte si SVG tohoto diagramu.

Architecture

Tento diagram znázorňuje, jak je propojení z Resource Manageru a CI/CD s ID Microsoft Entra klíčem k vytvoření kompletního modelu zásad správného řízení.

Stáhněte si SVG této architektury.

Poznámka:

Aby byl koncept srozumitelnější, diagram znázorňuje pouze doménu "zelenina". Doména "ovoce" by vypadala podobně a používala stejné zásady vytváření názvů.

Workflow

Číslování odráží pořadí, ve kterém správci IT a podnikoví architekti uvažují o cloudových prostředcích a konfigurují je.

1. Microsoft Entra ID

   Azure DevOps integrujeme s Microsoft Entra ID , abychom měli jednu rovinu identity. To znamená, že vývojář používá stejný účet Microsoft Entra pro Azure DevOps i Resource Manager. Uživatelé nejsou přidáni jednotlivě. Místo toho je členství přiřazeno skupinami Microsoft Entra, abychom mohli odebrat přístup vývojáře k prostředkům v jednom kroku – odebráním jejich členství ve skupinách Microsoft Entra. Pro každou doménu vytvoříme:

   • Skupiny Microsoft Entra. Dvě skupiny na doménu (popsané dále v kroku 4 a 5 dále v tomto článku).
   • Hlavní identita služby. Jeden explicitní služební účet pro každé prostředí.

2. Produkční prostředí

   Pro zjednodušení nasazení tato referenční implementace používá skupinu prostředků k reprezentaci produkčního prostředí. V praxi byste měli použít jiné předplatné.

   Privilegovaný přístup k tomuto prostředí je omezen pouze na správce.

3. vývojového prostředí

   Pro zjednodušení nasazení tato referenční implementace používá skupinu prostředků k reprezentaci vývojového prostředí. V praxi byste měli použít jiné předplatné.

4. Přiřazení rolí v Resource Manageru

   I když naše názvy skupin Microsoft Entra znamenají roli, řízení přístupu se nepoužije, dokud se nenakonfiguruje přiřazení role . Tím se přiřadí role k objektu zabezpečení Microsoft Entra pro konkrétní obor. Vývojáři mají například roli přispěvatel v produkčním prostředí.

   Hlavní subjekt Microsoft Entra	Vývojové prostředí (Resource Manager)	Produkční prostředí (Resource Manager)
   veggies-devs-group	Owner	Čtenář
   veggies-admins-group	Vlastník	Vlastník
   veggies-ci-dev-sp	Vlastní role *	–
   veggies-ci-prod-sp	–	Vlastní role *

   * Pro zjednodušení nasazení tato referenční implementace přiřadí Owner roli služebním identitám. V produkčním prostředí byste měli vytvořit vlastní roli, která brání principálu služby v odebrání zámků správy, které jste umístili na prostředky. To pomáhá chránit prostředky před náhodným poškozením, jako je odstranění databáze.

   Vysvětlení odůvodnění jednotlivých přiřazení rolí najdete v části Důležité informace dále v tomto článku.

5. Přiřazení skupin zabezpečení v Azure DevOps

   Skupiny zabezpečení fungují jako role v Resource Manageru. Využijte předdefinované role a výchozí nastavení přispěvatele pro vývojáře. Správci se přiřadí ke skupině zabezpečení Správce projektu pro zvýšená oprávnění, což jim umožní konfigurovat oprávnění zabezpečení.

   Všimněte si, že Azure DevOps a Resource Manager mají různé modely oprávnění:

   • Azure Resource Manager používá model doplňkových oprávnění .
   • Azure DevOps používá model nejmenších oprávnění .

   Z tohoto důvodu se členství ve skupinách -admins a -devs musí vzájemně vylučovat. Jinak by ovlivněné osoby měly v Azure DevOps méně přístupu, než se čekalo.

   Název skupiny	Role správce zdrojů	Role Azure DevOps
   fruits-all	–	–
   fruits-devs	Přispěvatel	Přispěvatel
   fruits-admins	Vlastník	Správci projektů
   veggies-all	–	–
   veggies-devs	Přispěvatel	Přispěvatel
   veggies-admins	Vlastník	Správci projektů
   infra-all	–	–
   infra-devs	Přispěvatel	Přispěvatel
   infra-admins	Vlastník	Správci projektů

   Ve scénáři omezené spolupráce, jako je například tým ovoce, který zve tým zeleniny ke spolupráci na jednom úložišti, by použili skupinu veggies-all.

   Vysvětlení odůvodnění jednotlivých přiřazení rolí najdete v části s aspekty dále v tomto článku.

6. Připojení služeb

   V Azure DevOps je připojení ke službě obecný obal kolem přihlašovacích údajů. Vytvoříme připojení služby, které obsahuje ID klienta servisního principálu a klientské tajemství. Správci projektů můžou v případě potřeby nakonfigurovat přístup k tomuto chráněnému prostředku , například když před nasazením vyžadují schválení člověkem. Tato referenční architektura má dvě minimální opatření na ochranu připojení služby.

   • Správci musí nakonfigurovat oprávnění pipeline ke kontrole, které pipeline mohou mít přístup k přihlašovacím údajům.
   • Správci musejí také nakonfigurovat kontrolu větve tak, aby pouze kanály spuštěné v kontextu production větve mohly používat prod-connection.

7. Úložiště Git

   Vzhledem k tomu, že připojení služeb jsou svázaná s větvemi prostřednictvím ovládacích prvků větví, je důležité nakonfigurovat oprávnění k úložištím Git a použít zásady větví. Kromě vyžadování, aby sestavení CI prošla, také požadujeme, aby pull requesty měly alespoň dva schvalovatele.

Components

• Azure DevOps
• Microsoft Entra ID
• Azure Resource Manager
• Azure Repos
• Kanály Azure

Alternatives

Koncept komplexních zásad správného řízení je nezávislý na dodavateli. I když se tento článek zaměřuje na Azure DevOps, azure DevOps Server je možné použít jako místní náhradu. Alternativně můžete také použít sadu technologií pro opensourcový vývojový kanál CI/CD s využitím možností, jako je Jenkins a GitLab.

Azure Repos i GitHub jsou platformy vytvořené tak, aby používaly opensourcový systém správy verzí Gitu. I když jsou jejich sady funkcí poněkud odlišné, obě je možné integrovat do globálních modelů zásad správného řízení pro CI/CD. GitLab je další platforma založená na Gitu, která poskytuje robustní funkce CI/CD.

Tento scénář používá Terraform jako nástroj pro infrastrukturu jako kód (IaC). K alternativám patří Jenkins, Ansible a Chef.

Úvahy

Pokud chcete dosáhnout komplexních zásad správného řízení v Azure, je důležité pochopit profil zabezpečení a oprávnění cesty z počítače vývojáře do produkčního prostředí. Následující diagram znázorňuje základní pracovní postup CI/CD s Azure DevOps. Červená ikona zámku označuje oprávnění zabezpečení, která musí uživatel nakonfigurovat. Nenakonfigurování nebo nesprávná konfigurace oprávnění způsobí, že vaše úlohy budou zranitelné.

Stáhněte si SVG tohoto pracovního postupu.

Pokud chcete úlohy úspěšně zabezpečit, musíte ve svém pracovním postupu použít kombinaci konfigurací oprávnění zabezpečení a lidských kontrol. Je důležité, aby se každý model RBAC rozšířil také na kanály a kód. Tyto úlohy se často spouštějí s privilegovanými identitami a mohou zničit vaše pracovní zátěže, pokud jsou k tomu vyzvány. Abyste tomu zabránili, měli byste ve svém úložišti nakonfigurovat zásady větve tak, aby před přijetím změn aktivovaných kanály automatizace vyžadovaly schválení člověkem.

Fáze nasazení	Odpovědnost	Description
Žádosti o přijetí změn	Uživatel	Inženýři by měli svou práci zkontrolovat, včetně samotného kódu kanálu.
Ochrana větví	sdílené	Nakonfigurujte Azure DevOps tak, aby odmítal změny, které nesplňují určité standardy, jako jsou kontroly CI a partnerské kontroly (prostřednictvím žádostí o přijetí změn).
Kanál jako kód	Uživatel	Server sestavení odstraní celé produkční prostředí, pokud kód pipeline k tomu dá pokyn. Pomozte tomu zabránit pomocí kombinace pull requestů a pravidel ochrany větví, jako je například ruční schválení.
Připojení služeb	sdílené	Nakonfigurujte Azure DevOps tak, aby omezovala přístup k těmto přihlašovacím údajům.
Prostředky Azure	sdílené	Nakonfigurujte řízení přístupu na základě role v Resource Manageru.

Při návrhu modelu zásad správného řízení je důležité zvážit následující koncepty a otázky. Mějte na paměti potenciální případy použití této ukázkové organizace.

1. Ochrana prostředí pomocí politik větví

Vzhledem k tomu, že zdrojový kód definuje a aktivuje nasazení, je vaším prvním řádkem obrany zabezpečení úložiště správy zdrojového kódu (SCM). V praxi toho dosáhnete pomocí pracovního postupu žádosti o přijetí změn v kombinaci se zásadami větví, které definují kontroly a požadavky před přijetím kódu.

Při plánování kompletního modelu zásad správného řízení zodpovídají privilegovaní uživatelé (veggies-admins) za konfiguraci ochrany větví. Mezi běžné kontroly ochrany větví, které se používají k zabezpečení nasazení, patří:

• Vyžadovat úspěšné dokončení sestavení CI. Užitečné pro stanovení základní kvality kódu, jako je lintování kódu, testy jednotek a dokonce i kontroly zabezpečení, jako jsou kontroly virů a přihlašovacích údajů.

• Vyžadovat kolegiální kontrolu Požádejte další osobu, aby ověřila, že kód funguje podle očekávání. Při změnách kódu kanálu buďte opatrní. Zkombinujte s buildy CI, aby partnerské recenze byly méně zdlouhavé.

Co se stane, když se vývojář pokusí odeslat přímo do produkčního prostředí?

Mějte na paměti, že Git je distribuovaný systém SCM. Vývojář může commitovat přímo do své lokální production větve. Pokud je ale Git správně nakonfigurovaný, server Git ho automaticky odmítne. Například:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Všimněte si, že pracovní postup v příkladu je nezávislý na dodavateli. Funkce žádosti o přijetí změn a ochrany větví jsou k dispozici od několika poskytovatelů SCM, včetně Azure Repos, GitHubu a GitLabu.

Po přijetí kódu do chráněné větve se další vrstva řízení přístupu použije na buildovacím serveru (například Azure Pipelines).

2. Jaký přístup potřebují zabezpečovací principy?

V Azure může být bezpečnostní objekt buď uživatelský objekt, nebo bezhlavý objekt, například služební objekt nebo spravovaná identita. Ve všech prostředích by objekty zabezpečení měly dodržovat zásadu nejnižších oprávnění. I když můžou bezpečnostní principály rozšířit přístup v předprodukčních prostředích, produkční prostředí Azure by měla minimalizovat stálá oprávnění, upřednostňovat přístup just-in-time (JIT) a podmíněný přístup Microsoft Entra. Vytvořte přiřazení rolí Azure RBAC pro uživatelské subjekty, aby odpovídaly zásadám nejnižších oprávnění.

Je také důležité modelovat Azure RBAC odlišně od Azure DevOps RBAC. Účelem kanálu je minimalizovat přímý přístup k Azure. S výjimkou zvláštních případů, jako jsou inovace, učení a řešení problémů, by se většina interakcí s Azure měla provádět prostřednictvím účelově vytvořených a vrátných kanálů.

U zástupců služby Azure Pipeline zvažte použití vlastní role, která zabrání odstranění blokací zdrojů a provádění dalších destruktivních akcí mimo určený účel.

3. Vytvoření vlastní role pro instanční objekt použitý pro přístup k produkčnímu prostředí

Je běžnou chybou poskytovat agentům pro sestavení CI/CD role vlastníka a oprávnění. Oprávnění přispěvatele nestačí, pokud váš proces potřebuje také provádět přiřazování rolí identit nebo jiné privilegované operace, jako je správa zásad služby Key Vault.

Agent CI/CD Build odstraní celé produkční prostředí, pokud k tomu dostane pokyn. Abychom se vyhnuli nevratným destruktivním změnám, vytvoříme vlastní roli, která:

• Odebere zásady přístupu ke službě Key Vault.
• Odebere správní zámky, které podle návrhu mají úmyslně zabránit odstranění prostředků (běžný požadavek v regulovaných odvětvích).

K tomu vytvoříme vlastní roli a odebereme akce Microsoft.Authorization/*/Delete.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Pokud se odebere příliš mnoho oprávnění pro vaše účely, projděte si úplný seznam v oficiální dokumentaci pro operace poskytovatele prostředků Azure a podle potřeby upravte definici role.

Nasazení tohoto scénáře

Tento scénář přesahuje Resource Manager. Proto používáme Terraform, který nám umožňuje také vytvářet objekty zabezpečení v Microsoft Entra ID a bootstrap Azure DevOps pomocí jediné infrastruktury jako nástroje pro kód.

Informace o zdrojovém kódu a podrobných pokynech najdete v zásadách správného řízení úložiště GitHub ve službě Azure Demo – od DevOps do ARM.

Pricing

Náklady na Azure DevOps závisí na počtu uživatelů ve vaší organizaci, kteří vyžadují přístup, spolu s dalšími faktory, jako je počet požadovaných souběžných buildů a vydaných verzí a počet uživatelů. Azure Repos a Azure Pipelines jsou funkce služby Azure DevOps. Další informace najdete v cenách Azure DevOps.

V Microsoft Entra ID je typ správy přístupu skupiny potřebný pro tento scénář k dispozici v edicích Premium P1 a Premium P2. Ceny těchto úrovní se počítají na základě jednotlivých uživatelů. Další informace najdete v tématu Ceny služby Microsoft Entra.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Julie Ng | Vedoucí servisní technik

Další kroky

• Navštivte úložiště kódu pro tento scénář v tématu Zásady správného řízení v Azure Demo – od DevOps do ARM.
• Projděte si příručky k zásadám správného řízení cloudu v rámci architektury přechodu na cloud.
• Co je řízení přístupu na základě role v Azure (Azure RBAC)?
• Architektura přechodu na cloud: Správa přístupu k prostředkům v Azure
• Role správce zdrojů Azure
  • Vlastník (integrovaný)
  • Přispěvatel (integrovaný)
  • Čtenář (integrovaný)
  • Vlastní role
• Skupiny zabezpečení Azure DevOps
  • Správci projektů
  • Contributor
  • Reader