Este artigo descreve os casos de uso do acesso baseado no contexto que incluem políticas com níveis de acesso personalizados. Nestes exemplos, você cria níveis de acesso personalizados no Modo avançado usando a Common Expressions Language (CEL).
Se preferir, você também pode usar funções e macros ao criar níveis de acesso personalizados usando expressões CEL.
Para ver exemplos dos níveis de acesso desenvolvidos no Modo básico (usando a interface do acesso baseado no contexto), consulte Exemplos de acesso baseado no contexto no Modo básico.
Exemplos de autenticação
Para melhorar a segurança no acesso a aplicativos que contêm dados confidenciais, você pode determinar como o usuário fez a autenticação no sistema para decidir se ele tem acesso a esses aplicativos.
Por exemplo, os usuários que fazem login com uma senha podem ter acesso apenas aos apps que não contêm informações confidenciais, enquantos os usuários que fazem login com uma chave de segurança de hardware como segundo fator podem acessar os aplicativos da empresa com informações sensíveis.
Esse nível de acesso usa atributos request.auth para verificar se os usuários fazem login com uma senha e uma chave de hardware para a verificação em duas etapas e têm acesso aos aplicativos confidenciais.
request.auth.claims.crd_str.pwd == true && request.auth.claims.crd_str.hwk == trueMuitas vezes, os administradores querem aplicar o acesso a recursos corporativos somente depois que o usuário fizer a autenticação com credenciais fortes. O exemplo a seguir usa os atributos levels e request.auth da seguinte maneira:
- Se um usuário vier de um dispositivo corporativo, de qualquer autenticação multifator (MFA), exceto SMS, o método será suficiente. Os métodos podem ser uma notificação push, uma chave de segurança de hardware ou de software ou uma senha única.
- Se um usuário vier de um dispositivo que NÃO é corporativo, deve ser usada uma chave de segurança de hardware ou de software.
// Exigir MFA básica (não SMS) em dispositivos corporativos e chave de segurança (hardware ou software) se não for
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
)
)
)
Exemplos de dispositivos
Abrir seção | Recolher tudo e voltar ao início
Você pode usar os sinais do dispositivo informados por um parceiro da BeyondCorp Alliance. Neste exemplo, o software Lookout é usado como o aplicativo.
Esse nível de acesso usa o atributo device para verificar se o dispositivo usado para acessar o Google Workspace é informado pelo Lookout como em conformidade com as políticas. Além disso, a pontuação de integridade é "Muito boa".
device.vendors["Lookout"].is_compliant_device == true && device.vendors["Lookout"].device_health_score == DeviceHealthScore.VERY_GOODEsse nível de acesso usa o atributo device para verificar se os usuários estão usando a versão mais recente de um navegador Chrome gerenciado e só permite o acesso nesse navegador.
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED && device.chrome.versionAtLeast("94.0.4606.81") Você pode usar certificados empresariais para dispositivos em níveis de acesso personalizados e determinar se um dispositivo pertence à empresa. Esse nível de acesso usa o atributo device para a verificação do recurso. Leia Como configurar condições de certificados empresariais para ver mais informações e exemplos.
Um dispositivo pode ter mais de um certificado. Os certificados empresariais são usados em um nível de acesso personalizado com a macro exists(). Exemplo:
device.certificates.exists(cert, predicate)
Neste exemplo, cert é um identificador simples a ser usado na variável predicate e vinculado ao certificado empresarial do dispositivo. A macro exists() combina resultados de predicado por elemento com o operador or(||). As macros retornam true quando pelo menos um certificado corresponde à expressão de predicado.
A tabela abaixo lista os atributos que podem ser usados para formar expressões de CEL a serem usadas com níveis de acesso personalizados. As comparações de strings diferenciam maiúsculas de minúsculas.
| Atributo | Descrição | Exemplo de expressão de predicado (em que cert é um identificador de macros) |
|---|---|---|
| is_valid |
Verdadeiro se o certificado for válido e não tiver expirado. |
cert.is_valid |
| cert_fingerprint | Impressão digital do certificado (hash SHA-256 no formato Base64 não preenchido) |
cert.cert_fingerprint == origin. |
| root_ca_fingerprint | Impressão digital do certificado de CA raiz usado para assinar este certificado (hash SHA-256 no formato Base64 não preenchido) |
cert.root_ca_fingerprint == "the_fingerprint" |
| issuer |
Nome do emissor Para encontrar o nome do emissor, execute o seguinte comando no certificado:
A string do emissor usada no nível de acesso é o inverso da saída, e o caractere “/” é substituído por uma vírgula, por exemplo:
|
cert.issuer == "EMAILADDRESS=test_inter1 |
| subject | Nome do assunto do certificado (nomes totalmente expandidos) |
cert.subject == "CA_SUB" |
| serial_number |
Número de série do certificado |
cert.serial_number == “123456789” |
| template_id | ID do modelo da extensão X.509 CertificateTemplate do certificado (string) |
cert.template_id == "1.3.6.1.4.1.311.21. |
Exemplos de políticas usadas com frequência:
Confirmar que o dispositivo tem um certificado corporativo válido assinado pelo certificado raiz da empresa
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "ROOT_CA_FINGERPRINT")
Validar o emissor do certificado empresarial no 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”)
Este exemplo usa o atributo device para exigir que a criptografia de disco e o bloqueio de tela sejam ativados. Além disso, o dispositivo deve ser aprovado pelos administradores.
Por padrão, todos os dispositivos criados pela Verificação de endpoints são aprovados. No entanto, em alguns casos, é possível bloquear um dispositivo, como, por exemplo, quando ele for perdido. Nesses casos, é melhor que os dispositivos não tenham acesso aos recursos corporativos.
Para outros exemplos de nível de acesso neste documento, vamos supor que esse nível de acesso se chame Require_Secure_Device.
// Exige criptografia de disco e bloqueio de tela ativados
// Isso se aplica a todas as principais plataformas (Windows, Mac, Linux, CrOS, iOS, Android)
// Isso é básico e deve depender de todos os outros níveis de acesso
device.encryption_status == DeviceEncryptionStatus.ENCRYPTED &&
device.is_secured_with_screenlock &&
device.is_admin_approved_device
Neste exemplo, o nível de acesso usa o atributo device para exigir o navegador Chrome com requisitos básicos de segurança.
// Exigir que o Chrome seja gerenciado no nível do perfil ou do navegador, deve ter
// relatórios de ocorrências de segurança ativados e deve ser a versão 97 ou mais recente
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")
Este exemplo usa o atributo device para exigir que o usuário venha de um navegador ou perfil gerenciado do Chrome e que o Chrome tenha os conectores contra ameaças e de proteção de dados ativados. O exemplo usa o atributo levels para se referir ao nível de acesso "Exigir acesso gerenciado do Chrome" descrito anteriormente. No exemplo a seguir, pressupomos que o nível de acesso dependente seja chamado Require_Managed_Chrome.
// Exigir Chrome gerenciado (dependente do nível de acesso “Require_Managed_Chrome”)
// e exigir inspeção de conteúdo para downloads, além de verificação de URL ativada
levels.Require_Managed_Chrome &&
device.chrome.is_file_download_analysis_enabled &&
device.chrome.is_realtime_url_check_enabled
Um requisito para controlar o acesso é somente permitir o acesso quando o dispositivo for gerenciado ou da empresa. Há muitas maneiras de determinar se um dispositivo é gerenciado ou pertence a uma empresa, incluindo:
- Se um dispositivo tem um número de série que corresponde ao do sistema de gerenciamento de recursos da empresa
- Se o dispositivo tem um certificado corporativo válido emitido pela empresa
Essas duas abordagens podem ser usadas no nível de acesso personalizado a seguir que usa os atributos levels e device para determinar se o dispositivo é gerenciado ou pertence a uma empresa.
// O dispositivo será corporativo se uma das seguintes condições for verdadeira:
// 1. Se o número de série corresponder ao que o administrador fez upload
// 2. Se o dispositivo tiver um certificado válido emitido pela 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")
)
A impressão digital é o hash sha-256 digest codificado em base64 (no formato binário) do certificado codificado por DER. A string pode ser gerada a partir do certificado no formato PEM usando o seguinte procedimento com openssl:
$ openssl x509 -in cert.pem -out cert.der -outform DER
$ openssl dgst -sha256 -binary cert.der > digest.sha
$ openssl base64 -in digest.sha
- Emitido em carimbo de data/hora (iat)
- Carimbo de data/hora de expiração (exp) (que parece ter duas semanas de emissão no carimbo de data/hora da versão atual)
O nível de acesso usa o atributo device para garantir que os dados da CrowdStrike sejam recentes. O BeyondCorp Enterprise tem um atraso inerente de 90 minutos para consumir qualquer nova avaliação da Falcon ZTA. Portanto, não recomendamos o uso de durações com menos de uma hora.
// Confirme se uma destas condições é verdadeira para os dados da Crowdstrike:
// Deve atender a uma destas condições
// 1. O dispositivo foi avaliado no último dia
// 2. A avaliação não expirou (duas semanas desde a ú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")
)
O BeyondCorp Enterprise trabalha com muitos parceiros de ecossistema da BeyondCorp Alliance para integrar os sinais e o contexto do dispositivo na solução do BeyondCorp Enterprise. Os parceiros podem compartilhar qualquer número de atributos com o BeyondCorp, e um deles é o atributo is_compliance_device. O exemplo a seguir usa o atributo device para mostrar como podemos verificar se qualquer um dos parceiros da BeyondCorp Alliance se integrou ao BeyondCorp Enterprise e considerar que o dispositivo está em conformidade.
A macro exists expande a expressão para cada um dos parceiros da BeyondCorp Alliance com um operador (ou) ||.
// Confira se algum dos parceiros da BCA considera que o dispositivo está em conformidade.
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)
Este exemplo usa o atributo device para garantir que os dispositivos executem uma versão segura do Android.
A Inicialização verificada verifica se o código executado vem de uma fonte confiável (geralmente OEMs de dispositivo), e não de um invasor ou de um arquivo corrompido. Saiba mais em Inicialização verificada.
// Exigir status verde de inicialização verificada do Android
device.android_device_security.verified_boot == true
Este exemplo usa atributos device para exigir que os dispositivos sejam aprovados nas verificações do Conjunto de teste de compatibilidade (CTS, na sigla em inglês). Veja mais detalhes em Conjunto de teste de compatibilidade.
// Exigir que os dispositivos sejam aprovados nas verificações de conformidade do CTS
device.android_device_security.cts_profile_match == true
Este exemplo usa atributos device para exigir que os dispositivos tenham o Verificar apps do Google Play Protect ativado.
Essa configuração verifica apps para identificar ameaças não provenientes do Google Play. Ela também verifica os dispositivos periodicamente para identificar apps potencialmente nocivos. O recurso Verificar apps vem ativado por padrão. Em dispositivos com gerenciamento avançado, você pode especificar se os usuários podem desativá-lo. Para mais informações, consulte Aplicar configurações a dispositivos móveis Android.
// Exigir que os dispositivos tenham o Verificar apps do Google Play Protect ativado
device.android_device_security.verify_apps_enabled == true
Este exemplo usa atributos device para negar acesso a dispositivos que têm aplicativos potencialmente nocivos. Esses apps geralmente são chamados de malware. Saiba mais em Aplicativos potencialmente nocivos (PHAs).
// Negar acesso a dispositivos que têm appsandroid_device_security.has_potentially_harmful_apps potencialmente nocivos != true
Exemplos de acesso com base no tempo
Abrir seção | Recolher tudo e voltar ao início
As empresas querem garantir que os funcionários que trabalham em turnos só tenham acesso aos recursos corporativos durante o horário de trabalho. Os níveis de acesso a seguir usam o atributo levels para definir três turnos de segunda a sexta-feira.
// Turno 1: de segunda a sexta-feira, da meia-noite às 8h
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 segunda a sexta-feira, das 8h às 16h
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 segunda a sexta-feira, das 16h à meia-noite
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 os funcionários que trabalham em turnos acessem os recursos de segunda a sexta-feira, das 9h às 17h, exceto no dia 4 de julho.
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')
Às vezes, as empresas querem permitir o acesso imediato durante emergências quando o administrador não tem acesso a um dispositivo seguro, mas precisa de acesso de emergência por um curto período.
Nesse caso, crie um nível de acesso com restrição de local e tempo usando o atributo levels e o atribua ao administrador específico. Depois que o nível de acesso for atribuído, ele só será válido pelo período especificado. Depois desse período, o acesso do administrador será controlado novamente pelos requisitos existentes.
// Permitir o acesso temporário a recursos em 1º de março de 2022, entre 22h e meia-noite,
// e esse acesso precisa estar dentro dos EUA.
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”
// O horário de término é exclusivo, portanto o código acima pode ter dois segundos que
// os usuários podem não ter acesso. Também é possível usar este
// !between(‘00:00:01’,’16:00:00’)
Exemplo de combinação de condições de dois níveis
Definir um novo nível de acesso combinando as condições de dois níveisEsse nível de acesso usa atributos levels e exige que os usuários atendam às condições combinadas de dois níveis de acesso. Neste exemplo, access_level_name_1 e access_level_name_2 fazem referência a Nome interno.
levels.access_level_name_1 && levels.access_level_name_2
