implementing-zero-trust-in-cloud

クラウドでゼロトラストを実装する

使用する場面

• 従来の境界ベースのセキュリティから、アイデンティティ中心のアクセス制御に移行する場合
• クラウドアプリケーションへのリモートワーカーのアクセスにおける VPN 依存をなくす場合
• ネットワーク上の場所にかかわらず、すべてのアクセスリクエストを継続的に検証する場合
• マルチクラウドワークロード向けのマイクロセグメンテーション戦略を設計する場合
• 規制要件により、ゼロトラストアーキテクチャの導入が義務付けられている場合（連邦政府の義務、NIST ガイドライン）

次の場合は使用しないでください。より広範なアーキテクチャ変更を伴わない単純な VPN の置き換え、ネットワークファイアウォールルールの管理のみ（implementing-cloud-network-segmentation を参照）、またはアイデンティティプロバイダーの初期設定（managing-cloud-identity-with-okta を参照）。

前提条件

• OIDC／SAML 統合に対応したアイデンティティプロバイダー（Okta、Azure AD、Google Workspace）
• エンドポイントの信頼性評価に使用するデバイス管理ソリューション（Intune、Jamf、Google Endpoint Verification）
• ロードバランサーまたはリバースプロキシのインフラストラクチャ経由で HTTPS にアクセスできるクラウドワークロード
• アクセス判断の継続的な監視と異常検知に使用する SIEM プラットフォーム

ワークフロー

ステップ 1：ゼロトラストの原則とアーキテクチャを定義する

NIST SP 800-207 に従い、中核となる原則を確立します。決して信頼せず、常に検証します。送信元にかかわらず、すべてのアクセスリクエストを認証、認可し、暗号化する必要があります。

Zero Trust Architecture Components:
+-------------------------------------------------------------------+
|                        Policy Decision Point                       |
|  +-------------------+  +------------------+  +-----------------+ |
|  | Identity Provider |  | Device Trust     |  | Risk Engine     | |
|  | (Okta/Azure AD)   |  | (Intune/Jamf)    |  | (Continuous)    | |
|  +-------------------+  +------------------+  +-----------------+ |
+-------------------------------------------------------------------+
                              |
                    +--------------------+
                    | Policy Enforcement |
                    | Point (IAP/Proxy)  |
                    +--------------------+
                              |
          +-------------------+-------------------+
          |                   |                   |
    +----------+        +----------+        +----------+
    | App A    |        | App B    |        | App C    |
    | (AWS)    |        | (Azure)  |        | (GCP)    |
    +----------+        +----------+        +----------+

ステップ 2：アイデンティティ認識型プロキシを導入する

リクエストがアプリケーションに到達する前に、アイデンティティとコンテキストに基づいてアクセス判断を強制するよう、Identity-Aware Proxy（IAP）を設定します。アプリケーションのバックエンドへの直接的なネットワークアクセスをなくします。

# GCP: Enable Identity-Aware Proxy for a backend service
gcloud services enable iap.googleapis.com

# Configure IAP for an App Engine application
gcloud iap web enable --resource-type=app-engine

# Set IAP access policy requiring specific user group
gcloud iap web add-iam-policy-binding \
  --resource-type=app-engine \
  --member="group:[email protected]" \
  --role="roles/iap.httpsResourceAccessor"

# Create Access Level requiring corporate device and MFA
gcloud access-context-manager levels create corporate-device \
  --title="Corporate Device with MFA" \
  --basic-level-spec='{
    "conditions": [
      {
        "devicePolicy": {
          "requireScreenlock": true,
          "allowedEncryptionStatuses": ["ENCRYPTED"],
          "osConstraints": [
            {"osType": "DESKTOP_CHROME_OS", "minimumVersion": "100.0"},
            {"osType": "DESKTOP_MAC", "minimumVersion": "12.0"},
            {"osType": "DESKTOP_WINDOWS", "minimumVersion": "10.0.19041"}
          ]
        },
        "requiredAccessLevels": ["accessPolicies/POLICY_ID/accessLevels/require-mfa"]
      }
    ]
  }'

# AWS: Configure AWS Verified Access for zero trust application access
aws ec2 create-verified-access-instance \
  --description "Zero Trust Access Instance"

aws ec2 create-verified-access-trust-provider \
  --trust-provider-type user \
  --user-trust-provider-type oidc \
  --oidc-options '{
    "Issuer": "https://company.okta.com/oauth2/default",
    "AuthorizationEndpoint": "https://company.okta.com/oauth2/default/v1/authorize",
    "TokenEndpoint": "https://company.okta.com/oauth2/default/v1/token",
    "UserInfoEndpoint": "https://company.okta.com/oauth2/default/v1/userinfo",
    "ClientId": "verified-access-client-id",
    "ClientSecret": "verified-access-client-secret",
    "Scope": "openid profile groups"
  }'

