Cas d'utilisation de l'accès contextuel en mode avancé

Pour renforcer la sécurité de l'accès aux applications contenant des données sensibles, vous pouvez déterminer si le mode d'authentification choisi par l'utilisateur lui permet ou non d'accéder à l'application en question.

Par exemple, les utilisateurs connectés avec un simple mot de passe peuvent uniquement être autorisés à accéder à des applications ne contenant aucune information sensible. En revanche, ceux connectés avec une clé de sécurité matérielle comme second facteur de validation peuvent être autorisés à accéder aux applications d'entreprise les plus sensibles.

Ce niveau d'accès utilise les attributs request.auth pour vérifier que les utilisateurs se connectent à la fois avec un mot de passe et une clé matérielle pour la validation en deux étapes, et qu'ils peuvent accéder aux applications sensibles.

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

Les administrateurs préfèrent souvent accorder l'accès aux ressources de l'entreprise uniquement après que l'utilisateur s'est authentifié avec des identifiants forts. Dans l'exemple ci-dessous, les attributs levels et request.auth sont utilisés comme suit :

• Si l'utilisateur se connecte à un appareil appartenant à l'entreprise, n'importe quelle méthode de MFA (sauf celle par SMS) convient : notification push, clé de sécurité matérielle ou logicielle, ou mot de passe à usage unique.
• S'il se connecte à un appareil n'appartenant pas à l'entreprise, une clé de sécurité matérielle ou logicielle est requise.

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

Limité aux applications Web pour ordinateur, non applicable aux applications mobiles ni aux API

Vous pouvez renforcer la sécurité de l'accès aux applications contenant des données sensibles en exigeant des identifiants de session liés à l'appareil. Les identifiants de session liés à l'appareil lient la session d'un utilisateur à son appareil lorsqu'il utilise le navigateur Chrome sous Windows, ce qui peut réduire considérablement le risque de détournement de session.

