Najlepsze rozwiązania dotyczące wszystkich architektur izolacji

Poniżej przedstawiono zagadnienia projektowe dotyczące wszystkich konfiguracji izolacji. W tej zawartości istnieje wiele linków. Łączymy się z zawartością, a nie duplikujemy ją tutaj, więc zawsze będziesz mieć dostęp do najbardziej aktualnych informacji.

Aby uzyskać ogólne wskazówki dotyczące konfigurowania dzierżaw Microsoft Entra (izolowanych lub nieizolowanych), zapoznaj się z przewodnikiem wdrażania funkcji Microsoft Entra.

Zasady zabezpieczeń izolacji

Podczas projektowania środowisk izolowanych należy wziąć pod uwagę następujące zasady:

• Używaj tylko nowoczesnego uwierzytelniania — aplikacje wdrożone w izolowanych środowiskach muszą używać nowoczesnego uwierzytelniania opartego na oświadczeniach (na przykład SAML, * Auth, OAuth2 i OpenID Connect), aby korzystać z funkcji, takich jak federacja, współpraca, delegowanie i struktura wyrażania zgody firmy Microsoft Entra B2B. W ten sposób starsze aplikacje, które mają zależność od starszych metod uwierzytelniania, takich jak NT LAN Manager (NTLM), nie będą przenoszone w środowiskach izolowanych.

• Wymuszanie silnego uwierzytelniania — silne uwierzytelnianie musi być zawsze używane podczas uzyskiwania dostępu do izolowanych usług i infrastruktury środowiska. Jeśli to możliwe, należy używać uwierzytelniania bez hasła, takiego jak Windows for Business Hello lub FIDO2 klucze zabezpieczeń.

• Wdrażanie bezpiecznych stacji roboczych Zabezpieczanie stacji roboczych - zapewnia mechanizm zapewniający, że platforma i tożsamość reprezentowana przez platformę są prawidłowo sprawdzane i zabezpieczone przed wykorzystaniem. Dwa inne podejścia do rozważenia to:

  • Użyj Komputer w chmurze Windows 365 s (cloud PC) z interfejsem API programu Microsoft Graph.

  • Użyj Kontroli dostępu warunkowego aby filtrować urządzenia jako warunek.

• Wyeliminowanie starszych mechanizmów zaufania — izolowane katalogi i usługi nie powinny ustanawiać relacji zaufania z innymi środowiskami za pomocą starszych mechanizmów, takich jak relacje zaufania usługi Active Directory. Wszystkie relacje zaufania między środowiskami należy ustanowić przy użyciu nowoczesnych konstrukcji, takich jak federacja i tożsamość oparta na oświadczeniach.

• Izoluj usługi — zminimalizuj powierzchnię ataku, chroniąc podstawowe tożsamości i infrastrukturę usług przed ujawnieniem. Włącz dostęp tylko za pośrednictwem nowoczesnego uwierzytelniania dla usług i bezpiecznego dostępu zdalnego (chronionego również przez nowoczesne uwierzytelnianie) dla infrastruktury.

• Przypisania ról na poziomie katalogu — unikaj lub zmniejszaj liczbę przypisań ról na poziomie katalogu (administrator użytkowników działający w ramach katalogu zamiast w ramach jednostek AU) lub ról katalogu specyficznych dla usługi z akcjami w płaszczyźnie sterowania (administrator wiedzy uprawniony do zarządzania członkostwem w grupach zabezpieczeń).

Oprócz wskazówek w przewodniku dotyczącym ogólnych operacji Microsoft Entra, zalecamy również następujące rozważania dotyczące izolowanych środowisk.

Zarządzanie tożsamością użytkownika

Uprzywilejowane konta

Utwórz konta w izolowanym środowisku dla personelu administracyjnego i zespołów IT obsługujących środowisko. Dzięki temu można dodać silniejsze zasady zabezpieczeń, takie jak kontrola dostępu oparta na urządzeniach dla bezpiecznych stacji roboczych. Zgodnie z opisem w poprzednich sekcjach, środowiska nieprodukcyjne mogą potencjalnie używać funkcji współpracy Microsoft Entra B2B do dołączania uprzywilejowanych kont do dzierżaw nieprodukcyjnych, korzystając z tego samego podejścia i mechanizmów kontroli zabezpieczeń, przeznaczonych do uprzywilejowanego dostępu w środowisku produkcyjnym.

Konta tylko w chmurze to najprostszy sposób aprowizacji tożsamości ludzkich w dzierżawie firmy Microsoft Entra i jest dobrym rozwiązaniem dla środowisk zielonych pól. Jeśli istnieje infrastruktura lokalna odpowiadająca izolowanemu środowisku (na przykład środowisko przedprodukcyjne lub las zarządzania Active Directory), możesz rozważyć synchronizowanie tożsamości z tego miejsca. Ma to szczególne zastosowanie, jeśli infrastruktura lokalna opisana w niniejszym dokumencie jest używana w przypadku rozwiązań IaaS, które wymagają dostępu serwera do zarządzania płaszczyzną danych rozwiązania. Aby uzyskać więcej informacji na temat tego scenariusza, zobacz Ochrona platformy Microsoft 365 przed atakami lokalnymi. Synchronizacja z izolowanymi środowiskami lokalnymi może być również potrzebna, jeśli istnieją określone wymagania dotyczące zgodności z przepisami, takie jak uwierzytelnianie tylko za pomocą karty inteligentnej.

Outsourcing ról wysokiego ryzyka

Aby zredukować zagrożenia wewnętrzne, można zlecić dostęp do ról Global Administrator i Privileged Role Administrator zewnętrznemu dostawcy usług zarządzanych, korzystając ze współpracy B2B platformy Azure lub delegując dostęp za pośrednictwem partnera CSP lub usługi Lighthouse. Ten dostęp może być kontrolowany przez pracowników w firmie za pośrednictwem przepływów zatwierdzania w usłudze Azure Privileged Identity Management (PIM). Takie podejście może znacznie ograniczyć zagrożenia wewnętrzne. Jest to podejście, którego można użyć do spełnienia wymagań dotyczących zgodności dla klientów, którzy mają wątpliwości.

Udostępnianie tożsamości nieludzkiej

Konta dostępu awaryjnego

