Bonnes pratiques pour protéger les identifiants SSH

Ce document décrit les bonnes pratiques à adopter pour protéger les identifiants SSH.

Par défaut, Compute Engine utilise l'authentification SSH basée sur une clé publique : les utilisateurs sont authentifiés par un élément en leur possession, à savoir une clé privée SSH. Si les clés privées des utilisateurs ne sont pas correctement sécurisées, elles peuvent tomber entre les mains d'acteurs malintentionnés qui pourraient les utiliser pour accéder à vos instances de VM.

Les sections suivantes décrivent les bonnes pratiques qui vous aideront à éviter les fuites de clés et à réduire l'impact potentiel d'une divulgation des clés privées :

Ce document est consacré aux pratiques spécifiques à Google Cloud ou particulièrement adaptées lors de l'utilisation de SSH sur Google Cloud. Il n'aborde pas les bonnes pratiques de mises en œuvre spécifiques d'un client ou d'un serveur SSH.

Traiter les clés privées SSH de la même manière que les clés de compte de service

Certaines de vos instances de VM peuvent disposer d'un compte de service associé. Associer un compte de service à une VM permet aux charges de travail exécutées sur ces VM de demander des jetons d'accès de courte durée au serveur de métadonnées, afin qu'elles puissent accéder aux API et aux ressources Google Cloud.

Lorsque vous vous connectez à une VM avec un compte de service associé à l'aide de SSH, vous pouvez également demander des jetons d'accès éphémères au serveur de métadonnées. Accorder à un utilisateur un accès SSH à une VM est donc semblable à lui accorder l'autorisation d'agir en tant que compte de service associé. En raison de cette similitude, traitez les clés privées SSH, en particulier lorsqu'elles ne sont pas protégées par une phrase secrète, comme des clés de compte de service : si elles sont divulguées, ces deux types de clés peuvent accorder à un pirate informatique l'accès aux ressources Google Cloud.

Utiliser des clés SSH éphémères pour les utilisateurs de machines

Les pipelines de déploiement ou les processus d'automatisation peuvent nécessiter un accès SSH aux instances de VM pour effectuer des déploiements ou appliquer des modifications de configuration. Au lieu de laisser ces charges de travail utiliser une paire de clés SSH à long terme, laissez-les utiliser une nouvelle clé SSH éphémère à chaque exécution.

Pour utiliser des clés SSH éphémères, laissez vos pipelines de déploiement ou vos processus d'automatisation effectuer les étapes suivantes :

  1. Authentifiez-vous en tant que compte de service sans impliquer de clé ni de secret, par exemple à l'aide d'un compte de service associé ou de la fédération d'identité de charge de travail.
  2. Générez une paire de clés SSH temporaire à l'aide d'un outil tel que ssh-keygen.

  3. Publiez la clé publique sur Google Cloud en spécifiant une date d'expiration proche (par exemple, 1 heure dans le futur).

    OS Login vous permet de spécifier une date d'expiration de clé lorsque vous publiez une clé. De même, vous pouvez spécifier une date d'expiration lorsque vous publiez une clé publique SSH dans les métadonnées du projet ou de la VM.

  4. Utilisez la clé privée pour établir des connexions SSH avec des instances de VM.

  5. Si vous le souhaitez, annulez la publication de la clé publique et supprimez la clé privée.

Exemple :

# Generate RSA2048 key pair without passphrase
ssh-keygen -b 2048 -t rsa -f ephemeral_key -q -N "" -V 30m

# Publish key to the service account's OS Login profile, with 30 min expiry
gcloud compute os-login ssh-keys add --key-file ephemeral_key.pub --ttl 30m

# Look up the service account's UNIX username
USERNAME=$(gcloud compute os-login describe-profile --format "value(posixAccounts[0].username)")

# Authenticate using the service account's UNIX user and public key
ssh $USERNAME@VM whoami

# Remove key
gcloud compute os-login ssh-keys remove --key-file ephemeral_key.pub

Bien qu'une clé privée SSH éphémère puisse toujours être divulguée, elle ne peut être utilisée que pendant une courte période. L'utilisation de clés SSH éphémères peut donc réduire le risque de fuite d'identifiants et vous permet d'utiliser Cloud IAM comme moyen principal d'authentification et d'autorisation.

Utiliser IAP pour compléter l'authentification par clé publique SSH

Par défaut, les clés privées SSH peuvent être utilisées indépendamment des identifiants Google : si la clé privée SSH d'un utilisateur est divulguée, une personne malintentionnée peut l'utiliser pour se connecter et s'authentifier auprès de toutes les instances de VM auxquelles la clé est autorisée à accéder. Le pirate informatique n'a pas besoin de connaître le nom d'utilisateur ou le mot de passe de l'utilisateur, ni même de posséder des identifiants Google.