Ce niveau d'accès utilise l'attribut request.auth pour vérifier que les sessions de l'utilisateur sont liées à un appareil spécifique. Si c'est le cas, l'accès est accordé à l'application. Sinon (c'est-à-dire si la session n'est pas liée aux identifiants de session de l'appareil), l'accès est refusé.

Pour éviter les erreurs, activez DBSC pour tous les comptes utilisateur soumis à ce niveau d'accès. Pour en savoir plus, consultez Activer les identifiants de session liés à l'appareil.

Définissez le niveau d'accès sur mode Moniteur avant d'activer le mode actif. En mode Moniteur, vous pouvez tester l'impact de l'application d'un niveau d'accès sans perturber l'accès des utilisateurs.

Utilisez cette expression CEL pour créer votre niveau d'accès personnalisé :

request.auth.sessionBoundToDevice(origin) == true

Utilisez cette expression CEL pour appliquer les identifiants de session liés à l'appareil uniquement sur les appareils Windows équipés du navigateur Chrome version 136 ou ultérieure :

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

Vous pouvez utiliser les signaux d'appareil indiqués par un partenaire BeyondCorp Alliance. L'application Lookout est utilisée dans cet exemple.

Ce niveau d'accès s'appuie sur l'attribut device pour vérifier que selon Lookout, l'appareil utilisé pour accéder à Google Workspace est conforme aux règles définies, et que l'évaluation est "Very Good" (très bonne).

Ce niveau d'accès utilise l'attribut device pour vérifier que les utilisateurs disposent de la dernière version d'un navigateur Chrome géré, et n'autorise l'accès que via un navigateur remplissant ces conditions.

Pour les appareils dont les niveaux d'accès sont personnalisés, les certificats d'entreprise vous permettent de déterminer si un appareil appartient à l'entreprise. Ce niveau d'accès utilise l'attribut device pour valider les appareils. Pour en savoir plus et obtenir des exemples, consultez Configurer les conditions de certificat d'entreprise.

Un appareil peut posséder plusieurs certificats. Les certificats d'entreprise sont utilisés dans les niveaux d'accès personnalisés à l'aide de la macro exists(). Exemple :

device.certificates.exists(certificat, prédicat)

Dans cet exemple, certificat est un identifiant simple qui permet de lier le certificat d'entreprise de l'appareil et qui doit être utilisé dans la variable du prédicat. La macro exists() combine les résultats du prédicat par élément avec l'opérateur or (||). Les macros renvoient true si au moins un certificat satisfait l'expression de prédicat.

Le tableau ci-dessous présente les attributs qui permettent de former des expressions CEL que vous pouvez utiliser avec les niveaux d'accès personnalisés. Notez que les comparaisons de chaînes sont sensibles à la casse.

Exemples de règles fréquemment utilisées :

S'assurer que l'appareil dispose d'un certificat d'entreprise valide signé par le certificat racine de l'entreprise

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

Valider l'émetteur du certificat d'entreprise sur l'appareil

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

Cet exemple utilise l'attribut device pour exiger que le chiffrement du disque et le verrouillage de l'écran soient activés. L'appareil doit, par ailleurs, être approuvé par les administrateurs.

Par défaut, tous les appareils créés par Endpoint Verification sont approuvés. Mais vous pouvez parfois être amené à bloquer un appareil, par exemple en cas de perte. Dans ce type de situation, vous ne souhaitez pas que l'appareil ait accès aux ressources de l'entreprise.

Pour les autres exemples de niveaux d'accès présentés ici, nous partirons du principe que ce niveau d'accès est nommé 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

Dans cet exemple, le niveau d'accès utilise l'attribut device pour imposer l'utilisation du navigateur Chrome avec les exigences de sécurité de base.

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

Cet exemple s'appuie sur l'attribut device pour exiger que l'utilisateur se connecte via un profil ou un navigateur Chrome géré, et que les connecteurs de protection des données et de prévention des menaces soient activés dans Chrome. Cet exemple utilise l'attribut levels pour faire référence au niveau d'accès "Exiger que Chrome soit géré" décrit précédemment. L'exemple suivant suppose que le niveau d'accès dépendant est nommé 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

Pour contrôler l'accès, vous devez l'autoriser uniquement lorsque l'appareil est géré ou détenu par l'entreprise. Il existe de nombreuses façons de déterminer si un appareil est détenu ou géré par l'entreprise, par exemple :

• Vérifier si le numéro de série de l'appareil correspond à un numéro figurant dans le système de gestion des ressources de l'entreprise
• Vérifier si l'appareil dispose d'un certificat d'entreprise valide émis par l'entreprise

Ces deux approches peuvent être adoptées dans le niveau d'accès personnalisé ci-dessous, qui utilise les attributs levels et device pour déterminer si l'appareil est détenu ou géré par l'entreprise.

// L'appareil appartient à l'entreprise si l'une des conditions suivantes est remplie :
// 1. Si le numéro de série correspond à celui importé par l'administrateur
// 2. Si l'appareil dispose d'un certificat d'entreprise valide
levels.Require_Secure_Device &&
(
device.is_corp_owned_device ||
device.certificates.exists(cert, cert.is_valid && cert.root_ca_fingerprint == "SOME_ROOT_CA_FINGERPRINT")
)

L'empreinte correspond au condensé SHA256 encodé en base64 sans remplissage (au format binaire) du certificat avec encodage DER. La chaîne peut être générée à partir du certificat au format PEM via la procédure suivante avec openssl :

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

• Code temporel d'émission (iat)
• Code temporel d'expiration (exp)

Le niveau d'accès utilise l'attribut device pour s'assurer que les données CrowdStrike sont récentes. Notez que Chrome Enterprise Premium accorde un délai de 90 minutes pour consulter les nouvelles évaluations Falcon ZTA. Il est donc déconseillé d'utiliser des durées inférieures à une heure.

// Vérifier que l'une des conditions suivantes est remplie pour les données de CrowdStrike :
// Doit respecter l'une de ces conditions
// 1. L'appareil a été évalué au cours du dernier jour
// 2. L'évaluation n'a pas expiré (deux semaines depuis la dernière iat)
"CrowdStrike" dans 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 collabore avec de nombreux partenaires de l'écosystème BeyondCorp Alliance pour intégrer les signaux et le contexte de leurs appareils à la solution Chrome Enterprise Premium. Les partenaires peuvent partager autant d'attributs qu'ils le souhaitent avec Chrome Enterprise Premium, et l'un d'entre eux est l'attribut is_compliant_device. L'exemple ci-dessous utilise l'attribut device pour montrer comment vérifier si l'un des partenaires BeyondCorp Alliance a intégré Chrome Enterprise Premium et considère l'appareil comme conforme.

La macro exists développe l'expression pour chacun des partenaires BeyondCorp Alliance avec un opérateur || (ou).

// Vérifiez si l'un des partenaires BCA considère l'appareil comme conforme
["CrowdStrike", "Tanium", "PANW", "Check Point", "Lookout"].exists(
v, v in device.vendors && device.vendors[v].is_compliant_device
)

Cet exemple utilise les attributs device pour s'assurer que les appareils exécutent une version sécurisée d'Android.

Le démarrage validé vérifie si le code exécuté provient d'une source fiable (généralement les OEM des appareils) et non d'un pirate informatique ou d'une corruption. Pour en savoir plus, consultez Démarrage validé.

// Exiger l'état de démarrage validé Android vert device.android_device_security.verified_boot == true

Cet exemple utilise les attributs device pour exiger que les appareils réussissent les contrôles de conformité Compatibility Test Suite (CTS). Pour en savoir plus, consultez Compatibility Test Suite.

// Exiger que les appareils réussissent les contrôles de conformité CTS
device.android_device_security.cts_profile_match == true

Cet exemple utilise les attributs device pour exiger que la fonctionnalité Vérifier les applications de Google Play Protect soit activée sur les appareils.

Le paramètre "Vérifier les applications" permet d'analyser les applications qui sont installées à partir de sources autres que Google Play afin de s'assurer de l'absence de menaces. Il analyse également régulièrement les appareils à la recherche d'applications potentiellement dangereuses. La fonctionnalité Vérifier les applications est activée par défaut. Pour les appareils gérés en mode avancé, vous pouvez indiquer si les utilisateurs peuvent le désactiver. Pour en savoir plus, consultez Appliquer les paramètres concernant les appareils mobiles Android.

// Exiger que la fonctionnalité Vérifier les applications de Google Play Protect soit activée sur les appareils
device.android_device_security.verify_apps_enabled == true

Cet exemple utilise les attributs device pour refuser l'accès aux appareils comportant des applis potentiellement dangereuses. Ces applications sont souvent appelées "logiciels malveillants". Pour en savoir plus, consultez Applications potentiellement dangereuses (PHA).

// Refuser l'accès aux appareils comportant des applications potentiellement dangereusesandroid_device_security.has_potentially_harmful_apps != true

Les entreprises souhaitent s'assurer que leurs travailleurs postés ne peuvent accéder aux ressources de l'entreprise que pendant leurs heures de travail. Les niveaux d'accès ci-dessous utilisent l'attribut levels pour définir trois périodes de travail entre le lundi et le vendredi.

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

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

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

// Autoriser les travailleurs postés à accéder aux ressources du lundi au vendredi, de 9h à 17h, sauf le 4 juillet.
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')

Les entreprises souhaitent parfois autoriser un accès d'urgence (dit "bris de glace") lorsque l'administrateur n'a pas accès à un appareil sécurisé mais a besoin d'un accès d'urgence sur une courte période.

Dans ce cas, créez un niveau d'accès avec contraintes de temps et d'emplacement à l'aide de l'attribut levels, puis attribuez-le à l'administrateur concerné. Lorsque ce type de niveau d'accès est attribué, il n'est valide que pendant la période spécifiée. Une fois la période écoulée, l'accès de l'administrateur est à nouveau contrôlé par les exigences existantes.

// Autoriser un accès temporaire aux ressources le 1er mars 2022 entre 22h et minuit,
// cet accès devant provenir des États-Unis.
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. Autre option :
// !between('00:00:01','16:00:00')

Ce niveau d'accès s'appuie sur les attributs levels et exige que les utilisateurs remplissent les conditions combinées de deux niveaux d'accès. Dans cet exemple, access_level_name_1 et access_level_name_2 font référence à un nom interne.

levels.access_level_name_1 && levels.access_level_name_2