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. Kontrahenci mogą na przykład zajmować się obsługą zgłaszanych problemów w firmie albo pracować w centrach pomocy (również telefonicznych). 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 mają dostęp do zasobów firmowych tylko wtedy, gdy korzystają z adresów IP należących do określonego zakresu adresów firmowych.
| Nazwa poziomu dostępu | contractor_access |
| Kontrahenci uzyskają dostęp, jeśli: | Spełnia 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ć swoje zasoby przed nieuprawnionym przejęciem, wiele firm blokuje dostęp ze znanych adresów IP wysokiego ryzyka.
W tym przykładzie został zablokowany adres IP 74.125.195.105. Użytkownicy uzyskują dostęp do zasobów firmowych, jeśli ich sesje pochodzą z innych adresów IP. Możesz określić wiele adresów IP i ich zakresów.
| Nazwa poziomu dostępu | block_highrisk |
| Użytkownik uzyska dostęp, jeśli: | Nie spełnia 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łnia atrybuty |
| Atrybuty warunku 1 |
Podsieć IP (prywatna) Podsieć prywatna 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 dla wszystkich użytkowników Wszystkie aplikacje używane przez kontrahentów |
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 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 często podróżują do odległych biur firmy lub partnerów, możesz określić lokalizacje geograficzne, z których mają oni dostęp do zasobów firmy.
Jeśli na przykład grupa sprzedawców często odwiedza klientów w Australii i Indiach, możesz umożliwić im dostęp tylko z siedziby firmy, Australii oraz 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 sprzedawców ma dostęp do zasobów firmowych tylko z USA (w siedzibie firmy), Australii i Indii.
| Nazwa poziomu dostępu | sales_access |
| Sprzedawcy uzyskają dostęp, jeśli: | Spełnia atrybuty |
| Atrybut warunku 1 | Pochodzenie geograficzne USA, Australia, Indie |
| Przypisanie poziomu dostępu | Grupa sprzedawców Wszystkie aplikacje używane przez sprzedawców |
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. W tym przypadku należy wymienić 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 ich przypisywania
W niektórych przypadkach przy próbie przypisania poziomów 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ą operatora LUB, przy czym każdy z warunków zawiera jeden 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). Następnie przypisz jednostce organizacyjnej lub grupie dostęp do aplikacji na poziomie USRegiony.
|
Nazwa poziomu dostępu |
USRegions |
|
Użytkownik uzyska dostęp, jeśli: |
Spełnia atrybuty |
|
Atrybut warunku 1 (tylko jeden poziom dostępu na warunek) |
Poziom dostępu USWest |
|
Połączenie warunków 1 i 2 przy użyciu operatora |
LUB |
|
Użytkownik uzyska dostęp, jeśli: |
Spełnia atrybuty |
|
Atrybut warunku 2 |
Poziom dostępu USEast |
|
Połączenie warunków 2 i 3 przy użyciu operatora |
LUB |
|
Użytkownik uzyska dostęp, jeśli: |
Spełnia atrybuty |
|
Atrybut warunku 3 |
Poziom dostępu USCentral |
Wymaganie urządzenia należącego do firmy w przypadku komputera, ale nie urządzenia mobilnego
Firma może wymagać od pracowników korzystania z komputerów służbowych, ale pomijać te wymagania w przypadku urządzeń mobilnych.
W tym celu należy najpierw utworzyć poziom dostępu dla komputerów:
|
Nazwa poziomu dostępu |
aldesktop_access |
|
Użytkownik uzyska dostęp, jeśli: |
Spełnia 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 |
almobile_access |
|
Użytkownik uzyska dostęp, jeśli: |
Spełnia 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, aby pracownicy korzystali z zasobów firmowych na urządzeniach, które są zaszyfrowane i mają odpowiednie wersje systemów operacyjnych. 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żdy z nich ma swoje zalety i wady.
Jeden poziom dostępu obejmujący 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 jest własnością firmy, ale nie ma zgodnej wersji systemu operacyjnego, następuje odmowa dostępu.
Zaleta: łatwo przygotować taką konfigurację. Po przypisaniu tego poziomu dostępu do aplikacji użytkownik musi spełnić wszystkie wymagania.
Wada: aby oddzielnie przypisać wymagania dotyczące zabezpieczeń różnym jednostkom organizacyjnym, trzeba utworzyć oddzielny poziom dostępu dla każdego takiego wymagania.
| Nazwa poziomu dostępu | device_security |
| Użytkownik uzyska dostęp, jeśli: | Spełnia 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 |
3 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 sprawdzana suma logiczna (LUB) poziomów dostępu.
Jeśli na przykład użytkownik ma zaszyfrowane urządzenie i korzysta ze starszej wersji systemu operacyjnego na urządzeniu osobistym, otrzymuje dostęp.
Zaleta: pozwala precyzyjnie zdefiniować poziomy 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 | device_encryption |
| Użytkownik uzyska dostęp, jeśli: | Spełnia atrybuty |
| Atrybut warunku 1 |
Zasady dotyczące urządzeń |
| Nazwa poziomu dostępu | corp_device |
| Użytkownik uzyska dostęp, jeśli: | Spełnia atrybuty |
| Atrybut warunku 1 |
Zasady dotyczące urządzeń |
| Nazwa poziomu dostępu | min_os |
| Użytkownik uzyska dostęp, jeśli: | Spełnia atrybuty |
| Atrybut warunku 1 |
Zasady dotyczące urządzeń |
1 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.
Jeśli przypiszesz 4. poziom dostępu do aplikacji, użytkownicy będą musieli spełnić warunki wszystkich 3 zagnieżdżonych poziomów, aby uzyskać dostęp. Jest sprawdzany iloczyn logiczny (I) poziomów dostępu.
Jeśli na przykład użytkownik ma zaszyfrowane urządzenie i korzysta ze starszej wersji systemu operacyjnego na urządzeniu osobistym, nastąpi odmowa 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 | device_security |
| Użytkownik uzyska dostęp, jeśli: | Spełnia atrybuty |
| Atrybut warunku 1 (tylko jeden poziom dostępu na warunek) |
Poziom dostępu szyfrowanie_urządzenia |
| Połączenie warunków 1 i 2 przy użyciu operatora | ORAZ |
| Użytkownik uzyska dostęp, jeśli: | Spełnia atrybuty |
| Atrybut warunku 1 | Poziom dostępu urządzenie_firmowe |
| Połączenie warunków 2 i 3 przy użyciu operatora | ORAZ |
| Użytkownik uzyska dostęp, jeśli: | Spełnia atrybuty |
| Atrybut warunku 1 | Poziom dostępu min_wersja_systemu |
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