ステップ 3：継続的な検証を実装する

アイデンティティ、デバイスのセキュリティ状態、場所、行動パターン、脅威インテリジェンスのシグナルに基づき、すべてのアクセスリクエストを評価するリアルタイムのリスク評価を設定します。

# Azure Conditional Access Policy (JSON representation)
{
  "displayName": "Zero Trust - Require MFA and Compliant Device",
  "state": "enabled",
  "conditions": {
    "users": {"includeUsers": ["All"]},
    "applications": {"includeApplications": ["All"]},
    "locations": {
      "includeLocations": ["All"],
      "excludeLocations": ["AllTrusted"]
    },
    "signInRiskLevels": ["medium", "high"],
    "deviceStates": {
      "includeStates": ["All"],
      "excludeStates": ["Compliant", "DomainJoined"]
    }
  },
  "grantControls": {
    "operator": "AND",
    "builtInControls": [
      "mfa",
      "compliantDevice"
    ]
  },
  "sessionControls": {
    "signInFrequency": {"value": 4, "type": "hours"},
    "persistentBrowser": {"mode": "never"}
  }
}

ステップ 4：マイクロセグメンテーションを強制する

クラウドワークロードを分離されたゾーンにセグメント化し、各通信経路に明示的な許可ルールを設定することで、ネットワークレベルのゼロトラストを適用します。

# AWS: Create isolated VPC with no default routes
aws ec2 create-vpc --cidr-block 10.100.0.0/16 --no-amazon-provided-ipv6-cidr-block

# Create security groups implementing micro-segmentation
aws ec2 create-security-group \
  --group-name web-tier-sg \
  --description "Web tier - accepts traffic from ALB only" \
  --vpc-id vpc-abc123

aws ec2 authorize-security-group-ingress \
  --group-id sg-web123 \
  --protocol tcp --port 8080 \
  --source-group sg-alb123

aws ec2 create-security-group \
  --group-name app-tier-sg \
  --description "App tier - accepts traffic from web tier only"

aws ec2 authorize-security-group-ingress \
  --group-id sg-app123 \
  --protocol tcp --port 8443 \
  --source-group sg-web123

ステップ 5：デバイスの信頼性評価を実装する

アクセスを許可する前にデバイスのセキュリティ状態を評価するため、エンドポイント検証を統合します。暗号化、OS のパッチ適用、エンドポイント保護を必須にします。

# Google Endpoint Verification with BeyondCorp
gcloud access-context-manager levels create managed-device \
  --title="Managed and Encrypted Device" \
  --basic-level-spec='{
    "conditions": [{
      "devicePolicy": {
        "requireScreenlock": true,
        "requireAdminApproval": true,
        "allowedEncryptionStatuses": ["ENCRYPTED"],
        "allowedDeviceManagementLevels": ["COMPLETE"]
      }
    }]
  }'

# Apply access level to IAP-protected resource
gcloud iap web set-iam-policy \
  --resource-type=backend-services \
  --service=web-app-backend \
  --condition='expression=accessPolicies/POLICY_ID/accessLevels/managed-device'

ステップ 6：継続的な分析で監視し、適応する

すべてのアクセス判断を監視し、異常を検知して、実際の使用パターンに基づきゼロトラストポリシーを継続的に改善するため、ロギングと分析を導入します。

# Export IAP access logs to BigQuery for analysis
gcloud logging sinks create iap-access-logs \
  bigquery.googleapis.com/projects/my-project/datasets/security_logs \
  --log-filter='resource.type="gce_backend_service" AND protoPayload.serviceName="iap.googleapis.com"'

# AWS Verified Access logs to CloudWatch
aws ec2 modify-verified-access-instance-logging-configuration \
  --verified-access-instance-id vai-abc123 \
  --access-logs '{
    "CloudWatchLogs": {"Enabled": true, "LogGroup": "/aws/verified-access/logs"},
    "S3": {"Enabled": true, "BucketName": "verified-access-logs"}
  }'

主な概念