Firma Microsoft zaleca, aby organizacje miały dwa konta dostępu awaryjnego tylko w chmurze, które zostały trwale przypisane do roli administratora globalnego. Te konta są wysoce uprzywilejowane i nie są przypisane do określonych osób. Konta są przeznaczone wyłącznie do sytuacji awaryjnych lub scenariuszy "break glass", gdy nie można używać zwykłych kont lub wszyscy inni administratorzy są przypadkowo zablokowani. Te konta należy tworzyć zgodnie z zaleceniami dotyczącymi kont dostępu awaryjnego.

Tożsamości zarządzane platformy Azure

Użyj tożsamości zarządzanych platformy Azure dla zasobów platformy Azure, które wymagają tożsamości usługi. Sprawdź listę usług, które obsługują tożsamości zarządzane podczas projektowania rozwiązań platformy Azure.

Jeśli tożsamości zarządzane nie są obsługiwane lub nie ma możliwości ich użycia, rozważ tworzenie obiektów głównego podmiotu usługi.

Konta usługi hybrydowej

Niektóre rozwiązania hybrydowe mogą wymagać dostępu zarówno do zasobów lokalnych, jak i w chmurze. Przykładem przypadku użycia jest aplikacja, która używa konta usługi w usługach AD DS w celu uzyskania dostępu do lokalnych serwerów przyłączonych do domeny, a także ma konto w identyfikatorze Entra firmy Microsoft, ponieważ wymaga dostępu do usług Microsoft Online Services.

Lokalne konta usług zwykle nie mają możliwości logowania interakcyjnego, co oznacza, że w scenariuszach w chmurze nie mogą spełnić silnych wymagań dotyczących poświadczeń, takich jak uwierzytelnianie wieloskładnikowe. W tym scenariuszu nie używaj konta usługi, które zostało zsynchronizowane ze środowiska lokalnego, ale zamiast tego użyj tożsamości zarządzanej \ jednostki usługi. W przypadku głównego obiektu usługi (SP) użyj certyfikatu jako poświadczenia lub ochroń SP przy użyciu dostępu warunkowego.

Jeśli istnieją ograniczenia techniczne, które tego nie umożliwiają, a to samo konto musi być używane zarówno dla środowiska lokalnego, jak i w chmurze, należy zaimplementować mechanizmy kontroli wyrównujących, takie jak dostęp warunkowy, aby zablokować konto hybrydowe, które ma pochodzić z określonej lokalizacji sieciowej.

Przydział zasobów

Rozwiązanie przedsiębiorstwa może składać się z wielu zasobów platformy Azure, a jego dostęp powinien być zarządzany i zarządzany jako jednostka logiczna przypisania — grupa zasobów. W tym scenariuszu grupy zabezpieczeń firmy Microsoft Entra można utworzyć i skojarzyć z odpowiednimi uprawnieniami i przypisaniem roli we wszystkich zasobach rozwiązania, dzięki czemu dodanie lub usunięcie użytkowników z tych grup spowoduje zezwolenie na dostęp do całego rozwiązania lub odmawianie mu dostępu.

Zalecamy używanie grup opartych na zabezpieczeniach i licencjach dla usług Microsoft, które wymagają przypisania użytkownikowi miejsca licencyjnego jako warunku wstępnego przed przyznaniem dostępu (na przykład Dynamics 365, Power BI).

Chmuro-rodzime grupy Microsoft Entra mogą być natywnie zarządzane w chmurze, w połączeniu z przeglądami dostępu Microsoft Entra i zarządzaniem upoważnieniami Microsoft Entra.

Identyfikator Entra firmy Microsoft obsługuje również bezpośrednie przypisywanie użytkowników do usług SaaS innych firm (na przykład Salesforce, Service Now) i aplikacji lokalnych na potrzeby logowania jednokrotnego i aprowizacji tożsamości. Bezpośrednie przypisania do zasobów mogą być natywnie zarządzane z chmury w połączeniu z przeglądami dostępu firmy Microsoft Entra i zarządzaniem upoważnieniami firmy Microsoft Entra. Przypisanie bezpośrednie może być dobrym rozwiązaniem w przypadku przypisywania dla użytkowników końcowych.

Niektóre scenariusze mogą wymagać udzielenia dostępu do zasobów lokalnych za pośrednictwem lokalnych grup zabezpieczeń Active Directory. W tych sytuacjach należy wziąć pod uwagę cykl synchronizacji z Microsoft Entra ID podczas projektowania SLA dla procesów.

Zarządzanie uwierzytelnianiem

W tej sekcji opisano kontrole, które należy wykonać, i akcje do wykonania w celu zarządzania poświadczeniami i zasad dostępu w oparciu o stan zabezpieczeń organizacji.

Zarządzanie poświadczeniami

Silne referencje

Wszystkie tożsamości człowieka (konta lokalne i tożsamości zewnętrzne aprowizowane za pośrednictwem współpracy B2B) w izolowanym środowisku muszą być aprowizowane przy użyciu silnych poświadczeń uwierzytelniania, takich jak uwierzytelnianie wieloskładnikowe lub klucz FIDO. Środowiska z bazową infrastrukturą lokalną z silnym uwierzytelnianiem, takim jak uwierzytelnianie za pomocą karty inteligentnej, mogą nadal korzystać z uwierzytelniania kart inteligentnych w chmurze.

Poświadczenia bez hasła

Rozwiązanie bez hasła to najlepsze rozwiązanie do zapewnienia najwygodniejszej i bezpiecznej metody uwierzytelniania. Poświadczenia bez hasła, takie jak klucze zabezpieczeń FIDO i Windows Hello dla firm, są zalecane w przypadku tożsamości człowieka z rolami uprzywilejowanymi.

Ochrona hasłem

Jeśli środowisko jest synchronizowane z lokalnego lasu Active Directory, należy wdrożyć ochronę haseł Microsoft Entra w celu wyeliminowania słabych haseł w organizacji. Inteligentna blokada firmy Microsoft Entra powinna być również używana w środowiskach hybrydowych lub tylko w chmurze, aby zablokować złych aktorów, którzy próbują odgadnąć hasła użytkowników lub użyć metod siłowych, aby się dostać.

Samoobsługowe zarządzanie hasłami

Użytkownicy, którzy muszą zmienić lub zresetować swoje hasła, jest jednym z największych źródeł ilości i kosztów połączeń pomocy technicznej. Oprócz kosztów zmiana hasła jako narzędzia w celu ograniczenia ryzyka związanego z użytkownikiem jest podstawowym krokiem w zakresie poprawy stanu zabezpieczeń organizacji. Wdróż co najmniej samoobsługowe zarządzanie hasłami dla kont użytkowników i testowych z hasłami, aby zmniejszyć liczbę połączeń do pomocy technicznej.

