はじめに
OktaのIdentity Threat Protection（ITP）は、継続的かつリアルタイムの脅威検知と自動レスポンス機能を提供します。これらの機能は、最初の認証イベント後も継続して動作します。ITPの強みは認証後のシグナルに基づいてアクションを実行できる点にありますが、その強みを一貫して発揮するには、基盤となるポリシー、ネットワークコンテキスト、シグナルの統合が、環境全体で一貫して設定されている必要があります。
そこでInfrastructure as Codeが役立ちます。
この記事では、Okta Terraform Providerを使用して、ITPの対象領域全体（ネットワークゾーン、ユーザーリスクの割り当て、エンティティリスクのポリシールール、セッション保護ルール、サードパーティシグナルの取り込み）を宣言的に管理する方法について説明します。
ITPにTerraformを使用する理由
Terraformの宣言型モデルは、セキュリティ構成で具体的な運用上のメリットを実現します。
- バージョン管理されたポリシー：ネットワークゾーンやリスク対応ルールへの変更はすべてソース管理にコミットされるため、完全な監査証跡が提供され、ロールバックも可能です。
- デプロイの再現性：開発、ステージング、本番の各環境に同じITP構成を適用できます。手動での再入力や、クリップボードの使用による不整合は発生しません。
- ドリフトの排除：Terraformのplan/applyサイクルは、帯域外の変更を検出して修正し、ライブ構成が宣言された意図と一致するようにします。
- CI/CD統合：セキュリティポリシーの変更は、アプリケーションコードと同じプルリクエストレビュー、自動テスト、デプロイメントパイプラインを経由します。
Okta Terraform Providerでは、特に以下が可能です。
- ITP設定を、他のIAMインフラストラクチャと一緒に単一のコードベースで管理します。
- すべての環境全体で、一貫性のある脅威対応制御を徹底します。
- 本番環境に適用する前に、プルリクエストを介してリスクポリシーの変更をピアレビューします。
- 脅威モデルが変化した際に、自動化された応答を迅速に再構成します
- ネットワークゾーン、リスクシグナル、Shared Signals Framework（SSF）レシーバー、ポリシールールの完全なライフサイクル管理を維持します。
以降のセクションでは、Okta Terraform ProviderにおけるITP関連の6つの主要なリソースについて、それぞれ説明します。
ネットワークゾーン —
okta_network_zone
ネットワークゾーンは、認証試行またはアクティブなセッションのネットワークコンテキストを分類するためにOktaが使用する、地域、IP範囲、または自律システム番号を定義します。ITPのコンテキストにおいて、ゾーンには2つの役割があります。1つは、ユーザーを特定のリスクチェックから除外できる、信頼できるネットワークコンテキスト（企業のVPN範囲など）の特定です。もう1つは、他のシグナルに関係なく即座にリスクを高めるブロックリスト（Torアノニマイザーなど）の定義です。
Terraformでゾーンを管理することで、環境内のすべての信頼できるネットワーク範囲とブロックされたネットワーク範囲について、バージョン管理された監査可能なインベントリを作成できます。type引数はゾーンの分類を制御します。IPは明示的なCIDR範囲またはIP範囲、DYNAMICはTorなどのプロキシタイプの分類、DYNAMIC_V2はASNベースの動的ゾーンに使用します。usage引数により、ゾーンがポリシー評価（POLICY）に使用されるか、ブロックリスト（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"
}
corporate_vpnゾーンは、後でセッション違反ルールで参照され、ネットワークコンテキストがITPポリシーのスタックをどのように通過するかを示します。
ユーザーリスク管理 —
okta_user_risk
okta_user_riskリソースを使用すると、特定のOktaユーザーにリスク分類をプログラム的に割り当てることができます。risk_levelでサポートされている値は、HIGH、MEDIUM、LOWです。このリソースは、自動修復ワークフローの一部として使用することで、その価値を最大限に発揮します。SIEMまたはSOARプラットフォームが侵害の兆候を検知すると、Terraformの実行をトリガーし（またはOkta APIを直接呼び出し）、影響を受けるユーザーのリスクをHIGHに設定します。その後、以下で定義されるエンティティリスクポリシーのルールが引き継ぎ、アクティブなセッションを終了させるか、修復ワークフローを呼び出します。
これにより、手動による介入なしに、外部の検知ツールとOktaの継続的評価エンジンが連携できるようになります。
resource "okta_user_risk" "compromised_user" {
user_id = okta_user.example.id
risk_level = "HIGH"
}
実際には、user_id はハードコーディングされるのではなく、通常はデータルックアップから取得されるか、自動化されたパイプラインの実行中に変数として渡されます。
エンティティリスクポリシーのルール —
okta_entity_risk_policy_rule
エンティティリスクポリシールールは、ITPによってユーザーに割り当てられたリスクスコアが、設定されたしきい値以上になった場合にOktaが実行する自動レスポンスを定義します。エンティティリスクポリシー自体は、OktaテナントでITPが有効になると自動的にプロビジョニングされます。このポリシーはTerraformでは作成しません。代わりに、okta_entity_risk_policyデータソースを使用してそのIDを取得し、その中にルールを作成します。
ルールは、特定のリスクレベル（HIGH、MEDIUM、またはLOW）をターゲットにすることができ、2つの応答アクションをサポートします。terminate_all_sessionsはユーザーのすべてのアクティブなセッションをただちに無効にし、workflow_idは通知の送信、アカウントの無効化、外部統合のトリガーといった、より複雑な修復ステップのためにOktaワークフローを呼び出します。
注：デフォルトのルール（優先度99）は事前プロビジョニングされており、変更または削除することはできません。Terraformで管理されるルールでは、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
}
users_excludedやgroups_includedなどの追加の引数を使用すると、特定のユーザー集団にルールをスコープ設定できます。これは、ITPの適用を段階的に展開する場合に便利です。
認証後のセッションポリシーのルール —
okta_post_auth_session_policy_rule
認証後のセッションポリシールールは、初期認証後にアクティブなセッションで継続的な評価チェックが失敗した場合にOktaが実行する処理を規定します。たとえば、ユーザーのデバイスのコンプライアンス状態が変化した場合、ネットワークコンテキストがブロックされたゾーンに移行した場合、受信したSSFシグナルに応じてリスクスコアが上昇した場合などが該当します。
重要：ほとんどのTerraformリソースとは異なり、okta_post_auth_session_policy_ruleはOktaによって事前プロビジョニングされており、Terraform経由で作成または破棄することはできません。既存のルールを管理するには、まずインポートする必要があります：
terraform import okta_post_auth_session_policy_rule.session_protection <policy_id>/<rule_id>
Oktaの管理コンソール、またはokta_post_auth_session_policyデータソースとOkta APIを使用して、ポリシーとルールのIDを取得します。
インポートのみという制約はありますが、Terraformによる管理には依然として大きな価値があります。構成はバージョン管理され、変更にはピアレビューが行われ、終了時の動作は他のすべてのITPポリシーと一緒に単一のリポジトリでコード化されます。
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
}
groups_included引数とgroups_excluded引数を使用すると、スコープ設定した適用が可能になります。また、workflow_idは、エンティティリスクルールと同じOkta Workflows統合をサポートしています。
セッション違反検知ポリシーのルール —
okta_session_violation_policy_rule
セッション違反検出ポリシーのルールは、アクティブなセッションをOktaがポリシー違反として分類する条件を定義します。認証後セッションポリシールールが違反への対応を定義するのに対し、このリソースは検知ロジック、つまりセッションにフラグを立てる前に存在していなければならない最小リスクレベルとネットワークコンテキストを定義します。
min_risk_level引数は、検知のしきい値（LOW、MEDIUM、HIGH）を設定します。network_connection引数は、適用のスコープを設定します。ZONEに設定し、network_includesまたはnetwork_excludesを介してゾーンIDを指定することで、きめ細かな制御が可能になります。
例えば、自社のVPNから発信されたセッションを違反検知から除外します。
重要：認証後のセッションポリシーのルールと同様に、okta_session_violation_policy_ruleはOktaによって事前プロビジョニングされており、Terraformで管理するにはインポートする必要があります。
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
}
okta_network_zone.corporate_vpn.idは、最初のセクションで定義されたネットワークゾーンを参照することに注意してください。Terraformのリソースグラフは、セッション違反ルールがゾーンを参照する前に、そのゾーンが確実に存在するようにします。
SSFレシーバーの構成 —
okta_security_events_provider
okta_security_events_providerリソースは、OktaをShared Signals Framework（SSF）のレシーバーとして構成し、CrowdStrike、Zscaler、または他のOktaテナントなどのサードパーティプロバイダーからセキュリティイベントシグナルを取り込めるようにします。こうしたインバウンドシグナルは、ITPのリスクエンジンに直接送信されます。
サードパーティのセキュリティベンダーからのエンドポイント検出イベントによって、ユーザーのリスクスコアがリアルタイムで上昇する可能性があります。これにより、前述のエンティティリスクポリシーのルールがトリガーされます。
TerraformでSSFレシーバーを管理することで、インバウンドの脅威インテリジェンスから自動セッション終了に至るまで、シグナルからレスポンスまでのチェーン全体が、すべての環境で一貫して構成され、監査可能であることを保証できます。
type引数は、SSFプロバイダーのタイプを識別します。SSFディスカバリードキュメントを公開するプロバイダーの場合は、settings.well_known_urlをプロバイダーの/.well-known/ssf-configurationエンドポイントに設定します。ディスカバリードキュメントがないプロバイダーの場合は、settings.issuerとsettings.jwks_urlを直接設定します。is_enabled引数には、ACTIVEまたは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"
}
}
レシーバーがアクティブになると、構成されたプロバイダーからのシグナルがOktaのリスクエンジンに取り込まれ、前のセクションで定義されたエンティティリスクとセッション違反のルールに照らして評価されます。
おわりに
TerraformでITPを管理することで、手動で維持していた構成から、バージョン管理、ピアレビュー、継続的な展開が可能なシステムへとセキュリティポスチャを変革できます。この記事で取り上げた6つのリソースは、ITP管理のあらゆる側面を網羅しています。
リソース | 役割 |
okta_network_zone | リスク評価のために、信頼できるネットワークコンテキストとブロックするネットワークコンテキストを定義します。 |
okta_user_risk | 自動化されたワークフローで、プログラム的にユーザーにリスクレベルを割り当てます。 |
okta_entity_risk_policy_rule | ITPのリスクスコアに基づいて、脅威対応（セッション終了、ワークフローの呼び出しなど）を自動化します。 |
okta_post_auth_session_policy_rule | アクティブなセッションで継続的な評価が失敗した場合のOktaの動作を制御します。 |
okta_session_violation_policy_rule | ポリシー違反としてセッションにフラグを立てる条件（リスクレベル、ネットワークコンテキスト）を定義します。 |
okta_security_events_provider | SSF経由でサードパーティの脅威シグナルを取り込み、ITPのリアルタイムリスクエンジンを強化します。 |
これらのリソースが連携することで、検出と対応のループがすべてコード内で完結します。SSF経由でサードパーティのシグナルが到着すると、ユーザーのリスクスコアが引き上げられ、エンティティリスクのポリシールールがトリガーされてセッションが終了します。セッション違反ルールは、継続的な評価によって残存セッションが確実に検出されるようにします。これらすべてがHCLで宣言され、プルリクエストでレビューされ、すべての環境で一貫して適用されます。
引数の完全なリファレンスとプロバイダーの構成については、Okta Terraform Providerのドキュメントを参照してください。
