Cette page a été traduite par l'API Cloud Translation.

Bonnes pratiques pour sécuriser les applications et les ressources à l'aide de l'accès contextuel

Last reviewed 2025-07-22 UTC

Ce document décrit les bonnes pratiques recommandées pour utiliser l'accès contextuel afin de protéger efficacement vos ressources Google Cloud . L'accès contextuel est une approche de sécurité qui vous permet de contrôler l'accès des utilisateurs en fonction de la robustesse de leur authentification, de l'état de sécurité de leur appareil, de l'emplacement sur le réseau, de leur emplacement géographique ou d'autres attributs. Cette approche va au-delà de l'utilisation d'identités utilisateur de base pour l'accès à la sécurité. Elle peut vous aider à implémenter un modèle de sécurité zéro confiance pour améliorer votre stratégie de sécurité globale. Pour savoir comment implémenter l'accès contextuel pour différents types d'applications et de ressources, consultez Sécuriser les applications et les ressources à l'aide de l'accès contextuel.

Pour sécuriser vos applications et vos ressources Google Cloud , vous pouvez définir un contrôle d'accès précis, basé sur une variété et une combinaison de facteurs contextuels. Vous pouvez utiliser Access Context Manager pour définir des règles d'accès, qui contiennent des niveaux d'accès et des paramètres de service.

Ce document s'adresse à tous les professionnels de la sécurité responsables de la gestion des identités et des accès (IAM) et de la sécurité des ressources et des applications Google Cloud . Ce document part du principe que vous connaissez déjà Access Context Manager,Google Cloudet la gestion IAM.

Approches d'accès contextuel

Lorsque vous configurez l'accès contextuel dans votre organisation, vous devez décider si vous souhaitez appliquer des contrôles d'accès contextuel aux applications, aux ressources ou aux deux. Pour prendre cette décision, il est utile de faire la distinction entre les différents types d'applications et de services suivants :

Applications administratives : ces applications permettent aux utilisateurs de gérer ou d'interagir avec des ressourcesGoogle Cloud , telles que des instances de VM, des ensembles de données BigQuery ou des buckets Cloud Storage. Parmi les exemples d'applications d'administration, on trouve la console Google Cloud , Google Cloud CLI, Terraform et IAP Desktop.
Applications métier : ces applications incluent les applications Web qui s'exécutent surGoogle Cloud et utilisent SAML ou Identity-Aware Proxy (IAP) pour l'authentification et l'autorisation. Ces applications sont parfois appelées applications internes. Les applications métier incluent, par exemple, les systèmes CRM, les tableaux de bord et d'autres applications personnalisées.
Google Workspace et autres services Google : ces services sont fournis par Google, mais ne sont pas liés à Google Cloud.

Vous pouvez distinguer plus précisément les applications métier en fonction de la façon dont elles gèrent l'authentification et l'autorisation :

SAML : applications qui utilisent Google Workspace SAML pour l'authentification. Les applications SaaS appartiennent souvent à cette catégorie.
IAP : applications Web personnalisées que vous avez déployées derrière IAP.
OAuth : applications Web ou de bureau personnalisées qui utilisent OAuth 2.0 et un ou plusieurs Google Cloud scopes OAuth.

Le diagramme de flux suivant indique l'approche d'accès contextuel la plus adaptée à chaque type d'application :

Arbre de décision pour les approches d'accès contextuel pour chaque type d'application.

Le schéma montre les types d'applications suivants :

