Zalecenia dotyczące zarządzania tożsamościami i dostępem

  • Artykuł

Dotyczy tego zalecenia listy kontrolnej zabezpieczeń usługi Azure Well-Architected Framework:

SE:05 Zaimplementuj ścisłe, warunkowe i podlegające inspekcji zarządzanie tożsamościami i dostępem (IAM) dla wszystkich użytkowników obciążeń, członków zespołu i składników systemu. Ogranicz dostęp wyłącznie do zgodnie z potrzebami. Używaj nowoczesnych standardów branżowych dla wszystkich implementacji uwierzytelniania i autoryzacji. Ogranicz i rygorystycznie przeprowadź inspekcję dostępu, który nie jest oparty na tożsamości.

W tym przewodniku opisano zalecenia dotyczące uwierzytelniania i autoryzowania tożsamości, które próbują uzyskać dostęp do zasobów obciążenia.

Z perspektywy kontroli technicznej tożsamość jest zawsze podstawowym obwodem. Ten zakres nie obejmuje tylko krawędzi obciążenia. Obejmuje również poszczególne składniki, które znajdują się wewnątrz obciążenia. Typowe tożsamości obejmują:

  • Ludzie. Użytkownicy aplikacji, administratorzy, operatorzy, audytorzy i zły aktorzy.

  • Systemy. Tożsamości obciążeń, tożsamości zarządzane, klucze interfejsu API, jednostki usługi i zasoby platformy Azure.

  • Anonimowe. Jednostki, które nie dostarczyły żadnych dowodów na to, kim są.

Definicje 

Terminologia Definicja
Uwierzytelnianie (AuthN) Proces weryfikujący, czy tożsamość jest tym, kto lub co mówi.
Autoryzacja (AuthZ) Proces weryfikujący, czy tożsamość ma uprawnienia do wykonania żądanej akcji.
Dostęp warunkowy Zestaw reguł, który zezwala na akcje na podstawie określonych kryteriów.
Dostawca tożsamości Dostawca tożsamości, taki jak identyfikator Microsoft Entra.
Persona Funkcja zadania lub tytuł, który ma zestaw obowiązków i akcji.
Klucze wstępnego udostępniania Typ wpisu tajnego współużytkowanego przez dostawcę i konsumenta oraz używany za pośrednictwem bezpiecznego i uzgodnionego mechanizmu.
Tożsamość zasobu Tożsamość zdefiniowana dla zasobów w chmurze zarządzanych przez platformę.
Rola Zestaw uprawnień definiujących, co może zrobić użytkownik lub grupa.
Zakres Różne poziomy hierarchii organizacyjnej, na których rola może działać. Ponadto grupa funkcji w systemie.
Podmiot zabezpieczeń Tożsamość, która zapewnia uprawnienia. Może to być użytkownik, grupa lub jednostka usługi. Każdy członek grupy uzyskuje ten sam poziom dostępu.
Tożsamość użytkownika Tożsamość osoby, takiej jak pracownik lub użytkownik zewnętrzny.
Tożsamość obciążenia Tożsamość systemu dla aplikacji, usługi, skryptu, kontenera lub innego składnika obciążenia używanego do uwierzytelniania się w innych usługach i zasobach.

Uwaga

Tożsamość można grupować z innymi, podobnymi tożsamościami w ramach elementu nadrzędnego o nazwie podmiotu zabezpieczeń. Grupa zabezpieczeń jest przykładem podmiotu zabezpieczeń. Ta relacja hierarchiczna upraszcza konserwację i poprawia spójność. Ponieważ atrybuty tożsamości nie są obsługiwane na poziomie indywidualnym, prawdopodobieństwo wystąpienia błędów również jest mniejsze. W tym artykule termin tożsamość obejmuje podmioty zabezpieczeń.

Rola dostawcy tożsamości

Dostawca tożsamości to usługa hostowana w chmurze, która przechowuje użytkowników i zarządza nimi jako tożsamości cyfrowe.

Korzystaj z możliwości zapewnianych przez zaufanego dostawcę tożsamości na potrzeby zarządzania tożsamościami i dostępem. Nie implementuj niestandardowych systemów w celu zastąpienia dostawcy tożsamości. Systemy dostawcy tożsamości są często ulepszane w oparciu o najnowsze wektory ataków, przechwytując miliardy sygnałów w wielu dzierżawach każdego dnia. Microsoft Entra id to dostawca tożsamości dla platformy w chmurze platformy Azure.

