Bonnes pratiques pour contrôler l'accès au réseau via SSH

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

Pour se connecter à une instance de VM à l'aide de SSH, un utilisateur doit disposer d'un accès réseau à l'instance de VM et d'identifiants SSH valides. Par défaut, Compute Engine utilise une règle de pare-feu qui n'empêche pas l'accès réseau SSH, mais qui permet à n'importe quel utilisateur d'Internet de se connecter au port 22 des instances de VM. Bien que cette méthode soit pratique pour les développeurs qui souhaitent se lancer rapidement sans tenir compte des contrôles réseau ou de sécurité, elle présente des risques, car elle permet aux utilisateurs de se connecter depuis n'importe quel appareil, réseau et emplacement :

  • Les utilisateurs peuvent se connecter à partir d'appareils ou de réseaux non fiables.
  • Des personnes malveillantes peuvent lancer des attaques par force brute et tenter de compromettre vos instances de VM.
  • Les personnes malintentionnées ayant accès à des identifiants SSH divulgués ou non révoqués à temps peuvent les utiliser pour accéder à une VM et s'y connecter depuis n'importe quel réseau.

Les sections suivantes expliquent comment réduire les risques en limitant les réseaux, les emplacements ou les appareils à partir desquels les utilisateurs peuvent établir une connexion SSH avec vos VM :

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.

Réduire l'exposition du réseau

Autoriser les utilisateurs à établir des connexions SSH depuis n'importe où signifie que vous dépendez entièrement des mécanismes d'authentification et d'autorisation SSH pour protéger vos VM. Vous pouvez réduire les risques et établir un niveau de protection supplémentaire en limitant l'exposition réseau des VM.

Il existe plusieurs façons de réduire l'exposition réseau de vos VM. Pour identifier l'approche la mieux adaptée à votre environnement, vous devez tenir compte de plusieurs facteurs, comme l'illustre l'organigramme suivant :

Réduire l'exposition du réseau

  • Accès externe : le premier facteur à prendre en compte est de savoir si la VM ne doit être accessible qu'au sein du réseau VPC ou si vous avez également besoin qu'elle soit accessible en externe.

    Si l'accès interne au VPC est suffisant, vous n'avez pas besoin d'attribuer d'adresse IP externe à la VM, mais vous devez quand même décider comment gérer l'accès.

  • Taille du réseau interne : si l'accès interne au VPC est suffisant, le deuxième facteur à prendre en compte est la taille de votre réseau interne.

    Dans les petits réseaux, il peut suffire d'utiliser des règles de pare-feu qui autorisent l'entrée sur le port 22 à partir d'adresses internes pour protéger vos VM. Dans les grands réseaux, s'appuyer uniquement sur les règles de pare-feu peut être trop limitant. Dans ce cas, vous pouvez utiliser le transfert TCP d'Identity-Aware Proxy pour appliquer un accès contextuel aux VM.

  • Conception du périmètre VPC Service Controls : le prochain facteur à prendre en compte est de savoir si l'instance de VM fait partie d'un périmètre VPC Service Controls.

    Si la VM fait partie d'un périmètre de service, tout accès à l'API provenant de la VM est considéré comme provenant de l'intérieur du périmètre. Lorsque vous accordez à un utilisateur situé en dehors du périmètre un accès SSH à une VM à l'intérieur du périmètre, il peut potentiellement copier des données du périmètre vers son poste de travail local, ou inversement. Cela peut mettre en danger la confidentialité et l'intégrité des données de votre périmètre.

    Chaque fois que vous devez accorder l'accès SSH à une instance de VM faisant partie d'un périmètre VPC Service Controls, utilisez IAP pour le transfert TCP. IAP détecte si le poste de travail de l'utilisateur fait partie du même périmètre VPC Service Controls et bloque par défaut les tentatives d'accès provenant de l'extérieur du périmètre de service. Pour autoriser l'accès externe, utilisez des règles d'entrée et configurez-les pour appliquer l'accès contextuel.

  • Gestion des appareils clients : le dernier facteur à prendre en compte est la façon dont vos appareils clients sont gérés, car cela détermine les façons dont vous pouvez contrôler l'accès contextuel.

    L'accès contextuel est plus efficace lorsque Access Context Manager a accès à un ensemble complet de signaux concernant un utilisateur, son appareil et sa position. Il fonctionne donc en association avec Chrome Enterprise Premium. Si vous utilisez Chrome Enterprise Premium pour gérer vos appareils, vous pouvez configurer des niveaux d'accès qui contrôlent l'accès en fonction de la posture de l'appareil. Vous pouvez ensuite appliquer ce niveau d'accès à l'accès SSH en utilisant le transfert TCP d'IAP en combinaison avec des liaisons d'accès ou des conditions IAM.

    Si vous ne contrôlez pas la configuration d'un appareil client, vous devez le considérer comme non géré et potentiellement non fiable.

    Pour autoriser l'accès à partir d'appareils non gérés, vous pouvez également utiliser le transfert TCP IAP, mais vous ne pouvez gérer l'accès qu'en fonction de l'identité de l'utilisateur et de l'adresse IP de l'appareil. Étant donné qu'Access Context Manager n'a accès à aucun signal d'appareil, vous ne pourrez pas restreindre l'accès en fonction de la posture de l'appareil.

