Примеры контекстно-зависимого доступа для расширенного режима

Для повышения безопасности доступа к приложениям, содержащим конфиденциальные данные, можно определить, каким образом пользователь прошел аутентификацию в системе, чтобы решить, получит ли он доступ к приложению.

Например, пользователям, вошедшим в систему только с помощью пароля, будет разрешен доступ только к приложениям, не содержащим конфиденциальной информации, тогда как пользователю, вошедшему в систему с помощью аппаратного ключа безопасности в качестве второго фактора, будет разрешен доступ к наиболее конфиденциальным корпоративным приложениям.

Этот уровень доступа использует атрибуты request.auth для проверки того, что пользователи входят в систему, используя как пароль, так и аппаратный ключ для двухфакторной аутентификации, и могут получить доступ к конфиденциальным приложениям.

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

Часто администраторы хотят ограничить доступ к корпоративным ресурсам только после аутентификации пользователя с использованием надежных учетных данных. В следующем примере используются атрибуты levels и request.auth следующим образом:

• Если пользователь использует корпоративное устройство, подойдет любой метод многофакторной аутентификации, кроме SMS (это могут быть push-уведомления, аппаратный или программный ключ безопасности или одноразовый пароль).
• Если пользователь использует устройство, не принадлежащее компании, необходимо использовать аппаратный или программный ключ безопасности.

// Требовать базовую многофакторную аутентификацию (не SMS) на корпоративных устройствах и ключ безопасности (аппаратный или программный), если это не требуется.
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
)
)
)

Применимо только к веб-приложениям для настольных компьютеров и не подходит для мобильных приложений или API.

Вы можете повысить безопасность доступа к приложениям, содержащим конфиденциальные данные, используя учетные данные сеанса, привязанные к устройству (DBSC). DBSC привязывает сеанс пользователя к его устройству при использовании браузера Chrome в Windows, что может значительно снизить риск перехвата сеанса.

Этот уровень доступа использует атрибут request.auth для проверки того, привязаны ли сессии пользователя к конкретному устройству. Если да, то доступ к приложению предоставляется. В противном случае (то есть сессия не привязана к DBSC), доступ запрещен.

Во избежание ошибок включите DBSC для всех учетных записей пользователей, на которые распространяется этот уровень доступа. Подробности см. в разделе «Включение DBSC» .

Перед включением активного режима установите уровень доступа в режим «Монитор» . В режиме «Монитор» вы можете проверить влияние принудительного применения уровней доступа, не нарушая доступ пользователей.

Используйте это выражение CEL для создания собственного уровня доступа:

request.auth.sessionBoundToDevice(origin) == true

Используйте это выражение CEL, чтобы принудительно включить DBSC только на устройствах Windows с браузером Chrome версии 136 или более поздней:

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

Вы можете использовать сигналы устройств, передаваемые партнером BeyondCorp Alliance. В этом примере в качестве приложения используется Lookout Software.

Этот уровень доступа использует атрибут устройства для проверки того, что устройство, используемое для доступа к Google Workspace, по данным Lookout соответствует политикам, и оценка состояния устройства составляет «Очень хорошо».

Этот уровень доступа использует атрибут устройства для проверки того, что пользователи используют последнюю версию управляемого браузера Chrome, и разрешает доступ только через такой браузер.

Для определения того, является ли устройство корпоративным активом, можно использовать корпоративные сертификаты для устройств с настраиваемыми уровнями доступа. Этот уровень доступа использует атрибут устройства для проверки актива. Дополнительную информацию и примеры см. в разделе « Настройка условий корпоративного сертификата» .

Устройство может иметь более одного сертификата. Корпоративные сертификаты используются на пользовательском уровне доступа с помощью макроса exists() . Например:

device.certificates.exists(cert, predicate)

В этом примере cert — это простой идентификатор, используемый в предикате переменной для привязки к корпоративному сертификату устройства. Макрос exists() объединяет результаты предикатов для каждого элемента с помощью оператора ИЛИ (||). Макросы возвращают true, если хотя бы один сертификат удовлетворяет выражению предиката.