Authentication

Uwierzytelnianie to proces, który weryfikuje tożsamości. Żądanie tożsamości jest wymagane, aby zapewnić jakąś formę weryfikowalnej identyfikacji. Na przykład:

  • Nazwa użytkownika i hasło.

  • Wpis tajny wstępnego, taki jak klucz interfejsu API, który udziela dostępu.

  • Token sygnatury dostępu współdzielonego (SAS).

  • Certyfikat używany w wzajemnym uwierzytelnianiu TLS.

Jak najwięcej, proces weryfikacji powinien być obsługiwany przez dostawcę tożsamości.

Autoryzacja

Autoryzacja to proces, który umożliwia lub odrzuca akcje żądane przez zweryfikowaną tożsamość. Akcja może być operacyjna lub związana z zarządzaniem zasobami.

Autoryzacja wymaga przypisania uprawnień do tożsamości, które należy wykonać przy użyciu funkcji zapewnianych przez dostawcę tożsamości.

Kluczowe strategie projektowania

Aby uzyskać całościowy widok potrzeb związanych z tożsamością dla obciążenia, musisz katalogować przepływy, zasoby obciążenia i osoby, a także akcje, które będą wykonywane przez zasoby i osoby. Strategia musi obejmować wszystkie przypadki użycia, które obsługują przepływy, które docierają do obciążenia lub jego składników (dostęp poza dostępem) oraz przepływy wychodzące z obciążenia do innych źródeł (dostęp wewnętrzny).

Każdy przypadek użycia prawdopodobnie będzie miał własny zestaw mechanizmów kontroli, które należy zaprojektować z myślą o założeniu naruszenia zabezpieczeń. Na podstawie wymagań dotyczących tożsamości przypadku użycia lub osoby zidentyfikuj opcje warunkowe. Unikaj używania jednego rozwiązania dla wszystkich przypadków użycia. Z drugiej strony kontrolki nie powinny być tak szczegółowe, że wprowadzasz niepotrzebne obciążenie związane z zarządzaniem.

Musisz zarejestrować dziennik dostępu do tożsamości. Dzięki temu można zweryfikować kontrolki i użyć dzienników do inspekcji zgodności.

Określanie wszystkich tożsamości na potrzeby uwierzytelniania

  • Dostęp poza dostępem. Projekt tożsamości musi uwierzytelniać wszystkich użytkowników, którzy uzyskują dostęp do obciążenia w różnych celach. Na przykład użytkownik końcowy, który uzyskuje dostęp do aplikacji, wywołując interfejsy API.

    Na szczegółowym poziomie składniki obciążenia mogą również potrzebować dostępu spoza firmy. Na przykład operator, który potrzebuje dostępu za pośrednictwem portalu lub dostępu do obliczeń w celu uruchamiania poleceń.

    Oba są przykładami tożsamości użytkowników , które mają różne osoby.

  • Dostęp wewnętrzny. Aplikacja będzie musiała uzyskiwać dostęp do innych zasobów. Na przykład odczytywanie z platformy danych lub zapisywanie ich na platformie danych, pobieranie wpisów tajnych z magazynu wpisów tajnych i rejestrowanie danych telemetrycznych w usługach monitorowania. Może być nawet konieczne uzyskanie dostępu do usług innych firm. Te wymagania dotyczące dostępu wymagają tożsamości obciążenia, co umożliwia aplikacji uwierzytelnianie się w innych zasobach.

    Koncepcja ma zastosowanie na poziomie składnika. W poniższym przykładzie kontener może potrzebować dostępu do potoków wdrażania, aby uzyskać jego konfigurację. Te wymagania dotyczące dostępu wymagają tożsamości zasobu.

Wszystkie te tożsamości powinny być uwierzytelniane przez dostawcę tożsamości.

Oto przykład sposobu implementacji tożsamości w architekturze:

Diagram przedstawiający sposób implementacji tożsamości w architekturze.

Określanie akcji autoryzacji

