Bonnes pratiques pour limiter les risques de compromission de jetons OAuth pour Google Cloud CLI

Last reviewed 2024-02-15 UTC

Ce document explique comment atténuer l'impact d'un pirate informatique qui parviendrait à compromettre les jetons OAuth utilisés par gcloud CLI.

Un pirate informatique peut compromettre ces jetons OAuth s'il a accès à un point de terminaison sur lequel un compte utilisateur légitime ou un compte de service s'est déjà authentifié avec gcloud CLI. Le pirate informatique peut ensuite copier ces jetons vers un autre point de terminaison, dont il a le contrôle, afin d'émettre des requêtes qui vont usurper l'identité légitime. Même si vous supprimez l'accès du pirate au point de terminaison compromis, il peut continuer à émettre des requêtes API authentifiées à l'aide des jetons copiés. Pour limiter ce risque, vous pouvez contrôler l'accès à vos systèmes à l'aide d'identifiants éphémères et offrant un accès contextuel.

Ce document est destiné aux équipes de sécurité ou aux architectes cloud chargés de sécuriser leurs ressources cloud contre tout accès illégitime. Il présente les contrôles disponibles permettant de réduire de manière proactive l'impact d'une compromission de jetons OAuth utilisés par gcloud CLI, et de corriger votre environnement après qu'un point de terminaison a été compromis.

Présentation

Pour comprendre le fonctionnement de cette menace, vous devez comprendre comment gcloud CLI stocke les identifiants OAuth 2.0 et comment ces identifiants peuvent être utilisés de manière abusive s'ils sont compromis par un pirate informatique.

Types d'identifiants stockés par gcloud CLI

gcloud CLI utilise des jetons d'accès OAuth 2.0 pour authentifier les requêtes des API Google Cloud. Le flux OAuth varie en fonction des types d'identifiants utilisés, mais le jeton d'accès et les autres identifiants sont généralement accessibles localement. Dans chaque cas, le jeton d'accès expire au bout de 60 minutes, mais d'autres types d'identifiants peuvent être persistants.

Lorsque vous définissez une autorisation de gcloud CLI basée sur un compte utilisateur, gcloud CLI lance un flux d'autorisation OAuth à trois acteurs pour accéder aux API Google Cloud au nom de l'utilisateur. Une fois que l'utilisateur a terminé le processus d'autorisation, gcloud CLI reçoit un jeton d'accès, ainsi qu'un jeton d'actualisation qui lui permet de demander de nouveaux jetons d'accès. Dans les paramètres par défaut, le jeton d'actualisation de longue durée est conservé jusqu'à ce que ses conditions d'expiration soient remplies.

Lorsque vous définissez une autorisation de gcloud CLI basée sur un compte de service, gcloud CLI lance un flux OAuth à deux acteurs pour accéder aux API Google Cloud avec l'identité du compte de service. Une fois que vous avez activé un compte de service à partir d'un fichier de clé privée, cette clé permet de demander périodiquement un jeton d'accès. La clé privée de longue durée est stockée dans la configuration de gcloud CLI et reste valide jusqu'à ce que vous supprimiez la clé de compte de service.

Lorsque vous exécutez gcloud CLI dans un environnement Google Cloud, tel que Compute Engine ou Cloud Shell, l'application peut automatiquement trouver les identifiants et s'authentifier en tant que compte de service. Par exemple, dans Compute Engine, une application telle que gcloud CLI peut interroger le serveur de métadonnées pour obtenir un jeton d'accès. Google gère et fait pivoter la clé de signature privée utilisée pour créer le jeton d'accès, et les identifiants de longue durée ne sont pas exposés à l'application.

Lorsque vous vous authentifiez avec la fédération d'identité de charge de travail, les applications s'authentifient à partir d'un identifiant provenant d'un fournisseur d'identité externe et reçoivent un jeton d'accès fédéré de courte durée. Pour en savoir plus sur le stockage et la gestion des identifiants de longue durée utilisés par le fournisseur d'identité externe, consultez la page Bonnes pratiques pour utiliser la fédération d'identité de charge de travail.

Comment un pirate informatique peut utiliser des jetons OAuth compromis

Si un pirate informatique parvient à compromettre un point de terminaison, les identifiants tels que les jetons OAuth vont constituer des cibles de choix, car ils permettent aux pirates informatiques de conserver ou d'augmenter leur accès.

Un développeur peut devoir légitimement afficher ses propres identifiants lors de l'écriture et du débogage de code. Par exemple, un développeur peut avoir besoin de s'authentifier pour utiliser les requêtes REST auprès des services Google Cloud lorsqu'il travaille avec une bibliothèque cliente non compatible. Le développeur dispose de différentes méthodes pour afficher ses identifiants :