En fonction des facteurs et à l'aide de l'organigramme, vous pouvez identifier l'approche de réduction de l'exposition du réseau la mieux adaptée à votre environnement. Les sections suivantes décrivent ces approches plus en détail.

Accès SSH basé sur IAP

L'idée de cette approche est d'autoriser l'accès SSH uniquement via le transfert TCP IAP et de laisser IAP contrôler l'accès en fonction de l'identité de l'utilisateur.

Nous recommandons cette approche pour les instances de VM qui répondent aux critères suivants :

  • L'instance de VM doit être accessible en externe ou depuis un grand réseau interne.
  • La VM ne fait pas partie d'un périmètre VPC Service Controls.

Par défaut, une instance de VM avec une adresse IP externe autorise l'accès SSH, car les pare-feu par défaut autorisent les connexions depuis l'Internet public vers le port 22. Toutefois, cette approche n'est pas recommandée. Cette approche peut augmenter considérablement le risque que la VM soit la cible d'attaques telles que les suivantes :

  • Utilisation d'identifiants non révoqués : les anciens employés dont l'accès n'a pas été entièrement révoqué peuvent continuer à accéder à la VM.
  • Utilisation abusive d'identifiants valides : des acteurs malveillants en possession d'identifiants volés ou divulgués peuvent les utiliser pour se connecter.
  • Déni de service : des personnes malintentionnées peuvent tenter d'épuiser les ressources de la VM en l'inondant de requêtes.

Pour activer l'accès SSH externe à une instance de VM de manière plus sécurisée, utilisez le transfert TCP d'IAP. Semblable à un hôte bastion ou à un proxy inverse, le transfert TCP IAP sert d'intermédiaire entre l'appareil client et la VM.

Le transfert TCP d'IAP effectue les quatre fonctions suivantes lorsqu'un utilisateur tente d'établir une connexion SSH :

  • Authentification : IAP vérifie que l'utilisateur possède un identifiant Google valide.
  • Autorisation : IAP vérifie les règles IAM pour s'assurer que l'utilisateur est autorisé à se connecter à la VM via IAP.
  • Accès contextuel : IAP peut éventuellement vérifier que l'utilisateur, son appareil et son emplacement répondent à certains niveaux d'accès.
  • Audit : lorsque les journaux d'accès aux données sont activés, IAP enregistre chaque tentative de connexion à une instance de VM, qu'elle ait réussi ou échoué.

En agissant en tant qu'intermédiaire et en effectuant ces fonctions, IAP évite d'avoir à attribuer une adresse IP externe à la VM et fournit une couche de sécurité supplémentaire.

Accès SSH contextuel basé sur IAP

L'idée de cette approche est d'autoriser l'accès SSH uniquement via le transfert de port TCP IAP, et de laisser IAP contrôler l'accès en fonction de l'identité de l'utilisateur et d'autres facteurs.