Następnie musisz wiedzieć, co każda uwierzytelniona tożsamość próbuje wykonać, aby te akcje mogły być autoryzowane. Akcje można podzielić według typu dostępu, którego wymagają:

  • Dostęp do płaszczyzny danych. Akcje, które mają miejsce na płaszczyźnie danych, powodują transfer danych do wewnątrz lub poza dostępem. Na przykład aplikacja odczytuje dane z bazy danych i zapisuje dane w bazie danych, pobiera wpisy tajne lub zapisuje dzienniki w ujściu monitorowania. Na poziomie składnika obliczenia, które ściągają lub wypychają obrazy do lub z rejestru, są traktowane jako operacje płaszczyzny danych.

  • Dostęp do płaszczyzny sterowania. Akcje wykonywane na płaszczyźnie sterowania powodują utworzenie, zmodyfikowanie lub usunięcie zasobu platformy Azure. Na przykład zmiany właściwości zasobu.

Aplikacje zazwyczaj docelowe operacje płaszczyzny danych, a operacje często uzyskują dostęp do płaszczyzny kontroli i danych. Aby zidentyfikować potrzeby autoryzacji, zanotuj akcje operacyjne, które można wykonać w zasobie. Aby uzyskać informacje o dozwolonych akcjach dla każdego zasobu, zobacz Operacje dostawcy zasobów platformy Azure.

Zapewnianie autoryzacji opartej na rolach

Na podstawie odpowiedzialności za każdą tożsamość należy autoryzować akcje, które powinny być dozwolone. Tożsamość nie może robić więcej niż musi. Przed ustawieniem reguł autoryzacji musisz mieć jasne zrozumienie, kto lub co wysyła żądania, co może zrobić ta rola i w jakim zakresie może to zrobić. Te czynniki prowadzą do wyborów łączących tożsamość, rolę i zakres.

Rozważmy tożsamość obciążenia jako przykład. Aplikacja musi mieć dostęp do płaszczyzny danych do bazy danych, więc akcje odczytu i zapisu w zasobie danych muszą być dozwolone. Czy jednak aplikacja potrzebuje dostępu płaszczyzny sterowania do magazynu wpisów tajnych? Jeśli tożsamość obciążenia zostanie naruszona przez złego aktora, jaki będzie wpływ na system, pod względem poufności, integralności i dostępności?

Przypisanie roli

Rola to zestaw uprawnień przypisanych do tożsamości. Przypisz role, które zezwalają tylko tożsamości na ukończenie zadania i nie tylko. Jeśli uprawnienia użytkownika są ograniczone do wymagań dotyczących zadań, łatwiej jest zidentyfikować podejrzane lub nieautoryzowane zachowanie w systemie.

Zadaj pytania, takie jak te:

  • Czy dostęp tylko do odczytu jest wystarczający?
  • Czy tożsamość musi mieć uprawnienia do usuwania zasobów?

Ograniczenie poziomu dostępu, który użytkownicy, aplikacje lub usługi muszą mieć do zasobów platformy Azure, zmniejsza potencjalną powierzchnię ataków. Jeśli przyznasz tylko minimalne uprawnienia wymagane do wykonywania określonych zadań, ryzyko pomyślnego ataku lub nieautoryzowanego dostępu zostanie znacznie zmniejszone. Na przykład zespoły ds. zabezpieczeń potrzebują tylko dostępu tylko do odczytu do atrybutów zabezpieczeń dla wszystkich środowisk technicznych. Ten poziom wystarczy, aby ocenić czynniki ryzyka, zidentyfikować potencjalne środki zaradcze i zgłosić ryzyko.

Istnieją scenariusze, w których użytkownicy potrzebują większego dostępu ze względu na strukturę organizacyjną i organizację zespołu. Może istnieć nakładanie się między różnymi rolami lub pojedynczy użytkownicy mogą wykonywać wiele ról standardowych. W takim przypadku należy użyć wielu przypisań ról opartych na funkcji biznesowej zamiast tworzyć rolę niestandardową dla każdego z tych użytkowników. Dzięki temu role są łatwiejsze do zarządzania.

Unikaj uprawnień, które w szczególności odwołują się do poszczególnych zasobów lub użytkowników. Szczegółowe i niestandardowe uprawnienia tworzą złożoność i zamieszanie, ponieważ nie przekazują zamiaru nowych zasobów, które są podobne. Może to spowodować utworzenie złożonej starszej konfiguracji, która jest trudna do utrzymania i negatywnie wpływa zarówno na bezpieczeństwo, jak i niezawodność.