Hasła tożsamości zewnętrznych

Dzięki współpracy B2B z Microsoft Entra, proces zaproszenia i realizacji umożliwia użytkownikom zewnętrznym, takim jak partnerzy, deweloperzy i podwykonawcy, by używać własnych poświadczeń w celu uzyskania dostępu do zasobów firmy. Ogranicza to konieczność wprowadzania większej liczby haseł do izolowanych dzierżaw.

Poświadczenia principal usługi

W przypadku scenariuszy, w których są potrzebne podmioty zabezpieczeń, użyj poświadczeń certyfikatów dla podmiotów zabezpieczeń lub dostępu warunkowego dla tożsamości aplikacji. W razie potrzeby należy użyć tajemnic klienta jako wyjątku do polityki organizacji.

W obu przypadkach usługa Azure Key Vault może być używana z tożsamościami zarządzanymi platformy Azure, dzięki czemu środowisko uruchomieniowe (na przykład funkcja platformy Azure) może pobrać poświadczenia z magazynu kluczy.

Sprawdź ten przykład, aby utworzyć jednostki usługi z certyfikatem z podpisem własnym na potrzeby uwierzytelniania jednostek usługi przy użyciu poświadczeń certyfikatu.

Zasady dostępu

W poniższych sekcjach przedstawiono zalecenia dotyczące rozwiązań platformy Azure. Aby uzyskać ogólne wskazówki dotyczące zasad dostępu warunkowego dla poszczególnych środowisk, zapoznaj się z najlepszymi rozwiązaniami dotyczącymi dostępu warunkowego, Przewodnikiem po operacjach firmy Microsoft i dostępem warunkowym dla zera zaufania:

• Zdefiniuj zasady dostępu warunkowego dla aplikacji w chmurze interfejsu API zarządzania usługami Azure, aby wymusić stan zabezpieczeń tożsamości podczas uzyskiwania dostępu do usługi Azure Resource Manager. Powinno to obejmować mechanizmy kontroli uwierzytelniania wieloskładnikowego i kontrolek opartych na urządzeniach, aby umożliwić dostęp tylko za pośrednictwem bezpiecznych stacji roboczych (więcej informacji na ten temat znajduje się w sekcji Role uprzywilejowane w obszarze Zarządzanie tożsamościami). Ponadto użyj dostępu warunkowego, aby filtrować urządzenia.

• Wszystkie aplikacje zintegrowane z izolowanymi środowiskami muszą mieć jawne zasady dostępu warunkowego zastosowane w ramach procesu integrowania.

• Zdefiniuj zasady dostępu warunkowego na potrzeby rejestrowania informacji o bezpieczeństwie, które odzwierciedlają bezpieczny korzeń zaufania w środowisku lokalnym (na przykład w przypadku stacji roboczych w lokalizacjach fizycznych, możliwych do zidentyfikowania przez adresy IP, które pracownicy muszą odwiedzić osobiście w celu weryfikacji).

• Rozważ użycie dostępu warunkowego w celu ograniczenia tożsamości obciążeń. Utwórz zasady, aby ograniczyć lub lepiej kontrolować dostęp w oparciu o lokalizację lub inne istotne okoliczności.

Wyzwania związane z uwierzytelnianiem

• Tożsamości zewnętrzne udostępniane za pomocą usługi Microsoft Entra B2B mogą wymagać ponownego dostarczania poświadczeń uwierzytelniania wieloskładnikowego w dzierżawcy zasobów. Może to być konieczne, jeśli nie skonfigurowano polityki dostępu między dzierżawami u dzierżawcy zasobów. Oznacza to, że wdrażanie do systemu jest zainicjowane przy pomocy jednego czynnika. Dzięki temu podejściu organizacja może ograniczyć ryzyko poprzez zweryfikowanie profilu ryzyka użytkownika i jego poświadczeń przed wystawieniem zaproszenia B2B. Ponadto zdefiniuj dostęp warunkowy do procesu rejestracji zgodnie z wcześniejszym opisem.

• Użyj ustawień dostępu międzydzierżawcowego dla tożsamości zewnętrznych, aby zarządzać współpracą z innymi organizacjami Microsoft Entra i innymi usługami w chmurze Microsoft Azure, za pośrednictwem współpracy B2B i B2B Direct Connect.

• W przypadku określonej konfiguracji i kontroli urządzenia można używać filtrów urządzeń w zasadach dostępu warunkowego do określania lub wykluczania określonych urządzeń. Dzięki temu można ograniczyć dostęp do narzędzi do zarządzania platformy Azure z wyznaczonej bezpiecznej stacji roboczej administratora (SAW). Inne podejścia, które można zastosować, można zastosować przy użyciu usługi Azure Virtual Desktop, usługi Azure Bastion lub komputera w chmurze.

• Aplikacje do zarządzania rozliczeniami, takie jak witryna Azure EA Portal lub konta rozliczeniowe MCA, nie są reprezentowane jako aplikacje w chmurze na potrzeby określania celu dostępu warunkowego. Jako kontrolka wyrównywająca zdefiniuj oddzielne konta administracyjne i docelowe zasady dostępu warunkowego do tych kont przy użyciu warunku "Wszystkie aplikacje".

Nadzór nad tożsamościami

Role uprzywilejowane

Poniżej podano niektóre zasady zarządzania tożsamością do rozważenia we wszystkich konfiguracjach dzierżawy na potrzeby izolacji.

• Brak stałego dostępu — żadna ludzka tożsamość nie powinna mieć stałego dostępu do wykonywania uprzywilejowanych operacji w izolowanych środowiskach. Kontrola dostępu oparta na rolach (RBAC) platformy Azure integruje się z usługą Microsoft Entra Privileged Identity Management (PIM). Usługa PIM zapewnia aktywację w odpowiednim czasie, określaną przez mechanizmy zabezpieczeń, takie jak uwierzytelnianie wieloskładnikowe, przepływ pracy zatwierdzania i ograniczony czas trwania.

• Liczba administratorów — organizacje powinny definiować minimalną i maksymalną liczbę osób posiadających uprzywilejowaną rolę w celu ograniczenia ryzyka ciągłości działania. W przypadku zbyt niewielu ról uprzywilejowanych może nie być wystarczające pokrycie strefy czasowej. Zniweluj zagrożenia bezpieczeństwa, mając jak najmniej administratorów, postępując zgodnie z zasadą najniższych uprawnień.

