Ejemplos de Acceso adaptado al contexto para el modo avanzado

Para mejorar la seguridad del acceso a las aplicaciones que contienen datos sensibles, puedes determinar cómo se autenticó el usuario en el sistema para decidir si obtiene acceso a la aplicación.

Por ejemplo, a los usuarios conectados solo con una contraseña se les puede permitir acceder a las aplicaciones que no contienen información sensible, mientras que a un usuario conectado con una llave de seguridad física como segundo factor se le puede permitir acceder a las aplicaciones empresariales más sensibles.

Este nivel de acceso usa los atributos request.auth para verificar que los usuarios accedan con una contraseña y una llave de hardware para la verificación en 2 pasos, y que puedan acceder a aplicaciones sensibles.

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

A menudo, los administradores quieren aplicar el acceso a los recursos corporativos solo después de que el usuario se haya autenticado con credenciales seguras. En el siguiente ejemplo, se usan los atributos levels y request.auth de la siguiente manera:

• Si un usuario accede desde un dispositivo corporativo, cualquier método de MFA, excepto SMS, será suficiente (los métodos pueden ser notificaciones push, llaves de seguridad de hardware o software, o contraseñas de un solo uso).
• Si un usuario accede desde un dispositivo no corporativo, se debe usar una llave de seguridad de hardware o software.

// Require basic MFA (not SMS) on corporate devices and security key (hardware or software) if not
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
)
)
)

Se limita a las apps web para computadoras y no corresponde a las apps para dispositivos móviles ni a las APIs.

Puedes mejorar la seguridad del acceso a las apps que contienen datos sensibles exigiendo las credenciales de sesión vinculadas al dispositivo (DBSC). Las DBSC vinculan la sesión de un usuario a su dispositivo cuando usa el navegador Chrome en Windows, lo que puede reducir significativamente el riesgo de secuestro de sesión.

Este nivel de acceso usa el atributo request.auth para verificar que las sesiones del usuario estén vinculadas a un dispositivo específico. Si es así, se otorga acceso a la app. De lo contrario (es decir, si la sesión no está vinculada a DBSC), se deniega el acceso.

Para evitar problemas de acceso, asegúrate de que las cuentas de usuario a las que se les asignó este nivel de acceso cumplan con los requisitos necesarios. Para obtener más información, consulta Requisitos para usar las DBSC.

Establece el nivel de acceso en Modo de supervisor antes de activar el modo Activo. En el modo de supervisor, puedes probar el impacto de la aplicación de medidas por incumplimiento del nivel de acceso sin interrumpir el acceso de los usuarios.

Usa esta expresión de CEL para crear tu nivel de acceso personalizado:

request.auth.sessionBoundToDevice(origin) == true

Usa esta expresión de CEL para aplicar la DBSC solo en dispositivos Windows con la versión 136 o posterior del navegador Chrome:

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

Puedes usar los indicadores de dispositivos que informa un socio de BeyondCorp Alliance. En este ejemplo, se usa Lookout Software como la aplicación.

Este nivel de acceso usa el atributo device para verificar que el dispositivo que se usa para acceder a Google Workspace se informe como conforme a las políticas de Lookout y que la puntuación de estado sea Muy buena.

Este nivel de acceso usa el atributo device para verificar que los usuarios usen la versión más reciente de un navegador Chrome administrado y permite el acceso solo a través de ese navegador.

Puedes usar certificados empresariales para dispositivos en niveles de acceso personalizados y determinar si un dispositivo es un recurso de propiedad de la empresa. Este nivel de acceso usa el atributo device para la verificación del recurso. Lee Configura las condiciones de los certificados empresariales para obtener más información y ejemplos.

Un dispositivo puede tener más de un certificado. Los certificados empresariales se usan en un nivel de acceso personalizado con la macro exists(). Por ejemplo:

device.certificates.exists(cert, predicate)

En este ejemplo, cert es un identificador simple que se usa en el predicado de la variable para vincularlo al certificado empresarial del dispositivo. La macro exists() combina los resultados del predicado por elemento con el operador or (||). Las macros devuelven true si al menos un certificado cumple con la expresión de predicado.

