Ce document décrit les bonnes pratiques, les scénarios et les procédures permettant de révoquer l'accès d'un utilisateur à un projet Google Cloud. Ce document a pour objectif de vous aider à élaborer des stratégies et des procédures vous permettant de révoquer les accès de manière cohérente et rapide.
Le retrait de l'accès d'une personne à vos ressources Google Cloud est un moment critique. Lorsqu'un employé quitte votre entreprise, que votre contrat avec un sous-traitant prend fin ou qu'un collaborateur passe à d'autres projets, vous devez prendre certaines mesures pour révoquer complètement les accès inutiles à vos ressources.
Certaines de ces procédures sont facultatives. C'est à vous de déterminer quelles étapes sont nécessaires, en fonction de vos besoins en matière de sécurité, des produits utilisés et de la confiance accordée à la personne dont l'accès est révoqué.
Bonnes pratiques pour la configuration de votre projet
Vous pouvez améliorer la capacité de votre projet à révoquer efficacement l'accès des utilisateurs en faisant des choix judicieux au moment de la configuration.
Fédérer les comptes utilisateur avec votre fournisseur d'identité existant
Lorsque vous fédérez des comptes utilisateur avec votre fournisseur d'identité existant, vous pouvez synchroniser l'état de vos comptes utilisateur. Lorsque vous supprimez un compte utilisateur de votre fournisseur d'identité, l'identité de l'utilisateur dans Cloud Identity est également supprimée et l'utilisateur n'a plus accès aux ressources Google Cloud via vos stratégies d'autorisation.
Pour en savoir plus, consultez la section Bonnes pratiques pour fédérer Google Cloud avec un fournisseur d'identité externe.
Pour en savoir plus sur les bonnes pratiques liées à l'identité, consultez la section Bonnes pratiques pour planifier des comptes et des organisations.
Utiliser Google Groupes pour gérer l'accès aux ressources du projet
Google Groups vous permet d'organiser les utilisateurs en fonction de leur appartenance à une équipe ou d'autres critères. Une fois que vous avez créé des groupes Google, vous pouvez attribuer l'accès aux projets et aux ressources Google Cloud en fonction de ces groupes. Ensuite, lorsqu'un utilisateur rejoint une autre équipe, vous pouvez simplement déplacer son compte vers un autre groupe, ce qui supprime automatiquement l'accès accordé par les stratégies d'autorisation au groupe précédent.
Pour en savoir plus, consultez les sections Gérer des groupes dans la console Google Cloud et Créer un groupe dans votre organisation.
Utiliser OS Login
Utilisez OS Login plutôt que des clés SSH basées sur les métadonnées afin de pouvoir associer les comptes Linux de vos utilisateurs à leurs identités Google. Lorsque vous supprimez un compte utilisateur, les clés sont automatiquement révoquées.
Pour obtenir des instructions, consultez la section Configurer OS Login.
Restreindre l'accès pour les comptes utilisateur externes
N'accordez pas aux utilisateurs externes d'accès au projet, car vous ne pouvez pas contrôler le cycle de vie de ces comptes utilisateur. Pour restreindre les utilisateurs externes, utilisez la contrainte de liste iam.allowedPolicyMemberDomains.
Pour obtenir des instructions, consultez la section Restreindre les identités par domaine.
Utiliser le proxy d'authentification Cloud SQL lors de la connexion à Cloud SQL
Le proxy d'authentification Cloud SQL vous permet de connecter des charges de travail à Cloud SQL en fonction des autorisations IAM, au lieu d'un contrôle des accès basé sur les adresses IP, comme les réseaux autorisés. Le proxy d'authentification Cloud SQL valide les connexions en utilisant les identifiants d'un utilisateur ou d'un compte de service et en encapsulant la connexion dans une couche SSL/TLS autorisée pour votre instance Cloud SQL. Il s'agit d'une méthode de connexion plus sécurisée que l'utilisation de certificats SSL/TLS autogérés ou de réseaux autorisés. Cette méthode vous permet également de supprimer l'accès à Cloud SQL lorsque vous révoquez des autorisations pour le compte utilisateur, ou de supprimer complètement le compte utilisateur.
Limiter l'accès aux VM
Les machines virtuelles, comme celles utilisées par Compute Engine et Google Kubernetes Engine, constituent des surfaces d'attaques potentielles importantes. Si une personne a déjà eu accès à une VM, en particulier un accès root ou administrateur, il est extrêmement difficile de savoir si elle n'a pas modifié la VM et laissé une porte dérobée pour pouvoir y accéder plus tard. Limitez l'accès des VM aux personnes qui en ont clairement et spécifiquement besoin.
Par défaut, les éditeurs et les propriétaires de projet disposent d'un accès administrateur à toutes les VM du projet. Supprimez cet accès par défaut et suivez le principe du moindre privilège pour l'accès aux VM.
Avant d'accorder des droits d'accès aux VM, réfléchissez aux tâches qui nécessitent un tel accès et déterminez s'il existe potentiellement d'autres moyens de répondre à ces besoins. Par exemple, au lieu d'accorder à chaque développeur un droit de connexion à la VM pour déployer du code, envisagez d'utiliser des outils tels que Chef, Puppet et Salt pour gérer vos déploiements.
Préparer la rotation des identifiants
Concevez vos projets et vos ressources de manière à permettre une rotation facile et sans interruption des identifiants au niveau du projet. Il s'agit de codes secrets liés au projet lui-même, tels que des clés de compte de service, des codes secrets du client OAuth, ainsi que de codes secrets spécifiques à une application, tels que des mots de passe racines de base de données. Pour en savoir plus, consultez la page Gérer des identifiants Google Cloud dont la sécurité a été compromise.
Restreindre les clés API
Lors de la création et de la gestion de clés API, limitez le nombre de sites Web, d'adresses IP et d'applications pouvant les utiliser. Un compte utilisateur doté de rôles tels que Lecteur ou Administrateur de clés API peut voir les clés API de votre projet. Par conséquent, les clés sans restriction doivent renouvelées ou supprimées afin de révoquer l'accès à la facturation. Pour en savoir plus, consultez la section Sécuriser une clé API.
Autres bonnes pratiques
Outre les bonnes pratiques décrites dans ce document, consultez les bonnes pratiques suivantes :
- Bonnes pratiques d'utilisation des comptes de service
- Décider de la sécurité de votre zone de destination Google Cloud
- Gérer l'identité et l'accès
Scénarios de révocation de l'accès à des projets Google Cloud
Si vous avez implémenté les bonnes pratiques listées dans la section Bonnes pratiques pour configurer votre projet, le tableau suivant récapitule comment révoquer l'accès.
| Scénario | Révoquer des options d'accès |
|---|---|
| Un employé quitte votre entreprise. | Si vous configurez la fédération entre Cloud Identity ou Google Workspace avec le provisionnement automatique des utilisateurs, la révocation de l'accès peut s'effectuer automatiquement. Si vous n'avez pas suivi les bonnes pratiques et que vous avez accordé aux identités des utilisateurs externes l'accès à vos ressources, vous devez les supprimer manuellement de vos projets et ressources. |
| Un employé change de poste. | vous supprimez l'employé du groupe correspondant à l'équipe. |
| Un engagement contractuel prend fin. | Si vous configurez la fédération entre Cloud Identity ou Google Workspace avec le provisionnement automatique des utilisateurs, la révocation de l'accès peut s'effectuer automatiquement. Si vous n'avez pas suivi les bonnes pratiques et que vous avez accordé aux identités des utilisateurs externes l'accès à vos ressources, vous devez les supprimer manuellement de vos projets et ressources. |
| Un compte a été compromis. | Pour obtenir des instructions, consultez la section Gérer des identifiants Google Cloud dont la sécurité a été compromise. |
Révoquer l'accès
Si vous avez fait de bons choix dans la configuration du projet, les procédures suivantes constitueront un moyen sûr et efficace pour révoquer l'accès d'une personne.
Pour déterminer les ressources auxquelles une personne a accès, utilisez Policy Analyzer. Pour obtenir des instructions, consultez la section Analyser les stratégies IAM.
Supprimer le compte utilisateur de votre fournisseur d'identité
Si l'utilisateur quitte votre organisation et que vous avez fédéré Cloud Identity ou Google Workspace avec votre fournisseur d'identité, avec le provisionnement automatique des utilisateurs, la révocation de l'accès peut s'effectuer automatiquement.
Déplacer le compte dans un autre groupe
Si l'utilisateur change de rôle, supprimez le compte utilisateur de son groupe Google Groupes actuel. Si vous avez fédéré Cloud Identity ou Google Workspace avec votre fournisseur d'identité pour gérer les appartenances à un groupe, la révocation de l'accès peut s'effectuer automatiquement.
Supprimer le compte utilisateur de l'abonnement au projet
Dans la console Google Cloud, accédez à la page Autorisations IAM.
Sélectionnez le projet pour lequel vous souhaitez supprimer un compte utilisateur.
Cochez la case située à côté de la ligne contenant le compte utilisateur que vous souhaitez supprimer de la liste des membres, puis cliquez sur Supprimer.
Alterner les identifiants du projet
Alterner les clés de compte de service
Si vous utilisez des clés de compte de service pour vous authentifier auprès d'un compte de service, vous devez les alterner. En outre, déterminez si la personne peut avoir eu accès aux clés de compte de service en dehors des outils Google Cloud, tels que votre dépôt de code source ou vos configurations d'application.
Dans la console Google Cloud, accédez à la page Identifiants de l'API.
Cliquez sur le nom du compte de service que vous souhaitez modifier.
Sous l'onglet Clé, cliquez sur Ajouter une clé.
Cliquez sur Create new key (Créer une clé).
Choisissez le type de clé que vous souhaitez créer. Dans la plupart des cas, JSON est recommandé, mais P12 est également disponible, pour assurer la rétrocompatibilité avec le code qui en dépend.
Cliquez sur Créer. Un fichier contenant la nouvelle clé sera automatiquement téléchargé via votre navigateur. Déployez cette clé sur toutes les applications qui en ont besoin.
Après avoir vérifié que la nouvelle clé fonctionne comme prévu, retournez à la page des identifiants et supprimez l'ancienne clé associée à ce compte de service.
Alterner les secrets d'ID client OAuth
Les codes secrets d'ID client OAuth ne fournissent aucun accès direct à votre projet. Toutefois, si un pirate informatique connaît le code secret d'ID client OAuth, il peut usurper l'identité de votre application et demander l'accès aux comptes Google de vos utilisateurs à partir d'une application malveillante.
Vous devrez peut-être alterner les codes secrets d'ID client OAuth si la personne dont l'accès est révoqué a déjà eu accès au secret, y compris dans votre dépôt de code source, vos configurations d'application ou via des rôles IAM.
Dans la console Google Cloud, accédez à la page Identifiants de l'API.
Cliquez sur le nom de l'ID client OAuth 2.0 que vous souhaitez modifier.
Sur la page d'ID client, cliquez sur Réinitialiser le code secret.
Cliquez sur Réinitialiser dans la boîte de dialogue de confirmation pour révoquer immédiatement l'ancien code secret et en définir un nouveau. Sachez que tout utilisateur actif devra s'authentifier de nouveau lors de sa prochaine requête.
Déployez le nouveau code secret dans toutes les applications qui en ont besoin.
Alterner les clés API
Les clés API ne permettent pas d'accéder à votre projet ni aux données de vos utilisateurs, mais elles permettent de savoir qui Google doit facturer pour les requêtes API. Un compte utilisateur doté de rôles tels que Lecteur ou Administrateur de clés API peut voir les clés API de votre projet. Si vous disposez de clés sans restriction, vous devez les supprimer ou les regénérer lorsque vous révoquez l'accès d'une personne à votre projet.
Dans la console Google Cloud, accédez à la page Identifiants de l'API.
Cliquez sur le nom de la clé API que vous souhaitez modifier.
Cliquez sur Régénérer la clé.
Une boîte de dialogue affiche la clé qui vient d'être créée. Déployez cette clé sur toutes les applications qui utilisent la clé que vous souhaitez remplacer.
Après avoir vérifié que vos applications fonctionnent comme prévu avec la nouvelle clé, revenez à la page des identifiants et supprimez l'ancienne clé sans restriction.
Révoquer l'accès aux VM
Si la personne dont vous révoquez l'accès ne dispose d'aucun droit de connexion à l'une des VM de votre projet, vous pouvez ignorer cette étape.
Supprimez toutes les clés SSH au niveau du projet auxquelles la personne avait accès.
Sur chaque VM dans laquelle la personne disposait d'un accès SSH, supprimez toutes les clés au niveau de l'instance.
Supprimez le compte de la personne de toutes les VM dans lesquelles elle disposait d'un droit de connexion.
Recherchez les applications suspectes que la personne peut avoir installées pour disposer d'un accès détourné à la VM. Si vous n'êtes pas sûr de la sécurité d'un code exécuté sur la VM, recréez-le et redéployez les applications dont vous avez besoin à partir de la source.
Vérifiez que les paramètres de pare-feu de la VM n'ont pas été modifiés par rapport à la configuration que vous avez planifiée ou prévue.
Si vous créez des VM à partir d'images de base personnalisées, vérifiez que ces images n'ont pas été modifiées de manière à compromettre la sécurité des nouvelles VM.
Révoquer l'accès aux bases de données Cloud SQL
Si votre projet ne fait pas appel à des ressources Cloud SQL, vous pouvez ignorer cette étape.
Dans la console Google Cloud, accédez à la page Instances SQL.
Cliquez sur l'ID de l'instance de la base de données à laquelle vous souhaitez révoquer l'accès.
Dans le menu de gauche, cliquez sur Connexions.
Vérifiez que la liste des adresses IP sous Réseaux autorisés et la liste des applications sous Autorisation App Engine correspondent à vos attentes. Si la personne dont vous révoquez l'accès a accès aux réseaux ou aux applications répertoriées ici, elle peut accéder à cette base de données.
Dans le menu de gauche, cliquez sur Utilisateurs.
Supprimez ou modifiez le mot de passe de tous les comptes utilisateur auxquels la personne a eu accès. Veillez à mettre à jour les applications qui dépendent de ces comptes utilisateur.
Redéployer App Engine
Par défaut, les applications App Engine ont accès à un compte de service qui est un éditeur du projet associé. Les gestionnaires de requêtes App Engine peuvent effectuer des opérations comme la création de VM, ou encore la lecture ou la modification des données dans Cloud Storage. Une personne ayant la capacité de déployer du code dans App Engine pourrait utiliser ce compte de service pour ouvrir une porte dérobée dans votre projet. Si l'intégrité du code de vos applications déployées vous préoccupe, vous pouvez les redéployer (avec tous les modules) à l'aide d'une bonne extraction connue depuis votre système de contrôle des versions.
Vérifier que les autorisations ont été supprimées
Dans Google Cloud CLI, exécutez la méthode search-all-iam-policies pour rechercher toutes les ressources auxquelles un compte utilisateur particulier peut avoir accès. Par exemple, pour déterminer si un utilisateur a accès à vos ressources, exécutez la commande suivante :
gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'
Où :
ORGANIZATION_IDest le numéro de votre organisation.IDENTITYest l'identité de l'utilisateur, par exemple une adresse e-mail.
Étapes suivantes
Consultez la section Gérer des identifiants Google Cloud dont la sécurité a été compromise.
Découvrez les Bonnes pratiques pour limiter les risques de compromission de jetons OAuth pour Google Cloud CLI.
Consultez la présentation de Google Cloud Security.