• Ograniczanie dostępu uprzywilejowanego — tworzenie grup tylko w chmurze i grup z możliwością przypisywania ról w celu uzyskania wysokich uprawnień lub uprawnień poufnych. Zapewnia to ochronę przypisanych użytkowników i obiektu grupy.

• Najmniej uprzywilejowany dostęp — tożsamości powinny mieć tylko te uprawnienia, które są niezbędne do wykonywania operacji uprzywilejowanych zgodnie z ich rolą w organizacji.

  • Niestandardowe role platformy Azure RBAC umożliwiają projektowanie ról o najmniejszych uprawnieniach na podstawie potrzeb organizacji. Zalecamy, aby definicje ról niestandardowych zostały utworzone lub przejrzyone przez wyspecjalizowane zespoły ds. zabezpieczeń i ograniczyły ryzyko niezamierzonych nadmiernych uprawnień. Tworzenie ról niestandardowych może być audytowane za pomocą Azure Policy.

  • Aby ograniczyć przypadkowe użycie ról, które nie są przeznaczone do szerszego użytku w organizacji, użyj usługi Azure Policy, aby określić jawnie, które definicje ról mogą służyć do przypisywania dostępu. Dowiedz się więcej z tego przykładu usługi GitHub.

• Dostęp uprzywilejowany z bezpiecznych stacji roboczych — dostęp uprzywilejowany powinien odbywać się z bezpiecznych, zablokowanych urządzeń. Oddzielenie tych poufnych zadań i kont od codziennych zastosowań stacji roboczych i urządzeń chroni uprzywilejowane konta przed atakami wyłudzającymi informacje, lukami w zabezpieczeniach aplikacji i systemu operacyjnego, atakami podszywania się i kradzieżą poświadczeń, takimi jak rejestrowanie naciśnięć klawiszy, przekazywanie skrótu i Pass-The-Ticket.

Niektóre podejścia, których można użyć do używania bezpiecznych urządzeń w ramach scenariusza uprzywilejowanego dostępu, obejmują używanie zasad dostępu warunkowego do określania celu lub wykluczania określonych urządzeń, przy użyciu usługi Azure Virtual Desktop, usługi Azure Bastion lub komputera w chmurze albo tworzenia zarządzanych przez platformę Azure stacji roboczych lub stacji roboczych z dostępem uprzywilejowanym.

• Zabezpieczenia procesów ról uprzywilejowanych — organizacje muszą definiować procesy i zabezpieczenia techniczne, aby zagwarantować, że uprzywilejowane operacje mogą być wykonywane zawsze w razie potrzeby przy zachowaniu zgodności z wymaganiami prawnymi. Przykłady kryteriów poręczy obejmują:

  • Kwalifikacja ludzi z uprzywilejowanymi rolami (na przykład pracownik/dostawca w pełnym wymiarze czasu pracy, poziom odprawy, obywatelstwo)

  • Jawna niezgodność ról (znana również jako separacja obowiązków). Przykłady obejmują zespoły posiadające role katalogowe Microsoft Entra, które nie powinny być odpowiedzialne za zarządzanie rolami uprzywilejowanymi w Azure Resource Manager, itd.

  • Określa, czy preferowane są przypisania bezpośrednie użytkowników lub grup do ról.

• Monitorowanie przypisań IAM spoza usługi Microsoft Entra PIM nie jest zautomatyzowane za pomocą zasad platformy Azure. Ograniczenie ryzyka polega na tym, że nie należy udzielać ról właściciela subskrypcji ani administratora dostępu użytkowników do zespołów inżynieryjnych. Zamiast tego utwórz grupy przypisane do ról o najniższych uprawnieniach, takich jak Współautor i deleguj zarządzanie tymi grupami do zespołów inżynieryjnych.

Dostęp do zasobów

• Zaświadczenia — tożsamości, które mają uprzywilejowane role, należy okresowo przeglądać, aby członkostwo było nadal aktualne i uzasadnione. Przeglądy dostępu firmy Microsoft Entra integrują się z rolami RBAC platformy Azure, członkostwem w grupach i zewnętrznymi tożsamościami firmy Microsoft Entra B2B.

• Cykl życia — operacje uprzywilejowane mogą wymagać dostępu do wielu zasobów, takich jak aplikacje biznesowe, aplikacje SaaS i grupy zasobów i subskrypcje platformy Azure. Rozwiązanie Microsoft Entra Entitlement Management umożliwia definiowanie pakietów dostępu reprezentujących zestaw zasobów przypisanych do użytkowników jako jednostkę, ustanowienie okresu ważności, przepływów pracy zatwierdzania itd.

Zarządzanie cyklem życia dzierżawy i subskrypcji

Cykl życia najemcy

• Zalecamy zaimplementowanie procesu w celu złożenia wniosku o nową instancję Microsoft Entra w firmie. Proces powinien uwzględniać następujące cele:

  • Uzasadnienie biznesowe, aby go utworzyć. Utworzenie nowej dzierżawy Microsoft Entra znacznie zwiększy złożoność, dlatego kluczowe jest ustalenie, czy nowa dzierżawa jest konieczna.

  • Chmura Azure, w której powinna zostać utworzona (na przykład Komercyjna, Rządowa itp.).

  • Bez względu na to, czy jest to produkcja, czy nie jest to produkcja

  • Wymagania dotyczące przechowywania danych katalogu

  • Kto będzie nim zarządzać

  • Szkolenie i zrozumienie typowych wymagań dotyczących zabezpieczeń.

• Po zatwierdzeniu dzierżawa Microsoft Entra zostanie utworzona, skonfigurowana przy użyciu niezbędnych podstawowych mechanizmów kontrolnych i dołączona na płaszczyźnie rozliczeniowej, monitoringu itd.

• Aby wykrywać i identyfikować tworzenie dzierżawców poza zarządzanym procesem, należy wdrożyć regularny przegląd dzierżawy Microsoft Entra w ramach rozliczeń. Aby uzyskać więcej informacji, zapoznaj się z sekcją Spis i widoczność tego dokumentu.

• Tworzenie dzierżawy Azure AD B2C można kontrolować za pomocą usługi Azure Policy. Zasady wykonują się, gdy subskrypcja platformy Azure jest skojarzona z dzierżawą B2C (wymaganie wstępne dotyczące rozliczeń). Klienci mogą ograniczyć zakładanie dzierżaw usługi Azure AD B2C do określonych grup zarządzania.