Applications administratives : en général, il est plus important de protéger les ressourcesGoogle Cloud auxquelles l'application administrative facilite l'accès que l'application elle-même. Étudions les cas de figure suivants :
- Un utilisateur ne peut accéder à aucune ressource. Dans ce cas, il est probable que l'accès à une application administrative ne soit pas aussi utile à l'utilisateur.
- Un utilisateur a accès à une ressource, mais pas à une application administrative. Dans ce cas, il peut peut-être trouver une autre application administrative qui n'est pas bloquée et qui lui permet d'accéder à la ressource.
Par conséquent, pour les applications administratives, adoptez une approche centrée sur les ressources. Pour appliquer les contrôles d'accès contextuels appropriés aux ressources de la manière la plus efficace possible, utilisez les périmètres de service de cloud privé virtuel (VPC) avec les règles d'entrée appropriées. Vous pouvez compléter les périmètres de service VPC avec des liaisons d'accès.
Applications métier utilisant OAuth : pour ces applications, il est important de protéger l'accès aux applications elles-mêmes, ainsi qu'aux ressources qu'elles peuvent utiliser. Pour protéger les applications à l'aide de l'accès contextuel, utilisez des liaisons d'accès.
Applications métier utilisant IAP : bien qu'IAP utilise OAuth, vous ne pouvez pas utiliser de liaisons d'accès pour protéger les applications qui utilisent IAP pour authentifier les utilisateurs. Protégez plutôt ces applications à l'aide de conditions IAM.
Applications métier utilisant SAML : comme pour les applications métier utilisant OAuth, il est important de protéger l'accès aux applications elles-mêmes, ainsi qu'aux ressources qu'elles peuvent utiliser. Pour protéger ces applications, utilisez l'accès contextuel Google Workspace.
Google Workspace et autres services Google : pour ces applications, il est important de protéger l'accès aux applications elles-mêmes, ainsi qu'aux ressources qu'elles peuvent utiliser. Pour protéger ces applications, utilisez l'accès contextuel Google Workspace.

Gestion des niveaux d'accès

Les sections suivantes décrivent les pratiques recommandées à suivre lorsque vous gérez les niveaux d'accès.

Créer des niveaux d'accès réutilisables

Les niveaux d'accès sont une ressource globale et sont destinés à être utilisés dans les ressources de votre organisation Google Cloud . Il est donc préférable de limiter le nombre total de niveaux d'accès et de les rendre pertinents et applicables à plusieurs ressources. Réfléchissez aux éléments suivants :

Évitez d'intégrer les noms de ressources ou d'applications spécifiques dans le nom d'un niveau d'accès.
Évitez d'encoder des exigences spécifiques à une ressource ou à une application dans un niveau d'accès.
Utilisez des noms qui affirment une certaine posture de l'utilisateur ou de l'appareil, comme Fully Trusted Device.

Utiliser des niveaux d'accès composites

Pour réduire les frais généraux de maintenance et assurer la cohérence lorsque les sous-réseaux ou les régions changent, ne répétez pas les mêmes exigences dans plusieurs niveaux d'accès. Au lieu de cela, faites en sorte que les niveaux d'accès dépendent les uns des autres.

Par exemple, ne listez pas les mêmes régions ou sous-réseaux IP de confiance dans plusieurs niveaux d'accès. Créez plutôt un niveau d'accès supplémentaire appelé Trusted location. Ce niveau Trusted location peut servir de dépendance pour les autres niveaux d'accès.

Exempter les utilisateurs ayant un accès d'urgence dans les niveaux d'accès

Pour éviter un verrouillage accidentel, il est préférable d'exclure au moins un utilisateur ayant un accès d'urgence de tous les niveaux d'accès. Pour vous assurer que l'exemption s'applique à toutes les applications et ressources auxquelles vous appliquez le niveau d'accès, configurez l'exemption dans le niveau d'accès lui-même :

Ajoutez une condition qui définit vos exigences habituelles.
Ajoutez une autre condition avec une exigence members qui liste un ou plusieurs de vos utilisateurs ayant accès en cas d'urgence.
Définissez la fonction de combinaison sur une condition OR afin que les utilisateurs n'aient besoin de remplir qu'une seule des deux conditions.

Par exemple, le niveau d'accès suivant limite l'accès à trois régions, mais l'utilisateur emergencyaccess@example.net est exempté de cette exigence :

{
  "name": "accessPolicies/…",
  "title": "Example access level",
  "basic": {
    "conditions": [
      {
        "members": [
          "user:emergencyaccess@example.net"
        ]
      },
      {
        "regions": [
          "DE",
          "AU",
          "SG"
        ]
      }
    ],
    "combiningFunction": "OR"
  }
}

Configurer un message de résolution

Les utilisateurs de votre organisation ne savent peut-être pas que leur position, leur appareil et d'autres facteurs peuvent avoir une incidence sur leur capacité à accéder à certaines applications. Pour tenir les utilisateurs informés et réduire les demandes d'assistance, configurez un message de résolution personnalisé qui indique aux utilisateurs les étapes à suivre pour retrouver l'accès.

