Podstawy zarządzania zasobami platformy Azure
Ważne jest, aby zrozumieć strukturę i terminy specyficzne dla zasobów platformy Azure. Na poniższej ilustracji przedstawiono przykład czterech poziomów zakresu udostępnianych przez platformę Azure:
Terminologia
Poniżej przedstawiono niektóre terminy, które należy znać:
Zasób — to dostępny za pośrednictwem platformy Azure element, którym można zarządzać. Przykładami zasobów są maszyny wirtualne, konta magazynu, aplikacje internetowe, bazy danych i sieci wirtualne.
Grupa zasobów — kontener, który zawiera powiązane zasoby dla rozwiązania platformy Azure, takie jak kolekcja maszyn wirtualnych, skojarzone sieci wirtualne i moduły równoważenia obciążenia, które wymagają zarządzania przez określone zespoły. Grupa zasobów zawiera te zasoby, którymi chcesz zarządzać jako grupa. Należy zdecydować, które zasoby należą do grupy zasobów, w oparciu o to, co jest najrozsądniejsze dla Twojej organizacji. Grupy zasobów mogą również pomóc w zarządzaniu cyklem życia przez usunięcie wszystkich zasobów, które mają tę samą żywotność jednocześnie. Takie podejście zapewnia również korzyści bezpieczeństwa, pozostawiając nie fragmentów, które mogą być wykorzystywane.
Subskrypcja — z perspektywy hierarchii organizacyjnej subskrypcja jest kontenerem rozliczeń i zarządzania zasobami i grupami zasobów. Subskrypcja platformy Azure jest połączona relacją zaufania z usługą Microsoft Entra ID. Subskrypcja „ufa”, że usługa Microsoft Entra ID będzie uwierzytelniać użytkowników, usługi i urządzenia.
Uwaga
Subskrypcja może ufać tylko jednej dzierżawie firmy Microsoft Entra. Jednak każda dzierżawa może ufać wielu subskrypcjom i subskrypcjom można przenosić między dzierżawami.
Grupy zarządzania platformy - Azure zapewniają hierarchiczną metodę stosowania zasad i zgodności w różnych zakresach powyżej subskrypcji. Może to być grupa zarządzania głównego dzierżawy (najwyższy zakres) lub na niższych poziomach w hierarchii. Subskrypcje są organizowane w kontenerach nazywanych „grupami zarządzania”, do których należy zastosować swoje warunki nadzoru. Wszystkie subskrypcje w grupie zarządzania automatycznie dziedziczą warunki zastosowane do tej grupy zarządzania. Należy pamiętać, że definicje zasad można zastosować do grupy zarządzania lub subskrypcji.
Dostawca zasobów — usługa dostarczająca zasoby platformy Azure. Na przykład typowym dostawcą zasobów jest firma Microsoft. Środowisko obliczeniowe, które dostarcza zasób maszyny wirtualnej. Microsoft. Magazyn to inny wspólny dostawca zasobów.
Szablon usługi Resource Manager — plik JavaScript Object Notation (JSON), który definiuje co najmniej jeden zasób do wdrożenia w grupie zasobów, subskrypcji, dzierżawie lub grupie zarządzania. Szablon może służyć do spójnego i wielokrotnego wdrażania zasobów. Zobacz Omówienie wdrażania szablonu. Ponadto można użyć języka Bicep zamiast kodu JSON.
Model zarządzania zasobami platformy Azure
Każda subskrypcja platformy Azure jest skojarzona z kontrolkami używanymi przez usługę Azure Resource Manager. Usługa Resource Manager to usługa wdrażania i zarządzania dla platformy Azure, ma relację zaufania z identyfikatorem Entra firmy Microsoft na potrzeby zarządzania tożsamościami w organizacjach oraz kontem Microsoft (MSA) dla użytkowników indywidualnych. Usługa Resource Manager udostępnia warstwę zarządzania, która umożliwia tworzenie, aktualizowanie i usuwanie zasobów w ramach subskrypcji platformy Azure. Funkcje zarządzania, takie jak kontrola dostępu, blokady i tagi, umożliwiają zabezpieczanie i organizowanie zasobów po wdrożeniu.
Uwaga
Przed usługą ARM istniał inny model wdrażania o nazwie Azure Service Manager (ASM) lub "klasyczny". Aby dowiedzieć się więcej, zobacz Azure Resource Manager a wdrożenie klasyczne. Zarządzanie środowiskami za pomocą modelu ASM jest poza zakresem tej zawartości.
Azure Resource Manager to usługa frontonu, która hostuje interfejsy API REST używane przez program PowerShell, witrynę Azure Portal lub innych klientów do zarządzania zasobami. Gdy klient wysyła żądanie do zarządzania określonym zasobem, usługa Resource Manager wysyła żądanie do dostawcy zasobów w celu ukończenia żądania. Jeśli na przykład klient wysyła żądanie zarządzania zasobem maszyny wirtualnej, usługa Resource Manager wysyła żądanie do firmy Microsoft. Dostawca zasobów obliczeniowych. Usługa Resource Manager wymaga od klienta określenia identyfikatora zarówno subskrypcji, jak i grupy zasobów w celu zarządzania zasobem maszyny wirtualnej.
Przed wykonaniem żądania zarządzania zasobami przez usługę Resource Manager sprawdzany jest zestaw kontrolek.
Sprawdzanie prawidłowego użytkownika — użytkownik żądający zarządzania zasobem musi mieć konto w dzierżawie microsoft Entra skojarzonej z subskrypcją zarządzanego zasobu.
Sprawdzanie uprawnień użytkownika — uprawnienia są przypisywane do użytkowników przy użyciu kontroli dostępu opartej na rolach (RBAC). Rola RBAC określa zestaw uprawnień, które użytkownik może przejąć na określony zasób. Kontrola dostępu oparta na rolach ułatwia zarządzanie osobami mającymi dostęp do zasobów platformy Azure, czynnościami, które mogą wykonywać za pomocą tych zasobów oraz obszarami, do których mają dostęp.
Zasady platformy Azure sprawdzają, czy - zasady platformy Azure określają operacje dozwolone lub jawnie odrzucone dla określonego zasobu. Na przykład zasady mogą określać, że użytkownicy mogą wdrażać tylko określony typ maszyny wirtualnej (lub nie jest to dozwolone).
Na poniższym diagramie przedstawiono podsumowanie właśnie opisanego modelu zasobów.
Usługa Azure Lighthouse Azure Lighthouse - umożliwia zarządzanie zasobami między dzierżawami. Organizacje mogą delegować role na poziomie subskrypcji lub grupy zasobów do tożsamości w innej dzierżawie.
Subskrypcje, które umożliwiają delegowane zarządzanie zasobami w usłudze Azure Lighthouse, mają atrybuty wskazujące identyfikatory dzierżawy, które mogą zarządzać subskrypcjami lub grupami zasobów, oraz mapowanie między wbudowaną rolą RBAC w dzierżawie zasobów na tożsamości w dzierżawie dostawcy usług. W czasie wykonywania usługa Azure Resource Manager będzie używać tych atrybutów do autoryzowania tokenów pochodzących z dzierżawy dostawcy usług.
Warto zauważyć, że sama usługa Azure Lighthouse jest modelowana jako dostawca zasobów platformy Azure, co oznacza, że aspekty delegowania w dzierżawie mogą być ukierunkowane za pośrednictwem zasad platformy Azure.
Microsoft 365 Lighthouse Microsoft 365 Lighthouse - to portal administracyjny ułatwiający dostawcom usług zarządzanych (MSP) zabezpieczanie urządzeń, danych i użytkowników na dużą skalę dla klientów małych i średnich firm (SMB), którzy korzystają z usługi Microsoft 365 Business Premium, Microsoft 365 E3 lub Windows 365 Business.
Zarządzanie zasobami platformy Azure przy użyciu identyfikatora Entra firmy Microsoft
Teraz, gdy masz lepsze zrozumienie modelu zarządzania zasobami na platformie Azure, pokrótce przeanalizujmy niektóre możliwości identyfikatora Entra firmy Microsoft, które mogą zapewnić zarządzanie tożsamościami i dostępem dla zasobów platformy Azure.
Rozliczenia
Rozliczenia są ważne dla zarządzania zasobami, ponieważ niektóre role rozliczeniowe współdziałają z zasobami lub mogą zarządzać nimi. Rozliczenia działają inaczej w zależności od typu umowy, którą masz z firmą Microsoft.
Azure Umowa Enterprise s
Klienci platformy Azure Umowa Enterprise (Azure EA) są dołączani do witryny Azure EA Portal po wykonaniu umowy komercyjnej z firmą Microsoft. Podczas dołączania tożsamość jest skojarzona z rolą rozliczeń administratora przedsiębiorstwa "root". Portal udostępnia hierarchię funkcji zarządzania:
Działy ułatwiają dzielenie kosztów na logiczne grupowania i umożliwiają ustawianie budżetu lub limitu przydziału na poziomie działu.
Konta są używane do dalszego segmentowania działów. Konta umożliwiają zarządzanie subskrypcjami i uzyskiwanie dostępu do raportów. Portal EA może autoryzować konta Microsoft (MSA) lub konta Microsoft Entra (zidentyfikowane w portalu jako "Konta służbowe"). Tożsamości z rolą "Właściciel konta" w witrynie EA Portal mogą tworzyć subskrypcje platformy Azure.
Rozliczenia dla przedsiębiorstw i dzierżawy firmy Microsoft Entra
Gdy właściciel konta tworzy subskrypcję platformy Azure w ramach umowy Enterprise Agreement, tożsamość i zarządzanie dostępem subskrypcji są skonfigurowane w następujący sposób:
Subskrypcja platformy Azure jest skojarzona z tą samą dzierżawą usługi Microsoft Entra właściciela konta.
Właściciel konta, który utworzył subskrypcję, zostanie przypisany do ról Administrator usługi i Administrator konta. (Witryna Azure EA Portal przypisuje role programu Azure Service Manager (ASM) lub "klasyczne" do zarządzania subskrypcjami. Aby dowiedzieć się więcej, zobacz Azure Resource Manager a wdrożenie klasyczne).
Umowę Enterprise Agreement można skonfigurować tak, aby obsługiwała wiele dzierżaw, ustawiając typ uwierzytelniania "Konto służbowe między dzierżawami" w witrynie Azure EA Portal. Biorąc pod uwagę powyższe, organizacje mogą ustawić wiele kont dla każdej dzierżawy i wiele subskrypcji dla każdego konta, jak pokazano na poniższym diagramie.
Należy pamiętać, że konfiguracja domyślna opisana powyżej przyznaje uprawnienia właściciela konta umowy EA platformy Azure do zarządzania zasobami we wszystkich utworzonych subskrypcjach. W przypadku subskrypcji z obciążeniami produkcyjnymi należy rozważyć oddzielenie rozliczeń i zarządzania zasobami przez zmianę administratora usługi subskrypcji bezpośrednio po utworzeniu.
Aby dodatkowo rozdzielić i uniemożliwić właścicielowi konta odzyskanie dostępu administratora usługi do subskrypcji, dzierżawa subskrypcji może zostać zmieniona po utworzeniu. Jeśli właściciel konta nie ma obiektu użytkownika w dzierżawie Firmy Microsoft Entra, do której zostanie przeniesiona subskrypcja, nie może odzyskać roli właściciela usługi.
Aby dowiedzieć się więcej, odwiedź stronę Role platformy Azure, role firmy Microsoft Entra i klasyczne role administratora subskrypcji.
Umowa klienta firmy Microsoft
Klienci zarejestrowani w Umowa z Klientem Microsoft (MCA) mają inny system zarządzania rozliczeniami z własnymi rolami.
Konto rozliczeniowe dla Umowa z Klientem Microsoft zawiera co najmniej jeden profil rozliczeniowy, który umożliwia zarządzanie fakturami i formami płatności. Każdy profil rozliczeniowy zawiera co najmniej jedną sekcję faktury w celu organizowania kosztów na fakturze profilu rozliczeniowego.
W Umowa z Klientem Microsoft role rozliczeniowe pochodzą z jednej dzierżawy firmy Microsoft Entra. Aby aprowizować subskrypcje dla wielu dzierżaw, subskrypcje muszą zostać początkowo utworzone w tej samej dzierżawie firmy Microsoft Entra co umowa MCA, a następnie zmienione. Na poniższym diagramie subskrypcje firmowego środowiska przedprodukcyjnego IT zostały przeniesione do dzierżawy ContosoSandbox po utworzeniu.
Kontrola dostępu oparta na rolach i przypisania ról na platformie Azure
W sekcji Microsoft Entra Fundamentals wiesz, że kontrola dostępu oparta na rolach platformy Azure to system autoryzacji, który zapewnia szczegółowe zarządzanie dostępem do zasobów platformy Azure i zawiera wiele wbudowanych ról. Role niestandardowe można tworzyć i przypisywać role w różnych zakresach. Uprawnienia są wymuszane przez przypisanie ról RBAC do obiektów żądających dostępu do zasobów platformy Azure.
Role firmy Microsoft Entra działają na pojęciach, takich jak kontrola dostępu oparta na rolach platformy Azure. Różnica między tymi dwoma systemami kontroli dostępu opartej na rolach polega na tym, że kontrola dostępu na podstawie ról platformy Azure używa usługi Azure Resource Management do kontrolowania dostępu do zasobów platformy Azure, takich jak maszyny wirtualne lub magazyn, a role firmy Microsoft Entra kontrolują dostęp do identyfikatora Entra firmy Microsoft, aplikacji i usługi firmy Microsoft, takich jak usługa Office 365.
Zarówno role entra firmy Microsoft, jak i role RBAC platformy Azure integrują się z usługą Microsoft Entra Privileged Identity Management, aby włączyć zasady aktywacji just in time, takie jak przepływ pracy zatwierdzania i uwierzytelnianie wieloskładnikowe.
AbAC i przypisania ról na platformie Azure
Kontrola dostępu oparta na atrybutach (ABAC) to system autoryzacji, który definiuje dostęp na podstawie atrybutów skojarzonych z jednostkami zabezpieczeń, zasobami i środowiskiem. Za pomocą funkcji ABAC można udzielić jednostce zabezpieczeń dostępu do zasobu na podstawie atrybutów. Usługa Azure ABAC odnosi się do implementacji usługi ABAC dla platformy Azure.
Usługa Azure ABAC bazuje na kontroli dostępu opartej na rolach platformy Azure przez dodanie warunków przypisywania ról na podstawie atrybutów w kontekście określonych akcji. Warunek przypisania roli to dodatkowa kontrola, którą można opcjonalnie dodać do przypisania roli, aby zapewnić bardziej szczegółową kontrolę dostępu. Warunek filtruje uprawnienia przyznane w ramach definicji roli i przypisania roli. Można na przykład dodać warunek, który wymaga, aby obiekt miał określony tag do odczytania obiektu. Nie można jawnie odmówić dostępu do określonych zasobów przy użyciu warunków.
Dostęp warunkowy
Dostęp warunkowy firmy Microsoft Entra może służyć do zarządzania dostępem do punktów końcowych zarządzania platformy Azure. Zasady dostępu warunkowego można zastosować do aplikacji w chmurze interfejsu API zarządzania usługami platformy Windows Azure w celu ochrony punktów końcowych zarządzania zasobami platformy Azure, takich jak:
Dostawca usługi Azure Resource Manager (usługi)
Interfejsy API usługi Azure Resource Manager
Azure PowerShell
Interfejs wiersza polecenia platformy Azure
Azure Portal
Na przykład administrator może skonfigurować zasady dostępu warunkowego, które umożliwiają użytkownikowi logowanie się do witryny Azure Portal tylko z zatwierdzonych lokalizacji, a także wymaga uwierzytelniania wieloskładnikowego (MFA) lub hybrydowego urządzenia przyłączonego do domeny firmy Microsoft Entra.
Tożsamości zarządzane platformy Azure
Typowym wyzwaniem podczas kompilowania aplikacji w chmurze jest sposób zarządzania poświadczeniami w kodzie w przypadku uwierzytelniania przy użyciu usług w chmurze. Zabezpieczanie poświadczeń to ważne zadanie. W idealnej sytuacji poświadczenia nie są nigdy wyświetlane na stacjach roboczych deweloperów ani zaewidencjonowane do kontroli źródła. Tożsamości zarządzane dla zasobów platformy Azure zapewniają usługom platformy Azure automatyczną tożsamość zarządzaną w usłudze Microsoft Entra ID. Za pomocą tożsamości można uwierzytelnić się w dowolnej usłudze, która obsługuje uwierzytelnianie firmy Microsoft Entra bez żadnych poświadczeń w kodzie.
Istnieją dwa typy tożsamości zarządzanych:
Tożsamość zarządzana przypisana przez system jest włączona bezpośrednio w zasobie platformy Azure. Po włączeniu zasobu platforma Azure tworzy tożsamość dla zasobu w zaufanej dzierżawie microsoft Entra skojarzonej subskrypcji. Po utworzeniu tożsamości poświadczenia są aprowizowane w zasobie. Cykl życia tożsamości przypisanej przez system jest bezpośrednio powiązany z zasobem platformy Azure. Jeśli zasób zostanie usunięty, platforma Azure automatycznie wyczyści poświadczenia i tożsamość w identyfikatorze Entra firmy Microsoft.
Tożsamość zarządzana przypisana przez użytkownika jest tworzona jako autonomiczny zasób platformy Azure. Platforma Azure tworzy tożsamość w dzierżawie firmy Microsoft Entra, która jest zaufana przez subskrypcję, z którą jest skojarzony zasób. Po utworzeniu tożsamości tożsamość można przypisać do co najmniej jednego zasobu platformy Azure. Cykl życia tożsamości przypisanej przez użytkownika jest zarządzany niezależnie od cyklu życia zasobów platformy Azure, do których jest przypisany.
Tożsamości zarządzane wewnętrznie są jednostkami usługi specjalnego typu, które mają być używane tylko przez określone zasoby platformy Azure. Po usunięciu tożsamości zarządzanej odpowiednia jednostka usługi zostanie automatycznie usunięta. Nie, że autoryzacja uprawnień interfejsu API programu Graph może być wykonywana tylko przez program PowerShell, więc nie wszystkie funkcje tożsamości zarządzanej są dostępne za pośrednictwem interfejsu użytkownika portalu.
Usługi domenowe Microsoft Entra
Usługi Microsoft Entra Domain Services udostępnia domenę zarządzaną, która ułatwia uwierzytelnianie obciążeń platformy Azure przy użyciu starszych protokołów. Obsługiwane serwery są przenoszone z lokalnego lasu usług AD DS i przyłączone do domeny zarządzanej usług Microsoft Entra Domain Services i nadal używają starszych protokołów do uwierzytelniania (na przykład uwierzytelniania Kerberos).
Katalogi usługi Azure AD B2C i platforma Azure
Dzierżawa usługi Azure AD B2C jest połączona z subskrypcją platformy Azure na potrzeby rozliczeń i komunikacji. Dzierżawy usługi Azure AD B2C mają autonomiczną strukturę roli w katalogu, która jest niezależna od ról uprzywilejowanych RBAC platformy Azure w ramach subskrypcji platformy Azure.
Gdy dzierżawa usługi Azure AD B2C jest początkowo aprowizowana, użytkownik tworzący dzierżawę B2C musi mieć uprawnienia współautora lub właściciela w subskrypcji. Później mogą tworzyć inne konta i przypisywać je do ról katalogu. Aby uzyskać więcej informacji, zobacz Omówienie kontroli dostępu opartej na rolach w usłudze Microsoft Entra ID.
Należy pamiętać, że właściciele i współautorzy połączonej subskrypcji Firmy Microsoft Entra mogą usunąć link między subskrypcją a katalogiem, co wpłynie na bieżące rozliczenia użycia usługi Azure AD B2C.
Zagadnienia dotyczące tożsamości dla rozwiązań IaaS na platformie Azure
W tym scenariuszu opisano wymagania dotyczące izolacji tożsamości, które organizacje mają obciążenia infrastruktury jako usługi (IaaS).
Istnieją trzy kluczowe opcje zarządzania izolacją obciążeń IaaS:
Maszyny wirtualne przyłączone do autonomicznych usług domena usługi Active Directory Services (AD DS)
Maszyny wirtualne przyłączone do usługi Microsoft Entra Domain Services
Logowanie się do maszyn wirtualnych na platformie Azure przy użyciu uwierzytelniania firmy Microsoft Entra
Kluczową koncepcją związaną z dwoma pierwszymi opcjami jest to, że istnieją dwa obszary tożsamości, które są zaangażowane w te scenariusze.
Po zalogowaniu się do maszyny wirtualnej z systemem Windows Server platformy Azure za pośrednictwem protokołu RDP (Remote Desktop Protocol) zazwyczaj logujesz się na serwerze przy użyciu poświadczeń domeny, co wykonuje uwierzytelnianie Kerberos względem lokalnego kontrolera domeny usług AD DS lub usług Microsoft Entra Domain Services. Alternatywnie, jeśli serwer nie jest przyłączony do domeny, można użyć konta lokalnego do logowania się na maszynach wirtualnych.
Po zalogowaniu się do witryny Azure Portal w celu utworzenia maszyny wirtualnej lub zarządzania nią uwierzytelniasz się w usłudze Microsoft Entra ID (potencjalnie przy użyciu tych samych poświadczeń, jeśli zsynchronizowano poprawne konta), co może spowodować uwierzytelnienie względem kontrolerów domeny, jeśli używasz usług Active Directory Federation Services (AD FS) lub uwierzytelniania passThrough.
Maszyny wirtualne przyłączone do autonomicznych usług domena usługi Active Directory
USŁUGI AD DS to oparta na systemie Windows Server usługa katalogowa, którą organizacje w dużej mierze przyjęły dla lokalnych usług tożsamości. Usługi AD DS można wdrożyć, gdy istnieje wymóg wdrażania obciążeń IaaS na platformie Azure, które wymagają izolacji tożsamości od administratorów usług AD DS i użytkowników w innym lesie.
W tym scenariuszu należy wziąć pod uwagę następujące kwestie:
Kontrolery domeny usług AD DS: należy wdrożyć co najmniej dwa kontrolery domeny usług AD DS, aby upewnić się, że usługi uwierzytelniania są wysoce dostępne i wydajne. Aby uzyskać więcej informacji, zobacz Ad DS Design and Planning (Projektowanie i planowanie usług AD DS).
Projektowanie i planowanie usług AD DS — należy utworzyć nowy las usług AD DS z następującymi usługami skonfigurowanymi poprawnie:
Usługi AD DS Domain Name Services (DNS) — system DNS usług AD DS musi być skonfigurowany dla odpowiednich stref w usługach AD DS, aby upewnić się, że rozpoznawanie nazw działa poprawnie dla serwerów i aplikacji.
Lokacje i usługi usług AD DS — te usługi muszą być skonfigurowane w celu zapewnienia, że aplikacje mają małe opóźnienia i sprawny dostęp do kontrolerów domeny. Odpowiednie sieci wirtualne, podsieci i lokalizacje centrów danych, w których znajdują się serwery, powinny być konfigurowane w lokacjach i usługach.
AD DS FSMOs — role elastycznej operacji pojedynczego wzorca (FSMO), które są wymagane, należy przejrzeć i przypisać do odpowiednich kontrolerów domeny usług AD DS.
Przyłączanie do domeny usług AD DS — wszystkie serwery (z wyłączeniem "serwerów przesiadkowych"), które wymagają usług AD DS na potrzeby uwierzytelniania, konfiguracji i zarządzania muszą być przyłączone do izolowanego lasu.
Zasady grupy usług AD DS (GPO) — obiekty zasad grupy usług AD DS należy skonfigurować, aby upewnić się, że konfiguracja spełnia wymagania dotyczące zabezpieczeń i że konfiguracja jest ustandaryzowana w całym lesie i maszynach przyłączonych do domeny.
Jednostki organizacyjne usług AD DS — jednostki organizacyjne usług AD DS muszą być zdefiniowane w celu zapewnienia grupowania zasobów usług AD DS w logiczne zarządzanie i silosy konfiguracji na potrzeby administrowania i stosowania konfiguracji.
Kontrola dostępu oparta na rolach — kontrola dostępu oparta na rolach musi być zdefiniowana na potrzeby administracji i dostępu do zasobów dołączonych do tego lasu. Obejmuje to:
Grupy usług AD DS — grupy należy utworzyć, aby zastosować odpowiednie uprawnienia dla użytkowników do zasobów usług AD DS.
Konta administracyjne — jak wspomniano na początku tej sekcji, istnieją dwa konta administracyjne wymagane do zarządzania tym rozwiązaniem.
Konto administracyjne usług AD DS z najmniej uprzywilejowanym dostępem wymaganym do wykonywania administracji wymaganej w usługach AD DS i serwerach przyłączonych do domeny.
Konto administracyjne firmy Microsoft Entra na potrzeby dostępu do witryny Azure Portal w celu łączenia i konfigurowania maszyn wirtualnych, sieci wirtualnych, sieciowych grup zabezpieczeń i innych wymaganych zasobów platformy Azure oraz zarządzania nimi.
Konta użytkowników usług AD DS — odpowiednie konta użytkowników należy aprowizować i dodawać do odpowiednich grup, aby umożliwić użytkownikom dostęp do aplikacji hostowanych przez to rozwiązanie.
Sieci wirtualne — wskazówki dotyczące konfiguracji
Adres IP kontrolera domeny usług AD DS — kontrolery domeny nie powinny być konfigurowane przy użyciu statycznych adresów IP w systemie operacyjnym. Adresy IP powinny być zarezerwowane w sieci wirtualnej platformy Azure, aby upewnić się, że zawsze pozostają takie same, a kontroler domeny powinien być skonfigurowany do używania protokołu DHCP.
Serwer DNS sieci wirtualnej — serwery DNS muszą być skonfigurowane w sieciach wirtualnych, które są częścią tego izolowanego rozwiązania, aby wskazywały kontrolery domeny. Jest to wymagane, aby zapewnić, że aplikacje i serwery mogą rozpoznawać wymagane usługi AD DS lub inne usługi przyłączone do lasu usług AD DS.
Sieciowe grupy zabezpieczeń — kontrolery domeny powinny znajdować się we własnej sieci wirtualnej lub podsieci ze zdefiniowanymi sieciowymi grupami zabezpieczeń , aby zezwolić tylko na dostęp do kontrolerów domeny z wymaganych serwerów (na przykład maszyn przyłączonych do domeny lub serwerów przesiadkowych). Aby uprościć tworzenie i administrowanie sieciową grupą zabezpieczeń, należy dodać do grupy zabezpieczeń aplikacji.
Wyzwania: Poniższa lista wyróżnia kluczowe wyzwania związane z używaniem tej opcji na potrzeby izolacji tożsamości:
Dodatkowy las usług AD DS do administrowania i monitorowania, co skutkuje większą pracą dla zespołu IT w celu wykonania.
Do zarządzania poprawkami i wdrożeniami oprogramowania może być wymagana dalsza infrastruktura. Organizacje powinny rozważyć wdrożenie usługi Azure Update Management, zasad grupy (GPO) lub programu System Center Configuration Manager (SCCM) w celu zarządzania tymi serwerami.
Dodatkowe poświadczenia dla użytkowników do zapamiętania i użycia do uzyskiwania dostępu do zasobów.
Ważne
W przypadku tego izolowanego modelu zakłada się, że nie ma łączności z kontrolerami domeny lub z sieci firmowej klienta i że nie ma żadnych relacji zaufania skonfigurowanych z innymi lasami. Należy utworzyć serwer przesiadkowy lub serwer zarządzania, aby umożliwić zarządzanie i administrowanie kontrolerami domeny usług AD DS.
Maszyny wirtualne przyłączone do usługi Microsoft Entra Domain Services
Jeśli istnieje wymaganie dotyczące wdrażania obciążeń IaaS na platformie Azure, które wymagają izolacji tożsamości od administratorów usług AD DS i użytkowników w innym lesie, można wdrożyć domenę zarządzaną usług Microsoft Entra Domain Services. Microsoft Entra Domain Services to usługa, która zapewnia domenę zarządzaną w celu ułatwienia uwierzytelniania obciążeń platformy Azure przy użyciu starszych protokołów. Zapewnia to izolowana domenę bez technicznych złożoności tworzenia własnych usług AD DS i zarządzania nimi. Należy wziąć pod uwagę następujące kwestie.
Domena zarządzana usług Microsoft Entra Domain Services — można wdrożyć tylko jedną domenę zarządzaną usług Microsoft Entra Domain Services dla dzierżawy firmy Microsoft Entra i jest ona powiązana z jedną siecią wirtualną. Zaleca się, aby ta sieć wirtualna stanowiła "centrum" uwierzytelniania usług Microsoft Entra Domain Services. Z tego centrum można utworzyć szprychy i połączyć je, aby umożliwić starsze uwierzytelnianie serwerów i aplikacji. Szprychy to dodatkowe sieci wirtualne, w których znajdują się serwery przyłączone do usług Microsoft Entra Domain Services i są połączone z koncentratorem przy użyciu bram sieciowych platformy Azure lub komunikacji równorzędnej sieci wirtualnych.
Lokalizacja domeny zarządzanej — należy ustawić lokalizację podczas wdrażania domeny zarządzanej usług Microsoft Entra Domain Services. Lokalizacja to region fizyczny (centrum danych), w którym wdrożono domenę zarządzaną. Zaleca się:
Rozważ lokalizację, która jest geograficznie zamknięta dla serwerów i aplikacji, które wymagają usług Microsoft Entra Domain Services.
Rozważ regiony, które zapewniają Strefy dostępności możliwości dla wymagań dotyczących wysokiej dostępności. Aby uzyskać więcej informacji, zobacz Regiony i Strefy dostępności na platformie Azure.
Aprowizowanie obiektów — usługi Microsoft Entra Domain Services synchronizują tożsamości z identyfikatora Entra firmy Microsoft skojarzonego z subskrypcją wdrożonych w usługach Microsoft Entra Domain Services. Warto również zauważyć, że jeśli skojarzony identyfikator Firmy Microsoft Entra ma skonfigurowaną synchronizację z programem Microsoft Entra Connect (scenariusz lasu użytkownika), cykl życia tych tożsamości można również odzwierciedlić w usługach Microsoft Entra Domain Services. Ta usługa ma dwa tryby, których można użyć do aprowizacji obiektów użytkowników i grup z identyfikatora Entra firmy Microsoft.
Wszystkie: wszyscy użytkownicy i grupy są synchronizowani z witryny Microsoft Entra ID do usług Microsoft Entra Domain Services.
Zakres: tylko użytkownicy w zakresie grup są synchronizowani z identyfikatorem Entra firmy Microsoft z usługami Microsoft Entra Domain Services.
Podczas pierwszego wdrażania usług Microsoft Entra Domain Services automatyczna synchronizacja jednokierunkowa jest skonfigurowana do replikowania obiektów z identyfikatora Entra firmy Microsoft. Ta jednokierunkowa synchronizacja nadal działa w tle, aby zachować aktualność domeny zarządzanej usług Microsoft Entra Domain Services z wszelkimi zmianami z identyfikatora Entra firmy Microsoft. Nie następuje synchronizacja z Microsoft Entra Domain Services z powrotem do Microsoft Entra ID. Aby uzyskać więcej informacji, zobacz Jak obiekty i poświadczenia są synchronizowane w domenie zarządzanej usług Microsoft Entra Domain Services.
Warto zauważyć, że jeśli musisz zmienić typ synchronizacji z Wszystkie na Zakres (lub odwrotnie), to domena zarządzana usługi Microsoft Entra Domain Services musi zostać usunięta, utworzona i skonfigurowana. Ponadto organizacje powinny rozważyć użycie aprowizacji "w zakresie", aby ograniczyć tożsamości tylko do tych, którzy potrzebują dostępu do zasobów usługi Microsoft Entra Domain Services jako dobrej praktyki.
Obiekty zasad grupy (GPO) — aby skonfigurować obiekt zasad grupy w domenie zarządzanej usług Microsoft Entra Domain Services, należy użyć narzędzi zarządzania zasadami grupy na serwerze, który został przyłączony do domeny zarządzanej usług Microsoft Entra Domain Services. Aby uzyskać więcej informacji, zobacz Administrowanie zasadami grupy w domenie zarządzanej usług Microsoft Entra Domain Services.
Secure LDAP — Microsoft Entra Domain Services udostępnia bezpieczną usługę LDAP, która może być używana przez aplikacje, które tego wymagają. To ustawienie jest domyślnie wyłączone i aby włączyć bezpieczny protokół LDAP, należy przekazać certyfikat, ponadto sieciowa grupa zabezpieczeń, która zabezpiecza sieć wirtualną wdrożona przez usługi Microsoft Entra Domain Services, aby umożliwić łączność portów 636 z domenami zarządzanymi usług Microsoft Entra Domain Services. Aby uzyskać więcej informacji, zobacz Konfigurowanie bezpiecznego protokołu LDAP dla domeny zarządzanej usług Microsoft Entra Domain Services.
Administracja — aby wykonywać obowiązki administracyjne w usługach Microsoft Entra Domain Services (na przykład maszyny przyłączone do domeny lub edytować obiekt zasad grupy), konto używane na potrzeby tego zadania musi być częścią grupy Administratorzy domeny Firmy Microsoft Entra. Konta należące do tej grupy nie mogą bezpośrednio logować się do kontrolerów domeny w celu wykonywania zadań zarządzania. Zamiast tego należy utworzyć maszynę wirtualną zarządzania przyłączona do domeny zarządzanej usług Microsoft Entra Domain Services, a następnie zainstalować zwykłe narzędzia do zarządzania usługami AD DS. Aby uzyskać więcej informacji, zobacz Pojęcia dotyczące zarządzania kontami użytkowników, hasłami i administracją w usługach Microsoft Entra Domain Services.
Skróty haseł — aby uwierzytelnianie za pomocą usług Microsoft Entra Domain Services działało, skróty haseł dla wszystkich użytkowników muszą być w formacie odpowiednim dla uwierzytelniania NT LAN Manager (NTLM) i Kerberos. Aby upewnić się, że uwierzytelnianie w usługach Microsoft Entra Domain Services działa zgodnie z oczekiwaniami, należy wykonać następujące wymagania wstępne.
Użytkownicy zsynchronizowani z programem Microsoft Entra Connect (z usług AD DS) — starsze skróty haseł muszą być synchronizowane z lokalnych usług AD DS do identyfikatora Entra firmy Microsoft.
Użytkownicy utworzeni w usłudze Microsoft Entra ID — należy zresetować hasło, aby można było wygenerować poprawne skróty do użycia z usługami Microsoft Entra Domain Services. Aby uzyskać więcej informacji, zobacz Włączanie synchronizacji skrótów haseł.
Sieć — usługi Microsoft Entra Domain Services są wdrażane w sieci wirtualnej platformy Azure, dlatego należy wziąć pod uwagę, aby upewnić się, że serwery i aplikacje są zabezpieczone i mogą prawidłowo uzyskiwać dostęp do domeny zarządzanej. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące projektowania sieci wirtualnej i opcje konfiguracji dla usług Microsoft Entra Domain Services.
Usługi Microsoft Entra Domain Services należy wdrożyć we własnej podsieci: nie używaj istniejącej podsieci ani podsieci bramy.
Sieciowa grupa zabezpieczeń ( NSG) — jest tworzona podczas wdrażania domeny zarządzanej usług Microsoft Entra Domain Services. Ta sieciowa grupa zabezpieczeń zawiera wymagane reguły poprawnej komunikacji z usługą. Nie twórz ani nie używaj istniejącej sieciowej grupy zabezpieczeń z własnymi regułami niestandardowymi.
Usługi Microsoft Entra Domain Services wymagają 3–5 adresów IP — upewnij się, że zakres adresów IP podsieci może zapewnić tę liczbę adresów. Ograniczenie dostępnych adresów IP może uniemożliwić usłudze Microsoft Entra Domain Services obsługę dwóch kontrolerów domeny.
Serwer DNS sieci wirtualnej — jak wspomniano wcześniej o modelu "piasty i szprychy", należy prawidłowo skonfigurować system DNS w sieciach wirtualnych, aby upewnić się, że serwery przyłączone do domeny zarządzanej usług Microsoft Entra Domain Services mają poprawne ustawienia DNS, aby rozpoznać domenę zarządzaną usług Microsoft Entra Domain Services. Każda sieć wirtualna ma wpis serwera DNS przekazywany do serwerów w miarę uzyskiwania adresu IP, a te wpisy DNS muszą być adresami IP domeny zarządzanej usług Microsoft Entra Domain Services. Aby uzyskać więcej informacji, zobacz Aktualizowanie ustawień DNS dla sieci wirtualnej platformy Azure.
Wyzwania — poniższa lista wyróżnia kluczowe wyzwania związane z używaniem tej opcji w przypadku izolacji tożsamości.
Niektóre konfiguracje usług Microsoft Entra Domain Services można administrować tylko z serwera przyłączonego do usług Microsoft Entra Domain Services.
Dla dzierżawy firmy Microsoft Entra można wdrożyć tylko jedną domenę zarządzaną usług Microsoft Entra Services. Zgodnie z opisem w tej sekcji model piasty i szprych jest zalecany do zapewnienia uwierzytelniania usług Microsoft Entra Domain Services w innych sieciach wirtualnych.
Dalsza infrastruktura może być wymagana do zarządzania wdrożeniami poprawek i oprogramowania. Organizacje powinny rozważyć wdrożenie usługi Azure Update Management, zasad grupy (GPO) lub programu System Center Configuration Manager (SCCM) w celu zarządzania tymi serwerami.
W przypadku tego izolowanego modelu zakłada się, że nie ma łączności z siecią wirtualną, która hostuje domenę zarządzaną usług Microsoft Entra Domain Services z sieci firmowej klienta i że nie ma żadnych relacji zaufania skonfigurowanych z innymi lasami. Należy utworzyć serwer przesiadkowy lub serwer zarządzania, aby umożliwić zarządzanie i administrowanie usługami Microsoft Entra Domain Services.
Logowanie się do maszyn wirtualnych na platformie Azure przy użyciu uwierzytelniania firmy Microsoft Entra
Jeśli istnieje wymaganie dotyczące wdrażania obciążeń IaaS na platformie Azure, które wymagają izolacji tożsamości, ostateczną opcją jest użycie identyfikatora Entra firmy Microsoft na potrzeby logowania do serwerów w tym scenariuszu. Dzięki temu można ustawić identyfikator entra firmy Microsoft na potrzeby uwierzytelniania i izolacji tożsamości, aprowizowanie serwerów w odpowiedniej subskrypcji, która jest połączona z wymaganą dzierżawą firmy Microsoft Entra. Należy wziąć pod uwagę następujące kwestie.
Obsługiwane systemy operacyjne: Logowanie się do maszyn wirtualnych na platformie Azure przy użyciu uwierzytelniania entra firmy Microsoft jest obecnie obsługiwane w systemach Windows i Linux. Aby uzyskać bardziej szczegółowe informacje na temat obsługiwanych systemów operacyjnych, zapoznaj się z dokumentacją systemów Windows i Linux.
Poświadczenia: Jedną z najważniejszych zalet logowania się do maszyn wirtualnych na platformie Azure przy użyciu uwierzytelniania firmy Microsoft Entra jest możliwość korzystania z tych samych poświadczeń federacyjnych lub zarządzanych w usłudze Microsoft Entra, których zwykle używasz do uzyskiwania dostępu do usług Microsoft Entra na potrzeby logowania się do maszyny wirtualnej.
Uwaga
Dzierżawa firmy Microsoft Entra używana do logowania w tym scenariuszu to dzierżawa firmy Microsoft Entra skojarzona z subskrypcją, w ramach którego zainicjowano aprowizację maszyny wirtualnej. Ta dzierżawa firmy Microsoft Entra może być dzierżawą, która ma tożsamości synchronizowane z lokalnych usług AD DS. Organizacje powinny dokonać świadomego wyboru, który jest zgodny z ich podmiotami zabezpieczeń izolacji podczas wybierania subskrypcji i dzierżawy firmy Microsoft Entra, której chcą używać do logowania się na tych serwerach.
Wymagania dotyczące sieci: Te maszyny wirtualne będą musiały uzyskać dostęp do identyfikatora Entra firmy Microsoft na potrzeby uwierzytelniania, aby upewnić się, że konfiguracja sieci maszyn wirtualnych zezwala na dostęp wychodzący do punktów końcowych firmy Microsoft Entra w wersji 443. Aby uzyskać więcej informacji, zobacz dokumentację dla systemów Windows i Linux .
Kontrola dostępu oparta na rolach (RBAC): dostępne są dwie role RBAC, aby zapewnić odpowiedni poziom dostępu do tych maszyn wirtualnych. Te role RBAC można skonfigurować za pośrednictwem witryny Azure Portal lub środowiska usługi Azure Cloud Shell. Aby uzyskać więcej informacji, zobacz Konfigurowanie przypisań ról dla maszyny wirtualnej.
Logowanie administratora maszyny wirtualnej: użytkownicy z przypisaną do nich rolą mogą logować się do maszyny wirtualnej platformy Azure z uprawnieniami administratora.
Logowanie użytkownika maszyny wirtualnej: użytkownicy z przypisaną do nich rolą mogą logować się do maszyny wirtualnej platformy Azure przy użyciu zwykłych uprawnień użytkownika.
Dostęp warunkowy: kluczową zaletą korzystania z identyfikatora Entra firmy Microsoft do logowania się na maszynach wirtualnych platformy Azure jest możliwość wymuszania dostępu warunkowego w ramach procesu logowania. Umożliwia to organizacjom wymaganie spełnienia warunków przed zezwoleniem na dostęp do maszyny wirtualnej i używanie uwierzytelniania wieloskładnikowego w celu zapewnienia silnego uwierzytelniania. Aby uzyskać więcej informacji, zobacz Korzystanie z dostępu warunkowego.
Uwaga
Zdalne połączenie z maszynami wirtualnymi dołączonymi do identyfikatora Entra firmy Microsoft jest dozwolone tylko z komputerów z systemem Windows 10, Windows 11 i Komputerami pc w chmurze, które są przyłączone do firmy Microsoft Entra lub przyłączone hybrydy firmy Microsoft Entra do tego samego katalogu co maszyna wirtualna.
Wyzwania: Poniższa lista wyróżnia kluczowe wyzwania związane z używaniem tej opcji na potrzeby izolacji tożsamości.
Brak centralnego zarządzania ani konfiguracji serwerów. Na przykład nie ma żadnych zasad grupy, które można zastosować do grupy serwerów. Organizacje powinny rozważyć wdrożenie rozwiązania Update Management na platformie Azure w celu zarządzania poprawkami i aktualizacjami tych serwerów.
Nie nadaje się do wielowarstwowych aplikacji, które mają wymagania dotyczące uwierzytelniania za pomocą mechanizmów lokalnych, takich jak zintegrowane uwierzytelnianie systemu Windows na tych serwerach lub usługach. Jeśli jest to wymagane w organizacji, zaleca się zapoznanie się z autonomicznymi usługami domena usługi Active Directory lub scenariuszami usług Microsoft Entra Domain Services opisanymi w tej sekcji.
W przypadku tego izolowanego modelu zakłada się, że nie ma łączności z siecią wirtualną, która hostuje maszyny wirtualne z sieci firmowej klienta. Należy utworzyć serwer przesiadkowy lub serwer zarządzania, aby umożliwić zarządzanie tymi serwerami i administrowanie nimi.