Udostępnij za pośrednictwem


Automatyzacja stref docelowych platformy Azure w różnych dzierżawach

Jeśli Twoja organizacja ma wiele dzierżaw Microsoft Entra ze strefami docelowymi platformy Azure (ALZ) w każdej z nich i są one wykorzystywane jednorazowo lub wielokrotnie, kluczowa jest automatyzacja. Automatyzacja pomaga pomyślnie obsługiwać i utrzymywać wdrożenie ALZ na szeroką skalę we wszystkich dzierżawach. Istnieje wiele podejść do automatyzowania wdrożeń ALZ u różnych dzierżawców. Podejście, które wybierasz, zależy od powodów, dla których twoja organizacja ma wiele tenantów Microsoft Entra.

Na przykład możesz mieć wiele dzierżaw Microsoft Entra, jeśli jesteś niezależnym dostawcą oprogramowania. Prawdopodobnie chcesz zachować oddzielne dzierżawy Microsoft Entra dla rozwiązań korporacyjnych i SaaS. Ryzyko operacji lub wdrożenia mającego wpływ na inną dzierżawę, niezależnie od tego, czy jest to zamierzone, czy przez pomyłkę, zmniejsza się.

W poniższych sekcjach przedstawiono diagramy i wskazówki dotyczące metod, które można wykonać. Wybierz, które podejście jest najlepsze dla Ciebie na podstawie wymagań, zagadnień i zaleceń dotyczących automatyzowania wdrożeń stref docelowych platformy Azure podczas obsługi wielu dzierżaw firmy Microsoft Entra.

Notatka

Najpierw zapoznaj się z następującymi artykułami, aby zapoznać się z omówieniem dzierżaw firmy Microsoft Entra:

Podejścia

Istnieją dwa podejścia do automatyzacji wdrażania stref docelowych platformy Azure w wielu dzierżawach firmy Microsoft Entra.

Podejście 1 — kompletna izolacja jest najbardziej typowym podejściem w scenariuszach wielodostępnych. Takie podejście zapewnia wymaganą separację i izolację między dzierżawami firmy Microsoft Entra, co jest najczęstszym wymaganiem w przypadku korzystania z wielodostępnego podejścia.

Podejście 2 — rejestracja aplikacji współużytkowanej (wielodostępna) z wieloma jednostkami usługi jest często używana w scenariuszach dostawcy usług zarządzanych (MSP). W tym podejściu wzorzec szablonu wdrażania może służyć do automatyzacji wdrażania niemal identycznej architektury w wielu dzierżawcach w szerokim zakresie.

Oba te podejścia są dostarczane jako przykłady i inspiracja. Możesz mieszać i dopasowywać podejścia we wdrożeniach na podstawie wymagań organizacji.

Ważny

W tym artykule opisano automatyzację wdrażania i funkcjonowania stref docelowych Azure jako platformy w każdej dzierżawie Microsoft Entra, posiadanej przez Twoją organizację. Podejścia, zalecenia i zagadnienia w tym artykule nie są przeznaczone do użycia przez zespoły aplikacji, które wdrażają i obsługują swoje usługi i aplikacje w swoich strefach docelowych (subskrypcje). Aby uzyskać więcej informacji na temat różnych typów obszarów docelowych, zobacz Platforma kontra obszary docelowe aplikacji.

Podejście 1 — kompletna izolacja

W tym podejściu głównym celem jest zapewnienie pełnej izolacji każdego tenantu Microsoft Entra we wszystkich składnikach automatyzacji, takich jak:

  • Repozytorium Git.
  • Funkcja GitHub Actions lub usługa Azure Pipelines (w tym moduły uruchamiane samodzielnie, jeśli są używane).
  • Tożsamości używane do wykonywania zadań z automatyzacji, takich jak tożsamości zarządzane przypisane do własnych modułów uruchamiających, nazwy główne usługi (SPN), użytkownicy lub administratorzy.

Diagram wielu dzierżaw Microsoft Entra ze strefami docelowymi platformy Azure wdrożonymi z użyciem pełnego podejścia do automatyzacji izolacji.

W tym podejściu istnieje więcej składników do zarządzania, które są zduplikowane dla każdego dzierżawcy usługi Microsoft Entra. Niektóre organizacje mogą mieć wymuszane mechanizmy kontroli zgodności z przepisami, które wymuszają tego typu segregację i izolację.

Notatka

Jeśli Wasza organizacja zezwala tylko na korzystanie z tożsamości zarządzanych do automatyzacji platformy, należy użyć tego podejścia lub podejścia, które loguje się do każdego dzierżawcy indywidualnie. Tożsamości zarządzane nie obsługują obecnie scenariuszy obejmujących wiele dzierżaw w stanie ogólnie dostępnym. Aby uzyskać więcej informacji, zobacz często zadawanych pytań.

Jest teraz dostępne w publicznej wersji zapoznawczej dla zarządzanych tożsamości User-Assigned poprzez skonfigurowanie zaufania między nimi a wielodostępną aplikacją Entra ID. Zobacz więcej informacji na temat konfigurowania tej funkcji w Konfigurowanie aplikacji w celu zaufania tożsamości zarządzanej (wersja zapoznawcza). Może to teraz sprawić, że Podejście 2 — rejestracja aplikacji (wielodostępnej) z wieloma głównymi jednostkami usługi stanie się realną opcją dla wdrożenia.

Tożsamości dla administratorów i deweloperów platformy — podejście 1

W tym podejściu tożsamości powinny być również odizolowane w każdej dzierżawie firmy Microsoft Entra, co oznacza, że każdy administrator platformy lub deweloper wymaga oddzielnego konta użytkownika w każdej dzierżawie do wykonywania operacji w ramach tej dzierżawy. Te konta są również używane do dostępu do narzędzi deweloperskich, takich jak GitHub lub Azure DevOps, dla każdego dzierżawcy. Uważnie zastanów się nad skutkami produktywności administratorów i deweloperów zgodnie z tym podejściem.