Nous recommandons cette approche pour les instances de VM qui répondent aux critères suivants :

  • L'instance de VM doit être accessible depuis l'extérieur du VPC et des réseaux connectés au VPC.
  • La VM ne fait pas partie d'un périmètre VPC Service Controls.
  • La VM ne doit être accessible que depuis certains appareils, réseaux ou emplacements.

Lorsque vous accordez à un utilisateur un accès SSH à une instance de VM, que ce soit directement ou via IAP, il peut par défaut accéder à l'instance de VM depuis n'importe quel appareil, réseau et emplacement. Bien que ce niveau d'accès soit pratique pour les utilisateurs, il augmente les risques, car ils peuvent se connecter à partir d'appareils compromis ou de réseaux non fiables.

Pour réduire les risques, configurez le transfert TCP d'IAP de sorte que les utilisateurs ne puissent accéder aux instances de VM que depuis certains appareils ou emplacements. Vous pouvez configurer cet accès contextuel de deux manières :

  • Liaisons d'accès : vous pouvez créer un niveau d'accès et l'attribuer à un groupe à l'aide d'une liaison d'accès. Les liaisons d'accès sont une forme de règle basée sur l'identité. Elles s'appliquent à toutes les ressources auxquelles un utilisateur tente d'accéder, y compris IAP, mais aussi à d'autres API et à la console Google Cloud .

    L'utilisation de liaisons d'accès est plus efficace si vous souhaitez vous assurer que l'accès contextuel est appliqué de manière uniforme aux ressources.

  • Conditions IAM : vous pouvez créer un niveau d'accès et l'attribuer à des liaisons de rôles IAM individuelles à l'aide des conditions IAM.

    L'utilisation de liaisons de rôle IAM est une forme de stratégie basée sur les ressources. Cette approche est plus efficace si vous souhaitez appliquer différentes stratégies à différents ensembles de VM.

Les niveaux d'accès de base vous permettent de limiter l'accès par réseau ou par zone géographique. En tant qu'abonné Chrome Enterprise Premium, vous pouvez également limiter l'accès en fonction d'autres attributs tels que la robustesse des identifiants, la configuration du navigateur utilisé pour l'authentification ou la posture de l'appareil.

Accès SSH basé sur VPC Service Controls

L'idée de cette approche est d'autoriser l'accès SSH uniquement via le transfert TCP IAP et de configurer le périmètre de service pour autoriser l'entrée IAP pour certaines identités de nos sources.

Nous recommandons cette approche pour les instances de VM qui font partie d'un périmètre VPC Service Controls.

Accorder aux utilisateurs un accès SSH externe à une VM faisant partie d'un périmètre de service peut être risqué, car cela peut leur permettre de compromettre votre périmètre VPC Service Controls en exfiltrant des données via SSH.

En n'autorisant l'accès SSH que via le transfert TCP IAP, vous pouvez réduire ce risque et vous assurer que tous les accès SSH sont soumis à la configuration de votre périmètre VPC Service Controls :

  • Si un utilisateur tente de se connecter depuis l'extérieur du périmètre de service (comme illustré dans l'exemple précédent), le transfert TCP IAP vérifie non seulement si l'utilisateur dispose d'un accès IAM à la VM, mais aussi si la requête respecte l'une des règles d'entrée du périmètre.

  • Si un utilisateur tente de se connecter depuis l'intérieur du périmètre de service, le transfert TCP IAP vérifie également si l'utilisateur dispose d'un accès IAM à la VM, mais ignore les règles d'entrée VPC Service Controls.

    IAP considère qu'une connexion provient de l'intérieur d'un périmètre de service si l'une des conditions suivantes est remplie :

    • L'adresse IP source est l'adresse IP externe d'une VM qui fait partie du périmètre de service.
    • La connexion est établie via l'accès privé à Google à partir d'une VM faisant partie du périmètre de service.
    • La connexion s'effectue via un point de terminaison d'accès Private Service Connect qui fait partie du périmètre de service.

Accès SSH interne contrôlé par un pare-feu

L'idée de cette approche est de refuser tout accès externe et d'autoriser uniquement l'accès SSH interne au VPC.

