Metoda testowania dla stref docelowych platformy Azure

Niektóre organizacje mogą chcieć przetestować definicje i przypisania zasad platformy Azure we wdrożeniu stref początkowych, niestandardowe role i przypisania kontroli dostępu opartej na rolach (RBAC) oraz inne elementy. Testy można wykonać za pośrednictwem automatyzacji przy użyciu szablonów usługi Azure Resource Manager (szablonów usługi ARM), programu Terraform, Bicep lub ręcznie za pośrednictwem witryny Azure Portal. Te wskazówki zawierają podejście, które może służyć do testowania zmian i ich wpływu na wdrożenie platformy stref docelowych platformy Azure.

Ten artykuł może być również używany razem z poradami dotyczącymi automatyzacji platformy i krytycznego obszaru projektowania DevOps w odniesieniu do zespołów PlatformOps i zadań związanych z funkcjami centralnymi. Ponadto można ją połączyć ze wskazówkami w artykule Wdrażanie barier zabezpieczających opartych na zasadach dotyczących technik wdrażania zmian zasad we wdrożeniu stref docelowych platformy Azure.

Te wskazówki są najbardziej odpowiednie dla organizacji z niezawodnymi procesami zarządzania zmianami zarządzającymi zmianami w hierarchii grup zarządzania produkcyjnego. Hierarchia grupy zarządzania kanarkiem może być używana niezależnie do tworzenia i testowania wdrożeń przed ich wdrożeniem w środowisku produkcyjnym.

Definicja platformy

Strefy docelowe platformy Azure ułatwiają projektowanie i wdrażanie wymaganych składników platformy Azure, aby umożliwić tworzenie i operacjonalizacja stref docelowych na dużą skalę.

Zasoby platformy w zakresie tego artykułu i to podejście do testowania są następujące:

Przykładowe scenariusze i wyniki

Przykładem tego scenariusza jest organizacja, która chce przetestować wpływ i wynik nowej usługi Azure Policy w celu zarządzania zasobami i ustawieniami we wszystkich strefach docelowych zgodnie z zasadą projektowania ładu opartego na zasadach. Nie chcą wprowadzać tej zmiany bezpośrednio w środowisku produkcyjnym, ponieważ obawiają się wpływu, jaki może mieć.

Testowanie tej zmiany platformy przy użyciu środowiska kanarowego umożliwi organizacji zaimplementowanie i przejrzenie wpływu i wyniku zmiany usługi Azure Policy. Ten proces zapewni spełnienie wymagań organizacji przed wdrożeniem usługi Azure Policy w środowisku produkcyjnym.

Podobny scenariusz może być zmianą przypisań ról RBAC platformy Azure i członkostwa w grupach firmy Microsoft Entra. Może to wymagać formy testowania przed wprowadzeniem zmian w środowisku produkcyjnym.

Rysunek 1. Hierarchia grup zarządzania Kanary.

Jak pokazano na diagramie, cała hierarchia produkcyjnych grup zarządzania strefami docelowymi platformy Azure zostaje zduplikowana w obszarze Tenant Root Group. Nazwa kanary jest dołączana do nazw wyświetlanych i identyfikatorów grupy zarządzania. Identyfikatory muszą być unikatowe w ramach jednej dzierżawy firmy Microsoft Entra.

Hierarchia grup zarządzania kanarka jest następnie wykorzystywana do uproszczenia testowania następujących typów zasobów:

• Grupy zarządzania
  • Umieszczanie subskrypcji
• Kontrola dostępu oparta na rolach (RBAC)
  • Role (wbudowane i niestandardowe)
  • Przypisania
• Azure Policy
  • Definicje (wbudowane i niestandardowe)
  • Inicjatywy, znane również jako definicje zestawów
  • Przypisania

Co jeśli nie chcesz wdrażać hierarchii grup zarządzania typu canary?

Jeśli nie chcesz wdrażać hierarchii grup zarządzania w wersji kanarkowej, możesz przetestować zasoby platformy w hierarchii środowiska produkcyjnego, używając subskrypcji sandbox, jak pokazano na diagramie.

Rysunek 2. Hierarchia grup zarządzania stref docelowych platformy Azure z wyróżnionymi piaskownicami.

