Défense résiliente d’Okta : focus sur les capacités ITDR optimisées par l’IA

Pendant le temps qu’il vous a fallu pour lire cette phrase, des milliers de tentatives de connexion malveillantes ont déjà été effectuées à travers le monde. L’ampleur et la complexité des attaques d’identité sont stupéfiantes, les menaces évoluant quotidiennement. En 2025, Okta a bloqué à lui seul plus de 15 milliards de tentatives de connexion malveillantes dans plus de 10 000 entreprises. Comment une entreprise peut-elle suivre le rythme ? La réponse ne réside pas dans la construction d’un mur unique et solide, mais dans la conception d’une défense plus intelligente et réactive. C’est le principe fondamental derrière les capacités ITDR (Identity Threat Detection and Response) optimisées par l’IA. Dans cet article, nous allons analyser de manière approfondie l’architecture de la plateforme de sécurité d’Okta, en fournissant un schéma de la façon dont la prévention en ligne et l’analytique hors ligne fonctionnent ensemble pour créer une défense véritablement résiliente.

Dans un article précédent, nous avons présenté le concept de défenses multicouches. Dans cet article, nous allons explorer l’architecture complète. Nous aborderons les trois sujets suivants :

1. L’architecture de nos défenses en ligne. Les défenses en ligne sont comme des gardes à la porte, protégeant les utilisateurs en temps réel lorsqu’ils interagissent directement avec Okta.
2. L’architecture de nos défenses hors ligne. Les défenses hors ligne sont comme des systèmes de surveillance qui protègent en permanence les identités en analysant les signaux de sécurité d’Okta et de tiers.
3. Principales recommandations pour sécuriser les tenants Okta.

Pourquoi avons-nous besoin de défenses en ligne et hors ligne ?

Nous détectons et neutralisons les attaques à la fois en ligne, dans le flux des requêtes web vers Okta (tentatives de connexion, inscriptions d’utilisateurs, etc.), et hors ligne, en réaction à des événements de sécurité (p. ex., un fournisseur de sécurité détecte un malware sur le terminal d’un utilisateur).

Une combinaison de défenses en ligne et hors ligne est nécessaire pour les raisons suivantes.

1. Une fois que l’utilisateur se sert d’Okta pour se connecter via l’authentification unique (SSO) à une application tierce, il interagit avec cette application tierce tant que le token reste valide. Okta n’est pas impliqué dans le traitement de ces requêtes web et s’appuie sur des signaux hors ligne provenant du terminal, de l’application tierce et de partenaires (p. ex., les fournisseurs ZTNA, SASE et EDR) pour détecter les attaques.
2. Les détections en ligne doivent s’exécuter très rapidement (en quelques millisecondes) afin de ne pas nuire à l’expérience des utilisateurs légitimes. Nous ne pouvons pas détecter certaines attaques sophistiquées avec une grande précision au moyen des détections en ligne.

Le schéma ci-dessous présente une vue d’ensemble des défenses en ligne et hors ligne. Comme vous pouvez le constater, les événements asynchrones générés par les défenses en ligne, ainsi que les signaux tiers, deviennent une entrée pour les défenses hors ligne. Les types d’actions que nous pouvons effectuer en ligne (blocage, MFA, etc.) sont différents et complémentaires des actions que nous pouvons effectuer hors ligne (p. ex., Universal Logout ou l’exécution de workflows).

Défenses en ligne

Okta traite plus de 100 millions de connexions et 100 000 nouvelles inscriptions d’utilisateurs chaque jour. Nous mettons en œuvre des défenses multicouches décrites ci-dessous sur la trajectoire de ces requêtes. Au cours des 18 derniers mois, nous avons introduit les couches suivantes (en gras italique dans les encadrés bleus), en plus des couches existantes décrites dans l’article précédent.

Penchons-nous maintenant sur les récentes innovations en matière de défenses en ligne.

Zones dynamiques améliorées