Gestion des liaisons d'accès

Les liaisons d'accès vous permettent de configurer l'accès contextuel pour les applications OAuth qui utilisent un ou plusieurs Google Cloud scopes. Les liaisons d'accès sont également un moyen efficace d'appliquer un accès contextuel aux applications métier.

Les sections suivantes décrivent les pratiques recommandées à suivre lorsque vous utilisez des liaisons d'accès.

Utiliser une seule association d'accès avec des paramètres limités

Lorsque vous utilisez des liaisons d'accès, vous devez tenir compte des contraintes suivantes :

Chaque groupe Cloud Identity ne peut comporter qu'une seule liaison d'accès.
Si plusieurs liaisons d'accès s'appliquent à un utilisateur, la liaison d'accès la moins restrictive prévaut.

Pour tenir compte de ces deux contraintes, utilisez une seule liaison d'accès qui s'applique à tous vos utilisateurs :

Créez un groupe qui contient automatiquement tous les utilisateurs de votre compte Cloud Identity ou Google Workspace.
Créez ou utilisez une liaison d'accès qui associe un niveau d'accès par défaut au groupe. Le niveau d'accès par défaut devrait convenir à la plupart des utilisateurs, appareils et applications.
Si nécessaire, utilisez les paramètres d'accès limité (scopedAccessSettings) pour attribuer des niveaux d'accès plus faibles à certaines applications.

Utiliser un niveau d'accès par défaut strict

Si une liaison d'accès spécifie à la fois un paramètre d'accès limité et un niveau d'accès par défaut, les deux niveaux d'accès sont combinés à l'aide de la sémantique OR. Ce comportement a les implications suivantes :

Un utilisateur n'a besoin de remplir les conditions que d'un seul niveau d'accès pour accéder à l'application OAuth.
Lorsque vous ajoutez un paramètre d'accès limité pour une application OAuth, vous pouvez abaisser les exigences d'accès effectives.
Un paramètre d'accès limité n'a aucun effet s'il utilise un niveau d'accès plus strict que le niveau d'accès par défaut de la liaison d'accès.

Lorsque vous sélectionnez un niveau d'accès par défaut pour une liaison d'accès, nous vous recommandons de procéder comme suit :

Utilisez un niveau d'accès strict comme niveau d'accès par défaut.
Appliquez des niveaux d'accès inférieurs à des applications OAuth individuelles à l'aide de paramètres d'accès limités.

Vous pouvez ajouter tout ou partie des restrictions suivantes au niveau d'accès par défaut :

Restrictions concernant les navigateurs et les appareils : exigez que vos utilisateurs accèdent aux applications à l'aide d'un navigateur Chrome géré et d'un appareil approuvé par l'administrateur.
Restrictions géographiques : si votre organisation opère exclusivement dans certaines régions, utilisez les restrictions régionales pour n'inclure que ces régions dans la liste d'autorisation. Sinon, vous pouvez utiliser des restrictions régionales pour limiter l'accès aux zones géographiques qui font l'objet de sanctions ou qui ne sont pas pertinentes pour d'autres raisons.
Restrictions liées au réseau IP : si les utilisateurs de votre organisation accèdent àGoogle Cloud exclusivement à partir de certains réseaux, ou si votre organisation utilise un proxy de sortie commun, vous pouvez inclure des restrictions liées au réseau IP.

N'utilisez pas de niveaux d'accès nécessitant une authentification basée sur les certificats comme niveau d'accès par défaut. L'authentification basée sur un certificat est la mieux adaptée aux règles d'entrée des périmètres de service VPC.

Gérer les exceptions par application

Pour gérer les exceptions au niveau d'accès par défaut, ajoutez des exceptions pour des applications individuelles, plutôt que pour des utilisateurs ou des groupes.

Un niveau d'accès par défaut strict peut convenir à la plupart des applications, mais pas à toutes :

Certaines applications peuvent être moins sensibles et vous devez les rendre accessibles aux utilisateurs qui ne remplissent pas le niveau d'accès par défaut. Par exemple, les applications qui doivent être accessibles aux partenaires, aux invités ou aux anciens élèves.
Il est possible que certaines applications soient techniquement incompatibles avec l'une des restrictions appliquées par le niveau d'accès par défaut.