• Nie ma żadnych technicznych środków kontroli umożliwiających podporządkowanie tworzenia dzierżaw organizacji. Jednak działanie jest rejestrowane w dzienniku inspekcji. Dołączanie do płaszczyzny rozliczeniowej to kontrola wyrównywająca na bramie. Zamiast tego należy uzupełnić je monitorowaniem i alertami.

Cykl życia subskrypcji

Poniżej przedstawiono kilka zagadnień dotyczących projektowania zarządzanego procesu cyklu życia subskrypcji:

• Zdefiniuj taksonomię aplikacji i rozwiązań, które wymagają zasobów platformy Azure. Wszystkie zespoły żądające subskrypcji powinny podać swój "identyfikator produktu" podczas żądania subskrypcji. Taksonomia informacji określi:

  • Dzierżawca Microsoft Entra do aprowizacji subskrypcji

  • Konto ea platformy Azure do użycia na potrzeby tworzenia subskrypcji

  • Konwencja nazewnictwa

  • Przypisanie do grupy zarządzania

  • Inne aspekty, takie jak tagowanie, ładowanie krzyżowe, użycie widoku produktu itd.

• Nie zezwalaj na tworzenie subskrypcji ad hoc za pośrednictwem portali ani w inny sposób. Zamiast tego należy rozważyć programowe zarządzanie subskrypcjami przy użyciu usługi Azure Resource Manager i programowe ściąganie raportów zużycia i rozliczeń. Może to pomóc ograniczyć udostępnianie subskrypcji autoryzowanym użytkownikom i wymusić realizację celów dotyczących zasad i taksonomii. Wskazówki dotyczące przestrzegania zasad AZOps mogą pomóc w stworzeniu praktycznego rozwiązania.

• Po aprowizacji subskrypcji utwórz grupy chmurowe Microsoft Entra, aby przypisywać standardowe role Azure Resource Manager wymagane przez zespoły aplikacji, takie jak Współautor, Czytelnik i zatwierdzone role niestandardowe. Dzięki temu można zarządzać przypisaniami ról RBAC platformy Azure z zarządzanym dostępem uprzywilejowanym w dużej skali.

  1. Skonfiguruj grupy, aby kwalifikowały się do ról RBAC platformy Azure przy użyciu usługi Microsoft Entra PIM z odpowiednimi mechanizmami kontroli, takimi jak zasady aktywacji, przeglądy dostępu, osoby zatwierdzające itd.

  2. Następnie deleguj zarządzanie grupami do właścicieli rozwiązań.

  3. Jako środek zapobiegawczy nie przypisuj właścicieli produktów do ról Administratora Dostępu Użytkownika ani Właściciela, aby uniknąć nieumyślnego bezpośredniego przypisania ról poza Microsoft Entra PIM lub potencjalnej zmiany subskrypcji na inną dzierżawę.

  4. W przypadku klientów, którzy zdecydują się włączyć zarządzanie subskrypcjami między dzierżawami w dzierżawach nieprodukcyjnych za pośrednictwem usługi Azure Lighthouse, upewnij się, że te same zasady dostępu z konta z uprawnieniami produkcyjnymi (na przykład dostęp uprzywilejowany tylko z zabezpieczonych stacji roboczych) są wymuszane podczas uwierzytelniania w celu zarządzania subskrypcjami.

• Jeśli Organizacja ma wstępnie zatwierdzone architektury referencyjne, aprowizowanie subskrypcji można zintegrować z narzędziami wdrażania zasobów, takimi jak Azure Blueprints lub Terraform.

• Biorąc pod uwagę powiązanie dzierżaw z subskrypcjami Azure, udostępnianie subskrypcji powinno uwzględniać wiele tożsamości tego samego aktora ludzkiego (pracownika, partnera, dostawcy itd.) w różnych dzierżawach i odpowiednio przypisywać dostęp.

Role EA i MCA

• Portal umowy Azure Enterprise (Azure EA) nie integruje się z Azure RBAC ani z dostępem warunkowym Azure. Ograniczeniem tego jest użycie dedykowanych kont administracyjnych, których celem mogą być zasady i dodatkowe monitorowanie.

• Witryna Azure EA Enterprise Portal nie udostępnia dziennika inspekcji. Aby temu zapobiec, rozważ zautomatyzowany proces zarządzający aprowizacją subskrypcji, biorąc pod uwagę powyższe rozważania, oraz użyj dedykowanych kont EA i przeprowadź inspekcję dzienników uwierzytelniania.

• Role z Umowy z Klientem Microsoft (MCA) nie integrują się natywnie z usługą PIM. Aby temu zapobiec, użyj dedykowanych kont MCA i monitoruj użycie tych kont.

Dzierżawy usługi Azure AD B2C

• W dzierżawie usługi Azure AD B2C wbudowane role nie obsługują usługi PIM. Aby zwiększyć bezpieczeństwo, zalecamy użycie współpracy firmy Microsoft Entra B2B w celu dołączenia zespołów inżynieryjnych zarządzających zarządzaniem dostępem do tożsamości klienta (CIAM) z dzierżawy platformy Azure, przypisania ich do ról uprzywilejowanych usługi Azure AD B2C i zastosowania zasad dostępu warunkowego do tych dedykowanych kont administracyjnych.

• Role uprzywilejowane w dzierżawie usługi Azure AD B2C nie są zintegrowane z przeglądami dostępu w usłudze Microsoft Entra. Środki zaradcze polegają na utworzeniu dedykowanych kont w dzierżawie firmy Microsoft Entra w organizacji, dodaniu tych kont do grupy i regularnym przeglądom dostępu w tej grupie.

• Zgodnie z powyższymi wytycznymi dotyczącymi dostępu awaryjnego dla identyfikatora Entra firmy Microsoft rozważ utworzenie równoważnych kont dostępu awaryjnego oprócz opisanych powyżej administratorów zewnętrznych.

• Zalecamy, aby logiczna odpowiedzialność za podstawową subskrypcję Microsoft Entra dzierżawy B2C była ukierunkowana na zespoły inżynieryjne CIAM, tak jak pozostałe subskrypcje Azure są wykorzystywane w rozwiązaniach B2C.

Operacje