Les attaquants utilisent souvent des proxys d’anonymisation, des proxys résidentiels et certains types de VPN pour masquer leur emplacement et lancer des attaques telles que le credential stuffing et le détournement de session. Pour détecter de telles attaques, nous avons introduit la prise en charge des zones dynamiques améliorées. Les clients peuvent désormais créer des zones réseau basées sur une combinaison de catégories de services IP (types spécifiques de proxys d’anonymisation, de proxys résidentiels et de VPN), d’emplacements géographiques et de numéros de système autonome (ASN, Autonomous System Numbers). Ces zones peuvent être utilisées comme listes de blocage ou configurées comme conditions dans les politiques de connexion, de MFA et autres. 

Vous pouvez utiliser les zones pour prendre en charge divers cas d’usage. Par exemple :

1. Bloquez toutes les requêtes vers le tenant provenant de tout proxy d’anonymisation, à l’exception des proxys autorisés par vos politiques de sécurité.
2. Exigez le MFA pour les connexions provenant de certains types de VPN, tout en autorisant tout autre trafic.
3. Refusez l’inscription MFA à partir d’une combinaison d’ASN, de pays et de types de proxy.

L’impact de cette fonctionnalité a été significatif : nous évaluons désormais les métadonnées IP pour chaque requête qui transite par Okta. En 2025, plus de 1 000 clients d’Okta ont utilisé cette fonctionnalité pour bloquer plus d’un milliard de requêtes malveillantes.

Le schéma ci-dessous illustre l’architecture générale pour l’ingestion de flux de métadonnées IP tiers et leur mise à disposition pour des recherches très rapides. Ces flux fournissent des données de géolocalisation et d’autres métadonnées IP, comme les catégories de services IP.

Cette architecture permet d’atteindre deux objectifs principaux :

1. Qualité améliorée : afin de réduire le risque de faux positifs et de faux négatifs, nous avons créé un pipeline hors ligne pour actualiser les métadonnées IP dès que les fournisseurs tiers mettent les données à disposition.
2. Latence réduite : pour réduire les temps de réponse aux requêtes, nous avons conçu la couche applicative afin de rechercher les métadonnées IP auprès de plusieurs fournisseurs en quelques millisecondes.

Bot Protection

Les bots malveillants participent à de nombreuses attaques à grande échelle basées sur les identifiants, telles que la création de comptes frauduleux et les attaques par password spray. Pour lutter contre ce phénomène, nous avons récemment annoncé la version bêta de Bot Protection, qui complète ThreatInsight pour bloquer les attaques basées sur les identifiants des manières suivantes.

1. Détection : ThreatInsight a été conçu pour détecter les adresses IP impliquées dans des attaques de connexion. Bot Protection détecte les bots en se basant sur des signaux autres que l’adresse IP impliquée, non seulement lors de la connexion, mais aussi lors des attaques d’inscription et de récupération. 
2. Correction : ThreatInsight prend en charge le blocage ou la journalisation comme options de correction. Le blocage est une action de correction forte. Avec un blocage, le coût des faux positifs est élevé. La protection contre les bots permet aux clients de configurer un défi de preuve de travail plus souple comme action de correction. Cela met en place des obstacles pour les bots tout en veillant à ce que les utilisateurs légitimes rencontrent un minimum de friction.
3. Configuration : la protection contre les bots permet aux clients de configurer la correction en fonction de leur tolérance au risque. Cela permet aux clients d’ajuster la fonctionnalité afin d’optimiser le compromis entre les faux positifs et les faux négatifs.

Nous tirons parti des très nombreuses données relatives aux attaques qu’Okta a collectées au fil des années pour élaborer des analyses heuristiques et des modèles de machine learning afin d’identifier les bots.

Identity Threat Protection : évaluation du contexte de session

Une fois qu’un utilisateur est authentifié, le risque ne disparaît pas. Identity Threat Protection inclut désormais l’évaluation en ligne des changements de contexte de session afin de détecter les menaces post-authentification. Cette fonctionnalité évalue en continu les sessions afin de détecter toute indication d’une session piratée. Chaque fois que l’adresse IP ou le contexte du terminal change, nous évaluons le niveau de risque de la session en exécutant un modèle de machine learning. Le modèle identifie à quel point la requête est anormale par rapport à la base de référence pour cet utilisateur. 

