Les clés publiques ne suffisent pas pour la sécurité SSH

Si votre société utilise des clés publiques SSH, il est tout à fait possible que vous en ayez déjà perdu une. Un fichier stocké dans une copie de sauvegarde ou sur l'ordinateur d'un ancien employé permet à son détenteur d'accéder à votre infrastructure. Si vous partagez des clés SSH entre employés, il est probable que seules quelques clés suffisent pour permettre à une personne malveillante d'accéder à l'ensemble de votre système. Si vous ne les partagez pas, il est probable que votre équipe ait généré tellement de clés que vous en ayez perdu au moins une depuis longtemps.

Si une personne malveillante parvient à pirater un seul de vos périphériques clients, il est probable qu'il y trouve un fichier known_hosts qui répertorie chaque cible pouvant être atteinte avec les clés déjà présentes sur la machine. Si quelqu'un parvient à pirater l'ordinateur portable d'un membre de l'équipe, il peut utiliser les clés sur l'appareil qui ne sont pas protégées par mot de passe pour atteindre des cibles confidentielles.

Si cela se produisait, comment réagiriez-vous et révoqueriez-vous la clé SSH perdue ? Tenez-vous un registre des clés qui ont été générées ? Renouvelez-vous les clés SSH ? Comment faire dans une entreprise qui se consacre si activement au service de ses clients pour que la sécurité soit adoptée en toute simplicité ?

Cloudflare Access a commencé à prendre en charge les connexions SSH l'année dernière afin de mettre en place un système de sécurité Zero Trust pour la connexion des équipes aux infrastructures. Access s’intègre à votre fournisseur d'identité pour offrir une sécurité SSO aux connexions SSH en appliquant des règles basées sur l'identité chaque fois qu'un utilisateur tente de se connecter à une ressource cible.

Cependant, une fois qu'Access connectait les utilisateurs au serveur, ces derniers devaient encore se fier aux clés SSH héritées pour obtenir l'autorisation de leur compte. A partir d'aujourd'hui, nous allons aider les équipes à lever cette condition et à remplacer les clés SSH statiques par des certificats de courte durée.

Dans les modèles traditionnels de périmètre de réseau, les équipes sécurisent leur infrastructure avec deux passerelles : un réseau privé et des clés SSH.

Le réseau privé exige que tout utilisateur tentant de se connecter à un serveur soit sur le même réseau ou un équivalent associé (comme un VPN). Cependant, cela présente un certain risque. Par défaut, les réseaux privés considèrent qu'un utilisateur sur le réseau peut atteindre une machine. Les administrateurs doivent segmenter proactivement le réseau ou sécuriser chaque élément de l'infrastructure à l'aide de listes de contrôle pour remonter à partir de cette valeur par défaut.

Cloudflare Access sécurise l'infrastructure en prenant la direction opposée : aucun utilisateur ne doit être digne de confiance. Les utilisateurs doivent plutôt prouver qu'ils sont autorisés par défaut à accéder à toute machine ou destination unique.

Nous avons introduit l'an dernier la prise en charge des connexions SSH dans Cloudflare Access pour aider les équipes à quitter ce modèle de périmètre réseau et à le remplacer par un modèle qui évalue l'identité des utilisateurs pour chaque requête envoyée à un serveur. Grâce à cette intégration avec les fournisseurs d'identité les plus utilisés, cette solution permet également aux équipes d'intégrer leur pipeline SSO à leur flux SSH.

Une fois qu'un utilisateur est connecté à un serveur par SSH, il a généralement besoin d'autoriser sa session. La machine qu'il essaie de joindre possède un ensemble de profils composés d'identités d'utilisateurs ou de rôles. Ces profils déterminent quelles actions l'utilisateur peut effectuer.

Les processus SSH mettent à la disposition de l'utilisateur un certain nombre de possibilités pour se connecter à un profil. Dans certains cas, les utilisateurs peuvent se connecter avec un nom d'utilisateur et un mot de passe. Cependant, la plupart des équipes utilisent des certificats de clés publics-privés pour gérer cette connexion. Pour utiliser ce flux, les administrateurs et les utilisateurs doivent au préalable effectuer quelques opérations.