В таблице ниже перечислены атрибуты, которые можно использовать для формирования выражений CEL, применяемых с пользовательскими уровнями доступа. Обратите внимание, что сравнение строк чувствительно к регистру.

Примеры часто используемых политик:

Убедитесь, что устройство имеет действительный корпоративный сертификат, подписанный корневым сертификатом компании.

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

Проверьте эмитента корпоративного сертификата на устройстве.

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")

В этом примере атрибут устройства используется для обязательного включения как шифрования диска, так и блокировки экрана. Кроме того, устройство должно быть одобрено администраторами.

По умолчанию все устройства, созданные с помощью проверки конечных точек, утверждаются. Однако бывают случаи, когда может потребоваться заблокировать устройство, например, в случае его утери. В таких случаях вы не захотите, чтобы эти устройства имели доступ к корпоративным ресурсам.

В других примерах уровней доступа, приведенных в этом документе, предполагается, что данный уровень доступа имеет название Require_Secure_Device .

// Требуется включение шифрования диска и блокировки экрана
// Это применимо ко всем основным платформам (Windows, Mac, Linux, CROS, iOS, Android)
// Это основополагающий принцип, на который должны полагаться все остальные уровни доступа.
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device

В этом примере уровень доступа использует атрибут устройства , чтобы потребовать использования браузера Chrome с базовыми требованиями к безопасности.

// Требуется управление Chrome на уровне профиля или браузера.
// Включена функция отправки отчетов о событиях безопасности, версия должна быть 97 или выше.
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")

В этом примере атрибут device используется для требования, чтобы пользователь использовал управляемый браузер или профиль Chrome, а также чтобы в Chrome были включены коннекторы защиты от угроз и данных. В примере атрибут levels используется для ссылки на описанный ранее уровень доступа Require Managed Chrome. В следующем примере предполагается, что зависимый уровень доступа называется Require_Managed_Chrome .

// Требуется управляемый Chrome (зависит от уровня доступа "Require_Managed_Chrome")
// и требуют включения проверки содержимого при загрузке, а также проверки URL-адресов.
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled

Одним из требований для контроля доступа является разрешение доступа только в том случае, если устройство находится в управлении или принадлежит компании. Существует множество способов определить, находится ли устройство в корпоративной собственности или под управлением компании, в том числе:

• Если серийный номер устройства совпадает с номером, зарегистрированным в системе управления активами компании.
• Если устройство имеет действующий корпоративный сертификат, выданный компанией.

Эти два подхода можно использовать в следующем пользовательском уровне доступа, который использует уровни и атрибуты устройства для определения того, принадлежит ли устройство корпорации или находится под ее управлением.

// Устройство является корпоративным, если выполняется одно из следующих условий:
// 1. Если серийный номер совпадает с тем, который загрузил администратор.
// 2. Если устройство имеет действительный сертификат, выданный предприятием
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)

Отпечаток представляет собой незаполненный дайджест SHA256 в кодировке Base64 (в двоичном формате) сертификата в кодировке DER. Строку можно сгенерировать из сертификата в формате PEM, используя следующую процедуру с помощью openssl:

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

• Выпущено в момент времени (iat)
• Отметка времени истечения срока действия (exp)

Уровень доступа использует атрибут устройства для обеспечения актуальности данных CrowdStrike. Обратите внимание, что Chrome Enterprise Premium имеет встроенную задержку в 90 минут для получения любых новых оценок от Falcon ZTA, поэтому использование продолжительности менее часа не рекомендуется.

// Убедитесь, что для данных из Crowdstrike выполняется одно из следующих условий:
// Должно выполняться одно из следующих условий
// 1. Оценка устройства проводилась в течение последних суток.
// 2. Срок действия оценки не истек (прошло 2 недели с момента последней промежуточной оценки)
"CrowdStrike" в 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 сотрудничает со многими партнерами по экосистеме BeyondCorp Alliance для интеграции сигналов и контекста их устройств в решение Chrome Enterprise Premium. Партнеры могут делиться с Chrome Enterprise Premium любым количеством атрибутов, и одним из них является атрибут is_compliant_device . В следующем примере используется атрибут device , чтобы показать, как можно проверить, интегрировалось ли какое-либо из партнеров BeyondCorp Alliance с Chrome Enterprise Premium и считает ли оно устройство соответствующим требованиям.

