Einführung
Oktas Identity Threat Protection (ITP) bietet kontinuierliche Bedrohungserkennung in Echtzeit und automatisierte Reaktionsfunktionen, die über das anfängliche Authentifizierungsereignis hinausgehen. Während die Stärke von ITP in der Fähigkeit liegt, auf Signale nach der Authentifizierung zu reagieren, kommt diese Stärke nur dann durchgängig zum Tragen, wenn die zugrunde liegenden Richtlinien, Netzwerkkontexte und Signalintegrationen über alle Umgebungen hinweg konsistent konfiguriert sind.
Hier kommt Infrastructure as Code ins Spiel.
Dieser Beitrag behandelt, wie Sie den gesamten ITP-Bereich – Netzwerkzonen, Zuweisungen von Benutzerrisiken, Regeln für Entity-Risikorichtlinien, Session-Schutzregeln und die Erfassung von Drittanbieter-Signalen – deklarativ mit dem Okta Terraform Provider verwalten können.
Warum Terraform für ITP?
Das deklarative Modell von Terraform bietet konkrete betriebliche Vorteile für die Sicherheitskonfiguration.
- Versionskontrollierte Richtlinie: Jede Änderung an einer Netzwerkzone oder einer Risikoreaktionsregel wird in der Quellcodeverwaltung gespeichert, was Ihnen einen vollständigen Audit-Trail und die Möglichkeit bietet, Änderungen rückgängig zu machen
- Wiederholbare Bereitstellungen: Wenden Sie dieselbe ITP-Konfiguration auf Entwicklungs-, Staging- und Produktionsumgebungen an, ohne manuelle Neueingabe oder durch die Zwischenablage bedingte Inkonsistenzen
- Drift-Beseitigung: Der Plan/Apply-Zyklus von Terraform erkennt und korrigiert Out-of-Band-Änderungen und hilft dabei sicherzustellen, dass Ihre Live-Konfiguration mit Ihrer deklarierten Absicht übereinstimmt
- CI/CD-Integration: Änderungen an Sicherheitsrichtlinien durchlaufen denselben Pull-Request-Review, dieselben automatisierten Tests und dieselbe Deployment-Pipeline wie der Anwendungscode
Mit dem Okta Terraform Provider können Sie insbesondere:
- ITP-Konfigurationen gemeinsam mit der restlichen IAM-Infrastruktur in einer einheitlichen Codebasis verwalten
- Einheitliche Kontrollen zur Bedrohungsabwehr über alle Umgebungen hinweg durchsetzen
- Änderungen an Risikorichtlinien per Pull Request durch ein Vier-Augen-Prinzip prüfen, bevor sie in der Produktionsumgebung wirksam werden
- Automatisierte Reaktionen schnell anpassen, wenn sich das Bedrohungsmodell ändert
- Das vollständige Lifecycle Management von Netzwerkzonen, Risikosignalen, SSF-Empfängern (Shared Signals Framework) und Richtlinienregeln aufrechterhalten
Die folgenden Abschnitte behandeln jede der sechs primären ITP-bezogenen Ressourcen im Okta Terraform Provider.
Netzwerkzonen
okta_network_zone
Netzwerkzonen definieren die geografischen Regionen, IP-Bereiche oder Nummern autonomer Systeme, die Okta verwendet, um den Netzwerkkontext eines Authentifizierungsversuchs oder einer aktiven Session zu klassifizieren. In einem ITP-Kontext erfüllen Zonen zwei Funktionen: Sie identifizieren vertrauenswürdige Netzwerkkontexte (wie z. B. einen unternehmensinternen VPN-Bereich), die Nutzer:innen von bestimmten Risikoprüfungen ausnehmen können, und definieren Blocklists (wie z. B. Tor-Anonymisierer), die das Risiko unabhängig von anderen Signalen sofort erhöhen.
Die Verwaltung von Zonen in Terraform bietet Ihnen ein versioniertes, überprüfbares Verzeichnis aller vertrauenswürdigen und blockierten Netzwerkbereiche in Ihrer Umgebung. Das type-Argument steuert die Zonenklassifizierung – IP für explizite CIDR-Blöcke oder IP-Bereiche, DYNAMIC für Proxy-Klassifizierungen wie Tor und DYNAMIC_V2 für ASN-basierte dynamische Zonen. Das usage-Argument legt fest, ob die Zone für die Richtlinienauswertung verwendet wird (POLICY) oder als Sperrliste fungiert (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"
}
Die Zone corporate_vpn wird später in der Regel für Session-Verstöße referenziert, was veranschaulicht, wie der Netzwerkkontext durch den ITP-Richtlinien-Stack fließt.
Benutzerrisikomanagement
okta_user_risk
Die Ressource okta_user_risk ermöglicht es Ihnen, einem bestimmten Okta-Benutzer programmgesteuert eine Risikoklassifizierung zuzuweisen. Unterstützte Werte für risk_level sind HIGH, MEDIUM und LOW. Diese Ressource ist als Teil eines automatisierten Behebungs-Workflows am wertvollsten: Eine SIEM- oder SOAR-Plattform erkennt einen Kompromittierungsindikator, löst einen Terraform-Lauf aus (oder ruft die Okta-API direkt auf), setzt das Risiko der betroffenen Benutzer:in auf HIGH, und die unten definierten Regeln der Entity-Risikorichtlinie übernehmen die Kontrolle – sie beenden aktive Sessions oder rufen einen Behebungs-Workflow auf.
Dies schließt den Kreis zwischen externen Erkennungstools und Oktas Engine für kontinuierliche Auswertung ohne manuelles Eingreifen.
resource "okta_user_risk" "compromised_user" {
user_id = okta_user.example.id
risk_level = "HIGH"
}
In der Praxis wird die user_id in der Regel aus einer Datenabfrage bezogen oder während eines automatisierten Pipeline-Durchlaufs als Variable übergeben, anstatt fest codiert zu werden.
Regeln für Entity-Risikorichtlinien
okta_entity_risk_policy_rule
Regeln für Entity-Risikorichtlinien definieren die automatisierten Reaktionen, die Okta ausführt, wenn ITP einer Benutzer:in einen Risiko-Score zuweist, der einen konfigurierten Schwellenwert erreicht oder überschreitet. Die Entity-Risikorichtlinie selbst wird automatisch bereitgestellt, wenn ITP in Ihrem Okta-Tenant aktiviert wird – Sie erstellen die Richtlinie nicht über Terraform. Stattdessen rufen Sie die zugehörige ID mithilfe der Datenquelle okta_entity_risk_policy ab und erstellen darin Regeln.
Regeln können auf bestimmte Risikostufen (HIGH, MEDIUM oder LOW) abzielen und unterstützen zwei Reaktionsaktionen: terminate_all_sessions macht sofort alle aktiven Sessions der Benutzer:innen ungültig, und workflow_id ruft einen Okta Workflow für komplexere Behebungsschritte auf, wie das Senden von Benachrichtigungen, das Deaktivieren von Accounts oder das Auslösen externer Integrationen.
Hinweis: Die Standardregel (Priorität 99) ist vorab bereitgestellt und kann nicht geändert oder gelöscht werden. Terraform-verwaltete Regeln sollten Prioritäten unter 99 verwenden.
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
}
Zusätzliche Argumente wie users_excluded und groups_included ermöglichen es Ihnen, Regeln auf bestimmte Benutzergruppen zu beschränken, was bei der schrittweisen Einführung der ITP-Durchsetzung nützlich ist.
Post-Auth-Session-Richtlinienregeln
okta_post_auth_session_policy_rule
Die Post-Auth-Session-Richtlinienregel legt fest, was Okta unternimmt, wenn eine kontinuierliche Evaluierungsprüfung für eine aktive Session nach der initialen Authentifizierung fehlschlägt – zum Beispiel, wenn sich der Compliance-Status des Geräts von Nutzer:innen ändert, ihr Netzwerkkontext in eine blockierte Zone wechselt oder ihr Risiko-Score als Reaktion auf ein eingehendes SSF-Signal steigt.
Wichtig: Im Gegensatz zu den meisten Terraform-Ressourcen wird okta_post_auth_session_policy_rule von Okta vorab bereitgestellt und kann nicht über Terraform erstellt oder gelöscht werden. Sie müssen die vorhandene Regel importieren, bevor Sie diese verwalten:
terraform import okta_post_auth_session_policy_rule.session_protection <policy_id>/<rule_id>
Rufen Sie die Richtlinien- und Regel-IDs aus der Okta Admin-Konsole oder über die Datenquelle okta_post_auth_session_policy und die Okta API ab.
Trotz der Nur-Import-Einschränkung bietet die Terraform-Verwaltung hier dennoch einen erheblichen Mehrwert: die Konfiguration ist versionskontrolliert, Änderungen durchlaufen ein Peer-Review und das Beendigungsverhalten ist zusammen mit allen anderen ITP-Richtlinien in einem einzigen Repository kodifiziert.
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
}
Die Argumente groups_included und groups_excluded ermöglichen eine bereichsbezogene Durchsetzung, und workflow_id unterstützt dieselbe Integration von Okta Workflows wie die Entity-Risikoregeln.
Detection-Policy-Regeln für Session-Verstöße
okta_session_violation_policy_rule
Regeln der Detection-Policy für Session-Verstöße definieren die Bedingungen, unter denen Okta eine aktive Session als Richtlinienverstoß klassifiziert. Während die Post-Auth-Session-Richtlinienregel die Reaktion auf einen Verstoß definiert, legt diese Ressource die Erkennungslogik fest: welches Mindestrisikoniveau und welcher Netzwerkkontext vorliegen müssen, bevor eine Session markiert wird.
Das Argument min_risk_level legt den Erkennungsschwellenwert (LOW, MEDIUM oder HIGH) fest. Das Argument network_connection legt den Gültigkeitsbereich der Durchsetzung fest – wenn Sie es auf ZONE setzen und Zonen-IDs über network_includes oder network_excludes angeben, erhalten Sie eine präzise Kontrolle.
Beispielsweise der Ausschluss von Sessions aus Ihrem Unternehmens-VPN von der Verstoßerkennung.
Wichtig: Wie die Post-Auth-Session-Richtlinienregel wird okta_session_violation_policy_rule von Okta vorab bereitgestellt und muss importiert werden, bevor Terraform sie verwalten kann:
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
}
Beachten Sie, dass okta_network_zone.corporate_vpn.id auf die im ersten Abschnitt definierte Netzwerkzone verweist. Der Terraform-Ressourcengraph hilft sicherzustellen, dass die Zone existiert, bevor die Regel für Session-Verstöße darauf verweist.
SSF-Empfängerkonfiguration
okta_security_events_provider
Die Ressource okta_security_events_provider konfiguriert Okta als Empfänger für das Shared Signals Framework (SSF) und ermöglicht so die Erfassung von Sicherheitsereignissignalen von Drittanbietern wie CrowdStrike, Zscaler oder anderen Okta-Tenants. Diese eingehenden Signale fließen direkt in die Risiko-Engine von ITP ein.
Ein Endpoint-Erkennungsereignis eines externen Sicherheitsanbieters kann den Risiko-Score einer Nutzer:in in Echtzeit erhöhen, was dann die oben definierten Regeln der Entity-Risikorichtlinie auslöst.
Die Verwaltung von SSF-Empfängern in Terraform hilft sicherzustellen, dass die gesamte Signal-Antwort-Kette – von eingehender Threat Intelligence bis zur automatisierten Beendigung von Sessions – in allen Umgebungen konsistent konfiguriert und auditierbar ist.
Das Argument type gibt den SSF-Anbietertyp an. Für Anbieter, die ein SSF-Erkennungsdokument veröffentlichen, legen Sie settings.well_known_url auf den /.well-known/ssf-configuration -Endpoint des Anbieters fest. Legen Sie für Anbieter ohne Erkennungsdokument settings.issuer und settings.jwks_url fest direkt. Das Argument is_enabled akzeptiert ACTIVE oder 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"
}
}
Sobald der Empfänger aktiv ist, fließen Signale des konfigurierten Anbieters in die Risiko-Engine von Okta und werden anhand der in den vorherigen Abschnitten definierten Regeln für Entitätsrisiken und Session-Verstöße ausgewertet.
Fazit
Die Verwaltung von ITP über Terraform verwandelt Ihre Sicherheitslage von einer manuell gepflegten Konfiguration in ein versionskontrolliertes, Peer-Review-geprüftes und kontinuierlich bereitstellbares System. Die sechs in diesem Beitrag behandelten Ressourcen decken gemeinsam die gesamte ITP-Verwaltungsoberfläche ab:
Ressource | Rolle |
okta_network_zone | Definieren Sie vertrauenswürdige und blockierte Netzwerkkontexte für die Risikobewertung |
okta_user_risk | Weisen Sie Konten in automatisierten Workflows programmatisch Risikostufen zu |
okta_entity_risk_policy_rule | Automatisieren Sie Reaktionen auf Bedrohungen – Beendigung von Sessions, Aufruf von Workflows – basierend auf ITP-Risiko-Scores |
okta_post_auth_session_policy_rule | Steuern Sie das Verhalten von Okta, wenn die kontinuierliche Auswertung bei einer aktiven Session fehlschlägt |
okta_session_violation_policy_rule | Definieren Sie die Bedingungen – Risikoniveau, Netzwerkkontext –, die eine Session als Richtlinienverstoß kennzeichnen |
okta_security_events_provider | Importieren Sie Bedrohungssignale von Drittanbietern über SSF, um die Echtzeit-Risiko-Engine von ITP anzureichern |
Zusammen schließen diese Ressourcen den Kreislauf zwischen Erkennung und Reaktion vollständig im Code. Ein Drittanbieter-Signal trifft über SSF ein, erhöht den Risiko-Score von Benutzer:innen, löst eine Regel der Entity-Risikorichtlinie aus, um Sessions zu beenden, und die Regel für Session-Verstöße trägt dazu bei, dass alle verbleibenden Sessions durch kontinuierliche Auswertung erfasst werden – all dies in HCL deklariert, in einem Pull Request überprüft und konsistent in jeder Umgebung angewendet.
Eine vollständige Referenz der Argumente und Informationen zur Provider-Konfiguration finden Sie in der Dokumentation zum Okta Terraform Provider.