Des contrôles de sécurité tels que la validation en deux étapes et la limitation de la durée de session pour les services Google Cloud peuvent être des moyens efficaces de réduire le risque de vol d'identifiants, mais ils ne s'appliquent qu'aux ressources qui nécessitent des identifiants Google.

Afin de vous assurer que les clés SSH ne peuvent pas être utilisées sans identifiants Google valides, utilisez IAP pour régir l'accès SSH et utilisez des stratégies de pare-feu pour vous assurer que tous les accès SSH sont effectués via IAP.

IAP agit en tant que proxy inverse et n'autorise les utilisateurs à établir des connexions SSH aux instances de VM que s'ils se sont authentifiés avec leurs identifiants Google. En outre, IAP vous permet de limiter les VM auxquelles les utilisateurs peuvent se connecter et d'appliquer l'accès contextuel.

Utiliser l'authentification multifacteur

L'utilisation d'IAP pour gérer l'accès SSH rend plus difficile pour une personne malintentionnée d'accéder aux instances de VM à l'aide d'identifiants divulgués, mais ne l'empêche pas. Par exemple, une personne malintentionnée peut compromettre un poste de travail et trouver à la fois une clé SSH privée et des identifiants gcloud CLI mis en cache, suffisants pour passer les vérifications d'authentification et d'autorisation IAP, et pour se connecter aux instances de VM de l'utilisateur.

Vous pouvez réduire l'impact potentiel de ces attaques de vol d'identifiants en configurant Cloud Identity ou Google Workspace pour exiger une authentification multifacteur (MFA).

Si Cloud Identity ou Google Workspace est votre fournisseur d'identité principal, procédez comme suit pour appliquer la MFA :

  1. Configurez Cloud Identity ou Google Workspace pour appliquer la validation en deux étapes.
  2. Limitez la durée de session pour les services Google Cloud afin que les identifiants mis en cache soient automatiquement invalidés et que les utilisateurs doivent se réauthentifier régulièrement et effectuer l'authentification multifacteur.

Si vous utilisez l'authentification unique avec un fournisseur d'identité externe, procédez comme suit :

  1. Configurez Cloud Identity ou Google Workspace pour limiter la durée de session des services Google Cloud afin que les identifiants mis en cache soient automatiquement invalidés et que les utilisateurs doivent se réauthentifier régulièrement à l'aide du fournisseur d'identité externe.
  2. Configurez votre fournisseur d'identité externe pour qu'il exige l'authentification MFA et limitez la durée de sa session afin que les utilisateurs doivent l'effectuer chaque fois que leur session Google Cloud expire.

Pour vous assurer que l'authentification multifacteur s'applique également à l'accès SSH, vous devez également effectuer au moins l'une des opérations suivantes :

  1. Utilisez IAP pour contrôler l'accès au réseau afin que les utilisateurs doivent effectuer régulièrement l'authentification multifacteur pour actualiser leurs identifiants Google.
  2. Activez l'authentification 2FA d'OS Login pour des instances de VM individuelles ou des projets entiers afin que les utilisateurs doivent effectuer l'authentification multifacteur chaque fois qu'ils établissent une connexion SSH.

Les utilisateurs disposant du rôle Administrateur d'instances Compute ou d'un rôle équivalent pour une instance de VM ou un projet peuvent désactiver OS Login 2FA en modifiant les métadonnées de l'instance. L'efficacité de l'authentification 2FA d'OS Login est donc limitée si vous n'appliquez pas également l'authentification multifacteur dans Cloud Identity ou votre fournisseur d'identité externe.

Utiliser des clés privées non exportables ou protégées par une phrase secrète

De nombreux clients SSH stockent par défaut les clés privées SSH sous forme de fichiers sur disque. Par exemple, gcloud compute ssh génère une paire de clés SSH lors de la première utilisation et la stocke dans votre répertoire d'accueil. Votre système d'exploitation peut protéger vos fichiers contre d'autres utilisateurs, mais si une personne malintentionnée parvient à contourner les autorisations du système de fichiers (par exemple, en copiant et en installant le disque sur une autre machine), il peut copier la clé ailleurs et l'utiliser à votre insu.

Certains clients SSH vous permettent d'éviter d'utiliser des clés basées sur des fichiers et proposent d'autres options pour gérer les clés privées SSH, par exemple :

  • Utiliser une clé matérielle : les versions modernes d'OpenSSH vous permettent d'utiliser des clés de sécurité FIDO2 pour l'authentification, et vous pouvez configurer OS Login pour qu'il n'autorise que les clés de sécurité enregistrées dans Cloud Identity ou Google Workspace. L'utilisation de clés matérielles vous permet d'éviter de stocker du matériel de clé privée sur le système de fichiers de votre ordinateur.
  • Utilisation des installations de stockage de clés de votre système d'exploitation : par exemple, IAP Desktop évite d'utiliser des clés basées sur des fichiers et utilise à la place Windows CNG pour protéger vos clés SSH.

