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

Dotyczy tego zalecenia listy kontrolnej dotyczącej zabezpieczeń platformy Azure Well-Architected Framework:

SE:05

Zaimplementuj ścisłe, warunkowe i poddane inspekcji zarządzanie tożsamościami i dostępem (IAM) we wszystkich użytkownikach obciążeń, członkach zespołu i składnikach systemu. Ogranicz dostęp wyłącznie do w razie potrzeby. 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 punktu widzenia 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 nietrafieni 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 

Warunki	Definicja
Uwierzytelnianie (AuthN)	Proces, który weryfikuje, czy tożsamość jest tym, kto lub co mówi.
Autoryzacja (AuthZ)	Proces, który sprawdza, 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 Microsoft Entra ID.
Osoba	Funkcja zadania lub tytuł, który ma zestaw obowiązków i akcji.
Klucze wstępnego udostępniania	Typ wpisu tajnego, który jest udostępniany między dostawcą a konsumentem i 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.
Scope	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. Wszyscy członkowie grupy uzyskują 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 nazywanego podmiotem zabezpieczeń. Grupa zabezpieczeń jest przykładem podmiotu zabezpieczeń. Ta hierarchiczna relacja 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.

Skorzystaj 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 na podstawie najnowszych wektorów 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.

Uwierzytelnianie

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 umożliwiający lub odrzucający akcje żądane przez zweryfikowaną tożsamość. Akcja może być operacyjna lub powiązana z zarządzaniem zasobami.

Autoryzacja wymaga przypisania uprawnień do tożsamości, które należy wykonać przy użyciu funkcji udostępnianych 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 oraz akcje, które będą wykonywane przez zasoby i osoby. Strategia musi obejmować wszystkie przypadki użycia obsługujące przepływy, które docierają do obciążenia lub jego składników (dostęp zewnętrzny) i 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ć przy użyciu myślenia o założeniu naruszenia zabezpieczeń. Na podstawie wymagań dotyczących tożsamości przypadku użycia lub osób zidentyfikuj opcje warunkowe. Unikaj używania jednego rozwiązania dla wszystkich przypadków użycia. Z drugiej strony kontrole 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 sprawdzić poprawność kontrolek i użyć dzienników na potrzeby inspekcji zgodności.

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

• Dostęp zewnętrzny. 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 poziomie szczegółowym składniki obciążenia mogą również potrzebować dostępu z zewnątrz. 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, 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 odniesieniu do innych zasobów.

  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:

Określanie akcji autoryzacji

Następnie musisz wiedzieć, co każda uwierzytelniona tożsamość próbuje zrobić, 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 na zewnątrz. 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, które mają miejsce na płaszczyźnie sterowania, powodują utworzenie, zmodyfikowanie lub usunięcie zasobu platformy Azure. Na przykład zmiany właściwości zasobu.

Aplikacje zwykle kierują operacje płaszczyzny danych, podczas gdy operacje często uzyskują dostęp zarówno do płaszczyzny kontroli, jak i danych. Aby zidentyfikować potrzeby autoryzacji, zanotuj akcje operacyjne, które można wykonać na zasobie. Aby uzyskać informacje na temat dozwolonych akcji 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ść autoryzuj akcje, które powinny być dozwolone. Tożsamość nie może robić więcej niż musi. Przed ustawieniem reguł autoryzacji musisz mieć jasne informacje o tym, 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, dlatego akcje odczytu i zapisu w zasobie danych muszą być dozwolone. Czy jednak aplikacja potrzebuje dostępu płaszczyzny kontroli 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 podobne do następujących:

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

Ograniczenie poziomu dostępu użytkowników, aplikacji lub usług 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 jest 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łową. Może istnieć nakładanie się na różne role 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. Ułatwia to zarządzanie rolami.

Unikaj uprawnień, które odwołują się konkretnie 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 negatywnego wpływu zarówno na bezpieczeństwo, jak i niezawodność.

Kompromis: Szczegółowe podejście do 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ń, rozszerzanie 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 można przypisywać 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. Są 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 mają negatywny wpływ na bezpieczeństwo.