Pour exempter des applications individuelles du niveau d'accès par défaut, utilisez les paramètres d'accès limité. Pour chaque application concernée, ajoutez un paramètre limité et attribuez un niveau d'accès plus approprié à l'application concernée.

Ne créez pas de liaisons d'accès supplémentaires pour gérer les exceptions par utilisateur ou par groupe. Des liaisons d'accès supplémentaires peuvent entraîner les problèmes suivants :

Vous pouvez créer par inadvertance des bindings d'accès qui se chevauchent.
Il peut devenir difficile de déterminer quelles exigences d'accès contextuel sont appliquées efficacement pour chaque application.

Éviter les liaisons d'accès qui se chevauchent

Les liaisons d'accès sont associées à des groupes. Si un utilisateur est membre de plusieurs groupes, plusieurs liaisons d'accès peuvent s'appliquer à lui. Dans ce cas, les exigences d'accès contextuel de ces liaisons d'accès sont combinées à l'aide de la sémantique OR.

Ce comportement peut entraîner des effets indésirables. Par exemple, si les utilisateurs sont autorisés à rejoindre d'autres groupes, la protection de certaines applications peut être compromise.

Pour éviter de telles situations, nous vous recommandons d'éviter les liaisons d'accès qui se chevauchent :

Minimisez le nombre de liaisons d'accès, idéalement à une seule.
Si vous avez besoin de plusieurs liaisons d'accès, attribuez-les à des groupes mutuellement exclusifs.

Protéger les groupes contre les modifications non autorisées

Par défaut, Cloud Identity permet aux membres d'un groupe de le quitter. Ce comportement est approprié pour les groupes d'accès, mais il pose problème pour les groupes associés à des liaisons d'accès. Si un utilisateur quitte un groupe associé à une liaison d'accès, il n'est plus soumis aux exigences d'accès contextuel imposées par les liaisons d'accès. Les utilisateurs peuvent donc contourner les exigences d'accès contextuel en quittant un groupe.

Utilisez toujours des groupes d'application et n'autorisez pas les utilisateurs à quitter un groupe d'application lorsque vous configurez des liaisons d'accès. Vous pouvez également créer un groupe qui contient automatiquement tous les utilisateurs de votre compte Cloud Identity ou Google Workspace.

Ne pas autoriser l'accès aux utilisateurs externes lorsque vous utilisez des liaisons d'accès

Les liaisons d'accès n'affectent que les utilisateurs du compte Cloud Identity ou Google Workspace auquel appartient votre organisation Google Cloud . Ces utilisateurs restent soumis aux liaisons d'accès dans votre organisationGoogle Cloud s'ils tentent d'accéder à des ressources dans d'autres organisationsGoogle Cloud . Cette application des liaisons d'accès aux utilisateurs diffère du comportement dans d'autres contextes avec Cloud Identity.

Si vous autorisez les utilisateurs de comptes Cloud Identity ou Google Workspace externes à accéder aux ressources de vos organisations Google Cloud, vos liaisons d'accès n'ont aucun effet sur ces utilisateurs.

Pour vous assurer que vos liaisons d'accès sont efficaces, n'accordez pas aux utilisateurs externes l'accès aux applications ni aux ressources de votre organisation Google Cloud . De plus, n'ajoutez pas d'utilisateurs externes aux groupes de votre compte Cloud Identity ou Google Workspace.

Utiliser des liaisons d'accès distinctes pour contrôler la durée des sessions

En plus du contrôle des accès contextuel, vous pouvez également utiliser des liaisons d'accès pour gérer la durée des sessions de navigateur et des jetons OAuth.

Lorsque vous utilisez des liaisons d'accès pour contrôler l'accès contextuel, il est préférable d'éviter les liaisons d'accès qui se chevauchent.

Lorsque vous utilisez des liaisons d'accès pour contrôler la durée des sessions, ne créez pas de liaisons d'accès qui se chevauchent. Si plusieurs liaisons d'accès de ce type s'appliquent à un utilisateur, seule la dernière liaison d'accès mise à jour prend effet, ce qui peut entraîner des résultats inattendus.

Pour éviter de tels résultats indésirables, utilisez une liaison d'accès distincte pour contrôler la durée de la session.