Макрос exists расширяет выражение для каждого из партнеров альянса BeyondCorp с помощью оператора || (или).

// Проверьте, считает ли кто-либо из партнеров BCA данное устройство соответствующим требованиям.
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)

В этом примере используются атрибуты устройства , чтобы убедиться, что на устройствах установлена ​​безопасная версия Android.

Проверка Verified Boot подтверждает, что выполняемый код поступает из надежного источника (обычно от производителей устройств), а не от злоумышленника или в результате повреждения данных. Подробнее см. на странице Verified Boot .

// Требуется подтверждение загрузки Android в зелёном цвете
device.android_device_security.verified_boot == true

В этом примере используются атрибуты устройств , чтобы потребовать от устройств прохождения проверок на соответствие требованиям пакета тестов совместимости (Compatibility Test Suite, CTS). Подробности см. в разделе «Пакет тестов совместимости» .

// Требовать от устройств прохождения проверок на соответствие стандартам CTS
device.android_device_security.cts_profile_match == true

В этом примере используются атрибуты устройства , чтобы потребовать включения функции проверки приложений Google Play Protect .

Функция «Проверка приложений» сканирует приложения на наличие угроз, если они установлены не из Google Play. Она также периодически сканирует устройства на наличие потенциально вредоносных приложений. Функция «Проверка приложений» включена по умолчанию. Для устройств, находящихся в расширенном управлении, можно указать, могут ли пользователи её отключать. Дополнительную информацию см. в разделе «Применение настроек для мобильных устройств Android» .

// Для корректной работы устройства необходимо включить функцию проверки приложений Google Play Protect.
device.android_device_security.verify_apps_enabled == true

В этом примере используются атрибуты устройства для блокировки доступа к устройствам, на которых установлены потенциально вредоносные приложения. Такие приложения часто называют вредоносным ПО. Подробнее см. раздел «Потенциально вредоносные приложения (PHA)» .

// Запретить доступ к устройствам, содержащим потенциально опасные приложения. android_device_security.has_potentially_harmful_apps != true

Предприятия хотят гарантировать, что их сотрудники, работающие посменно, будут иметь доступ к корпоративным ресурсам только в часы своей смены. Следующие уровни доступа используют атрибут levels для определения 3 смен в период с понедельника по пятницу.

// Смена 1 - с понедельника по пятницу, с полуночи до 8 утра
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')

// Смена 2 - с понедельника по пятницу, с 8:00 до 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')

// Смена 3 - с понедельника по пятницу, с 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('16:00:00', '00:00:00')

// Разрешить работникам, работающим посменно, доступ к ресурсам с понедельника по пятницу с 9:00 до 17:00, за исключением Дня независимости 4 июля.
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')

Иногда предприятиям необходимо разрешить экстренный доступ в случае чрезвычайных ситуаций, когда у администратора нет доступа к защищенному устройству, но ему требуется кратковременный экстренный доступ.

В этом случае создайте уровень доступа с ограничениями по времени и местоположению, используя атрибут levels , и назначьте его конкретному администратору. После назначения этот уровень доступа будет действителен только в течение указанного времени. По истечении этого периода времени доступ администратора снова будет регулироваться существующими требованиями.

// Разрешить временный доступ к ресурсам 1 марта 2022 года с 22:00 до полуночи.
// И доступ должен осуществляться из региона США.
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"
// Обратите внимание, что время окончания исключает предыдущие, поэтому в приведенном выше примере потенциально может быть 2 секунды, которые...
// Пользователи могут не иметь доступа. Другой вариант — использовать это.
// !between('00:00:01','16:00:00')

Этот уровень доступа использует атрибуты уровней и требует, чтобы пользователи соответствовали комбинированным условиям двух уровней доступа. В этом примере access_level_name_1 и access_level_name_2 относятся к внутреннему имени .

levels.access_level_name_1 && levels.access_level_name_2