Udzielanie ról rozpoczynających się od najniższych uprawnień i dodawanie większej liczby opartych na wymaganiach dotyczących dostępu do danych lub operacyjnych. Zespoły techniczne muszą mieć jasne wskazówki dotyczące implementowania uprawnień.

Jeśli chcesz uzyskać szczegółową kontrolę nad kontrolą RBAC, dodaj warunki przypisania roli na podstawie kontekstu, takie jak akcje i atrybuty.

Podejmowanie wyborów dostępu warunkowego

Nie udostępniaj wszystkim tożsamościom tego samego poziomu dostępu. Na podstawie Twoich decyzji należy podjąć dwa główne czynniki:

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

• Uprawnienia. Poziom uprawnień.

Te czynniki 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.

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

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

Chociaż czas i przywilej są głównymi 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ść i lokalizacja użytkownika, kondycja urządzenia, kontekst obciążenia, klasyfikacja danych i anomalie.

Na przykład może być konieczne uzyskanie dostępu do obciążenia przez tożsamości innych firm, takie jak dostawcy, partnerzy i klienci. Potrzebują 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 najmniejszych uprawnień i zapewniają wbudowaną analizę zagrożeń. Obejmuje to monitorowanie żądań dostępu i logowania. Dostawca tożsamości platformy Azure to identyfikator Firmy Microsoft Entra. Aby uzyskać więcej informacji, zobacz sekcję ułatwienia platformy Azure w tym artykule.

Ochrona kont o krytycznym wpływie

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 podjęcia kompletnego i przemyślanego podejścia w celu odizolowania tych systemów od ryzyka. Oto kilka strategii:

• Zminimalizuj liczbę kont o krytycznym znaczeniu.

• 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 należy postępować zgodnie z procesem dostępu awaryjnego.

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

• Wymuszanie kluczowych atrybutów zabezpieczeń przy użyciu zasad dostępu warunkowego.

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

Użyj jednej tożsamości w ś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 zapewnienia bezpieczeństwa. 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 z wysokimi uprawnieniami. Osoba atakująca może uzyskać pełną kontrolę nad zasobami lokalnymi i może to prowadzić do pomyślnego naruszenia zabezpieczeń konta w chmurze. Oceń strategię synchronizacji, filtrują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 z wysokimi uprawnieniami, 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ępnie współużytkowane, 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żytkowników 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ływanie wpisów tajnych.

• Zastosuj praktyki operacyjne, które obsługują 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 certyfikatów w usłudze Key Vault.

Zabezpieczanie środowisk programistycznych

Wszystkie skrypty i kod, narzędzia potoków i systemy kontroli źródła powinny być traktowane jako zasoby obciążenia. 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 na podstawie potrzeb. Repozytoria kodu muszą mieć wersje, a przeglądy kodu zabezpieczeń według elementów równorzędnych muszą być regularną praktyką zintegrowaną z cyklem projektowania. 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 jest możliwy do inspekcji. Sprawdza, czy strategie zakładania naruszenia są skuteczne. Obsługa dziennika inspekcji pomaga:

• Sprawdź, czy tożsamość jest uwierzytelniona przy użyciu silnego uwierzytelniania. Wszelkie działania muszą być śledzone , 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 wglądu w nie.

• Ocena dostępu 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 wykonywane przez nie akcje. Możesz użyć tych informacji 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 używają 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 ID to dzierżawa skojarzona z subskrypcją obciążenia. Śledzi tożsamości i ich dozwolone uprawnienia oraz 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ń firmy Microsoft dla segmentów użytkowników:

• Microsoft Entra ID. Pracownicy i zasoby przedsiębiorstwa.

• Tożsamość zewnętrzna Microsoft Entra. Partnerów.

• Azure AD B2C. Klientela.

• Lista zgodności federacji firmy Microsoft Entra. Rozwiązania federacyjne innych firm.

Możesz użyć identyfikatora Entra firmy Microsoft 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 być na bieżąco, odwiedzając stronę Co nowego w usłudze Microsoft Entra ID.

