Introducción
La solución Identity Threat Protection (ITP) de Okta proporciona detección de amenazas continua y en tiempo real, así como capacidades de respuesta automatizada que operan más allá del evento de autenticación inicial. Si bien el poder de ITP reside en su capacidad para actuar sobre señales de autenticación posterior, ese poder solo se materializa de forma consistente si las políticas subyacentes, los contextos de red y las integraciones de señales se configuran de manera consistente en todos los entornos.
Ahí es donde entra en juego la infraestructura como código.
Esta publicación explica cómo gestionar toda la superficie de ITP (zonas de red, asignaciones de riesgo de usuario, reglas de política de riesgo de entidad, reglas de protección de sesión e ingesta de señales de terceros) de forma declarativa utilizando el proveedor Okta Terraform.
¿Por qué Terraform para ITP?
El modelo declarativo de Terraform ofrece ventajas operativas concretas para la configuración de seguridad:
- Política de control de versiones: Cada cambio en una zona de red o regla de respuesta a riesgos se registra en el control de versiones, lo que le proporciona un registro de auditoría completo y la posibilidad de revertir los cambios.
- Implementaciones repetibles: aplique la misma configuración de ITP en los entornos de desarrollo, preproducción y producción sin necesidad de reintroducirla manualmente ni de generar inconsistencias derivadas del portapapeles.
- Eliminación de desviaciones: el ciclo de planificación/aplicación de Terraform detecta y corrige los cambios fuera de banda, lo que ayuda a garantizar que la configuración en vivo coincida con la intención declarada.
- Integración de CI/CD: Los cambios en la política de seguridad pasan por el mismo proceso de revisión de solicitudes de extracción, pruebas automatizadas y pipeline de implementación que el código de la aplicación.
Con el proveedor de Okta Terraform específicamente, puede:
- Gestione las configuraciones de ITP junto con el resto de su infraestructura de IAM en un único código base
- Implementar controles de respuesta ante amenazas coherentes en todos los entornos
- Revisar por par los cambios en la política de riesgos mediante solicitudes de extracción antes de que lleguen a producción
- Reconfigure rápidamente las respuestas automatizadas cuando cambie su modelo de amenazas
- Mantener la gestión del ciclo de vida completo de las zonas de red, las señales de riesgo, los receptores de Shared Signals Framework (SSF) y las reglas de directivas
Las siguientes secciones describen cada uno de los seis recursos principales relacionados con ITP en el proveedor Okta Terraform.
Zonas de red —
zona_de_red_okta
Las zonas de red definen las regiones geográficas, los rangos de IP o los números de sistema autónomo que Okta utiliza para clasificar el contexto de red de un intento de autenticación o una sesión activa. En un contexto de ITP, las zonas cumplen dos funciones: identifican contextos de red de confianza (como un rango de VPN corporativa) que pueden eximir a los usuarios de ciertas comprobaciones de riesgo, y definen listas de bloqueo (como los anonimizadores de Tor) que elevan el riesgo de inmediato, independientemente de otras señales.
La gestión de zonas en Terraform le proporciona un inventario versionado y auditable de cada rango de red, tanto de confianza como bloqueado, en su entorno. El argumento type controla la clasificación de la zona: IP para rangos CIDR explícitos o rangos IP, DYNAMIC para clasificaciones de tipo proxy como Tor y DYNAMIC_V2 para zonas dinámicas basadas en ASN. El argumento usage determina si la zona se utiliza para la evaluación de políticas (POLICY) o actúa como una lista de bloqueo (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 zona corporate_vpn se menciona más adelante en la regla de violación de sesión, lo que demuestra cómo fluye el contexto de red a través de la pila de políticas ITP.
Gestión de riesgos del usuario —
riesgo_de_usuario_okta
El recurso okta_user_risk permite asignar de manera programática una clasificación de riesgo a un usuario específico de Okta. Los valores admitidos para risk_level son HIGH, MEDIUM y LOW. Este recurso resulta muy valioso como parte de un flujo de trabajo de saneamiento automatizado: una plataforma SIEM o SOAR detecta un indicador de compromiso, activa una ejecución de Terraform (o llama directamente a la API de Okta), establece el riesgo del usuario afectado en HIGH y las reglas de la política de riesgo de entidades definidas a continuación toman el control —finalizando las sesiones activas o invocando un flujo de trabajo de saneamiento.
Esto cierra el círculo entre las herramientas de detección externas y el motor de evaluación continua de Okta sin necesidad de intervención manual.
resource "okta_user_risk" "compromised_user" {
user_id = okta_user.example.id
risk_level = "HIGH"
}
En la práctica, el user_id normalmente se obtendrá de una búsqueda de datos o se pasará como una variable durante la ejecución de un pipeline automatizado, en lugar de estar codificado de forma fija.
Reglas de la política de riesgo de la entidad —
okta_entity_risk_policy_rule
Las reglas de la política de riesgo de la entidad definen las respuestas automatizadas que Okta ejecuta cuando ITP asigna una puntuación de riesgo a un usuario que cumple o supera un umbral configurado. La política de riesgo de entidad se aprovisionamiento automáticamente cuando se habilita ITP en su inquilino de Okta; no es necesario crear la política a través de Terraform. En su lugar, se recupera su ID utilizando la fuente de datos okta_entity_risk_policy y se crean reglas dentro de ella.
Las reglas pueden dirigirse a niveles de riesgo específicos (HIGH, MEDIUM o LOW) y admiten dos acciones de respuesta: terminate_all_sessions invalida inmediatamente todas las sesiones activas del usuario, y workflow_id invoca un flujo de trabajo de Okta para pasos de saneamiento más complejos, como enviar notificaciones, deshabilitar cuentas o activar integraciones externas.
Nota: La regla predeterminada (prioridad 99) está preconfigurada y no se puede modificar ni eliminar. Las reglas gestionadas por Terraform deben usar prioridades inferiores a 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
nombre = "Riesgo alto - Finalizar todas las sesiones"
nivel_riesgo = "ALTO"
finalizar_todas_las_sesiones = verdadero
prioridad = 1
}
recurso "okta_entity_risk_policy_rule" "respuesta_riesgo_medio" {
id_política = data.okta_entity_risk_policy.main.id
nombre = "Riesgo medio - Workflow de saneamiento activada"
nivel_riesgo = "MEDIO"
id_flujo_de_trabajo = "abc123"
prioridad = 2
Los argumentos adicionales, como users_excluded y groups_included, permiten limitar el alcance de las reglas a poblaciones de usuarios específicas, lo cual resulta útil al implementar la aplicación de ITP de forma gradual.
Reglas de política de sesión posterior a la autenticación —
okta_post_auth_session_policy_rule
La regla de política de sesión posterior a la autenticación rige lo que hace Okta cuando falla una comprobación de evaluación continua en una sesión activa después de la autenticación inicial; por ejemplo, cuando cambia el estado de cumplimiento del dispositivo de un usuario, su contexto de red cambia a una zona bloqueada o su puntuación de riesgo aumenta en respuesta a una señal SSF entrante.
Importante: A diferencia de la mayoría de los recursos de Terraform, okta_post_auth_session_policy_rule viene preconfigurado por Okta y no se puede crear ni destruir a través de Terraform. Debe importar la regla existente antes de gestionarla:
terraform import okta_post_auth_session_policy_rule.session_protection <policy_id>/<rule_id>
Obtenga los ID de las políticas y las reglas desde la consola de administración de Okta o a través de la fuente de datos okta_post_auth_session_policy y la API de Okta.
A pesar de la restricción de solo importación, la gestión de Terraform sigue aportando un valor significativo aquí: la configuración está controlada por versiones, los cambios pasan por una revisión por pares y el comportamiento de terminación está codificado junto con todas las demás políticas de ITP en un único repositorio.
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 = "Protección de sesión posterior a la autenticación"
status = "ACTIVE"
terminate_session = true
}
Los argumentos groups_included y groups_excluded permiten una aplicación delimitada, y workflow_id admite la misma integración con Okta Workflows que las reglas de riesgo de entidad.
Reglas de la política de detección de infracciones de sesión —
okta_session_violation_policy_rule
Las reglas de la política de detección de infracciones de sesión definen las condiciones bajo las cuales Okta clasifica una sesión activa como una infracción de la política. Mientras que la regla de política de sesión posterior a la autenticación define la respuesta a una infracción, este recurso define la lógica de detección: qué nivel de riesgo mínimo y contexto de red deben estar presentes antes de que se marque una sesión.
El argumento min_risk_level establece el umbral de detección (LOW, MEDIUM o HIGH). El argumento network_connection define el alcance de la aplicación de las políticas: al configurarlo en ZONE y proporcionar identificadores de zona mediante network_includes o network_excludes se obtiene un control preciso.
Por ejemplo, excluir de la detección de infracciones las sesiones que se originan en su VPN corporativa.
Importante: Al igual que la regla de política de sesión posterior a la autenticación, okta_session_violation_policy_rule viene preaprovisionada por Okta y debe importarse antes de que Terraform pueda gestionarla:
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]
habilitada_evaluación_de_políticas = verdadero
Tenga en cuenta que okta_network_zone.corporate_vpn.id hace referencia a la zona de red definida en la primera sección. El gráfico de recursos de Terraform ayuda a garantizar que la zona exista antes de que la regla de violación de sesión haga referencia a ella.
Configuración del receptor SSF —
Proveedor de eventos de seguridad de Okta
El recurso okta_security_events_provider configura Okta como un receptor de Shared Signals marco (SSF), lo que le permite ingerir señales de evento de seguridad de proveedores externos como CrowdStrike, Zscaler u otros inquilino de Okta. Estas señales entrantes alimentan directamente el Risk Engine de ITP.
Un evento de detección de endpoints por parte de un proveedor de seguridad externo puede elevar la puntuación de riesgo de un usuario en tiempo real, lo que a su vez activa las reglas de la política de riesgo de entidad definidas anteriormente.
La gestión de los receptores SSF en Terraform ayuda a garantizar que toda la cadena de señal a respuesta, desde la inbound Threat Intelligence hasta la finalización automatizada de sesión, esté configurada de forma coherente y sea auditable en todos los entornos.
El argumento type identifica el tipo de proveedor SSF. Para los proveedores que publican un documento de detección SSF, configure settings.well_known_url con el extremo /.well-known/ssf-configuration del proveedor. Para los proveedores que no tengan un documento de detección, configure settings.issuer y settings.jwks_url directamente. El argumento is_enabled acepta ACTIVE o 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"
}
}
Una vez que el receptor está activo, las señales del proveedor configurado fluyen hacia el Risk Engine de Okta y se evalúan en función de las reglas de riesgo de la entidad y de violación de sesión definidas en las secciones anteriores.
Conclusión
Gestionar ITP mediante Terraform transforma su postura de seguridad, pasando de una configuración mantenida manualmente a un sistema con control de versiones, revisado por pares y de despliegue continuo. Los seis recursos que se tratan en esta publicación abarcan en conjunto toda la superficie de gestión de ITP:
RECURSOS | Rol |
zona_de_red_okta | Defina los contextos de red confiables y bloqueados para la evaluación de riesgos |
riesgo_de_usuario_okta | Asignar de manera programática niveles de riesgo a los usuarios en Workflows automatizados |
okta_entity_risk_policy_rule | Automatice las respuestas a amenazas (finalización de sesión, invocación de Workflows) en función de las puntuaciones de riesgo de ITP. |
okta_post_auth_session_policy_rule | Controle el comportamiento de Okta cuando la evaluación continua falla en una sesión activa |
okta_session_violation_policy_rule | Defina las condiciones (nivel de riesgo, contexto de red) que marcan una sesión como una infracción de la política. |
Proveedor de eventos de seguridad de Okta | Ingiera señales de amenazas de terceros a través de SSF para enriquecer el Risk Engine en tiempo real de ITP |
En conjunto, estos recursos cierran el ciclo entre la detección y la respuesta completamente mediante código. Una señal de terceros llega a través de SSF, eleva la puntuación de riesgo de un usuario, activa una regla de política de riesgo de entidad para finalizar las sesiones, y la regla de violación de sesión ayuda a garantizar que cualquier sesión superviviente sea detectada mediante una evaluación continua; todo ello declarado en HCL, revisado en una solicitud de extracción y aplicado de forma coherente en todos los entornos.
Para obtener una referencia completa de los argumentos y la configuración del proveedor, consulte la documentación del proveedor de Okta Terraform.