Aby przetestować Azure Policy i RBAC w tym scenariuszu, potrzebujesz jednej subskrypcji platformy Azure z przypisaną rolą Owner w RBAC do tożsamości, w której chcesz przeprowadzać testowanie, na przykład konto użytkownika, zasadę usługi lub zarządzaną tożsamość usługi. Ta konfiguracja umożliwia tworzenie, przypisywanie i korygowanie definicji i przypisań usługi Azure Policy tylko w zakresie subskrypcji piaskownicy.

Podejście piaskownicy może być również wykorzystywane do testowania RBAC w ramach subskrypcji, na przykład gdy tworzysz nową niestandardową rolę RBAC w celu przyznania uprawnień dla określonego przypadku użycia. Te testy można wykonać w ramach subskrypcji piaskownicy i przetestować przed utworzeniem i przypisaniem ról wyższych w hierarchii.

Zaletą tego podejścia jest to, że subskrypcje piaskownicy mogą być używane przez czas wymagany, a następnie usuwane ze środowiska.

Jednak takie podejście nie umożliwia testowania dziedziczenia mechanizmu kontroli dostępu opartego na rolach (RBAC) i zasad platformy Azure w hierarchii grup zarządzania.

Wskazówki dotyczące implementacji

Poniżej przedstawiono wskazówki dotyczące implementowania i korzystania z hierarchii grup zarządzania kanarkowej dla stref lądowania Azure, obok hierarchii grup zarządzania stref lądowania Azure w środowisku produkcyjnym.

1. Używaj oddzielnych jednostek usługi Microsoft Entra (SPN) lub zarządzanych tożsamości (MI), które mają przyznane uprawnienia do odpowiedniego środowiska produkcyjnego lub kanarowego, w hierarchii grup zarządzania strefami docelowymi platformy Azure.
   • Niniejsze wytyczne są zgodne z zasadą najmniejszych uprawnień (PoLP)
2. Użyj oddzielnych folderów w repozytorium Git, gałęziach lub repozytoriach, aby przechowywać IaC dla środowiska produkcyjnego i środowiska canary przy wdrażaniu stref landing zones na platformie Azure.
   • Korzystanie z odpowiednich jednostek usługowych Microsoft Entra (SPN) lub tożsamości zarządzanych (MI) w ramach potoków CI/CD, w zależności od wdrażanej hierarchii.
3. Zaimplementuj zasady gałęzi git lub zabezpieczenia dla środowiska testowego (canary), tak jak masz to wdrożone w środowisku produkcyjnym.
   • Rozważ zmniejszenie liczby osób zatwierdzających i liczby kontroli, aby szybko wykrywać awarie w środowisku kanarkowym.
4. Użyj tych samych akcji usługi Azure Pipelines lub GitHub, które używają zmiennych środowiskowych, aby zmienić, która hierarchia jest wdrażana. Inną opcją jest sklonowanie potoków i zmianę zakodowanych ustawień w celu zdefiniowania, która hierarchia jest wdrażana.
   • Korzystanie z szablonów devOps usługi Azure Pipelines lub szablonów przepływów pracy funkcji GitHub Actions pomoże Ci przestrzegać zasady Nie powtarzaj siebie (DRY).
5. Miej zestaw subskrypcji kanarkowych w ramach oddzielnego konta rozliczeniowego, na przykład w sekcji faktury Umowy Enterprise Agreement (EA) lub umowy z Klientem Microsoft (MCA), które można przenosić w razie potrzeby w hierarchii grup zarządzania kanarkowego.
   • Może być korzystne, aby zestaw zasobów był zawsze wdrażany w subskrypcjach środowiska kanarkowego, co pozwoli na przyspieszenie testów i walidacji zmian w tym środowisku.
6. Posiadaj zestaw przykładowych architektur obciążeń aplikacji, które można wdrożyć w subskrypcjach kanału w środowisku kanałowym, aby przetestować zmiany w Azure Policy i RBAC. To pomaga zweryfikować zmiany przed ich wdrożeniem i wprowadzeniem do środowiska produkcyjnego.
   • Te przykładowe obciążenia można wdrożyć przy użyciu tych samych szablonów IaC, które są używane do wdrażania obciążeń aplikacji produkcyjnych. Pomoże to upewnić się, że środowisko kanary jest zsynchronizowane ze środowiskiem produkcyjnym i że testowane zmiany są prawidłowe i mają zastosowanie do środowiska produkcyjnego.
   • Należy stale przeglądać i aktualizować przykładowe obciążenia, aby upewnić się, że są one odpowiednie i aktualne z najnowszymi wzorcami architektury i projektowania w organizacji.
   • Jeśli udostępniasz architektury referencyjne do zespołów aplikacji, rozważ wdrożenie ich również w środowisku kanarowym. Pomaga to zweryfikować zmiany w architekturach referencyjnych i upewnić się, że mają one zastosowanie do środowiska produkcyjnego.
