Cet article décrit les cas d'utilisation courants de l'accès contextuel et propose des exemples de configurations développées en mode de base.
Pour obtenir des exemples de niveaux d'accès développés en mode avancé (à l'aide de l'éditeur CEL), consultez Cas d'utilisation de l'accès contextuel en mode avancé.
Autoriser l'accès pour les prestataires uniquement via le réseau de l'entreprise
De nombreuses entreprises souhaitent limiter l'accès des prestataires aux ressources de l'entreprise. C'est par exemple le cas des entreprises qui recourent à des prestataires pour répondre à des appels d'assistance d'ordre général, ou qui travaillent dans des centres d'assistance et des centres d'appel. Tout comme les employés à plein temps, les prestataires doivent disposer d'une licence compatible pour que les règles d'accès contextuel leur soient applicables.
Dans cet exemple, l'accès des prestataires n'est autorisé qu'à partir d'une plage d'adresses IP d'entreprise spécifique.
| Nom du niveau d'accès | contractor_access |
| L'accès d'un sous-traitant est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 | Sous-réseau IP (public) 74.125.192.0/18 |
| Attribution du niveau d'accès | Unités organisationnelles pour les prestataires Toutes les applications utilisées par les prestataires |
Bloquer l'accès à partir d'adresses IP pirate connues
Pour éviter que la sécurité des ressources de l'entreprise ne soit compromise, de nombreuses entreprises bloquent l'accès aux sources risquées connues.
Dans cet exemple, l'adresse IP 74.125.195.105 est bloquée. L'accès des utilisateurs aux ressources de l'entreprise est autorisé si leurs sessions proviennent d'une autre adresse IP. Vous pouvez spécifier plusieurs adresses et plages d'adresses IP.
| Nom du niveau d'accès | block_highrisk |
| L'accès d'un utilisateur est autorisé lorsque | Les conditions des attributs ne sont pas remplies |
| Attribut de la condition 1 | Sous-réseau IP (public) 74.125.195.105 |
| Attribution du niveau d'accès | Unité organisationnelle racine Toutes les applications |
Autoriser l'accès depuis un réseau privé spécifique dans Google Cloud
De nombreuses entreprises acheminent le trafic utilisateur vers Google via un cloud privé virtuel (VPC). Un VPC est un réseau sécurisé et isolé dans l'environnement Google Cloud.
Sachez que le trafic acheminé via votre VPC peut utiliser des adresses IP privées. Cela peut entraîner des problèmes avec les adresses IP publiques ou les règles régionales.
Dans cet exemple, vous pouvez autoriser le trafic provenant de ces VPC spécifiques.
| Nom du niveau d'accès | vpc_access |
| L'accès d'un utilisateur est autorisé lorsque... | remplissent les conditions des attributs |
| Attributs de la condition 1 |
Sous-réseau IP (privé) Sous-réseau IP privé : //compute.googleapis.com/projects/project- name-test/global/networks/network-name Sous-réseau VPC : 74.125.192.0/18 |
| Attribution du niveau d'accès |
Unités organisationnelles pour tous les utilisateurs Toutes les applications utilisées par les prestataires |
Points importants à retenir :
- Trafic direct uniquement : ce niveau d'accès ne fonctionne que pour le trafic qui atteint directement les serveurs de Google depuis le VPC autorisé. Si le trafic transite d'abord par un autre réseau ou tunnel, l'accès n'est pas accordé. Google ne reconnaît que le dernier VPC qui envoie le trafic à ses serveurs.
- Autorisations d'administrateur : pour afficher les VPC et configurer ce niveau d'accès, les administrateurs doivent disposer du rôle Identity and Access Management (IAM) approprié (par exemple, compute.networks.list, compute.subnetworks.list, etc.).
- VPC externes : le VPC que vous ajoutez à la liste d'autorisation peut provenir d'un domaine Google Cloud autre que celui que vous utilisez actuellement. Un administrateur doit disposer des droits d'affichage pour ajouter le VPC externe.
Autoriser ou interdire l'accès depuis des zones spécifiques
Si certains de vos collaborateurs se rendent régulièrement dans des bureaux de l'entreprise ou de partenaires lors de déplacements, vous pouvez indiquer les zones géographiques depuis lesquelles ils peuvent accéder aux ressources de l'entreprise.
Par exemple, si l'équipe commerciale se rend régulièrement chez des clients en Australie et en Inde, vous pouvez n'autoriser l'accès du groupe que depuis le pays de l'entreprise qui les emploie, l'Australie et l'Inde. Si, dans le cadre d'un voyage d'affaires, ces collaborateurs se rendent dans d'autres pays pour des vacances personnelles, ils ne peuvent pas accéder aux ressources d'entreprise depuis ces autres pays.
Dans cet exemple, l'équipe commerciale ne peut accéder aux ressources de l'entreprise qu'aux États-Unis (pays de l'entreprise qui les emploie), en Australie et en Inde.
| Nom du niveau d'accès | sales_access |
| L'accès d'un commercial est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 | Origine géographique Australie, États-Unis, Inde |
| Attribution du niveau d'accès | Équipe commerciale Toutes les applications utilisées par l'équipe |
Vous pouvez également créer une règle permettant d'interdire l'accès depuis certains pays en spécifiant que l'accès des utilisateurs est autorisé s'ils ne répondent pas aux conditions définies. Vous devez pour cela répertorier les pays dont vous souhaitez bloquer l'accès.
Utiliser des niveaux d'accès imbriqués plutôt que d'attribuer plusieurs niveaux d'accès
Dans certains cas, lorsque vous essayez d'attribuer des niveaux d'accès à une ou plusieurs applications pour une unité organisationnelle ou un groupe, vous pouvez être invité à réduire le nombre d'applications ou de niveaux d'accès.
Pour éviter cette erreur, vous pouvez réduire le nombre de niveaux d'accès utilisés pour l'attribution en les imbriquant dans un niveau d'accès unique. Le niveau d'accès imbriqué associe plusieurs conditions avec un opérateur "OR", chaque condition contenant un niveau d'accès individuel.
Dans cet exemple, USWest, USEast et USCentral sont répartis en trois niveaux d'accès distincts. Imaginons que les utilisateurs doivent pouvoir accéder aux applications s'ils possèdent le niveau d'accès USWest OU USEast OU USCentral.Vous pouvez alors créer un niveau d'accès imbriqué unique (USRegions) à l'aide de l'opérateur "OR". Au moment d'attribuer les niveaux d'accès, attribuez USRegions à l'application pour l'unité organisationnelle ou le groupe concerné.
|
Nom du niveau d'accès |
USRegions |
|
L'accès d'un utilisateur est autorisé lorsque |
remplissent les conditions des attributs |
|
Attribut de la condition 1 (un seul niveau d'accès par condition) |
Niveau d'accès USWest |
|
Conditions 1 et 2 associées à l'aide de |
OU |
|
L'accès d'un utilisateur est autorisé lorsque |
remplissent les conditions des attributs |
|
Attribut de la condition 2 |
Niveau d'accès USEast |
|
Conditions 2 et 3 associées à l'aide de |
OU |
|
L'accès d'un utilisateur est autorisé lorsque |
remplissent les conditions des attributs |
|
Attribut de la condition 3 |
Niveau d'accès USCentral |
Exiger la détention par l'entreprise pour les ordinateurs, mais pas pour les appareils mobiles
Une entreprise peut exiger l'utilisation d'un ordinateur de bureau qu'elle détient, mais exclure les appareils mobiles.
Pour commencer, créez un niveau d'accès pour les appareils de bureau :
|
Nom du niveau d'accès |
aldesktop_access |
|
L'accès des utilisateurs est autorisé lorsque |
remplissent les conditions des attributs |
|
Attribut de la condition 1 |
Règles relatives aux appareils
Chiffrement de l'appareil : non compatible OS de l'appareil macOS : 0.0.0 Windows : 0.0.0 Système d'exploitation Linux : 0.0.0 ChromeOS : 0.0.0 |
Ensuite, créez un niveau d'accès pour les appareils mobiles :
|
Nom du niveau d'accès |
almobile_access |
|
L'accès des utilisateurs est autorisé lorsque |
remplissent les conditions des attributs |
|
Attribut de la condition 1 |
OS de l'appareil iOS : 0.0.0 Android : 0.0.0 |
Exiger des conditions minimales de sécurité pour les appareils
La plupart des grandes entreprises exigent désormais que les collaborateurs accèdent aux ressources de l'entreprise par le biais d'appareils chiffrés qui exécutent la version minimale requise ou une version ultérieure du système d'exploitation. Certaines exigent également que les collaborateurs utilisent des appareils détenus par l'entreprise.
Vous pouvez configurer ces règles pour toutes vos unités organisationnelles, ou uniquement pour celles qui utilisent des données sensibles, comme celles réservées aux cadres, au service financier ou aux ressources humaines.
Il existe plusieurs méthodes pour configurer une règle qui inclut le chiffrement des appareils, la version minimale du système d'exploitation et les appareils détenus par l'entreprise. Chacune présente des avantages et des inconvénients.
Un niveau d'accès unique qui inclut toutes les exigences de sécurité
Dans cet exemple, les attributs concernant le chiffrement des appareils, la version minimale du système d'exploitation et les appareils détenus par l'entreprise sont inclus dans un seul niveau d'accès. Les utilisateurs doivent remplir toutes les conditions requises pour que leur accès soit autorisé.
Par exemple, si un appareil utilisateur est chiffré et est détenu par l'entreprise, mais n'exécute pas une version conforme du système d'exploitation, l'accès est refusé à l'utilisateur.
Avantage : facile à configurer. Lorsque vous attribuez ce niveau d'accès à une application, un utilisateur doit remplir toutes les conditions requises.
Inconvénient : pour attribuer séparément les exigences de sécurité à différentes unités organisationnelles, vous devez créer un niveau d'accès distinct pour chacune de ces exigences.
| Nom du niveau d'accès | device_security |
| L'accès d'un utilisateur est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 (Vous pouvez ajouter tous les attributs à une condition ou créer trois conditions et les associer à l'aide de l'opérateur AND.) |
Règles relatives aux appareils OS de l'appareil |
Trois niveaux d'accès distincts
Dans cet exemple, les attributs concernant le chiffrement des appareils, la version minimale du système d'exploitation et les appareils détenus par l'entreprise sont répartis en trois niveaux d'accès distincts. Les utilisateurs doivent remplir les conditions d'un seul niveau d'accès pour que leur accès soit autorisé. Il s'agit d'une relation "OU" logique des niveaux d'accès.
Par exemple, un utilisateur disposant d'un appareil chiffré et qui exécute une ancienne version du système d'exploitation sur un appareil personnel peut accéder aux ressources de l'entreprise.
Avantage : vous pouvez définir les niveaux d'accès de manière très précise. Vous pouvez attribuer séparément des niveaux d'accès à différentes unités organisationnelles.
Inconvénient : les utilisateurs doivent remplir les conditions d'un seul niveau d'accès.
| Nom du niveau d'accès | device_encryption |
| L'accès d'un utilisateur est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 |
Règles relatives aux appareils |
| Nom du niveau d'accès | corp_device |
| L'accès d'un utilisateur est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 |
Règles relatives aux appareils |
| Nom du niveau d'accès | min_os |
| L'accès d'un utilisateur est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 |
Règles relatives aux appareils |
Un niveau d'accès unique comportant des niveaux d'accès imbriqués
Dans cet exemple, les exigences de sécurité concernant le chiffrement des appareils, la version minimale du système d'exploitation et les appareils détenus par l'entreprise sont contenues dans trois niveaux d'accès distincts. Ces trois niveaux d'accès sont imbriqués dans un quatrième niveau d'accès.
Lorsque vous attribuez le quatrième niveau d'accès aux applications, les utilisateurs doivent remplir les conditions requises de chacun des trois niveaux d'accès imbriqués pour que leur accès soit autorisé. Il s'agit d'une relation "ET" logique des niveaux d'accès.
Par exemple, un utilisateur disposant d'un appareil chiffré et qui exécute une ancienne version du système d'exploitation sur un appareil personnel ne peut pas accéder aux ressources de l'entreprise.
Avantage : vous continuez à bénéficier de la flexibilité nécessaire pour répartir les exigences de sécurité à travers les niveaux d'accès 1, 2 et 3. Avec le niveau d'accès 4, vous pouvez également appliquer une règle contenant l'ensemble des exigences de sécurité.
Inconvénient : le journal d'audit capture uniquement les accès refusés au niveau d'accès 4 (et non aux niveaux 1, 2 et 3), car les niveaux d'accès 1, 2 et 3 ne sont pas directement attribués à des applications.
Créez trois niveaux d'accès tel que décrit dans la section "Trois niveaux d'accès distincts" ci-dessus : "device_encryption", "corp_device" et "min_os". Créez ensuite un quatrième niveau d'accès, "device_security", comportant trois conditions. Chacune d'entre elles est associée à un niveau d'accès. (Vous ne pouvez ajouter qu'un seul attribut de niveau d'accès par condition.)
| Nom du niveau d'accès | device_security |
| L'accès d'un utilisateur est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 (un seul niveau d'accès par condition) |
Niveau d'accès device_encryption |
| Conditions 1 et 2 associées à l'aide de | ET |
| L'accès d'un utilisateur est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 | Niveau d'accès corp_device |
| Conditions 2 et 3 associées à l'aide de | ET |
| L'accès d'un utilisateur est autorisé lorsque | remplissent les conditions des attributs |
| Attribut de la condition 1 | Niveau d'accès min_os |
Informations connexes
- Présentation de l'accès contextuel
- Configurer des logiciels et créer des niveaux d'accès contextuel
- Attribuer des niveaux d'accès contextuel aux applications
- Personnaliser l'accès contextuel à l'aide de groupes
- Cas d'utilisation de l'accès contextuel en mode avancé
- Journal d'audit de l'accès contextuel