Kompleksowe zarządzanie na platformie Azure podczas korzystania z ciągłej integracji/ciągłego wdrażania

Podczas tworzenia modelu ładu dla organizacji należy pamiętać, że usługa Azure Resource Manager jest tylko jednym ze sposobów zarządzania zasobami. Usługa Azure DevOps i ciągła integracja i ciągła automatyzacja ciągłego dostarczania (CI/CD) może być niezamierzonym zapleczem zabezpieczeń, jeśli nie jest prawidłowo zabezpieczone. Te zasoby powinny być chronione przez dublowanie modelu kontroli dostępu opartej na rolach (RBAC) używanego dla usługi Resource Manager.

Pojęcie kompleksowego ładu jest niezależne od dostawcy. Implementacja opisana w tym miejscu korzysta z usługi Azure DevOps, ale alternatywy są również krótko wymienione.

Potencjalne przypadki użycia

Ta implementacja referencyjna i pokaz są typu open source i mają być używane jako narzędzie do nauczania dla organizacji, które są nowe w usłudze DevOps i muszą utworzyć model ładu na potrzeby wdrażania na platformie Azure. Przeczytaj ten scenariusz dokładnie, aby zrozumieć decyzje dotyczące modelu używanego w tym przykładowym repozytorium.

Każdy model zapewniania ładu musi być powiązany z regułami biznesowymi organizacji, które są odzwierciedlane w dowolnej implementacji technicznej mechanizmów kontroli dostępu. W tym przykładowym modelu użyto fikcyjnej firmy z następującym typowym scenariuszem (z wymaganiami biznesowymi):

• Grupy entra firmy Microsoft, które są zgodne z domenami biznesowymi i modelami uprawnień
  Organizacja ma wiele pionowych domen biznesowych, takich jak "owoce" i "warzywa", które działają w dużej mierze niezależnie. W każdej domenie biznesowej istnieją dwa poziomy lub uprawnienia, które są mapowane na odrębne *-admins grupy lub *-devs Grupy entra firmy Microsoft. Dzięki temu deweloperzy mogą być objęci celami podczas konfigurowania uprawnień w chmurze.

• Środowiska wdrażania
  Każdy zespół ma dwa środowiska:

  • Produkcja. Tylko administratorzy mają podwyższone uprawnienia.
  • Nieprodukcyjny. Wszyscy deweloperzy mają podwyższone uprawnienia (aby zachęcić do eksperymentowania i innowacji).

• Cele automatyzacji
  Każda aplikacja powinna implementować usługę Azure DevOps nie tylko na potrzeby ciągłej integracji, ale także ciągłego wdrażania (CD). Na przykład wdrożenia mogą być wyzwalane automatycznie przez zmiany w repozytorium Git.

• Podróż do chmury do tej pory
  Organizacja rozpoczęła pracę z izolowanym modelem projektu, aby przyspieszyć podróż do chmury. Ale teraz badają opcje, aby złamać silosy i zachęcić do współpracy, tworząc projekty "współpracy" i "supermarketu".

Ten uproszczony diagram przedstawia sposób mapowania gałęzi w repozytorium Git na środowiska programistyczne, przejściowe i produkcyjne:

Pobierz plik SVG tego diagramu.

Architektura

Na tym diagramie pokazano, jak łączenie z usługi Resource Manager i ciągłej integracji/ciągłego wdrażania z identyfikatorem Entra firmy Microsoft jest kluczem do posiadania kompleksowego modelu ładu.

Pobierz plik SVG tej architektury.

Przepływ pracy

Numerowanie odzwierciedla kolejność, w jakiej administratorzy IT i architekci przedsiębiorstwa myślą i konfigurują swoje zasoby w chmurze.