用語	定義
ゼロトラスト	すべてのアクセスリクエストに継続的な認証、認可、暗号化を要求することで、暗黙の信頼をなくすセキュリティモデル
BeyondCorp	ネットワーク境界から個々のユーザーとデバイスへアクセス制御の対象を移す、Google のゼロトラスト実装
Identity-Aware Proxy	バックエンドアプリケーションにリクエストを転送する前にユーザーのアイデンティティとコンテキストを検証し、VPN ベースのアクセスに代わるリバースプロキシ
継続的な検証	初回認証時だけでなく、すべてのアクセスリクエストについて、アイデンティティ、デバイスのセキュリティ状態、場所、行動をリアルタイムで評価すること
デバイスの信頼性	アクセスを許可する前に、暗号化の状態、OS のバージョン、パッチレベル、MDM への準拠状況など、エンドポイントのセキュリティ状態を評価すること
NIST SP 800-207	ゼロトラストアーキテクチャの原則と導入モデルを定義する、米国国立標準技術研究所の刊行物
Access Context Manager	デバイス属性、IP 範囲、アイデンティティのプロパティに基づく条件付きアクセス ポリシーを定義する GCP サービス
AWS Verified Access	VPN を使用せず、アイデンティティとデバイスの信頼性を示すシグナルに基づいてゼロトラストのアプリケーションアクセスを提供する AWS サービス

ツールとシステム

• Google BeyondCorp Enterprise：Identity-Aware Proxy、Access Context Manager、Endpoint Verificationを備えたエンドツーエンドのゼロトラストプラットフォーム
• AWS Verified Access：IDプロバイダーおよびデバイス信頼サービスと連携する、ゼロトラストのアプリケーションアクセスサービス
• Azure Conditional Access：Azure ADアプリケーションに対する、ID、デバイス、場所、リスクに基づいたアクセス制御を適用するポリシーエンジン
• Zscaler Private Access：VPNを置き換え、IDとコンテキストに基づくアプリケーションアクセスを提供するゼロトラストのネットワークアクセスプラットフォーム
• Cloudflare Access：ID確認とデバイスの状態チェックにより内部アプリケーションを保護するゼロトラストプロキシ

よくあるシナリオ

シナリオ：リモートエンジニアのアクセスにVPNを不要にする

背景：ある組織では、500人のエンジニアがVPN経由で内部ツールにアクセスしています。VPNコンセントレーターは単一障害点となっており、最近発生した認証情報の窃取事件から、VPNアクセスによって過剰な水平移動が可能になることが明らかになりました。

アプローチ：

1. VPN経由でアクセスされるすべての内部アプリケーションを洗い出し、機密性レベル別に分類します
2. 各アプリケーションの前段にIdentity-Aware Proxy（GCP）またはVerified Access（AWS）を導入します
3. すべてのアクセスでMFAを必須にするよう、企業のIDプロバイダーとのOIDC連携を設定します
4. デバイスの暗号化、最新のOSパッチ、およびエンドポイント保護を必須とするデバイス信頼ポリシーを導入します
5. 機密性の高いアプリケーションでは4時間ごとの再認証を含む、継続的なセッション評価を有効にします
6. アクセス障害を監視し、ポリシーを調整しながら、チームをVPNからIAPアクセスへ段階的に移行します
7. 100％の移行と30日間の並行運用期間を経て、VPNを廃止します

注意点：デバイス管理が整っていない状態でゼロトラストを導入すると、個人所有デバイスを使う正規ユーザーがブロックされます。再認証の間隔を短く設定しすぎると、ログイン要求が頻発して開発者の生産性を損ないます。

出力形式

Zero Trust Architecture Assessment Report
===========================================
Organization: Acme Corp
Cloud Providers: AWS, Azure, GCP
Assessment Date: 2025-02-23

MATURITY LEVEL: Level 2 (Advanced) - NIST ZTA Maturity Model

IDENTITY PILLAR:
  MFA Enforcement: 98% of users (target: 100%)
  Phishing-Resistant MFA: 34% (target: 80%)
  SSO Coverage: 87% of applications
  Conditional Access Policies: 12 active policies

DEVICE PILLAR:
  MDM Enrollment: 92% of corporate devices
  Encryption Enforcement: 95%
  OS Patch Compliance: 78% (30-day window)
  Endpoint Protection: 96%

NETWORK PILLAR:
  VPN Dependency: 3 applications remaining (target: 0)
  IAP-Protected Applications: 47/50
  Micro-Segmented Workloads: 65%
  East-West Traffic Encryption: 40% (mTLS adoption)

APPLICATION PILLAR:
  Applications Behind Zero Trust Proxy: 94%
  Session Re-Authentication: Configured for 85% of apps
  Runtime Access Logging: 100%

RECOMMENDATIONS:
  1. [HIGH] Migrate remaining 3 VPN-dependent apps to IAP
  2. [HIGH] Increase phishing-resistant MFA to 80% within 6 months
  3. [MEDIUM] Expand micro-segmentation to remaining 35% of workloads
  4. [MEDIUM] Deploy service mesh for east-west mTLS encryption