Kompromis: Szczegółowe podejście kontroli dostępu umożliwia lepszą inspekcję i monitorowanie działań użytkowników.

Rola ma również skojarzony zakres. Rola może działać w dozwolonej grupie zarządzania, subskrypcji, grupie zasobów lub zakresie zasobów lub w innym zakresie niestandardowym. Nawet jeśli tożsamość ma ograniczony zestaw uprawnień, rozszerzenie zakresu w celu uwzględnienia zasobów spoza funkcji zadania tożsamości jest ryzykowne. Na przykład dostęp do odczytu do całego kodu źródłowego i danych może być niebezpieczny i musi być kontrolowany.

Role są przypisywane do tożsamości przy użyciu kontroli dostępu opartej na rolach (RBAC). Zawsze używaj kontroli dostępu opartej na rolach dostawcy tożsamości , aby korzystać z funkcji, które umożliwiają spójne stosowanie kontroli dostępu i odwoływanie jej rygorystycznie.

Użyj ról wbudowanych. Zostały one zaprojektowane tak, aby obejmowały większość przypadków użycia. Role niestandardowe są zaawansowane i czasami przydatne, ale należy je zarezerwować w scenariuszach, w których wbudowane role nie będą działać. Dostosowanie prowadzi do złożoności, która zwiększa zamieszanie i sprawia, że automatyzacja jest bardziej złożona, trudna i krucha. Wszystkie te czynniki negatywnie wpływają na bezpieczeństwo.

Udziel ról, które zaczynają się od najmniejszych uprawnień i dodaj więcej na podstawie potrzeb operacyjnych lub dostępu do danych. Zespoły techniczne muszą mieć jasne wskazówki dotyczące implementowania uprawnień.

Jeśli chcesz precyzyjnie kontrolować kontrolę na podstawie ról, dodaj warunki przypisania roli na podstawie kontekstu, takie jak akcje i atrybuty.

Wybór dostępu warunkowego

Nie udostępniaj wszystkim tożsamościom tego samego poziomu dostępu. Opierać się na decyzjach dotyczących dwóch głównych czynników:

  • Czas. Jak długo tożsamość może uzyskiwać dostęp do środowiska.

  • Uprawnienia. Poziom uprawnień.

Czynniki te nie wykluczają się wzajemnie. Naruszona tożsamość, która ma więcej uprawnień i nieograniczony czas trwania dostępu, może uzyskać większą kontrolę nad systemem i danymi lub użyć tego dostępu, aby nadal zmieniać środowisko. Ogranicz te czynniki dostępu zarówno jako środek zapobiegawczy, jak i do kontrolowania promienia wybuchu.

  • Podejścia just in Time (JIT) zapewniają wymagane uprawnienia tylko wtedy, gdy są potrzebne.

  • Just Enough Access (JEA) zapewnia tylko wymagane uprawnienia.

Chociaż czas i uprawnienia są podstawowymi czynnikami, istnieją inne warunki, które mają zastosowanie. Można na przykład użyć urządzenia, sieci i lokalizacji, z której dostęp pochodzi, aby ustawić zasady.

Używaj silnych kontrolek, które filtrować, wykrywać i blokować nieautoryzowany dostęp, w tym parametry, takie jak tożsamość użytkownika i lokalizacja, kondycja urządzenia, kontekst obciążenia, klasyfikacja danych i anomalie.

Na przykład obciążenie może wymagać dostępu do tożsamości innych firm, takich jak dostawcy, partnerzy i klienci. Potrzebują one odpowiedniego poziomu dostępu, a nie domyślnych uprawnień udzielanych pracownikom pełnoetatowym. Jasne rozróżnienie kont zewnętrznych ułatwia zapobieganie atakom pochodzącym z tych wektorów i wykrywanie ich.

Wybór dostawcy tożsamości musi być w stanie zapewnić takie różnice, zapewnić wbudowane funkcje, które udzielają uprawnień na podstawie najniższych uprawnień i zapewniają wbudowaną analizę zagrożeń. Obejmuje to monitorowanie żądań dostępu i logowania. Dostawca tożsamości platformy Azure ma identyfikator Microsoft Entra. Aby uzyskać więcej informacji, zobacz sekcję ułatwienia platformy Azure w tym artykule.

