Vers une gestion dynamique et continue des accès numériques

Points clés La gestion statique des accès — "accordé une fois, révisé annuellement" — ne correspond plus à la vitesse d'évolution des environnements et à la dyn

M
Mehdi SARIAK
24 mai 2026 7 min de lecture 17 lectures
Points clés
  • La gestion statique des accès — "accordé une fois, révisé annuellement" — ne correspond plus à la vitesse d'évolution des environnements et à la dynamique des attaques modernes qui exploitent les fenêtres entre deux revues.
  • SingHealth (2018) : trois mois de présence non détectée malgré des logs existants — l'absence d'analyse comportementale continue des accès a permis à une activité anormale persistante de passer sous les radars.
  • Samsung (2022) : les identifiants d'employés et prestataires utilisés pour accéder aux dépôts de code source depuis des contextes non habituels auraient pu être détectés par une analyse comportementale en temps réel des accès aux ressources de propriété intellectuelle.
  • Le Zero Trust ne se déploie pas en un projet mais s'implémente en couches successives — commencer par les identités et les accès à privilèges produit un retour sur sécurité rapide avant d'étendre à l'ensemble de l'architecture.
  • L'accès juste-à-temps (Just-in-Time access) élimine les droits permanents sur les systèmes critiques : les droits élevés sont accordés pour une durée déterminée et une raison documentée, puis révoqués automatiquement — sans nécessiter d'intervention humaine pour la révocation.

Les modèles traditionnels de gestion des accès reposent sur une logique statique : des droits sont accordés lors du provisioning, éventuellement révisés lors d'une access review périodique, et révoqués lors du déprovisioning. Cette logique était adaptée à des environnements stables avec des périmètres définis et des attaques peu sophistiquées. Elle ne l'est plus dans les environnements hybrides actuels où les ressources, les identités et les contextes d'accès évoluent en permanence, et où les attaquants exploitent précisément les fenêtres d'inactivité entre deux revues statiques.

La gestion dynamique et continue des accès répond à cette limite par trois évolutions complémentaires : une évaluation du contexte à chaque demande d'accès (pas seulement à l'authentification initiale), une surveillance comportementale continue des accès accordés (pas seulement l'alerte lors de dépassement de droits), et une révocation automatisée des accès sur signal de risque (pas seulement lors d'événements planifiés).

L'évaluation contextuelle continue

Dans une architecture d'accès dynamique, chaque demande d'accès à une ressource est évaluée dans son contexte : qui demande (identité, rôle, attributs), depuis quoi (poste conforme ou non, application autorisée), depuis où (localisation, réseau), quand (heure habituelle ou non), et pour faire quoi (action demandée, sensibilité de la ressource). Cette évaluation multi-dimensionnelle permet de différencier une requête normale d'une requête anormale — même si les deux proviennent d'un compte légitime — et d'adapter la réponse en conséquence : accorder sans friction, demander une re-authentification, ou bloquer.

Les moteurs de politique d'accès modernes (Azure AD Conditional Access, Google BeyondCorp, Okta ThreatInsight) implémentent cette logique en analysant en temps réel les signaux de risque associés à chaque session : score de risque de l'identité calculé par le système, conformité du poste vérifiée par l'agent de gestion des terminaux, localisation comparée aux patterns habituels, et comportement de la session comparé à la baseline établie sur l'historique du compte.

Cas documenté — Uber, États-Unis, 2022

L'attaque Uber de 2022 illustre les limites d'un accès statique face à une attaque dynamique. Le compte prestataire compromis disposait de droits d'accès permanents qui restaient valides quelle que soit la façon dont la session était établie. Une gestion dynamique des accès aurait pu identifier plusieurs signaux anormaux en temps réel : une session MFA approuvée après un nombre anormalement élevé de tentatives (signal de MFA fatigue), des accès à des ressources hors périmètre habituel du compte prestataire (signal de comportement anormal), et une découverte de secrets dans des partages réseau (signal d'activité de reconnaissance). Ces signaux, capturés et corrélés par un moteur d'évaluation contextuelle continue, auraient dû déclencher une suspension de session et une alerte SOC avant que l'attaquant n'atteigne les systèmes critiques.

Surveillance comportementale : UEBA

Les solutions UEBA (User and Entity Behavior Analytics) établissent des profils comportementaux pour chaque compte et entité du système d'information : heures d'accès habituelles, ressources accédées, volumes de données consultés, localisation géographique. Toute déviation significative par rapport à cette baseline génère un score de risque élevé et une alerte. L'UEBA est particulièrement efficace pour détecter les compromissions de comptes légitimes — scénario où l'attaquant utilise les credentials d'un vrai utilisateur et où les contrôles d'accès traditionnels ne voient qu'une authentification valide.

La valeur de l'UEBA est proportionnelle à la richesse des logs d'accès collectés : plus les sources de logs sont nombreuses et granulaires (authentifications, accès aux ressources, actions sur les données), plus les profils comportementaux sont précis et plus les anomalies sont détectables. L'absence de logs granulaires sur certains systèmes crée des angles morts dans la surveillance comportementale — typiquement les systèmes hérités qui ne génèrent pas de logs exploitables par les solutions UEBA modernes.

Just-in-Time et Just-Enough-Access

Le Just-in-Time access (JIT) et le Just-Enough-Access (JEA) sont deux principes qui traduisent opérationnellement la gestion dynamique des droits à privilèges. Le JIT signifie que les droits élevés ne sont pas permanents : ils sont accordés à la demande, pour une durée déterminée (généralement 1 à 4 heures selon la tâche), avec documentation de la raison, et révoqués automatiquement à expiration. Le JEA signifie que les droits accordés sont limités aux actions spécifiques requises pour la tâche documentée, pas aux droits globaux d'administrateur. Ces deux principes réduisent la fenêtre d'exposition d'un compte à privilèges à la durée effective de son usage.

Cas documentés
LastPass — États-Unis US · 2022

La violation LastPass illustre comment l'accès statique d'un compte individuel à des environnements cloud critiques — droits accordés une fois, sans réévaluation contextuelle — crée une surface d'attaque persistante. Une approche Just-in-Time aurait imposé au développeur de demander explicitement un accès élevé à l'environnement cloud de production pour chaque intervention, avec durée limitée et traçabilité. Cette friction contrôlée aurait éliminé les droits permanents qui ont permis à l'attaquant, après compromission du poste, d'accéder directement aux ressources de production sans étape supplémentaire d'élévation de privilèges.

British Airways — Royaume-Uni EUROPE · 2018

Le skimming de British Airways, actif pendant 15 jours, aurait pu être détecté plus tôt par une surveillance comportementale des flux de données sortants du processus de paiement. Un système UEBA monitorant les volumes et destinations des données transitant par les composants du site de paiement aurait identifié l'exfiltration de données cartes vers un domaine externe non autorisé comme une anomalie comportementale significative dès les premières transactions capturées — potentiellement dans les premières heures de l'attaque plutôt que 15 jours après.

Toyota — Japon ASIE · 2019

Le premier incident Toyota T-Connect de 2019, impliquant une mauvaise configuration d'accès à un composant cloud, illustre l'insuffisance d'une gouvernance des accès sans surveillance continue des configurations. Une approche dynamique de la gestion des accès cloud inclut le scanning continu des configurations (CSPM — Cloud Security Posture Management) qui détecte en temps réel les dérives par rapport aux politiques définies : une ressource cloud rendue publique par erreur de configuration serait détectée et alertée dans les minutes suivant la modification, pas découverte des mois ou années après lors d'un audit ponctuel.

WhatsApp