Udostępnij za pośrednictwem

Tożsamość strefy docelowej i zarządzanie dostępem

  • Artykuł

Po zidentyfikowaniu architektury tożsamości należy zarządzać autoryzacją i dostępem do zasobów w strefach docelowych aplikacji i platformy. Zastanów się, które zasoby każdy uwierzytelniony podmiot zabezpieczeń ma dostęp do zasobów i do których potrzebuje dostępu, oraz jak ograniczyć ryzyko nieautoryzowanego dostępu do zasobów. Aby uzyskać więcej informacji, zobacz Projekt architektury tożsamości.

Omówienie

Obszar projektowania zarządzania tożsamościami i dostępem zawiera wskazówki ułatwiające implementowanie modelu dostępu przedsiębiorstwa na platformie Azure oraz implementowanie i zabezpieczanie płaszczyzn kontroli. Po włączeniu zasady projektowania demokratyzacji subskrypcji zespół aplikacji może zarządzać własnymi obciążeniami w ramach środków zabezpieczających zasad ustawianych przez zespół platformy. Takie podejście jest również zgodne z zasadą ładu opartą na zasadach.

Zespół platformy jest odpowiedzialny za aprowizowanie nowych stref docelowych lub subskrypcji aplikacji. Podczas aprowizowania strefy docelowej dla właściciela aplikacji zespół platformy powinien skonfigurować ją przy użyciu odpowiednich mechanizmów kontroli dostępu, aby właściciel aplikacji mógł zarządzać własnymi zasobami. Właściciel aplikacji powinien mieć możliwość tworzenia użytkowników i grup oraz zarządzania nimi w ramach identyfikatora Entra firmy Microsoft oraz przypisywania ról do tych użytkowników i grup. Właściciel aplikacji może następnie zarządzać dostępem do własnych zasobów i delegować dostęp do innych użytkowników i grup zgodnie z potrzebami. Strefa docelowa powinna również mieć opcjonalną łączność sieciową z usługami domena usługi Active Directory (AD DS) lub Microsoft Entra Domain Services w subskrypcji Platforma tożsamości Microsoft w zależności od wymagań aplikacji.

Użyj kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby zarządzać dostępem administracyjnym do zasobów platformy Azure. Zastanów się, czy użytkownicy wymagają uprawnień w wąskim zakresie, takim jak administrator pojedynczej aplikacji, czy szerokiego zakresu, takiego jak administrator sieci w wielu obciążeniach aplikacji. W obu przypadkach postępuj zgodnie z zasadą wystarczającego dostępu i upewnij się, że użytkownik ma tylko role wymagane do normalnego działania. Użyj ról niestandardowych i usługi Microsoft Entra Privileged Identity Management (PIM), jeśli jest to konieczne, aby wymusić dostęp just in time (JIT). Mimo że zespół platformy jest odpowiedzialny za podstawy zarządzania tożsamościami i dostępem, zarówno zespoły platformy, jak i aplikacji są konsumentami usługi i powinny przestrzegać tych samych zasad.

Zarządzanie tożsamościami i dostępem jest ważne w przypadku pomyślnego oddzielenia jednej strefy docelowej od innej i izolacji obciążeń w organizacji. Jest to krytyczny obszar projektowania zarówno dla stref docelowych platformy, jak i aplikacji.

Jeśli twoja organizacja korzysta z procesu sprzedaży subskrypcji, możesz zautomatyzować wiele konfiguracji tożsamości i dostępu dla stref docelowych aplikacji. Zaimplementuj sprzedaż abonamentów, aby ułatwić standaryzację tworzenia strefy docelowej, dzięki czemu zespoły aplikacji mogą zarządzać własnymi zasobami.

Uwagi dotyczące projektowania

Niektóre organizacje współdzielą usługi między wieloma aplikacjami. Na przykład może istnieć scentralizowana usługa integracji używana przez kilka niezależnych aplikacji. W tym scenariuszu należy rozważyć, które usługi są zarządzane centralnie i które są przekazane zespołom aplikacji, i zrozumieć, gdzie należy wymuszać granice zabezpieczeń. Zapewnienie zespołom aplikacji dostępu administracyjnego do usługi udostępnionej może być przydatne w przypadku produktywności deweloperów, ale może zapewnić więcej dostępu niż jest to wymagane.

Zarządzanie zasobami aplikacji, które nie przekraczają granic zabezpieczeń, można delegować do zespołów aplikacji. Rozważ delegowanie innych aspektów, które są wymagane do utrzymania zabezpieczeń i zgodności, jak również. Umożliwienie użytkownikom aprowizacji zasobów w bezpiecznym środowisku zarządzanym umożliwia organizacjom korzystanie z elastycznego charakteru chmury i zapobieganie naruszeniu wszelkich krytycznych zabezpieczeń lub granic ładu.

RBAC

Ważne

Zasoby klasyczne i administratorzy klasyczni wycofują się 31 sierpnia 2024 r. Usuń niepotrzebnych współadministratorów i użyj kontroli dostępu na podstawie ról platformy Azure w celu uzyskania szczegółowej kontroli dostępu.

