Séparez vos identifiants SSH pour sécuriser l'accès à la production

Un seul identifiant SSH donnant accès au développement, au staging et à la production transforme une petite commodité en une vaste autorité distante. Il rend aussi les validations peu sincères : une personne peut approuver une tâche apparemment inoffensive sur le staging alors que le même identifiant peut ouvrir une session de production quelques minutes plus tard.

Séparez les identifiants SSH selon la classe de système et le niveau de risque. Rendez ensuite cette séparation visible dans la configuration du client, imposez-la sur les serveurs et testez les chemins refusés avec autant de sérieux que les chemins autorisés. J'ai vu des équipes appeler cela du contrôle d'accès alors qu'elles avaient simplement donné trois noms à une même clé dans ~/.ssh/config ; ce n'est pas une frontière.

Un identifiant crée un domaine de défaillance unique

Un identifiant partagé entre plusieurs classes d'environnement donne à chaque détenteur l'ensemble des privilèges de ces classes. Si le poste d'un ingénieur, une tâche automatisée ou un circuit de validation peut l'utiliser, la compromission de ce seul chemin atteint l'environnement le plus sensible qui accepte la clé publique.

La défense habituelle consiste à dire que les mêmes personnes administrent tous les environnements. Cela passe à côté du problème. Les personnes peuvent se recouper, mais les situations sont différentes. Le développement implique souvent des scripts non révisés, des données de test, des machines temporaires et une large liberté d'expérimentation. La production devrait reposer sur un ensemble plus restreint de processus acceptables, une validation plus attentive et une trace claire de la personne connectée et de sa raison.

C'est aussi pourquoi un identifiant unique avec des alias d'hôtes différents ne sert à rien. Ces entrées semblent bien organisées :

Host dev-db
  HostName dev-db.internal

Host prod-db
  HostName prod-db.internal

Mais si les deux hôtes acceptent la même clé publique SSH, chaque alias peut s'authentifier avec la même clé privée. Une faute de frappe dans une variable d'automatisation ou une commande copiée peut franchir la frontière sans nouvelle décision d'autorisation.

Des identifiants distincts changent le résultat. Un identifiant de développement volé devrait échouer sur le staging et la production. Un processus autorisé à utiliser un identifiant de staging ne devrait disposer d'aucun élément privé ni d'aucune capacité de signature lui permettant de s'authentifier en production. Ce sont deux contrôles différents. Le premier limite une compromission. Le second empêche un processus légitime, mais trop largement autorisé, de faire quelque chose qu'il ne devrait pas faire.

Ne confondez pas cela avec la rotation des mots de passe. La rotation remplace un identifiant au fil du temps. La séparation détermine où un identifiant peut fonctionner. Vous avez besoin des deux, mais la rotation ne peut pas réparer un identifiant délibérément accepté partout.

Les noms d'environnement ne suffisent pas

Le développement, le staging et la production ne sont utiles comme étiquettes que lorsqu'ils correspondent à des décisions de confiance différentes. Un hôte appelé staging peut contenir des données proches de la production, envoyer de vrais e-mails, conserver un secret de signature ou se connecter à un service de paiement réel. À l'inverse, un hôte de supervision en production peut avoir moins d'autorité qu'un administrateur de base de données de staging.

Classez les accès SSH selon l'effet d'une session, pas selon un préfixe de nom d'hôte. Je commence généralement par quatre questions :

• Ce compte peut-il lire des données clients ou réglementées ?
• Peut-il modifier un service actif, un déploiement, un pare-feu ou un enregistrement DNS ?
• Peut-il récupérer un autre identifiant ou usurper un autre service ?
• Peut-il rebondir vers des systèmes disposant de plus d'autorité ?

Si la réponse change selon les hôtes, le périmètre de l'identifiant doit changer lui aussi. Cela produit souvent des groupes plus utiles que le modèle classique à trois environnements : développement applicatif, systèmes de test contenant des données sensibles, hôtes de publication, diagnostic en production en lecture seule et administration de production.

Un compte Unix distinct a souvent sa place dans la conception. Un compte nommé deploy peut posséder le répertoire de publication et accepter une commande limitée. Un compte nommé ops-read peut consulter les journaux sans modifier les unités de service. Un compte nommé admin peut effectuer la maintenance selon un niveau de validation plus élevé. Des comptes distincts donnent au serveur un point d'attache pour les permissions et donnent aux journaux un sujet identifiable.

Ne vous laissez pas tromper par des noms de comptes distincts au point d'accepter un identifiant partagé. Si la même clé publique apparaît sous dev, deploy et admin sur des machines différentes, la clé privée reste un identifiant inter-environnements. Les comptes distincts et les identifiants distincts résolvent des aspects différents du problème.

