Pourquoi demander des cartes RGS** pour se connecter aux serveurs ?

Compromissions : des cas d’école qui doivent ouvrir les yeux

Il y a quelques jours, les serveurs de Uber ont été visités très publiquement : selon la presse, l’annuaire Active Directory, des comptes d’administration AWS, et GCP ont été compromis. On pourrait penser que cette pénétration est le fait d’experts de hauts niveaux disposant de ressources importantes. Au contraire, les fuites dans les médias portent à croire que le forfait a été réalisé par un jeune homme futé, selon un schéma trop connu quand on travaille dans la cybersécurité. Il a pleinement exploité les faiblesses techniques et humaines, jusque dans les détails de mise en œuvre des authentifications dites « seconde facteur » (2FA). Par du phishing répété au point « d’harceler » ses victimes, il a pu maîtriser un compte VPN pour poser un premier pied dans les infrastructures qu’il a ensuite scannées. Il y a repéré un coffre à jetons d’accès aux autres systèmes et l’affaire était dans le sac.

Cartes bancaires, une réussite à l’échelle mondiale

Ce scénario catastrophe aurait pu être entravé à de multiples endroits mais le barrage le plus efficace consiste à mettre en place une authentification réellement efficace. Or si on prend du recul, on sait parfaitement comment faire, à l’échelle mondiale : alors que toutes les agences nationales alertent sur la montée de la cyber-insécurité, le rapport annuel de l’Observatoire sur la sécurité des moyens de paiement publié par la Banque de France (en toute transparence, j’y ai représenté le ministère de l’économie pendant plusieurs années) démontre sans contestation qu’il n’y a pas d’explosion des fraudes à la carte bancaire, bien au contraire. Dès qu’une carte est matériellement présente dans la transaction (DAB, terminal de paiement dans un commerce), la « fraude brute » n’est que le résidu de différents commerciaux, voire de violences physiques pour faire utiliser une carte. Même les américains se sont résolus à adopter la puce de sécurité dans leurs cartes de crédit.
La dernière preuve que l’authentification est un facteur essentiel, a été apportée par le règlement européen DSP2. Son impact sur la banque en ligne et l’e-commerce est sensible, au prix de l’ergonomie la plupart du temps, il faut bien le reconnaître.

Application dans les SI d’entreprise

Contrairement à l’opinion largement répandue dans les DSI, les cartes à puce sont parfaitement utilisables dans les outils informatiques d’entreprises, SSH en tête. Elles apportent même un certain confort. Un code PIN est bien plus facile à taper qu’un mot de passe dont la longueur doit être logiquement significative pour répondre au besoin de complexité. Et le périmètre de sécurité est immensément réduit : un attaquant ne pourra pas se connecter s’il ne possède pas physiquement de carte.
Pour un agent du pôle ministériel, le processus ne peut être plus simple. Auprès de son support informatique, il fait une demande de CAE (carte agents de l’Etat), avec justificatif d’identité. La carte lui sera remise en face à face par son gestionnaire de cartes. Le certificat X.509 associé à sa carte est automatiquement placé dans l’annuaire. Il peut immédiatement utiliser sa carte pour signer des documents (.pdf .docx), s’authentifier à Chorus (quand il est habilité pour la gestion comptable) ou se connecter aux bastions du centre serveur (quand il est habilité pour l’exploitation informatique)

RGS**

Pour un prestataire informatique, le processus est analogue en procédant à l’acquisition d’une carte RGS** auprès des fournisseurs qualifiés par l’ANSSI. Ce niveau de certification a été choisi parce qu’il correspond exactement aux principes de la carte bancaire : clés embarquées dans une carte à puce, carte associée à un porteur dont l’identité civile est vérifiée (obligation Know Your Customer dans le jargon bancaire), élément qui fait défaut par conception dans les clés FIDO, Yubikey, Solokey, etc.