Ne pas autoriser les utilisateurs à agir en tant que compte de service

Les liaisons d'accès s'appliquent aux utilisateurs Cloud Identity et Google Workspace, mais pas aux comptes de service. Si vous autorisez les utilisateurs à s'authentifier et à agir en tant que compte de service, ils pourront peut-être contourner vos contrôles d'accès contextuels.

D'autres risques sont impliqués lorsque les utilisateurs peuvent agir en tant que compte de service. Si vous souhaitez autoriser les utilisateurs à élever temporairement leurs privilèges, nous vous recommandons d'utiliser Privileged Access Manager. N'utilisez pas l'emprunt d'identité de compte de service, sauf à des fins de développement.

Pour savoir comment sécuriser les comptes de service et les clés de compte de service, consultez les pages Bonnes pratiques pour utiliser les comptes de service et Bonnes pratiques pour gérer les clés de compte de service.

Règles d'entrée pour les périmètres de service VPC

Les règles d'entrée vous permettent d'accorder un accès contextuel depuis l'extérieur du périmètre de service aux ressources situées à l'intérieur du périmètre. Les périmètres de service VPC et les règles d'entrée protègent les ressources Google Cloud , et non les applications individuelles. Par conséquent, un périmètre de service avec des règles d'entrée est idéal pour appliquer un accès contextuel aux outils d'administration tels que la console Google Cloud et gcloud CLI.

Pour en savoir plus et découvrir les bonnes pratiques concernant les périmètres de service VPC, consultez Bonnes pratiques pour activer VPC Service Controls.

Les sections suivantes décrivent les pratiques recommandées lorsque vous utilisez des règles d'entrée pour appliquer l'accès contextuel.

Inclure IAP pour le transfert TCP en tant que service restreint

Il peut être risqué d'autoriser les utilisateurs à se connecter aux instances de VM dans votre périmètre de service à l'aide de SSH ou RDP pour les raisons suivantes :

Vos règles d'entrée ne s'appliquent pas aux connexions, car l'utilisation de SSH et RDP n'implique aucun accès aux API Google.
Une fois qu'un utilisateur a établi une session SSH ou RDP, tout accès à l'API initié à partir de cette session est considéré comme provenant du périmètre de service. Par conséquent, vos règles d'entrée ne s'appliquent à aucun accès à l'API initié au cours de cette session.

Pour limiter ces risques, autorisez l'accès SSH et RDP aux VM uniquement via le transfert TCP d'IAP :

Incluez le service iaptunnel.googleapis.com en tant que service restreint.
Configurez des règles de pare-feu qui restreignent l'accès aux ports SSH et RDP via le transfert TCP IAP.

Utilisez le transfert TCP IAP pour vous assurer que la configuration des règles d'entrée de votre périmètre de service VPC s'applique à chaque tentative d'accès SSH et RDP.

Utiliser un accès basé sur des certificats pour les périmètres de service sensibles

Par défaut, les jetons d'accès et d'actualisation Google ne sont pas liés à un appareil et peuvent être vulnérables au vol ou aux attaques par relecture. Pour limiter ces risques, vous pouvez utiliser l'accès basé sur les certificats (CBA), qui restreint l'accès aux appareils possédant un certificat X.509 approuvé.

L'authentification basée sur les identifiants client vous aide à renforcer la sécurité, mais cette approche ajoute également des exigences d'infrastructure supplémentaires :

L'appareil d'un utilisateur doit disposer d'un certificat X.509 émis par une autorité de certification interne.
La clé associée au certificat doit être stockée de manière à empêcher toute exportation non autorisée.
Les applications clientes doivent utiliser l'authentification TLS mutuelle (mTLS) pour se connecter aux APIGoogle Cloud .

Utilisez l'authentification basée sur les certificats pour protéger l'accès à vos périmètres de service VPC les plus sensibles. Cette approche vous permet d'équilibrer la robustesse de la sécurité avec des exigences d'infrastructure minimales et un impact global.

Contributeurs

Auteur : Johannes Passing | Architecte de solutions cloud

Autre contributeur : Ido Flatow | Architecte de solutions cloud

Bonnes pratiques pour sécuriser les applications et les ressources à l'aide de l'accès contextuel Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.