Ce document décrit les bonnes pratiques à suivre 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 ne limite pas l'accès réseau SSH, mais qui autorise n'importe qui sur Internet à se connecter au port 22
des instances de VM. Bien que cela soit pratique pour les développeurs de se lancer rapidement sans tenir compte des contrôles réseau ou de sécurité, autoriser les utilisateurs à se connecter depuis n'importe quel appareil, réseau et emplacement présente des risques:
- Les utilisateurs peuvent se connecter à partir d'appareils ou de réseaux non approuvés.
- Des personnes malintentionnées peuvent lancer des attaques par force brute et tenter de compromettre vos instances de VM.
- Des 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 des connexions SSH avec vos VM:
- Réduire l'exposition du réseau
- Utiliser une VM bastion si vous avez besoin d'enregistrer des sessions
- Utiliser des stratégies de pare-feu pour limiter l'exposition SSH
- Désactiver l'accès à la console série
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 une couche de protection supplémentaire en réduisant l'exposition réseau des VM.
Il existe plusieurs approches pour réduire l'exposition réseau de vos VM. Pour identifier l'approche la mieux adaptée à votre environnement, vous devez prendre en compte un certain nombre de facteurs, comme illustré par l'organigramme suivant:
Accès externe: le premier facteur à prendre en compte est de savoir si la VM doit être accessible uniquement sur le réseau VPC ou si vous avez besoin qu'elle soit également accessible en externe.
Si l'accès interne au VPC est suffisant, vous n'avez pas besoin d'attribuer une adresse IP externe à la VM, mais vous devez tout de même décider de la manière dont vous allez gérer l'accès.
Taille du réseau interne:si l'accès au réseau VPC interne 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'accès au port
22
à partir d'adresses internes pour protéger vos VM. Dans les réseaux plus importants, s'appuyer uniquement sur des règles de pare-feu peut être trop limitatif. 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 du périmètre. Lorsque vous accordez à un utilisateur situé en dehors du périmètre un accès SSH à une VM située dans le périmètre, il peut potentiellement copier des données du périmètre vers sa station de travail locale, ou inversement. Cela peut mettre en péril 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 le transfert TCP d'IAP. L'API IAP détecte si la station de travail de l'utilisateur fait partie du même périmètre VPC Service Controls et bloque les tentatives d'accès en dehors du périmètre de service par défaut. 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 manière dont vos appareils clients sont gérés, car cela détermine les moyens dont vous disposez pour contrôler l'accès contextuel.
L'accès contextuel est le plus efficace lorsque Access Context Manager a accès à un ensemble riche de signaux sur un utilisateur, son appareil et sa position. Il fonctionne donc en conjonction 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 position de l'appareil. Vous pouvez ensuite appliquer ce niveau d'accès à l'accès SSH à l'aide du 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 approuvé.
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 de l'appareil, vous ne pouvez pas limiter l'accès en fonction de l'état 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 plus adaptée à votre environnement. Les sections suivantes décrivent ces approches plus en détail.
Accès SSH basé sur l'API IAP
L'idée de cette approche est d'autoriser uniquement l'accès SSH via le transfert TCP IAP et de laisser IAP contrôler l'accès en fonction de l'identité de l'utilisateur.
Nous vous recommandons cette approche pour les instances de VM pour lesquelles les conditions suivantes s'appliquent:
- L'instance de VM doit être accessible en externe ou à partir d'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 disposant d'une adresse IP externe autorise l'accès SSH, car les pare-feu par défaut autorisent les connexions de l'Internet public au port 22. Toutefois, cette approche n'est pas recommandée. Cette approche peut considérablement augmenter le risque que la VM soit soumise à des 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 acteurs malintentionnés peuvent tenter d'épuiser les ressources de la VM en l'inondant de requêtes.
Pour activer un accès SSH externe à une instance de VM, il est plus sécurisé d'utiliser le transfert TCP d'IAP. Comme un hôte bastion ou un proxy inverse, le transfert TCP de l'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:l'IAP vérifie que l'utilisateur dispose d'identifiants Google valides.
- Autorisation:IAP vérifie les stratégies IAM pour vérifier que l'utilisateur a été autorisé à se connecter à la VM via IAP.
- Accès contextuel:l'IAP peut vérifier si 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 consigne chaque tentative de connexion réussie et non réussie à une instance de VM.
En agissant en tant qu'intermédiaire et en effectuant ces fonctions, l'IAP élimine la nécessité d'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 de n'autoriser l'accès SSH que via le transfert TCP IAP et de laisser IAP contrôler l'accès en fonction de l'identité de l'utilisateur et d'autres facteurs.
Nous vous recommandons cette approche pour les instances de VM pour lesquelles les conditions suivantes s'appliquent:
- 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 qu'à partir de 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 l'IAP, il peut accéder à l'instance de VM depuis n'importe quel appareil, réseau et emplacement par défaut. Bien que pratique pour les utilisateurs, ce niveau d'accès augmente les risques, car les utilisateurs peuvent se connecter à partir d'appareils compromis ou de réseaux non approuvés.
Pour réduire les risques, configurez le transfert TCP d'IAP afin 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 des règles basées sur un formulaire ou une identité. Elles s'appliquent à toutes les ressources auxquelles un utilisateur tente d'accéder, y compris aux IAP, mais aussi aux 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 à toutes les ressources.
Conditions IAM:vous pouvez créer un niveau d'accès et l'attribuer à des liaisons de rôles IAM individuelles à l'aide de 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 solidité des identifiants, la configuration du navigateur utilisé pour l'authentification ou la position de l'appareil.
Accès SSH basé sur VPC Service Controls
L'idée de cette approche est d'autoriser uniquement l'accès SSH 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 vous 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 il peut leur permettre de saper votre périmètre VPC Service Controls en exfiltrant des données via SSH.
En n'autorisant que l'accès SSH via le transfert TCP d'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 en dehors 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 répond à l'une des règles d'entrée du périmètre.
Si un utilisateur tente de se connecter depuis le périmètre de service, le transfert TCP de l'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.
L'IAP considère qu'une connexion provient de l'intérieur d'un périmètre de service si l'un des cas suivants s'applique:
- 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 est établie 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 d'interdire tout accès externe et de n'autoriser que 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 envergure.
- 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 afin que le trafic SSH entrant provenant de plages d'adresses IP situées en dehors du VPC ne soit pas autorisé.
Désactiver l'accès à la console série
Pour résoudre les problèmes liés aux instances de VM, 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 au public 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 à une console série de VM peut laisser la VM surexposée par inadvertance. 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 lever 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 en tant qu'intermédiaire entre les appareils clients et les VM, le transfert TCP de l'IAP effectue des fonctions généralement effectuées par des hôtes bastion ou des serveurs de saut. Ces fonctions incluent:
- Appliquer des 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 de l'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 des sessions, utilisez une VM bastion:
- Configurez la VM bastion pour qu'elle mette fin aux connexions SSH et enregistre leur contenu. Veillez à limiter l'utilisation du transfert de port SSH, car il pourrait nuire à l'efficacité de l'enregistrement de session.
- Configurez les règles de pare-feu des VM cibles afin que les connexions SSH ne soient autorisées que depuis la VM bastion.
- Autoriser l'accès à la VM bastion via le transfert TCP IAP uniquement
Utiliser des stratégies de pare-feu pour limiter l'exposition SSH
Une fois que vous avez déterminé la méthode la plus adaptée pour limiter l'exposition SSH dans 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 aux dossiers de 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é):
- Autorisez l'entrée de
35.235.240.0/20
vers le port 22 des VM sélectionnées.35.235.240.0/20
est la plage d'adresses IP utilisée par le transfert TCP d'IAP. - Interdire l'accès entrant de
0.0.0.0/0
au port 22 de toutes les VM.
Étape suivante
- Découvrez les bonnes pratiques pour contrôler l'accès à la connexion SSH.