Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące wszystkich architektur izolacji

  • Artykuł

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 firmy Microsoft Entra (izolowanych lub nie), zapoznaj się z przewodnikiem wdrażania funkcji firmy Microsoft Entra.

Uwaga

W przypadku wszystkich izolowanych dzierżaw zalecamy użycie jasnej i zróżnicowanej znakowania, aby uniknąć błędu ludzkiego pracy w niewłaściwej dzierżawie.

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 dostępu warunkowego i filtruj dla urządzeń jako warunku.

  • 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 obszar ataku na powierzchnię, chroniąc bazowe 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 w zakresie katalogu zamiast określania zakresu jednostek AU) lub ról katalogu specyficznych dla usługi z akcjami płaszczyzny sterowania (administrator wiedzy z uprawnieniami do zarządzania członkostwem w grupach zabezpieczeń).

Oprócz wskazówek w przewodniku po ogólnych operacjach firmy Microsoft zalecamy również następujące zagadnienia dotyczące izolowanych środowisk.

Aprowizowanie tożsamości przez człowieka

Uprzywilejowane konta

Aprowizuj konta w izolowanym środowisku dla personelu administracyjnego i zespołów IT, które obsługują ś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 wykorzystywać współpracę firmy Microsoft Entra B2B do dołączania uprzywilejowanych kont do dzierżaw nieprodukcyjnych przy użyciu tej samej postawy 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 jednak istnieje istniejąca infrastruktura lokalna odpowiadająca izolowanemu środowisku (na przykład w środowisku przedprodukcyjnym lub zarządzaniu lasem usługi 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.

Uwaga

Nie ma żadnych kontroli technicznych do sprawdzania tożsamości dla kont Microsoft Entra B2B. Tożsamości zewnętrzne aprowidowane za pomocą usługi Microsoft Entra B2B są uruchamiane przy użyciu jednego czynnika. Ograniczenie ryzyka polega na tym, że organizacja ma proces weryfikacji wymaganych tożsamości przed wystawieniem zaproszenia B2B oraz regularne przeglądy dostępu tożsamości zewnętrznych do zarządzania cyklem życia. Rozważ włączenie zasad dostępu warunkowego w celu kontrolowania rejestracji uwierzytelniania wieloskładnikowego.

Outsourcing ról wysokiego ryzyka

Aby wyeliminować zagrożenia wewnętrzne, można przekazać dostęp do ról administratorów globalnych i administratorów ról uprzywilejowanych, aby być dostawcą usług zarządzanych przy użyciu współpracy B2B platformy Azure lub delegowania dostępu za pośrednictwem partnera CSP lub latarni morskiej. 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.

Inicjowanie obsługi administracyjnej 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ą ograniczone do scenariuszy awaryjnych lub "break glass", w których nie można używać zwykłych kont lub wszyscy inni administratorzy są przypadkowo zablokowani. Te konta należy utworzyć zgodnie z zaleceniami dotyczącymi konta 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 są możliwe, rozważ aprowizowanie obiektów jednostki 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 jednostki usługi (SP) użyj certyfikatu jako poświadczenia lub chroń dostawcę usługi 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 licencjonowania i grup zabezpieczeń opartych na grupach dla usługi firmy Microsoft, które polegają na użytkowniku z przypisaniem miejsca licencji jako wymaganiem wstępnym przed udostępnieniem dostępu (na przykład Dynamics 365, Power BI).

Grupy natywne chmury Firmy Microsoft Entra 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.

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 użytkowników końcowych.

Niektóre scenariusze mogą wymagać udzielenia dostępu do zasobów lokalnych za pośrednictwem lokalna usługa Active Directory grup zabezpieczeń. W takich przypadkach należy wziąć pod uwagę cykl synchronizacji z identyfikatorem Entra firmy Microsoft podczas projektowania umów SLA 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 poświadczenia

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 lasu lokalna usługa Active Directory, należy wdrożyć ochronę haseł firmy 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 ludzkich i testowych z hasłami, aby odwrócić połączenia pomocy technicznej.

Hasła tożsamości zewnętrznych

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

Uwaga

Niektóre aplikacje, infrastruktura lub przepływy pracy mogą wymagać poświadczeń lokalnych. Oceń to na podstawie wielkości liter.

Poświadczenia jednostek usługi

W przypadku scenariuszy, w których są potrzebne jednostki usługi, użyj poświadczeń certyfikatu dla jednostek usługi lub dostępu warunkowego dla tożsamości obciążeń. W razie potrzeby należy użyć wpisów tajnych klienta jako wyjątku do zasad 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 Platformy Windows 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 dołączone do izolowanych środowisk muszą mieć jawne zasady dostępu warunkowego stosowane w ramach procesu dołączania.

  • Zdefiniuj zasady dostępu warunkowego na potrzeby rejestracji informacji zabezpieczających, która odzwierciedla bezpieczny katalog główny procesu 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 aprowidowane za pomocą usługi Microsoft Entra B2B mogą wymagać ponownego aprowizowania poświadczeń uwierzytelniania wieloskładnikowego w dzierżawie zasobów. Może to być konieczne, jeśli nie skonfigurowano zasad dostępu między dzierżawami w dzierżawie zasobów. Oznacza to, że dołączanie do systemu jest uruchamiane przy użyciu jednego czynnika. Dzięki temu podejściu ograniczenie ryzyka jest przeznaczone dla organizacji w celu weryfikacji profilu ryzyka użytkownika i poświadczeń przed wystawieniem zaproszenia B2B. Ponadto zdefiniuj dostęp warunkowy do procesu rejestracji zgodnie z wcześniejszym opisem.

  • Użyj ustawień dostępu tożsamości zewnętrznych między dzierżawami, aby zarządzać sposobem współpracy z innymi organizacjami firmy Microsoft Entra i innymi chmurami platformy Microsoft Azure za pośrednictwem współpracy B2B i bezpośredniego połączenia B2B.

  • 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 przedstawiono niektóre zasady zapewniania ładu tożsamości, które należy wziąć pod uwagę we wszystkich konfiguracjach dzierżawy na potrzeby izolacji.

  • Brak stałego dostępu — żadne tożsamości człowieka nie powinny 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ę just in time określaną przez bramy 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 uprawnienia wymagane do wykonywania operacji uprzywilejowanych na rolę w organizacji.

    • Role niestandardowe RBAC platformy Azure umożliwiają projektowanie ról o najniższych 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żna przeprowadzić inspekcję za pomocą usługi 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, różnymi atakami personifikacji i kradzieżą poświadczeń, takimi jak rejestrowanie naciśnięć, przekazywanie skrótu i przekazywanie biletu.

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 z rolami katalogu Entra firmy Microsoft, które nie powinny być odpowiedzialne za zarządzanie rolami uprzywilejowanymi usługi Azure Resource Manager itd.

    • Określa, czy bezpośrednie przypisania użytkowników lub grup są preferowane dla 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świadczanie — tożsamości, które posiadają uprzywilejowane role, należy okresowo przeglądać, aby zachować bieżące i uzasadnione członkostwo. 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 dzierżawy

  • Zalecamy zaimplementowanie procesu w celu zażądania nowej firmowej dzierżawy firmy Microsoft Entra. Proces powinien uwzględniać następujące celach:

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

    • Chmura platformy Azure, w której powinna zostać utworzona (na przykład Commercial, Government itd.).

    • 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 firmy Microsoft Entra zostanie utworzona, skonfigurowana przy użyciu niezbędnych mechanizmów kontroli punktu odniesienia i dołączona na płaszczyźnie rozliczeń, monitorowaniu itd.

  • Aby wykrywać i odnajdywać tworzenie dzierżaw dzierżawy poza zarządzanym procesem, należy wdrożyć regularne przegląd dzierżawy w płaszczyźnie rozliczeń. Aby uzyskać więcej informacji, zapoznaj się z sekcją Spis i widoczność tego dokumentu.

  • Tworzenie dzierżawy usługi Azure AD B2C można kontrolować przy użyciu usługi Azure Policy. Zasady są wykonywane, gdy subskrypcja platformy Azure jest skojarzona z dzierżawą B2C (wymaganie wstępne dotyczące rozliczeń). Klienci mogą ograniczyć tworzenie dzierżaw usługi Azure AD B2C do określonych grup zarządzania.

  • Nie ma żadnych kontroli technicznych w celu podwładnego tworzenia dzierżaw w 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. Te informacje taksonomii określą:

    • Dzierżawa firmy Microsoft Entra w celu aprowizacji subskrypcji

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

    • Konwencja nazewnictwa

    • Przypisanie 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ć aprowizację subskrypcji autoryzowanym użytkownikom i wymusić cele zasad i taksonomii. Wskazówki dotyczące następujących podmiotów zabezpieczeń AZOps mogą służyć do tworzenia praktycznego rozwiązania.

  • Po aprowizacji subskrypcji utwórz grupy chmury Firmy Microsoft Entra, aby przechowywać standardowe role usługi 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 dostępem uprzywilejowanym na dużą skalę.

    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 zabezpieczenia nie należy przypisywać właścicieli produktów do ról administratorów dostępu użytkowników ani właścicieli, aby uniknąć nieumyślnego bezpośredniego przypisywania ról poza firmą Microsoft Entra PIM ani potencjalnie 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ę koligację dzierżawy z subskrypcjami platformy Azure, aprowizowanie subskrypcji powinno mieć świadomość wielu tożsamości dla tego samego aktora ludzkiego (pracownika, partnera, dostawcy itd.) w wielu dzierżawach i odpowiednio przypisz dostęp.

Role umowy EA i umowy MCA

  • Portal umowy Azure Enterprise (Azure EA) nie integruje się z kontrolą dostępu opartego na rolach platformy Azure ani dostępu warunkowego. 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 podlegający aprowizacji subskrypcji z zagadnieniami opisanymi powyżej i użyj dedykowanych kont EA i przeprowadź inspekcję dzienników uwierzytelniania.

  • role Umowa 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 dzierżawy usługi Azure AD B2C nie są zintegrowane z przeglądami dostępu firmy 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 własność logiczna podstawowej subskrypcji firmy Microsoft Entra dzierżawy B2C była zgodna z zespołami inżynierów CIAM w taki sam sposób, jak pozostałe subskrypcje platformy Azure są używane dla rozwiązań 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 przestarzałe środowiska.

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

  • Płaszczyzna rozliczeń (EA Portal/MCA) stan zabezpieczeń, stan operacyjny i podejście delegowania.

  • Proces tworzenia dzierżawy.

  • Taksonomia aplikacji dla przedsiębiorstw.

  • Proces aprowizacji subskrypcji platformy Azure.

  • Granice autonomii izolacji i administracji 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 dzierżawy — konkretny zespół powinien być właścicielem tworzenia dzierżawy zgodnie ze standardowymi procedurami zdefiniowanymi przez architekturę SecOps dla całego przedsiębiorstwa. Obejmuje to:

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

  • Dołączanie do firmowego planu rozliczeniowego (na przykład umowy EA platformy Azure lub umowy 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ń na uzgodnioną architekturę cyberbezpieczeństwa, w tym ustawienia diagnostyczne, dołączanie rozwiązania SIEM, dołączanie casb, dołączanie do usługi PIM itd.

  • Konfiguracja ról firmy 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 między środowiskami — niektóre narzędzia, takie jak aprowizowanie tożsamości i potoki kontroli źródła, mogą wymagać pracy w wielu środowiskach. Te narzędzia powinny być traktowane jako krytyczne dla infrastruktury i muszą być zaprojektowane, zaprojektowane, 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.

Spis i widoczność

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

Uwaga

Ta akcja jest wysoce uprzywilejowana i może zapewnić administratorowi dostęp do subskrypcji, które przechowują bardzo poufne informacje, jeśli te dane nie zostały prawidłowo odizolowane.

Włączanie dostępu do odczytu w celu odnajdywania zasobów — grupy zarządzania umożliwiają przypisywanie kontroli dostępu opartej na rolach na dużą skalę w wielu subskrypcjach. Klienci mogą udzielić roli Czytelnik scentralizowanemu zespołowi IT, konfigurując przypisanie roli w głównej grupie zarządzania, 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ć wymagania prawne, które ograniczają, które dane (jeśli istnieją) mogą pozostawić dane w danym środowisku. 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 między środowiskami na potrzeby inspekcji i śledczego, takich jak próby przenoszenia bocznego między środowiskami. Zaleca się, aby unikatowy identyfikator obiektu tożsamości człowieka należący do tej samej osoby był wykrywalny, potencjalnie jako część systemów aprowizacji tożsamości.

Strategia dziennika musi zawierać następujące dzienniki firmy Microsoft Entra dla każdej dzierżawy używanej w organizacji:

  • Aktywność związana z logowaniem

  • Dzienniki inspekcji

  • Zdarzenia o podwyższonym ryzyku

Identyfikator entra firmy Microsoft 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ą włączać 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

  • Agenci serwer proxy aplikacji

  • Agenci zapisywania zwrotnego haseł

  • Maszyny bramy ochrony haseł

  • Serwer zasad sieciowych z rozszerzeniem RADIUS uwierzytelniania wieloskładnikowego firmy Microsoft

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.

Przechowywanie magazynu dzienników — wszystkie środowiska powinny mieć spójną strategię przechowywania, projektowanie i implementację magazynu dzienników w celu ułatwienia spójnego zestawu narzędzi (na przykład systemów SIEM, takich jak Azure Sentinel), typowych zapytań, badania i podręczników kryminalistycznych. 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ń. Wszystkie dzierżawy powinny definiować sieci nazwane lokalizacje , aby uniknąć hałaśliwych wykryć 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 aprowizowana tożsamość (na przykład jeśli tożsamość człowieka 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 analizy behawioralnej jednostki użytkownika (UEBA) — analiza UEBA powinna służyć do uzyskiwania szczegółowych informacji na podstawie wykrywania anomalii. Usługa Microsoft Microsoft 365 Defender dla Chmury Apps zapewnia analizę UEBA w chmurze. Klienci mogą zintegrować lokalną analizę UEBA z usługi Microsoft Microsoft 365 Defender for Identity. Usługa MCAS odczytuje sygnały z Ochrona tożsamości Microsoft Entra.

  • 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 zarządzania rozliczeniami — biorąc pod uwagę wrażliwość kont z rolami zarządzania rozliczeniami w ramach umowy EA platformy Azure lub umowy MCA oraz ich znaczących uprawnień, zaleca się monitorowanie i zgłaszanie alertów:

    • Próby logowania według kont z rolami rozliczeniowymi.

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

    • Każda próba uwierzytelnienia w aplikacjach innych niż usługa Azure Resource Management w przypadku korzystania z dedykowanych kont dla zadań rozliczeniowych umowy MCA.

    • Przypisywanie do zasobów platformy Azure przy użyciu dedykowanych kont dla zadań rozliczeniowych umowy MCA.

  • Działanie roli uprzywilejowanej — konfigurowanie i przeglądanie alertów zabezpieczeń generowanych przez usługę Microsoft Entra PIM. Jeśli blokowanie bezpośrednich przypisań kontroli dostępu opartej na rolach nie jest w pełni wymuszane za pomocą kontroli technicznej (na przykład rola właściciela musi zostać udzielona zespołom produktu w celu wykonania swojej pracy), monitoruj bezpośrednie przypisywanie ról uprzywilejowanych poza usługą PIM, generując alerty, gdy użytkownik jest przypisany bezpośrednio do subskrypcji za pomocą kontroli dostępu opartej na rolach platformy Azure.

  • Przypisania ról klasycznych — organizacje powinny używać nowoczesnej infrastruktury roli RBAC platformy 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 dozwolone dostawcy tożsamości (dostawcy tożsamości SAML za pośrednictwem federacji bezpośredniej lub logowania społecznościowego)

    • Zmiany zasad dostępu warunkowego

  • Application and service principal objects (Obiekty aplikacji i jednostki usługi)

    • 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 mg

    • Zasady platformy Azure stosowane w usłudze MG

    • Subskrypcje przeniesione między grupami zabezpieczeń

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

  • Role niestandardowe

    • Aktualizacje definicji ról niestandardowych

    • Utworzone nowe role niestandardowe

  • Niestandardowe rozdzielenie reguł obowiązków — jeśli organizacja ustanowiła jakiekolwiek rozdzielenie reguł obowiązków, użyj niezgodnych pakietów dostępu do zarządzania upoważnieniami firmy Microsoft, aby wymusić rozdzielenie obowiązków, a także utworzyć alerty lub skonfigurować 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

Zagadnienia dotyczące projektowania narzędzi między środowiskami :

  • 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 wielodostępna firmy Microsoft, aby uniknąć ponownego wdrażania wielu wystąpień w każdej dzierżawie i uniknąć nieefektywności operacyjnej. Implementacja powinna obejmować logikę autoryzacji w programie w celu zapewnienia zachowania izolacji między użytkownikami a danymi.

  • Dodaj alerty i wykrycia, aby monitorować wszystkie automatyzacje między środowiskami (na przykład aprowizację tożsamości) i limity progowe dla bezpieczeństwa w przypadku awarii. Na przykład może być potrzebny alert, jeśli anulowanie aprowizacji 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ć szeroki wpływ.

  • Każda automatyzacja, która organizuje zadania między środowiskami, powinna być obsługiwana jako wysoce uprzywilejowany system. Ten system powinien być obsługiwany do najwyższego środowiska zabezpieczeń i ściągać 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 w celu usunięcia tożsamości ze wszystkich środowisk dla zakończonego pracownika.

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 modelować je jako usługę Azure Pipelines, która wykonuje typowe operacje (na przykład dodać pojemność do rozwiązania PaaS, uruchomić diagnostykę itd.) i modelować bezpośredni dostęp do interfejsów usługi 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. Środki zaradcze mają dedykowane konta administracyjne i monitorują aktywność konta.

  • Umowa MCA nie udostępnia dzienników inspekcji dla zadań rozliczeniowych. Środki zaradcze mają dedykowane konta administracyjne i monitorują aktywność 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 interfejsu API w usługach Microsoft Online Services, aby w pełni osiągnąć infrastrukturę jako kod. Ograniczenie ryzyka polega na jak największej korzystaniu z interfejsów API i używaniu portali w pozostałej części. Ta inicjatywa open source ułatwia określenie podejścia, które może działać w danym środowisku.

  • Nie ma możliwości programowych odnajdywania dzierżaw zasobów, które mają delegowany dostęp subskrypcji do tożsamości w dzierżawie zarządzającej. 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 konto break-glass, konto zarządzania rozliczeniami) nie jest dostarczane z pudełka. Środki zaradcze są przeznaczone dla klientów w celu utworzenia własnych reguł alertów.

  • Monitorowanie konfiguracji dla całej dzierżawy nie jest gotowe. Środki zaradcze są przeznaczone dla klientów w celu utworzenia własnych reguł alertów.

Następne kroki