managing-cloud-identity-with-okta

使用 Okta 管理云身份

何时使用

• 当需要通过单一身份提供商集中管理 AWS、Azure 和 GCP 控制台访问的身份验证时
• 当需要实施抗钓鱼 MFA 以替代基于 SMS 或 TOTP 的身份验证时
• 当需要在云平台和 SaaS 应用之间自动化用户预配和取消预配时
• 当需要根据设备合规性、用户风险和网络环境执行自适应访问策略时
• 当需要为 SOC 2 或零信任合规审计身份相关安全控制时

不要使用于无外部 IdP 需求的云原生身份管理（请原生使用 AWS IAM Identity Center 或 Azure AD）、应用级授权逻辑，或密钥管理（参见 implementing-secrets-management-with-vault）。

前置条件

• 具有管理员控制台访问权限和适当许可层级（Workforce Identity）的 Okta 组织
• 已为 SAML 或 OIDC 联合配置的 AWS、Azure 和 GCP 账户
• 已填充从 HR 系统或 Active Directory 同步的用户身份的 Okta Universal Directory
• 用于设备信任集成的设备管理平台（Intune、Jamf）

工作流

步骤 1：配置与云提供商的 SSO 集成

在 Okta 与各云提供商控制台之间设置 SAML 2.0 或 OIDC 联合，以实现集中式身份验证。

Okta AWS SSO Integration (SAML 2.0):
1. In Okta Admin Console: Applications > Add Application > AWS Account Federation
2. Configure SAML settings:
   - Single Sign-On URL: https://signin.aws.amazon.com/saml
   - Audience URI: urn:amazon:webservices
   - Attribute Statements:
     - https://aws.amazon.com/SAML/Attributes/RoleSessionName -> user.email
     - https://aws.amazon.com/SAML/Attributes/Role -> appuser.awsRoles
3. Download Okta metadata XML
4. In AWS IAM: Create Identity Provider (SAML) with Okta metadata
5. Create IAM roles with trust policy referencing the Okta SAML provider

AWS IAM Trust Policy:
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::123456789012:saml-provider/Okta"
    },
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "SAML:aud": "https://signin.aws.amazon.com/saml"
      }
    }
  }]
}

# Azure AD integration via OIDC
# Configure Okta as external IdP in Azure AD
az ad sp create --id <okta-app-client-id>

# GCP integration via Workforce Identity Federation
gcloud iam workforce-pools create okta-pool \
  --organization=123456789 \
  --location=global \
  --display-name="Okta Workforce Pool"

gcloud iam workforce-pools providers create-oidc okta-provider \
  --workforce-pool=okta-pool \
  --location=global \
  --issuer-uri="https://company.okta.com/oauth2/default" \
  --client-id="gcp-workforce-client-id" \
  --attribute-mapping="google.subject=assertion.sub,google.groups=assertion.groups"

步骤 2：部署抗钓鱼 MFA

启用 Okta FastPass 和 FIDO2 WebAuthn 身份验证器作为抗钓鱼 MFA 因素。配置要求特权云访问使用这些因素的政策。

Okta MFA Policy Configuration:
1. Security > Authenticators:
   - Enable Okta Verify (FastPass) - Phishing resistant
   - Enable FIDO2 (WebAuthn) - Hardware security keys
   - Disable SMS and Voice (phishable)

2. Authentication Policies > Cloud Admin Access:
   - Rule: "Require phishing-resistant MFA for AWS/Azure/GCP admin roles"
   - Factor Types: Okta FastPass OR FIDO2 WebAuthn
   - Re-authentication: Every 4 hours for admin consoles
   - Session Lifetime: 8 hours maximum

3. Device Trust Policy:
   - Require managed device for cloud admin access
   - Require device encryption enabled
   - Require OS version within 90 days of latest

步骤 3：自动化用户生命周期管理

配置 SCIM 预配，以便在员工入职、角色变更或离职时，自动在云服务中创建和停用用户账户。

Okta Lifecycle Management:
1. Provisioning Configuration (AWS IAM Identity Center):
   - Enable SCIM provisioning to AWS IAM Identity Center
   - Map Okta groups to AWS permission sets
   - Configure attribute mapping: email, displayName, groups

2. Automation Rules:
   - On User Activation: Provision to AWS, Azure, GCP based on department group
   - On Group Change: Update cloud role assignments within 15 minutes
   - On User Deactivation: Immediately revoke all cloud sessions and permissions
   - On Suspension: Disable cloud accounts, preserve data for 30 days

3. Offboarding Workflow:
   - HR triggers deactivation in Workday/BambooHR
   - Okta receives SCIM event, deactivates user in Universal Directory
   - All SSO sessions terminated across AWS, Azure, GCP
   - SCIM deprovisioning removes user from cloud platforms
   - Audit log entry created for compliance evidence

步骤 4：配置自适应访问策略

创建上下文感知的身份验证策略，评估风险信号，包括设备状态、网络位置、用户行为和威胁情报。

Adaptive Access Policy Examples:

Policy 1: "High-Risk Cloud Admin Access"
  IF: User is in "Cloud Admins" group
  AND: Accessing AWS Console, Azure Portal, or GCP Console
  THEN:
    - Require phishing-resistant MFA (FastPass or FIDO2)
    - Require managed and compliant device
    - Block access from anonymous proxies or Tor
    - Session duration: 4 hours
    - Re-authentication: Every 2 hours for sensitive actions