Toutefois, un pirate informatique peut utiliser ces mêmes techniques après avoir compromis un point de terminaison.

Si un pirate informatique compromet un point de terminaison, tel qu'un poste de travail de développeur, la menace principale est qu'il va pouvoir exécuter des commandes gcloud CLI ou d'autres portions de code en se servant des identifiants légitimes de l'identité authentifiée. En outre, le pirate informatique peut copier les jetons OAuth sur un autre point de terminaison qu'il contrôle, afin de conserver son accès. Il existe aussi une menace secondaire associée à ce vol d'identifiants : le pirate informatique peut toujours utiliser les jetons OAuth de longue durée pour obtenir un accès persistant, même après que vous avez supprimé l'accès au point de terminaison compromis.

Si le pirate informatique parvient à compromettre les jetons OAuth, il peut effectuer les actions suivantes :

  • Il peut usurper l'identité de l'utilisateur ou du compte de service compromis. Le trafic d'API qui utilise les jetons compromis est consigné comme s'il provenait de l'utilisateur ou du compte de service compromis, d'où une distinction complexe dans les journaux entre activité normale et activité malveillante.
  • Il peut actualiser indéfiniment le jeton d'accès à l'aide d'un jeton d'actualisation persistant, associé à un utilisateur ou à une clé privée associée à un compte de service.
  • Il peut contourner l'authentification demandant le mot de passe de l'utilisateur ou la validation en deux étapes, car les jetons sont accordés après le flux de connexion.

Bonnes pratiques pour limiter les risques

Mettez en œuvre les contrôles décrits dans les sections suivantes pour réduire le risque de compromission de jetons gcloud CLI. Si vous suivez les bonnes pratiques de sécurité décrites dans le plan de base de l'entreprise ou dans la conception de la zone de destination dans Google Cloud, vous disposez peut-être déjà de ces contrôles.

Définir la durée de session pour les services Google Cloud

Pour réduire la durée d'exploitation d'un jeton compromis, définissez la durée de session pour les services Google Cloud. Par défaut, le jeton d'actualisation accordé par le système après l'authentification est un identifiant de longue durée, et une session gcloud CLI ne nécessite jamais de réauthentification. Modifiez ce paramètre pour configurer une règle de réauthentification avec une durée de session comprise entre 1 et 24 heures. Une fois la durée de session écoulée, la règle de réauthentification annule la validation du jeton d'actualisation et oblige l'utilisateur à se réauthentifier régulièrement sur gcloud CLI avec son mot de passe ou sa clé de sécurité.

La durée de session pour les services Google Cloud est un paramètre distinct de la durée de session pour les services Google, qui contrôle les sessions Web pour la connexion aux services Google Workspace, mais ne contrôle pas la réauthentification pour Google Cloud. Si vous utilisez les services Google Workspace, définissez également la durée de session pour ceux-ci.

Configurez VPC Service Controls

Configurez VPC Service Controls dans votre environnement pour garantir que seul le trafic d'API Google Cloud provenant du périmètre que vous avez défini peut accéder aux ressources compatibles. Le périmètre de service limite l'utilité des identifiants compromis, car il bloque les requêtes adressées à des services restreints provenant de points de terminaison contrôlés par le pirate informatique et extérieurs à votre environnement.

Configurer Chrome Enterprise Premium

Configurez des règles Chrome Enterprise Premium pour sécuriser la console Google Cloud et les API Google Cloud. Configurez un niveau d'accès Chrome Enterprise Premium et une liaison visant à autoriser de manière sélective les attributs évalués lors de chaque requête API, y compris l'accès basé sur les adresses IP ou l'accès basé sur les certificats pour l'authentification TLS mutuelle. Les requêtes qui utilisent des identifiants d'autorisation compromis, mais qui ne répondent pas aux conditions définies dans votre règle Chrome Enterprise Premium, seront rejetées.

Chrome Enterprise Premium est un contrôle centré sur l'utilisateur qui rejette le trafic utilisateur des API qui ne répond pas aux conditions définies. VPC Service Controls est un contrôle centré sur les ressources qui définit les périmètres au sein desquels les ressources peuvent communiquer. VPC Service Controls s'applique à toutes les identités d'utilisateur et identités de compte de service ; en revanche, Chrome Enterprise Premium ne s'applique qu'aux identités d'utilisateur de votre organisation. Lorsqu'ils sont utilisés conjointement, Chrome Enterprise Premium et VPC Service Controls réduisent l'efficacité des identifiants compromis sur une machine contrôlée par un pirate informatique en dehors de votre environnement.