Zapoznaj się z różnicą między rolami identyfikatora entra firmy Microsoft i rolami RBAC platformy Azure.

  • Role identyfikatora entra firmy Microsoft kontrolują uprawnienia administracyjne do usług obejmujących całą dzierżawę, takich jak Microsoft Entra ID, i inne usługi firmy Microsoft, w tym Microsoft Teams, Microsoft Exchange Online i Microsoft Intune.

  • Role RBAC platformy Azure kontrolują uprawnienia administracyjne do zasobów platformy Azure, takich jak maszyny wirtualne, subskrypcje i grupy zasobów.

  • Role Właściciel kontroli dostępu na podstawie ról platformy Azure i Administrator dostępu użytkowników mogą modyfikować przypisania ról w zasobach platformy Azure. Domyślnie rola administratora globalnego firmy Microsoft Entra nie ma uprawnień do zarządzania dostępem do zasobów platformy Azure. Musi być jawnie włączona. Aby uzyskać więcej informacji, zobacz Podnoszenie poziomu dostępu w celu zarządzania wszystkimi subskrypcjami platformy Azure i grupami zarządzania.

Ważne

Firma Microsoft zaleca używanie ról z najmniejszymi uprawnieniami. Pomaga to zwiększyć bezpieczeństwo organizacji. Administrator globalny to wysoce uprzywilejowana rola, która powinna być ograniczona do scenariuszy awaryjnych, gdy nie można użyć istniejącej roli.

Na poniższym diagramie przedstawiono relację między rolami identyfikatora entra firmy Microsoft i rolami RBAC platformy Azure:

Diagram przedstawiający relację między rolami Microsoft Entra ID i Azure RBAC.

  • Możesz utworzyć grupy z możliwością przypisania ról i przypisać role firmy Microsoft Entra do grup , jeśli ustawisz isAssignableToRole właściwość na true. Chronione są tylko grupy z tym zestawem właściwości. Jedynymi rolami, które mogą modyfikować członkostwo grupy, są administratorzy globalni, administratorzy ról uprzywilejowanych lub właściciel grupy.

  • Tylko niektóre role mogą resetować ustawienia uwierzytelniania wieloskładnikowego lub hasła dla innego administratora. To ograniczenie uniemożliwia nieautoryzowanym administratorom resetowanie poświadczeń konta z wyższymi uprawnieniami w celu uzyskania większej liczby uprawnień.

  • Jeśli wbudowane role platformy Azure nie spełniają konkretnych potrzeb organizacji, możesz utworzyć własne role niestandardowe. Podobnie jak role wbudowane, role niestandardowe można przypisywać do użytkowników, grup i jednostek usługi w zakresach dzierżawy, grupy zarządzania, subskrypcji i grupy zasobów. W razie potrzeby należy używać wbudowanych ról platformy Azure i tworzyć role niestandardowe tylko wtedy, gdy jest to konieczne.

  • Podczas projektowania strategii kontroli dostępu należy znać limity usługi dla ról, przypisań ról i ról niestandardowych.

  • Niektóre role RBAC platformy Azure obsługują kontrolę dostępu opartą na atrybutach (ABAC) lub warunki przypisywania ról. W przypadku używania warunków administratorzy mogą dynamicznie przypisywać role na podstawie atrybutów zasobu. Można na przykład przypisać rolę Współautor danych obiektu blob usługi Storage, ale tylko dla obiektów blob, które mają określony tag indeksu, a nie wszystkie obiekty blob w kontenerze.

  • Możesz użyć wbudowanych i niestandardowych ról RBAC z uprawnieniami Microsoft.Authorization/roleAssignments/write lub Microsoft.Authorization/roleAssignments/delete do tworzenia, usuwania i aktualizowania przypisań ról. Każda osoba, która ma tę rolę, może zdecydować, kto ma uprawnienia do zapisu, odczytu i usuwania dla dowolnego zasobu w zakresie przypisania. Członkowie zespołu ds. strefy docelowej platformy lub aplikacji powinni rozważyć delegowanie ról uprzywilejowanych do innych użytkowników i grup w celu udzielenia im niezbędnej autonomii. Aby zapewnić zgodność z zasadami dostępu z najmniejszymi uprawnieniami, mogą używać warunków do delegowania użytkowników.

Zalecenia dotyczące projektowania

