W tym artykule opisano architekturę dostępu warunkowego, która jest zgodna z zasadami zerowego zaufania. Architektura korzysta z podejścia opartego na osobach, aby utworzyć ustrukturyzowaną strukturę dostępu warunkowego.
Architektura zerowego zaufania dostępu warunkowego
Najpierw musisz wybrać architekturę. Zalecamy rozważenie architektury dostępu warunkowego ukierunkowanego lub zerowego zaufania. Na tym diagramie przedstawiono odpowiednie ustawienia:
Architektura dostępu warunkowego zero trust jest taka, która najlepiej pasuje do zasad zero trust. W przypadku wybrania opcji Wszystkie aplikacje w chmurze w zasadach dostępu warunkowego wszystkie punkty końcowe są chronione przez podane kontrolki udzielania, takie jak znany użytkownik i znane lub zgodne urządzenie. Jednak zasady nie dotyczą tylko punktów końcowych i aplikacji, które obsługują dostęp warunkowy. Dotyczy to dowolnego punktu końcowego, z którego korzysta użytkownik.
Przykładem jest punkt końcowy przepływu logowania urządzenia, który jest używany w różnych nowych narzędziach programu PowerShell i programu Microsoft Graph. Przepływ logowania urządzenia umożliwia logowanie z urządzenia, na którym nie można wyświetlić ekranu logowania, takiego jak urządzenie IoT.
Na danym urządzeniu jest uruchamiane polecenie logowania oparte na urządzeniu, a dla użytkownika jest wyświetlany kod. Ten kod jest używany na innym urządzeniu. Użytkownik przechodzi do https://aka.ms/devicelogin i określa nazwę użytkownika i hasło. Po zalogowaniu się z innego urządzenia logowanie powiedzie się na urządzeniu IoT w tym kontekście użytkownika.
Wyzwaniem podczas logowania jest to, że nie obsługuje dostępu warunkowego opartego na urządzeniach. Oznacza to, że nikt nie może używać narzędzi i poleceń w przypadku zastosowania zasad punktu odniesienia, które wymagają znanego użytkownika i znanego urządzenia dla wszystkich aplikacji w chmurze. Istnieją inne aplikacje, które mają ten sam problem z dostępem warunkowym opartym na urządzeniach.
Druga architektura, docelowa, jest oparta na zasadzie, że jest przeznaczona tylko dla poszczególnych aplikacji, które mają być chronione w zasadach dostępu warunkowego. W takim przypadku logowanie urządzenia dla punktów końcowych wcześniej objętych wszystkimi aplikacjami w chmurze, takimi jak wywołania grafu do identyfikatora Entra firmy Microsoft, nie jest chronione przez zasady dostępu warunkowego, więc nadal działają.
W przypadku używania identyfikatora device-login jako przykładu do odróżnienia dwóch architektur można uwierzytelnić się przy użyciu logowania urządzenia. Logowanie urządzenia może potencjalnie być dozwolone dla jednej lub kilku pojedynczych aplikacji, biorąc pod uwagę, że każda aplikacja jest docelowa, a tym samym może zostać wykluczona w zasadach dostępu warunkowego, które wymagają logowania opartego na urządzeniach.
Wyzwanie związane z docelową architekturą polega na tym, że możesz zapomnieć o ochronie wszystkich aplikacji w chmurze. Mimo to należy wybrać wszystkie wybrane aplikacje w zasadach dostępu warunkowego. Pozostawisz dostęp do aplikacji, których nie można wybrać bez ochrony. Przykłady obejmują dostęp do portalu pakietu Office, portalu ea platformy Azure (Umowa Enterprise) oraz portalu informacji o zabezpieczeniach, które są bardzo poufnymi portalami.
Inną kwestią jest to, że liczba aplikacji Office 365 i Microsoft Entra rośnie wraz z upływem czasu, ponieważ firma Microsoft i partnerzy udostępniają nowe funkcje, a administratorzy IT integrują różne aplikacje z identyfikatorem Entra firmy Microsoft. Dostęp do wszystkich takich aplikacji jest chroniony tylko wtedy, gdy masz mechanizm, który wykrywa dowolną nową aplikację, która obsługuje dostęp warunkowy i automatycznie stosuje do niej zasady. Tworzenie i utrzymywanie takiego skryptu może być trudne.
Ponadto maksymalna obsługiwana liczba aplikacji dla wszystkich zasad dostępu warunkowego wynosi około 250. Może być możliwe dodanie aż 600 aplikacji przed wystąpieniem błędu dotyczącego przekroczenia ładunku, ale ta liczba nie jest obsługiwana.
Osoby dostępu warunkowego
Istnieje wiele sposobów struktury zasad dostępu warunkowego. Jednym z podejść jest struktura zasad na podstawie poufności uzyskiwanego dostępu do zasobu. W praktyce takie podejście może być trudne do zaimplementowania w sposób, który nadal chroni dostęp do zasobów dla różnych użytkowników.
Można na przykład zdefiniować zasady dostępu warunkowego, które wymagają znanego użytkownika i znanego urządzenia w celu uzyskania dostępu do poufnego zasobu, do którego muszą uzyskiwać dostęp zarówno goście, jak i pracownicy. Gdy goście próbują uzyskać dostęp z urządzenia zarządzanego, żądanie dostępu nie będzie działać. Należy dostosować zasady dostępu warunkowego, aby spełnić oba wymagania, co zwykle spowoduje, że zasady spełniają mniej bezpieczne wymaganie.
Innym podejściem jest próba zdefiniowania zasad dostępu na podstawie tego, gdzie użytkownik znajduje się w organizacji. Takie podejście może spowodować powstanie wielu zasad dostępu warunkowego i może być niezarządzane.
Lepszym podejściem jest struktura zasad związanych z typowymi potrzebami dostępu i wiązanie zestawu potrzeb dostępu w persona dla grupy użytkowników, którzy mają takie same potrzeby. Osoby to typy tożsamości, które mają wspólne atrybuty przedsiębiorstwa, obowiązki, środowiska, cele i dostęp.
Zrozumienie sposobu uzyskiwania dostępu do zasobów i zasobów przedsiębiorstwa przez różne osoby jest integralną częścią opracowywania kompleksowej strategii zero trust.
Poniżej przedstawiono niektóre sugerowane osoby dostępu warunkowego firmy Microsoft:
Firma Microsoft zaleca również zdefiniowanie oddzielnej osoby dla tożsamości, które nie są częścią żadnej innej grupy osób. Jest to nazywane globalną osobą. Globalne jest przeznaczone do wymuszania zasad dla tożsamości, które nie są w grupie persona i zasad, które powinny być wymuszane dla wszystkich osób.
W poniższych sekcjach opisano niektóre zalecane osoby.
Globalne
Globalny to persona/symbol zastępczy zasad, które są ogólne. Służy do definiowania zasad, które mają zastosowanie do wszystkich osób lub które nie mają zastosowania do jednej konkretnej osoby. Użyj jej w przypadku zasad, które nie są objęte innymi osobami. Ta osoba jest potrzebna do ochrony wszystkich odpowiednich scenariuszy.
Załóżmy na przykład, że chcesz użyć jednej zasady do blokowania starszego uwierzytelniania dla wszystkich użytkowników. Zasady globalne można ustawić zamiast używać grupy starszych zasad, które mogą być inne dla różnych osób.
Inny przykład: chcesz zablokować dane konto lub użytkownika z określonych aplikacji, a użytkownik lub konto nie jest częścią żadnej osoby. Jeśli na przykład tworzysz tożsamość w chmurze w dzierżawie firmy Microsoft Entra, ta tożsamość nie jest częścią żadnej innej osoby, ponieważ nie ma przypisanych żadnych ról firmy Microsoft Entra. Nadal może być konieczne zablokowanie tożsamości dostępu do usług Office 365.
Możesz zablokować dostęp do wszystkich tożsamości, które nie są objęte żadną grupą osób. Możesz też wymusić uwierzytelnianie wieloskładnikowe.
Administracja
W tym kontekście administrator ma dowolną tożsamość inną niż gość, chmurę lub synchronizację, która ma dowolny identyfikator Entra firmy Microsoft lub inną rolę administratora platformy Microsoft 365 (na przykład w aplikacjach Microsoft Defender dla Chmury, exchange, usłudze Defender dla punktu końcowego lub Menedżerze zgodności). Ponieważ osoby, które mają te role, są objęte inną osobą, goście są wykluczeni z tej osoby.
Niektóre firmy mają oddzielne konta dla poufnych ról administratora, na których opiera się ta osoba. Optymalnie administratorzy używają tych poufnych kont z stacji roboczej z dostępem uprzywilejowanym (PAW). Jednak często widzimy, że konta administratora są używane na standardowych stacjach roboczych, gdzie użytkownik przełącza się tylko między kontami na jednym urządzeniu.
Możesz chcieć odróżnić się od poufności ról administratora chmury i przypisać mniej wrażliwe role platformy Azure do osoby wewnętrznej zamiast używać oddzielnych kont. Następnie można użyć podniesienia uprawnień Just-In-Time (JIT). W takim przypadku użytkownik jest objęty dwoma zestawami zasad dostępu warunkowego, po jednym dla każdej osoby. Jeśli używasz stacji roboczych z dostępem uprzywilejowanym, możesz również wprowadzić zasady korzystające z filtrów urządzeń w dostępie warunkowym w celu ograniczenia dostępu, aby administratorzy mogli korzystać tylko z stacji roboczych z dostępem uprzywilejowanym.
Deweloperzy
Osoba deweloperów zawiera użytkowników, którzy mają unikatowe potrzeby. Są one oparte na kontach usługi Active Directory, które są synchronizowane z identyfikatorem Entra firmy Microsoft, ale potrzebują specjalnego dostępu do usług, takich jak Azure DevOps, potoki ciągłej integracji/ciągłego wdrażania, przepływ kodu urządzenia i GitHub. Osoba deweloperów może obejmować użytkowników, którzy są uważane za wewnętrzne i inne uważane za zewnętrzne, ale osoba powinna znajdować się tylko w jednej z osób.
Elementy wewnętrzne
Elementy wewnętrzne zawierają wszystkich użytkowników, którzy mają konto usługi Active Directory zsynchronizowane z identyfikatorem Entra firmy Microsoft, którzy są pracownikami firmy i którzy pracują w standardowej roli użytkownika końcowego. Zalecamy dodanie użytkowników wewnętrznych, którzy są deweloperami do osoby deweloperów.
Zewnętrzne
Ta osoba zawiera wszystkich zewnętrznych konsultantów, którzy mają konto usługi Active Directory zsynchronizowane z identyfikatorem Entra firmy Microsoft. Zalecamy dodanie użytkowników zewnętrznych będących deweloperami do osoby deweloperów.
Zatrzymali
Goście posiadają wszystkich użytkowników, którzy mają konto gościa Microsoft Entra, które zostało zaproszone do dzierżawy klienta.
Gość Administracja s
Osoba gościa Administracja s zawiera wszystkich użytkowników, którzy mają konto gościa Microsoft Entra, które ma przypisane dowolne z wcześniej wymienionych ról administratora.
Microsoft365ServiceAccounts
Ta osoba zawiera konta usług oparte na chmurze (Microsoft Entra ID), które są używane do uzyskiwania dostępu do usług Platformy Microsoft 365, gdy żadne inne rozwiązanie nie spełnia potrzeby, na przykład przy użyciu tożsamości usługi zarządzanej.
AzureServiceAccounts
Ta osoba zawiera konta usług oparte na chmurze (Microsoft Entra ID), które są używane do uzyskiwania dostępu do usług platformy Azure (IaaS/PaaS), gdy żadne inne rozwiązanie nie spełnia potrzeby, na przykład przy użyciu tożsamości usługi zarządzanej.
Konta usługi corpservice
Ta osoba zawiera konta usług oparte na użytkownikach, które mają wszystkie te cechy:
- Pochodzą z lokalna usługa Active Directory.
- Są używane ze środowiska lokalnego lub z maszyny wirtualnej opartej na usłudze IaaS w innym centrum danych (w chmurze), na przykład na platformie Azure.
- Są synchronizowane z wystąpieniem firmy Microsoft Entra, które uzyskuje dostęp do dowolnej usługi platformy Azure lub platformy Microsoft 365.
Należy unikać tego scenariusza.
Identyfikatory obciążeń
Ta osoba zawiera tożsamości maszyn, takie jak jednostki usługi Microsoft Entra i tożsamości zarządzane. Dostęp warunkowy obsługuje teraz ochronę dostępu do zasobów z tych kont, z pewnymi ograniczeniami w odniesieniu do warunków i kontroli udzielania.
Karty szablonów programu Access
Zalecamy używanie kart szablonów dostępu do definiowania cech każdej osoby. Oto przykład:
Karta szablonu dla każdej osoby zawiera dane wejściowe dotyczące tworzenia określonych zasad dostępu warunkowego dla każdej osoby.
Wskazówki dotyczące dostępu warunkowego
Przejrzyj strukturę dostępu warunkowego, która zawiera ustrukturyzowane podejście do zasad grupowania na podstawie utworzonych osób.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Claus Jespersen | Identyfikator &s głównego konsultanta
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- ścieżka Edukacja: implementowanie tożsamości i dostępu oraz zarządzanie nimi
- Co to jest dostęp warunkowy?
- Typowe zasady dostępu warunkowego