Introduction
La solution Identity Threat Protection (ITP) d’Okta offre des fonctionnalités continues de détection des menaces en temps réel et de réponse automatisée, qui interviennent au-delà de l’événement d’authentification initial. La puissance d’ITP réside dans sa capacité à agir sur les signaux post-authentification, mais cette puissance ne se concrétise de façon fiable que si les politiques sous-jacentes, les contextes réseau et les intégrations de signaux sont configurés de manière cohérente sur différents environnements.
C’est là qu’intervient l’Infrastructure as Code.
Cet article explique comment gérer l’ensemble de la surface ITP — zones réseau, attributions de niveau de risque des utilisateurs et utilisatrices, règles de politique de risque des entités, règles de protection des sessions et ingestion de signaux tiers — de façon déclarative à l’aide de l’ Okta Terraform Provider.
Pourquoi choisir Terraform pour ITP ?
Le modèle déclaratif de Terraform présente des avantages opérationnels concrets pour la configuration de la sécurité :
- Politique avec gestion des versions : chaque modification apportée à une zone réseau ou à une règle de réponse aux risques est enregistrée dans le système de gestion de code source, ce qui vous offre une piste d’audit complète et la possibilité de revenir en arrière.
- Déploiements reproductibles : appliquez la même configuration ITP sur les environnements de développement, de préproduction et de production, sans ressaisie manuelle ni risque d’incohérence lié au copier-coller.
- Élimination de la dérive : le cycle plan/apply de Terraform détecte et corrige les modifications hors bande, contribuant à faire en sorte que votre configuration en production corresponde à votre intention déclarée.
- Intégration CI/CD : les modifications de la politique de sécurité suivent le même workflow de revue de pull request, de tests automatisés et de pipeline de déploiement que le code applicatif.
Avec le fournisseur Terraform d’Okta, vous pouvez notamment :
- Gérer les configurations ITP avec le reste de votre infrastructure IAM dans une seule base de code
- Appliquer des contrôles cohérents de réponse aux menaces sur l’ensemble des environnements
- Soumettre les modifications des politiques de gestion des risques à une relecture par les pairs via des pull requests avant leur mise en production
- Reconfigurer rapidement les réponses automatisées lorsque votre modèle de menace évolue
- Assurer la gestion complète du cycle de vie des zones réseau, des signaux de risque, des récepteurs Shared Signals Framework (SSF) et des règles de politique
Les sections suivantes présentent chacune des six principales ressources liées à l’ITP dans le fournisseur Terraform d’Okta.
Zones réseau —
okta_network_zone
Les zones réseau définissent les régions géographiques, les plages d’adresses IP ou les numéros de systèmes autonomes qu’Okta utilise pour classer le contexte réseau d’une tentative d’authentification ou d’une session active. Dans un contexte ITP, les zones remplissent deux fonctions : elles identifient des contextes réseau de confiance (comme une plage d’adresses VPN d’entreprise) permettant d’exempter les utilisateurs de certains contrôles de risque, et elles définissent des listes de blocage (comme les anonymiseurs Tor) qui élèvent immédiatement le niveau de risque, quels que soient les autres signaux.
La gestion des zones dans Terraform vous offre un inventaire versionné et traçable de chaque plage réseau approuvée ou bloquée dans votre environnement. L’argument type détermine la classification de la zone : IP pour les plages CIDR explicites ou les plages d’adresses IP, DYNAMIC pour les classifications de type proxy telles que Tor, et DYNAMIC_V2 pour les zones dynamiques basées sur l’ASN. L’argument usage détermine si la zone alimente l’évaluation de la politique (POLICY) ou si elle agit comme une liste de blocage (BLOCKLIST).
resource "okta_network_zone" "corporate_vpn" {
name = "Corporate VPN"
type = "IP"
usage = "POLICY"
gateways = ["203.0.113.0/24", "198.51.100.10-198.51.100.20"]
}
resource "okta_network_zone" "tor_blocklist" {
name = "TOR Blocklist"
type = "DYNAMIC"
usage = "BLOCKLIST"
dynamic_proxy_type = "TorAnonymizer"
}
La zone corporate_vpn est mentionnée plus loin dans la règle de violation de session, illustrant la façon dont le contexte réseau se propage dans la pile de politiques ITP.
Gestion des risques utilisateurs —
okta_user_risk
La ressource okta_user_risk vous permet d’attribuer par programmation une classification de risque à un utilisateur Okta spécifique. Les valeurs prises en charge pour risk_level sont HIGH, MEDIUM et LOW. Cette ressource prend toute sa valeur intégrée à un workflow de remédiation automatisé : une plateforme SIEM ou SOAR détecte un indicateur de compromission, déclenche une exécution Terraform (ou appelle directement l’API Okta), définit le niveau de risque de l’utilisateur concerné sur HIGH, puis les règles de la politique de risque d’entité définies ci-dessous prennent le relais, mettant fin aux sessions actives ou lançant un workflow de remédiation.
Cela boucle la boucle entre les outils de détection externes et le moteur d’évaluation continue d’Okta, sans nécessiter d’intervention manuelle.
resource "okta_user_risk" "compromised_user" {
user_id = okta_user.example.id
risk_level = "HIGH"
}
En pratique, le user_id proviendra généralement d’une extraction de données ou sera transmis comme variable lors de l’exécution automatisée d’un pipeline, plutôt que d’être codé en dur.
Règles de politique de risque d’entité —
okta_entity_risk_policy_rule
Les règles de politique de risque d’entité définissent les réponses automatisées qu’Okta applique lorsque ITP attribue un score de risque à un utilisateur atteignant ou dépassant un seuil configuré. La politique de risque d’entité est automatiquement provisionnée lorsque ITP est activé sur votre tenant Okta ; vous ne créez pas la politique via Terraform. À la place, vous extrayez son identifiant à l’aide de la source de données okta_entity_risk_policy et créez des règles en son sein.
Les règles peuvent cibler des niveaux de risque spécifiques (HIGH, MEDIUM ou LOW) et prendre en charge deux actions de réponse : terminate_all_sessions invalide immédiatement toutes les sessions actives de l’utilisateur, et workflow_id déclenche un Workflow Okta pour des mesures correctives plus complexes, telles que l’envoi de notifications, la désactivation de comptes ou le déclenchement d’intégrations externes.
Remarque : la règle par défaut (priorité 99) est préconfigurée et ne peut pas être modifiée ni supprimée. Les règles gérées par Terraform doivent utiliser des priorités inférieures à 99.
data "okta_entity_risk_policy" "main" {}
resource "okta_entity_risk_policy_rule" "high_risk_response" {
policy_id = data.okta_entity_risk_policy.main.id
name = "High Risk - Terminate All Sessions"
risk_level = "HIGH"
terminate_all_sessions = true
priority = 1
}
resource "okta_entity_risk_policy_rule" "medium_risk_response" {
policy_id = data.okta_entity_risk_policy.main.id
name = "Medium Risk - Trigger Remediation Workflow"
risk_level = "MEDIUM"
workflow_id = "abc123"
priority = 2
}
Des arguments supplémentaires tels que users_excluded et groups_included vous permettent de limiter le champ d’application des règles à certaines populations d’utilisateurs, ce qui s’avère utile lors du déploiement progressif de l’application d’ITP.
Règles de politique de session post-auth —
okta_post_auth_session_policy_rule
La règle de politique de session Post Auth détermine la réaction d’Okta lorsqu’un contrôle d’évaluation continue échoue sur une session active après l’authentification initiale — par exemple lorsque l’état de conformité de l’appareil d’un utilisateur change, que son contexte réseau bascule vers une zone bloquée ou que son score de risque augmente en réponse à un signal SSF entrant.
Important : Contrairement à la plupart des ressources Terraform, okta_post_auth_session_policy_rule est préconfiguré par Okta et ne peut pas être créé ni supprimé via Terraform. Vous devez importer la règle existante avant de la gérer :
terraform import okta_post_auth_session_policy_rule.session_protection <policy_id>/<rule_id>
Extrayez les identifiants de la politique et des règles depuis la console d’administration Okta ou via la source de données okta_post_auth_session_policy et l’API Okta.
Malgré la contrainte d’importation uniquement, la gestion via Terraform apporte ici une réelle valeur ajoutée : la configuration est gérée par le contrôle de version, les modifications sont soumises à une revue par les pairs, et le comportement de résiliation est codifié avec l’ensemble des autres politiques ITP dans un référentiel unique.
data "okta_post_auth_session_policy" "main" {}
resource "okta_post_auth_session_policy_rule" "session_protection" {
policy_id = data.okta_post_auth_session_policy.main.id
name = "Post-Auth Session Protection"
status = "ACTIVE"
terminate_session = true
}
Les arguments groups_included et groups_excluded permettent une application ciblée, et workflow_id prend en charge la même intégration Okta Workflows que les règles de risque liées aux entités.
Règles de la politique de détection des violations de session —
okta_session_violation_policy_rule
Les règles de la Politique de détection des violations de session définissent les conditions dans lesquelles Okta considère qu’une session active constitue une violation de la politique. Alors que la règle de politique de session post-authentification définit la réponse à une violation, cette ressource définit la logique de détection : le niveau de risque minimal et le contexte réseau qui doivent être réunis avant qu’une session ne soit signalée.
L’argument min_risk_level définit le seuil de détection (LOW, MEDIUM ou HIGH). L’argument network_connection définit le périmètre d’application : en le définissant sur ZONE et en fournissant des identifiants de zone via network_includes ou network_excludes, vous bénéficiez d’un contrôle granulaire.
Par exemple, exclure les sessions provenant de votre VPN d’entreprise de la détection des violations.
Important : Comme la règle de politique de session Post Auth, okta_session_violation_policy_rule est préconfigurée par Okta et doit être importée avant que Terraform puisse la gérer :
terraform import okta_session_violation_policy_rule.high_risk_sessions <policy_id>/<rule_id>
data "okta_session_violation_policy" "main" {}
resource "okta_session_violation_policy_rule" "high_risk_sessions" {
policy_id = data.okta_session_violation_policy.main.id
name = "High Risk Session Violation"
min_risk_level = "HIGH"
network_connection = "ZONE"
network_excludes = [okta_network_zone.corporate_vpn.id]
policy_evaluation_enabled = true
}
Veuillez noter que okta_network_zone.corporate_vpn.id fait référence à la zone réseau définie dans la première section. Le graphe des ressources Terraform permet de vérifier que la zone existe avant que la règle de violation de session ne s’y réfère.
Configuration du récepteur SSF —
okta_security_events_provider
La ressource okta_security_events_provider configure Okta en tant que récepteur Shared Signals Framework (SSF), ce qui lui permet d’ingérer des signaux d’événements de sécurité provenant de fournisseurs tiers tels que CrowdStrike, Zscaler ou d’autres tenants Okta. Ces signaux entrants alimentent directement le moteur d’évaluation des risques d’ITP.
Un événement de détection sur un terminal provenant d’un fournisseur de sécurité tiers peut augmenter le score de risque d’un utilisateur en temps réel, ce qui déclenche ensuite les règles de la Politique de risque d’entité définies ci-dessus.
La gestion des récepteurs SSF dans Terraform contribue à garantir que l’ensemble de la chaîne signal-réponse, de la Threat Intelligence entrante à la clôture de session automatisée, soit configuré de manière cohérente et vérifiable sur tous les environnements.
L’argument type identifie le type de fournisseur SSF. Pour les fournisseurs qui publient un document de découverte SSF, définissez settings.well_known_url sur le point de terminaison /.well-known/ssf-configuration du fournisseur. Pour les fournisseurs sans document de découverte, définissez settings.issuer et settings.jwks_url directement. L’argument is_enabled accepte ACTIVE ou INACTIVE.
resource "okta_security_events_provider" "crowdstrike" {
name = "CrowdStrike Threat Intelligence"
type = "okta"
is_enabled = "ACTIVE"
settings {
well_known_url = "https://crowdstrike.example.com/.well-known/ssf-configuration"
}
}
Une fois le récepteur activé, les signaux provenant du fournisseur configuré sont transmis au moteur de gestion des risques d’Okta et évalués selon les règles de risque d’entité et de violation de session définies dans les sections précédentes.
Conclusion
La gestion d’ITP avec Terraform transforme votre posture de sécurité : vous passez d’une configuration maintenue manuellement à un système contrôlé par version, validé par les pairs et déployable en continu. Les six ressources présentées dans cet article couvrent ensemble l’ensemble du périmètre de gestion ITP :
Ressource | Rôle |
okta_network_zone | Définir des contextes réseau de confiance et bloqués pour l’évaluation des risques |
okta_user_risk | Attribuer par programmation des niveaux de risque aux utilisateurs dans des workflows automatisés |
okta_entity_risk_policy_rule | Automatiser les réponses aux menaces : clôture de session, lancement de workflows, en fonction des scores de risque ITP |
okta_post_auth_session_policy_rule | Contrôler le comportement d’Okta en cas d’échec de l’évaluation continue lors d’une session active |
okta_session_violation_policy_rule | Définir les conditions — niveau de risque, contexte réseau — qui signalent qu’une session constitue une violation de la politique |
okta_security_events_provider | Ingestion de signaux de menace provenant de tiers via SSF pour enrichir le moteur d’évaluation des risques en temps réel d’ITP |
Ensemble, ces ressources bouclent la boucle entre la détection et la réponse, entièrement dans le code. Un signal tiers arrive via SSF, augmente le score de risque d’un utilisateur, déclenche une règle de politique de risque d’entité pour mettre fin aux sessions, et la règle de violation de session permet de s’assurer que toute session restante soit détectée par l’évaluation continue — l’ensemble étant déclaré en HCL, examiné dans une pull request et appliqué de manière cohérente sur tous les environnements.
Pour obtenir la liste complète des arguments et la configuration du fournisseur, consultez la documentation du fournisseur Okta Terraform.
