Bonnes pratiques pour contrôler l'accès à la connexion SSH

Ce document décrit les bonnes pratiques à suivre pour contrôler l'accès à la connexion SSH aux instances de machines virtuelles (VM) Linux.

Pour gérer efficacement l'accès SSH aux instances de VM, vous devez autoriser les utilisateurs à y accéder lorsqu'ils en ont besoin et révoquer cet accès lorsqu'ils n'en ont plus besoin. Si votre processus de révocation d'accès n'est pas fiable ou ne couvre pas toutes les ressources, des acteurs malintentionnés peuvent conserver l'accès même après que leur accès aurait dû être révoqué.

Les sections suivantes décrivent les bonnes pratiques qui vous aident à garantir une révocation efficace des accès et à vous protéger contre les menaces de persistance :

Ce document est consacré aux pratiques spécifiques à Google Cloud ou particulièrement pertinentes lorsque vous utilisez 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.

Utiliser OS Login pour assurer une évaluation continue des accès par rapport aux stratégies IAM

Les images Linux publiques de Compute Engine sont configurées pour autoriser l'authentification par clé publique SSH. Pour autoriser la clé publique d'un utilisateur et lui accorder l'autorisation d'établir une session SSH, vous pouvez utiliser l'un des deux mécanismes suivants :

  • Autorisation par clé basée sur les métadonnées : en tant qu'administrateur, vous importez la clé publique d'un utilisateur dans les métadonnées d'une VM ou du projet, ou vous laissez les utilisateurs effectuer l'importation eux-mêmes en accordant l'autorisation de modifier les métadonnées.

    Une clé publique importée dans les métadonnées d'une seule VM n'accorde les privilèges racine de l'utilisateur que sur la VM. Une clé importée dans les métadonnées du projet permet à un utilisateur d'accéder à toutes les VM du projet.

  • Autorisation de clé OS Login : en tant qu'utilisateur, vous importez une ou plusieurs clés publiques dans votre profil OS Login, qui fait partie de votre compte utilisateur Google.

    En tant qu'administrateur, vous pouvez décider d'accorder à un utilisateur des droits racine ou des droits d'utilisateur standards sur la VM en lui attribuant le rôle IAM Utilisateur administrateur OS Login ou le rôle IAM Utilisateur OS Login.

    gcloud CLI, le client SSH intégré au navigateur de la console Google Cloud et IAP Desktop détectent automatiquement le mécanisme que vous utilisez et peuvent importer la clé d'un utilisateur en conséquence.

Une différence clé entre les deux mécanismes est le moment où l'accès est évalué par rapport aux stratégies IAM :

  • Avec les clés de métadonnées, l'accès n'est évalué qu'une fois, au moment de l'importation de la clé.

    La clé de l'utilisateur est liée au cycle de vie de la VM ou du projet et reste valide jusqu'à ce que vous supprimiez la clé ou la VM ou le projet. La suspension ou la suppression du compte utilisateur n'a aucun effet sur la validité de ses clés.

  • Avec OS Login, l'accès est évalué chaque fois qu'un utilisateur tente d'établir une session SSH.

    La clé de l'utilisateur est liée au cycle de vie de son compte utilisateur. Si vous suspendez ou supprimez un utilisateur dans Cloud Identity ou Google Workspace, ses clés ne peuvent plus être utilisées pour accorder l'accès SSH.

L'utilisation de clés basées sur des métadonnées peut vous exposer à des menaces de persistance : les utilisateurs peuvent conserver l'accès SSH plus longtemps que nécessaire si leur clé publique n'est pas supprimée des métadonnées dans les meilleurs délais, et ils peuvent même conserver l'accès après avoir quitté l'organisation. Bien que vous puissiez réduire ce risque en parcourant régulièrement les métadonnées, cette opération peut s'avérer difficile dans les environnements plus vastes et peut s'avérer insuffisante, car les clés basées sur les métadonnées accordent aux utilisateurs des privilèges racine.

Pour vous protéger contre ces menaces persistantes, n'autorisez pas les utilisateurs à utiliser des clés basées sur des métadonnées. Configurez plutôt vos projets pour appliquer l'utilisation d'OS Login.

Utiliser des règles d'administration pour appliquer une utilisation cohérente d'OS Login

OS Login est contrôlé par la clé de métadonnéesenable-oslogin : Définir le paramètre enable-oslogin sur TRUE dans les métadonnées de projet ou d'instance active OS Login, tandis que la valeur FALSE désactive OS Login.