Appliquer la validation en deux étapes pour accéder au serveur distant

Si vous autorisez les développeurs à accéder aux ressources Compute Engine via SSH, configurez OS Login avec la validation en deux étapes. Cela consiste à définir un point de contrôle supplémentaire, selon lequel l'utilisateur doit s'authentifier de nouveau avec son mot de passe ou sa clé de sécurité. Un pirate informatique disposant de jetons OAuth compromis, mais d'aucun mot de passe ni clé de sécurité, va se retrouver bloqué par cette fonctionnalité.

L'accès RDP (Remote Desktop Protocol) aux instances Windows sur Compute Engine n'est pas compatible avec le service OS Login. Par conséquent, la validation en deux étapes ne peut pas être appliquée de manière précise pour les sessions RDP. Lorsque vous utilisez des plug-ins RDP pour IAP Desktop ou Google Chrome, définissez des contrôles plus précis, tels que la durée de session pour les services Google et les paramètres de validation en deux étapes des sessions Web de l'utilisateur, et désactivez le paramètre Autoriser l'utilisateur à faire confiance à son appareil dans les paramètres de validation en deux étapes.

Restreindre l'utilisation des clés de compte de service

Lorsque vous utilisez une clé de compte de service pour l'authentification, la valeur de la clé est stockée dans les fichiers de configuration de gcloud CLI, séparément du fichier de clé téléchargé. Un pirate informatique ayant accès à votre environnement pourrait copier la clé à partir de la configuration de gcloud CLI, ou copier le fichier de clé à partir de votre système de fichiers local ou de votre dépôt de code interne. Par conséquent, en plus de votre plan d'atténuation des jetons d'accès compromis, vous devez étudier la façon dont vous gérez les fichiers de clé de compte de service téléchargés.

Examinez des alternatives plus sécurisées pour l'authentification afin de réduire ou d'éliminer les cas d'utilisation qui dépendent d'une clé de compte de service, et appliquez la contrainte de règle d'administration iam.disableServiceAccountKeyCreation pour désactiver la création de clés de compte de service.

Envisager de recourir au principe du moindre privilège

Lorsque vous concevez des stratégies IAM, gardez en tête le principe du moindre privilège. Accordez aux utilisateurs les rôles dont ils ont besoin pour accomplir une tâche, en cherchant à limiter le plus possible leur champ d'action : ne leur accordez pas de rôles dont ils n'ont pas besoin. Étudiez les recommandations concernant les rôles et mettez-les en application, pour éviter de définir dans votre environnement des stratégies IAM mêlant des rôles inutilisés, et des rôles offrant trop de possibilités.

Protéger vos points de terminaison

Déterminez comment un pirate informatique peut obtenir un accès physique ou distant à vos points de terminaison, tels que des postes de travail de développeur ou des instances Compute Engine. Bien qu'il soit important de définir un plan pour répondre à la menace de compromission de jetons OAuth, réfléchissez également comment répondre en premier lieu au risque de compromission de vos points de terminaison de confiance par un pirate informatique. Si celui-ci parvient à accéder à vos points de terminaison de confiance, il pourra exécuter des commandes gcloud CLI ou d'autres portions de code directement sur le point de terminaison.

Bien que la protection complète des postes de travail de développeur dépasse le cadre de ce document, évaluez la manière dont vos outils et opérations de sécurité peuvent vous aider à protéger et à surveiller vos points de terminaison. Posez-vous les questions suivantes :

  • Comment la sécurité physique des postes de travail de développeur est-elle assurée ?
  • Comment identifier et résoudre les violations de réseau ?
  • Comment les utilisateurs obtiennent-ils un accès à distance aux sessions SSH ou RDP ?
  • Comment d'autres identifiants persistants, tels que les clés SSH ou les clés de compte de service, peuvent-ils être compromis ?
  • Certains workflows utilisent-ils des identifiants persistants et pourraient-ils être remplacés par des identifiants éphémères ?
  • Existe-t-il des appareils partagés sur lesquels un utilisateur pourrait consulter les identifiants gcloud CLI d'un autre utilisateur, mis en cache ?
  • Un utilisateur peut-il s'authentifier sur gcloud CLI à partir d'un appareil non vérifié ?
  • Comment le trafic approuvé se connecte-t-il aux ressources au sein de votre périmètre VPC Service Controls ?

Assurez-vous que vos opérations de sécurité apportent une réponse à chacune de ces questions.