1. Tożsamość Microsoft Entra

   Integrujemy usługę Azure DevOps z identyfikatorem Entra firmy Microsoft, aby mieć jedną płaszczyznę tożsamości. Oznacza to, że deweloper korzysta z tego samego konta Microsoft Entra zarówno dla usługi Azure DevOps, jak i usługi Resource Manager. Użytkownicy nie są dodawani indywidualnie. Zamiast tego członkostwo jest przypisywane przez grupy entra firmy Microsoft, abyśmy mogli usunąć dostęp dewelopera do zasobów w jednym kroku — usuwając ich członkostwo w grupie Microsoft Entra. Dla każdej domeny tworzymy:

   • Grupy firmy Microsoft Entra. Dwie grupy na domenę (opisane w kroku 4 i 5 w dalszej części tego artykułu).
   • Jednostki usługi. Jedna jawna jednostka usługi na środowisko.

2. Środowisko produkcyjne

   Aby uprościć wdrażanie, ta implementacja referencyjna używa grupy zasobów do reprezentowania środowiska produkcyjnego. W praktyce należy użyć innej subskrypcji.

   Uprzywilejowany dostęp do tego środowiska jest ograniczony tylko do administratorów.

3. Środowisko programistyczne

   Aby uprościć wdrażanie, ta implementacja referencyjna używa grupy zasobów do reprezentowania środowiska deweloperskiego. W praktyce należy użyć innej subskrypcji.

4. Przypisania ról w usłudze Resource Manager

   Mimo że nazwy grup Entra firmy Microsoft oznaczają rolę, kontrole dostępu nie są stosowane do momentu skonfigurowania przypisania roli. Spowoduje to przypisanie roli do podmiotu zabezpieczeń firmy Microsoft dla określonego zakresu. Na przykład deweloperzy mają rolę Współautor w środowisku produkcyjnym.

   Podmiot zabezpieczeń firmy Microsoft	Środowisko deweloperskie (Resource Manager)	Środowisko produkcyjne (Resource Manager)
   veggies-devs-group	Właściciel	Czytelnik
   veggies-admins-group	Właściciel	Właściciel
   veggies-ci-dev-sp	Rola niestandardowa *	–
   veggies-ci-prod-sp	–	Rola niestandardowa *

   * Aby uprościć wdrażanie, ta implementacja referencyjna przypisuje Owner rolę do jednostek usługi. Jednak w środowisku produkcyjnym należy utworzyć rolę niestandardową, która uniemożliwia jednostce usługi usunięcie wszelkich blokad zarządzania, które zostały umieszczone w zasobach. Pomaga to chronić zasoby przed przypadkowymi uszkodzeniami, takimi jak usunięcie bazy danych.

   Aby zrozumieć przyczyny poszczególnych przypisań ról, zapoznaj się z sekcją dotyczącą zagadnień w dalszej części tego artykułu.

5. Przypisania grup zabezpieczeń w usłudze Azure DevOps

   Grupy zabezpieczeń działają jak role w usłudze Resource Manager. Korzystaj z wbudowanych ról i domyślnych ról współautora dla deweloperów. Administratorzy uzyskują przypisanie do grupy zabezpieczeń Administrator projektu w celu uzyskania podwyższonych uprawnień, co pozwala im skonfigurować uprawnienia zabezpieczeń.

   Pamiętaj, że usługi Azure DevOps i Resource Manager mają różne modele uprawnień:

   • Usługa Azure Resource Manager używa modelu uprawnień addytywnego.
   • Usługa Azure DevOps używa modelu najmniejszych uprawnień .

   Z tego powodu członkostwo w -admins grupach i -devs musi być wzajemnie wykluczające. W przeciwnym razie osoby, których dotyczy problem, będą miały mniejszy dostęp niż oczekiwano w usłudze Azure DevOps.

   Nazwa grupy	Rola usługi Resource Manager	Rola usługi Azure DevOps
   fruits-all	–	–
   fruits-devs	Współautor	Współautor
   fruits-admins	Właściciel	Administratorzy projektu
   veggies-all	–	–
   veggies-devs	Współautor	Współautor
   veggies-admins	Właściciel	Administratorzy projektu
   infra-all	–	–
   infra-devs	Współautor	Współautor
   infra-admins	Właściciel	Administratorzy projektu

   W scenariuszu ograniczonej współpracy, takiej jak zespół owoców zapraszający zespół warzyw do współpracy nad pojedynczym repozytorium, będzie używać veggies-all grupy.

   Aby zrozumieć przyczyny poszczególnych przypisań ról, zapoznaj się z sekcją dotyczącą zagadnień w dalszej części tego artykułu.

