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

Ce document décrit les bonnes pratiques 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 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 peuvent 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 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 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 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 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 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 en temps voulu, et ils peuvent même conserver l'accès après avoir quitté l'organisation. Bien que vous puissiez réduire ce risque en analysant régulièrement les métadonnées, cela peut s'avérer difficile dans les environnements plus volumineux et peut être insuffisant, car les clés basées sur les métadonnées accordent aux utilisateurs des droits racine.

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

Utiliser des règles d'administration pour appliquer l'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 concernée.

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 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 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 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, 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 é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.
  • N'accordez aux utilisateurs les rôles Compute OS Login, Administrateur d'instances Compute ou d'autres rôles privilégiés que 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 pour utiliser 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 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 d'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 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. 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 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 d'accéder 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 accordez des droits d'utilisateur limités sur la VM. En revanche, lorsque vous accordez à un utilisateur le rôle Utilisateur 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 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 garantir des noms d'utilisateur et des UID cohérents

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 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 UID et aux noms d'utilisateur en utilisant OS Login. Lorsque vous vous connectez à une VM Linux pour la première fois à 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 UID et un GID uniques pour tous les projets Google Cloud
  • un chemin d'accès au répertoire personnel ;
  • 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, la connexion OS 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 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 la connexion 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