Ce document décrit les bonnes pratiques recommandées pour utiliser l'accès contextuel afin de protéger efficacement vos Google Cloud ressources. 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 la posture de leur appareil, de leur emplacement 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 sécurisé. Elle peut vous aider à mettre en œuvre un modèle de sécurité zéro confiance afin d'améliorer votre stratégie de sécurité globale. Pour savoir comment mettre en œuvre 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 Google Cloud ressources, vous pouvez définir contrôle des 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 est destiné à tout professionnel de la sécurité responsable de Identity and Access Management (IAM) et de la sécurité des Google Cloud ressources et des applications. Dans ce document, nous partons du principe que vous connaissez déjà Access Context Manager, Google Cloud, et 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 distinguer les différents types d'applications et de services suivants :
- Applications administratives : ces applications permettent aux utilisateurs de gérer des ressources telles que des instances de VM, des ensembles de données BigQuery ou des buckets Cloud Storage, ou d'interagir avec elles.Google Cloud Parmi les exemples d'applications administratives citons la Google Cloud console, Google Cloud CLI, Terraform et IAP Desktop.
- Applications métier : ces applications incluent des applications Web qui s'exécutent sur Google Cloud et utilisent SAML ou Identity-Aware Proxy (IAP) pour l'authentification et l'autorisation. Ces applications sont parfois appelées applications internes. Parmi les exemples d'applications métier, citons 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 également distinguer les applications métier en fonction de la manière dont elles gèrent l'authentification et l'autorisation :
- SAML : applications qui utilisent Google Workspace SAML pour l'authentification. Les applications SaaS entrent souvent dans 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 champs d'application OAuth.
Le diagramme de flux suivant présente l'approche d'accès contextuel la plus adaptée à 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 Google Cloud ressources 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 des ressources. Dans ce cas, il est probable que l'accès à une application administrative ne soit pas aussi utile pour l'utilisateur.
- Un utilisateur a accès à une ressource, mais ne peut pas accéder à une application administrative. Dans ce cas, il peut 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 le plus efficacement possible les contrôles d'accès contextuel appropriés aux ressources, utilisez des 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 qui utilisent 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 qui utilisent 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 qui utilisent SAML : comme pour les applications métier qui utilisent 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 à utiliser lorsque vous gérez des 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 toutes les ressources de votre Google Cloud organisation. Il est donc préférable de limiter le nombre total de niveaux d'accès, et de les rendre significatifs et applicables à plusieurs ressources. Tenez compte des points 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 d'utilisateur ou d'appareil, par exemple
Fully Trusted Device.
Utiliser des niveaux d'accès composites
Pour réduire la surcharge de maintenance et garantir 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. Laissez plutôt les niveaux d'accès dépendre les uns des autres.
Par exemple, ne listez pas les mêmes régions approuvées
ou sous-réseaux IP dans plusieurs niveaux d'accès, mais 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 d'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 d'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
membersexigence qui liste un ou plusieurs de vos utilisateurs d'accès d'urgence. - Définissez la fonction de combinaison sur une condition
ORafin 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 emplacement, leur appareil et d'autres facteurs peuvent avoir un impact sur leur autorisation d'accéder à certaines applications. Pour informer les utilisateurs et réduire les demandes d'assistance, configurez un message de résolution personnalisé qui leur indique 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 champs d'application. Les liaisons d'accès sont également un moyen efficace d'appliquer l'accès contextuel aux applications métier.
Les sections suivantes décrivent les pratiques recommandées à utiliser lorsque vous utilisez des liaisons d'accès.
Utiliser une seule liaison 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 peut comporter au maximum une 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 doit être approprié pour la plupart des utilisateurs, appareils et applications.
- Si nécessaire, utilisez
des paramètres d'accès limités (
scopedAccessSettings) pour attribuer des niveaux d'accès plus faibles aux applications sélectionnées.
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 qu'un seul des niveaux 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 réduire 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.
Envisagez d'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 des 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 soumises à des sanctions ou qui ne sont pas pertinentes pour d'autres raisons.
- Restrictions concernant les réseaux 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 concernant les réseaux IP.
N'utilisez pas de niveaux d'accès nécessitant une authentification basée sur des certificats comme niveau d'accès par défaut. L'authentification basée sur des certificats est plus adaptée aux règles d'entrée du périmètre 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 être approprié pour la plupart des applications, mais pas pour 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.
- Certaines applications peuvent être 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 des paramètres d'accès limités. Pour chaque application concernée, ajoutez un paramètre limité et attribuez un niveau d'accès plus approprié pour l'application individuelle.
Ne créez pas de liaisons d'accès supplémentaires pour gérer les exceptions par utilisateur ou par groupe. Les liaisons d'accès supplémentaires peuvent entraîner les problèmes suivants :
- Vous risquez de créer involontairement des liaisons d'accès qui se chevauchent .
- Il peut devenir difficile de déterminer quelles exigences d'accès contextuel sont appliquées efficacement pour des applications individuelles.
Éviter le chevauchement des liaisons d'accès
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, lorsque les utilisateurs sont autorisés à rejoindre des groupes supplémentaires, la protection de certaines applications peut être compromise.
Pour éviter de telles situations, nous vous recommandons d'éviter le chevauchement des liaisons d'accès :
- Réduisez 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 qui s'excluent mutuellement.
Protéger les groupes contre les modifications non autorisées
Par défaut, Cloud Identity permet aux membres d'un groupe de quitter un groupe. Ce comportement est approprié pour les groupes d'accès, mais il est problématique pour les groupes auxquels sont associées des liaisons d'accès. Si un utilisateur quitte un groupe auquel est associée une liaison d'accès, il n'est plus soumis aux exigences d'accès contextuel imposées par les liaisons d'accès. Par conséquent, les utilisateurs peuvent 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.
N'autoriser pas l'accès des 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 votre Google Cloud organisation appartient. Ces utilisateurs sont toujours soumis aux liaisons d'accès de votre Google Cloud organisation s'ils tentent d'accéder à des ressources dans d'autres Google Cloud organisations. Cette application des liaisons d'accès aux utilisateurs est différente 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 Google Cloud organisations, 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 à des applications ou des ressources de votre Google Cloud organisation. N'ajoutez pas non plus d'utilisateurs externes à des groupes dans votre compte Cloud Identity ou Google Workspace.
Utiliser des liaisons d'accès distinctes pour le contrôle de 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 le chevauchement des liaisons d'accès.
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 inattendus, utilisez une liaison d'accès distincte pour contrôler la durée des sessions.
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 elles n'affectent pas les comptes de service. Si vous autorisez les utilisateurs à s'authentifier et à agir en tant que compte de service, ils peuvent être en mesure de compromettre vos contrôles d'accès contextuel.
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é d'un compte de service, sauf à des fins de développement.
Pour en savoir plus sur la sécurisation des comptes de service et des clés de compte de service, consultez les pages Bonnes pratiques pour l'utilisation des comptes de service et Bonnes pratiques pour la gestion des clés de compte de service.
Règles d'Ingress pour les périmètres de service VPC
Les règles d'Ingress vous permettent d'accorder un accès contextuel depuis l'extérieur du périmètre de service aux ressources à l'intérieur du périmètre. Les périmètres de service VPC et les règles d'entrée protègent les Google Cloud ressources, 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 l'accès contextuel aux outils d'administration tels que la Google Cloud console et gcloud CLI.
Pour en savoir plus et découvrir les bonnes pratiques concernant les périmètres de service VPC, consultez la section 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 le transfert TCP d'IAP en tant que service restreint
Il peut être risqué d'autoriser les utilisateurs à se connecter à des instances de VM dans votre périmètre de service à l'aide de SSH ou de RDP pour les raisons suivantes :
- Vos règles d'entrée ne s'appliquent pas aux connexions, car l'utilisation de SSH et de RDP n'implique aucun accès à l'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é à partir de cette session.
Pour atténuer ces risques, n'autorisez l'accès SSH et RDP aux VM que via le transfert TCP d'IAP :
- Incluez le
iaptunnel.googleapis.comservice en tant que service restreint. - Configurez des règles de pare-feu qui limitent l'accès aux ports SSH et RDP via le transfert TCP d'IAP.
Utilisez le transfert TCP d'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 les jetons d'actualisation Google ne sont pas liés à un appareil et peuvent être vulnérables au vol ou aux attaques par relecture. Pour atténuer ces risques, vous pouvez utiliser l'accès basé sur des certificats (CBA), qui limite l'accès aux appareils possédant un certificat X.509 approuvé.
Le CBA 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 Google Cloud API.
Utilisez le CBA 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