Można użyć usługi Microsoft Entra B2B i/lub Azure Lighthouse, ale ta opcja podnosi pytanie o sens posiadania oddzielnych dzierżaw Microsoft Entra.

Podejście 2 — rejestracja aplikacji udostępnionej (wielodostępna) z wieloma jednostkami usługi

W tym podejściu rejestracja aplikacji jest tworzona w dzierżawie zarządzanej przez Microsoft Entra. W każdej dzierżawie firmy Microsoft Entra, którą chcesz zarządzać, w tej dzierżawie jest tworzona główna nazwa usługi (SPN) na podstawie rejestracji aplikacji. Ta akcja umożliwia pracownikom uruchamiającym zadania i kroki potoku logowanie się do dowolnej dzierżawy Microsoft Entra przy użyciu jednego zestawu poświadczeń.

Napiwek

Aby uzyskać informacje na temat relacji między rejestracjami aplikacji a aplikacjami dla przedsiębiorstw (obiektami zasad usługi), zobacz Obiekty aplikacji i zasad usługi w Microsoft Entra ID.

Diagram wielu dzierżaw firmy Microsoft Entra ze strefami docelowymi platformy Azure wdrożonych przy użyciu rejestracji aplikacji udostępnionej (wielodostępnej) z wieloma jednostkami usługi automatyzacji.

Ważny

W tym podejściu rejestracja pojedynczej aplikacji i skojarzone aplikacje dla przedsiębiorstw (jednostki usługi) powinny być monitorowane pod kątem wszelkich nietypowych działań w narzędziach do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM), ponieważ jest to wysoce uprzywilejowane konto. Powinien wysyłać alerty i potencjalnie automatycznie podejmować działania w zależności od ważności alertu.

W poprzednim przykładzie, rejestracja pojedynczej aplikacji znajduje się w dzierżawie contoso.onmicrosoft.com Microsoft Entra, a aplikacja biznesowa znajduje się w każdej dzierżawie Microsoft Entra połączonej z rejestracją aplikacji. Ta konfiguracja umożliwia potokowi uwierzytelnianie i autoryzację we wszystkich dzierżawach Microsoft Entra, korzystając z pojedynczej rejestracji aplikacji. Aby uzyskać więcej informacji, zobacz Tworzenie aplikacji wielodostępnej oraz Przyznanie zgody administracyjnej dla najemcy na aplikację.

Napiwek

Zarządzane tożsamości przypisane użytkownikowi, które są w publicznej wersji zapoznawczej, mogą teraz obsługiwać scenariusze wielodzierżawcze, konfigurując relację zaufania między sobą a wielodostępną aplikacją Entra ID. Zobacz więcej informacji na temat konfigurowania tej funkcji w Konfigurowanie aplikacji w celu zaufania tożsamości zarządzanej (wersja zapoznawcza).

Korzystając ze scentralizowanego potoku, możesz potrzebować utworzenia małej tabeli odwzorowania zawierającej dane korelujące dzierżawy usługi Microsoft Entra oraz inne metadane, takie jak środowisko, powiązane subskrypcje, nazwa organizacji i identyfikator obiektu tożsamości wykorzystywany do uwierzytelniania i autoryzacji. Te dane mogą być wywoływane podczas uruchamiania potoku w kroku, który używa pewnej logiki i warunków do kontrolowania, do którego dzierżawcy Microsoft Entra jest wdrażany i z jakimi tożsamościami. Dane mogą być przechowywane w usługach, takich jak Azure Cosmos DB lub Azure Table Storage.

W przypadku obsługi wielu środowisk, takich jak rozwój, testowanie lub produkcja, można je kontrolować w ten sam sposób, używając tych samych lub oddzielnych rejestracji aplikacji oraz aplikacji korporacyjnych z potokami.

Możesz zdecydować się na oddzielne potoki dla każdej usługi Microsoft Entra lub użyć jednego potoku. Wybór zależy od Twoich wymagań.

Notatka

Usługa Azure Lighthouse działa podobnie do tego podejścia, ale usługa Azure Lighthouse nie zezwala na przypisanie właściciela RBAC, administratora dostępu użytkowników i ról z uprawnieniami DataActions. Aby uzyskać więcej informacji, zobacz Obsługa ról dla usługi Azure Lighthouse.

Role dostępu właściciela i użytkownika są zwykle wymagane we wszystkich scenariuszach wdrażania strefy docelowej platformy Azure. To wymaganie eliminuje usługę Azure Lighthouse jako opcję dla całego aspektu wdrażania automatyzacji platformy w strefach docelowych platformy Azure, ale nadal jest to przydatne w niektórych scenariuszach. Aby uzyskać więcej informacji, zobacz użycie usługi Azure Lighthouse w wielodostępnymALZ.

Tożsamości dla administratorów i programistów platformy — Podejście 2

W tym podejściu administratorzy platformy i deweloperzy zwykle potrzebują tylko dostępu do dzierżawy zarządzanej przez Microsoft Entra. Ten dostęp daje im dostęp do narzędzi deweloperskich, takich jak GitHub lub Azure DevOps, które są wdrażane i obsługiwane przez wszystkie dzierżawy.

Mogą oni mieć dostęp do innych dzierżaw firmy Microsoft Entra za pośrednictwem usługi Microsoft Entra B2B lub Azure Lighthouse. Używają tego samego konta z dzierżawy zarządzającej lub mogą mieć oddzielne konta, takie jak przykład w pierwszym podejściu.

Następne kroki