Poniżej przedstawiono dodatkowe zagadnienia operacyjne dotyczące identyfikatora Entra firmy Microsoft, specyficzne dla wielu izolowanych środowisk. Zapoznaj się z przewodnikiem Azure Cloud Adoption Framework, testem porównawczym zabezpieczeń w chmurze firmy Microsoft i przewodnikiem Microsoft Entra Operations, aby uzyskać szczegółowe wskazówki dotyczące obsługi poszczególnych środowisk.

Role i obowiązki między środowiskami

Architektura SecOps dla całego przedsiębiorstwa — członkowie zespołów ds. operacji i zabezpieczeń ze wszystkich środowisk w organizacji powinni wspólnie zdefiniować następujące elementy:

• Zasady definiowania, kiedy należy tworzyć, konsolidować lub wycofywać ze stosowania środowiska.

• Zasady definiowania hierarchii grup zarządzania w każdym środowisku.

• Plan rozliczeniowy (EA Portal/MCA): stan zabezpieczeń, stan operacyjny oraz podejście do delegowania.

• Proces tworzenia dzierżawy.

• Taksonomia aplikacji dla przedsiębiorstw.

• Proces aprowizacji subskrypcji platformy Azure.

• Granice izolacji i autonomii administracyjnej oraz ocena ryzyka w zespołach i środowiskach.

• Wspólna konfiguracja punktu odniesienia i mechanizmy kontroli zabezpieczeń (techniczne i wyrównujące) oraz operacyjne punkty odniesienia, które mają być używane we wszystkich środowiskach.

• Typowe standardowe procedury operacyjne i narzędzia obejmujące wiele środowisk (na przykład monitorowanie, aprowizowanie).

• Uzgodniono delegowanie ról w wielu środowiskach.

• Segregacja obowiązku w różnych środowiskach.

• Typowe zarządzanie łańcuchem dostaw dla uprzywilejowanych stacji roboczych.

• Konwencje nazewnictwa.

• Mechanizmy korelacji między środowiskami.

Tworzenie najemcy — konkretny zespół powinien odpowiadać za tworzenie najemcy zgodnie ze standardowymi procesami zdefiniowanymi przez architekturę SecOps dla całego przedsiębiorstwa. Obejmuje to:

• Podstawowa aprowizacja licencji (na przykład Platforma Microsoft 365).

• Dołączenie do firmowego planu rozliczeniowego (na przykład umowy Azure EA lub MCA).

• Tworzenie hierarchii grup zarządzania platformy Azure.

• Konfiguracja zasad zarządzania dla różnych obwodów, w tym tożsamości, ochrony danych, platformy Azure itd.

• Wdrożenie stosu zabezpieczeń zgodnie z uzgodnioną architekturą cyberbezpieczeństwa, w tym ustawienia diagnostyczne, dołączanie rozwiązania SIEM, dołączanie CASB, dołączanie PIM itd.

• Konfiguracja ról Microsoft Entra na podstawie uzgodnionego delegowania.

• Konfiguracja i dystrybucja początkowych uprzywilejowanych stacji roboczych.

• Aprowizowanie kont dostępu awaryjnego.

• Konfiguracja stosu aprowizacji tożsamości.

Architektura narzędzi działających w różnych środowiskach — niektóre narzędzia, takie jak zarządzanie tożsamością i potoki kontroli źródła, mogą działać w wielu środowiskach. Te narzędzia powinny być traktowane jako krytyczne dla infrastruktury i muszą być architektonicznie zaprojektowane, stworzone, zaimplementowane i zarządzane jako takie. W związku z tym architekci ze wszystkich środowisk powinni być zaangażowani za każdym razem, gdy należy zdefiniować narzędzia między środowiskami.

Zapas i widoczność

Wykrywanie subskrypcji platformy Azure — dla każdej wykrytej dzierżawy globalny administrator Microsoft Entra może podnieść poziom dostępu, aby uzyskać widoczność wszystkich subskrypcji w środowisku. To podniesienie uprawnień spowoduje przypisanie użytkownikom wbudowanej roli Administratora Dostępu Użytkowników w grupie głównej zarządzania.

Włączanie dostępu do odczytu w celu odnajdywania zasobów — Grupy zarządzania umożliwiają przypisywanie Kontroli Dostępu opartej na Rolach (KBA) na szeroką skalę w wielu subskrypcjach. Klienci mogą przypisać rolę Czytelnika scentralizowanemu zespołowi IT, konfigurując przypisanie roli w grupie zarządzania głównego, która będzie propagowana do wszystkich subskrypcji w środowisku.

Odnajdywanie zasobów — po uzyskaniu dostępu do odczytu zasobu w środowisku usługa Azure Resource Graph może służyć do wykonywania zapytań dotyczących zasobów w środowisku.

Rejestrowanie i monitorowanie

Centralne zarządzanie dziennikami zabezpieczeń — pozyskiwanie dzienników z każdego środowiska w sposób scentralizowany, zgodnie ze spójnymi najlepszymi rozwiązaniami w różnych środowiskach (na przykład ustawienia diagnostyczne, przechowywanie dzienników, pozyskiwanie rozwiązania SIEM itd.). Usługa Azure Monitor może służyć do pozyskiwania dzienników z różnych źródeł, takich jak urządzenia punktu końcowego, sieć, dzienniki zabezpieczeń systemów operacyjnych itd.

Szczegółowe informacje na temat używania zautomatyzowanych lub ręcznych procesów i narzędzi do monitorowania dzienników w ramach operacji zabezpieczeń są dostępne w przewodniku po operacjach zabezpieczeń firmy Microsoft Entra.

Niektóre środowiska mogą mieć regulacje prawne, które ograniczają, jakie dane (jeśli w ogóle) mogą opuścić dane środowisko. Jeśli scentralizowane monitorowanie w różnych środowiskach nie jest możliwe, zespoły powinny mieć procedury operacyjne w celu skorelowania działań tożsamości w różnych środowiskach do celów audytu i śledztwa, takich jak próby nieautoryzowanych ruchów lateralnych między środowiskami. Zaleca się, aby unikatowe identyfikatory obiektów dla tożsamości ludzkich należących do tej samej osoby były wykrywalne, potencjalnie jako część systemów zarządzania tożsamością.

Strategia logowania musi zawierać następujące dzienniki firmy Microsoft Entra dla każdego dzierżawcy używanego w organizacji.

• Aktywność związana z logowaniem

• Dzienniki inspekcji

• Zdarzenia o podwyższonym ryzyku

Usługa Microsoft Entra ID zapewnia integrację usługi Azure Monitor dla dzienników aktywności logowania i dzienników inspekcji. Zdarzenia ryzyka mogą być pozyskiwane za pośrednictwem interfejsu API programu Microsoft Graph.