Si vous ne pouvez pas utiliser de clés basées sur du matériel ou gérées par le système d'exploitation, vous pouvez utiliser une phrase secrète pour protéger votre clé privée SSH. Pour utiliser une clé SSH protégée par une phrase secrète, un pirate informatique a besoin non seulement d'une copie de la clé privée, mais aussi de connaître la phrase secrète de la clé.

Utiliser des clés d'hôte pour authentifier l'hôte

Lorsque vous créez une connexion SSH à une instance de VM, vous identifiez l'instance de VM par son nom ou son adresse IP. Les noms et les adresses IP peuvent être réattribués et réutilisés. Le nom qui faisait référence à une certaine instance de VM hier ne fait peut-être pas référence à la même instance de VM aujourd'hui. Des personnes malintentionnées peuvent réattribuer ou réutiliser délibérément des noms ou des adresses IP pour falsifier des instances de VM et inciter les utilisateurs à se connecter à une VM compromise.

Les clients SSH peuvent détecter les situations où une instance de VM précédemment approuvée a été remplacée par une autre instance de VM à l'aide de clés d'hôte SSH : la clé d'hôte SSH d'une VM est générée au premier démarrage et permet d'identifier l'instance. Les clients SSH demandent et stockent généralement la clé d'hôte d'une VM lors de la première connexion, puis vérifient qu'elle n'a pas changé lors des connexions ultérieures.

Les clés d'hôte SSH fonctionnent selon le schéma de confiance lors de la première utilisation. L'efficacité des clés d'hôte SSH peut être compromise si une personne malintentionnée utilise une attaque MITM ("man in the middle") pour permettre à un client de se connecter à la mauvaise VM et d'approuver la mauvaise VM lors de la première utilisation. Le meilleur moyen d'obtenir une clé d'hôte consiste à l'obtenir via un canal secondaire approuvé avant de vous connecter à une VM pour la première fois.

Vous pouvez autoriser gcloud CLI à obtenir des clés d'hôte via un canal secondaire en activant les attributs d'invité dans votre projet. gcloud CLI lit ensuite la clé d'hôte d'une VM avant que vous ne vous y connectiez pour la première fois, et l'enregistre sur votre ordinateur local.

Ne laissez pas d'identifiants personnels sur les VM

Lorsque vous autorisez gcloud CLI, l'outil obtient un jeton d'actualisation OAuth et le stocke dans votre répertoire d'accueil local. Lorsque vous exécutez ensuite une commande gcloud CLI, gcloud CLI utilise le jeton d'actualisation pour vous authentifier automatiquement.

Il se peut que les autres utilisateurs ne puissent pas accéder à votre ordinateur local, mais, sur une instance de VM, votre répertoire d'accueil est également accessible aux autres utilisateurs disposant de privilèges sudo sur la VM.

Si un pirate informatique parvient à obtenir des privilèges sudo sur une VM, il peut rechercher des jetons de rafraîchissement et d'autres identifiants dans les répertoires d'accueil d'autres utilisateurs, et utiliser ces identifiants pour accroître ses privilèges ou étendre son accès à d'autres ressources (mouvement latéral).

Lorsque vous êtes connecté à une instance de VM via SSH, évitez d'autoriser gcloud CLI ou les identifiants par défaut de l'application (ADC) avec vos identifiants personnels, et laissez gcloud CLI utiliser le compte de service associé de la VM. De même, évitez d'exécuter d'autres outils susceptibles de stocker des identifiants personnels dans votre répertoire d'accueil.

Vous pouvez réduire davantage les risques en limitant la durée de session pour les services Google Cloud afin que les jetons d'actualisation OAuth stockés expirent automatiquement au bout d'un certain temps.

Ne pas envoyer de clés privées SSH aux dépôts de code source

Certains outils d'automatisation, comme Ansible, utilisent SSH pour accéder aux instances de VM et les gérer. Étant donné que ces outils peuvent avoir accès à de nombreuses instances de VM (et à leurs comptes de service associés), les clés privées SSH utilisées par ces outils peuvent être particulièrement sensibles.

Si vous envoyez une clé privée SSH à un dépôt de code source, vous augmentez le risque que des utilisateurs non autorisés et des personnes malintentionnées puissent y accéder :

  • Les acteurs malintentionnés peuvent analyser le code source des dépôts sources publics pour détecter les fuites de clés.
  • À l'avenir, vous pourrez décider de transformer un dépôt source privé en dépôt public sans avoir à vérifier les clés au préalable.
  • D'autres membres de l'équipe peuvent stocker des copies du code source sur leur poste de travail.

Pour atténuer ces risques, stockez la clé privée SSH dans un emplacement sécurisé distinct du code source et utilisez des clés SSH éphémères lorsque cela est possible.

Étape suivante