En la siguiente tabla, se enumeran los atributos que puedes usar para formar expresiones de CEL que se usarán con niveles de acceso personalizados. Ten en cuenta que las comparaciones de cadenas distinguen mayúsculas de minúsculas.

Estos son algunos ejemplos de políticas de uso general:

Valida que el dispositivo tenga un certificado empresarial válido firmado por el certificado raíz de la empresa

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

Valida la entidad emisora del certificado empresarial en el dispositivo

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

En este ejemplo, se usa el atributo device para exigir que se habiliten la encriptación de disco y el bloqueo de pantalla. Además, los administradores deben aprobar el dispositivo.

De forma predeterminada, se aprueban todos los dispositivos creados por la Verificación de extremos. Sin embargo, hay casos en los que es posible que quieras bloquear un dispositivo, como cuando se pierde. En estos casos, no querrás que estos dispositivos puedan acceder a los recursos corporativos.

Para otros ejemplos de niveles de acceso en este documento, supón que este nivel de acceso tiene el nombre Require_Secure_Device.

// Require disk encryption and screen lock enabled
// This is applicable across all major platforms (Windows, Mac, Linux, CrOS, iOS, Android)
// This foundational and should be depended upon by all other access levels
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device

En este ejemplo, el nivel de acceso usa el atributo device para requerir el navegador Chrome con requisitos de seguridad básicos.

// Require Chrome to be managed at profile or browser level, must have
// security event reporting enabled and must be version 97 or greater
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")

En este ejemplo, se usa el atributo device para exigir que el usuario provenga de un navegador o perfil de Chrome administrado, y que Chrome tenga activados los conectores de protección de datos y contra amenazas. En el ejemplo, se usa el atributo levels para hacer referencia al nivel de acceso Require Managed Chrome que se describió anteriormente. En el siguiente ejemplo, se supone que el nivel de acceso dependiente se llama Require_Managed_Chrome.

// Require managed chrome (dependent on "Require_Managed_Chrome" access level)
// and require content inspection for downloads as well as URL check enabled
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled

Un requisito para controlar el acceso es permitirlo solo cuando el dispositivo es administrado por la empresa o es de su propiedad. Existen muchas formas de determinar si un dispositivo es propiedad de la empresa o si está administrado, incluidas las siguientes:

• Si un dispositivo tiene un número de serie que coincide con uno que está en el sistema de administración de activos de la empresa
• Si un dispositivo tiene un certificado empresarial válido emitido por la empresa

Estos dos enfoques se pueden usar en el siguiente nivel de acceso personalizado que usa los atributos levels y device para determinar si el dispositivo es propiedad de la empresa o si está administrado por ella.

// El dispositivo es corporativo si se cumple una de las siguientes condiciones:
// 1. Si el número de serie coincide con el que subió el administrador
// 2. Si el dispositivo tiene un certificado válido emitido por la empresa
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)

La huella digital es el resumen SHA256 codificado en Base64 sin relleno (en formato binario) del certificado codificado en DER. La cadena se puede generar a partir del certificado en formato PEM con el siguiente procedimiento con openssl:

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

• Marca de tiempo de emisión (iat)
• Marca de tiempo de vencimiento (exp)

El nivel de acceso usa el atributo device para garantizar que los datos de CrowdStrike estén actualizados. Ten en cuenta que Chrome Enterprise Premium tiene una demora innata de 90 minutos para consumir cualquier evaluación nueva de Falcon ZTA, por lo que no se recomienda usar duraciones de menos de una hora.

// Ensure one of these conditions is true for data from Crowdstrike:
// Must meet one of these conditions
// 1. El dispositivo se evaluó en el último día
// 2. La evaluación no venció (2 semanas desde el último 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 aprovecha los indicadores y el contexto de dispositivos de sus socios del ecosistema de BeyondCorp Alliance para fortalecer la integración de su plataforma. Los socios pueden compartir con Chrome Enterprise Premium cuantos atributos quieran, y uno de ellos es el atributo is_compliant_device. En el siguiente ejemplo, se usa el atributo device para mostrar cómo podemos verificar si alguno de los socios de BeyondCorp Alliance se integró con Chrome Enterprise Premium y considera que el dispositivo cumple con los requisitos.