Pour modifier les métadonnées au niveau du projet, vous devez disposer de l'autorisation compute.projects.setCommonInstanceMetadata sur le projet. Cette autorisation fait partie des rôles Administrateur d'instances Compute (roles/compute.instanceAdmin.v1) et Administrateur Compute (roles/compute.admin). De même, la modification des métadonnées au niveau de l'instance nécessite l'autorisation compute.instances.setMetadata sur l'instance de VM correspondante.

Les métadonnées au niveau de l'instance prévalent sur les métadonnées au niveau du projet. Définir enable-oslogin sur TRUE dans les métadonnées du projet n'est donc pas suffisant pour appliquer l'utilisation d'OS Login tout au long du projet : les utilisateurs disposant du rôle Administrateur d'instances Compute ou d'un accès équivalent à une instance de VM du projet peuvent remplacer votre paramètre en ajoutant enable-oslogin=FALSE aux métadonnées de l'instance de VM.

Pour appliquer une utilisation cohérente d'OS Login, ne vous appuyez pas sur la définition de enable-oslogin sur TRUE dans les métadonnées du projet. Appliquez plutôt la section Activer OS Login pour une organisation à l'aide d'une règle d'administration afin que toute tentative de définition de enable-oslogin sur false dans les métadonnées d'instance ou de projet soit refusée.

Accorder des rôles avec accès privilégié de manière temporaire ou par VM

Si vous avez des instances de VM qui exécutent différentes charges de travail et qui sont gérées par différentes équipes, vous pouvez simplifier la gestion des accès en déployant ces VM dans différents projets Google Cloud et en laissant les projets utiliser un réseau partagé. Cependant, l'utilisation de projets distincts n'est pas toujours viable et certains de vos projets peuvent contenir une combinaison d'instances de VM, où différentes instances de VM ne doivent être accessibles qu'à différents utilisateurs.

Chaque fois qu'un projet contient une telle combinaison d'instances de VM différentes, évitez d'accorder définitivement des rôles tels que Administrateur d'instances Compute au niveau du projet. Faites plutôt la distinction entre l'accès en lecture seule et l'accès privilégié :

  • Attribuez aux utilisateurs le rôle Lecteur de Compute ou un rôle équivalent en lecture seule au niveau du projet. Ce rôle permet aux utilisateurs de parcourir des VM à l'aide de la console Google Cloud, mais ne leur permet pas de publier des clés SSH ni d'accéder aux VM.
  • Accordez aux utilisateurs les rôles Compute OS Login, Compute Instance Admin ou d'autres rôles privilégiés uniquement pour des VM individuelles ou à la demande uniquement.

Suspendre les comptes utilisateur lorsque les utilisateurs quittent l'organisation

La suspension ou la suppression d'un compte utilisateur dans Cloud Identity ou Google Workspace révoque automatiquement les autorisations IAM de l'utilisateur. Étant donné qu'OS Login vérifie les autorisations IAM d'un utilisateur avant de lui permettre d'établir une session SSH, la suspension ou la suppression d'un compte utilisateur révoque également son accès aux VM qui utilisent OS Login.

Si vous avez configuré Cloud Identity ou Google Workspace pour qu'ils utilisent un fournisseur d'identité externe pour l'authentification unique, les employés disposent d'un compte utilisateur à la fois dans votre fournisseur d'identité externe et dans Cloud Identity ou Google Workspace. La désactivation ou la suppression du compte utilisateur d'un employé dans votre fournisseur d'identité externe révoque sa capacité à établir de nouvelles sessions de navigateur pour accéder aux services Google, mais n'a pas d'impact immédiat sur OS Login : tant que le compte utilisateur Cloud Identity ou Google Workspace de l'employé reste actif, OS Login continuera de permettre à l'utilisateur de s'authentifier et d'établir des connexions SSH.

Pour révoquer de manière fiable l'accès SSH lorsqu'un utilisateur quitte l'organisation, veillez à suspendre ou à supprimer son compte utilisateur Cloud Identity ou Google Workspace. Si vous utilisez un IdP externe, configurez-le pour propager les événements de suspension des utilisateurs afin qu'OS Login puisse révoquer l'accès.

Éviter d'accorder l'accès SSH aux VM ayant un compte de service privilégié

Si une instance de VM est associée à un compte de service associé, les applications exécutées sur la VM peuvent demander des identifiants éphémères au serveur de métadonnées de la VM et utiliser ces identifiants pour agir en tant que compte de service.

L'accès SSH à une VM vous confère des droits similaires : comme pour une application, vous pouvez demander des identifiants éphémères au serveur de métadonnées de la VM et agir en tant que compte de service associé.

