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, los usuarios que acceden solo con una contraseña pueden acceder a las aplicaciones que no contienen información sensible, mientras que un usuario que accedió con una llave de seguridad de hardware como segundo factor puede acceder a la información más sensible de las aplicaciones empresariales.

Este nivel de acceso usa atributos de 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 autentique con credenciales sólidas. 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 el 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, debe usar una llave de seguridad física o de 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 se aplica a las APIs ni a las apps para dispositivos móviles

Puedes mejorar la seguridad del acceso a las apps que contienen datos sensibles si exiges credenciales de sesión vinculadas al dispositivo (DBSC). DBSC vincula 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 sesiones.

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. Si no es así (es decir, la sesión no está vinculada a DBSC), se deniega el acceso.

Para evitar errores, activa el DBSC en todas las cuentas de usuario sujetas a este nivel de acceso. Para obtener más información, consulta Cómo activar el 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 niveles de acceso sin interrumpir el acceso de los usuarios.

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

request.auth.sessionBoundToDevice(origin) == true

Usa esta expresión CEL para aplicar el 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 Lookout informe que el dispositivo que se usa para acceder a Google Workspace cumple con las políticas y que la puntuación de estado es Muy bueno.

Este nivel de acceso usa el atributo device para verificar que los usuarios estén usando 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 activo propiedad de la empresa. Este nivel de acceso usa el atributo device para la verificación del activo. Para obtener más información y ejemplos, consulta Cómo configurar condiciones de certificados empresariales.

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 predicate para vincularse al certificado empresarial del dispositivo. La macro exists() combina los resultados del predicado por elemento con el operador or (||). Las macros devuelven verdadero si al menos un certificado satisface la expresión del predicado.

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

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 certificadora 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 requerir que se habiliten la encriptación del 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 desees bloquear un dispositivo, por ejemplo, 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.

// Se requiere que Chrome se administre a nivel del perfil o del navegador, debe tener
// habilitada la generación de informes de eventos de seguridad y debe ser la versión 97 o posterior
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 le pertenece. Existen muchas formas de determinar si un dispositivo es propiedad de la empresa o está administrado por ella, incluidas las siguientes:

• Si un dispositivo tiene un número de serie que coincide con uno que se encuentra 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 atributos de niveles y dispositivo para determinar si el dispositivo es propiedad de la empresa o 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 inherente 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. Se evaluó el dispositivo en el último día
// 2. La evaluación no venció (2 semanas desde el último iat)
"CrowdStrike" en device.vendors Y (
request.time - timestamp(device.vendors["CrowdStrike"].data["iat"]) < duration("1d") O
timestamp(device.vendors["CrowdStrike"].data["exp"]) - request.time > duration("0m")
)

Chrome Enterprise Premium funciona con muchos socios del ecosistema de BeyondCorp Alliance para integrar sus indicadores y contexto de dispositivos en la solución de Chrome Enterprise Premium. Los socios pueden compartir cualquier cantidad de atributos con Chrome Enterprise Premium, 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 || (o).

// 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 del dispositivo 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 confiable (por lo general, los OEM de dispositivos) en lugar de un atacante o una corrupción. Para obtener más información, 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 pasen las verificaciones de cumplimiento del Conjunto de pruebas de compatibilidad (CTS). Para obtener más información, consulta el Conjunto de pruebas de compatibilidad.

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

En este ejemplo, se usan atributos de device para exigir que los dispositivos tengan activada la Verificación de aplicaciones de Google Play Protect.

La función de Verificación de apps analiza las apps en busca de amenazas cuando se instalan desde fuentes que no son de Google Play. También analiza periódicamente los dispositivos en busca de apps potencialmente dañinas. La función Verificar aplicaciones está activada de forma predeterminada. En el caso de los dispositivos con administración avanzada, puedes especificar si los usuarios pueden desactivar el parámetro. Para obtener más información, consulta Cómo aplicar la configuración a 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 apps potencialmente dañinas. Estas apps suelen denominarse software malicioso. Para obtener más información, 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 su horario laboral. Los siguientes niveles de acceso usan el atributo levels para definir 3 turnos de lunes a viernes.

// 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')

// Turno 2: De lunes a viernes, de 8 a.m. a 4 p.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('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')

// 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')

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

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

// 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"
// Note that the end time is exclusive, so the above potentially has 2 seconds that
// the users may not have access. Otra opción es usar este
// !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 al Nombre interno.

levels.access_level_name_1 && levels.access_level_name_2