Répondre aux identifiants Google Cloud compromis

Si vous pensez que vos identifiants ont été piratés, vous devez réagir immédiatement pour limiter les conséquences sur votre compteGoogle Cloud .

Les identifiantsGoogle Cloud contrôlent l'accès à vos ressources hébergées sur Google Cloud. Google Cloud inclut les identifiants à longue durée de vie et ceux à courte durée de vie. Pour sécuriser vos données et les protéger des pirates informatiques, vous devez gérer vos identifiants avec la plus grande vigilance et réagir rapidement en cas de suspicion de piratage.

Google Cloud  identifiants

Le tableau suivant décrit les identifiants Google Cloud courants.

Identifiant Description
Clés privées de compte de service (fichiers JSON et p12)

Type : identifiant de service de longue durée

Emplacements habituels :

  • Postes de travail pour les développeurs
  • Environnements de serveur d'application
  • Dépôts de code source
  • Systèmes de gestion des secrets

Correction : Clés et jetons de compte de service
Jetons de compte de service (jetons d'accès OAuth 2.0)

Type : identifiant éphémère

Emplacements habituels :

  • Mémoire d'exécution de l'application
  • Charges de travail de production (récupérées de manière dynamique à partir des serveurs de métadonnées d'instance)
  • Postes de travail des développeurs ou pipelines CI/CD

Correction : Clés et jetons de compte de service
Clés API

Type : identifiant de service de longue durée

Emplacements habituels :

  • Code source du frontend
  • Fichiers de configuration du backend
  • Systèmes de gestion des secrets ou variables d'environnement

Solution : clés API
Codes secrets d'ID client OAuth 2.0

Type : identifiant de service de longue durée

Emplacements habituels :

  • Fichiers de configuration du backend du serveur Web
  • Systèmes de gestion des secrets

Solution : Codes secrets d'ID client OAuth 2.0
Identifiants Google Cloud CLI

Type : identifiant utilisateur de longue durée

Emplacement type : répertoire d'accueil de l'utilisateur. Pour lister les identifiants actifs, exécutez la commande gcloud auth list.

Solution : Identifiants utilisateur et jetons OAuth Google Cloud CLI
Jetons d'accès OAuth pour Google Cloud CLI

Type : identifiant éphémère

Emplacement type : postes de travail des développeurs

Solution : Identifiants utilisateur et jetons OAuth gcloud CLI
Identifiants par défaut de l'application

Type : identifiant utilisateur de longue durée

Emplacement type : postes de travail des développeurs

Solution : Identifiants par défaut de l'application
Cookies de navigateur

Type : identifiant utilisateur de longue durée

Emplacement type : spécifique au navigateur, mais généralement stocké sur les postes de travail des développeurs

Résolution : cookies du navigateur
Jetons d'accès fédérés Security Token Service pour la fédération d'identité de charge de travail

Type : identifiant éphémère

Emplacements habituels :

  • Environnements d'exécution des charges de travail externes
  • Pipelines de déploiement CI/CD

Solution : Jetons d'accès fédérés du service de jetons de sécurité
Jetons d'accès fédérés Security Token Service pour la fédération d'identité de personnel

Type : identifiant éphémère

Emplacements habituels :

  • Postes de travail pour les développeurs
  • Applications et scripts clients tiers

Solution : Jetons d'accès fédérés du service de jetons de sécurité

Protéger vos ressources Google Cloud contre un identifiant dont la sécurité a été compromise

Si vous pensez que la sécurité d'un identifiant a été compromise, révoquez-le puis recréez-le. Agissez avec prudence pour éviter toute interruption de service résultant de la révocation des identifiants.

Pour recréer un identifiant, vous devez généralement en générer un nouveau, le déployer sur tous les services et utilisateurs qui en ont besoin, puis révoquer l'ancien identifiant.

Les sections suivantes fournissent des instructions spécifiques pour chaque type d'identifiant.

Clés et jetons de compte de service

Pour remplacer une clé de compte de service compromise et bloquer les jetons de compte de service à courte durée de vie compromis, procédez comme suit.

Les jetons de compte de service éphémères existent indépendamment de l'identifiant ou de l'autorisation utilisés pour les générer. Ils ne peuvent pas être révoqués. Les jetons d'accès aux comptes de service sont des jetons de support et restent valides jusqu'à leur date d'expiration (par défaut, jusqu'à 60 minutes, ou jusqu'à 12 heures si une règle de durée de vie étendue des jetons est configurée).

Contrairement aux jetons d'accès accordés aux identités d'utilisateur, la validation des jetons d'accès accordés aux comptes de service ne peut pas être annulée via la console d'administration ni des commandes telles que gcloud auth revoke. En outre, la durée de la session que vous spécifiez dans le contrôle de sessionGoogle Cloud s'applique aux comptes utilisateur de votre annuaire Cloud Identity ou Google Workspace, mais pas aux comptes de service. Par conséquent, votre gestion des incidents concernant des comptes de service piratés doit porter sur les fichiers de clés persistantes ainsi que sur les jetons d'accès de courte durée.

Rôles requis

Pour obtenir les autorisations nécessaires pour répondre aux clés et jetons de compte de service piratés, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  • Gérer les clés de compte de service : Administrateur de clés de compte de service (roles/iam.serviceAccountKeyAdmin) sur le projet contenant le compte de service
  • Désactiver, activer ou supprimer des comptes de service : Administrateur de compte de service (roles/iam.serviceAccountAdmin) sur le projet contenant le compte de service
  • Appliquer des règles de refus pour bloquer les jetons actifs : Administrateur des refus (roles/iam.denyAdmin) de l'organisation
  • Révoquez les rôles d'usurpation d'identité : Administrateur IAM (Identity and Access Management) de projet (roles/resourcemanager.projectIamAdmin), Administrateur de compte de service (roles/iam.serviceAccountAdmin) sur le projet

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour répondre aux clés et jetons de compte de service compromis. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour répondre aux clés et jetons de compte de service piratés :

  • Gérez les clés de compte de service :
    • iam.serviceAccountKeys.create dans le projet contenant le compte de service
    • iam.serviceAccountKeys.delete dans le projet contenant le compte de service
    • iam.serviceAccountKeys.list dans le projet contenant le compte de service
  • Désactiver, activer ou supprimer des comptes de service :
    • iam.serviceAccounts.disable dans le projet contenant le compte de service
    • iam.serviceAccounts.enable dans le projet contenant le compte de service
    • iam.serviceAccounts.delete dans le projet contenant le compte de service
  • Appliquez des règles de refus pour bloquer les jetons actifs : iam.denypolicies.create sur l'organisation
  • Révoquez les rôles d'emprunt d'identité :
    • resourcemanager.projects.setIamPolicy sur le projet
    • iam.serviceAccounts.setIamPolicy dans le projet contenant le compte de service

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Répondre aux clés et jetons de compte de service piratés

  1. Pour bloquer un jeton de compte de service piraté, effectuez l'une des opérations suivantes :

    • Désactivez le compte de service correspondant à l'identifiant.

    • Appliquez une règle de refus IAM pour le principal du compte de service (principal://iam.googleapis.com/projects/-/serviceAccounts/SA_EMAIL_ADDRESS) sur vos projets ou dossiers. La stratégie de refus IAM refuse l'accès aux API et aux autorisations sensibles pour les jetons et les charges de travail actifs. Vous pouvez ainsi examiner l'incident sans détruire le compte de service.

    • Supprimez le compte de service.

    Si vous désactivez ou supprimez le compte de service, toute charge de travail utilisant ce compte perd immédiatement l'accès à vos ressources.

  2. Pour remplacer une clé de compte de service compromise, procédez comme suit :

    1. Dans la console Google Cloud , accédez à la page Comptes de service.

      Accéder à la page "Comptes de service"

    2. Identifiez le compte de service concerné.

    3. Si nécessaire, créez une clé pour le compte de service et déployez-la à tous les emplacements où l'ancienne clé était utilisée.

    4. Désactivez l'ancienne clé pour vérifier que la nouvelle fonctionne comme prévu.

    5. Supprimez l'ancienne clé.

    Pour en savoir plus, consultez Créer et supprimer des clés de compte de service.

  3. Si des comptes principaux non autorisés sont susceptibles d'être autorisés à générer des jetons, révoquez le rôle Créateur de jetons du compte de service (roles/iam.serviceAccountTokenCreator). Pour obtenir des instructions, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

  4. Une fois l'incident résolu, attendez au moins 60 minutes après avoir désactivé le compte de service pour que le jeton piraté puisse expirer. Si vous définissez une règle de durée de vie étendue à l'aide de constraints/iam.allowServiceAccountCredentialLifetimeExtension, attendez la durée spécifiée dans la contrainte avant de réactiver le compte de service.

  5. Une fois le délai d'attente requis écoulé, réactivez le compte de service et réinitialisez la stratégie de refus.

Identifiants utilisateur et jetons OAuth gcloud CLI

Après la compromission d'un point de terminaison, vous devez déterminer comment réagir face à la menace principale d'un point de terminaison compromis et à la menace secondaire de jetons compromis. Si un pirate informatique dispose d'un accès persistant au poste de travail du développeur, il peut copier à nouveau les jetons après que l'utilisateur légitime se soit réauthentifié.

Rôles requis

Pour obtenir les autorisations nécessaires pour révoquer l'accès des utilisateurs et invalider les jetons OAuth de gcloud CLI dans la console d'administration Google Workspace, demandez à votre administrateur de vous accorder les rôles d'administrateur Google Workspace suivants :

Pour en savoir plus sur l'attribution de rôles d'administrateur dans Google Workspace, consultez Attribuer des rôles d'administrateur dans la console d'administration Google.

Invalider les jetons gcloud CLI pour des comptes utilisateur spécifiques

Pour supprimer l'accès d'un utilisateur à la gcloud CLI et invalider les jetons compromis, procédez comme suit :

  1. Pour supprimer l'accès d'un utilisateur à Google Cloud CLI, effectuez l'une des opérations suivantes :

    Lorsque l'utilisateur accède à nouveau à Google Cloud CLI, il est invité à réautoriser l'application.

  2. Si vous avez extrait ou intercepté une chaîne de jeton compromise spécifique (jeton d'actualisation ou jeton d'accès), vous pouvez l'invalider directement à l'aide du point de terminaison de révocation Google OAuth 2.0 :

    curl -d "token=TOKEN_STRING" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -X POST "https://oauth2.googleapis.com/revoke"

    Lorsque vous exécutez cette commande pour révoquer un jeton d'actualisation, vous révoquez à la fois le jeton d'actualisation et tous les jetons d'accès associés. Lorsque vous exécutez cette commande pour révoquer un jeton d'accès, vous invalidez également le jeton d'actualisation associé.

  3. Si vous n'avez pas encore appliqué le contrôle de sessionGoogle Cloud , activez-le immédiatement en définissant une courte fréquence de réauthentification. Ce contrôle permet de s'assurer que tous les jetons d'actualisation expirent à la fin de la durée que vous définissez, ce qui limite la durée pendant laquelle un pirate informatique peut utiliser les jetons compromis.

Invalider les jetons gcloud CLI pour de nombreux comptes utilisateur

Si vous suspectez une violation, mais que vous ne parvenez pas à identifier les utilisateurs concernés, envisagez de révoquer les sessions actives pour tous les utilisateurs de votre organisation plus rapidement que ne le permet la règle de réauthentification.

Cette approche peut perturber les utilisateurs légitimes et mettre fin à des processus de longue durée, qui dépendent des identifiants des utilisateurs. Si vous choisissez cette approche, préparez une solution intégrant un script, qui sera exécuté au préalable par votre centre des opérations de sécurité (SOC), lors de tests portant sur quelques utilisateurs.

L'exemple de code suivant utilise le SDK Admin Google Workspace pour identifier toutes les identités d'utilisateur de votre compte Google Workspace ou Cloud Identity qui ont accès à gcloud CLI. Si un utilisateur a défini une autorisation de gcloud CLI, le script révoque le jeton d'actualisation et le jeton d'accès, et impose une réauthentification à partir de son mot de passe ou de sa clé de sécurité. Pour savoir comment activer l'API SDK Admin et exécuter ce code, consultez le guide de démarrage rapide de Google Apps Script.

/**
 * Remove access to the Google Cloud CLI for all users in an organization
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/tokens
 * @see https://developers.google.com/admin-sdk/directory/reference/rest/v1/users
 * @see https://developers.google.com/apps-script/guides/services/advanced#enabling_advanced_services
 */

function listUsersAndInvalidate() {
  const users = AdminDirectory.Users.list({
    customer: 'my_customer' // alias to represent your account's customerId
    }).users;
  if (!users || users.length === 0) {
    Logger.log('No users found.');
    return;
  }
  for (const user of users){
    let tokens = AdminDirectory.Tokens.list(user.primaryEmail).items
    if (!tokens || tokens.length === 0) {
      continue;
    }
    for (const token of tokens) {
      if (token.clientId === "32555940559.apps.googleusercontent.com") {
        AdminDirectory.Tokens.remove(user.primaryEmail, token.clientId)
        Logger.log('Invalidated the tokens granted to gcloud for user %s', user.primaryEmail)
      }
    }
  }
}

Identifiants par défaut de l'application

Si vous pensez qu'un identifiant par défaut de l'application a été piraté, vous pouvez le révoquer. Cette procédure peut entraîner une panne temporaire jusqu'à la recréation du fichier d'identifiants.

Rôles requis

Pour obtenir les autorisations nécessaires pour supprimer l'accès aux applications connectées dans la console d'administration Google Workspace, demandez à votre administrateur de vous attribuer le rôle d'administrateur de la sécurité ou de super-administrateur.

Les commandes locales exécutées sur les postes de travail des développeurs ne nécessitent pas de rôle d'administrateur. Pour en savoir plus sur l'attribution de rôles d'administrateur dans Google Workspace, consultez Attribuer des rôles d'administrateur dans la console d'administration Google.

Révoquer les identifiants par défaut de l'application

Effectuez l'une des actions suivantes :

  • En tant qu'administrateur Google Workspace, supprimez l'accès à la bibliothèque Google Auth de la liste des applications connectées de l'utilisateur. Pour en savoir plus, consultez la section Afficher et supprimer l'accès des applications tierces.

  • Demandez au propriétaire des identifiants piratés de procéder comme suit :

    1. Installez et initialisez gcloud CLI, si ce n'est pas déjà fait.

    2. Révoquez les identifiants :

      gcloud auth application-default revoke

    3. Si vous ne parvenez pas à exécuter gcloud CLI, procédez comme suit :

      1. Révoquez l'accès à la bibliothèque Google Auth à l'aide de myaccount.google.com/permissions ou du point de terminaison de révocation OAuth 2.0.

      2. Supprimez manuellement le fichier application_default_credentials.json :

        • Linux, macOS : $HOME/.config/gcloud/application_default_credentials.json
        • Windows : %APPDATA%\gcloud\application_default_credentials.json

    4. Recréez le fichier d'identifiants avec votre identité utilisateur :

      gcloud auth application-default login

Clés API

Pour régénérer une clé API compromise, procédez comme suit :

Rôles requis

Pour obtenir les autorisations nécessaires pour gérer les clés API, demandez à votre administrateur de vous accorder le rôle IAM Administrateur de clés API (roles/serviceusage.apiKeysAdmin) sur votre projet. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient les autorisations requises pour gérer les clés API. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour gérer les clés API :

  • apikeys.keys.create
  • apikeys.keys.delete
  • apikeys.keys.update
  • apikeys.keys.getKeyString
  • apikeys.keys.list
  • apikeys.keys.get

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Régénérer une clé API

  1. Dans la console Google Cloud , accédez à la page Identifiants.

    Accéder à "Identifiants"

  2. Cliquez sur le nom de la clé API dont vous souhaitez effectuer la rotation.

  3. Cliquez sur Effectuer une rotation de la clé.

  4. Saisissez un nom et confirmez les restrictions.

  5. Cliquez sur Créer.

  6. Mettez à jour les applications pour qu'elles utilisent la nouvelle clé API.

  7. Dans Clé précédente, cliquez sur Supprimer la clé précédente.

Pour en savoir plus, consultez Faire pivoter une clé API.

Codes secrets d'ID client OAuth 2.0

La modification d'un secret d'ID client provoque une interruption temporaire pendant le changement du secret.

Rôles requis

Pour obtenir les autorisations nécessaires pour réinitialiser les secrets d'ID client OAuth 2.0, demandez à votre administrateur de vous accorder le rôle IAM Éditeur de configuration OAuth (roles/oauthconfig.editor) sur votre projet. Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient les autorisations requises pour réinitialiser les secrets des ID client OAuth 2.0. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour réinitialiser les secrets d'ID client OAuth 2.0 :

  • clientauthconfig.clients.createSecret
  • clientauthconfig.clients.getWithSecret
  • clientauthconfig.clients.update
  • clientauthconfig.clients.get

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Réinitialiser un secret d'ID client OAuth 2.0

  1. Dans la console Google Cloud , accédez à la page Identifiants.

    Accéder à "Identifiants"

  2. Sélectionnez l'ID client OAuth 2.0 dont la sécurité a été compromise et modifiez-le.

  3. Cliquez sur Réinitialiser le code secret.

  4. Déployez le nouveau secret dans votre application.

Pour en savoir plus, consultez les pages Configurer OAuth 2.0 et Utiliser le protocole OAuth 2.0 pour accéder aux API Google.

Jetons d'accès fédérés Security Token Service

Lorsque des sessions d'identité externes sont compromises, vous devez arrêter les nouveaux échanges de jetons et révoquer les jetons d'accès fédérés actifs. Cette tâche s'applique aux jetons d'accès émis par la fédération d'identité de charge de travail ou la fédération des identités des employés.

Rôles requis

Pour obtenir les autorisations nécessaires pour gérer la fédération d'identité de charge de travail et la fédération d'identité des employés afin de bloquer les jetons fédérés, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour gérer la fédération d'identité de charge de travail et la fédération d'identité du personnel afin de bloquer les jetons fédérés. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour gérer la fédération d'identité de charge de travail et la fédération des identités des employés afin de bloquer les jetons fédérés :

  • Gérez les pools et fournisseurs d'identités de charge de travail :
    • iam.workloadIdentityPools.update sur le projet contenant le pool d'identités de charge de travail
    • iam.workloadIdentityPoolProviders.update sur le projet contenant le pool d'identités de charge de travail
  • Gérer les pools et les fournisseurs d'identité de personnel :
    • iam.workforcePools.update sur l'organisation qui contient le pool d'identités de personnel
    • iam.workforcePoolProviders.update sur l'organisation qui contient le pool d'identités de personnel
  • Appliquez des règles de refus pour bloquer les jetons actifs :
    • iam.denypolicies.create sur l'organisation
    • iam.denypolicies.update sur le projet, le dossier ou l'organisation
  • Gérez l'emprunt d'identité d'un compte de service : iam.serviceAccounts.setIamPolicy dans le projet contenant le compte de service.

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Bloquer les jetons d'accès fédérés

  1. Effectuez l'une des actions suivantes :

  2. Pour bloquer l'accès immédiat aux jetons porteurs actifs (valables jusqu'à une heure), effectuez l'une des actions suivantes :

    • Pour bloquer l'accès direct aux ressources, révoquez les rôles IAM pour le principal ou le principalSet concernés, ou appliquez une stratégie IAM de refus temporaire.

    • Si l'identité fédérée emprunte l'identité d'un compte de service (roles/iam.workloadIdentityUser), suivez la procédure Clés et jetons de compte de service. Pour éviter de futurs problèmes d'emprunt d'identité, supprimez la liaison de rôle d'emprunt d'identité.

  3. Dans votre fournisseur d'identité, faites tourner les identifiants compromis, révoquez les sessions actives ou supprimez l'entité compromise.

Cookies de navigateur

Pour invalider les cookies de navigateur d'un utilisateur, procédez comme suit.

Rôles requis

Pour obtenir les autorisations dont vous avez besoin pour déconnecter un utilisateur et forcer la modification de son mot de passe dans la console d'administration Google Workspace, demandez à votre administrateur de vous attribuer le rôle d'administrateur de la gestion des utilisateurs ou de super-administrateur.

Pour en savoir plus sur l'attribution de rôles d'administrateur dans Google Workspace, consultez Désigner un utilisateur comme administrateur.

Invalider les cookies de navigateur

Si vous pensez que des cookies de navigateur ont été piratés, effectuez l'une des actions suivantes :

Ces actions invalident tous les cookies existants, et l'utilisateur est invité à se reconnecter.

Examiner les accès et ressources non autorisés après la révocation des identifiants

Après avoir révoqué les identifiants piratés et restauré votre service, vérifiez tous les accès à vos ressources Google Cloud . Vous pouvez utiliser Cloud Logging ou Security Command Center.

Rôles requis

Pour obtenir les autorisations nécessaires pour examiner les accès et ressources non autorisés, demandez à votre administrateur de vous accorder les rôles IAM suivants :

  • Afficher les journaux d'audit dans Logging : Lecteur de journaux (roles/logging.viewer) sur le projet, le dossier ou l'organisation
  • Afficher les journaux d'audit pour l'accès aux données dans Logging : Lecteur de journaux privés (roles/logging.privateLogViewer) sur le projet, le dossier ou l'organisation
  • Afficher les résultats dans Security Command Center : Lecteur de résultats du centre de sécurité (roles/securitycenter.findingsViewer) sur le projet ou l'organisation

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour examiner les accès et les ressources non autorisés. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Vous devez disposer des autorisations suivantes pour examiner les accès et les ressources non autorisés :

  • Afficher les journaux d'audit dans Logging :
    • logging.logEntries.list sur le projet, le dossier ou l'organisation
    • logging.views.access sur le projet, le dossier ou l'organisation
  • Afficher les journaux d'audit pour l'accès aux données dans Logging : logging.privateLogEntries.list sur le projet, le dossier ou l'organisation
  • Affichez les résultats dans Security Command Center :
    • securitycenter.findings.list sur le projet ou l'organisation
    • securitycenter.findings.get sur le projet ou l'organisation

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Examiner les accès et les ressources non autorisés

Dans Logging, procédez comme suit :

  1. Examinez vos journaux d'audit dans la consoleGoogle Cloud .

    Accéder à l'explorateur de journaux

  2. Recherchez toutes les ressources potentiellement concernées et assurez-vous qu'aucune des activités du compte (concernant plus particulièrement les identifiants piratés) ne révèle un comportement inhabituel.

    Par exemple, effectuez les opérations suivantes :

    • Recherchez tous les appels d'API initiés par l'identité compromise pendant la période de l'incident.
    • Si l'identité disposait de droits d'usurpation d'identité, recherchez les actions où protoPayload.authenticationInfo.serviceAccountDelegationInfo.firstPartyPrincipal.principalEmail correspond au compte principal compromis.
    • Vérifiez si de nouvelles clés de compte de service, de nouveaux comptes utilisateur ou de nouvelles clés SSH au niveau du projet ont été créés pendant l'incident.

Dans Security Command Center, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Résultats de Security Command Center.

    Accéder

  2. Si nécessaire, sélectionnez votre Google Cloud projet ou votre organisation.

  3. Dans la section Filtres rapides, cliquez sur un filtre approprié pour afficher le résultat dont vous avez besoin dans le tableau Résultats de la requête de résultats. Par exemple, si vous sélectionnez Event Threat Detection ou Container Threat Detection dans la sous-section Nom à afficher pour la source, seuls les résultats du service sélectionné s'affichent dans les résultats.

    Le tableau est rempli avec les résultats de la source sélectionnée.

  4. Pour afficher les détails d'un résultat spécifique, cliquez sur le nom du résultat sous Catégorie. Le volet de détails du résultat se développe pour afficher un résumé des détails du résultat.

  5. Pour afficher tous les résultats issus des actions du même utilisateur, procédez comme suit :

    1. Dans le volet des détails du résultat, copiez l'adresse e-mail située à côté de Adresse e-mail principale.
    2. Fermez le volet.

    3. Dans l'éditeur de requêtes, saisissez la requête suivante :

      access.principal_email="USER_EMAIL"

      Remplacez USER_EMAIL par l'adresse e-mail que vous avez copiée précédemment.

      Security Command Center affiche tous les résultats associés aux actions effectuées par l'utilisateur que vous avez spécifié.

Supprimer toutes les ressources non autorisées

Vérifiez qu'il n'existe aucune ressource inhabituelle (telles que des machines virtuelles, des applications App Engine, des comptes de service et des buckets Cloud Storage) à laquelle les identifiants piratés tenteraient d'accéder.

Une fois que vous avez identifié toutes les ressources non autorisées, vous pouvez les supprimer immédiatement. Il est particulièrement important d'agir immédiatement pour les ressources Compute Engine, car les pirates informatiques peuvent utiliser des comptes piratés pour exfiltrer des données ou compromettre d'une autre manière vos systèmes de production.

Pour supprimer des ressources non autorisées, consultez la documentation suivante :

Vous pouvez également isoler les ressources non autorisées afin de permettre à vos propres équipes d'investigation d'effectuer une analyse supplémentaire.

Contacter le service client

Pour obtenir de l'aide sur la recherche des journaux et des outils Google Cloud nécessaires à vos étapes d'investigation et d'atténuation des risques, contactez le service client Cloud et déposez une demande d'assistance.

Gérer les pertes d'accès aux comptes

Si vous n'arrivez pas du tout à accéder à votre compte, voici quelques options à envisager :

  • Utilisez le formulaire de récupération de compte Google Workspace, disponible dans la Google Workspace Admin Toolbox. Pour en savoir plus, consultez Récupérer l'accès administrateur à votre compte.

  • Si un pirate informatique crée des ressources frauduleuses alors que vous êtes complètement bloqué et que vous avez droit à l'assistance, procédez comme suit :

    1. Dans une fenêtre de navigation privée, accédez à l'outil de dépannage pour contacter l'assistance.

    2. Sélectionnez Oui, puis cliquez sur Envoyer une demande.

    3. Remplissez et envoyez le formulaire en indiquant vos coordonnées.

  • Si un pirate informatique crée des ressources frauduleuses alors que vous êtes complètement bloqué et que vous ne disposez pas d'un droit d'accès à l'assistance, procédez comme suit :

    1. Dans une fenêtre de navigation privée, accédez à l'outil de dépannage pour contacter l'assistance.

    2. Répondez aux questions comme suit :

      Question de l'outil de dépannage Sélection requise
      Disposez-vous d'un droit d'accès à l'assistance ? Non
      Votre période d'essai sans frais est-elle en cours ? Non
      Êtes-vous l'administrateur de la facturation d'un compte de facturation GCP (Google Cloud) ? Non
      Rencontrez-vous l'une de ces situations ? Je n'ai plus accès à mon projet GCP ni à mon compte de facturation, et je dois le récupérer.

    3. Cliquez sur Envoyer une demande à notre équipe de récupération d'accès.

    4. Remplissez et envoyez le formulaire de contact non authentifié avec vos informations, y compris les ID de compte de facturation ou les indicateurs de paiement que vous pouvez fournir pour valider votre identité.

Étapes suivantes

Mettez en œuvre les bonnes pratiques suivantes pour éviter les problèmes liés aux identifiants piratés :