Konta wpływu krytycznego

Tożsamości administracyjne wprowadzają niektóre z najwyższych zagrożeń bezpieczeństwa, ponieważ zadania, które wykonują, wymagają uprzywilejowanego dostępu do szerokiego zestawu tych systemów i aplikacji. Naruszenie lub niewłaściwe użycie może mieć szkodliwy wpływ na firmę i jej systemy informacyjne. Bezpieczeństwo administracji jest jednym z najbardziej krytycznych obszarów zabezpieczeń.

Ochrona uprzywilejowanego dostępu przed określonymi przeciwnikami wymaga pełnego i przemyślanego podejścia w celu odizolowania tych systemów od ryzyka. Oto kilka strategii:

  • Zminimalizuj liczbę kont o krytycznym wpływie.

  • Używaj oddzielnych ról zamiast podnosić uprawnienia dla istniejących tożsamości.

  • Unikaj stałego lub stałego dostępu przy użyciu funkcji JIT dostawcy tożsamości. W przypadku sytuacji ze szkła awaryjnego postępuj zgodnie z procesem dostępu awaryjnego.

  • Używaj nowoczesnych protokołów dostępu, takich jak uwierzytelnianie bez hasła lub uwierzytelnianie wieloskładnikowe. Zainicjuj te mechanizmy dostawcy tożsamości.

  • Wymuszaj atrybuty zabezpieczeń kluczy przy użyciu zasad dostępu warunkowego.

  • Likwiduj konta administracyjne , które nie są używane.

Użyj jednej tożsamości w różnych środowiskach i skojarz pojedynczą tożsamość z użytkownikiem lub podmiotem zabezpieczeń. Spójność tożsamości w środowiskach chmurowych i lokalnych zmniejsza błędy ludzkie i wynikające z tego zagrożenia bezpieczeństwa. Zespoły w obu środowiskach, które zarządzają zasobami, potrzebują spójnego, autorytatywnego źródła w celu spełnienia wymagań dotyczących zabezpieczeń. Skontaktuj się z centralnym zespołem tożsamości, aby upewnić się, że tożsamości w środowiskach hybrydowych są synchronizowane.

Ryzyko: istnieje ryzyko związane z synchronizowaniem tożsamości o wysokim poziomie uprawnień. Osoba atakująca może uzyskać pełną kontrolę nad zasobami lokalnymi i może to prowadzić do pomyślnego naruszenia bezpieczeństwa konta w chmurze. Oceń strategię synchronizacji, odfiltrując konta, które mogą zostać dodane do obszaru ataków.

Ustanawianie procesów zarządzania cyklem życia tożsamości

Dostęp do tożsamości nie może trwać dłużej niż zasoby, do których uzyskują dostęp tożsamości. Upewnij się, że masz proces wyłączania lub usuwania tożsamości w przypadku zmian w strukturze zespołu lub składnikach oprogramowania.

Te wskazówki dotyczą kontroli źródła, danych, płaszczyzn sterowania, użytkowników obciążeń, infrastruktury, narzędzi, monitorowania danych, dzienników, metryk i innych jednostek.

Ustanów proces zapewniania ładu tożsamości w celu zarządzania cyklem życia tożsamości cyfrowych, użytkowników o wysokim poziomie uprawnień, użytkowników zewnętrznych/gości i użytkowników obciążeń. Zaimplementuj przeglądy dostępu, aby upewnić się, że gdy tożsamości opuszczają organizację lub zespół, ich uprawnienia obciążenia zostaną usunięte.

Ochrona wpisów tajnych opartych na niezidentycie

Wpisy tajne aplikacji, takie jak klucze wstępnego udostępniania, powinny być traktowane jako punkty podatne na zagrożenia w systemie. W dwukierunkowej komunikacji, jeśli dostawca lub konsument zostanie naruszony, można wprowadzić znaczące zagrożenia bezpieczeństwa. Te klucze mogą być również uciążliwe, ponieważ wprowadzają procesy operacyjne.