Vous pouvez utiliser cette approche pour les instances de VM pour lesquelles les conditions suivantes s'appliquent :

  • L'instance de VM n'a pas besoin d'être accessible en externe.
  • La VM est connectée à un réseau interne de petite ou moyenne taille.
  • La VM ne fait pas partie d'un périmètre VPC Service Controls.

Pour interdire tout accès externe, vous pouvez effectuer l'une des opérations suivantes :

  • Déployez les instances de VM sans adresse IP externe.
  • Configurez des règles de pare-feu pour interdire le trafic SSH entrant provenant de plages d'adresses IP en dehors du VPC.

Désactiver l'accès à la console série

Pour résoudre les problèmes liés aux instances de VM qui ne fonctionnent pas correctement, Compute Engine vous permet de vous connecter à la console du port série d'une instance via une passerelle SSH, ssh-serialport.googleapis.com. Cette passerelle est accessible publiquement sur Internet.

La passerelle SSH accède à la VM via l'hyperviseur sous-jacent au lieu du réseau VPC. L'accès à la console série est donc contrôlé par des stratégies IAM et non par des règles de pare-feu.

Autoriser les utilisateurs à accéder à la console série d'une VM peut involontairement la rendre trop exposée. Pour éviter cette surexposition, utilisez la contrainte de règle d'administration compute.disableSerialPortAccess pour désactiver l'accès à la console série, et supprimez temporairement la contrainte lorsque vous avez besoin d'un accès d'urgence au port série de la VM.

Utiliser une VM bastion si vous avez besoin d'enregistrer des sessions

En agissant comme intermédiaire entre les appareils clients et les VM, le transfert TCP IAP effectue des fonctions couramment effectuées par les hôtes bastion ou les serveurs relais. Ces fonctions incluent :

  • Appliquer les règles d'accès de manière centralisée
  • Auditer l'accès

Contrairement à certains hôtes bastion, le transfert TCP d'IAP ne met pas fin aux connexions SSH. Lorsque vous établissez une connexion SSH à une VM via le transfert TCP d'IAP, la connexion SSH est chiffrée de bout en bout entre votre client et la VM. En raison de ce chiffrement de bout en bout, le transfert TCP IAP ne peut pas inspecter le contenu de la session SSH et ne fournit pas de fonctionnalités d'enregistrement de session. Les journaux d'audit IAP contiennent des métadonnées de connexion, mais ne révèlent aucune information sur le contenu de la session.

Si vous avez besoin d'enregistrer les sessions, utilisez une VM bastion :

  • Configurez la VM bastion pour qu'elle mette fin aux connexions SSH et enregistre leur contenu. Veillez à restreindre l'utilisation du transfert de port SSH, car cela pourrait nuire à l'efficacité de l'enregistrement de session.
  • Configurez les règles de pare-feu des VM cibles pour que les connexions SSH ne soient autorisées qu'à partir de la VM bastion.
  • Autoriser l'accès à la VM bastion uniquement via le transfert TCP IAP

Utiliser des stratégies de pare-feu pour limiter l'exposition SSH

Une fois que vous avez déterminé la méthode de limitation de l'exposition SSH qui convient le mieux à votre environnement, vous devez vous assurer que toutes les VM et tous les projets sont configurés en conséquence. En particulier, vous devez vous assurer que tous les projets utilisent un ensemble cohérent de règles de pare-feu qui déterminent comment SSH peut être utilisé.

Pour appliquer un ensemble de règles de pare-feu à plusieurs projets, utilisez des stratégies de pare-feu hiérarchiques et appliquez-les à des dossiers dans votre hiérarchie des ressources.

Par exemple, pour vous assurer que tous les accès SSH sont effectués via le transfert TCP IAP, appliquez une stratégie de pare-feu qui inclut les deux règles personnalisées suivantes (par ordre de priorité) :

  1. Autorisez l'entrée depuis 35.235.240.0/20 vers le port 22 des VM sélectionnées. 35.235.240.0/20 correspond à la plage d'adresses IP utilisée par le transfert TCP IAP.
  2. Refuser l'entrée de 0.0.0.0/0 vers le port 22 de toutes les VM.

Étapes suivantes