Kompromis: Microsoft Entra ID to pojedynczy punkt awarii, podobnie jak każda inna podstawowa usługa. Nie ma obejścia, dopóki awaria nie zostanie naprawiona przez firmę Microsoft. Jednak bogaty zestaw funkcji firmy Microsoft Entra przewyższa ryzyko korzystania z rozwiązań niestandardowych.

pomoc techniczna platformy Azure 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 Entra firmy Microsoft. 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 Wbudowane role usługi Microsoft Entra.

Oto kilka przypadków użycia:

• Przypisując użytkowników do ról, możesz kontrolować dostęp do zasobów platformy Azure. Aby uzyskać więcej informacji, zobacz Omówienie kontroli dostępu opartej na rolach w usłudze Microsoft Entra ID.

• Usługa Privileged Identity Management umożliwia aktywację ról opartych na czasie i zatwierdzania dla ról skojarzonych z tożsamościami o dużym wpływie. Aby uzyskać więcej informacji, zobacz Co to jest usługa Privileged Identity Management?.

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

Identyfikator Entra firmy Microsoft 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ż abstrakcja 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 firmy 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 dla decyzji dotyczącej dostępu. Aby korzystać z dostępu warunkowego, musisz zrozumieć ograniczenia wymagane dla przypadku użycia. Skonfiguruj dostęp warunkowy firmy Microsoft Entra, 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 grup

Zamiast udzielać uprawnień określonym użytkownikom, przypisz dostęp do grup w identyfikatorze Entra firmy Microsoft. 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. Możesz również użyć grupy do innych celów, takich jak listy wysyłkowe.

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

Wykrywanie zagrożeń

Ochrona tożsamości Microsoft Entra ułatwia wykrywanie, badanie i korygowanie zagrożeń opartych na tożsamościach. Aby uzyskać więcej informacji, zobacz Co to jest usługa Identity Protection?.

Wykrywanie zagrożeń może mieć formę 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ą analizy UEBA.

Systemy hybrydowe

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

Aby uzyskać informacje na temat filtrowania w usłudze Microsoft Entra ID, zobacz Microsoft Entra Connect Sync: Configure filtering (Synchronizacja programu Microsoft Entra Connect: 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ść, zwłaszcza 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.

Składniki tożsamości

• Tożsamości zarządzane przez system. Identyfikator Entra firmy Microsoft zapewnia dostęp do płaszczyzn danych usługi, które nie napotykają na użytkowników, takich jak usługa 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 dla składników obciążenia, agentów wdrażania i członków zespołu.

• Tożsamości obciążeń. Usługi aplikacji w klastrze usługi 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 człowieka. Uwierzytelnianie użytkownika i operatora jest delegowane do identyfikatora Entra firmy Microsoft lub identyfikatora Entra firmy Microsoft (natywnego, B2B lub B2C).

Bezpieczeństwo wstępnych wpisów tajnych ma kluczowe znaczenie dla każdej aplikacji. Usługa Azure Key Vault udostępnia bezpieczny mechanizm magazynu 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.

Usługa Azure Policy służy do zapewnienia, że składniki tożsamości, takie jak Usługa 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.

Pokrewne łącza

• Samouczek: automatyzowanie rotacji wpisu tajnego dla zasobów, które mają dwa zestawy poświadczeń uwierzytelniania
• Samouczek: aktualizowanie częstotliwości automatycznego obracania certyfikatów w usłudze Key Vault
• Co nowego w identyfikatorze Entra firmy Microsoft?
• Wbudowane role usługi Microsoft Entra
• Omówienie kontroli dostępu opartej na rolach w usłudze Microsoft Entra ID
• Co to są tożsamości obciążeń?
• Co to są tożsamości zarządzane dla zasobów platformy Azure?
• Dostęp warunkowy: tożsamości użytkowników, grup i obciążeń
• Synchronizacja usługi Microsoft Entra Connect: Konfigurowanie filtrowania

Lista kontrolna zabezpieczeń

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna zabezpieczeń