Le référentiel de l’ANSSI publié par le MagIT pour les entités assujetties à la directive NIS2 en France mentionne à plusieurs reprises les risques liés aux accès des « processus automatiques ».
Objectif #10 : L’entité sécurise les accès distants à ses SI réglementés
En l’absence d’un tel objectif, l’entité s’expose, par exemple, à des vols de secrets d’authentification et à des accès illégitimes à ses SIR via les accès distants légitimes des personnels de l’entité, des processus automatiques ou des prestataires de l’entité, pouvant entraîner la dégradation voire l’interruption des activités ou services qu’elle fournit ou encore la divulgation d’informations sensibles.
Objectif #13 : L’entité gère les identités et les accès des utilisateurs à ses SI réglementés
L’atteinte de cet objectif permet à l’entité de maîtriser les utilisateurs accédant à ses systèmes d’information réglementés, que ces derniers soient internes ou externes à l’entité (par exemple : les prestataires) ainsi que les processus automatiques (par exemple : les agents de supervision ou de sauvegarde) via des mécanismes d’identification et d’authentification à l’état de l’art. L’atteinte de cet objectif permet également à l’entité de maîtriser les accès afin que ces utilisateurs n’accèdent qu’aux seules ressources utiles pour l’accomplissement de leurs missions.
A quoi l’ANSSI se réfère-t-elle par cette expression ?
Il s’agit clairement de comptes de service – des comptes à part entière dans les annuaires des entreprises, indiscernables à priori des comptes d’employés ordinaires.
Mais au contraire des comptes « humains », ces comptes de service accomplissent des tâches automatisées prédéfinies. Par exemple, un agent de sauvegarde s’authentifiera tous les jours à la même heure afin d’extraire les données du SI réglementé et les sauvegarder dans une base de données externe afin de mitiger les dégâts d’un ransomware.
Du fait qu’ils opèrent entre différents systèmes informatiques sans l’intervention d’un humain, on désigne souvent ces accès par l’anglicisme « machine-to-machine ».
Dans l’objectif #13 de la transposition de NIS2, s’appliquant à toutes les entités (à la fois ‘essentielles’ et ‘importantes’) concernées par la directive, l’ANSSI exige la mise en œuvre de plusieurs mesures censées mitiger les risques liés à ces « processus automatiques ». Cela inclut notamment les points suivants :
- Les utilisateurs et les processus automatiques accédant aux ressources des systèmes d’information réglementés (SIR) de l’entité importante ou essentielle disposent de comptes individuels. Les utilisateurs peuvent, le cas échéant, disposer de plusieurs comptes individuels.
- L’emploi d’un compte individuel du SIR est réservé à l’utilisateur ou au processus automatique auquel ce compte a été attribué.
- Lorsque des raisons techniques ou opérationnelles ne permettent pas de créer de comptes individuels pour les utilisateurs ou pour les processus automatiques, l’entité met en place des mesures permettant de réduire le risque lié à l’utilisation de comptes partagés et d’assurer la traçabilité de l’utilisation de ces comptes.
- L’entité désactive sans délai les comptes qui ne sont plus nécessaires.
- L’entité protège les accès des utilisateurs et processus automatiques aux ressources de ses systèmes d’information réglementés (SIR) au moyen d’un mécanisme d’authentification (par exemple : un mécanisme d’authentification mono- ou multi-facteur) impliquant au moins un élément secret (par exemple : un facteur de connaissance tel qu’un mot de passe).
- Pour chaque utilisateur ou chaque processus automatique, l’entité n’attribue les droits d’accès qu’aux seules ressources nécessaires à la réalisation des activités et services de l’entité ou au maintien en condition opérationnelle ou de sécurité.
- Lorsque des raisons techniques ou opérationnelles ne permettent pas de modifier l’élément secret [d’un compte humain ou d’un processus automatique], l’entité met en œuvre un contrôle d’accès approprié à la ressource concernée ainsi que des mesures de réduction du risque lié à l’utilisation d’un élément secret d’authentification fixe.
- Pour chaque ressource du SIR, l’entité n’attribue les droits d’accès qu’aux seuls utilisateurs et processus automatiques justifiant d’un besoin au regard de leurs missions.
Il vaut la peine de se pencher sur les raisons justifiant de telles mesures, et sur les difficultés à surmonter dans le cadre de leur implémentation. Enfin, nous montrerons comment Silverfort peut aider à répondre à ces exigences de manière simple et rapide.
Pourquoi sécuriser les comptes de service ?
Les comptes de service sont immunisés contre plusieurs types d’attaques visant les comptes d’humains. Ils sont incapables de cliquer sur des liens malveillants ou d’être dupés par des tentatives d’usurpation d’identité et d’hameçonnage. Mais cela ne les rend pas pour autant invulnérables. En effet, on constate qu’ils sont utilisés de plus en plus souvent dans des scénarios d’attaques pour réaliser des mouvements latéraux.
Pour mentionner un exemple bien connu, prenons l’attaque impliquant SolarWinds en 2020 qui affecta plus de 18 000 clients de la société (dont Microsoft, Cisco, et de nombreux départements gouvernementaux américains). Les attaquants russes, dénommés CozyBear, avaient établi une porte dérobée dans le logiciel Orion que SolarWinds vendait à ses clients, leur permettant ainsi de s’infiltrer dans les SI de chaque entité opérant l’outil. Le logiciel en question employait des comptes de service pour scanner le réseau et accéder à d’autres ressources. CozyBear put donc aisément exploiter ces accès pour se propager et s’implanter chez leurs victimes.
Cet exemple illustre très bien les risques que posent ces accès machines. Ils opèrent généralement sans grande supervision. Leur comportement est complètement prédéterminé et prévisible : ils interviennent généralement à la même heure, depuis la même source, et vers la même destination, à intervalle régulière (par exemple, tous les jours à 15h) pour accomplir le « processus automatique » qui leur est confié. Le processus en question étant souvent d’ordre administratif, il nécessite qu’il leur soit octroyés des privilèges élevés.
Lorsqu’il s’agit de comptes de service dans le Cloud, leur traçabilité est assurée et les équipes de surveillance peuvent aisément détecter tout comportement anormal. Mais dans l’infrastructure on-premise, plus ancienne, les risques sont plus élevés.
Tout d’abord, dans l’annuaire Active Directory de l’entreprise, le seul moyen de les distinguer des comptes humains est par une convention de nommage spécifique.
Deuxièmement, il est difficile de surveiller leurs activités au quotidien, de changer leurs mots de passe, ou d’empêcher un individu possédant les identifiants du compte d’y accéder librement.
Enfin, ils ne peuvent répondre à une demande d’authentification multi-facteur, comme le font les utilisateurs humains pour s’assurer que leur compte n’a pas été usurpé.
On comprend donc pourquoi les attaquants, et également l’ANSSI, considèrent les comptes de service comme une cible stratégique. En devinant ou trouvant leurs mots de passe (parfois stockés négligemment dans des partages de fichiers réseaux), ces comptes deviennent une clé passepartout permettant de se propager librement dans l’infrastructure de leurs victimes et d’y installer des codes malveillants.
Quelles mesures les sociétés peuvent-elles mettre en œuvre pour mitiger ces risques ? Et quelles limites risquent-elles de rencontrer en chemin ?
Les obstacles à surmonter
Des bonnes pratiques d’hygiène des SI et le principe du « moindre privilège » permettent de réduire considérablement les moyens par lesquels les attaquants peuvent obtenir les identifiants des comptes de service et les détourner à des fins malveillantes.
Il convient donc de suivre les conventions de nommage pour clairement identifier quels comptes sont effectivement des comptes de service et les distinguer d’accès humains ordinaires, et par la suite, d’analyser leurs privilèges pour s’assurer qu’ils sont appropriés à leur mission.
Cependant, même ces simples mesures peuvent être difficile à implémenter rétroactivement pour les comptes les plus anciens, parfois décrits comme « légacy ». La plupart auront été créés avant l’établissement d’une quelconque convention de nommage. Dans les plus grandes entreprises, on en compte probablement des centaines voire des milliers, donc un projet d’analyse et de nettoyage s’avèrerait extrêmement chronophage.
Dans de tels SI, on sait rarement où sont les comptes de service, quelle fonction ils accomplissent, quel est leur mot de passe, et ainsi de suite. Ils continuent d’opérer en arrière-plan, parfois depuis des décennies, à l’insu des responsables informatique.
L’ANSSI exige que chaque compte de service soit réservé au processus automatique pour lequel il a été créé, et donc qu’il ne soit pas détourné à d’autres fins. Lorsqu’il s’agit de réaliser des tâches critiques, les administrateurs passent généralement soit par un poste d’administrateur dédié (PAW), soit par un bastion à travers lequel leurs actions sont surveillées et enregistrées. En théorie, aucun utilisateur n’a le droit d’accéder aux ressources sensibles depuis un compte ordinaire – toute tentative serait rejetée.
Cependant, les moyens qu’Active Directory propose nativement pour limiter les privilèges des différents comptes de service sont difficiles à implémenter, et l’opacité entourant leur activité au quotidien entraine des risques dans l’élaboration de politiques d’accès (GPO). Si une politique venait par exemple à empêcher l’un de ces comptes d’accéder à une ressource, cela pourrait entraîner la faillite du processus – souvent critique – sur lequel il dépend.
Les comptes de service échappent donc souvent aux restrictions s’appliquant aux comptes d’administration humains (PAW, bastion…), laissant la porte ouverte à leur détournement par des administrateurs peu scrupuleux ou des attaquants. Le cas échéant, peu de moyens existent pour surveiller leurs actions et s’assurer qu’ils n’introduisent pas de vulnérabilités dans le système.
Concernant les mots de passe, enfin, Microsoft fournit désormais les moyens de créer des comptes de service « administrés de groupe » (gMSA) avec des changements de mots de passe réguliers. Cependant, certaines limites demeurent : les comptes de service opérant sur des systèmes autre que Windows (notamment Unix/Linux) ne sont pas compatibles, et certains comptes auront un mot de passe codé en dur qu’il est impossible de modifier.
Pour résumer, l’ANSSI souhaite que les entités concernées par NIS2 sécurisent leurs comptes de service en assurant :
- qu’ils soient utilisés exclusivement pour le processus pour lequel ils ont été créé ;
- qu’ils soient désactivés dès qu’ils ne sont plus nécessaires ;
- que leurs mots de passe changent régulièrement ;
- que leurs privilèges soient proportionnels à leur mission.
Malheureusement, pour chacune de ces exigences, des limitations en termes de visibilité mènent rapidement à des difficultés dans l’implémentation de ces mesures. Le cas échéant, l’ANSSI requiert que des contrôles appropriés soient mis en œuvre pour mitiger les risques occasionnés.
Comment Silverfort sécurise les comptes de service
La technologie Silverfort permet d’identifier et de sécuriser les comptes de service de manière rapide et efficace.
Pour résoudre les difficultés liées à la visibilité et traçabilité des accès, Silverfort se positionne derrière l’Active Directory (ainsi que d’autres annuaires compatibles), consolide et surveille l’intégralité des authentifications au sein du SI.
Ainsi, en l’espace de quelques semaines, nous sommes en mesure d’identifier lorsqu’un compte opère de manière prévisible et répétitive, caractéristique d’un compte de service.
Nous les étiquetons, fournissant ainsi rapidement un inventaire complet de tous les comptes de service de l’organisation, incluant ceux qui n’obéissent pas à la convention de nommage.
Nous identifions également les comptes « hybrides » : ceux qui s’apparentent à un compte machine mais dont le comportement dévie de la normale de manière spontanée – signe qu’ils sont également utilisés par des humains ; et inversement les comptes nominatifs d’administrateurs depuis lesquels opèrent des processus automatiques.
Enfin, nous mettons en lumière toutes les sources depuis lesquelles ces comptes s’authentifient, ainsi que leur(s) destination(s). Cela s’accompagne par un score de risque pour mettre en avant les comptes accédant à des ressources sensibles, ayant des privilèges trop élevés, ou dont le mot de passe n’a pas été changé depuis longtemps.
La plateforme fournit ainsi une visibilité accrue aux équipes en charge des identités et de la sécurité. En moins d’un mois, elles auront à leur disposition une liste complète de comptes qui enfreignent les recommandations de l’ANSSI, qu’elles pourront prioriser dans leurs démarches de réduction de risques.
Au-delà de l’hygiène, Silverfort propose également des outils redoutables pour sécuriser ces accès machine.
En surveillant justement les authentifications en temps réel, notre plateforme peut alerter le SOC dès qu’un compte de service dévie de son comportement habituel.
De plus, Silverfort peut mettre en place des contrôles d’accès granulaires sur ces comptes, de manière bien plus simple et chirurgicale que les politiques configurables dans l’Active Directory.
Nous donnons les moyens aux équipes responsables de configurer précisément quelles sources et quelles destinations sont autorisées pour chaque compte de service, et également restreindre leurs permissions en fonction de paramètres spécifiques.
Ainsi, nous pouvons bloquer toute tentative de déviation d’un compte de service au-delà des fonctions pour lesquelles il a été créé. Si un administrateur tente de s’authentifier depuis un poste non-autorisé ou de contourner le bastion, ou un attaquant souhaite réaliser des mouvements latéraux par leur intermédiaire, leur tentative sera automatiquement bloquée.
Cette fonction s’accomplit sur l’intégralité des comptes de service opérant dans les annuaires compatibles, notamment l’Active Directory, même si leurs mots de passe sont codés en dur ou s’ils sont employés sur des environnements au-delà de Windows.
Par ces moyens, Silverfort peut aider toutes les entités concernées par NIS2 dans leurs projets de mise en conformité par rapport aux mesures s’appliquant aux « processus automatiques ».