Jeśli to możliwe, unikaj używania wpisów tajnych i rozważ użycie uwierzytelniania opartego na tożsamościach w celu uzyskania dostępu użytkownika do samej aplikacji, a nie tylko do jej zasobów.

Poniższa lista zawiera podsumowanie wskazówek. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące wpisów tajnych aplikacji.

  • Traktuj te wpisy tajne jako jednostki, które mogą być dynamicznie pobierane z magazynu wpisów tajnych. Nie powinny one być zakodowane w kodzie aplikacji, skryptach IaC, potokach wdrażania ani w żadnym innym artefaktie.

  • Upewnij się, że masz możliwość odwołania wpisów tajnych.

  • Stosowanie praktyk operacyjnych obsługujących zadania, takie jak rotacja kluczy i wygaśnięcie.

Aby uzyskać informacje na temat zasad rotacji, zobacz Automatyzowanie rotacji wpisu tajnego dla zasobów, które mają dwa zestawy poświadczeń uwierzytelniania i Samouczek: Aktualizowanie częstotliwości automatycznego obracania certyfikatu w Key Vault.

Bezpieczne środowiska programistyczne

Wszystkie kody i skrypty, narzędzia potoków i systemy kontroli źródła powinny być traktowane jako zasoby obciążeń. Dostęp do zapisów powinien być ogrodzony za pomocą automatyzacji i przeglądu równorzędnego. Dostęp do odczytu do kodu źródłowego powinien być ograniczony do ról w zależności od potrzeb. Repozytoria kodu muszą mieć wersje, a przeglądy kodu zabezpieczeń przez elementów równorzędnych muszą być regularną praktyką zintegrowaną z cyklem życia programowania. Musisz mieć proces, który regularnie skanuje zasoby i identyfikuje najnowsze luki w zabezpieczeniach.

Użyj tożsamości obciążeń, aby udzielić dostępu do zasobów ze środowisk wdrażania, takich jak GitHub.

Utrzymywanie dziennika inspekcji

Jednym z aspektów zarządzania tożsamościami jest zapewnienie, że system można przeprowadzić inspekcję. Sprawdza, czy strategie zakładania naruszenia są skuteczne. Obsługa dziennika inspekcji ułatwia:

  • Sprawdź, czy tożsamość jest uwierzytelniana przy użyciu silnego uwierzytelniania. Wszelkie działania muszą być śledzne , aby zapobiec atakom repudiation.

  • Wykrywanie słabych lub brakujących protokołów uwierzytelniania oraz uzyskiwanie wglądu w logowania użytkowników i aplikacji oraz uzyskiwanie szczegółowych informacji o użytkownikach i aplikacjach.

  • Oceń dostęp z tożsamości do obciążenia na podstawie wymagań dotyczących zabezpieczeń i zgodności oraz rozważ ryzyko związane z kontem użytkownika, stan urządzenia oraz inne ustawione kryteria i zasady.

  • Śledzenie postępu lub odchylenia od wymagań dotyczących zgodności.

Większość zasobów ma dostęp do płaszczyzny danych. Musisz znać tożsamości, które uzyskują dostęp do zasobów i akcji, które wykonują. Te informacje można użyć do diagnostyki zabezpieczeń.

Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące monitorowania zabezpieczeń i analizy zagrożeń.

Ułatwienia platformy Azure

Zalecamy, aby zawsze używać nowoczesnych protokołów uwierzytelniania, które uwzględniają wszystkie dostępne punkty danych i korzystają z dostępu warunkowego. Microsoft Entra ID zapewnia zarządzanie tożsamościami i dostępem na platformie Azure. Obejmuje ona płaszczyznę zarządzania platformy Azure i jest zintegrowana z płaszczyznami danych większości usług platformy Azure. Microsoft Entra identyfikator to dzierżawa skojarzona z subskrypcją obciążenia. Śledzi tożsamości i zarządza nimi oraz ich dozwolonymi uprawnieniami i upraszcza ogólne zarządzanie, aby zminimalizować ryzyko nadzoru lub błędu ludzkiego.

Te możliwości natywnie integrują się z tym samym modelem tożsamości i uprawnień Microsoft Entra dla segmentów użytkowników:

