Metoda testowania dla strefy docelowej Azure

Niektóre organizacje mogą chcieć przetestować wdrożenie akceleratora strefy docelowej platformy w zakresie definicji i przypisań usługi Azure Policy, ról niestandardowych i przypisań kontroli dostępu opartej na rolach (RBAC) i tak dalej. 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 akceleratora strefy docelowej platformy.

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 je połączyć ze wskazówkami zawartymi w artykule Wdrażanie barier zabezpieczających opartych na zasadach dotyczących technik wdrażania zmian zasad we wdrożeniu strefy docelowej platformy.

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

Wskazówki dotyczące stref docelowych platformy Azure pomagają projektować i wdrażać wymagane składniki platformy Azure, które umożliwiają tworzenie i eksploatację 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 grup zarządzania produkcyjnej strefy docelowej platformy Azure została zduplikowana pod elementem Tenant Root Group. Nazwa kanary jest dołączana do nazw wyświetlanych i identyfikatorów grupy zarządzania. Identyfikatory grup zarządzania muszą być unikatowe w ramach jednej dzierżawy Microsoft Entra. Dzierżawca traktuje identyfikatory grup zarządzania jako identyfikatory nadrzędne, więc muszą one być unikatowe w jego obrębie. Możesz utrzymać nazwy wyświetlane grup zarządzania w zgodności z hierarchią produkcyjnych grup zarządzania. Dodaj również rozróżnienie w wyświetlanych nazwach, aby użytkownicy mogli wizualnie odróżnić hierarchię kanarkową od hierarchii produkcyjnej podczas poruszania się po drzewie grup zarządzania.

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 znajdują się wskazówki dotyczące wdrażania i używania hierarchii grup zarządzania dla testowej strefy docelowej platformy Azure obok produkcyjnej hierarchii grup zarządzania dla strefy docelowej platformy Azure.

1. Użyj oddzielnych jednostek usługi Microsoft Entra (SPN) lub tożsamości zarządzanych (MI), którym przyznano uprawnienia do odpowiedniej hierarchii grup zarządzania strefą docelową platformy Azure dla środowiska produkcyjnego lub kanarkowego.
   • 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 kanarowego Azure wdrożenia strefy docelowej.
   • 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. Przygotuj zestaw przykładowych architektur obciążeń, które można wdrożyć w subskrypcjach kanarkowych w środowisku kanarkowym, aby przetestować zmiany w Azure Policy i mechanizmie kontroli dostępu opartej na rolach (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ń 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 zespołom odpowiedzialnym za obciążenia, rozważ również wdrożenie ich w środowisku canary. 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 ze wszystkich subskrypcji platformy Azure, w tym z subskrypcji środowisk typu canary, do obszaru roboczego usługi Azure Log Analytics w środowisku produkcyjnym zgodnie z zaleceniami projektowymi usługi Azure Landing Zone.
   • 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 jednej dzierżawy jest zgodne z zaleceniami dotyczącymi projektowania strefy docelowej Azure dla dzierżaw Microsoft Entra.
  • W ramach jednej dzierżawy Microsoft Entra można używać różnych grup Microsoft Entra zarówno dla produkcyjnych, jak i testowych środowisk stref docelowych platformy Azure, przy czym ci sami użytkownicy są przypisani 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 utrudnienia i czas potrzebny na wdrożenie zmian we wdrożeniu strefy docelowej platformy Azure.

Następne kroki

Po wdrożeniu środowiska kanarkowego możesz rozpocząć testowanie zmian w Azure Policy i RBAC przed wdrożeniem ich w hierarchii grup zarządzania produkcyjnej strefy docelowej platformy Azure.

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 sandbox do użycia przez zespoły odpowiedzialne za obciążenia podczas opracowywania i testowania swoich obciążeń. Jest to koncepcja odrębna od środowiska kanarowego i służy do zapewnienia bezpiecznego środowiska, w którym zespoły odpowiedzialne za obciążenia mogą tworzyć i testować swoje obciążenia przed wdrożeniem ich do środowiska produkcyjnego.