Les clients peuvent configurer des politiques afin de réévaluer toutes les politiques d’authentification globales et applicatives si la session est risquée. Ce sont les mêmes politiques qui sont évaluées avant qu’une session ne soit accordée au départ. L’évaluation des politiques, non seulement dans le contexte d’une connexion, mais aussi de manière continue en réaction à tout changement dans le contexte de la session, permet à Okta de fournir une véritable authentification continue. 

Lisez cet article pour comprendre les détails de l’authentification continue.

Défenses hors ligne

Nos défenses hors ligne, basées sur les événements, analysent en continu les signaux de sécurité provenant d’un large éventail de sources afin d’identifier et de répondre de façon proactive aux menaces.

Identity Threat Protection : évaluation continue des risques liés aux utilisateurs

Identity Threat Protection va au-delà de l’analyse en ligne. Nous ingérons et analysons en continu un large éventail d’événements de sécurité internes et tiers. Nous utilisons une combinaison de modèles de machine learning hors ligne et d’analyses heuristiques pour estimer en continu le niveau de risque d’un utilisateur. Le client peut configurer des politiques pour entreprendre des actions automatisées lorsqu’un utilisateur est signalé comme présentant un risque élevé, comme le déclenchement d’une demande Universal Logout pour déconnecter l’utilisateur d’Okta et de toutes les applications auxquelles il est connecté. En 2025, Identity Threat Protection a signalé plus de 70 000 utilisateurs à haut risque. Lisez cet article pour obtenir une vue plus détaillée de l’impact réel d’Identity Threat Protection.

Le schéma ci-dessous décrit l’architecture générale pour l’ingestion de signaux provenant de diverses sources et le traitement asynchrone de ces informations afin de mettre à jour et de corriger les risques liés aux utilisateurs.

Ingestion de signaux tiers

La plupart des clients utilisent Okta en complément d’autres produits de sécurité tiers. De nombreux produits de sécurité fonctionnent de manière cloisonnée, et il est extrêmement difficile pour les clients d’intégrer les signaux provenant de plusieurs produits afin de détecter et de bloquer les attaques d’identité. Notre innovation avec le standard OpenID Shared Signals Framework répond à ce défi. Identity Threat Protection permet aux clients de configurer Okta pour échanger des signaux de sécurité avec leurs produits de sécurité existants (ZTNA, WAF, SASE, EDR, etc.). Un échange de signaux basé sur des standards permet une intégration fluide et sécurisée, tant pour les fournisseurs de sécurité que pour les clients.

Signaux first-party Okta

Identity Threat Protection ingère des signaux provenant de plusieurs sources natives d’Okta. Par exemple :

1. Nous ingérons les flux d’informations sur les menaces produits par l’équipe de Threat Intelligence d’Okta. Ces flux comprennent des indicateurs de compromission liés à une infrastructure malveillante de phishing-as-a-service. Cela permet aux clients de prendre des mesures de correction automatisées, telles que la déconnexion universelle, basées sur les informations exploitables fournies par notre équipe de recherche sur les menaces. 
2. Nous ingérons en continu des signaux de terminal (p. ex., l’état de gestion du terminal, si le terminal est débridé et les signaux du logiciel EDR installé sur le terminal) via Okta Verify afin de créer un contexte de terminal détaillé. Ce contexte de terminal est utilisé pour évaluer en continu les risques liés à l’utilisateur et à la session.
3. Nous ingérons en continu les événements Okta System Log dans un data lake afin d’exécuter des modèles de machine learning hors ligne et des analyses heuristiques pour signaler les utilisateurs à risque et les adresses IP malveillantes.

Breached Credential Protection

