En este artículo se describen casos prácticos de acceso contextual que incluyen políticas que usan niveles de acceso personalizados. En estos ejemplos, se crean niveles de acceso personalizados en el modo avanzado mediante el lenguaje de expresión común (CEL).
Si lo prefieres, también puedes usar funciones y macros al crear niveles de acceso personalizados con expresiones CEL.
Para ver ejemplos de niveles de acceso desarrollados en el modo básico (mediante la interfaz de acceso contextual), consulta el artículo Ejemplos de acceso contextual del modo básico.
Ejemplos de autenticación
Para mejorar la seguridad del acceso a las aplicaciones que contienen datos sensibles, puedes determinar cómo se tiene que autenticar el usuario en el sistema para acceder a las aplicaciones.
Por ejemplo, los usuarios que inicien sesión únicamente con una contraseña solo podrán acceder a aplicaciones que no contengan información sensible, mientras que un usuario que inicie sesión, además, con una llave de seguridad de hardware como segundo factor podrá acceder a las aplicaciones empresariales más sensibles.
Este nivel de acceso utiliza atributos request.auth para verificar que los usuarios inician sesión utilizando tanto una contraseña como una llave de hardware para la verificación en dos pasos y que pueden acceder a aplicaciones sensibles.
request.auth.claims.crd_str.pwd == true && request.auth.claims.crd_str.hwk == trueA menudo, los administradores quieren implementar obligatoriamente niveles de acceso a los recursos de la empresa después de que el usuario se haya autenticado con credenciales seguras. En el siguiente ejemplo se utilizan los atributos levels y request.auth como se indica a continuación:
- Si un usuario accede desde un dispositivo corporativo, podrá utilizar cualquier método de autenticación multifactor, excepto los SMS; se aceptan como métodos válidos las notificaciones push, las llaves de seguridad de hardware o software, o las 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.
// Requerir autenticación multifactor básica (no SMS) en los dispositivos corporativos y llave de seguridad (hardware o software) en los no corporativos
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
)
)
)
Ejemplos de dispositivos
Abrir sección | Ocultar todo y volver al principio
Puedes utilizar las señales de dispositivos notificadas por un partner de BeyondCorp Alliance. En este ejemplo, se utiliza el software de Lookout como aplicación.
Este nivel de acceso utiliza el atributo device para verificar que Lookout considera que el dispositivo utilizado para acceder a Google Workspace cumple las políticas y que la puntuación de estado es Muy bueno.
device.vendors["Lookout"].is_compliant_device == true && device.vendors["Lookout"].device_health_score == DeviceHealthScore.VERY_GOODEste nivel de acceso utiliza el atributo device para verificar que los usuarios estén utilizando la última versión de un navegador Chrome gestionado, y solo permite el acceso desde ese navegador.
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED && device.chrome.versionAtLeast("94.0.4606.81") Puedes utilizar certificados de empresa en dispositivos usando niveles de acceso personalizados para determinar si esos dispositivos son propiedad de la empresa. Este nivel de acceso utiliza el atributo device para verificar el recurso. Para obtener más información y ejemplos, consulta el artículo sobre cómo configurar condiciones de certificados de empresa.
Un dispositivo puede tener más de un certificado. Los certificados de empresa se usan en un nivel de acceso personalizado mediante la macro exists(). Por ejemplo:
device.certificates.exists(certificado, predicado)
En este ejemplo, certificado es un identificador simple, que se puede usar en la variable predicado para vincularlo con el certificado de empresa del dispositivo. La macro exists() combina resultados de predicados por elemento con el operador o (||). Las macros devuelven true si al menos un certificado se corresponde con la expresión del predicado.
En la tabla siguiente, se incluyen los atributos con los que puedes crear expresiones CEL para usarlas con niveles de acceso personalizados. Ten en cuenta que las comparaciones de cadenas distinguen entre mayúsculas y minúsculas.
| Atributo | Descripción | Ejemplo de expresión de predicado (donde certificado es un identificador de macros) |
|---|---|---|
| is_valid |
Devuelve true si el certificado es válido y no ha caducado. |
certificado.is_valid |
| cert_fingerprint | Huella digital del certificado (SHA256 sin relleno en base64) |
certificado.cert_fingerprint == origin. |
| root_ca_fingerprint | Huella digital del certificado AC raíz utilizado para firmar este certificado (SHA256 sin relleno en base64) |
certificado.root_ca_fingerprint == "la_huella_digital" |
| issuer |
Nombre del emisor Para encontrar el nombre del emisor, ejecuta el siguiente comando en el certificado:
La cadena de emisor que se utiliza en el nivel de acceso es la inversa del resultado de este comando, con la barra diagonal (/) sustituida por una coma. Por ejemplo:
|
certificado.issuer == "EMAILADDRESS=prueba_inter1 |
| subject | Nombre del sujeto del certificado (nombres totalmente ampliados) |
certificado.subject == "SUJETO_AC" |
| serial_number |
Número de serie del certificado |
certificado.serial_number == "123456789" |
| template_id | ID de plantilla de Certificate Template de la extensión X.509 para el certificado (cadena) |
certificado.template_id == "1.3.6.1.4.1.311.21. |
Ejemplos de políticas utilizadas habitualmente:
Validar que el dispositivo tiene un certificado de empresa válido firmado por el certificado raíz de la empresa
device.certificates.exists(certificado, certificado.is_valid && certificado.root_ca_fingerprint == "HUELLA_DIGITAL_DE_AC_RAÍZ")
Validar el emisor del certificado de empresa del dispositivo
device.certificates.exists(certificado, certificado.is_valid && certificado.issuer == "EMAILADDRESS=prueba_inter1@beyondcorp.in, CN=inter_1, OU=BCEDemo_1, O=BCEDemo, L=NCR, ST=UP, C=IN”)
En este ejemplo se utiliza el atributo device para requerir que el cifrado de disco y el bloqueo de pantalla estén habilitados. Además, los administradores tienen que aprobar el dispositivo.
De forma predeterminada, todos los dispositivos creados con verificación de puntos finales están aprobados. Sin embargo, en algunos casos es posible que quieras bloquear un dispositivo; por ejemplo, cuando se pierde. En estos casos, es posible que no quieras que estos dispositivos accedan a los recursos corporativos.
En el resto de los ejemplos de niveles de acceso incluidos en este documento, asignaremos el nombre Require_Secure_Device a este nivel de acceso.
// Requerir que el cifrado de disco y el bloqueo de pantalla estén habilitados
// Se debe aplicar a todas las plataformas principales (Windows, Mac, Linux, CrOS, iOS, Android)
// Este es el nivel de acceso básico y el resto de los niveles de acceso deberían depender de él
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device
En este ejemplo, el nivel de acceso utiliza el atributo device para requerir el uso de un navegador Chrome con requisitos de seguridad básicos.
// Requerir que Chrome se gestione a nivel de perfil o de navegador, que tenga
// habilitados los informes de la actividad relacionada con la seguridad y que su versión sea la 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 utiliza el atributo device para requerir que el usuario acceda desde un perfil o un navegador Chrome gestionado y que Chrome tenga activados los conectores de amenazas y protección de datos. En el ejemplo se utiliza el atributo levels para hacer referencia al nivel de acceso en el que se requiere Chrome gestionado descrito anteriormente. En el siguiente ejemplo, el nivel de acceso dependiente se denomina require_Managed_Chrome.
// Requerir Chrome gestionado (dependiente del nivel de acceso "Require_Managed_Chrome")
// y requerir que la inspección del contenido de las descargas y la comprobación de URLs estén habilitadas
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled
Uno de los requisitos para controlar el acceso es permitir el acceso solo cuando el dispositivo esté gestionado o sea propiedad de la empresa. Hay muchas formas de determinar si un dispositivo es propiedad de una empresa o está gestionado; por ejemplo:
- Si el número de serie de un dispositivo coincide con el de un dispositivo del sistema de gestión de recursos de la empresa
- Si un dispositivo tiene un certificado de empresa válido emitido por la empresa
Estos dos enfoques se pueden utilizar 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 está gestionado.
// El dispositivo es propiedad de la empresa si una de estas condiciones devuelve true:
// 1. Si el número de serie coincide con el que ha subido el administrador
// 2. Si el dispositivo tiene un certificado emitido por la empresa válido
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(certificado, certificado.is_valid && certificado.root_ca_fingerprint == "HUELLA_DIGITAL_DE_AC_RAÍZ")
)
La huella digital es el algoritmo SHA256 digest codificado (en formato binario) sin relleno en base64 del certificado DER codificado. La cadena se puede generar a partir del certificado en formato PEM mediante 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 la emisión (iat)
- Marca de tiempo de la caducidad (exp) (que parece ser 2 semanas posterior a la marca de tiempo de emisión en la versión actual)
El nivel de acceso utiliza el atributo device para asegurar que los datos de CrowdStrike estén actualizados. Ten en cuenta que BeyondCorp Enterprise aplica las nuevas evaluaciones de Falcon ZTA con un retraso inherente de 90 minutos, por lo que no es aconsejable usar duraciones inferiores a una hora.
// Verificar que una de estas condiciones devuelve true para los datos de CrowdStrike:
// Se debe cumplir una de estas condiciones
// 1. El dispositivo se ha evaluado durante el último día
// 2. La evaluación no ha caducado (2 semanas desde la última 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")
)
BeyondCorp Enterprise colabora con muchos partners del ecosistema de BeyondCorp Alliance para integrar sus señales de dispositivos y su contexto en la solución BeyondCorp Enterprise. Los partners pueden compartir cualquier cantidad de atributos con BeyondCorp, y uno de ellos es is_compliant_device attribute. En el siguiente ejemplo se utiliza el atributo device para mostrar cómo podemos comprobar si alguno de los partners de BeyondCorp Alliance ha integrado BeyondCorp Enterprise y considerar que el dispositivo cumple los requisitos.
La macro exists amplía la expresión de cada partner de BeyondCorp Alliance con un operador || (o).
// Comprobar si alguno de los partners de BCA considera que el dispositivo cumple los requisitos
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)
En este ejemplo se utilizan atributos device para asegurar que los dispositivos utilicen una versión de Android segura.
El inicio verificado comprueba si el código ejecutado procede de una fuente de confianza (por lo general, el fabricante del dispositivo), y que no proceda de un atacante o esté dañado. Consulta más información sobre el inicio verificado.
// Requerir que el estado de inicio verificado de Android sea verde
device.android_device_security.verified_boot == true
En este ejemplo se utilizan atributos device para requerir que los dispositivos superen las comprobaciones de cumplimiento de la Suite de Pruebas de Compatibilidad (CTS). Para obtener más información, ve a la Suite de Pruebas de Compatibilidad.
// Requerir que los dispositivos superen las comprobaciones de cumplimiento de la CTS
device.android_device_security.cts_profile_match == true
En este ejemplo se utilizan atributos device para requerir que los dispositivos tengan activada la función Verificar Aplicaciones de Google Play Protect.
La función Verificar Aplicaciones analiza las aplicaciones que se descargan desde fuentes distintas a Google Play en busca de amenazas. También analiza periódicamente los dispositivos para detectar aplicaciones potencialmente dañinas. Verificar Aplicaciones está activada de forma predeterminada. En los dispositivos con gestión avanzada, puedes especificar si los usuarios pueden desactivarla. Para obtener más información, consulta el artículo Aplicar ajustes a dispositivos móviles Android.
// Requerir que los dispositivos tengan habilitada la función Verificar Aplicaciones de Google Play Protect
device.android_device_security.verify_apps_enabled == true
En este ejemplo se utilizan atributos device para denegar el acceso a los dispositivos que tengan aplicaciones potencialmente dañinas. A menudo, estas aplicaciones se denominan malware. Consulta más información en el artículo Aplicaciones potencialmente dañinas.
// Denegar el acceso a dispositivos que tengan aplicaciones potencialmente dañinas appsandroid_device_security.has_potentially_harmful_apps != true
Ejemplos de acceso basados en el tiempo
Abrir sección | Ocultar todo y volver al principio
Las empresas quieren asegurarse de que los empleados que trabajan por turnos solo puedan acceder a los recursos corporativos durante su jornada laboral. Los siguientes niveles de acceso utilizan el atributo levels para definir tres turnos de lunes a viernes.
// Turno 1: de lunes a viernes, de medianoche a 08: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('00:00:00', '08:00:00')
// Turno 2: de lunes a viernes, de 8:00 a 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
// Turno 3: de lunes a viernes, de 16:00 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')
// Permitir que los empleados que trabajan por turnos accedan a los recursos de lunes a viernes de 9:00 a 17:00, excepto el día cuatro 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 un acceso de emergencia cuando el administrador no tiene acceso a un dispositivo seguro, pero necesita acceder urgentemente durante un breve periodo de tiempo.
En este caso, crea un nivel de acceso con limitación de tiempo y ubicación mediante el atributo levels y asígnalo al administrador específico. Si se asigna este nivel de acceso, solo sería válido durante el tiempo especificado. Una vez finalizado este periodo, se volverían a aplicar los requisitos actuales al acceso del administrador.
// Permitir el acceso temporal a los recursos el 1 de marzo del 2022 de 22:00 a 00:00;
// solo se debe acceder desde 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 no está incluida, por lo que es posible que los usuarios no tengan acceso
// durante 2 segundos en el periodo indicado arriba. También puedes utilizar esta opción:
// !between(‘00:00:01’,’16:00:00’)
Ejemplo de combinación de condiciones de dos niveles
Definir un nuevo nivel de acceso combinando condiciones de otros dosEste nivel de acceso utiliza atributos levels, y requiere que los usuarios cumplan las condiciones combinadas de dos niveles de acceso. En este ejemplo, nombre_nivel_acceso_1 y nombre_nivel_acceso_2 hacen referencia al nombre interno.
level.nombre_nivel_acceso_1 && level.nombre_nivel_acceso_2