Avant la connexion, l'utilisateur doit générer un certificat et fournir la clé publique à un administrateur, qui configurera ensuite le serveur pour qu'il fasse confiance au certificat et l'associe à un certain utilisateur et à un ensemble d'autorisations. L'utilisateur enregistre ce certificat sur son appareil et le présente au cours de cette dernière étape. Cependant, cela laisse la porte ouverte à tous les problèmes que le SSO tente de résoudre :

• La plupart des équipes ne forcent jamais les utilisateurs à renouveler les certificats. Si c'est le cas, cela pourrait être nécessaire une fois par an au plus. Les informations d'identification statiques de l'infrastructure centrale sont donc conservées sur des centaines ou des milliers de périphériques.

• Les utilisateurs ont la responsabilité de sécuriser leurs certificats sur leurs appareils. Les utilisateurs sont également responsables des mots de passe, mais les entreprises peuvent centraliser le respect des exigences et la révocation.

• La révocation est difficile. Les équipes doivent se doter d'une plate-forme CRL ou OCSP pour s'assurer que les certificats perdus ou volés ne sont pas utilisés.

Avec Cloudflare Access, vous pouvez mettre en place l'authentification des utilisateurs pour vos comptes SSO au sein de votre infrastructure. Aucune clé statique n’est requise.

Pour y parvenir, nous avons eu recours à trois outils que nous possédions déjà : Cloudflare Access, Argo Tunnel et Workers.

Access est un moteur d'application des politiques qui associe les données des employés enregistrées par le fournisseur d'identité (comme Okta ou AzureAD) aux politiques que vous élaborez. En se basant sur ces politiques, Access peut limiter l'accès à vos applications internes aux utilisateurs de votre choix. Il n'est pas difficile de comprendre comment le même concept pourrait servir à contrôler l'accès à un serveur via SSH. Vous rédigez une politique et nous l'utilisons pour décider qui parmi vos employés peut accéder à telles ou telles ressources. Nous générons ensuite un certificat temporaire qui leur permet d'accéder à cette ressource pendant une très courte durée. Si vous supprimez un utilisateur de votre fournisseur d'identité, son accès à votre infrastructure est également supprimé.

Pour canaliser le trafic via notre réseau, nous utilisons un autre outil Cloudflare existant : Argo Tunnel. Argo Tunnel renverse le modèle traditionnel de connexion d'un serveur à Internet. Lorsque vous lancez notre programme fantôme sur une machine, il établit des connexions sortantes vers Cloudflare, et tout votre trafic circule ensuite sur ces connexions. Cela permet à la machine de faire partie du réseau Cloudflare sans que vous ayez à la connecter directement à Internet.

Pour les cas d'utilisation du HTTP, Argo Tunnel n'a besoin que d'être exécuté sur le serveur. Dans le cas du flux SSH Access, nous proxysons le trafic SSH au travers de Cloudflare en exécutant le client Argo Tunnel cloudflared, à la fois sur le serveur et sur l’ordinateur portable de l'utilisateur final.

Lorsque les utilisateurs se connectent via SSH à une ressource sécurisée par Access for Infrastructure, ils utilisent l'outil de ligne de commande cloudflared. cloudflared prend le trafic SSH destiné à ce nom d'hôte et le transfère via Cloudflare en fonction des paramètres de configuration SSH. Pas besoin d'acheminement ou de mise en forme de commande. cloudflared lance une fenêtre de navigateur et invite l'utilisateur à s'authentifier avec ses identifiants SSO.

Une fois l'authentification effectuée, Access vérifie l'identité de l'utilisateur par rapport à la politique que vous avez définie pour cette application. Si l'utilisateur est autorisé à accéder à la ressource, Access génère un jeton Web JSON (JWT), signé par Cloudflare et envoyé à l'utilisateur et à l'application. Access envoie le jeton à l'appareil de l'utilisateur avec cloudflared et l'outil le stocke localement.