Selon certaines estimations, il y aurait plus de 50 milliards d’identifiants compromis sur le Dark Web. Les attaquants utilisent ces données pour mener des attaques d’envergure basées sur les identifiants. Breached Credential Protection (désormais disponible en version GA) s’intègre aux fournisseurs tiers pour vérifier en permanence si les identifiants de vos utilisateurs figurent dans des brèches de données connues. Si une correspondance est trouvée, nous pouvons automatiquement faire expirer le mot de passe compromis et mettre fin à toutes les sessions actives, empêchant ainsi un attaquant d’utiliser les identifiants volés. 

Nous avons créé une architecture hautement évolutive, capable de télécharger ces bases de données volumineuses, de les traiter et de les rendre disponibles pour une consultation à très faible latence, après une authentification réussie par mot de passe.

Le schéma ci-dessous illustre l’architecture générale pour l’ingestion de milliards d’identifiants compromis provenant de plusieurs fournisseurs et la manière dont ces données sont utilisées pour détecter et corriger les brèches.

Dans les trois mois suivant son lancement en version GA, Breached Credential Protection a signalé 1,7 million d’identifiants compromis et réinitialisé 770 000 identifiants.

Comment l’IA établit des liens

Ni la couche en ligne ni la couche hors ligne ne fonctionnent de manière isolée. La véritable puissance de cette architecture réside dans notre moteur de détection basé sur l’IA, qui unifie les données des deux sources. Au cœur de ce moteur de détection se trouvent les données d’utilisation véritablement uniques (adresses IP, utilisation des applications, validations d’identifiants, utilisation des terminaux, etc.) qu’Okta collecte dans le pipeline d’identité à travers des milliards de connexions chaque mois. Ces données d’utilisation riches, ainsi que les données étiquetées provenant d’attaques connues, sont utilisées pour entraîner des modèles de machine learning hors ligne et en ligne afin de bloquer les attaques d’identité sophistiquées. Par exemple :

1. Nous utilisons un modèle de machine learning hors ligne pour identifier les adresses IP malveillantes impliquées dans des attaques à grande échelle basées sur les identifiants. Nous recherchons des modèles liés aux attaques par password spray, aux taux de connexion, aux taux d’échec, aux types d’échecs, etc., afin d’identifier ces adresses IP. L’attaque par password spray est une méthode intéressante basée sur les identifiants, où les attaquants automatisent la vérification d’un mot de passe sur plusieurs comptes utilisateurs. Okta peut identifier ces mots de passe en suivant leur utilisation par différents utilisateurs et entreprises, et bloquer ces tentatives.
2. Nous utilisons un modèle de machine learning hors ligne pour identifier les adresses IP impliquées dans des attaques de phishing en nous basant sur les signaux des tentatives bloquées par FastPass.
3. Nous utilisons un modèle de machine learning en ligne pour signaler les usurpations de compte (ATO) et les attaques par détournement de session. Le modèle de machine learning détermine si la requête s’écarte de la base de référence (adresses IP connues et valides, terminaux, emplacements, etc.) que nous établissons pour les utilisateurs en fonction de leurs connexions réussies.
4. Nous utilisons un modèle de machine learning en ligne pour identifier les requêtes suspectes en fonction de divers attributs au niveau de la requête, afin de pouvoir limiter leur débit séparément des requêtes légitimes adressées à l’entreprise.

Principales recommandations 

1. Activez ThreatInsight, les zones dynamiques améliorées et Bot Protection pour bloquer de manière proactive les attaques automatisées à grande échelle dès l’entrée.
2. Activez Breached Credential Detection pour neutraliser instantanément les menaces liées à des identifiants compromis lors de brèches tierces.
3. Activez Identity Threat Protection pour obtenir une authentification continue et répondre aux menaces post-authentification en temps réel.

Conclusion

Nous vous encourageons à utiliser cet article comme un outil pour examiner votre propre posture de sécurité. Vos défenses fonctionnent-elles de concert ? Exploitez-vous l’IA pour détecter l’indétectable ? Aller au-delà des outils traditionnels et cloisonnés pour adopter un framework ITDR intégré et optimisé par l’IA constitue une étape décisive pour sécuriser vos identités et vos ressources dans le paysage des menaces modernes.