Étant donné que l'accès SSH à une VM avec un compte de service associé vous permet d'agir en tant que compte de service, OS Login nécessite que vous disposiez de l'autorisation iam.serviceAccounts.actAs sur le compte de service et vérifie cette autorisation à chaque fois que vous vous connectez à l'instance de VM. De cette façon, OS Login permet de maintenir la sécurité du compte de service et d'éviter toute utilisation abusive de l'accès SSH à des fins d'élévation des privilèges.

Pour atténuer davantage les risques associés aux VM disposant de comptes de service privilégiés, envisagez les alternatives suivantes :

  • N'associez pas de compte de service à la VM, sauf si la charge de travail nécessite un accès aux ressources Google Cloud.
  • Utilisez un compte de service à usage unique et ne lui accordez que l'accès aux ressources dont la charge de travail a besoin.
  • Exiger des utilisateurs qu'ils demandent un accès "juste-à-temps" au lieu de leur accorder un accès permanent à la VM et au compte de service.

Limiter l'utilisation des droits racine

Lorsque vous utilisez OS Login et que vous attribuez à un utilisateur le rôle Utilisateur OS Login (roles/compute.osLogin), vous lui attribuez des droits d'utilisateur limités sur la VM. À l'inverse, lorsque vous attribuez à un utilisateur le rôle Utilisateur administrateur OS Login (roles/compute.osAdminLogin), utilisez l'autorisation de clé basée sur les métadonnées au lieu d'OS Login ou autorisez les utilisateurs à modifier les métadonnées de la VM, vous accordez implicitement à l'utilisateur des droits d'administrateur racine sur la VM.

Accorder des droits racine à des utilisateurs sur une VM peut vous exposer à des risques de persistance : les utilisateurs peuvent abuser de ces droits pour créer des comptes utilisateur ou installer des portes dérobées afin de conserver un accès permanent à la VM.

Pour réduire ce risque de persistance, limitez l'utilisation des droits racine et accordez uniquement le rôle Utilisateur OS Login (roles/compute.osLogin) lorsque les droits racine ne sont pas requis.

Précréez des profils POSIX pour garantir la cohérence des noms d'utilisateur et des identifiants uniques.

Chaque VM Linux gère une base de données locale d'utilisateurs (/etc/passwd) et de groupes (/etc/groups). Lorsque vous vous connectez pour la première fois à une VM Linux à l'aide de SSH, l'environnement invité crée automatiquement un compte utilisateur Linux pour vous et lui attribue un UID.

Lorsque vous utilisez des clés basées sur les métadonnées, l'environnement invité n'associe pas l'utilisateur Linux à votre compte utilisateur Google et peut vous attribuer un UID différent sur chaque VM à laquelle vous vous connectez. Si vous utilisez des protocoles tels que NFS, qui supposent des UID cohérents dans un environnement qui n'applique pas d'UID cohérents entre les machines, les utilisateurs peuvent, accidentellement, ou délibérément dans le cas d'acteurs malintentionnés, être en mesure d'accéder à distance avec un autre compte utilisateur.

Lorsque vous utilisez des clés basées sur les métadonnées, l'environnement invité vous permet également de choisir le nom d'utilisateur que vous souhaitez utiliser. Si vous choisissez un nom d'utilisateur utilisé précédemment par un collègue, vous êtes connecté à l'aide du compte créé initialement pour lui.

Vous pouvez éviter ces ambiguïtés d'UID et de nom d'utilisateur en utilisant OS Login : lorsque vous vous connectez pour la première fois à une VM Linux à l'aide d'OS Login, l'environnement invité crée un utilisateur Linux basé sur le profil POSIX de votre compte utilisateur Google. Le profil POSIX sert de modèle pour les utilisateurs Linux et définit les éléments suivants :

  • Un nom d'utilisateur Linux unique pour tous les utilisateurs du même compte Cloud Identity ou Google Workspace
  • un UID et un GID uniques pour tous les projets Google Cloud
  • un chemin d'accès au répertoire d'accueil
  • une configuration supplémentaire, comme un shell de connexion

Si votre compte Google ne possède pas de profil POSIX lors de votre première connexion, OS Login en crée un automatiquement pour vous.

Le nom d'utilisateur et les UID attribués par OS Login sont uniques dans votre environnement Google Cloud, mais ils peuvent se chevaucher ou être incohérents avec les noms d'utilisateur et les UID que vous utilisez en dehors de Google Cloud. Si vous souhaitez que les noms d'utilisateur et les UID d'OS Login soient cohérents dans les autres environnements, il est préférable de ne pas compter sur la création automatique de profils. Utilisez plutôt l'API Directory pour précréer des profils POSIX OS Login et attribuer des noms d'utilisateur, des UID et des GID personnalisés.

Étape suivante