Aligner vos équipes de réponse

Assurez-vous à l'avance que les équipes de sécurité responsables de la gestion des incidents disposent d'un accès approprié sur la console Google Cloud et la console d'administration. Si des équipes distinctes gèrent la console Google Cloud et la console d'administration, vous risquez d'obtenir une réponse retardée lors d'un incident.

Pour supprimer l'accès d'un compte utilisateur compromis, votre équipe de gestion des incidents doit disposer d'un rôle associé à la console d'administration, tel que Administrateur des comptes utilisateur. Pour évaluer si une activité suspecte s'est produite dans vos ressources Google Cloud, cette équipe peut également avoir besoin de rôles IAM, tels que le rôle "Examinateur de sécurité", accordé pour tous les projets, ou bien le rôle "Lecteur de journaux" sur un récepteur de journaux centralisé. Les rôles nécessaires à votre équipe de sécurité varient en fonction de la conception et du fonctionnement de votre environnement.

Bonnes pratiques pour définir des mesures correctives après un incident de sécurité

Concernant votre plan de gestion des incidents, 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 comment atténuer les dommages potentiels pouvant résulter de 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é. Si vous pensez que des jetons gcloud CLI sont compromis, créez une demande d'assistance via Cloud Customer Care et suivez les recommandations figurant dans les sections suivantes. Ces actions peuvent contribuer à limiter l'impact d'un tel événement dans votre organisation Google Cloud.

Les recommandations de cette section correspondent aux consignes générales sur la gestion des identifiants Google Cloud compromis, mais se concentrent spécifiquement sur la menace des jetons de CLI gcloud copiés à partir d'un point de terminaison compromis.

Révoquer les jetons actifs pour tous les comptes utilisateur avec le contrôle de session Google Cloud

Si vous n'avez pas encore appliqué le contrôle de session Google 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.

Annuler manuellement la validation des jetons pour les comptes utilisateur piratés

Consultez les conseils de gestion des identifiants piratés pour toutes les identités d'utilisateur qui auraient pu être compromises. En particulier, la suppression des identifiants gcloud CLI constitue la méthode la plus efficace pour une équipe de sécurité cherchant à résoudre la compromission de jetons OAuth pour des identités d'utilisateurs. Pour annuler immédiatement la validation des jetons d'actualisation et des jetons d'accès pour gcloud CLI, et forcer l'utilisateur à s'authentifier de nouveau avec son mot de passe ou sa clé de sécurité, supprimez gcloud CLI de la liste des applications connectées d'un utilisateur.

Un utilisateur spécifique peut également supprimer les identifiants gcloud CLI pour son compte individuel.

D'autres méthodes, telles que la suspension de l'utilisateur, la réinitialisation de son mot de passe ou la réinitialisation des cookies de connexion n'apportent pas de réponse spécifique à la menace de compromission de jetons OAuth. Ces méthodes sont généralement utiles pour la gestion des incidents, mais elles n'annulent pas la validation des jetons d'accès déjà contrôlés par le pirate. Par exemple, si vous avez décidé de suspendre un utilisateur lors d'une enquête, mais que vous ne révoquez pas les jetons gcloud CLI, les jetons d'accès peuvent toujours être valides si l'utilisateur suspendu est restauré avant l'expiration des jetons d'accès.

Annuler de manière automatisée la validation des jetons 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 d'opérations de sécurité, lors de tests portant sur quelques utilisateurs.

L'exemple de code suivant utilise le SDK Admin 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)
      }
    }
  }
}

Annuler la validation et définir une rotation des identifiants pour les comptes de service

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 ou des commandes telles que gcloud auth revoke. En outre, la durée de session spécifiée dans le contrôle de session Google 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.

Si vous pensez que les identifiants d'un compte de service ont été piratés, désactivez le compte de service, supprimez les clés de compte de service, le cas échéant, attendez 60 minutes, puis activez le compte de service. La suppression d'une clé de compte de service peut annuler la validation d'un identifiant de longue durée, afin qu'un pirate informatique ne puisse pas demander de nouveau jeton d'accès. En revanche, elle n'annule pas la validation des jetons d'accès déjà accordés. Pour vous assurer que les jetons d'accès ne sont pas utilisés de manière abusive pendant leur durée de vie de 60 minutes, vous devez désactiver le compte de service pendant 60 minutes.

Vous pouvez également supprimer et remplacer le compte de service afin de révoquer immédiatement tous les identifiants de courte durée et de longue durée, mais le remplacement du compte de service dans les applications peut engendrer davantage de perturbations.

Étapes suivantes