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 . Étant donné que chaque entreprise a des règles et des charges de travail différentes, nous vous recommandons d'utiliser ce document pour élaborer vos propres règles et procédures vous permettant de révoquer les accès de manière cohérente et rapide.
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 les accès inutiles à vos ressources cloud.
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, assurez-vous de propager les événements de suspension et de suppression des utilisateurs. Avec la propagation, lorsque vous suspendez ou supprimez un compte utilisateur de votre fournisseur d'identité, l'utilisateur perd également l'accès aux ressources Google Cloud .
Pour en savoir plus, consultez 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 Bonnes pratiques pour planifier des comptes et des organisations.
Pour en savoir plus sur la fédération des identités des employés, consultez Fédération des identités des employés.
Envisagez d'utiliser Google Groupes pour gérer l'accès aux ressources du projet
Les groupes Google vous permettent d'organiser les utilisateurs en fonction de leur appartenance à une équipe, de leurs exigences d'accès ou d'autres critères. Une fois que vous avez créé des groupes Google, vous pouvez attribuer des accès aux projets et aux ressources Google Cloud en fonction de l'appartenance à un groupe. Lorsqu'un utilisateur change d'équipe ou de fonction, vous pouvez déplacer son compte vers un autre groupe. L'accès accordé par les règles d'autorisation à l'ancien groupe est alors automatiquement supprimé.
L'utilisation de Google Groupes n'est pas appropriée dans toutes les circonstances. Par exemple, vous ne devez pas utiliser de groupes basés uniquement sur la structure de votre entreprise pour gérer les accès. Pour connaître les bonnes pratiques concernant l'utilisation des groupes, consultez Bonnes pratiques d'utilisation de Google Groupes.
Pour en savoir plus, consultez 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 que les clés autorisées de l'utilisateur soient associées à son identité Google. Lorsque vous supprimez un compte utilisateur, les clés autorisées et l'accès aux VM sont automatiquement révoqués. Pour en savoir plus, consultez Utiliser OS Login pour assurer une évaluation continue des accès par rapport aux stratégies IAM.
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 des proxys d'authentification avec des bases de données
Les proxys d'authentification vous permettent d'associer le cycle de vie des identifiants de base de données à celui d'une identité Google. Lorsque vous suspendez ou supprimez un compte utilisateur dans Cloud Identity ou Google Workspace, l'accès aux bases de données est automatiquement révoqué.
Pour en savoir plus, consultez Proxy d'authentification Cloud SQL et Proxy d'authentification AlloyDB pour PostgreSQL.
Préparer la rotation des identifiants
Concevez vos projets et vos ressources de manière à permettre une rotation 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 Répondre aux identifiantsGoogle Cloud compromis.
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 être renouvelées ou supprimées afin de révoquer l'accès facturation. Pour en savoir plus, consultez Sécuriser une clé API.
Surveiller les autorisations d'accès
Le suivi minutieux des accès permet d'atténuer les risques d'abus d'accès. Vous pouvez utiliser l'outil de recommandation de rôles IAM pour suivre l'utilisation des rôles et appliquer le principe du moindre privilège. De plus, les fonctionnalités Cloud Infrastructure Entitlement Management (CIEM) de Security Command Center vous permettent de gérer les identités qui ont accès aux différentes ressources de vos déploiements et de réduire les failles potentielles liées à des erreurs de configuration.
Utiliser l'accès uniforme au niveau du bucket pour Cloud Storage
L'accès uniforme au niveau du bucket vous permet d'utiliser IAM seul pour gérer les autorisations de vos buckets Cloud Storage. Utilisez l'accès uniforme au niveau du bucket avec d'autres options de contrôle des accès pour affiner les personnes autorisées à accéder au contenu de vos buckets.
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
- Choisir comment sécuriser votre zone de destination Google Cloud
- Valider explicitement chaque tentative d'accès
Scénarios de révocation de l'accès aux projets Google Cloud
Si vous avez appliqué les bonnes pratiques listées dans 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 Répondre aux identifiantsGoogle Cloud piratés. |
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 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.
Pour savoir comment supprimer des utilisateurs de la fédération d'identité des employés, consultez Supprimer des utilisateurs de la fédération d'identité des employés et leurs données.
Révoquer les sessions utilisateur du personnel
Si vous pensez que les identifiants d'un utilisateur de Workforce ont été piratés ou si vous souhaitez mettre fin immédiatement aux sessions actives avant la suppression, révoquez les sessions de l'utilisateur.
Pour en savoir plus, consultez Révoquer les sessions utilisateur de la fédération des identités des employés.
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.
Pour en savoir plus, consultez Afficher et modifier les détails d'un groupe.
Supprimer le compte utilisateur des stratégies d'autorisation IAM
Pour supprimer un compte utilisateur des règles d'autorisation au niveau du 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.
Pour vérifier les autres emplacements où la stratégie d'autorisation peut être définie, y compris les dossiers, l'organisation ou les ressources individuelles, consultez Vérifier que les autorisations ont été supprimées.
Alterner les identifiants du projet
Si la personne dont vous révoquez l'accès avait accès à des identifiants au niveau du projet, tels que des clés de compte de service, des codes secrets du client OAuth ou des clés API, vous devez alterner ces identifiants.
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
Si votre projet n'utilise pas de ressources Cloud SQL ni AlloyDB pour PostgreSQL, vous pouvez ignorer cette étape.
Pour révoquer l'accès à une base de données Cloud SQL, procédez comme suit :
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.
Pour révoquer l'accès à une base de données AlloyDB pour PostgreSQL, consultez Supprimer un compte d'utilisateur ou de service IAM d'un cluster.
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
Vous pouvez vérifier les autorisations au niveau de l'organisation ou du projet, ou à l'aide de Policy Analyzer.
Pour trouver les ressources auxquelles un utilisateur particulier peut avoir accès au niveau de l'organisation, utilisez la méthode search-all-iam-policies dans Google Cloud CLI. 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.
Pour vérifier les autorisations d'un compte principal sur un projet, consultez Autorisations d'un compte principal sur un projet.
Pour vérifier les autorisations à l'aide de Policy Analyzer, consultez Déterminer les ressources auxquelles un compte principal peut accéder.
Étapes suivantes
En savoir plus sur les bonnes pratiques pour protéger les identifiants de développeur
Créez une stratégie de refus pour spécifier les autorisations auxquelles l'utilisateur ne peut plus accéder.