Introdução
O Identity Threat Protection (ITP) da Okta oferece detecção contínua de ameaças em tempo real e recursos de resposta automatizada que operam além do evento de autenticação inicial. Embora o poder do ITP resida na sua capacidade de agir sobre sinais pós-autenticação, esse poder só é concretizado de forma consistente se as políticas subjacentes, os contextos de rede e as integrações de sinais forem configurados de forma consistente em todos os ambientes.
É aí que entra a Infraestrutura como Código.
Este artigo aborda como gerenciar toda a superfície do ITP — zonas de rede, atribuições de risco do usuário, regras de política de risco da entidade, regras de proteção de sessão e ingestão de sinais de terceiros — de forma declarativa usando o provedor Terraform da Okta.
Por que usar Terraform para ITP?
O modelo declarativo do Terraform oferece vantagens operacionais concretas para a configuração de segurança:
- Política com controle de versão: cada alteração em uma zona de rede ou regra de resposta a riscos é registrada no controle de versão, fornecendo uma trilha de auditoria completa e a capacidade de reverter as alterações.
- Implantações repetíveis: aplique a mesma configuração do ITP em ambientes de desenvolvimento, teste e produção sem necessidade de reinserção manual ou inconsistências causadas pela área de transferência.
- Eliminação de desvios: o ciclo de planejamento/aplicação do Terraform detecta e corrige alterações fora do canal, ajudando a garantir que sua configuração em produção corresponda à intenção declarada.
- Integração CI/CD: as alterações na política de segurança passam pelo mesmo processo de revisão de pull requests, testes automatizados e pipeline de implantação que o código do aplicativo.
Especificamente com o provedor Terraform da Okta, você pode:
- Gerencie as configurações do ITP juntamente com o restante da sua infraestrutura IAM em uma única base de código
- Implementar controles consistentes de resposta a ameaças em todos os ambientes
- Revisar por pares as alterações na política de risco por meio de pull requests antes que elas cheguem à produção
- Reconfigure rapidamente as respostas automatizadas quando o seu modelo de ameaças mudar
- Gerenciar todo o ciclo de vida das zonas de rede, sinais de risco, receptores do Shared Signals Framework (SSF) e regras de política
As seções a seguir descrevem cada um dos seis principais recursos relacionados ao ITP no provedor Terraform da Okta.
Zonas de rede —
okta_network_zone
As Zonas de Rede definem as regiões geográficas, intervalos de IP ou números de sistemas autônomos que a Okta usa para classificar o contexto de rede de uma tentativa de autenticação ou sessão ativa. Em um contexto de ITP, as zonas desempenham duas funções: identificam contextos de rede confiáveis (como um intervalo de VPN corporativa) que podem isentar os usuários de determinadas verificações de risco e definem listas de bloqueio (como anonimizadores do Tor) que elevam imediatamente o risco, independentemente de outros sinais.
O gerenciamento de zonas no Terraform fornece um inventário versionado e auditável de todos os intervalos de rede confiáveis e bloqueados em seu ambiente. O argumento type controla a classificação da zona — IP para intervalos CIDR explícitos ou intervalos IP, DYNAMIC para classificações do tipo proxy, como Tor, e DYNAMIC_V2 para zonas dinâmicas baseadas em ASN. O argumento de uso determina se a zona alimenta a avaliação de políticas (POLICY) ou atua como uma lista de bloqueio (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"
}
A zona corporate_vpn é mencionada posteriormente na regra de violação de sessão, demonstrando como o contexto de rede flui através da pilha de políticas do ITP.
Gerenciamento de riscos do usuário —
okta_user_risk
O recurso okta_user_risk permite atribuir programaticamente uma classificação de risco a um usuário específico do Okta. Os valores suportados para risk_level são HIGH, MEDIUM e LOW. Este recurso é mais valioso como parte de um fluxo de trabalho de remediação automatizado: uma plataforma SIEM ou SOAR detecta um indicador de comprometimento, aciona uma execução do Terraform (ou chama a API do Okta diretamente), define o risco do usuário afetado como HIGH e as regras da Política de Risco da Entidade definidas abaixo entram em ação — encerrando as sessões ativas ou invocando um fluxo de trabalho de remediação.
Isso fecha o ciclo entre as ferramentas de detecção externas e o mecanismo de avaliação contínua da Okta sem exigir intervenção manual.
resource "okta_user_risk" "compromised_user" {
user_id = okta_user.example.id
risk_level = "HIGH"
}
Na prática, o user_id normalmente será obtido por meio de uma pesquisa de dados ou passado como uma variável durante a execução automatizada de um pipeline, em vez de ser codificado diretamente no código.
Regras da política de risco da entidade —
regra_de_política_de_risco_de_entidade_okta
As Regras de Política de Risco da Entidade definem as respostas automatizadas que a Okta executa quando o ITP atribui uma pontuação de risco a um usuário que atinge ou excede um limite configurado. A própria Política de Risco de Entidade é provisionada automaticamente quando o ITP é ativado em seu tenant Okta — você não cria a política via Terraform. Em vez disso, você recupera o ID usando a fonte de dados okta_entity_risk_policy e cria regras dentro dela.
As regras podem ser direcionadas a níveis de risco específicos (HIGH, MEDIUM ou LOW) e suportam duas ações de resposta: terminate_all_sessions invalida imediatamente todas as sessões ativas do usuário, e workflow_id invoca um Okta Workflows para etapas de remediação mais complexas, como o envio de notificações, a desativação de contas ou o acionamento de integrações externas.
Observação: a regra padrão (prioridade 99) é pré-provisionada e não pode ser modificada ou excluída. As regras gerenciadas pelo Terraform devem 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
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
nome = "Risco Médio - Fluxo de Trabalho de Remediação de Acionamento"
nível_de_risco = "MÉDIO"
id_do_fluxo_de_trabalho = "abc123"
prioridade = 2
Argumentos adicionais como users_excluded e groups_included permitem que você defina o escopo das regras para populações de usuários específicas, o que é útil ao implementar a aplicação do ITP de forma incremental.
Regras de política de sessão pós-autenticação —
okta_post_auth_session_policy_rule
A regra de política de sessão pós-autenticação define o que a Okta faz quando uma verificação de avaliação contínua em uma sessão ativa falha após a autenticação inicial — por exemplo, quando o estado de conformidade do dispositivo de um usuário muda, seu contexto de rede passa para uma zona bloqueada ou sua pontuação de risco aumenta em resposta a um sinal SSF de entrada.
Importante: Ao contrário da maioria dos recursos do Terraform, okta_post_auth_session_policy_rule é pré-provisionado pelo Okta e não pode ser criado ou destruído via Terraform. Você precisa importar a regra existente antes de gerenciá-la:
terraform import okta_post_auth_session_policy_rule.session_protection <policy_id>/<rule_id>
Recupere os IDs de política e regra no Console de Administração da Okta ou por meio da fonte de dados okta_post_auth_session_policy e da API da Okta.
Apesar da restrição de apenas importação, o gerenciamento do Terraform ainda oferece um valor significativo aqui: a configuração é controlada por versão, as alterações passam por revisão por pares e o comportamento de encerramento é codificado juntamente com todas as outras políticas do ITP em um único repositório.
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
nome = "Proteção de Sessão Pós-Autenticação"
status = "ATIVO"
terminar_sessão = true
Os argumentos groups_included e groups_excluded permitem a aplicação de regras com escopo definido, e workflow_id oferece suporte à mesma integração com o Okta Workflows que as regras de risco da entidade.
Regras da política de detecção de violação de sessão —
regra_de_política_de_violação_de_sessão_okta
As regras da política de detecção de violação de sessão definem as condições sob as quais a Okta classifica uma sessão ativa como uma violação de política. Enquanto a regra de política de sessão pós-autenticação define a resposta a uma violação, este recurso define a lógica de detecção: qual nível mínimo de risco e contexto de rede devem estar presentes antes que uma sessão seja sinalizada.
O argumento min_risk_level define o limite de detecção (LOW, MEDIUM ou HIGH). O argumento network_connection define o escopo de aplicação — configurá-lo como ZONE e fornecer IDs de zona por meio de network_includes ou network_excludes oferece um controle granular.
Por exemplo, excluindo sessões originadas da VPN corporativa da detecção de violações.
Importante: assim como a regra de política de sessão pós-autenticação, okta_session_violation_policy_rule é pré-provisionada pelo Okta e deve ser importada antes que o Terraform possa gerenciá-la:
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
nome = "Violação de Sessão de Alto Risco"
nível_mínimo_de_risco = "ALTO"
conexão_de_rede = "ZONA"
exclusões_de_rede = [okta_network_zone.corporate_vpn.id]
policy_evaluation_enabled = true
}
Observe que okta_network_zone.corporate_vpn.id faz referência à zona de rede definida na primeira seção. O gráfico de recursos do Terraform ajuda a garantir que a zona exista antes que a regra de violação de sessão faça referência a ela.
Configuração do receptor de SSF —
provedor_de_eventos_de_segurança_okta
O recurso okta_security_events_provider configura a Okta como um receptor do Shared Signals estrutura (SSF), permitindo que ela receba sinais de evento de segurança de provedores terceirizados, como CrowdStrike, Zscaler ou outros locatário da Okta. Esses sinais de entrada alimentam diretamente o Risk Engine do ITP.
Um evento de detecção de endpoint proveniente de um fornecedor de segurança terceirizado pode elevar a pontuação de risco de um usuário em tempo real, o que, por sua vez, aciona as regras da Política de Risco da Entidade definidas acima.
Gerenciar receptores SSF no Terraform ajuda a garantir que toda a cadeia de sinal-resposta — desde a inteligência de ameaças recebida até o encerramento da sessão automático — seja configurada de forma consistente e auditável em todos os ambientes.
O argumento type identifica o tipo de provedor SSF. Para provedores que publicam um documento de descoberta SSF, defina settings.well_known_url para o endpoint /.well-known/ssf-configuration do provedor. Para provedores sem um documento de descoberta, defina settings.issuer e settings.jwks_url diretamente. O argumento is_enabled aceita 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"
}
}
Assim que o receptor estiver ativo, os sinais do provedor configurado fluem para o Risk Engine da Okta e são avaliados em relação às regras de risco da entidade e de violação de sessão definidas nas seções anteriores.
Conclusão
Gerenciar o ITP via Terraform transforma sua postura de segurança de uma configuração mantida manualmente em um sistema versionado, revisado por pares e com implantação contínua. Os seis recursos abordados nesta publicação, em conjunto, abrangem toda a superfície de gerenciamento do ITP:
RECURSO | FUNÇÃO |
okta_network_zone | Defina contextos de rede confiáveis e bloqueados para avaliação de risco |
okta_user_risk | Atribua níveis de risco aos usuários de forma programática em Workflows automatizados |
regra_de_política_de_risco_de_entidade_okta | Automatize respostas a ameaças — encerramento da sessão, invocação de fluxo de trabalho — com base em pontuações de risco do ITP |
okta_post_auth_session_policy_rule | Controle o comportamento da Okta quando a avaliação contínua falhar em uma sessão ativa |
regra_de_política_de_violação_de_sessão_okta | Defina as condições — nível de risco, contexto de rede — que sinalizam uma sessão como uma violação de política |
provedor_de_eventos_de_segurança_okta | Ingerir sinais de ameaças de terceiros via SSF para enriquecer o Risk Engine em tempo real do ITP |
Em conjunto, esses recursos fecham o ciclo entre detecção e resposta inteiramente em código. Um sinal de terceiros chega via SSF, eleva a pontuação de risco de um usuário, aciona uma regra de política de risco da entidade para encerrar sessões, e a regra de violação de sessão ajuda a garantir que quaisquer sessões sobreviventes sejam detectadas pela avaliação contínua — tudo isso declarado no HCL, revisado em uma solicitação de pull e aplicado de forma consistente em todos os ambientes.
Para obter informações completas sobre os argumentos e a configuração do provedor, consulte a documentação do provedor Okta Terraform.
