Face aux attaques permanentes sur les administrations, nous incitons de plus en plus lourdement à l’authentification multi-facteurs pour les comptes utilisateurs. Elle est désormais obligatoire sur le Bnum. Mais on a parfois tendance à oublier les comptes de service, entre applications, qui portent des accès agrégés.
Là où un inspecteur n’analyse pas 1000 dossiers dans la journée et pourra donc être limité par des quotas applicatifs, une API ou un serveur frontal peut légitimement toucher pratiquement l’intégralité de la base de données pendant la même journée.
C’est la raison pour laquelle une authentification reposant sur la seule clé d’API est très problématique. Certes, la clé comprend suffisamment de bits d’aléa et elle n’est pas manipulée au quotidien par un humain, mais si la simple connaissance de la clé donne accès aux données, le système n’a aucun garde-fou contre des erreurs d’exploitation ou des attaques de plus en plus guidées par des automates dopés à l’IA. L’attention est attirée en particulier sur les services de type S3, généralement limités aux clés d’API car mutualisés, quand les références d’objets sont elles-mêmes prévisibles.
Que proposons-nous ?
En l’absence de solution plus lourde (mTLS avec certificat embarqué dans une puce TPM, ce qui serait l’équivalent de la carte agent), il faut en revenir au bon sens : les listes d’accès par IP sont un moyen éprouvé de ne pas s’exposer à tous les vents. N’importe quel SGBD ou serveur SSH permet de limiter les connexions d’un compte à des IP dans la configuration des droits d’accès (clause GRANT en SQL, préfixe from dans authorized_keys, etc.). Un pare-feu en amont peut aussi jouer le même rôle.
Pour ceux qui travaillent avec des partenaires via Internet, avec des infrastructures Cloud plus fluctuantes, les règles peuvent être adaptées en s’inspirant de l’email. Le reverse-DNS permet à la fois de garder un minimum de souplesse et d’auto-documenter le contrôle d’accès, en autorisant par exemple plateforme.partenaire.fr et non son IP. C’est ainsi que procède DossierFacile pour son API. Se reposer uniquement sur la sécurisation du DNS serait inapproprié mais comme second facteur, c’est un garde-fou pragmatique et efficace.
Mention spéciale
Puisque nous évoquions l’exemple de l’email, qui utilise historiquement le DNS comme facteur de sécurisation (résolution reverse puis forward pour identifier les serveurs non légitimes), ce mémo est aussi l’occasion d’adresser un message à certains développeurs et intégrateurs de SI. Quand notre pôle ministériel choisit une politique DMARC (authentification des serveurs émetteurs d’email) de niveau reject, que leur propre ESN employeur fait de même pour son domaine, il n’y a pas lieu de nous demander d’abaisser ce niveau parce que « cela gêne » l’envoi d’email en masse. C’est justement l’objet de cette politique de sécurisation. A bon entendeur...