Zalecenia ogólne

  • Wymuszanie uwierzytelniania wieloskładnikowego firmy Microsoft (MFA) dla użytkowników, którzy mają prawa do środowiska platformy Azure, w tym subskrypcji platformy, subskrypcji aplikacji i dzierżawy microsoft Entra ID. Wiele struktur zgodności wymaga wymuszania uwierzytelniania wieloskładnikowego. Uwierzytelnianie wieloskładnikowe pomaga zmniejszyć ryzyko kradzieży poświadczeń i nieautoryzowanego dostępu. Aby zapobiec nieautoryzowanemu dostępowi do poufnych informacji, upewnij się, że użytkownicy mają role czytelnika w zasadach uwierzytelniania wieloskładnikowego.

  • Użyj zasad dostępu warunkowego firmy Microsoft dla użytkowników, którzy mają prawa do środowiska platformy Azure. Dostęp warunkowy to kolejna funkcja, która pomaga chronić kontrolowane środowisko platformy Azure przed nieautoryzowanym dostępem. Administratorzy aplikacji i platformy powinni mieć zasady dostępu warunkowego, które odzwierciedlają profil ryzyka swojej roli. Na przykład mogą istnieć wymagania dotyczące wykonywania działań administracyjnych tylko z określonych lokalizacji lub określonych stacji roboczych. Lub tolerancja ryzyka logowania dla użytkowników z dostępem administracyjnym do zasobów platformy Azure może być niższa niż w przypadku standardowych użytkowników identyfikatora Entra firmy Microsoft.

  • Włącz usługę Microsoft Defender for Identity , aby chronić tożsamości użytkowników i zabezpieczać poświadczenia użytkownika. Usługa Defender for Identity jest częścią usługi Microsoft Defender XDR. Usługa Defender for Identity umożliwia identyfikowanie podejrzanych działań użytkowników i uzyskiwanie osi czasu zdarzeń. Można go również używać z dostępem warunkowym w celu odmowy prób uwierzytelniania wysokiego ryzyka. Wdróż czujniki usługi Defender for Identity na lokalnych kontrolerach domeny i kontrolerach domeny w subskrypcji tożsamości platformy Azure.

  • Użyj usługi Microsoft Sentinel , aby zapewnić możliwości analizy zagrożeń i śledcze. Usługa Sentinel używa dzienników z dzienników usługi Azure Monitor, identyfikatora Microsoft Entra ID, platformy Microsoft 365 i innych usług w celu zapewnienia proaktywnego wykrywania zagrożeń, badania i reagowania.

  • Oddziel dostęp administracyjny od dostępu nieadministracyjnego, codziennego dostępu, takiego jak przeglądanie internetu i dostęp do poczty e-mail. Sieć Web i poczta e-mail są typowymi wektorami ataków. Po naruszeniu zabezpieczeń konta użytkownika jest mniej prawdopodobne, aby spowodować naruszenie zabezpieczeń, jeśli konto nie jest używane do dostępu administracyjnego.

    • Używaj oddzielnych kont tylko w chmurze dla ról uprzywilejowanych. Nie używaj tego samego konta do codziennego użytku w przypadku administracji uprzywilejowanej. Uprzywilejowane role Microsoft Entra ID i RBAC platformy Azure są oznaczone jako PRIVILEGED w witrynie Azure Portal i w dokumentacji.

    • W przypadku ról funkcji zadań nieuprzywilejowanych, które mogą zarządzać zasobami aplikacji platformy Azure, należy rozważyć, czy potrzebujesz oddzielnych kont administracyjnych, czy używasz usługi Microsoft Entra PIM do kontrolowania dostępu administracyjnego. Usługa PIM zapewnia, że konto ma wymagane uprawnienia tylko w razie potrzeby i że uprawnienia zostaną usunięte po zakończeniu zadania (nazywanego również dostępem just in time).

  • Aby ułatwić zarządzanie przypisaniami ról, nie przypisz ról bezpośrednio do użytkowników. Zamiast tego przypisz role do grup, aby zminimalizować liczbę przypisań ról, które mają limit dla każdej subskrypcji.

    • Użyj usługi Microsoft Entra PIM dla grup , aby zastosować mechanizmy kontroli dostępu administracyjnego just in time do uprzywilejowanych użytkowników. Rozważ kontrolowanie członkostwa w grupie przy użyciu zarządzania upoważnieniami. Możesz użyć funkcji zarządzania upoważnieniami, aby dodać przepływy pracy zatwierdzania i inspekcji do operacji członkostwa w grupach i pomóc w zapewnieniu, że członkowie grupy administracyjnej nie zostaną niepotrzebnie dodani ani usunięci.

    • W przypadku udzielania dostępu do zasobów użyj grup tylko firmy Microsoft dla zasobów płaszczyzny sterowania platformy Azure. Zarówno użytkownicy i grupy tylko w usłudze Entra, jak i te synchronizowane ze środowiska lokalnego przy użyciu programu Microsoft Entra Connect, można dodać do grupy tylko w usłudze Entra. Dodaj grupy lokalne do grupy tylko firmy Microsoft, jeśli system zarządzania grupami jest już w miejscu. Korzystanie z grup tylko w usłudze Entra pomaga chronić płaszczyznę sterowania chmurą przed nieautoryzowaną modyfikacją lokalnych usług katalogowych. Należy pamiętać, że tylko firma Microsoft Entra jest znana jako tylko chmura.

  • Utwórz konta dostępu awaryjnego lub konta typu break-glass, aby uniknąć przypadkowego zablokowania z organizacji microsoft Entra ID. Konta dostępu awaryjnego są wysoce uprzywilejowane i są przypisywane tylko do określonych osób. Przechowuj poświadczenia dla kont bezpiecznie, monitoruj ich użycie i regularnie testuj je, aby upewnić się, że można ich używać, jeśli wystąpi awaria.

    Aby uzyskać więcej informacji, zobacz Secure access practices for administrators in Microsoft Entra ID (Praktyki bezpiecznego dostępu dla administratorów w usłudze Microsoft Entra ID).

