Przykłady dostępu zależnego od kontekstu w trybie zaawansowanym

Aby zwiększyć bezpieczeństwo dostępu do aplikacji zawierających dane wrażliwe, możesz uzależnić go od sposobu uwierzytelniania użytkownika w systemie.

Na przykład użytkownicy zalogowani tylko za pomocą hasła mogą uzyskać dostęp jedynie do aplikacji niezawierających żadnych informacji poufnych. Natomiast użytkownik zalogowany przy użyciu fizycznego klucza bezpieczeństwa jako drugiego składnika może mieć dostęp do najbardziej poufnych aplikacji dla firm.

Na tym poziomie dostępu do sprawdzania, czy użytkownicy logują się przy użyciu hasła i klucza fizycznego do weryfikacji dwuetapowej oraz czy mają dostęp do poufnych aplikacji, służą atrybuty request.auth.

request.auth.claims.crd_str.pwd == true && request.auth.claims.crd_str.hwk == true

Często administratorzy chcą wymuszać dostęp do zasobów firmowych dopiero po uwierzytelnieniu użytkownika przy użyciu silnych danych logowania. W tym przykładzie użyto atrybutów levels i request.auth:

• Jeśli użytkownik korzysta z urządzenia firmowego, można użyć dowolnego uwierzytelniania wieloskładnikowego z wyjątkiem SMS-ów (metodami mogą być powiadomienia push, fizyczny lub programowy klucz bezpieczeństwa albo hasło jednorazowe).
• Jeśli użytkownik korzysta z urządzenia nienależącego do firmy, należy użyć fizycznego lub programowego klucza bezpieczeństwa.

// Wymagaj podstawowego uwierzytelniania dwuskładnikowego (bez SMS-ów) na urządzeniach firmowych i klucza zabezpieczeń (sprzętowego lub programowego), jeśli nie jest to możliwe
levels.Require_Secure_Device &&
(
(
levels.Require_Corporate_Device &&
request.auth.claims.crd_str.mfa &&
!request.auth.claims.crd_str.sms
) ||
(
!levels.Require_Corporate_Device &&
(
request.auth.claims.crd_str.hwk || request.auth.claims.crd_str.swk
)
)
)

Ograniczone do aplikacji internetowych na komputer i nieobowiązujące w przypadku aplikacji mobilnych lub interfejsów API

Aby zwiększyć bezpieczeństwo dostępu do aplikacji zawierających dane wrażliwe, możesz wymagać danych uwierzytelniających sesji powiązanych z urządzeniem (DBSC). DBSC wiąże sesję użytkownika z jego urządzeniem, gdy korzysta on z przeglądarki Chrome w systemie Windows, co może znacznie zmniejszyć ryzyko przechwycenia sesji.

Na tym poziomie dostępu do sprawdzania, czy sesje użytkownika są powiązane z konkretnym urządzeniem, służy atrybut request.auth. Jeśli tak jest, aplikacja otrzymuje dostęp. Jeśli nie (czyli sesja nie jest związana z DBSC), następuje odmowa dostępu.

Aby uniknąć błędów, włącz DBSC na wszystkich kontach użytkowników, których dotyczy ten poziom dostępu. Więcej informacji znajdziesz w artykule na temat włączania DBSC.

Przed włączeniem trybu aktywnego ustaw poziom dostępu na Tryb monitorowania. W trybie monitorowania możesz sprawdzić wpływ wymuszania poziomu dostępu bez zakłócania dostępu użytkowników.

Aby utworzyć niestandardowy poziom dostępu, użyj tego wyrażenia CEL:

request.auth.sessionBoundToDevice(origin) == true

Użyj tego wyrażenia CEL, aby wymusić DBSC tylko na urządzeniach z systemem Windows i przeglądarką Chrome w wersji 136 lub nowszej:

!(device.os_type == OsType.DESKTOP_WINDOWS && device.chrome.versionAtLeast("136.0.0")) || request.auth.sessionBoundToDevice(origin) == true

Możesz korzystać z sygnałów urządzenia zgłaszanych przez partnera – BeyondCorp Alliance. W tym przykładzie jako aplikacji użyjemy oprogramowania Lookout.