7. Wyślij wszystkie dzienniki aktywności platformy Azure dla wszystkich subskrypcji platformy Azure, w tym wszystkich subskrypcji środowiska kanarkowego, do obszaru roboczego usługi Azure Log Analytics w środowisku produkcyjnym zgodnie z zaleceniami projektowymi stref docelowych platformy Azure.
   • Ułatwia to zespołom ds. bezpieczeństwa i operacji monitorowanie środowiska kanarowego pod kątem wszelkich zmian lub problemów, które mogą wynikać z testowania Azure Policy i zmian RBAC (kontroli dostępu opartej na rolach) w środowisku produkcyjnym.

Korzystanie z jednego dzierżawcy Microsoft Entra

Należy wziąć pod uwagę następujące zagadnienia przy korzystaniu z jednej dzierżawy Microsoft Entra:

• Korzystanie z pojedynczej dzierżawy jest zgodne z zaleceniami dotyczącymi projektowania stref docelowych platformy Azure dla dzierżaw Microsoft Entra.
  • W jednej dzierżawie Microsoft Entra można używać różnych grup Microsoft Entra zarówno dla środowisk produkcyjnych, jak i kanarycznych stref docelowych platformy Azure, przypisując tych samych użytkowników do odpowiedniej hierarchii grup zarządzania.
• Zwiększone lub zduplikowane koszty licencjonowania identyfikatora Entra firmy Microsoft ze względu na wiele tożsamości w różnych dzierżawach firmy Microsoft Entra. Jest to szczególnie istotne dla klientów korzystających z funkcji Microsoft Entra ID P1 lub P2.
• Zmiany w kontroli dostępu opartej na rolach są bardziej złożone zarówno w środowiskach kanaryjnych, jak i produkcyjnych, ponieważ prawdopodobnie użytkownicy i grupy nie są identyczne w obu dzierżawach Microsoft Entra.
  • Należy wziąć pod uwagę, że identyfikatory użytkowników i grup nie będą takie same w dzierżawach firmy Microsoft Entra, ponieważ są one globalnie unikatowe.
• Zmniejsza złożoność i nakład pracy związany z zarządzaniem wieloma dzierżawami firmy Microsoft Entra.
  • Uprzywilejowani użytkownicy, którzy muszą zachować dostęp i zalogować się do oddzielnych dzierżaw w celu przeprowadzenia testów, mogą wprowadzać przypadkowe zmiany w środowisku produkcyjnym zamiast w środowisku kanarowym, na przykład.
• Zmniejsza prawdopodobieństwo dryfu konfiguracji i niepowodzeń wdrażania.
• Nie wymaga utworzenia dodatkowych procesów zabezpieczeń ani procesów typu break-glass, ani awaryjnego dostępu.
• Zmniejsza tarcie i czas wymagany do wdrożenia zmian w strefach docelowych platformy Azure.

Następne kroki

Po utworzeniu środowiska testowego typu canary, możesz rozpocząć testowanie zmian Azure Policy i RBAC przed ich wdrożeniem w produkcyjnej hierarchii grup zarządzania Azure landing zones.

Po przetestowaniu zmian w zasadach platformy Azure w środowisku kanarkowym, można je następnie przenieść do środowiska produkcyjnego zgodnie z tym samym podejściem, które opisano w wytycznych dotyczących barier zabezpieczających opartych na zasadach. Odbywa się to przy użyciu funkcji trybu wymuszania przypisań zasad. Korzystając z podejścia opisanego w tych wskazówkach, można przejść przez dodatkową fazę testowania przed wymuszeniem usługi Azure Policy w środowisku produkcyjnym w pożądanym efekcie, co pomoże Ci w budowaniu zaufania do wprowadzania zmian w usłudze Azure Policy.

Możesz również przejrzeć środowiska piaskownicy dla zespołów aplikacji, które będą używane do tworzenia i testowania obciążeń. Jest to odrębna koncepcja od środowiska kanarowego i służy do zapewnienia bezpiecznego otoczenia dla zespołów zajmujących się aplikacjami w celu opracowywania i testowania swoich zadań przed ich wdrożeniem na produkcję.