Tout comme le flux d'authentification principal d'Access, la validation des jetons est réalisée avec un Cloudflare Worker qui est exécuté dans chacun de nos datacenters, ce qui le rend à la fois rapide et très disponible. Workers nous a permis de déployer ce SSH en le proxysant sur l'ensemble des 194 datacenters de Cloudflare, ce qui signifie que l'accès pour l'infrastructure accélère souvent les sessions SSH plutôt que de les ralentir.

Avec l'activation des certificats temporaires, le processus d'exécution de cloudflared sur le client ajoute une étape. cloudflared envoie ce jeton à un point de terminaison signant le le certificat Cloudflare qui crée un certificat éphémère. Le flux SSH de l'utilisateur envoie alors à la fois le jeton, qui sert à s'authentifier via Access, et le certificat de courte durée, qui sert à s'authentifier sur le serveur. Tout comme le flux d'authentification principal d'Access, la validation des jetons est réalisée avec un Cloudflare Worker qui est exécuté dans chacun de nos datacenters, ce qui le rend à la fois rapide et très disponible.

Lorsque le serveur reçoit la requête, il valide le certificat temporaire en fonction de cette clé publique et, s'il est authentique, attribue l'identité de l'utilisateur à un utilisateur Unix correspondant. Une fois émis, le certificat est valide pendant 2 minutes mais la connexion SSH peut durer plus longtemps une fois que la session a débuté.

La fonction SSH de Cloudflare Access est entièrement transparente pour l'utilisateur final et ne nécessite aucune commande, wrapper ou marqueur SSH uniques. Au lieu de cela, Access demande que les membres de votre équipe prennent quelques mesures ponctuelles pour commencer :

1. Installer le démon cloudflared

Le logiciel allégé qui est exécuté sur le serveur cible est utilisé pour mettre en proxy les connexions SSH des appareils des membres de votre équipe via Cloudflare. Les utilisateurs peuvent l'installer avec des gestionnaires de packages populaires comme Brew ou en cliquant sur le lien disponible ici. Ou alors, le logiciel étant open-source, il peut être compilé et distribué par vos administrateurs.

2. Imprimer la mise à jour de la configuration SSH et l'enregistrer

Une fois qu'un utilisateur final a installé cloudflared, il doit exécuter une commande pour générer de nouvelles lignes à ajouter à son fichier de configuration SSH :

cloudflared access ssh-config --hostname vm.example.com --short-lived-cert

Le champ --hostname contiendra le nom d'hôte ou le sous-domaine générique de la ressource protégée par Access. Une fois exécuté, cloudflared imprimera les détails des configurations suivantes :

Host vm.example.com
    ProxyCommand bash -c '/usr/local/bin/cloudflared access ssh-gen --hostname %h; ssh -tt %r@cfpipe-vm.example.com >&2 <&1'
    
Host cfpipe-vm.example.com
    HostName vm.example.com
    ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h
    IdentityFile ~/.cloudflared/vm.example.com-cf_key
    CertificateFile ~/.cloudflared/vm.example.com-cf_key-cert.pup

Les utilisateurs doivent ajouter ces données à leur fichier de configuration SSH. Une fois celui-ci enregistré, ils peuvent se connecter à la ressource protégée via SSH. Access leur demandera de se connecter avec leurs identifiants SSO dans le navigateur, de la même manière qu'ils se connectent à tout autre outil du navigateur. S'ils ont déjà une session de navigation active avec leurs identifiants, ils verront simplement une page de confirmation.

Dans leur appareil, cloudflared créera la session et délivrera le certificat client correspondant à leur identité.

Avec des certificats de courte durée, Access peut devenir une passerelle unique intégrant le SSO pour votre équipe et votre infrastructure dans n’importe quel environnement. Les utilisateurs peuvent utiliser SSH directement sur une machine donnée et les administrateurs peuvent remplacer complètement leurs serveurs intermédiaires (jumphosts), en supprimant cette surcharge. La fonctionnalité est disponible aujourd'hui pour tous les clients d’Access. Vous pouvez débuter en vous référant au manuel disponible ici.