Na tym poziomie dostępu do sprawdzania, czy urządzenie używane do uzyskania dostępu do Google Workspace jest zgłaszane przez Lookout jako zgodne z zasadami, a wskaźnik stanu jest bardzo dobry, służy atrybut device.

Na tym poziomie dostępu do sprawdzania, czy użytkownicy korzystają z najnowszej wersji zarządzanej przeglądarki Chrome, służy atrybut device, który pozwala na dostęp tylko w takiej przeglądarce.

Używając certyfikatów przedsiębiorstwa na urządzeniach z niestandardowymi poziomami dostępu, możesz określić, czy urządzenie jest własnością firmy. Na tym poziomie dostępu do weryfikacji zasobów używany jest atrybut device. Więcej informacji i przykłady znajdziesz w artykule Konfigurowanie warunków certyfikatu przedsiębiorstwa.

Urządzenie może mieć więcej niż 1 certyfikat. Certyfikaty przedsiębiorstwa są stosowane na niestandardowym poziomie dostępu za pomocą makra exists(). Na przykład:

device.certificates.exists(cert, predicate)

W tym przykładzie certyfikat jest prostym identyfikatorem używanym w zmiennej predykat do powiązania z certyfikatem przedsiębiorstwa urządzenia. Makro exists() łączy wyniki z wybranymi elementami za pomocą operatora lub (||). Makra zwracają wartość prawda, jeśli co najmniej 1 certyfikat spełnia wyrażenie predykatu.

Tabela poniżej zawiera atrybuty, których możesz użyć do tworzenia wyrażeń CEL do wykorzystania z niestandardowymi poziomami dostępu. Pamiętaj, że w porównaniach ciągów znaków wielkość liter ma znaczenie.

Przykładowe często używane zasady:

Sprawdzenie, czy urządzenie ma ważny certyfikat przedsiębiorstwa podpisany certyfikatem głównym firmy

device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT")

Weryfikacja wystawcy certyfikatu przedsiębiorstwa na urządzeniu

device.certificates.exists(cert, cert.is_valid && cert.issuer == "EMAILADDRESS=test_inter1@beyondcorp.in, CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN")

W tym przykładzie użyto atrybutu device, aby wymagać włączenia szyfrowania dysku i blokady ekranu. Dodatkowo urządzenie musi zostać zatwierdzone przez administratorów.

Domyślnie wszystkie urządzenia utworzone przez weryfikację punktów końcowych są zatwierdzone. Jednak niekiedy możesz chcieć zablokować urządzenie, na przykład gdy zostanie zgubione. W takich sytuacjach nie należy zezwalać urządzeniom na dostęp do zasobów firmy.

W innych przykładach poziomów dostępu w tym dokumencie przyjmiemy, że ten poziom nosi nazwę Require_Secure_Device.

// Wymagaj włączenia szyfrowania dysku i blokady ekranu
// Dotyczy wszystkich głównych platform (Windows, Mac, Linux, CrOS, iOS, Android)
// Jest to podstawowe wymaganie, od którego powinny zależeć wszystkie inne poziomy dostępu
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device

W tym przykładzie poziom dostępu korzysta z atrybutu device i wymaga, żeby przeglądarka Chrome spełniała podstawowe wymagania dotyczące zabezpieczeń.

// Wymagaj zarządzania Chrome na poziomie profilu lub przeglądarki, musi mieć
// włączone raportowanie zdarzeń związanych z bezpieczeństwem i musi być w wersji 97 lub nowszej
levels.Require_Secure_Device &&
(
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED ||
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_PROFILE_MANAGED
) &&
device.chrome.is_security_event_analysis_enabled &&
device.chrome.versionAtLeast("97")

W tym przykładzie użyto atrybutu device, aby określić, że użytkownik ma korzystać z zarządzanej przeglądarki lub zarządzanego profilu Chrome, a w Chrome mają być włączone wtyczki związane z ochroną przed zagrożeniami i zabezpieczeniem danych. W przykładzie użyto atrybutu levels w odniesieniu do opisanego wcześniej poziomu dostępu Wymagaj zarządzanej przeglądarki Chrome. W tym przykładzie założono, że zależny poziom dostępu ma nazwę Require_Managed_Chrome.

