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

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

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

Для реализации такого уровня доступа применяются атрибуты 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…

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

Специальный уровень доступа создается с помощью такого выражения 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.

При использовании этого уровня с помощью атрибута device проверяется, соответствует ли устройство, по данным Lookout, заданным правилам и имеет ли оценку состояния Very Good (Очень хорошо).

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

Для специальных уровней доступа можно использовать корпоративный сертификат устройства, чтобы определить, принадлежит ли оно компании. Для этого уровня доступа используется атрибут device, чтобы проверить принадлежность компании. Подробнее о настройке условий, связанных с корпоративными сертификатами…

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

device.certificates.exists(cert, predicate)

В этом примере cert – это простой идентификатор, используемый в переменной predicate для привязки корпоративного сертификата устройства. Макрос exists() совмещает поэлементные результаты предиката с оператором or (||). Макрос возвращает значение 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")

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

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

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

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

В этом примере для уровня доступа используется атрибут 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 с включенными коннекторами Threat and Data Protection. В этом примере используется атрибут levels, чтобы ссылаться на ранее описанный уровень доступа, в котором требуется управляемый браузер 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

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

• Проверить, есть ли у устройства серийный номер, который соответствует номеру в системе управления активами компании.
• Проверить, есть ли у устройства действительный корпоративный сертификат, выданный компанией.

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

// The device is a corporate if one of the following conditions is true:
// 1. If the serial number matches what the admin has uploaded
// 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")
)

Цифровой отпечаток – это закодированный по алгоритму base64 без заполнителей дайджест SHA256 (в двоичном формате) сертификата, закодированного по правилам 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).

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

// Ensure one of these conditions is true for data from Crowdstrike:
// Must meet one of these conditions
// 1. Device was assessed within the last day
// 2. Срок действия оценки не истек (с момента последнего значения iat прошло меньше двух недель).
"CrowdStrike" in 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 attribute. В примере ниже используется атрибут device, чтобы показать, как можно проверить, интегрирован ли какой-либо из партнеров BeyondCorp Alliance в решение Chrome Enterprise Premium, и в таком случае считать устройство соответствующим требованиям.

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

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

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

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

// Требовать, чтобы статус проверки при запуске Android был зеленым
device.android_device_security.verified_boot == true

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

// Require devices to pass CTS compliance checks
device.android_device_security.cts_profile_match == true

В этом примере используется атрибут device, чтобы требовать использования на устройствах Проверки приложений в Google Play Защите.

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

// Require devices to have Google Play Protect Verify Apps enabled
device.android_device_security.verify_apps_enabled == true

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

// Deny access to devices that have potentially harmful appsandroid_device_security.has_potentially_harmful_apps != true

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

// Смена 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 до 00: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')

// Allow shift workers to access resources from Monday to Friday between 9 AM to 5 PM, except for July fourth.
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, и назначьте его определенному администратору. После назначения уровень будет действителен только в течение указанного времени, а затем доступ администратора снова будет ограничен в соответствии с существующими требованиями.

// Allow temporary access to resources on March 1, 2022, between 10 PM to midnight,
// and this access must come from within the US region.
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"
// Обратите внимание, что конечное время не включено, поэтому в приведенном выше примере
// у пользователей может не быть доступа в течение двух секунд. Другой вариант – использовать следующий код:
// !between('00:00:01','16:00:00')

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

levels.access_level_name_1 && levels.access_level_name_2