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 . Chaque entreprise ayant 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 complètement 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 les 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.
Pour en savoir plus sur la fédération des identités des employés, consultez la page Fédération des identités des employés.
Envisager 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 l'accès à des Google Cloud projets et des ressources en fonction de l'appartenance au groupe. Lorsqu'un utilisateur rejoint une autre équipe ou un autre poste, vous pouvez 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.
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 organisationnelle de votre entreprise pour gérer l'accès. Pour connaître les bonnes pratiques concernant l'utilisation des groupes, consultez Bonnes pratiques concernant l'utilisation de Google Groupes.
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 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 règles 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 de connecter le cycle de vie des identifiants de base de données au cycle de vie 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 les pages 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 Gérer les identifiantsGoogle 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 être 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.
Surveiller les autorisations d'accès
Le suivi minutieux des accès permet de limiter les utilisations abusives potentielles. Vous pouvez utiliser IAM Role Recommender pour suivre l'utilisation des rôles afin d'appliquer le principe du moindre privilège. De plus, les fonctionnalités de gestion des droits d'accès à l'infrastructure cloud (CIEM) de Security Command Center vous permettent de gérer les identités ayant accès aux ressources de vos déploiements et d'atténuer les failles potentielles résultant d'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 uniquement IAM pour gérer les autorisations de vos buckets Cloud Storage. Utilisez un accès uniforme au niveau du bucket avec d'autres options de contrôle des accès pour affiner les utilisateurs autorisés à 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 Google Cloud zone de destination
- Vérifiez explicitement chaque tentative d'accès.
Scénarios de révocation de l'accès aux 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 identifiantsGoogle 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.
Pour savoir comment supprimer des utilisateurs de la fédération des identités des employés, consultez la section Supprimer des utilisateurs de la fédération des identités des employés et leurs données.
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, procédez comme suit:
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 d'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
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 ne fait pas appel à des ressources Cloud SQL ou 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, du projet ou à l'aide de l'outil d'analyse des règles.
Pour rechercher 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 projet, consultez la section 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.
Étape suivante
Consultez Gérer les identifiants Google Cloudpiratés.
Découvrez les Bonnes pratiques pour limiter les risques de compromission de jetons OAuth pour Google Cloud CLI.
Créez une règle de refus pour spécifier les autorisations auxquelles l'utilisateur ne peut plus accéder.