// Wymagaj zarządzanego Chrome (zależne od poziomu dostępu „Require_Managed_Chrome”)
// i wymagaj sprawdzania treści pobieranych plików oraz włączonego sprawdzania adresów URL
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled

Zezwolić na dostęp możesz tylko wtedy, gdy urządzenie należy do firmy lub jest przez nią zarządzane. Jest tak, jeśli m.in.:

• urządzenie ma numer seryjny odpowiadający numerowi w systemie zarządzania zasobami firmy,
• urządzenie ma ważny certyfikat przedsiębiorstwa wydany przez firmę.

Te 2 podejścia mogą być używane w następującym niestandardowym poziomie dostępu, który wykorzystuje atrybuty levels i device, aby określić, czy urządzenie należy do firmy lub jest przez nią zarządzane.

// Urządzenie należy do firmy, jeśli spełnia jeden z tych warunków:
// 1. Numer seryjny jest zgodny z numerem przesłanym przez administratora
// 2. Jeśli urządzenie ma ważny certyfikat wydany przez firmę
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)

Odcisk cyfrowy to base64 bez dopełnienia zakodowany w formacie SHA256 (w formacie binarnym) certyfikatu z kodowaniem DER. Ciąg można wygenerować z certyfikatu w formacie PEM, korzystając z tej procedury za pomocą openssl:

$ openssl x509 -in cert.pem -out cert.der -outform DER
$ openssl dgst -sha256 -binary cert.der > digest.sha
$ openssl base64 -in digest.sha

• sygnatura czasowa wystawienia (iat),
• sygnatura czasowa wygaśnięcia (exp).

Aby dane CrowdStrike na pewno były aktualne, poziom dostępu wykorzystuje atrybut device. Pamiętaj, że Chrome Enterprise Premium ma 90 minut opóźnienia w przypadku każdej nowej oceny Falcon ZTA, więc nie zalecamy ustawiania czasu trwania mniejszego niż godzina.

// Upewnij się, że w przypadku danych z Crowdstrike spełniony jest jeden z tych warunków:
// Musisz spełnić jeden z tych warunków
// 1. Urządzenie zostało ocenione w ciągu ostatniego dnia
// 2. Ocena nie wygasła (2 tygodnie od ostatniego czasu iat)
„CrowdStrike” w device.vendors && (
request.time – timestamp(device.vendors["CrowdStrike"].data["iat"]) < duration("1d") ||
timestamp(device.vendors["CrowdStrike"].data["exp"]) – request.time > duration("0m")
)

Chrome Enterprise Premium współpracuje z wieloma partnerami ekosystemu BeyondCorp Alliance, aby integrować sygnały z urządzeń i ich kontekst z konkretnym rozwiązaniem Chrome Enterprise Premium. Partnerzy mogą udostępniać dowolną liczbę atrybutów usłudze Chrome Enterprise Premium, a jeden z nich to is_compliant_device. W przykładzie poniżej użyto atrybutu device, aby pokazać, jak sprawdzić, czy którykolwiek z partnerów BeyondCorp Alliance został zintegrowany z Chrome Enterprise Premium, a urządzenie można uznać za zgodne.

Makro exists rozszerza wyrażenie na każdego partnera BeyondCorp Alliance za pomocą operatora || (lub).

// Sprawdź, czy któryś z partnerów BCA uznaje urządzenie za zgodne z zasadami
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)

W tym przykładzie użyto atrybutów device, aby zapewnić, że urządzenia działają w bezpiecznej wersji Androida.

Weryfikacja podczas uruchamiania sprawdza, czy uruchomiony kod pochodzi z zaufanego źródła (zwykle od producentów OEM urządzeń) i nie jest wynikiem ataku lub uszkodzenia. Więcej informacji znajdziesz w artykule na temat weryfikacji podczas uruchamiania.

// Wymagaj, żeby stan weryfikacji podczas uruchamiania w Androidzie był oznaczony kolorem zielonym
device.android_device_security.verified_boot == true

W tym przykładzie użyto atrybutów device, aby wymagać od urządzeń przejścia kontroli zgodności Compatibility Test Suite (CTS). Więcej informacji znajdziesz w artykule Compatibility Test Suite.

// Wymagaj, aby urządzenia przeszły kontrolę zgodności CTS
device.android_device_security.cts_profile_match == true

