Struktura dostępu warunkowego i zasady
Ten artykuł przedstawia ramy do implementacji architektury dostępu warunkowego opartej na personach, takiej jak opisana w architektura dostępu warunkowego Zero Trust. W tym artykule znajdują się szczegółowe informacje na temat tworzenia i nazywania zasad dostępu warunkowego. Istnieje również punkt wyjścia do tworzenia zasad.
Jeśli nie używasz ram, takich jak te przedstawione tutaj, w tym standardu nazewnictwa, zasady są tworzone z czasem przez różne osoby w sposób ad hoc. Może to spowodować nakładanie się zasad. Jeśli osoba, która utworzyła zasady, nie jest już dostępna, może być trudno innym znać cel polityki.
Przestrzeganie struktury ustrukturyzowanej ułatwia zrozumienie zasad. Ułatwia to również pokrycie wszystkich scenariuszy i unikanie zasad powodujących konflikt, które są trudne do rozwiązania.
Konwencje nazewnictwa
Prawidłowo zdefiniowana konwencja nazewnictwa pomaga tobie i współpracownikom zrozumieć przeznaczenie zasad, co ułatwia zarządzanie zasadami i rozwiązywanie problemów. Konwencja nazewnictwa powinna pasować do struktury używanego przez Ciebie modelu do tworzenia zasad.
Zalecane zasady nazewnictwa są oparte na osobach, typach zasad i aplikacjach. Wygląda na to:
<CANumber>—<Persona>—<PolicyType>—<App>—<Platform>—<GrantControl>—<OptionalDescription>
Składniki tej nazwy są opisane tutaj:
| Komponent nazewnictwa | Opis/przykład |
|---|---|
| Numer urzędu certyfikacji | Służy do szybkiego identyfikowania zakresu i kolejności typów zasad. Przykład: CA001-CA099. |
| Osobowość | Globalni, Administratorzy, Wewnętrzni, Zewnętrzni, GośćUżytkownicy, GośćAdministratorzy, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Typ zasad | OchronaPodstawowa, OchronaAplikacji, OchronaDanych, OchronaTożsamości, RedukcjaPowierzchniAtaku, Zgodność. |
| Aplikacja | AllApps, O365 (dla wszystkich usług Office 365), EXO (dla usługi Exchange Online). |
| Platforma | AnyPlatform, Unknown, WindowsPhone, macOS, iOS, Android. |
| Udzielanie kontroli | Blokuj, ADHJ, Zgodne, Niezarządzane (gdzie stan urządzenia jest określony jako niezarządzany). |
| Opis | Opcjonalny opis przeznaczenia zasad. |
Schemat numerowania
Aby ułatwić administrowanie, sugerujemy następujący schemat numerowania:
| Grupa użytkownika | Alokacja liczb |
|---|---|
| Ca-Persona-Global | CA001-CA099 |
| Ca-Persona-Admins | CA100-CA199 |
| Ca-Persona-Internals | CA200-CA299 |
| Ca-Persona-Externals | CA300-CA399 |
| Ca-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| Ca-Persona-M365ServiceAccounts | CA600-CA699 |
| Ca-Persona-AzureServiceAccounts | CA700-CA799 |
| Ca-Persona-CorpServiceAccounts | CA800-CA899 |
| Ca-Persona-WorkloadIdentities | CA900-CA999 |
| Ca-Persona-Developers | CA1000-CA1099 |
Typy zasad
Są to zalecane typy zasad:
| Typ zasad | Opis/przykłady |
|---|---|
| BaseProtection | Dla każdej osoby istnieje ochrona punktu odniesienia, która jest objęta tym typem zasad. W przypadku użytkowników na urządzeniach zarządzanych zazwyczaj są to znany użytkownik i znane urządzenie. W przypadku gości zewnętrznych może to być znany użytkownik i uwierzytelnianie wieloskładnikowe. Ochrona podstawowa to domyślna zasada dla wszystkich aplikacji dla użytkowników w danej kategorii. Jeśli określona aplikacja powinna mieć inne zasady, wyklucz tę aplikację z zasad ochrony podstawowej i dodaj jawne zasady przeznaczone tylko dla tej aplikacji. Przykład: Załóżmy, że podstawowa ochrona systemów wewnętrznych jest wymagana dla znanego użytkownika i znanego urządzenia dla wszystkich aplikacji w chmurze, ale chcesz zezwolić programowi Outlook na korzystanie z dowolnego urządzenia. Możesz wykluczyć usługę Exchange Online z podstawowych zasad ochrony i dodać oddzielne zasady dla usługi Exchange Online, w przypadku których wymagane jest znane urządzenie LUB uwierzytelnianie wieloskładnikowe. |
| Ochrona Tożsamości | Oprócz podstawowej ochrony dla każdej osoby można mieć zasady dostępu warunkowego, które odnoszą się do tożsamości. Przykłady: Blokuj starsze uwierzytelnianie, wymaga dodatkowego uwierzytelniania wieloskładnikowego dla wysokiego ryzyka związanego z użytkownikiem lub logowaniem, wymagaj znanego urządzenia do rejestracji uwierzytelniania wieloskładnikowego. |
| Ochrona danych | Ten typ zasad wskazuje zasady różnicowe, które chronią dane jako dodatkową warstwę ponad podstawową ochroną. Przykłady:
|
| Ochrona aplikacji | Ten typ zasad jest kolejnym dodatkiem do ochrony podstawowej. Przykłady:
|
| Redukcja Powierzchni Ataku | Celem tych zasad jest eliminowanie różnych ataków. Przykłady:
|
| Zgodność | Możesz użyć zasad zgodności, aby wymagać od użytkownika wyświetlania warunków użytkowania dla gości, którzy uzyskują dostęp do usług klienta. |
Aplikacja
W poniższej tabeli opisano składnik aplikacji w nazwie zasady:
| Nazwa aplikacji | Opis/przykłady |
|---|---|
| Wszystkie aplikacje | AllApps wskazuje, że wszystkie aplikacje w chmurze są objęte zasadami dostępu warunkowego. Wszystkie punkty końcowe są omówione, w tym te, które obsługują dostęp warunkowy, i te, które nie. W niektórych scenariuszach obejmowanie wszystkich aplikacji nie działa prawidłowo. Zalecamy uwzględnienie wszystkich aplikacji w polityce bazowej, aby wszystkie urządzenia końcowe zostały objęte tą polityką. Nowe aplikacje, które są wyświetlane w identyfikatorze Entra firmy Microsoft, będą również automatycznie zgodne z zasadami. |
| <AppName> |
<AppName> to zamiennik nazwy aplikacji, do którego odnoszą się zasady. Unikaj zbyt długiej nazwy. Przykładowe nazwy:
|
Typ platformy
Poniższa tabela opisuje składnik Platforma w nazwie polityki.
| Typ platformy | Opis |
|---|---|
| AnyPlatform | Zasady dotyczą dowolnej platformy. Zazwyczaj można to skonfigurować, wybierając pozycję Dowolne urządzenie. (W zasadach dostępu warunkowego używane są zarówno słowo platform, jak i słowo device). |
| Ios | Zasady dotyczą platform Apple iOS. |
| Android | Polityka dotyczy platform Android Google. |
| Windows | Te zasady dotyczą platformy systemu Windows. |
| Linux | Te zasady dotyczą platform systemu Linux. |
| WindowsPhone | Polityka dotyczy platform Windows Phone. |
| macOS | Polityka dotyczy platform macOS |
| iOSAndroid | Zasady dotyczą zarówno platform iOS, jak i Android. |
| Nieznany | Polityka dotyczy każdej platformy, która nie jest wcześniej wymieniona. Zazwyczaj można to skonfigurować, włączając Dowolne urządzenie i wykluczając wszystkie poszczególne platformy. |
Rodzaje kontroli
W poniższej tabeli opisano składnik Grant Control nazwy zasad:
| Typ udzielenia | Opis/przykłady |
|---|---|
| Blok | Polityka blokuje logowanie się |
| MFA | Zasady wymagają uwierzytelniania wieloskładnikowego. |
| Zgodny | Zasady wymagają zgodnego urządzenia określonego przez program Endpoint Manager, więc urządzenie musi być zarządzane przez program Endpoint Manager. |
| CompliantorAADHJ | Zasady wymagają zgodnego urządzenia LUB urządzenia połączonego hybrydowo z Microsoft Entra. Standardowy komputer firmowy przyłączony do domeny jest również przyłączony do Hybrid Microsoft Entra ID. Telefony komórkowe i komputery z systemem Windows 10, które są współzarządzane lub dołączone do Microsoft Entra, mogą spełniać wymagania. |
| Zgodne i AADHJ | Zasady wymagają urządzenia, które jest zgodne i jednocześnie połączone hybrydowo z Microsoft Entra. |
| Uwierzytelnianie Wieloskładnikowe lub Zgodny | Zasady wymagają zgodnego urządzenia LUB uwierzytelniania wieloskładnikowego, jeśli nie są zgodne. |
| MFA i zgodność | Zasady wymagają zgodnego urządzenia i uwierzytelniania wieloskładnikowego. |
| MFAorAADHJ | Zasady wymagają komputera przyłączonego hybrydowo do firmy Microsoft LUB uwierzytelniania wieloskładnikowego, jeśli nie jest to komputer dołączony hybrydowo do firmy Microsoft Entra. |
| MFAandAADHJ | Zasady wymagają komputera hybrydowo dołączonego do Microsoft Entra ORAZ uwierzytelniania wieloskładnikowego. |
| WymagajZatwierdzonegoKlienta | Zasady wymagają zatwierdzonej aplikacji klienckiej. |
| Ochrona aplikacji | Polityka wymaga ochrony aplikacji |
| Niezarządzany | Polityka dotyczy urządzeń, które nie są rozpoznawane przez Microsoft Entra ID. Możesz na przykład użyć tego typu udzielania, aby zezwolić na dostęp do usługi Exchange Online z dowolnego urządzenia. |
Nazwane lokalizacje
Zalecamy zdefiniowanie tych standardowych lokalizacji do użycia w zasadach dostępu warunkowego:
- Zaufane adresy IP/sieci wewnętrzne. Te podsieci IP reprezentują lokalizacje i sieci, które mają ograniczenia dostępu fizycznego lub inne mechanizmy kontroli, takie jak zarządzanie systemem komputerowym, uwierzytelnianie na poziomie sieci lub wykrywanie nieautoryzowanego dostępu. Te lokalizacje są bezpieczniejsze, więc wymuszanie dostępu warunkowego może być złagodzone. Czy platforma Azure lub inne lokalizacje centrów danych (IP) powinny być uwzględnione w tej lokalizacji czy mieć własne nazwane lokalizacje?
- Zaufane adresy IP firmy Citrix. Jeśli masz lokalne rozwiązanie Citrix, może być przydatne skonfigurowanie oddzielnych wychodzących adresów IPv4 dla farm Citrix, jeśli musisz mieć możliwość łączenia się z usługami w chmurze z sesji Citrix. W takim przypadku można wykluczyć te lokalizacje z zasad dostępu warunkowego, jeśli zajdzie taka potrzeba.
- Lokalizacje rozwiązania Zscaler, jeśli ma to zastosowanie. Komputery mają zainstalowanego agenta ZPA i przesyłają cały ruch do Internetu do chmury Zscaler lub przez nie. Warto więc zdefiniować źródłowe adresy IP rozwiązania Zscaler w dostępie warunkowym i wymagać, aby wszystkie żądania z urządzeń innych niż urządzenia przenośne przechodziły przez rozwiązanie Zscaler.
- Kraje/regiony, z którymi można zezwolić na działalność biznesową. Przydatne może być podzielenie krajów/regionów na dwie grupy lokalizacji: jeden reprezentujący obszary świata, w których pracownicy zazwyczaj pracują, i jeden reprezentujący inne lokalizacje. Dzięki temu można zastosować dodatkowe mechanizmy kontroli do żądań pochodzących z spoza obszarów, w których organizacja normalnie działa.
- Lokalizacje, w których uwierzytelnianie wieloskładnikowe może być trudne lub niemożliwe. W niektórych scenariuszach wymaganie uwierzytelniania wieloskładnikowego może utrudnić pracownikom wykonywanie pracy. Na przykład pracownicy mogą nie mieć czasu ani możliwości reagowania na częste wyzwania związane z uwierzytelnianiem wieloskładnikowym. Lub w niektórych lokalizacjach ekranowanie RF lub interferencja elektryczna może utrudnić korzystanie z urządzeń przenośnych. Zazwyczaj używa się innych kontroli w tych lokalizacjach lub mogą być one zaufane.
Mechanizmy kontroli dostępu oparte na lokalizacji opierają się na źródłowym adresie IP żądania w celu określenia lokalizacji użytkownika w momencie żądania. Fałszowanie w publicznym Internecie nie jest łatwe, ale ochrona zapewniana przez granice sieci może być uważana za mniej istotne niż kiedyś. Nie zalecamy polegania wyłącznie na lokalizacji jako warunku dostępu. Jednak w niektórych scenariuszach może to być najlepsza kontrola, której można użyć, na przykład jeśli zabezpieczasz dostęp z konta usługi ze środowiska lokalnego, który jest używany w scenariuszu nieinterakcyjnym.
Zalecane zasady dostępu warunkowego
Utworzyliśmy arkusz kalkulacyjny zawierający zalecane zasady dostępu warunkowego. Możesz pobrać arkusz kalkulacyjny tutaj.
Użyj sugerowanych zasad jako punktu wyjścia.
Twoje zasady prawdopodobnie zmienią się w czasie, aby uwzględnić przypadki użycia, które są ważne dla Twojej firmy. Oto kilka przykładów scenariuszy, które mogą wymagać zmian:
- Zaimplementuj dostęp tylko do odczytu do usługi Exchange Online dla pracowników przy użyciu dowolnego niezarządzanego urządzenia na podstawie uwierzytelniania wieloskładnikowego, ochrony aplikacji i zatwierdzonej aplikacji klienckiej.
- Zaimplementuj ochronę informacji, aby upewnić się, że poufne informacje nie są pobierane bez lepszej ochrony zapewnianej przez usługę Azure Information Protection.
- Zapewnij ochronę przed kopiowaniem i wklejaniem przez gości.
Obecnie wiele wersji jest w publicznej wersji zapoznawczej, więc można się wkrótce spodziewać aktualizacji sugerowanego zestawu zasad dostępu warunkowego.
Wskazówki dotyczące dostępu warunkowego
Teraz, gdy masz zestaw początkowy zasad dostępu warunkowego, musisz wdrożyć je w kontrolowany i etapowy sposób. Zalecamy użycie modelu wdrażania.
Oto jedno podejście:
Chodzi o to, aby najpierw wdrożyć zasady dla niewielkiej liczby użytkowników w jednej grupie osób. Dla tego wdrożenia możesz użyć skojarzonej grupy microsoft Entra o nazwie Persona Ring 0. Po sprawdzeniu, czy wszystko działa, należy zmienić przypisanie do grupy Persona Ring 1, która ma więcej członków itd.
Następnie włączysz zasady przy użyciu tego samego podejścia opartego na pierścieniu do momentu wdrożenia wszystkich zasad.
Zazwyczaj zarządzasz członkami pierścienia 0 i pierścieniem 1 ręcznie. Pierścień 2 lub 3, który zawiera setki lub nawet tysiące użytkowników, może być zarządzany za pośrednictwem grupy dynamicznej opartej na procentowym udziale użytkowników w danej personie.
Użycie pierścieni w ramach modelu wdrażania nie dotyczy tylko początkowego wdrożenia. Można go również użyć, gdy są wymagane nowe zasady lub zmiany istniejących zasad.
Po zakończeniu wdrażania należy również zaprojektować i wdrożyć mechanizmy monitorowania i kontroli, które zostały omówione w zasadach dostępu warunkowego.
Oprócz automatyzacji początkowego wdrożenia można zautomatyzować zmiany zasad przy użyciu potoków ciągłej integracji/ciągłego wdrażania. W tej automatyzacji można użyć usługi Microsoft365DSC.
Współpracownicy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Claus Jespersen | ID Konsultanta Wiodącego&
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- ścieżka szkoleniowa : Implementowanie tożsamości i dostępu oraz zarządzanie nimi
- zasady dostępu warunkowego