Identyfikator Microsoft Entra można użyć do uwierzytelniania i autoryzacji aplikacji niestandardowych za pośrednictwem biblioteki Microsoft Authentication Library (MSAL) lub funkcji platformy, takich jak uwierzytelnianie dla aplikacji internetowych. Obejmuje ona płaszczyznę zarządzania platformy Azure, płaszczyzny danych większości usług platformy Azure i możliwości integracji dla aplikacji.

Możesz pozostać na bieżąco, odwiedzając stronę Co nowego w identyfikatorze Microsoft Entra.

Kompromis: Microsof Microsoft Entra ID jest pojedynczym punktem awarii, podobnie jak każda inna podstawowa usługa. Nie ma obejścia problemu, dopóki awaria nie zostanie naprawiona przez firmę Microsoft. Jednak bogaty zestaw funkcji Microsoft Entra przewyższa ryzyko użycia niestandardowych rozwiązań.

Platforma Azure obsługuje otwarte protokoły, takie jak OAuth2 i OpenID Connect. Zalecamy używanie tych standardowych mechanizmów uwierzytelniania i autoryzacji zamiast projektowania własnych przepływów.

Kontrola dostępu na podstawie ról platformy Azure

Kontrola dostępu oparta na rolach platformy Azure reprezentuje podmioty zabezpieczeń w identyfikatorze Microsoft Entra. Wszystkie przypisania ról są wykonywane za pośrednictwem kontroli dostępu opartej na rolach platformy Azure. Korzystaj z wbudowanych ról, które zapewniają większość potrzebnych uprawnień. Aby uzyskać więcej informacji, zobacz Microsoft Entra wbudowanych ról.

Oto kilka przypadków użycia:

Aby uzyskać więcej informacji na temat kontroli dostępu opartej na rolach, zobacz Najlepsze rozwiązania dotyczące kontroli dostępu opartej na rolach platformy Azure.

Aby uzyskać informacje na temat kontrolek opartych na atrybutach, zobacz Co to jest usługa Azure ABAC?.

Tożsamość obciążenia

Microsoft Entra identyfikator może obsługiwać tożsamość aplikacji. Jednostka usługi skojarzona z aplikacją może dyktować jej zakres dostępu.

Aby uzyskać więcej informacji, zobacz Co to są tożsamości obciążeń?.

Jednostka usługi jest również abstrakcjonowana podczas korzystania z tożsamości zarządzanej. Zaletą jest to, że platforma Azure zarządza wszystkimi poświadczeniami aplikacji.

Nie wszystkie usługi obsługują tożsamości zarządzane. Jeśli nie możesz używać tożsamości zarządzanych, możesz użyć jednostek usługi. Jednak użycie jednostek usługi zwiększa obciążenie związane z zarządzaniem. Aby uzyskać więcej informacji, zobacz Czym są tożsamości zarządzane dla zasobów platformy Azure?.

Tożsamość zasobu

Pojęcie tożsamości zarządzanych można rozszerzyć na zasoby platformy Azure. Zasoby platformy Azure mogą używać tożsamości zarządzanych do uwierzytelniania się w innych usługach, które obsługują uwierzytelnianie Microsoft Entra. Aby uzyskać więcej informacji, zobacz Usługi platformy Azure, które mogą używać tożsamości zarządzanych do uzyskiwania dostępu do innych usług.

Zasady dostępu warunkowego

Dostęp warunkowy opisuje zasady dotyczące decyzji o dostępie. Aby korzystać z dostępu warunkowego, musisz zrozumieć ograniczenia wymagane w przypadku użycia. Skonfiguruj Microsoft Entra dostęp warunkowy, konfigurując zasady dostępu na podstawie potrzeb operacyjnych.

Aby uzyskać więcej informacji, zobacz Dostęp warunkowy: użytkownicy, grupy i tożsamości obciążeń.

Zarządzanie dostępem do grupy

Zamiast udzielać uprawnień określonym użytkownikom, przypisz dostęp do grup w identyfikatorze Microsoft Entra. Jeśli grupa nie istnieje, skontaktuj się z zespołem tożsamości, aby go utworzyć. Następnie możesz dodawać i usuwać członków grupy spoza platformy Azure i upewnić się, że uprawnienia są aktualne. Grupę można również używać do innych celów, takich jak listy wysyłkowe.

Aby uzyskać więcej informacji, zobacz Zabezpieczanie kontroli dostępu przy użyciu grup w identyfikatorze Microsoft Entra.