La macro exists expande la expresión para cada uno de los socios de BeyondCorp Alliance con un operador || (or).

// Check to see if any of the BCA partners consider the device to be compliant
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)

En este ejemplo, se usan atributos de device para garantizar que los dispositivos ejecuten una versión segura de Android.

El inicio verificado comprueba si el código ejecutado proviene de una fuente de confianza (por lo general, los OEM del dispositivo) y no de un atacante o de un daño. Para obtener más detalles, consulta Inicio verificado.

// Require green Android verified boot status
device.android_device_security.verified_boot == true

En este ejemplo, se usan atributos de dispositivo para exigir que los dispositivos aprueben las verificaciones de cumplimiento del Conjunto de pruebas de compatibilidad (CTS). Para obtener más información, consulta el Conjunto de pruebas de compatibilidad.

// Exige que los dispositivos aprueben las verificaciones de cumplimiento de CTS
device.android_device_security.cts_profile_match == true

En este ejemplo, se usan atributos de dispositivo para exigir que los dispositivos tengan activada la opción Verificar apps de Google Play Protect.

Verificar apps analiza las apps en busca de amenazas cuando se instalan desde fuentes que no son Google Play. Asimismo, escanea los dispositivos de forma periódica en busca de aplicaciones potencialmente dañinas. La función Verificar apps está activada de forma predeterminada. En el caso de los dispositivos con administración avanzada, puedes especificar si los usuarios pueden desactivarla. Para obtener más información, consulta Cómo aplicar la configuración para dispositivos móviles Android.

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

En este ejemplo, se usan atributos de dispositivo para denegar el acceso a dispositivos que tienen aplicaciones potencialmente dañinas. Estas apps suelen llamarse software malicioso. Para obtener más detalles, consulta Aplicaciones potencialmente dañinas (APD).

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

Las empresas quieren asegurarse de que sus trabajadores por turnos solo puedan acceder a los recursos corporativos durante sus horas de turno. Los siguientes niveles de acceso usan el atributo levels para definir 3 turnos de lunes a viernes.

// Turno 1: de lunes a viernes, de medianoche a 8 a.m.
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')

// Shift 2 - Monday to Friday, 8am to 4pm
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')

// Turno 3: de lunes a viernes, de 4 p.m. a medianoche
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')

// Permite que los trabajadores por turnos accedan a los recursos de lunes a viernes de 9:00 a.m. a 5:00 p.m., excepto el 4 de julio.
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')

A veces, las empresas quieren permitir el acceso de emergencia durante situaciones de emergencia en las que el administrador no tiene acceso a un dispositivo seguro, pero necesita acceso de emergencia durante un período breve.

En este caso, crea un nivel de acceso con restricciones de tiempo y ubicación con el atributo levels y asígnalo al administrador específico. Cuando se asigne este nivel de acceso, solo será válido durante el tiempo especificado. Una vez que venza este período, el acceso de administrador volverá a estar controlado por los requisitos existentes.

// Permitir el acceso temporal a los recursos el 1 de marzo de 2022, entre las 10 p.m. y la medianoche,
// y este acceso debe provenir de la región de EE.UU.
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"
// Ten en cuenta que la hora de finalización es exclusiva, por lo que lo anterior puede tener 2 segundos que
// es posible que los usuarios no tengan acceso. Otra opción es usar
// !between('00:00:01','16:00:00')

Este nivel de acceso usa atributos de niveles y requiere que los usuarios cumplan con las condiciones combinadas de dos niveles de acceso. En este ejemplo, access_level_name_1 y access_level_name_2 hacen referencia a Internal Name.

levels.access_level_name_1 && levels.access_level_name_2