Na poniższym diagramie przedstawiono różne źródła danych, które należy włączyć w ramach strategii monitorowania:

Dzierżawy usługi Azure AD B2C można zintegrować z usługą Azure Monitor. Zalecamy monitorowanie usługi Azure AD B2C przy użyciu tych samych kryteriów opisanych powyżej dla identyfikatora Entra firmy Microsoft.

Subskrypcje, które włączyły zarządzanie między dzierżawami za pomocą usługi Azure Lighthouse, mogą uaktywnić monitorowanie między dzierżawami, jeśli dzienniki są zbierane przez usługę Azure Monitor. Odpowiednie obszary robocze usługi Log Analytics mogą znajdować się w dzierżawie zasobów i można je analizować centralnie w dzierżawie zarządzającej przy użyciu skoroszytów usługi Azure Monitor. Aby dowiedzieć się więcej, zobacz Monitorowanie delegowanych zasobów na dużą skalę — Azure Lighthouse.

Dzienniki zabezpieczeń systemu operacyjnego infrastruktury hybrydowej

Wszystkie dzienniki systemu operacyjnego infrastruktury tożsamości hybrydowej powinny być archiwizowane i uważnie monitorowane jako system warstwy 0, biorąc pod uwagę implikacje dotyczące obszaru powierzchni. Obejmuje to:

• Serwery usług AD FS i serwer proxy aplikacji sieci Web

• Microsoft Entra Connect

• Agenty proxy aplikacji

• Agenci zwrotnego zapisywania haseł

• Urządzenia bramy ochrony hasłem

• NPS z rozszerzeniem RADIUS uwierzytelniania wieloskładnikowego Microsoft Entra

Program Microsoft Entra Connect Health musi być wdrożony w celu monitorowania synchronizacji tożsamości i federacji (jeśli ma to zastosowanie) dla wszystkich środowisk.

Zarządzanie przechowywaniem dzienników — wszystkie środowiska powinny mieć spójną strategię, projektowanie i wdrażanie w zakresie przechowywania dzienników, aby ułatwić spójny zestaw narzędzi (na przykład systemy SIEM, takie jak Azure Sentinel), powszechne zapytania, badania i procedury kryminalistyczne. Usługa Azure Policy może służyć do konfigurowania ustawień diagnostycznych.

Monitorowanie i przeglądanie dzienników — zadania operacyjne związane z monitorowaniem tożsamości powinny być spójne i mieć właścicieli w każdym środowisku. Jak opisano powyżej, staraj się skonsolidować te obowiązki w różnych środowiskach w zakresie dozwolonym przez wymagania dotyczące zgodności z przepisami i izolacji.

Następujące scenariusze muszą być jawnie monitorowane i badane:

• Podejrzane działania — wszystkie zdarzenia o podwyższonym ryzyku firmy Microsoft powinny być monitorowane pod kątem podejrzanych działań. Wszyscy dzierżawcy powinni definiować nazwane lokalizacje w sieci, aby uniknąć fałszywych alarmów na sygnałach opartych na lokalizacji. Ochrona tożsamości Microsoft Entra jest natywnie zintegrowana z usługą Azure Security Center. Zalecane jest, aby każde badanie wykrywania ryzyka obejmowało wszystkie środowiska, w których jest przydzielona tożsamość użytkownika (na przykład, jeśli tożsamość użytkownika ma aktywne wykrywanie ryzyka w dzierżawie firmowej, zespół obsługujący dzierżawę klienta powinien również zbadać aktywność odpowiedniego konta w tym środowisku).

• Alerty UEBA - analiza behawioralna jednostki użytkownika powinna być używana do uzyskiwania szczegółowych informacji na podstawie wykrywania anomalii. Microsoft Microsoft 365 Defender for Cloud Apps zapewnia UEBA w chmurze. Klienci mogą zintegrować lokalną wersję UEBA z Microsoft 365 Defender for Identity. Usługa MCAS odczytuje sygnały z Microsoft Entra ID Protection.

• Aktywność kont dostępu awaryjnego — każdy dostęp przy użyciu kont dostępu awaryjnego powinien być monitorowany i alerty utworzone na potrzeby badań. To monitorowanie musi obejmować:

  • Logowania

  • Zarządzanie poświadczeniami

  • Wszelkie aktualizacje członkostwa w grupach

  • Przypisania aplikacji

• Konta do zarządzania rozliczeniami — biorąc pod uwagę wrażliwość kont z rolami zarządzania w ramach umowy Azure EA lub MCA i ich znaczące uprawnienia, zaleca się monitorowanie i powiadamianie o alertach:

  • Próby logowania przez konta z rolami rozliczeniowymi.

  • Każda próba uwierzytelnienia w aplikacjach innych niż witryna EA Portal.

  • Każda próba uwierzytelnienia się w aplikacjach innych niż Azure Resource Management przy użyciu dedykowanych kont do zadań rozliczeniowych MCA.

  • Przypisywanie zasobów platformy Azure za pomocą dedykowanych kont do zadań związanych z rozliczeniami umowy MCA.

• Działanie roli uprzywilejowanej — konfigurowanie i przeglądanie alertów zabezpieczeń generowanych przez usługę Microsoft Entra PIM. Jeśli zablokowanie bezpośrednich przypisań RBAC nie jest w pełni wymuszane za pomocą kontroli technicznych (na przykład rola właściciela musi zostać przyznana zespołom produktowym, aby wykonywać swoje zadania), monitoruj bezpośrednie przypisywanie ról uprzywilejowanych poza usługą PIM, wywołując alerty, gdy użytkownik jest bezpośrednio przypisany do dostępu do subskrypcji za pomocą RBAC platformy Azure.

• Przypisania ról klasycznych — organizacje powinny używać nowoczesnej infrastruktury ról RBAC Azure zamiast ról klasycznych. W związku z tym należy monitorować następujące zdarzenia:

  • Przypisywanie do ról klasycznych na poziomie subskrypcji

• Konfiguracje dla całej dzierżawy — każda usługa konfiguracji dla całej dzierżawy powinna generować alerty w systemie.

  • Aktualizowanie domen niestandardowych

  • Aktualizowanie znakowania

  • Microsoft Entra B2B — lista dozwolonych/zablokowanych

  • Microsoft Entra B2B dozwoleni dostawcy tożsamości (SAML IDP za pośrednictwem federacji bezpośredniej lub loginów społecznościowych)

  • Zmiany zasad dostępu warunkowego