Donnez une identité propre à chaque personne et chaque processus

Chaque opérateur humain et chaque processus d'automatisation a besoin d'une identité SSH distincte dans la classe d'environnement qui lui est autorisée. Une clé privée commune à toute l'équipe ralentit la réponse aux incidents, car retirer l'accès d'une personne oblige à la remplacer pour tout le monde. Les journaux deviennent également presque inutiles lorsque plusieurs personnes s'authentifient avec le même compte et la même clé publique.

Pour un opérateur humain, créez des clés privées distinctes pour les périmètres autorisés. Utilisez des noms qui indiquent le périmètre, plutôt que des noms vagues comme id_ed25519_new ou server-key-final.

mkdir -p ~/.ssh/identities
chmod 700 ~/.ssh/identities

ssh-keygen -t ed25519 \
  -f ~/.ssh/identities/id_ed25519_dev_alex \
  -C dev-alex

ssh-keygen -t ed25519 \
  -f ~/.ssh/identities/id_ed25519_stage_alex \
  -C stage-alex

ssh-keygen -t ed25519 \
  -f ~/.ssh/identities/id_ed25519_prod_alex \
  -C prod-alex

Le commentaire aide à examiner une liste de clés publiques, mais il n'impose rien. Le serveur décide de l'accès à partir de la clé publique, du compte et des règles d'autorisation. Considérez les commentaires comme des étiquettes destinées aux opérateurs, pas comme des métadonnées de sécurité.

L'automatisation mérite la même discipline. Une tâche de publication doit utiliser un identifiant attribué à cette tâche et à cet environnement, pas l'identité de production d'un ingénieur copiée dans un gestionnaire de secrets. Si plusieurs tâches ont besoin d'un accès, donnez-leur des identités distinctes, sauf si elles ont le même responsable, le même ensemble de cibles et la même autorité de commande. Un identifiant doit permettre de répondre simplement à cette question lors de l'analyse d'un incident : quel processus l'a utilisé ?

Les identifiants protégés par du matériel peuvent rendre le vol d'un fichier de clé privée plus difficile, mais ils ne corrigent pas une conception d'autorisation trop large. Un identifiant protégé par du matériel et accepté par tous les environnements donne toujours accès à tous les environnements. Commencez par le périmètre, puis choisissez comment protéger chaque clé privée.

La configuration du client doit empêcher la fuite d'identité

OpenSSH essaie les identités définies dans la configuration et, sauf restriction, celles proposées par un agent SSH. Ce comportement est pratique jusqu'au moment où un agent contient une identité de production et qu'une connexion destinée au staging réussit avec cette identité.

Le manuel ssh_config d'OpenSSH décrit IdentitiesOnly comme un contrôle qui limite les identités utilisées pour l'authentification par clé publique aux fichiers d'identité et aux certificats configurés, même lorsqu'un agent contient d'autres identités. Activez cette option pour chaque alias d'hôte délimité. Donnez à chaque alias un fichier d'identité explicite et ne dépendez pas de l'ordre dans lequel un agent propose ses clés.

Host dev-*
  User devops
  IdentityFile ~/.ssh/identities/id_ed25519_dev_alex
  IdentitiesOnly yes
  ForwardAgent no

Host stage-*
  User release
  IdentityFile ~/.ssh/identities/id_ed25519_stage_alex
  IdentitiesOnly yes
  ForwardAgent no

Host prod-*
  User admin
  IdentityFile ~/.ssh/identities/id_ed25519_prod_alex
  IdentitiesOnly yes
  ForwardAgent no

Utilisez des alias qui rendent l'environnement impossible à manquer dans l'historique du terminal. Par exemple, prod-api-01 vaut mieux que api-01 lorsque le développement et la production contiennent chacun un hôte API aux noms similaires. Ne dissimulez pas la cible derrière un alias générique comme server.

Vérifiez la configuration finale qu'utilisera OpenSSH. Cela permet de repérer les collisions de caractères génériques, les fichiers inclus et un paramètre global oublié.

ssh -G prod-api-01 | grep -E '^(hostname|user|identityfile|identitiesonly|forwardagent) '

La sortie devrait avoir cette forme :

hostname prod-api-01.internal
user admin
identitiesonly yes
forwardagent no
identityfile ~/.ssh/identities/id_ed25519_prod_alex

Le chemin peut être développé différemment sur votre machine. L'essentiel est que l'alias de production corresponde uniquement à l'identité de production et que identitiesonly indique yes.