6. Połączenia z usługami

   W usłudze Azure DevOps połączenie z usługą to ogólna otoka wokół poświadczeń. Tworzymy połączenie usługi, które przechowuje identyfikator klienta jednostki usługi i klucz tajny klienta. Administratorzy projektu mogą skonfigurować dostęp do tego chronionego zasobu w razie potrzeby, na przykład w przypadku wymagania zatwierdzenia przez człowieka przed wdrożeniem. Ta architektura referencyjna ma dwie minimalne zabezpieczenia połączenia z usługą:

   • Administratorzy muszą skonfigurować uprawnienia potoku, aby kontrolować, które potoki mogą uzyskiwać dostęp do poświadczeń.
   • Administratorzy muszą również skonfigurować kontrolę gałęzi, aby tylko potoki uruchomione w kontekście production gałęzi mogły używać polecenia prod-connection.

7. Repozytoria Git

   Ponieważ nasze połączenia z usługą są powiązane z gałęziami za pośrednictwem kontrolek gałęzi, niezwykle ważne jest skonfigurowanie uprawnień do repozytoriów Git i zastosowanie zasad gałęzi. Oprócz wymagania przekazywania kompilacji ciągłej integracji wymagamy również, aby żądania ściągnięcia miały co najmniej dwie osoby zatwierdzające.

Składniki

• Azure DevOps
• Tożsamość Microsoft Entra
• Azure Resource Manager
• Azure Repos
• Azure Pipelines

Alternatywy

Pojęcie kompleksowego ładu jest niezależne od dostawcy. Chociaż ten artykuł koncentruje się na usłudze Azure DevOps, serwer Usługi Azure DevOps może być używany jako lokalny zamiennik. Alternatywnie można również użyć zestawu technologii dla potoku programowania ciągłej integracji/ciągłego wdrażania typu open source przy użyciu opcji, takich jak Jenkins i GitLab.

Zarówno usługi Azure Repos, jak i GitHub to platformy, które są tworzone w celu korzystania z systemu kontroli wersji git typu open source. Chociaż ich zestawy funkcji są nieco inne, oba można zintegrować z globalnymi modelami ładu dla ciągłej integracji/ciągłego wdrażania. GitLab to kolejna platforma oparta na usłudze Git, która zapewnia niezawodne funkcje ciągłej integracji/ciągłego wdrażania.

W tym scenariuszu narzędzie Terraform jest używane jako narzędzie infrastruktury jako kodu (IaC). Alternatywy to Jenkins, Ansible i Chef.

Kwestie wymagające rozważenia

Aby osiągnąć kompleksowe zarządzanie na platformie Azure, ważne jest, aby zrozumieć profil zabezpieczeń i uprawnień ścieżki z komputera dewelopera do środowiska produkcyjnego. Na poniższym diagramie przedstawiono bazowy przepływ pracy ciągłej integracji/ciągłego wdrażania w usłudze Azure DevOps. Ikona czerwonej blokady wskazuje uprawnienia zabezpieczeń, które muszą być skonfigurowane przez użytkownika. Nieskonfigurowanie lub błędne konfigurowanie uprawnień spowoduje pozostawienie podatnych na zagrożenia obciążeń.

Pobierz plik SVG tego przepływu pracy.

Aby pomyślnie zabezpieczyć obciążenia, należy użyć kombinacji konfiguracji uprawnień zabezpieczeń i kontroli człowieka w przepływie pracy. Ważne jest, aby każdy model RBAC był również rozszerzany zarówno na potoki, jak i kod. Te operacje są często uruchamiane z uprzywilejowanymi tożsamościami i spowodują zniszczenie obciążeń, jeśli zostanie to poinstruowane. Aby temu zapobiec, należy skonfigurować zasady gałęzi w repozytorium, aby wymagać zatwierdzenia przez człowieka przed zaakceptowaniem zmian wyzwalających potoki automatyzacji.

