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 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.

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 accorde à l'utilisateur des droits d'administrateur uniquement sur la VM. Une clé importée dans les métadonnées du projet accorde à l'utilisateur un accès à 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.

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

La principale différence entre les deux mécanismes réside dans 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 seule 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 la supprimiez ou que vous supprimiez la VM ou le projet. La suspension ou la suppression du compte utilisateur n'a aucune incidence 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 un 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 examinant régulièrement les métadonnées, cela peut s'avérer difficile dans les environnements plus importants et ne pas être suffisant, car les clés basées sur les métadonnées accordent aux utilisateurs des droits d'administrateur.

Pour vous protéger contre de telles menaces de persistance, 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 ont la priorité 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 disposez d'instances de VM qui exécutent différentes charges de travail et sont gérées par différentes équipes, vous pouvez simplifier la gestion des accès en déployant ces VM dans différents projetsGoogle Cloud et en autorisant les projets à utiliser un réseau partagé. Toutefois, 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é :

  • Accordez aux utilisateurs le rôle Lecteur de Compute ou un rôle en lecture seule équivalent au niveau du projet. Ce rôle permet aux utilisateurs de parcourir les 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 manière, OS Login permet de maintenir la sécurité du compte de service et d'empêcher l'accès SSH d'être utilisé à des fins d'escalade de 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 l'accès à des 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 accordez à 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 par 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 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éer des profils POSIX pour assurer la cohérence des noms d'utilisateur et des UID

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 qu'un collègue a utilisé précédemment, vous êtes connecté avec le compte créé initialement pour votre collègue.

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 Google Cloud projets
  • un chemin d'accès au répertoire d'accueil
  • une configuration supplémentaire, comme un shell de connexion

Si votre compte Google ne dispose pas de profil POSIX lors de votre première connexion, OS Login en crée automatiquement un 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 avez besoin que les noms d'utilisateur et les UID de connexion à l'OS soient cohérents dans d'autres environnements, il est préférable de ne pas vous fier à 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