Un échec fréquent survient après l'exécution de ssh-add pour des raisons pratiques. L'agent contient alors plusieurs identités. Sans IdentitiesOnly yes, le client les essaie sur un hôte jusqu'à ce que l'une d'elles fonctionne. Les serveurs limitent souvent le nombre de tentatives d'authentification, ce qui peut provoquer des erreurs déroutantes. Pire encore, un identifiant trop large peut faire réussir la connexion discrètement, sans que l'opérateur remarque qu'il a utilisé le mauvais périmètre.

L'autorisation du serveur doit refléter la séparation

Des clés privées distinctes ne fonctionnent que si chaque serveur accepte la clé publique correspondante et refuse les autres. Placez la clé publique de développement sur les hôtes de développement, celle du staging sur les hôtes de staging et celle de production uniquement là où l'accès à la production est prévu.

Cette règle semble évidente, mais le mauvais modèle est fréquent lors d'une mise en place urgente : quelqu'un copie un fichier authorized_keys complet sur un nouvel hôte. Ce fichier contient souvent des identités obsolètes datant de plusieurs années, d'anciens prestataires, des clés de déploiement et une clé d'administrateur générale. Le nouvel hôte de production hérite alors de décisions d'accès que personne n'a examinées.

Construisez la liste d'autorisation de chaque compte à partir de sa fonction. Pour un compte de déploiement, utilisez les restrictions OpenSSH adaptées à un transfert ou à une opération de publication non interactive. Le manuel authorized_keys d'OpenSSH documente l'option restrict, qui désactive la redirection de ports, la redirection d'agent, la redirection X11 et l'allocation d'un PTY, sauf si une autre option les autorise. Une entrée de déploiement restreinte peut ressembler à ceci :

restrict,from="198.51.100.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... prod-release-job

Remplacez le réseau d'exemple par une plage d'adresses que vous contrôlez réellement. N'ajoutez pas from= uniquement parce que cette option semble stricte. Si la tâche provient d'adresses changeantes ou d'un parc d'exécuteurs hébergés, une restriction de source incorrecte provoquera une panne et incitera quelqu'un à supprimer toutes les restrictions sous la pression.

Utilisez les commandes forcées uniquement pour une automatisation précisément définie. Une commande forcée peut empêcher un identifiant de déploiement d'obtenir un shell, mais elle devient aussi un contrat de maintenance. La commande doit valider ses entrées, choisir les chemins avec prudence et journaliser la demande. N'appliquez pas de commande forcée à un compte administrateur en supposant que le compte est alors sûr ; les utilisateurs finiront par avoir besoin d'un shell et contourneront la restriction.

Pour l'administration humaine de la production, un compte distinct accompagné d'une clé publique distincte est généralement plus clair que des options authorized_keys complexes. Restreignez le compte avec les permissions normales de l'hôte, consignez son activité sudo lorsque cela s'applique et retirez la clé publique lorsque la personne n'a plus besoin de l'accès.

Les certificats SSH ne sont utiles que si leurs attributs restent limités

Les certificats OpenSSH peuvent simplifier l'attribution et la révocation opérationnelle d'un accès de courte durée. Une autorité de certification signe la clé publique d'un utilisateur, et les serveurs font confiance à l'autorité plutôt que de stocker chaque clé publique individuelle. Cela peut réduire le travail nécessaire pour mettre à jour de grands parcs de machines.

Ils ne suppriment pas le besoin de séparer les autorités. Un certificat doté d'un principal de production ne devrait pas aussi donner accès au développement et au staging simplement parce qu'un opérateur travaille dans les trois environnements. Émettez des certificats distincts, utilisez des principaux différents ou séparez les autorités de certification lorsque les frontières administratives et les risques le justifient.

Le protocole de certificats OpenSSH distingue les certificats utilisateur, les principaux, les intervalles de validité et les options critiques. Cette structure n'est utile que si le serveur vérifie les principaux et si les règles d'émission restent étroites. Un certificat valide pour chaque compte sur chaque hôte transforme simplement une clé privée en identité de porteur largement approuvée, avec une date d'expiration.

Des certificats de courte durée aident en cas d'appareil perdu ou de départ d'un membre du personnel, mais ils ne remplacent pas la révocation lors d'un incident en cours. Vous devez toujours pouvoir empêcher rapidement l'acceptation d'une identité compromise ou retirer son autorisation. Prévoyez ce mécanisme avant d'émettre les certificats et testez-le sur un véritable hôte.

