managing-cloud-identity-with-okta

Okta によるクラウド ID の管理

使用するタイミング

• 単一の ID プロバイダーを通じて、AWS、Azure、GCP のコンソールアクセスの認証を一元化する場合
• SMS や TOTP ベースの認証を置き換えるために、フィッシング耐性のある MFA を導入する場合
• クラウドプラットフォームおよび SaaS アプリケーション全体でユーザーのプロビジョニングとデプロビジョニングを自動化する場合
• デバイスのコンプライアンス、ユーザーのリスク、ネットワークコンテキストに基づいて、適応型アクセスポリシーを適用する場合
• SOC 2 またはゼロトラストのコンプライアンスに向けて、ID 関連のセキュリティ管理を監査する場合

外部 IdP の要件がないクラウドネイティブな ID 管理（AWS IAM Identity Center または Azure AD をネイティブに使用）、アプリケーションレベルの認可ロジック、またはシークレット管理（implementing-secrets-management-with-vault を参照）には使用しないでください。

前提条件

• 管理コンソールへのアクセス権と適切なライセンスティア（Workforce Identity）を持つ Okta 組織
• SAML または OIDC フェデレーション用に構成された AWS、Azure、GCP アカウント
• HR システムまたは Active Directory から同期されたユーザー ID が登録された 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 で ID への脅威を監視する

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	クラウドアプリケーション間でユーザーの作成、更新、削除を自動化するクロスドメイン ID 管理プロトコルのためのシステム
Universal Directory	AD、LDAP、HR システムなど複数のソースからユーザープロファイルを集約する、Okta のクラウドベースの ID ストア
Adaptive MFA	デバイストラスト、場所、行動などのリスクシグナルに基づいて MFA 要件を調整する、コンテキスト対応の認証
Workforce Identity	SSO、MFA、ライフサイクル管理を含む、従業員と契約社員の ID 管理に重点を置いた Okta の製品ティア
ThreatInsight	クレデンシャルスタッフィング、パスワードスプレー、ボットによる認証攻撃を特定して遮断する Okta の脅威検知サービス
Device Trust	アクセスを許可する前にデバイスのコンプライアンス（暗号化、OS バージョン、管理状態）を検証するための MDM プラットフォームとの連携

ツールとシステム

• Okta Identity Engine: SSO、MFA、ライフサイクル管理、適応型アクセスポリシーを提供するコアの ID プラットフォーム
• Okta Workflows: クラウドサービス全体にわたる ID 主導のワークフローを構築するためのノーコード自動化プラットフォーム
• Okta Advanced Server Access: 短期間有効な証明書を使用した、クラウドサーバーへの SSH および RDP アクセス管理
• AWS IAM Identity Center: 外部 ID プロバイダーとして Okta と連携する、AWS ネイティブの SSO サービス
• Azure AD External Identities: B2B およびワークフォースのシナリオで Okta とフェデレーションするための Azure サービス

一般的なシナリオ

シナリオ：マルチクラウド環境におけるオフボーディングの自動化

背景: AWS 管理者、Azure コントリビューター、GCP エディターの各権限を持つ従業員が退職します。組織は、HR が退職手続きを行ってから 15 分以内にすべてのアクセス権を取り消す必要があります。

アプローチ:

1. HR が Workday で従業員を無効化し、Okta への SCIM イベントをトリガーします
2. Okta はユニバーサルディレクトリでユーザーを直ちに無効化し、アクティブなすべての 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