C’était un dossier d’audit SSI comme j’en ai vu tant d’autres. Le prestataire qualifié par l’ANSSI avait rapidement découvert les pratiques locales : un compte équivalent à root était utilisé par tous les techniciens pour configurer les serveurs. Comme leurs « consoles » étaient en fait des PC bureautiques, il n’existait évidemment pas de durcissement et les mots de passe n’étaient pas du niveau de complexité attendu par les auditeurs et leur rotation pour ainsi dire absente.
S’ensuivait une liste de prescriptions longue comme le bras, avec restructuration profonde de l’Active Directory et évidemment préconisation d’un plan de remédiation par des « spécialistes ». Je n’ai pas suivi l’affaire mais il y a fort à parier qu’un contre-audit deux ans plus tard aura fait approximativement les mêmes constats.
Car quel est le problème en amont ? Sait-on qu’un ingénieur ou technicien se connecte parfois à plusieurs dizaines de machines par jour au gré des actions demandées par des tickets, quand il n’est pas interrompu par un incident où on lui demande de plonger immédiatement dans un environnement différent ? Peut-on réalistement penser qu’il va utiliser un mot de passe différent pour chaque machine, de plus de 15 caractères, avec des caractères spéciaux, changé tous les 3 mois ?
L’ergonomie du système conduit naturellement à des usages sécurisés
Comparez avec votre carte bancaire. Vous pouvez l’utiliser une dizaine de fois dans la journée pour de menus achats auprès d’autant de commerçants. Votre banque ne vous a même pas obligé à changer votre code PIN depuis des années. Et pourtant la sécurité est excellente au point qu’on puisse imputer indubitablement à votre compte toute transaction réalisée avec la carte présente (la vente en ligne est un autre sujet). Du coup, vous ne passez pas votre carte à n’importe qui…
Il est tout à fait possible de faire exactement la même chose avec SSH. Nous l’avons mis en place à l’échelle déjà de 250 comptes par des bastions entrants mais nous visons au-delà des machines des centres serveurs sous notre gestion.
Des bastions, une carte à puce : une solution simple pour sécuriser aussi les accès aux serveurs externes
Avec l’expérience, nous savons bien qu’il y a des utilisateurs qui ont des besoins légitimes d’utiliser des serveurs externes. S’ils n’ont pas la patience d’attendre le traitement de leur dérogation à la PFAI de l’Etat, ils y accèdent souvent dans des conditions folkloriques, par exemple en interconnectant leur PC portable à leur ordiphone 4G personnel. Ces serveurs externes sont encore souvent gérés par mots de passe et la liste des violations aux « bonnes règles SSI » comme des dérogations dans les parefeux peut être presque aussi longue que l’audit présenté en début d’article.
Selon notre analyse que l’ergonomie est un préalable à la cybersécurité, il nous revenait de proposer une solution innovante pour y accéder et depuis quelques mois, nous avons mis à disposition des bastions SSH sortants, toujours aussi simples à utiliser dès que vous avez une carte. Pas de justification à formuler, seulement une demande d’activation du service en sachant que les connexions sortantes seront journalisées (horodatage et IP, le contenu reste chiffré de bout en bout).
Après les retours d’expérience, nous pouvons maintenant passer à l’annonce formelle qu’à partir du 14 juillet 2023, les flux SSH quittant l’Intranet devront passer par ces bastions sortants. Passé cette date, les dérogations historiques mises en place via règles spécifiques de parefeux pourront être démantelées sans délai de prévenance, en fonction des activités des équipes techniques.
Évidemment, il reste du ressort des utilisateurs de configurer leurs serveurs externes pour y insérer la clé publique correspondant à leur carte et bloquer les accès par mot de passe.
Crédit photo : Arnaud Bouissou / Terra