Les certificats ne résolvent pas non plus le mauvais usage d'un agent. Si un processus automatisé peut obtenir un certificat de production chaque fois qu'il le demande, le service d'émission constitue la frontière de production. Protégez-le avec le même soin qu'une clé privée de production.

La redirection d'agent franchit une frontière invisible

La redirection d'agent SSH permet à un hôte distant de demander à votre agent local de signer des défis d'authentification pour d'autres hôtes. La machine distante ne reçoit pas la clé privée, mais un processus exécuté sous le compte distant peut utiliser l'agent redirigé tant que votre session reste ouverte.

La redirection est donc particulièrement dangereuse pour une session de production qui arrive d'abord sur un hôte relais. Si cet hôte est compromis, ou si un processus non fiable s'exécute sous ce compte, il peut demander des signatures pour toutes les identités proposées par votre agent redirigé. Le résultat peut être un accès latéral que votre plan de connexion initial ne mentionnait jamais.

Conservez cette valeur par défaut dans la configuration du client :

Host *
  ForwardAgent no

Créez ensuite une seule exception explicite lorsqu'un flux de travail maintenu l'exige. Avant de l'ajouter, demandez-vous si ProxyJump, un identifiant dédié pour le bastion ou une opération effectuée localement permettrait de s'en passer. ProxyJump transporte la connexion SSH via un hôte intermédiaire ; il n'expose pas votre agent local à cet hôte de la même manière.

Ne croyez pas que la redirection est sûre parce que la clé privée reste sur l'ordinateur portable. Un oracle de signature peut suffire à s'authentifier ailleurs. La distinction compte lors d'une compromission : protéger un fichier ne revient pas à limiter ce qui peut utiliser l'identifiant.

Le périmètre de validation doit correspondre au périmètre de l'identifiant

Une validation autorisant un nouveau processus à utiliser un identifiant SSH devrait indiquer l'environnement de cet identifiant et le processus qui en fait la demande. Une invite qui dit seulement ssh command requested demande à une personne de déduire trop de choses à partir de trop peu d'informations.

C'est ici que les équipes confondent souvent deux contrôles. Le périmètre de l'identifiant indique où une identité peut s'authentifier. Le périmètre de validation indique quel processus en cours peut utiliser cette identité. Les deux sont nécessaires. Des identifiants de production distincts empêchent un processus de développement d'atteindre la production par accident ; la validation d'un processus empêche un processus local inconnu d'utiliser un identifiant de production disponible.

La validation commande par commande semble plus sûre, et les équipes la demandent souvent après un incident inquiétant. Elle échoue généralement lors de la maintenance courante, car les demandes répétées habituent les opérateurs à approuver sans lire. Réservez la confirmation à chaque utilisation aux identifiants dont l'utilisation exige elle-même une décision humaine, par exemple une identité d'administration de production à fort impact. Pour le travail courant, accordez une autorisation de session qui prend fin lorsque le processus se termine, puis gardez le périmètre côté serveur étroit.

Sallyport conserve les identifiants SSH dans son coffre chiffré et peut exiger une autorisation pour un nouveau processus d'agent, ou une validation à chaque utilisation pour un identifiant choisi. Cela ne remplace pas l'autorisation distincte du serveur, mais rend la frontière du processus explicite sans transmettre l'identifiant à l'agent.

Un agent de programmation IA mérite une séparation plus stricte qu'un terminal interactif, car il peut exécuter rapidement de nombreuses commandes et suivre une instruction incorrecte. Donnez-lui par défaut un accès au développement. S'il a besoin du staging, utilisez une identité limitée au staging et une exécution approuvée distincte. Traitez l'accès à la production comme une opération différente, avec une cible nommée et un objectif précis.

L'échec commence souvent par une exception anodine

Prenons une équipe qui utilise une seule clé SSH ops, acceptée par les hôtes de développement, de staging et de production. Un ingénieur charge cette clé dans un agent SSH pour une fenêtre de maintenance en production. Plus tard, un outil local d'aide à la compilation ouvre une connexion SSH vers un hôte de staging pour collecter des journaux.

L'outil n'a pas de paramètre IdentityFile explicite et IdentitiesOnly est absent. OpenSSH essaie les identités de l'agent. La clé partagée ops fonctionne, puisque le staging l'accepte. L'outil dispose maintenant d'une session de staging authentifiée avec une identité qui fonctionne également en production.

Une deuxième erreur suit. La redirection d'agent est activée sur l'hôte de staging parce que quelqu'un avait besoin d'une connexion ponctuelle le mois précédent. Un processus exécuté sur cet hôte peut demander des signatures via l'agent redirigé. Il atteint un hôte de production avec la même identité ops. L'ingénieur initial avait approuvé une session de maintenance en production, mais un outil sans rapport et un hôte de staging ont hérité de son autorité.