Zalecenia dotyczące identyfikatora entra firmy Microsoft

  • Zintegruj identyfikator entra firmy Microsoft z usługą Azure Monitor , aby umożliwić analizowanie aktywności logowania i dziennik inspekcji zmian w dzierżawie. Skonfiguruj ustawienie diagnostyczne, aby wysyłać dzienniki logowania i dzienniki inspekcji do centralnego obszaru roboczego Dzienniki usługi Azure Monitor platformy w subskrypcji zarządzania.

  • Użyj funkcji zarządzania upoważnieniami Zarządzanie tożsamością Microsoft Entra, aby utworzyć pakiety dostępu kontrolujące członkostwo w grupie za pośrednictwem procesów automatycznego zatwierdzania i regularne przeglądy dostępu dla uprzywilejowanych członków grupy.

  • Użyj wbudowanych ról firmy Microsoft Entra, aby zarządzać następującymi ustawieniami tożsamości na poziomie dzierżawy:

    Rola opis Uwaga
    Globalny administrator usługi Zarządza wszystkimi aspektami identyfikatora Entra firmy Microsoft i usługi firmy Microsoft korzystającymi z tożsamości firmy Microsoft Entra. Do tej roli nie należy przypisywać więcej niż pięciu osób.
    Administrator tożsamości hybrydowej Zarządza aprowizowaniem w chmurze z usługi Active Directory do usługi Microsoft Entra ID, a także zarządza ustawieniami logowania jednokrotnego microsoft Entra Connect, uwierzytelniania przekazywanego firmy Microsoft, synchronizacji skrótów haseł firmy Microsoft Entra, bezproblemowego logowania jednokrotnego (SSO) firmy Microsoft.
    Administrator zabezpieczeń Odczytuje informacje o zabezpieczeniach i raporty oraz zarządza konfiguracjami w usłudze Microsoft Entra ID i Microsoft 365.
    Administrator aplikacji Tworzy i zarządza wszystkimi aspektami rejestracji aplikacji i aplikacji dla przedsiębiorstw. Nie można udzielić zgody administracyjnej dla całej dzierżawy.

  • Nie przypisuj roli uprzywilejowanej do zadania, które może wykonać rola o niższych uprawnieniach. Na przykład przypisz rolę Administrator użytkowników, aby zarządzać użytkownikami, a nie z rolą administratora globalnego. Aby uzyskać więcej informacji, zobacz Microsoft Entra wbudowane uprawnienia ról.

  • Użyj jednostek administracyjnych, aby ograniczyć zestaw administratorów, aby mogli zarządzać tylko określonymi obiektami w dzierżawie. Jednostki administracyjne umożliwiają delegowanie administracji podzestawu katalogu. Na przykład możesz delegować administrację działu obsługi do jednej jednostki biznesowej w ramach szerszej organizacji.

    Jednostki administracyjne mogą również pomóc wyeliminować potrzebę oddzielnych dzierżaw identyfikatorów Entra firmy Microsoft jako granicy zabezpieczeń, gdzie oddzielne zespoły zarządzają platformą Microsoft 365 i platformą Azure w tej samej organizacji. Na przykład można użyć jednostek administracyjnych, aby delegować zarządzanie podmiotami zabezpieczeń aplikacji platformy Azure do zespołu aplikacji bez udzielania uprawnień w całej dzierżawie microsoft Entra ID.

  • Aby zapewnić dalszą ochronę, użyj ograniczonych jednostek administracyjnych zarządzania. Uniemożliwiaj wszystkim innym niż określony zestaw administratorów wyznaczonych do modyfikowania określonych obiektów. Na przykład rozdzielenie zasad obowiązków może wymagać użycia tej funkcji, aby uniemożliwić każdemu użytkownikowi modyfikowanie określonego konta użytkownika, nawet użytkowników z rolą Administrator użytkowników. To ograniczenie jest przydatne w przypadku kont usług używanych przez aplikacje, a nawet administratorów nie powinien modyfikować. Można również zapobiec eskalacji uprawnień, na przykład jeśli ktoś modyfikuje konto użytkownika lub grupę z uprawnieniami administracyjnymi platformy lub strefy docelowej.

