Cet article décrit les cas d'utilisation de l'accès contextuel qui comportent des règles faisant appel à des niveaux d'accès personnalisés. Dans ces exemples, vous créez des niveaux d'accès personnalisés en mode avancé à l'aide du langage CEL (Common Expression Language).
Notez que, si vous préférez, vous pouvez également utiliser des fonctions et des macros lorsque vous créez des niveaux d'accès personnalisés à l'aide d'expressions CEL.
Pour obtenir des exemples de niveaux d'accès développés en mode de base (via l'interface d'accès contextuel), consultez Cas d'utilisation de l'accès contextuel en mode de base.
Exemples concernant l'authentification
Ouvrir la section | Tout réduire
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 == trueLes 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.
// Exiger une MFA de base (sauf par SMS) sur les appareils de l'entreprise, et une clé de sécurité (matérielle ou logicielle) sur les autres
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
)
)
)
Exemples concernant les appareils
Ouvrir la section | Tout réduire et revenir en haut de la page
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).
device.vendors["Lookout"].is_compliant_device == true && device.vendors["Lookout"].device_health_score == DeviceHealthScore.VERY_GOODCe 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.
device.chrome.management_state == ChromeManagementState.CHROME_MANAGEMENT_STATE_BROWSER_MANAGED && device.chrome.versionAtLeast("94.0.4606.81") 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.
| Attribut | Description | Exemple d'expression de prédicat (pour laquelle cert est un identifiant de macros) |
|---|---|---|
| is_valid |
Définie sur "true" si le certificat est valide et s'il n'a pas expiré. |
cert.is_valid |
| cert_fingerprint | Empreinte du certificat (SHA256 sans remplissage base64) |
cert.cert_fingerprint == origin. |
| root_ca_fingerprint | Empreinte du certificat CA racine qui permet de signer ce certificat (SHA256 sans remplissage base64) |
cert.root_ca_fingerprint == "the_fingerprint" |
| issuer |
Nom de l'émetteur Pour trouver le nom de l'émetteur, exécutez la commande suivante sur le certificat :
La chaîne d'émetteur utilisée dans le niveau d'accès correspond à l'inverse de la sortie. De plus, la barre oblique "/" est remplacée par une virgule, par exemple :
|
cert.issuer == "EMAILADDRESS=test_inter1 |
| subject | Nom de l'objet du certificat (noms entiers) |
cert.subject == "CA_SUB" |
| serial_number |
Numéro de série du certificat |
cert.serial_number == “123456789” |
| template_id | ID du modèle de l'extension X.509 du certificat (chaîne) |
cert.template_id == "1.3.6.1.4.1.311.21. |
Exemples de règles communément 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.
// Exiger que le chiffrement du disque et le verrouillage de l'écran soient activés
// S'applique à toutes les grandes plates-formes (Windows, Mac, Linux, CrOS, iOS, Android)
// Ce principe de base doit être repris par tous les autres niveaux d'accès
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.
// Exiger que Chrome soit géré au niveau du profil ou du navigateur, que les
// rapports sur les événements liés à la sécurité soient activés, et que la version soit au moins 97
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.
// Exiger que Chrome soit géré (dépend du niveau d'accès "Require_Managed_Chrome")
// et exiger l'activation de l'inspection du contenu pour les téléchargements et de la vérification des URL
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 valide émis par l'entreprise
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 digest 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) (qui semble être deux semaines après le code temporel d'émission dans la version actuelle)
Le niveau d'accès utilise l'attribut device pour s'assurer que les données CrowdStrike sont récentes. Notez que BeyondCorp Enterprise 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 le dernier code temporel d'émission)
“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 collabore avec de nombreux partenaires de l'écosystème BeyondCorp Alliance pour intégrer les signaux et le contexte de leurs appareils à la solution BeyondCorp Enterprise. Les partenaires peuvent partager autant d'attributs qu'ils le souhaitent avec BeyondCorp, et l'un d'entre eux est l'attribut is_compliance_device. L'exemple ci-dessous utilise l'attribut device pour montrer comment vérifier si l'un des partenaires BeyondCorp Alliance a intégré BeyondCorp Enterprise 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érifier si l'un des partenaires BCA considère que l'appareil est 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 dangereuses android_device_security.has_potentially_harmful_apps != true
Exemples d'accès basé sur l'heure
Ouvrir la section | Tout réduire et revenir en haut de la page
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.
// Période 1 - Du lundi au vendredi, de minuit à 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')
// Période 2 - Du lundi au vendredi, de 8h à 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')
// Période 3 - Du lundi au vendredi, de 16h à minuit
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”
// Notez que l'heure de fin est exclue, ce qui signifie que pour les horaires ci-dessus, les utilisateurs
// peuvent ne pas disposer de l'accès pendant deux secondes. Autre option
// !between(‘00:00:01’,’16:00:00’)
Exemple en combinant les conditions de deux niveaux
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