Podczas projektowania modelu ładu należy wziąć pod uwagę następujące pojęcia i pytania. Należy pamiętać o potencjalnych przypadkach użycia tej przykładowej organizacji.

1. Ochrona środowisk za pomocą zasad gałęzi

Ponieważ kod źródłowy definiuje wdrożenia i wyzwala je, pierwszym wierszem obrony jest zabezpieczenie repozytorium zarządzania kodem źródłowym (SCM). W praktyce jest to osiągane przy użyciu przepływu pracy żądania ściągnięcia w połączeniu z zasadami gałęzi, które definiują kontrole i wymagania przed zaakceptowaniem kodu.

Podczas planowania kompleksowego modelu zapewniania ładu uprzywilejowani użytkownicy (veggies-admins) będą odpowiedzialni za konfigurowanie ochrony gałęzi. Typowe kontrole ochrony gałęzi używane do zabezpieczania wdrożeń obejmują:

• Wymagaj przekazania kompilacji ciągłej integracji. Przydatne do ustanawiania jakości kodu bazowego, takich jak linting kodu, testy jednostkowe, a nawet testy bezpieczeństwa, takie jak skanowanie wirusów i poświadczeń.

• Wymagaj przeglądu równorzędnego. Sprawdź, czy kod działa zgodnie z oczekiwaniami. Podczas wprowadzania zmian w kodzie potoku należy zachować szczególną ostrożność. Połącz z kompilacjami ciągłej integracji, aby przeglądy równorzędne mniej żmudne.

Co się stanie, jeśli deweloper spróbuje wypchnąć bezpośrednio do środowiska produkcyjnego?

Pamiętaj, że usługa Git jest rozproszonym systemem SCM. Deweloper może zatwierdzić bezpośrednio w swojej gałęzi lokalnej production . Jednak gdy usługa Git jest prawidłowo skonfigurowana, takie wypychanie zostanie automatycznie odrzucone przez serwer Git. Na przykład:

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'

Należy pamiętać, że przepływ pracy w przykładzie jest niezależny od dostawcy. Funkcje żądania ściągnięcia i ochrony gałęzi są dostępne u wielu dostawców SCM, w tym usług Azure Repos, GitHub i GitLab.

Po zaakceptowaniu kodu w gałęzi chronionej kolejna warstwa kontroli dostępu zostanie zastosowana przez serwer kompilacji (np . Azure Pipelines).

2. Jakiego dostępu potrzebują podmioty zabezpieczeń?

Na platformie Azure podmiot zabezpieczeń może być podmiotem zabezpieczeń lub podmiotem zabezpieczeń bez nagłówka, takim jak jednostka usługi lub tożsamość zarządzana. We wszystkich środowiskach podmioty zabezpieczeń powinny przestrzegać zasady najniższych uprawnień. Chociaż podmioty zabezpieczeń mogły mieć rozszerzony dostęp w środowiskach przedprodukcyjnych, produkcyjne środowiska platformy Azure powinny zminimalizować stałe uprawnienia, faworyzując dostęp just in time (JIT) i dostęp warunkowy firmy Microsoft Entra. Utwórz przypisania ról RBAC platformy Azure dla podmiotów zabezpieczeń użytkowników, aby dopasować je do tych podmiotów z najniższymi uprawnieniami.

Ważne jest również, aby modelować kontrolę dostępu opartą na rolach platformy Azure w sposób odrębny od kontroli dostępu opartej na rolach usługi Azure DevOps. Celem potoku jest zminimalizowanie bezpośredniego dostępu do platformy Azure. Z wyjątkiem przypadków specjalnych, takich jak innowacje, uczenie się i rozwiązywanie problemów, większość interakcji z platformą Azure powinna być prowadzona za pomocą specjalnie utworzonych i ogrodzonych potoków.

W przypadku jednostek usługi Azure Pipeline rozważ użycie roli niestandardowej, która uniemożliwia usunięcie blokad zasobów i wykonanie innych destrukcyjnych akcji poza zakresem.

