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

Ce document décrit les bonnes pratiques pour contrôler l'accès de 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 l'accès aux utilisateurs lorsqu'ils en ont besoin et le révoquer 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 personnes malintentionnées risquent de conserver leur accès même s'il 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 de sorte à 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 d'un projet, ou vous laissez les utilisateurs effectuer l'importation eux-mêmes en leur 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 privilèges racine sur cette VM uniquement. Une clé importée dans les métadonnées d'un projet accorde à l'utilisateur l'accès à toutes les VM du projet.

  • Autorisation des clés 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 privilèges racine ou des droits d'utilisateur standards sur la VM en lui attribuant le rôle IAM Administrateur OS Login ou Utilisateur OS Login.

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

L'une des différences majeures 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. Elle 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 l'accès SSH.

L'utilisation de clés basées sur des métadonnées peut vous exposer à des menaces de persistance. En effet, 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 en temps voulu. Ils peuvent même conserver l'accès après avoir quitté l'organisation. Bien que vous puissiez limiter ce risque en analysant régulièrement les métadonnées, cela peut s'avérer difficile dans les environnements plus volumineux et risque d'être insuffisant, car les clés basées sur des métadonnées accordent aux utilisateurs des privilèges racine.

Pour vous protéger contre ces 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ées enable-oslogin : le paramètre enable-oslogin défini 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 concernée.

Les métadonnées au niveau de l'instance sont prioritaires par rapport aux métadonnées au niveau du projet. Il n'est donc pas suffisant de définir enable-oslogin sur TRUE dans les métadonnées du projet 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 fiez pas à 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 dotés de privilèges de manière temporaire ou pour chaque 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 laissant les projets utiliser un réseau partagé. Toutefois, l'utilisation de projets distincts n'est pas toujours viable. Certains de vos projets peuvent contenir une combinaison d'instances de VM, dans laquelle différentes instances de VM ne doivent être accessibles qu'à certains 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 doté de privilèges :

  • Accordez 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 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, Administrateur d'instances Compute ou d'autres rôles dotés de privilèges seulement pour des VM individuelles ou uniquement de manière ponctuelle.

Suspendre les comptes utilisateur lorsque des 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 l'accès de l'utilisateur aux VM qui utilisent OS Login.

Si vous avez configuré Cloud Identity ou Google Workspace de sorte à employer un IdP externe pour l'authentification unique, les employés disposent d'un compte utilisateur à la fois dans votre IdP externe et dans Cloud Identity ou Google Workspace. La désactivation ou la suppression du compte utilisateur d'un employé dans votre IdP 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 d'un compte utilisateur afin qu'OS Login puisse révoquer l'accès.

Éviter d'accorder l'accès SSH aux VM disposant d'un compte de service doté de privilèges

Su un compte de service est associé à une VM, 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. OS Login permet ainsi de préserver la sécurité du compte de service et d'empêcher l'utilisation abusive de l'accès SSH pour l'élévation des privilèges.

Pour limiter davantage les risques associés aux VM disposant de comptes de service dotés de privilèges, envisagez les alternatives suivantes :

  • N'associez pas de compte de service à la VM, sauf si la charge de travail nécessite l'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.
  • Exigez 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 privilèges racine

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

Le fait d'accorder à des utilisateurs des privilèges racine sur une VM peut vous exposer à des risques de persistance. En effet, les utilisateurs peuvent abuser de ces privilèges 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 privilèges racine et accordez uniquement le rôle Utilisateur OS Login (roles/compute.osLogin) lorsque les privilèges racine ne sont pas requis.

Créer au préalable des profils POSIX pour garantir la cohérence des noms et ID d'utilisateur

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 et lui attribue un ID utilisateur.

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

Lorsque vous utilisez des clés basées sur des métadonnées, l'environnement invité vous permet également de choisir le nom d'utilisateur à utiliser. Si vous choisissez un nom d'utilisateur qu'un collègue a déjà utilisé, vous êtes connecté au compte qui a été créé à l'origine pour votre collègue.

Vous pouvez éviter ces ambiguïtés liées aux noms et ID 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 en fonction du profil POSIX de votre compte d'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 ID d'utilisateur et un ID de groupe 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 dispose pas de profil POSIX lors de votre première connexion, OS Login en crée automatiquement un.

Le nom d'utilisateur et ID utilisateur attribués par OS Login sont uniques dans votre environnement Google Cloud. Ils peuvent néanmoins se chevaucher ou ne pas concorder avec les noms d'utilisateur et les ID utilisateur que vous utilisez en dehors de Google Cloud. Si vous avez besoin que les noms d'utilisateur et les ID utilisateur d'OS Login concordent 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 créer au préalable des profils POSIX OS Login et attribuer des noms d'utilisateur, des ID utilisateur et des ID de groupe.

Étape suivante