Wykrywanie zagrożeń

Ochrona tożsamości Microsoft Entra może pomóc wykrywać, badać i korygować zagrożenia oparte na tożsamościach. Aby uzyskać więcej informacji, zobacz Co to jest usługa Identity Protection?.

Wykrywanie zagrożeń może mieć postać reagowania na alert o podejrzanych działaniach lub proaktywne wyszukiwanie nietypowych zdarzeń w dziennikach aktywności. Analiza zachowań użytkowników i jednostek (UEBA) w usłudze Microsoft Sentinel ułatwia wykrywanie podejrzanych działań. Aby uzyskać więcej informacji, zobacz Identyfikowanie zaawansowanych zagrożeń za pomocą funkcji UEBA.

Systemy hybrydowe

Na platformie Azure nie synchronizuj kont z identyfikatorem Microsoft Entra, które mają wysokie uprawnienia w istniejącej usłudze Active Directory. Ta synchronizacja jest zablokowana w domyślnej konfiguracji Microsoft Entra Connect Sync, dlatego musisz tylko potwierdzić, że ta konfiguracja nie została dostosowana.

Aby uzyskać informacje na temat filtrowania w identyfikatorze Microsoft Entra, zobacz Microsoft Entra Connect Sync: Konfigurowanie filtrowania.

Rejestrowanie tożsamości

Włącz ustawienia diagnostyczne w zasobach platformy Azure , aby emitować informacje, których można użyć jako dziennika inspekcji. Informacje diagnostyczne pokazują, które tożsamości próbują uzyskać dostęp do zasobów i wyniku tych prób. Zebrane dzienniki są wysyłane do usługi Azure Monitor.

Kompromis: Rejestrowanie wiąże się z kosztami z powodu magazynu danych używanego do przechowywania dzienników. Może to również spowodować wpływ na wydajność, szczególnie w przypadku kodu i rozwiązań rejestrowania dodanych do aplikacji.

Przykład

W poniższym przykładzie przedstawiono implementację tożsamości. Różne typy tożsamości są używane razem w celu zapewnienia wymaganych poziomów dostępu.

Diagram przedstawiający implementację tożsamości.

Składniki tożsamości

  • Tożsamości zarządzane przez system. Microsoft Entra ID zapewnia dostęp do płaszczyzn danych usług, które nie są narażone na użytkowników, takich jak azure Key Vault i magazyny danych. Te tożsamości kontrolują również dostęp za pośrednictwem kontroli dostępu opartej na rolach do płaszczyzny zarządzania platformy Azure pod kątem składników obciążeń, agentów wdrażania i członków zespołu.

  • Tożsamości obciążeń. Usługi aplikacji w klastrze Azure Kubernetes Service (AKS) używają tożsamości obciążeń do uwierzytelniania się w innych składnikach rozwiązania.

  • Tożsamości zarządzane. Składniki systemu w roli klienta używają tożsamości zarządzanych przez system, w tym agentów kompilacji.

  • Tożsamości ludzkie. Uwierzytelnianie użytkownika i operatora jest delegowane do identyfikatora Microsoft Entra lub identyfikatora Microsoft Entra (natywnego, B2B lub B2C).

Bezpieczeństwo wstępnych wpisów tajnych ma kluczowe znaczenie dla każdej aplikacji. Usługa Azure Key Vault zapewnia bezpieczny mechanizm magazynowania dla tych wpisów tajnych, w tym usługi Redis i wpisów tajnych innych firm.

Mechanizm rotacji służy do zapewnienia, że wpisy tajne nie zostały naruszone. Tokeny dla Platforma tożsamości Microsoft implementacji protokołu OAuth 2 i OpenID Connect są używane do uwierzytelniania użytkowników.

Azure Policy służy do zapewnienia, że składniki tożsamości, takie jak Key Vault, używają kontroli dostępu opartej na rolach zamiast zasad dostępu. JIT i JEA zapewniają tradycyjne stałe uprawnienia dla operatorów ludzkich.

Dzienniki dostępu są włączane we wszystkich składnikach za pośrednictwem Diagnostyka Azure lub kodu dla składników kodu.

Lista kontrolna zabezpieczeń

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna zabezpieczeń