W tym przykładzie użyto atrybutów device, aby wymagać włączenia funkcji Weryfikacji aplikacji Google Play Protect na urządzeniach.

Gdy aplikacje są instalowane ze źródeł innych niż Google Play, funkcja ta skanuje aplikacje w poszukiwaniu zagrożeń. Co jakiś czas wykonywane jest też skanowanie urządzenia w poszukiwaniu potencjalnie szkodliwych aplikacji. Weryfikacja aplikacji jest domyślnie włączona. W przypadku urządzeń objętych zaawansowanymi funkcjami zarządzania możesz określić, czy użytkownicy mogą ją wyłączyć. Więcej informacji znajdziesz w artykule Stosowanie ustawień na urządzeniach mobilnych z Androidem.

// Wymagaj, aby na urządzeniach była włączona funkcja Weryfikacji aplikacji Google Play Protect
device.android_device_security.verify_apps_enabled == true

W tym przykładzie użyto atrybutów device, aby zablokować dostęp do urządzeń, na których są zainstalowane potencjalnie szkodliwe aplikacje. Takie aplikacje są często nazywane złośliwym oprogramowaniem. Szczegółowe informacje znajdziesz w artykule Potencjalnie szkodliwe aplikacje.

// Zablokuj dostęp do urządzeń, na których są zainstalowane potencjalnie szkodliwe aplikacje android_device_security.has_potentially_harmful_apps != true

Firmy chcą mieć pewność, że pracownicy zmianowi będą mieli dostęp do zasobów firmowych tylko w godzinach pracy. Poniższe poziomy dostępu wykorzystują atrybut levels do określania 3 zmian w dniach od poniedziałku do piątku.

// Shift 1 - Monday to Friday, midnight to 8am
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('00:00:00', '08:00:00')

// Zmiana 2 – od poniedziałku do piątku, od 8:00 do 16:00
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('08:00:00', '16:00:00')

// Shift 3 - Monday to Friday, 4pm to midnight
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
request.time.timeOfDay("America/Los_Angeles").between('16:00:00', '00:00:00')

// Zezwalaj pracownikom zmianowym na dostęp do zasobów od poniedziałku do piątku w godzinach 9:00–17:00 (z wyjątkiem 4 lipca).
levels.Require_Secure_Device &&
request.time.getDayOfWeek("America/Los_Angeles") >= 1 &&
request.time.getDayOfWeek("America/Los_Angeles") <= 5 &&
!(
request.time.getMonth("America/Los_Angeles") == 6 &&
request.time.getDayOfMonth("America/Los_Angeles") == 3
) &&
request.time.timeOfDay("America/Los_Angeles").between('09:30:00', '17:00:00')

Czasami firmy chcą zezwolić na dostęp w ramach wyjątku w sytuacjach awaryjnych, gdy administrator nie ma dostępu do bezpiecznego urządzenia, ale potrzebuje krótkotrwałego dostępu.

W takim przypadku utwórz poziom dostępu z ograniczeniem czasu i lokalizacji za pomocą atrybutu levels i przypisz go do wybranego administratora. Gdy ten poziom dostępu jest przypisany, pozostaje ważny tylko przez określony czas. Po upływie tego czasu dostęp administratora będzie ponownie kontrolowany przez obowiązujące wymagania.

// Zezwól na tymczasowy dostęp do zasobów 1 marca 2022 roku między 22:00 a północą.
// Dostęp musi być uzyskiwany z regionu USA.
levels.Require_Secure_Device &&
request.time.between('2022-03-01T23:00:00+08:00', '2022-03-02T23:59:59+08:00') &&
origin.region_code == "US"
// Uwaga: czas zakończenia jest wyłączny, więc powyższy warunek może obejmować 2 sekundy, do których
// użytkownicy mogą nie mieć dostępu. Innym sposobem jest użycie tego atrybutu:
// !between('00:00:01','16:00:00')

Ten poziom dostępu korzysta z atrybutów levels i wymaga, aby użytkownicy spełniali warunki dwóch poziomów dostępu. W tym przykładzie access_level_name_1 i access_level_name_2 odnoszą się do nazwy wewnętrznej.

levels.access_level_name_1 && levels.access_level_name_2