Comme le grand Mark Twain l'a écrit un jour en réponse à la lecture de sa propre nécrologie en mai 1897, « les nouvelles de ma mort ont été grandement exagérées ». Avance rapide de près de cent ans jusqu'en 1995, et un informaticien finlandais nommé Tatu Ylönen a créé un protocole de transport sécurisé connu simplement sous le nom de Secure Shell (SSH). Qu'est-ce que ces choses ont à voir les unes avec les autres ? Rien, à part la perception.
Dans ses termes les plus pratiques, SSH permet aux utilisateurs d'établir une connexion à distance sécurisée avec une machine basée sur Linux via une interface de ligne de commande (CLI). SSH est la norme de facto pour l'accès sécurisé aux serveurs et a résisté à l'épreuve du temps, malgré un changement important dans la façon dont l'infrastructure est exploitée dans le cloud.
Chez Okta, nous adoptons le passage au modèle d’exploitation du cloud, où les ressources sont dynamiques et éphémères, en adaptant les propriétés de sécurité sous-jacentes de SSH. Nos clients utilisent Okta Advanced Server Access (Okta ASA) pour automatiser en toute sécurité les contrôles d’identité et d’accès pour que leurs équipes utilisent SSH en toute sécurité. Et nous venons d’atteindre une étape importante en enregistrant plus d’un million de connexions SSH par mois... et ce n’est pas fini !
Dans cet article, j'aimerais aborder certaines tendances concernant le modèle d'exploitation du cloud, le rôle continu que joue SSH dans la sécurisation de l'accès à distance, et comment Okta a aidé nos clients à résoudre élégamment un problème épineux.
Un grand pouvoir implique de grandes responsabilités
En tant que norme de facto pour l'accès à distance aux serveurs Linux, SSH est naturellement une cible courante pour les attaquants qui tentent d'infiltrer le réseau d'une entreprise. Le protocole de transport est intrinsèquement sécurisé ; cependant, le mécanisme d'authentification sous-jacent est sujet à l'erreur humaine, avec des résultats potentiellement catastrophiques. Les clés SSH, qui sont des paires de clés cryptographiques conçues pour être une attestation de confiance, nécessitent une grande prudence pour s'assurer qu'elles ne tombent pas entre de mauvaises mains. Il n'existe aucun moyen de garantir un lien entre une clé SSH et une identité. À bien des égards, la possession est donc la clé de tout.
De ce fait, les entreprises ont traditionnellement été forcées de faire l'une des choses suivantes :
- Mettez en œuvre une politique de sécurité pour que les utilisateurs gèrent et renouvellent régulièrement leurs clés SSH personnelles (la plus simple, la moins sécurisée).
- Exploiter un service de coffre-fort sécurisé capable de stocker les clés SSH, extraites à la demande (plus difficile, plus sûr).
- Achetez et déployez un produit de gestion des accès privilégiés pour servir de passerelle pour l'accès à distance (le plus difficile, le plus sûr).
J'imagine que vous voyez le modèle ici—comme pour beaucoup de choses, on récolte ce que l'on sème. Mais écoutez, la sécurité évolue, et rapidement. Tout d'abord, la solution la plus difficile n'est pas toujours la plus sûre, mais surtout, qui a le temps de faire tout ce travail supplémentaire ?? !! Nous sommes tous forcés de faire plus avec moins, mais les équipes de sécurité ont également le défi supplémentaire de protéger l'entreprise sans entraver les activités. Ce n'est pas une chose facile d'en être responsable.
Nous comprenons cet acte d'équilibrage continu et concevons nos produits pour qu'ils soient la solution la plus sécurisée et la plus facile à utiliser du marché. Avant d'aborder les détails de la façon dont nous permettons à nos clients d'obtenir de meilleurs résultats avec Okta ASA, j'aimerais aborder la perception selon laquelle SSH est mort à l'ère du cloud moderne.
Le défi Kubernetes
Avec l’évolution vers le modèle d’exploitation du cloud, Kubernetes est devenu la plateforme de plan de gestion de la configuration/couche d’orchestration/interface de ligne de commande/runtime/maillage de services/environnement de développement préférée de tous. Voici une phrase que j’entends parfois : « Nous sommes tous sur Kubernetes, nous n’aurons plus besoin d’accès SSH. »
Cela ressemble certainement à un rêve : une couche d'abstraction unifiée qui supprime toute interaction humaine de la gestion de l'infrastructure élastique multi-cloud. Kubernetes est certainement sur le point de devenir le système d'exploitation proverbial du cloud, mais il introduit un tout nouvel ensemble de complexités et de considérations. Voici un petit échantillon de scénarios où l'interaction humaine est encore nécessaire :
- Connexion aux hôtes sous-jacents pour exécuter des scripts de diagnostic, inspecter les journaux, déboguer les problèmes de réseau, etc.
- Écrire et déboguer du code YAML pour décrire et configurer les environnements cibles, les services, les environnements d'exécution, etc.
- Surveillance des performances des réseaux, de l'infrastructure, des services, etc.
Debout, fort et grand au milieu de toute cette innovation et de ce changement, SSH, car vous ne pouvez tout simplement pas remplacer cette connexion directe et robuste entre un utilisateur et un système d'exploitation hôte. Même les environnements les plus automatisés ont besoin d'un accès humain en cas d'urgence, mais il y a plus que cela : l'automatisation a également besoin de contrôles de sécurité. SSH convient toujours à la fois à l'accès humain et au niveau des services.
L'image mentale que nous avons tous probablement en tête ici est celle d'un administrateur système assis à son bureau, se connectant à un seul serveur Linux depuis son terminal en tapant « ssh <hostname> ». Bien que la connexion directe utilisateur-serveur soit un cas d'utilisation courant, l'utilisation de SSH est également répandue dans :
- Développeurs écrivant et exécutant des scripts qui se connectent à de nombreux serveurs à la fois pour exécuter une série de tests de diagnostic
- Logiciel de gestion de la configuration (Terraform, Chef, Puppet, Ansible, etc.) qui se connecte aux hôtes cibles pour effectuer des modifications locales
- Outils d'automatisation CI/CD qui se connectent aux serveurs de production pour configurer les environnements d'exécution et pousser les versions logicielles
Qui détient les clés ?
Revenons au problème des clés SSH. L'infrastructure PKI (Public Key Infrastructure) traditionnelle qui sous-tend SSH a été conçue pour une époque différente, où un échange de clés était suffisant pour accorder la confiance. Le problème fondamental réside dans la fausse hypothèse selon laquelle la possession d'une clé privée équivaut à un profil d'identité. Bien que nous puissions dire « clé privée d'Alice », il n'y a pas de processus d'authentification associé qui pourrait vérifier que c'est bien Alice qui a généré la paire de clés au départ, ou qu'Alice est la seule personne qui possède actuellement la clé privée.
À mesure que ces clés sont émises et distribuées dans des flottes d'infrastructure dynamique et de services cloud, le défi ne fait que s'aggraver. Chaque clé publique accumule plus de privilèges au fil du temps ; plus elle est ancienne, plus elle est susceptible d'être partagée avec une ressource, ce qui la rend extrêmement difficile à suivre et, par conséquent, à révoquer. Avec ce modèle, le temps est un bug qui ne peut pas être corrigé.
Dans un monde Zero Trust, une attestation de confiance significative consiste à adhérer correctement à une politique qui stipule qu'une personne (ou un service) à partir d'un appareil connu peut accéder à une ressource spécifique à un moment donné. Il ne s'agit pas nécessairement de l'identifiant lui-même, mais du contexte entourant la requête. Même ainsi, nous avons toujours besoin d'un moyen de représenter l'identité et les autorisations associées à l'attestation qui a été faite.
Saisir les certificats de client SSH
Heureusement, les technologies OpenSSH de base ont évolué au fil du temps et ont introduit en 2011 la possibilité de s'authentifier à l'aide d'un certificat client au lieu d'une clé SSH. Contrairement aux clés SSH standard, qui ne contiennent aucune métadonnée, les certificats clients sont des objets de métadonnées cryptographiquement vérifiables qui peuvent injecter des éléments tels que des noms d'utilisateur, des rôles, etc. Mais, sans doute le plus important, ils ont une date d'expiration.
Avec les certificats clients, l'accès SSH peut suivre un flux d'authentification et d'autorisation centré sur l'identité, où une information d'identification étroitement définie pour correspondre à une décision d'accès contextuelle est créée à la demande. Une seule demande, une seule information d'identification—agréable et propre. Avec un délai d'expiration court, aucun nettoyage n'est requis, ce qui supprime la charge associée au suivi, à la gestion et à la rotation des informations d'identification, comme indiqué précédemment. Le temps devient désormais une fonctionnalité.
Maintenant, il n'y a toujours pas de repas gratuit ; il faut beaucoup de travail et de responsabilités opérationnelles continues pour construire et maintenir un système d'infrastructure à clé publique (PKI) qui peut générer ces certificats clients sur chaque demande valide. C'est là qu'Okta entre en jeu—tout comme nous savons que vous ne devriez pas déployer votre propre authentification, vous ne devriez pas déployer votre propre PKI.
Comment nous gérons l'accès SSH avec Okta ASA
Depuis l'introduction d'Okta ASA, un plus grand nombre de nos clients ont pris conscience que l'accès au serveur est avant tout un problème d'identité. Les systèmes de gestion des accès disparates avec des contrôles disparates entraînent une complexité indésirable et une surface d'attaque ingérable. Plus vous pouvez unifier l'accès avec l'identité, mieux c'est, et lorsque vous disposez de la plateforme leader du marché pour commencer, il devient naturel d'étendre l'accès à des ressources plus axées sur l'identité comme les serveurs Linux.
Avec Okta ASA, les connexions SSH suivent désormais une expérience Single Sign-On familière, et les demandes authentifiées et autorisées sont frappées de ce que nous appelons des « informations d'identification éphémères » en coulisses. Pour l'utilisateur, c'est juste SSH. Pour l'équipe de sécurité, c'est tout un monde de douleur, soulagé.
Expérience utilisateur final d'Okta Advanced Server Access
Les utilisateurs installent une application cliente légère sur leurs stations de travail qui s'interface avec leurs outils SSH locaux. Pour fonctionner, l'application cliente nécessite des privilèges d'administrateur sur la machine. Les serveurs inscrits auprès d'Okta exécutent un agent léger qui effectue la gestion locale des comptes et des politiques, et capture les événements de connexion. Pour activer l'authentification par certificat client, OpenSSH est configuré localement pour approuver les certificats signés par Okta comme mécanisme d'authentification valide — c'est un détail important que nous aborderons lorsque nous discuterons du système PKI de support.
Lorsqu'un utilisateur tente de se connecter à un serveur, il est authentifié via Okta et soumis aux politiques de connexion configurées par le client. Cela peut inclure l'authentification multifacteur et/ou la confiance de l'appareil. Une fois authentifié, il est autorisé en fonction des contrôles d'accès basés sur les rôles (RBAC) du serveur cible. Si tout est vérifié, Okta ASA crée un certificat client de courte durée, limité à la requête. Ce certificat client est remis à l'application client, qui l'utilise en mémoire pour établir une connexion directe et sécurisée avec le serveur cible.
Ce qui rend cela si révolutionnaire, c'est que nous sommes capables d'abstraire une telle complexité PKI derrière l'élégance de notre SaaS, exposant une expérience Single Sign-On familière et transparente. Alors, que se passe-t-il en coulisses qui soit si complexe ?
Architecture de certificat client dynamique
Il faut beaucoup d'efforts pour exploiter une plateforme SaaS hautement disponible, résiliente et sécurisée. Lorsque vous ajoutez PKI au mélange, vous avez une sacrée bête entre les mains, c'est pourquoi nous ne recommanderions jamais de construire vous-même un système équivalent. L'architecture de certificat client de support d'Okta ASA est issue de ScaleFT, qui a été acquise par Okta en juillet 2018.
Ce qui rend notre conception unique, c’est que nous n’exploitons pas d’autorité de certification (CA) au sens traditionnel du terme (pensez à l’infrastructure à clé publique (PKI) Web où la chaîne de confiance est d’une importance capitale, car les certificats sont de longue durée). Nous traitons notre architecture CA comme aussi dynamique que les environnements d’infrastructure cloud de nos clients, et nous mettons en place des services capables de créer des certificats client éphémères à la demande pour des groupes de serveurs spécifiques lors de chaque connexion SSH indépendante.
Architecture Okta ASA CA
L'objectif principal de cette architecture d'autorité de certification est de minimiser la portée de chaque certificat client autant que possible sur le plan technique. En tant que justificatifs signés, les propriétés cryptographiques de chacun sont, bien sûr, toujours importantes. Nous tirons parti d'AWS KMS en tant que service de signature racine, en tirant parti de leurs propriétés de sécurité sous-jacentes et de leur conception hautement disponible. Au sein d'Okta ASA, nous exploitons des services de chiffrement qui effectuent un certain nombre de tâches basées sur divers événements API.
Les événements les plus pertinents ici sont Project Create et SSH Connection :
- Lorsqu'un nouveau projet Okta ASA est créé, nous créons une clé de signature chiffrée SHA-256. Lorsque des serveurs sont enregistrés auprès du projet ASA respectif, OpenSSH local est configuré pour faire confiance aux certificats clients signés par cette clé. Étant donné que les projets représentent le périmètre d'autorisation de l'accès basé sur les rôles (RBAC) aux serveurs, le fait de disposer d'une clé de signature dédiée limite également la correspondance des informations d'identification.
- Lorsqu'une connexion SSH est authentifiée et autorisée à un utilisateur sur un appareil à un moment donné, nous frappons un nouveau certificat client avec des métadonnées d'utilisateur et d'appareil injectées, et un court délai d'expiration destiné à limiter sa validité. C'est ce certificat client que l'application cliente de l'utilisateur utilise pour établir une connexion SSH sécurisée avec le serveur cible selon le flux de travail de l'expérience utilisateur final. En raison du court délai d'expiration, le certificat client n'a pas besoin d'être nettoyé après son utilisation.
Les entreprises et les fournisseurs ont dépensé tellement de temps et d'argent pour atténuer le risque de prolifération des informations d'identification. Nous abordons ce problème à la base. La meilleure façon d'atténuer le risque lié aux informations d'identification est de les rendre inutiles !
Un million de connexions SSH. Zéro clé SSH.
Revenons maintenant à cette grande étape. L'agent serveur installé sur chaque serveur cible capture chaque événement de connexion attribuable à un utilisateur et à un appareil, ce qui fournit un événement d'audit beaucoup plus robuste que ce que vous pourriez obtenir en utilisant des comptes partagés ou des informations d'identification partagées.
À mesure que de plus en plus de clients Okta ont adopté Advanced Server Access pour sécuriser leurs parcs de serveurs sur AWS, GCP, Azure ou sur site, nous avons constaté une augmentation continue des événements d'inscription de serveurs et de connexion SSH. Et nous avons franchi le cap du million de connexions SSH en un mois, sans utiliser de clés SSH, ce qui atténue considérablement le risque d'expansion des justificatifs d'identité.
Nombre total mensuel de connexions SSH réussies via Okta ASA
SSH est là pour rester
Bien que sa notice nécrologique ait été publiée en 1897, Mark Twain est décédé en avril 1910, après avoir terminé deux autres romans et plusieurs nouvelles. De même, nous pouvons nous attendre à ce que SSH continue de rester fort et de s'adapter à l'évolution des cas d'utilisation. Tout comme dans la littérature, avec la sécurité, rien ne vaut ce qui a fait ses preuves.
Pour en savoir plus sur la façon dont Okta gère correctement SSH (et rend SSH amusant à nouveau), consultez la présentation d'Okta Advanced Server Access, ou demandez une démo.