Zalecenia dotyczące kontroli dostępu opartej na rolach platformy Azure

  • Aby uprościć administrację i zmniejszyć ryzyko błędnej konfiguracji, standaryzacja ról i przypisań ról we wszystkich strefach docelowych aplikacji. Jeśli na przykład masz rolę, która deleguje użytkowników do zarządzania maszynami wirtualnymi, użyj tej samej roli we wszystkich strefach docelowych aplikacji. Takie podejście upraszcza również proces przenoszenia zasobów między strefami docelowymi.

  • Użyj kontroli dostępu opartej na rolach platformy Azure, aby zarządzać dostępem płaszczyzny danych do zasobów, jeśli to możliwe. Przykładami punktów końcowych płaszczyzny danych są usługa Azure Key Vault, konto magazynu lub baza danych SQL.

  • Upewnij się, że obszary robocze dzienników usługi Azure Monitor są skonfigurowane z odpowiednim modelem uprawnień. W przypadku korzystania ze scentralizowanego obszaru roboczego dzienników usługi Azure Monitor użyj uprawnień do zasobów, aby upewnić się, że zespoły aplikacji mają dostęp do własnych dzienników, ale nie do dzienników z innych zespołów.

Wbudowane role

  • Zastanów się, czy wbudowane role są odpowiednie dla Twoich wymagań. W wielu przypadkach można przypisać wiele wbudowanych ról do grupy zabezpieczeń w celu zapewnienia odpowiedniego dostępu dla użytkownika. Czasami jednak nie można używać wbudowanych ról, a także zapewnić zgodność z dostępem z najmniejszymi uprawnieniami, ponieważ role mogą zawierać uprawnienia przekraczające wymagane przez użytkowników. Aby uzyskać bardziej szczegółową kontrolę, rozważ utworzenie roli niestandardowej, która odzwierciedla określone uprawnienia wymagane do wykonania funkcji zadania. Aby uzyskać więcej informacji, zobacz Zapewnianie autoryzacji opartej na rolach.

  • Wiele wbudowanych ról platformy Azure zapewnia wstępnie zdefiniowane przypisania ról na poziomie platformy i zasobu. Podczas łączenia kilku przypisań ról należy wziąć pod uwagę ogólne efekty.

  • Akcelerator strefy docelowej platformy Azure zawiera kilka ról niestandardowych dla typowych funkcji administracyjnych. Te role można używać razem z rolami wbudowanymi platformy Azure. W poniższej tabeli opisano niestandardowe role administracyjne lub obszary akceleratora strefy docelowej platformy Azure:

    Rola lub obszar administracyjny opis Akcje NotActions
    Właściciel platformy Azure (na przykład wbudowana rola właściciela) Zarządza grupami zarządzania i cyklami życia subskrypcji *
    Właściciel subskrypcji Rola delegowana dla właściciela subskrypcji * Microsoft.Authorization/*/write, , Microsoft.Network/vpnGateways/*
    Microsoft.Network/expressRouteCircuits/*,
    Microsoft.Network/routeTables/write,
    Microsoft.Network/vpnSites/*
    Właściciel aplikacji (DevOps, operacje aplikacji) Rola współautora dla zespołu ds. aplikacji lub operacji w zakresie subskrypcji * Microsoft.Authorization/*/write, , Microsoft.Network/publicIPAddresses/write
    Microsoft.Network/virtualNetworks/write,
    Microsoft.KeyVault/locations/deletedVaults/purge/action
    Zarządzanie siecią (NetOps) Zarządza globalną łącznością obejmującą całą platformę, taką jak sieci wirtualne, trasy zdefiniowane przez użytkownika, sieciowe grupy zabezpieczeń, urządzenia WUS, sieci VPN, usługa Azure ExpressRoute i inne */read,
    Microsoft.Network/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Support/*
    Operacje zabezpieczeń (SecOps) Rola administratorów zabezpieczeń z widokiem poziomym w całej infrastrukturze platformy Azure i zasad przeczyszczania usługi Key Vault */read,
    */register/action,
    Microsoft.KeyVault/locations/deletedVaults/purge/action,
    Microsoft.PolicyInsights/*,
    Microsoft.Authorization/policyAssignments/*,
    Microsoft.Authorization/policyDefinitions/*,
    Microsoft.Authorization/policyExemptions/*,
    Microsoft.Authorization/policySetDefinitions/*,
    Microsoft.Insights/alertRules/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Security/*,
    Microsoft.Support/*

    Te role mogą potrzebować dodatkowych praw w zależności od modelu odpowiedzialności. Na przykład w niektórych organizacjach rola NetOps może wymagać tylko zarządzania i konfigurowania łączności globalnej. W organizacjach wymagających bardziej scentralizowanego podejścia można wzbogacić rolę NetOps o bardziej dozwolone akcje, takie jak tworzenie komunikacji równorzędnej między piastami i szprychami.

Przypisania ról i grupy

  • Gdy zespół platformy aprowizuje strefę docelową aplikacji, powinien upewnić się, że są tworzone wszystkie wymagane obiekty zarządzania tożsamościami i dostępem, takie jak grupy zabezpieczeń, standardowe przypisania ról i tożsamości zarządzane przypisane przez użytkownika.

  • Utwórz przypisania ról strefy docelowej w zakresie subskrypcji lub grupy zasobów. Przypisania usługi Azure Policy są wykonywane w zakresie grupy zarządzania, dlatego należy aprowizować przypisania ról strefy docelowej w niższym zakresie. Użyj tego podejścia, aby upewnić się, że administratorzy strefy docelowej mają pełną autonomię nad swoimi zasobami, ale nie mogą modyfikować przypisań usługi Azure Policy, które zarządzają ich strefą docelową.

  • Każda strefa docelowa aplikacji powinna mieć własne grupy i przypisania ról. Nie twórz grup ogólnych i przypisz je do wielu stref docelowych. Takie podejście może prowadzić do błędnej konfiguracji i naruszeń zabezpieczeń i trudno jest zarządzać na dużą skalę. Jeśli jeden użytkownik wymaga dostępu do wielu stref docelowych, przypisz je do odpowiednich grup w każdej strefie docelowej. Zarządzanie członkostwem w grupach za pomocą ładu identyfikatora.

  • Przypisz role do grup, a nie do użytkowników. Takie podejście pomaga zagwarantować, że użytkownicy mają odpowiednie uprawnienia podczas dołączania lub opuszczania organizacji. Pomaga to również zapewnić, że użytkownicy mają odpowiednie uprawnienia podczas przechodzenia między zespołami. Jeśli na przykład użytkownik przenosi się z zespołu sieciowego do zespołu ds. zabezpieczeń, należy je usunąć z grupy sieciowej i dodać je do grupy zabezpieczeń. Jeśli przypiszesz rolę bezpośrednio do użytkownika, zachowają rolę po przejściu do innego zespołu. Użyj ładu identyfikatora, aby zarządzać członkostwem w grupie, a nie ręcznie dodawać i usuwać członków grupy.

  • Zachowaj oddzielne konfiguracje zabezpieczeń dla różnych środowisk tej samej aplikacji, takich jak tworzenie i testowanie i produkcja. Utwórz oddzielne grupy i przypisania ról dla każdego środowiska. Nie udostępniaj tożsamości zarządzanych ani jednostek usługi w różnych środowiskach. Traktuj każde środowisko jako oddzielną strefę docelową. Takie podejście pomaga zapewnić izolację między tworzeniem i testowaniem i produkcją oraz standaryzacją procesu przenoszenia wdrożeń aplikacji między środowiskami. Jeśli ta sama osoba wymaga dostępu do kilku stref docelowych, należy przypisać je do odpowiednich grup w każdej strefie docelowej.

  • Zastanów się, czy administratorzy platformy wymagają uprawnień do stref docelowych aplikacji. Jeśli tak, użyj usługi Microsoft Entra PIM, aby kontrolować dostęp do tych zasobów i przypisywać wymagane uprawnienia o najniższych uprawnieniach. Na przykład administrator platformy może wymagać dostępu do określonej strefy docelowej aplikacji w celu rozwiązania problemu, ale nie powinien mieć rutynowego dostępu do danych lub kodu aplikacji. W takim przypadku administrator platformy może zażądać dostępu do aplikacji. Administrator ról uprzywilejowanych zatwierdza żądanie, a administrator platformy otrzymuje wymagane uprawnienia dla określonego okresu. Takie podejście pomaga wymusić rozdzielenie obowiązków i chroni strefy docelowe aplikacji przed przypadkową lub złośliwą błędną konfiguracją.

  • W przypadku delegowania odpowiedzialności administracyjnej do innych osób, takich jak zespoły aplikacji, należy rozważyć, czy wymagają pełnego zestawu uprawnień, czy tylko podzestawu. Przestrzegaj zasady najniższych uprawnień (PoLP). Możesz na przykład przypisać rolę administratora dostępu użytkowników lub rolę administratora RBAC do użytkownika, który musi zarządzać dostępem do zasobów platformy Azure, ale nie musi zarządzać zasobami samodzielnie. Aby ograniczyć tożsamości, typy tożsamości i role, do których użytkownicy mogą delegować i przypisywać przypisania RBAC platformy Azure, użyj delegowanych przypisań ról z warunkami. Zespoły aplikacji mogą używać warunków do zarządzania własnymi jednostkami zabezpieczeń w ramach ograniczeń określonych przez zespół ds. platformy. Bardziej uprzywilejowane przypisania ról wymagają eskalacji do zespołu platformy. Podczas delegowania ról RBAC należy wziąć pod uwagę następujące czynniki:

    • Przejrzyj bieżące przypisania ról dla wbudowanych i niestandardowych ról uprzywilejowanych i oceń, czy należy dodać odpowiednie warunki do tych istniejących przypisań. Można na przykład dodać warunki do ról niestandardowych Właściciel subskrypcji i Właściciel aplikacji, które zapewnia akcelerator strefy docelowej platformy Azure. Te warunki mogą ograniczać typy podmiotów zabezpieczeń, które mogą przypisywać role lub ograniczać określone role, które mogą przypisywać.

    • Postępuj zgodnie z zasadami poLP podczas dodawania warunków do przypisań ról. Na przykład ogranicz delegatów, aby przypisywać role tylko do grup lub umożliwiać delegatom przypisywanie wszystkich ról z wyjątkiem ról uprzywilejowanych administratorów, takich jak Właściciel, Administrator dostępu użytkowników i Administrator RBAC.

    • Utwórz własne warunki, jeśli dostępne szablony warunków nie spełniają Twoich wymagań ani zasad.

      Zrzut ekranu przedstawiający szablony warunków dla ograniczonego delegowania kontroli dostępu opartej na rolach.

    • Zapoznaj się ze znanymi ograniczeniami delegowania zarządzania dostępem platformy Azure do innych osób.

  • W poniższej tabeli przedstawiono przykładową strukturę przypisania roli dla środowiska strefy docelowej platformy Azure. Zapewnia równowagę między zabezpieczeniami a łatwością administracji. Możesz dostosować strukturę do wymagań organizacji. Tę samą osobę można przypisać do wielu grup w zależności od ich roli w organizacji. Należy jednak zastosować przypisania RBAC do określonej grupy w określonej strefie docelowej.

    Zasób User Przypisanie roli Cel przypisania Zakres przypisania
    Strefa docelowa Application X Właściciele aplikacji X Właściciel aplikacji (niestandardowy, uwzględniony w akceleratorze strefy docelowej platformy Azure) Application X Admins grupa zabezpieczeń Subskrypcje produkcyjne i deweloperskie/testowe aplikacji X
    Strefa docelowa Application X Właściciele aplikacji X Administrator dostępu do aplikacji (niestandardowy z warunkami przypisywania ról w celu zarządzania dostępem do własnej aplikacji) Application X Admins grupa zabezpieczeń Subskrypcje produkcyjne i deweloperskie/testowe aplikacji X
    Strefa docelowa Application X Administrator danych aplikacji X Administrator danych (niestandardowy z uprawnieniami do wymaganych zasobów danych) Application X Data Team grupa zabezpieczeń Subskrypcje produkcyjne i deweloperskie/testowe aplikacji X
    Strefa docelowa aplikacji Y Właściciele aplikacji Y Właściciel aplikacji (niestandardowy, uwzględniony w akceleratorze strefy docelowej platformy Azure) Application Y Admins grupa zabezpieczeń Subskrypcje produkcyjne i subskrypcje tworzenia i testowania aplikacji Y
    Strefa docelowa aplikacji Y Zespół testowania aplikacji Y Współautor testów (niestandardowy z uprawnieniami wymaganymi do testowania aplikacji) Application Y Test Team grupa zabezpieczeń Subskrypcja tworzenia i testowania aplikacji Y
    Piaskownica Zespół deweloperów aplikacji Z Właściciel (wbudowany) Application Z developers grupa zabezpieczeń Grupy zasobów aplikacji Z w subskrypcji piaskownicy
    Zasoby platformy Zespół zarządzający platformą Współautor (wbudowany) Platform Admins Grupa PIM Platform grupa zarządzania
    Strefy docelowe platformy Zespół zarządzający platformą Czytelnik (wbudowany) Platform Team grupa zabezpieczeń Organizacyjna grupa zarządzania najwyższego poziomu
    Dla całej dzierżawy Zespół ds. zabezpieczeń Operacje zabezpieczeń (niestandardowe, uwzględnione w akceleratorze strefy docelowej platformy Azure) Security Ops grupa zabezpieczeń Organizacyjna grupa zarządzania najwyższego poziomu
    Dla całej dzierżawy Zespół ds. zabezpieczeń Administrator dostępu warunkowego (wbudowany z włączonymi akcjami chronionymi) Security administrators grupa zabezpieczeń Dzierżawa identyfikatora entra firmy Microsoft
    Dla całej dzierżawy Zespół ds. sieci Operacje sieciowe (niestandardowe, uwzględnione w akceleratorze strefy docelowej platformy Azure) Network Ops grupa zabezpieczeń Wszystkie subskrypcje
    Dla całej dzierżawy Zespół FinOps Czytelnik rozliczeń (wbudowany) FinOps Team grupa zabezpieczeń Organizacyjna grupa zarządzania najwyższego poziomu

  • Przypisania usługi Azure Policy, które mają DeployIfNotExists wpływ, wymagają tożsamości zarządzanej w celu skorygowania niezgodnych zasobów. Jeśli używasz tożsamości zarządzanej przypisanej przez system w ramach procesu przypisywania usługi Azure Policy, platforma Azure automatycznie udziela wymaganych uprawnień. Jeśli używasz tożsamości zarządzanej przypisanej przez użytkownika, uprawnienia muszą zostać przyznane ręcznie. Przypisania ról tożsamości zarządzanej muszą być zgodne z zasadami PoLP i włączyć tylko wymagane uprawnienia do przeprowadzenia korygowania zasad w zakresie docelowym. Tożsamości zarządzane korygowania zasad nie obsługują niestandardowych definicji ról. Stosowanie przypisań ról bezpośrednio do tożsamości zarządzanych, a nie do grup.

Zalecenia dotyczące usługi Microsoft Entra PIM

  • Użyj usługi Microsoft Entra PIM , aby zachować zgodność z modelem Zero Trust i dostępem z najmniejszymi uprawnieniami. Skoreluj role organizacji z minimalnymi wymaganymi poziomami dostępu. W usłudze Microsoft Entra PIM można używać narzędzi natywnych dla platformy Azure, rozszerzać istniejące narzędzia i procesy lub używać istniejących i natywnych narzędzi zgodnie z potrzebami.

  • Użyj przeglądów dostępu usługi Microsoft Entra PIM, aby regularnie weryfikować uprawnienia do zasobów. Przeglądy dostępu są częścią wielu struktur zgodności, dlatego wiele organizacji ma już proces przeglądu dostępu.

  • Użyj tożsamości uprzywilejowanych dla elementów Runbook automatyzacji, które wymagają podwyższonych uprawnień dostępu lub dla uprzywilejowanych potoków wdrażania. Za pomocą tych samych narzędzi i zasad można zarządzać zautomatyzowanymi przepływami pracy, które uzyskują dostęp do krytycznych granic zabezpieczeń używanych do zarządzania użytkownikami równoważnymi uprawnieniami. Potoki automatyzacji i wdrażania dla zespołów aplikacji powinny mieć przypisania ról, które uniemożliwiają właścicielowi aplikacji eskalację własnych uprawnień.

  • Kontrolowanie ról RBAC platformy Azure z wysokimi uprawnieniami, takich jak właściciele lub administratorzy dostępu użytkowników przypisani do członków zespołu strefy docelowej platformy lub aplikacji w ramach subskrypcji lub grupy zarządzania. Użyj usługi Microsoft Entra PIM dla grup , aby skonfigurować role RBAC platformy Azure, aby wymagać tego samego procesu podniesienia uprawnień co role identyfikatora entra firmy Microsoft.

    Na przykład użytkownik może rutynowo wymagać ograniczonego dostępu administracyjnego do zasobów w strefie docelowej aplikacji. Czasami mogą wymagać roli Właściciel. Można utworzyć dwie grupy zabezpieczeń: Administratorzy aplikacji i Właściciele aplikacji. Przypisz role z najmniejszymi uprawnieniami do grupy Administratorzy aplikacji i przypisz rolę właściciela do roli Właściciele aplikacji. Użyj grup PIM, aby użytkownik mógł zażądać roli Właściciel, jeśli jest to wymagane. Przez cały czas użytkownik ma tylko uprawnienia wymagane do wykonywania typowych działań.

  • Użyj akcji chronionych w usłudze Microsoft Entra PIM, aby dodać dodatkowe warstwy ochrony. W usłudze Microsoft Entra ID chronione akcje to uprawnienia przypisane do zasad dostępu warunkowego. Gdy użytkownik próbuje wykonać akcję chronioną, musi najpierw spełnić zasady dostępu warunkowego przypisane do wymaganych uprawnień. Aby na przykład umożliwić administratorom aktualizowanie ustawień dostępu między dzierżawami, można wymagać, aby najpierw spełnili zasady uwierzytelniania wieloskładnikowego odpornego na wyłudzanie informacji.

Zarządzanie tożsamościami i dostępem w akceleratorze strefy docelowej platformy Azure

Zarządzanie tożsamościami i dostępem to podstawowe funkcje implementacji akceleratora strefy docelowej platformy Azure. Wdrożenie obejmuje subskrypcję dedykowaną dla tożsamości, w której organizacje mogą wdrażać kontrolery domeny usług AD DS lub inne usługi tożsamości, takie jak serwery Microsoft Entra Connect, które są wymagane dla ich środowiska. Nie wszystkie organizacje wymagają usług w ramach subskrypcji. Na przykład niektóre organizacje mogą mieć aplikacje, które są już w pełni zintegrowane z identyfikatorem Entra firmy Microsoft.

Subskrypcja tożsamości ma sieć wirtualną równorzędną z siecią wirtualną koncentratora w subskrypcji platformy. Dzięki tej konfiguracji zespół platformy może zarządzać subskrypcją tożsamości, a właściciele aplikacji mają dostęp do usług tożsamości zgodnie z potrzebami. Należy zabezpieczyć subskrypcję tożsamości i sieć wirtualną, aby chronić usługi tożsamości przed nieautoryzowanym dostępem.

Implementacja akceleratora strefy docelowej platformy Azure obejmuje również następujące opcje:

  • Przypisz zalecane zasady, aby zarządzać tożsamościami i kontrolerami domeny.
  • Utwórz sieć wirtualną i połącz się z koncentratorem za pośrednictwem komunikacji równorzędnej sieci wirtualnych.

Następne kroki

Zarządzanie tożsamościami aplikacji i dostępem