• Obiekty główne aplikacji i usług

  • Nowe aplikacje/jednostki usługi, które mogą wymagać zasad dostępu warunkowego

  • Działanie zgody aplikacji

• Aktywność grupy zarządzania — należy monitorować następujące aspekty tożsamości grup zarządzania:

  • Przypisania ról RBAC w systemie MG

  • Zasady platformy Azure stosowane do Grupy Zarządzania (MG)

  • Subskrypcje przeniesione między grupami zarządzania

  • Wszelkie zmiany zasad zabezpieczeń w głównej grupie MG

• Role niestandardowe

  • Aktualizacje definicji ról niestandardowych

  • Utworzone nowe role niestandardowe

• Niestandardowe reguły rozdzielenia obowiązków - jeśli Twoja organizacja ustanowiła jakiekolwiek reguły rozdzielenia obowiązków, użyj niekompatybilnych pakietów dostępu Microsoft Entra Entitlement Management, aby wymusić rozdzielenie obowiązków, a także utwórz alerty lub skonfiguruj okresowe przeglądy w celu wykrywania naruszeń przez administratorów.

Inne zagadnienia dotyczące monitorowania — subskrypcje platformy Azure zawierające zasoby używane do zarządzania dziennikami powinny być traktowane jako infrastruktura krytyczna (warstwa 0) i zablokowane przez zespół ds. operacji zabezpieczeń odpowiedniego środowiska. Rozważ użycie narzędzi, takich jak usługa Azure Policy, aby wymusić dodatkowe mechanizmy kontroli dla tych subskrypcji.

Narzędzia operacyjne

Wielośrodowiskowe zagadnienia dotyczące projektowania narzędzi :

• Jeśli to możliwe, narzędzia operacyjne, które będą używane w wielu dzierżawach, powinny być zaprojektowane tak, aby działały jako aplikacja Microsoft Entra dla wielu dzierżaw, aby uniknąć ponownego wdrażania wielu instancji w każdej dzierżawie i zredukować nieefektywności operacyjne. Implementacja powinna obejmować logikę autoryzacji w programie w celu zapewnienia zachowania izolacji między użytkownikami a danymi.

• Dodaj alerty i detekcje, aby monitorować automatyzację międzyśrodowiskową (na przykład aprowizację tożsamości) i limity progowe dla zabezpieczeń awaryjnych. Na przykład możesz potrzebować alertu, jeśli usuwanie kont użytkowników osiągnie określony poziom, ponieważ może to wskazywać na usterkę lub błąd operacyjny, który może mieć dalekosiężne skutki.

• Każda automatyzacja, która organizuje zadania między środowiskami, powinna być obsługiwana jako wysoce uprzywilejowany system. Ten system powinien być umieszczony w środowisku o najwyższym poziomie zabezpieczeń i pozyskiwać dane ze źródeł zewnętrznych, jeśli wymagane są dane z innych środowisk. Aby zachować integralność systemu, należy zastosować walidację danych i progi. Typowym zadaniem między środowiskami jest zarządzanie cyklem życia tożsamości polegające na usuwaniu ich ze wszystkich środowisk dla pracownika, który zakończył pracę.

Narzędzia do zarządzania usługami IT — organizacje korzystające z systemów zarządzania usługami IT (ITSM), takich jak ServiceNow, powinny skonfigurować ustawienia aktywacji roli Microsoft Entra PIM, aby zażądać numeru biletu w ramach celów aktywacji.

Podobnie usługa Azure Monitor może być zintegrowana z systemami ITSM za pośrednictwem łącznika zarządzania usługami IT.

Praktyki operacyjne — minimalizuj działania operacyjne, które wymagają bezpośredniego dostępu do środowiska do tożsamości ludzkich. Zamiast tego, zamodeluj je jako Azure Pipelines, które wykonują typowe operacje (na przykład dodają pojemność do rozwiązania PaaS, uruchamiają diagnostykę itd.) i zamodeluj bezpośredni dostęp do interfejsów Azure Resource Manager w scenariuszach "break glass".

Wyzwania związane z operacjami

• Działanie monitorowania jednostki usługi jest ograniczone w niektórych scenariuszach

• Alerty usługi Microsoft Entra PIM nie mają interfejsu API. Ograniczenie ryzyka polega na regularnym przeglądzie tych alertów PIM.

• Witryna Azure EA Portal nie zapewnia możliwości monitorowania. Środkiem zaradczym jest założenie dedykowanych kont administracyjnych i monitorowanie aktywności konta.

• Umowa MCA nie udostępnia dzienników audytu dla zadań rozliczeniowych. Środkiem zaradczym jest założenie dedykowanych kont administracyjnych i monitorowanie aktywności konta.

• Niektóre usługi na platformie Azure potrzebne do obsługi środowiska muszą zostać ponownie wdrożone i ponownie skonfigurowane w środowiskach, ponieważ nie mogą być wielodostępne ani wielochmurowe.

• Nie ma pełnego pokrycia API w Microsoft Online Services, co uniemożliwia pełne wdrożenie infrastruktury jako kod. Ograniczenie ryzyka polega na jak największym korzystaniu z API i używaniu portali do pozostałych celów. Ta inicjatywa open source ułatwia określenie podejścia, które może działać w danym środowisku.

• Nie ma możliwości programistycznej odkrycia dzierżaw zasobów, które mają zdelegowany dostęp do subskrypcji w zarządzającej dzierżawie. Jeśli na przykład adres e-mail włączył grupę zabezpieczeń w dzierżawie contoso.com do zarządzania subskrypcjami w dzierżawie fabrikam.com, administratorzy w contoso.com nie mają interfejsu API umożliwiającego wykrycie, że to delegowanie miało miejsce.

• Określone monitorowanie aktywności konta (na przykład awaryjne konto, konto rozliczeniowe) nie jest dostępne od razu. Środek zaradczy polega na tym, że klienci tworzą własne reguły alertów.

• Monitorowanie konfiguracji dla całej dzierżawy nie jest dostępne od razu. Środek zaradczy polega na tym, że klienci tworzą własne reguły alertów.

Następne kroki

• Wprowadzenie do delegowanej administracji i środowisk izolowanych

• Microsoft Entra fundamentals

• Podstawy zarządzania zasobami platformy Azure

• Izolacja zasobów w jednokrotnym użytkowniku

• Izolacja zasobów z wieloma najemcami