Ta funkcja jest dostępna w tych wersjach: Frontline Standard i Frontline Plus, Enterprise Standard i Enterprise Plus, Education Standard i Education Plus, Enterprise Essentials Plus oraz Cloud Identity Premium. Porównaj wersje
W tym artykule opisaliśmy typowe przypadki użycia dostępu zależnego od kontekstu i przedstawiliśmy przykładowe konfiguracje utworzone w trybie podstawowym.
Przykłady poziomów dostępu opracowanych w trybie zaawansowanym (za pomocą edytora CEL) znajdziesz w artykule Przykłady dostępu zależnego od kontekstu w trybie zaawansowanym.
Zezwalanie kontrahentom na dostęp tylko przez sieć firmową
Wiele firm chce ograniczyć dostęp kontrahentów do zasobów firmowych. Na przykład firmy, które korzystają z usług wykonawców, aby odpowiadać na ogólne pytania dotyczące pomocy lub pracować w centrach pomocy i centrach obsługi telefonicznej. Podobnie jak w przypadku pracowników pełnoetatowych kontrahenci muszą mieć obsługiwaną licencję, aby obejmowały ich zasady dostępu zależnego od kontekstu.
W tym przykładzie kontrahenci uzyskują dostęp do zasobów firmy tylko z określonego zakresu firmowych adresów IP.
| Nazwa poziomu dostępu | dostęp_kontrahenta |
| Kontrahenci uzyskają dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 | Podsieć IP (publiczna) 74.125.192.0/18 |
| Przypisanie poziomu dostępu | Jednostki organizacyjne przeznaczone dla kontrahentów Wszystkie aplikacje używane przez kontrahentów |
Blokowanie dostępu ze znanych adresów IP hakerów
Aby chronić zasoby firmy przed naruszeniem bezpieczeństwa, wiele firm blokuje dostęp do znanych źródeł wysokiego ryzyka.
W tym przykładzie adres IP 74.125.195.105 jest zablokowany. Użytkownicy uzyskują dostęp do zasobów firmowych, jeśli ich sesje pochodzą z dowolnego innego adresu IP. Możesz podać wiele adresów i zakresów adresów IP.
| Nazwa poziomu dostępu | blokada_adresów_hakerów |
| Użytkownik uzyska dostęp, jeśli: | Nie spełniają atrybutów |
| Atrybut warunku 1 | Podsieć IP (publiczna) 74.125.195.105 |
| Przypisanie poziomu dostępu | Jednostka organizacyjna najwyższego poziomu Wszystkie aplikacje |
Zezwalanie na dostęp z określonej sieci prywatnej w Google Cloud
Wiele firm kieruje ruch użytkowników do Google przez prywatne środowisko wirtualne w chmurze (VPC). VPC to bezpieczna, odizolowana sieć w środowisku Google Cloud.
Pamiętaj, że ruch kierowany przez VPC może korzystać z prywatnych adresów IP. Może to powodować problemy z zasadami dotyczącymi publicznego adresu IP lub regionu.
W tym przykładzie możesz zezwolić na ruch z tych konkretnych sieci VPC.
| Nazwa poziomu dostępu | vpc_access |
| Użytkownik uzyska dostęp, jeśli… | Spełniają atrybuty |
| Atrybuty warunku 1 |
Podsieć (prywatna) Podsieć prywatna: //compute.googleapis.com/projects/project- name-test/global/networks/network-name Podsieć VPC: 74.125.192.0/18 |
| Przypisanie poziomu dostępu |
Jednostki organizacyjne wszystkich użytkowników Wszystkie aplikacje, których używają wykonawcy |
Ważne kwestie, o których należy pamiętać:
- Tylko ruch bezpośredni: ten poziom dostępu działa tylko w przypadku ruchu, który dociera bezpośrednio do serwerów Google z dozwolonej sieci VPC. Jeśli ruch najpierw przechodzi przez inną sieć lub tunel, dostęp nie zostanie przyznany. Google rozpoznaje tylko ostatnią sieć VPC, która wysyła ruch do jego serwerów.
- Uprawnienia administracyjne: aby wyświetlać sieci VPC i konfigurować ten poziom dostępu, administratorzy muszą mieć odpowiednią rolę Identity and Access Management (IAM) (np. compute.networks.list, compute.subnetworks.list itp.).
- Zewnętrzne sieci VPC: sieć VPC, którą dodasz do listy dozwolonych, może znajdować się poza Twoją obecną domeną Google Cloud. Aby dodać zewnętrzną sieć VPC, administrator musi mieć uprawnienia do wyświetlania.
Zezwalanie na dostęp i blokowanie dostępu z określonych lokalizacji
Jeśli masz pracowników, którzy regularnie podróżują do zdalnych biur firmy lub partnerów, możesz określić położenia geograficzne, w których mogą oni uzyskiwać dostęp do zasobów firmowych.
Jeśli na przykład grupa sprzedawców regularnie odwiedza klientów w Australii i Indiach, możesz ograniczyć dostęp tej grupy do jej biura domowego oraz do Australii i Indii. Jeżeli w ramach podróży służbowej udadzą się na prywatny urlop do innego kraju, nie będą mieli stamtąd dostępu do zasobów firmowych.
W tym przykładzie grupa sprzedaży może uzyskać dostęp do zasobów firmowych tylko z USA (siedziba główna), Australii i Indii.
| Nazwa poziomu dostępu | dostęp_sprzedawców |
| Sprzedawcy uzyskają dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 | Pochodzenie geograficzne USA, Australia, Indie |
| Przypisanie poziomu dostępu | Grupa pracowników działu sprzedaży Wszystkie aplikacje, których używają pracownicy działu sprzedaży |
Możesz też stworzyć zasady odmowy dostępu z określonych krajów: w tym celu wystarczy umożliwić użytkownikom dostęp, jeśli nie spełniają warunków. Wymień kraje, z których chcesz zablokować dostęp.
Używanie zagnieżdżonych poziomów dostępu zamiast wybierania wielu poziomów dostępu podczas przypisywania
W niektórych przypadkach, gdy spróbujesz przypisać poziomy dostępu do danej jednostki organizacyjnej lub grupy i aplikacji (lub zestawu aplikacji), może pojawić się komunikat o błędzie z prośbą o zmniejszenie liczby aplikacji lub poziomów dostępu.
Aby uniknąć tego błędu, możesz zmniejszyć liczbę poziomów dostępu używanych podczas przypisywania, umieszczając je w jednym poziomie dostępu. Zagnieżdżony poziom dostępu łączy wiele warunków za pomocą operacji LUB, przy czym każdy warunek zawiera indywidualny poziom dostępu.
W tym przykładzie PLZachodnia, PLWschodnia i PLŚrodkowa są 3 oddzielnymi poziomami dostępu. Załóżmy, że chcesz, aby użytkownicy mieli dostęp do aplikacji, jeśli spełniają kryteria dotyczące poziomu dostępu PLZachodnia LUB PLWschodnia LUB PLŚrodkowa.Za pomocą operatora LUB możesz utworzyć pojedynczy zagnieżdżony poziom dostępu (o nazwie PLRegiony). Gdy nadejdzie czas przypisania poziomów dostępu, przypisz poziom dostępu USRegions do aplikacji dla jednostki organizacyjnej lub grupy.
|
Nazwa poziomu dostępu |
PLRegiony |
|
Użytkownik uzyska dostęp, jeśli: |
Spełniają atrybuty |
|
Atrybut warunku 1 (tylko jeden poziom dostępu na warunek) |
Poziom dostępu PLZachodnia |
|
Połączenie warunków 1 i 2 przy użyciu operatora |
LUB |
|
Użytkownik uzyska dostęp, jeśli: |
Spełniają atrybuty |
|
Atrybut warunku 2 |
Poziom dostępu PLWschodnia |
|
Połączenie warunków 2 i 3 przy użyciu operatora |
LUB |
|
Użytkownik uzyska dostęp, jeśli: |
Spełniają atrybuty |
|
Atrybut warunku 3 |
Poziom dostępu PLŚrodkowa |
Wymaganie urządzenia należącego do firmy w przypadku komputera, ale nie urządzenia mobilnego
Firma może wymagać komputera należącego do firmy, ale nie urządzenia mobilnego należącego do firmy.
W tym celu należy najpierw utworzyć poziom dostępu dla komputerów:
|
Nazwa poziomu dostępu |
dostęp_komputery |
|
Użytkownik uzyska dostęp, jeśli: |
Spełniają atrybuty |
|
Atrybut warunku 1 |
Zasady dotyczące urządzeń
Szyfrowanie urządzenia = Funkcja jest nieobsługiwana System operacyjny urządzenia macOS = 0.0.0 Windows = 0.0.0 Linux = 0.0.0 Chrome OS = 0.0.0 |
Następnie trzeba utworzyć poziom dostępu dla urządzeń mobilnych:
|
Nazwa poziomu dostępu |
dostęp_mobilne |
|
Użytkownik uzyska dostęp, jeśli: |
Spełniają atrybuty |
|
Atrybut warunku 1 |
System operacyjny urządzenia iOS = 0.0.0 Android = 0.0.0 |
Wymaganie podstawowych zabezpieczeń urządzenia
Większość firm wymaga obecnie od pracowników dostępu do zasobów firmowych z urządzeń, które są zaszyfrowane i mają minimalną wymaganą wersję systemu operacyjnego. Czasami wymaga się też, aby pracownicy korzystali z urządzeń należących do firmy.
Możesz skonfigurować te zasady dla wszystkich jednostek organizacyjnych lub tylko dla tych, w których osoby pracują z poufnymi danymi. Może to być na przykład kierownictwo firmy, dział finansów czy dział kadr.
Istnieje kilka sposobów skonfigurowania zasad, które pozwalałyby na dostęp do danych tylko z urządzeń szyfrowanych, z minimalną wymaganą wersją systemu operacyjnego i należących do firmy. Każda z tych opcji ma swoje wady i zalety.
1 poziom dostępu, który zawiera wszystkie wymagania dotyczące zabezpieczeń;
W tym przykładzie atrybuty szyfrowania urządzenia, minimalnej wersji systemu operacyjnego i urządzenia należącego do firmy są objęte jednym poziomem dostępu. Aby uzyskać dostęp, użytkownicy muszą spełniać wszystkie warunki.
Jeśli na przykład urządzenie użytkownika jest zaszyfrowane i należy do firmy, ale nie ma zgodnej wersji systemu operacyjnego, użytkownik nie uzyska dostępu.
Zaleta: łatwa konfiguracja. Po przypisaniu tego poziomu dostępu do aplikacji użytkownik musi spełnić wszystkie wymagania.
Wada: aby przypisać wymagania dotyczące zabezpieczeń do różnych jednostek organizacyjnych, musisz utworzyć osobny poziom dostępu dla każdego wymagania.
| Nazwa poziomu dostępu | zabezpieczenia_urządzenia |
| Użytkownik uzyska dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 (Możesz dodać wszystkie atrybuty do jednego warunku lub utworzyć 3 warunki i połączyć je operatorem I). |
Zasady dotyczące urządzeń System operacyjny urządzenia |
Trzy osobne poziomy dostępu
W tym przykładzie atrybuty szyfrowania urządzenia, minimalnej wersji systemu operacyjnego i urządzenia należącego do firmy są objęte 3 oddzielnymi poziomami dostępu. Aby uzyskać dostęp, użytkownicy muszą spełniać warunki tylko jednego z poziomów dostępu. Jest to suma logiczna „LUB” poziomów dostępu.
Na przykład użytkownik, który ma zaszyfrowane urządzenie i starszą wersję systemu operacyjnego na urządzeniu osobistym, uzyska dostęp.
Zaleta: szczegółowy sposób definiowania poziomów dostępu. Możesz oddzielnie przypisywać poziomy dostępu do różnych jednostek organizacyjnych.
Wada: użytkownicy muszą spełniać warunki tylko jednego z poziomów dostępu.
| Nazwa poziomu dostępu | szyfrowanie_urządzenia |
| Użytkownik uzyska dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 |
Zasady dotyczące urządzeń |
| Nazwa poziomu dostępu | urządzenie_firmowe |
| Użytkownik uzyska dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 |
Zasady dotyczące urządzeń |
| Nazwa poziomu dostępu | min_wersja_systemu |
| Użytkownik uzyska dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 |
Zasady dotyczące urządzeń |
Jeden poziom dostępu z zagnieżdżonymi poziomami dostępu
W tym przykładzie wymagania dotyczące zabezpieczeń urządzenia – szyfrowanie urządzenia, minimalna wersja systemu operacyjnego i urządzenie należące do firmy – są określone na 3 różnych poziomach dostępu. Te 3 poziomy dostępu są zagnieżdżone w 4. poziomie dostępu.
Gdy przypiszesz do aplikacji czwarty poziom dostępu, użytkownicy muszą spełniać warunki każdego z 3 zagnieżdżonych poziomów dostępu, aby uzyskać dostęp. Jest to iloczyn logiczny „I” poziomów dostępu.
Na przykład użytkownik, który ma zaszyfrowane urządzenie i korzysta ze starszej wersji systemu operacyjnego na urządzeniu osobistym, nie będzie miał dostępu.
Zaleta: zachowujesz elastyczność dzięki oddzieleniu wymagań dotyczących zabezpieczeń na poziomach dostępu 1, 2 i 3. Korzystając z poziomu dostępu 4, możesz też wymusić stosowanie zasad obejmujących wszystkie wymagania dotyczące zabezpieczeń.
Wada: w dzienniku kontrolnym jest rejestrowana tylko odmowa dostępu w przypadku poziomu 4 (bez informacji o poziomach 1, 2 i 3), ponieważ poziomy dostępu 1, 2 i 3 nie są bezpośrednio przypisane do aplikacji.
Utwórz 3 poziomy dostępu zgodnie z opisem w sekcji „Trzy osobne poziomy dostępu” powyżej: szyfrowanie_urządzenia, urządzenie_firmowe i min_wersja_systemu. Następnie utwórz 4 poziom dostępu o nazwie „zabezpieczenia_urządzenia”, który zawiera 3 warunki. Atrybutem każdego z tych warunków będzie poziom dostępu. (Do każdego warunku możesz dodać tylko jeden atrybut poziomu dostępu).
| Nazwa poziomu dostępu | zabezpieczenia_urządzenia |
| Użytkownik uzyska dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 (tylko jeden poziom dostępu na warunek) |
Poziom dostępu device_encryption |
| Połączenie warunków 1 i 2 przy użyciu operatora | ORAZ |
| Użytkownik uzyska dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 | Poziom dostępu corp_device |
| Połączenie warunków 2 i 3 przy użyciu operatora | ORAZ |
| Użytkownik uzyska dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 | Poziom dostępu min_os |
Powiązane informacje
- Omówienie dostępu zależnego od kontekstu
- Konfigurowanie oprogramowania i tworzenie poziomów dostępu zależnego od kontekstu
- Przypisywanie poziomów dostępu zależnego od kontekstu do aplikacji
- Dostosowywanie dostępu zależnego od kontekstu za pomocą grup
- Przykłady dostępu zależnego od kontekstu w trybie zaawansowanym
- Dziennik kontrolny dostępu zależnego od kontekstu