Policy 2: "Standard Cloud Developer Access"
  IF: User is in "Developers" group
  AND: Accessing non-admin cloud resources
  THEN:
    - Require any MFA factor (FastPass, TOTP, or push notification)
    - Allow unmanaged devices with step-up verification
    - Session duration: 8 hours
    - Block access from countries outside operating regions

Policy 3: "Emergency Break-Glass Access"
  IF: User is in "Emergency Admins" group
  AND: Break-glass request approved in ServiceNow
  THEN:
    - Require FIDO2 hardware key only
    - Log all actions to immutable audit trail
    - Session duration: 1 hour maximum
    - Notify SOC team via automated alert

步骤 5：使用 Okta ThreatInsight 监控身份威胁

启用 Okta ThreatInsight 和系统日志监控，以检测撞库、账户接管和可疑身份验证模式。

# Query Okta System Log for security events via API
curl -s -H "Authorization: SSWS ${OKTA_API_TOKEN}" \
  "https://company.okta.com/api/v1/logs?filter=eventType+eq+%22user.session.start%22+and+outcome.result+eq+%22FAILURE%22&since=$(date -d '-24 hours' +%Y-%m-%dT%H:%M:%SZ)" | \
  jq '.[] | {time: .published, actor: .actor.displayName, ip: .client.ipAddress, result: .outcome.reason}'

# Export Okta logs to SIEM via Log Streaming
# Configure in Okta Admin > Reports > Log Streaming
# Supported targets: Splunk Cloud, AWS EventBridge, Datadog

关键概念

术语	定义
Okta FastPass	抗钓鱼的无密码 MFA，通过加密方式将身份验证绑定到设备和来源，防止实时钓鱼攻击
SCIM Provisioning	跨域身份管理系统协议，可跨云应用自动创建、更新和删除用户
Universal Directory	Okta 基于云的身份存储，聚合来自 AD、LDAP 和 HR 系统等多个来源的用户配置文件
Adaptive MFA	上下文感知身份验证，根据设备信任、位置和行为等风险信号调整 MFA 要求
Workforce Identity	Okta 产品层级，专注于员工和承包商身份管理，包括 SSO、MFA 和生命周期管理
ThreatInsight	Okta 的威胁检测服务，可识别并阻止撞库、密码喷洒和机器人驱动的身份验证攻击
Device Trust	与 MDM 平台集成，在授予访问权限前验证设备合规性（加密、操作系统版本、管理状态）

工具与系统

• Okta Identity Engine：核心身份平台，提供 SSO、MFA、生命周期管理和自适应访问策略
• Okta Workflows：无代码自动化平台，用于跨云服务构建身份驱动的工作流
• Okta Advanced Server Access：使用短期证书对云服务器进行 SSH 和 RDP 访问管理
• AWS IAM Identity Center：AWS 原生 SSO 服务，可与 Okta 集成为外部身份提供商
• Azure AD External Identities：Azure 服务，用于与 Okta 联合以支持 B2B 和员工场景

常见场景

场景：跨多云环境自动化离职流程

背景：一名拥有 AWS 管理员、Azure 参与者及 GCP 编辑者权限的员工离职。组织需要在 HR 完成终止流程后的 15 分钟内撤销其所有访问权限。

方案：

1. HR 在 Workday 中停用该员工，触发 SCIM 事件发送至 Okta
2. Okta 立即在 Universal Directory 中停用该用户，终止所有活跃的 SSO 会话
3. SCIM 取消配置将该用户从 AWS IAM Identity Center、Azure AD 和 GCP Workforce Identity 中移除
4. Okta Workflow 触发额外清理：撤销 OAuth 令牌、从 Slack 中移除、禁用 VPN 证书
5. 创建审计日志条目，记录每项取消配置操作的时间戳，作为合规证据
6. SOC 收到通知，以核实不存在通过直接 IAM 用户或服务账号遗留的访问权限

注意事项：未取消配置在 Okta 联邦之外创建的直接 IAM 用户或服务账号会留下后门访问权限。某些服务的 SCIM 传播延迟可能导致在 Okta 停用后的数分钟内访问权限仍处于活跃状态。

输出格式

Cloud Identity Security Report
================================
Identity Provider: Okta (company.okta.com)
Report Date: 2025-02-23

USER STATISTICS:
  Total Users: 2,450
  Active: 2,312 | Suspended: 45 | Deactivated: 93
  MFA Enrolled: 2,298/2,312 (99.4%)
  Phishing-Resistant MFA: 812/2,312 (35.1%)

CLOUD SSO COVERAGE:
  AWS Console (45 accounts):     100% via SAML federation
  Azure Portal (8 subscriptions): 100% via OIDC federation
  GCP Console (3 projects):       100% via Workforce Identity

AUTHENTICATION EVENTS (Last 30 Days):
  Total Logins: 145,234
  MFA Challenges: 89,456
  Failed Logins: 3,456
  Account Lockouts: 23
  ThreatInsight Blocks: 12,345 (credential stuffing attempts)

LIFECYCLE EVENTS:
  Users Provisioned: 45
  Users Deprovisioned: 23
  Average Deprovisioning Time: 8 minutes
  Orphan Accounts Detected: 3 (direct IAM users not managed by Okta)

RECOMMENDATIONS:
  [HIGH] Increase phishing-resistant MFA adoption from 35% to 80%
  [HIGH] Remediate 3 orphan cloud accounts not managed by Okta
  [MEDIUM] Reduce session duration for admin roles from 8h to 4h