Aucun exploit n'exige de clé privée divulguée dans cette séquence. La conception autorisait une identité trop large, le client l'a choisie de manière opportuniste et la redirection a étendu sa portée. Les journaux peuvent afficher une authentification valide du début à la fin, ce qui explique pourquoi les équipes parlent d'erreur utilisateur au lieu de corriger le modèle d'accès.

Une conception séparée brise la chaîne à plusieurs endroits. L'outil utilise uniquement un identifiant de staging. La production refuse cet identifiant. La redirection d'agent reste désactivée. L'identité de production n'est disponible que pour un processus de production explicitement autorisé. Chacun de ces contrôles aide ; ensemble, ils font échouer rapidement la mauvaise connexion.

La rotation et la révocation d'urgence nécessitent un ordre éprouvé

La rotation fonctionne lorsque vous ajoutez un remplacement avant de supprimer l'ancien identifiant, vérifiez le chemin exact, puis révoquez l'ancien. Les rotations de production échouent lorsque quelqu'un teste uniquement depuis son ordinateur portable alors que le véritable outil de publication se connecte depuis un autre compte, réseau ou exécuteur d'automatisation.

Pour une rotation normale, suivez cet ordre :

1. Créez un identifiant de remplacement avec le même périmètre étroit que l'ancien.
2. Ajoutez l'autorisation de sa clé publique ou de son certificat au compte et aux hôtes prévus.
3. Testez la commande réelle depuis le véritable chemin du processus, y compris tout hôte relais.
4. Supprimez l'ancienne autorisation et confirmez que l'ancien identifiant échoue désormais.
5. Enregistrez l'empreinte, le responsable, le périmètre et la date de suppression du remplacement dans le registre des accès.

Conservez une procédure d'accès d'urgence, mais n'en faites pas un second identifiant d'administrateur permanent copié sur chaque poste de travail. Stockez-le séparément, limitez les personnes qui peuvent l'activer et testez-le dans des conditions contrôlées. Une procédure d'urgence que personne n'a exercée devient un exercice de devinettes pendant une panne.

La révocation d'urgence est différente. Si un identifiant de production est susceptible d'avoir été exposé, retirez immédiatement sa clé publique ou cessez d'accepter son certificat, puis remplacez-le. N'attendez pas la fenêtre de rotation planifiée, car un attaquant ne respectera pas votre calendrier. Le compromis est une perturbation opérationnelle, ce qui explique l'intérêt des identifiants étroits : révoquer une identité de déploiement de production ne devrait pas interrompre le développement.

Testez les accès refusés et examinez les preuves

La séparation des accès n'est terminée que lorsque le mauvais identifiant échoue d'une manière que vous pouvez expliquer. Après chaque changement important, effectuez un test négatif volontaire : utilisez l'identité de développement contre un hôte de production et vérifiez que l'authentification par clé publique échoue. Testez ensuite l'identifiant attendu et examinez le nom du compte et la cible dans l'enregistrement de connexion.

Utilisez la sortie détaillée du client pendant les tests, pas comme habitude permanente :

ssh -vvv -o IdentitiesOnly=yes \
  -i ~/.ssh/identities/id_ed25519_dev_alex \
  [email protected]

Vous devriez voir le client proposer la clé publique de développement et le serveur la refuser. Ne copiez pas cette sortie dans des tickets sans la vérifier d'abord ; les journaux SSH détaillés peuvent révéler des noms d'hôtes, des noms d'utilisateur et des informations d'authentification.

Les journaux du serveur doivent permettre de répondre aux questions suivantes : qui s'est authentifié, quel compte a été utilisé, quelle empreinte de clé publique le serveur a acceptée et d'où provenait la connexion. Si plusieurs personnes ou processus partagent une identité, le journal ne pourra pas reconstituer cette attribution manquante par la suite.

Recherchez les dérives de frontière : une clé de développement ajoutée à un compte de production, un ancien identifiant de déploiement toujours accepté, une clé de production chargée dans un agent polyvalent ou une règle générique du client qui annule IdentitiesOnly. Ces changements arrivent souvent comme des solutions temporaires. Un accès SSH temporaire a tendance à survivre longtemps après l'urgence qui l'a créé.

Commencez par inventorier chaque clé publique acceptée sur les hôtes de production et étiquetez-la selon son responsable, son processus, son objectif et son périmètre. Toute entrée qui ne peut pas satisfaire cette description en quatre points ne devrait plus rester autorisée.