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. Dotyczy to na przykład firm, które korzystają z usług wykonawców do odbierania ogólnych połączeń pomocy lub pracy 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 adresów IP firmy.
| Nazwa poziomu dostępu | dostęp_kontrahenta |
| Kontrahenci uzyskają dostęp, jeśli: | Spełniają atrybuty |
| Atrybut warunku 1 | Podsieć (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 zablokowany jest adres IP 74.125.195.105. 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 IP i zakresów.
| 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ć (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) Prywatna podsieć IP: //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, z których korzystają wykonawcy |
Ważne kwestie, o których należy pamiętać:
- Tylko wizyty bezpośrednie: 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 przechodzi najpierw przez inną sieć lub tunel, dostęp nie jest przyznawany. 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 odległych biur firmowych lub biur partnerów, możesz określić lokalizacje 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 biura domowego oraz 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 ds. sprzedaży może uzyskiwać dostęp do zasobów firmowych tylko ze Stanów Zjednoczonych (biuro domowe), 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 Australia, Indie, Stany Zjednoczone |
| Przypisanie poziomu dostępu | Grupa pracowników działu sprzedaży Wszystkie aplikacje używane przez pracowników 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. Wymienisz kraje, z których chcesz zablokować dostęp.
Używaj zagnieżdżonych poziomów dostępu zamiast wybierania wielu poziomów dostępu podczas przypisywania
W niektórych przypadkach, gdy pró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, a każdy warunek zawiera pojedynczy 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 w przypadku 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, które pracują z danymi wrażliwymi, takich jak 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 nich ma swoje zalety i wady.
1 poziom dostępu, który zawiera wszystkie wymagania związane z zabezpieczeniami.
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 będzie mieć do niego dostępu.
Zaleta: łatwa konfiguracja. Po przypisaniu tego poziomu dostępu do aplikacji użytkownik musi spełnić wszystkie wymagania.
Wada: aby osobno 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 osobiste z starszą wersją systemu operacyjnego, uzyskuje 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ądzenia |
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łnić warunki każdego z 3 zagnieżdżonych poziomów dostępu, aby uzyskać dostęp. Jest to logiczna suma „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 mieć 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