3. Utwórz rolę niestandardową dla jednostki usługi używanej do uzyskiwania dostępu do środowiska produkcyjnego

Typowym błędem jest nadanie agentom kompilacji ciągłej integracji/ciągłego wdrażania roli właściciela i uprawnień. Uprawnienia współautora nie są wystarczające, jeśli potok musi również wykonywać przypisania ról tożsamości lub inne uprzywilejowane operacje, takie jak zarządzanie zasadami usługi Key Vault.

Jednak agent kompilacji ciągłej integracji/ciągłego wdrażania usunie całe środowisko produkcyjne, jeśli zostanie to powiedziane. Aby uniknąć nieodwracalnych zmian destrukcyjnych, tworzymy rolę niestandardową, która:

• Usuwa zasady dostępu usługi Key Vault
• Usuwa blokady zarządzania, które zgodnie z projektem powinny uniemożliwiać usuwanie zasobów (typowe wymaganie w branżach regulowanych)

W tym celu utworzymy rolę niestandardową i usuniemy Microsoft.Authorization/*/Delete akcje.

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

Jeśli spowoduje to usunięcie zbyt wielu uprawnień do Twoich celów, zapoznaj się z pełną listą w oficjalnej dokumentacji dotyczącej operacji dostawcy zasobów platformy Azure i dostosuj definicję roli zgodnie z potrzebami.

Wdrażanie tego scenariusza

Ten scenariusz wykracza poza usługę Resource Manager. Dlatego używamy narzędzia Terraform, który umożliwia nam również tworzenie podmiotów zabezpieczeń w usłudze Microsoft Entra ID i bootstrap usługi Azure DevOps przy użyciu pojedynczej infrastruktury jako narzędzia kodu.

Aby uzyskać kod źródłowy i szczegółowe instrukcje, odwiedź witrynę Governance repozytorium GitHub na platformie Azure Demo — od devOps do usługi ARM.

Cennik

Koszty usługi Azure DevOps zależą od liczby użytkowników w organizacji, którzy wymagają dostępu, wraz z innymi czynnikami, takimi jak liczba wymaganych współbieżnych kompilacji/wydań i liczba użytkowników. Usługi Azure Repos i Azure Pipelines to funkcje usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure DevOps.

W usłudze Microsoft Entra ID typ zarządzania dostępem do grupy wymagany w tym scenariuszu jest dostępny w wersjach Premium P1 i Premium P2. Ceny tych warstw są obliczane dla poszczególnych użytkowników. Aby uzyskać więcej informacji, zobacz Microsoft Entra pricing.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• Julie Ng | Starszy inżynier ds. usług

Następne kroki

• Odwiedź repozytorium kodu dla tego scenariusza w artykule Governance on Azure Demo — from DevOps to ARM (Governance on Azure Demo — from DevOps to ARM ( Governance on Azure Demo — from DevOps to ARM (Zarządzanie na platformie Azure — pokaz — od devOps do usługi ARM).
• Zapoznaj się z przewodnikami dotyczącymi ładu w chmurze przewodnika Cloud Adoption Framework.
• Co to jest kontrola dostępu oparta na rolach na platformie Azure (Azure RBAC)?
• Cloud Adoption Framework: zarządzanie dostępem do zasobów na platformie Azure
• Role usługi Azure Resource Manager
  • Właściciel (wbudowany)
  • Współautor (wbudowany)
  • Czytelnik (wbudowany)
  • Rola niestandardowa
• Grupy zabezpieczeń usługi Azure DevOps
  • Administratorzy projektu
  • Współautor
  • Czytelnik

Powiązane zasoby

• Projektowanie potoku ciągłej integracji/ciągłego wdrażania przy użyciu usługi Azure DevOps
• Łańcuch nadzoru śledczego komputerów na platformie Azure
• Hybrydowe zarządzanie i wdrażanie usługi Azure Arc dla klastrów Kubernetes
• Przeglądanie architektur platformy Azure — ciągła integracja/ciągłe wdrażanie