Zero Trustアーキテクチャ完全ガイド2025：Never Trust Always Verify、BeyondCorp、SASE

従来の境界セキュリティモデル：

  [インターネット] ── [ファイアウォール] ── [内部ネットワーク (信頼ゾーン)]
     │                                          │
   不信ゾーン                               全て信頼される
     │                                          │
  VPNでのみ                              自由な横移動
   アクセス可能                          (Lateral Movement)

侵害パターン（境界セキュリティの失敗）：

1. 初期侵入
   フィッシングメール → 1名の従業員のアカウント奪取

2. 横移動（Lateral Movement）
   信頼された内部ネットワーク内で自由に移動
   → 他のサーバー、DBに無制限アクセス

3. 権限昇格
   内部ネットワークのため追加認証なし
   → 管理者権限を取得

4. データ漏洩
   内部から外部への通信は緩く管理
   → 大量データ流出

Zero Trust基本原則：

┌─────────────────────────────────────────────────┐
│              Zero Trust Architecture             │
│                                                  │
│  1. 明示的検証（Verify Explicitly）              │
│     → 全てのアクセス要求を認証＋認可             │
│     → ユーザー、デバイス、場所、行動パターン検証 │
│                                                  │
│  2. 最小権限（Least Privilege Access）            │
│     → 必要最小限の権限のみ付与                   │
│     → Just-In-Time、Just-Enough-Access           │
│                                                  │
│  3. 侵害想定（Assume Breach）                    │
│     → 既に内部が侵害されたと仮定                │
│     → 爆発半径（Blast Radius）の最小化           │
│     → マイクロセグメンテーションで隔離           │
└─────────────────────────────────────────────────┘

NIST 800-207 Zero Trust Architecture：

  [ユーザー/デバイス]
        │
        ▼
  ┌──────────────┐     ┌──────────────────────┐
  │  PEP         │────▶│  PDP (Policy Engine)  │
  │  Policy      │◀────│  + Policy Admin       │
  │  Enforcement │     │                       │
  │  Point       │     │  判断基準：            │
  └──────┬───────┘     │  - ユーザーID         │
         │             │  - デバイス状態        │
         ▼             │  - ネットワーク位置    │
  ┌──────────────┐     │  - 要求リソース        │
  │  Enterprise  │     │  - 時間/行動パターン   │
  │  Resources   │     └──────────────────────┘
  └──────────────┘              │
                                ▼
                    ┌──────────────────────┐
                    │  データソース：        │
                    │  - CDM (資産管理)     │
                    │  - Threat Intel       │
                    │  - Activity Logs      │
                    │  - Compliance         │
                    │  - SIEM/SOAR          │
                    └──────────────────────┘

# Policy Engine 意思決定例
policy_evaluation:
  input:
    user: "engineer@company.com"
    device_trust_score: 85
    location: "Japan"
    resource: "production-database"
    time: "2025-03-15T14:30:00Z"
    mfa_verified: true
    risk_score: "low"

  rules:
    - name: "prod-db-access"
      conditions:
        - user.role IN ["sre", "dba"]
        - device.trust_score >= 80
        - device.os_patched == true
        - mfa.verified == true
        - risk.score IN ["low", "medium"]
      action: "allow"
      session_controls:
        max_duration: "4h"
        require_reauthentication: true
        log_all_queries: true

  decision: "ALLOW with session controls"

PEP動作フロー：

  リクエスト → [PEP] → ポリシー確認要求 → [PDP]
                                             │
                                    許可/拒否の決定
                                             │
               [PEP] ← 決定受信 ←────────────┘
                 │
            許可時 → リソースアクセス（暗号化チャネル）
            拒否時 → アクセスブロック + ログ記録

CISA Zero Trust成熟度モデル：

Level 1: Traditional（従来型）
├── 静的セキュリティポリシー
├── 手動プロビジョニング
└── 限定的な可視性

Level 2: Advanced（高度化）
├── 一部自動化されたポリシー
├── 集中化されたID管理
└── 基本的な分析

Level 3: Optimal（最適）
├── 完全自動化されたポリシー
├── 継続的検証
├── AI/MLベースの分析
└── 動的ポリシー適用

5つのコア領域：
┌────────────┬────────────┬────────────┬────────────┬────────────┐
│  Identity  │  Devices   │  Networks  │   Apps/    │   Data     │
│            │            │            │  Workloads │            │
├────────────┼────────────┼────────────┼────────────┼────────────┤
│ MFA, SSO   │ MDM, EDR   │ Micro-     │ SDLC       │ 分類、     │
│ Conditional│ デバイス   │ Segment    │ DAST/SAST  │ DLP、      │
│ Access     │ インベン   │ 暗号化     │ Runtime    │ 暗号化     │
└────────────┴────────────┴────────────┴────────────┴────────────┘

BeyondCorpコア原則：

1. ネットワーク位置で信頼を決定しない
   → 会社オフィス = カフェWi-Fi（同等に扱う）

2. アクセス権限はユーザー＋デバイスによって決定
   → 誰（Who）＋ 何のデバイス（What）＋ どんな状態（Health）

3. 全てのアクセスは認証、認可、暗号化
   → VPN不要。インターネット経由で直接アクセス

4. アクセスポリシーは動的で継続的に評価
   → 一度の認証で終わらない

BeyondCorp Architecture：

  [従業員デバイス]
       │
       │（インターネット - どこからでも）
       ▼
  ┌──────────────────┐
  │  Access Proxy     │ ← 全リクエストの入口
  │  (Identity-Aware  │
  │   Proxy)          │
  └────────┬─────────┘
           │
    ┌──────┴──────┐
    ▼              ▼
┌────────┐   ┌────────────┐
│ Access │   │ Device     │
│ Control│   │ Inventory  │
│ Engine │   │ Service    │
└───┬────┘   └─────┬──────┘
    │              │
    ▼              ▼
┌────────────────────────┐
│  Trust Evaluation       │
│                         │
│  User Identity ────────┤
│  Device State ─────────┤
│  Access Policy ────────┤
│  Context (time, loc) ──┤
│                         │
│  → Trust Score算出      │
│  → アクセス許可/拒否    │
└────────────────────────┘

# GCP IAP設定例
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: iap-backend-config
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: iap-oauth-secret
  securityPolicy:
    name: "rate-limit-policy"
  healthCheck:
    requestPath: /healthz
    port: 8080

# IAPを通じたアクセス検証（サーバーサイド）
from google.auth.transport import requests
from google.oauth2 import id_token

def verify_iap_jwt(iap_jwt, expected_audience):
    """IAP JWTトークンを検証してユーザーIDを返す"""
    try:
        decoded_jwt = id_token.verify_token(
            iap_jwt,
            requests.Request(),
            audience=expected_audience,
            certs_url="https://www.gstatic.com/iap/verify/public_key"
        )
        return {
            "email": decoded_jwt["email"],
            "sub": decoded_jwt["sub"],
            "access_levels": decoded_jwt.get("google", {}).get(
                "access_levels", []
            )
        }
    except Exception as e:
        print(f"JWT verification failed: {e}")
        return None

# アクセスレベルベースのポリシー適用
def check_access_policy(user_info, resource):
    """ユーザーのアクセスレベルとリソースポリシーを比較"""
    required_levels = get_resource_policy(resource)
    user_levels = set(user_info.get("access_levels", []))

    if required_levels.issubset(user_levels):
        return True
    return False

GoogleのBeyondCorp移行プロセス（約8年）：

Phase 1: 可視性の確保（Visibility）
├── 全デバイスインベントリの構築
├── 全ユーザーアクセスパターンの分析
└── 既存VPNトラフィックのモニタリング

Phase 2: アクセスプロキシの構築
├── Identity-Aware Proxyのデプロイ
├── 内部アプリケーションをプロキシ背後に移動
└── 証明書ベースのデバイス認証

Phase 3: ポリシーエンジンの構築
├── 動的アクセスポリシーの定義
├── デバイス信頼スコアシステム
└── コンテキストベースのアクセス制御

Phase 4: VPNの廃止
├── 段階的なVPNトラフィック削減
├── 全アプリをプロキシベースに移行
└── VPN完全廃止

Phase 5: 継続的改善
├── MLベースの異常検知
├── リアルタイムリスク評価
└── 自動対応（SOAR統合）

現代的IAMアーキテクチャ：

  ┌─────────────────────────────────────────┐
  │           Identity Provider (IdP)        │
  │                                          │
  │  ┌──────────┐  ┌──────────┐  ┌────────┐│
  │  │ User     │  │ Directory│  │ MFA    ││
  │  │ Store    │  │ Service  │  │ Engine ││
  │  │ (DB)     │  │ (LDAP/   │  │        ││
  │  │          │  │  SCIM)   │  │        ││
  │  └──────────┘  └──────────┘  └────────┘│
  │                                          │
  │  ┌──────────┐  ┌──────────┐  ┌────────┐│
  │  │ SSO      │  │ OAuth2/  │  │ Risk   ││
  │  │ Engine   │  │ OIDC     │  │ Engine ││
  │  │ (SAML)   │  │ Server   │  │        ││
  │  └──────────┘  └──────────┘  └────────┘│
  └─────────────────────────────────────────┘
           │              │
      ┌────┴────┐    ┌───┴────┐
      ▼         ▼    ▼        ▼
   [SaaS]   [Internal] [Cloud]  [API]
    Apps      Apps      Infra   Services

# 条件付きアクセスポリシーエンジン実装例
from dataclasses import dataclass
from enum import Enum

class RiskLevel(Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"

@dataclass
class AccessContext:
    user_id: str
    user_role: str
    device_compliant: bool
    device_managed: bool
    mfa_completed: bool
    mfa_method: str  # "phishing_resistant", "push", "sms"
    location: str  # "corporate", "home", "unknown"
    ip_reputation: str  # "trusted", "suspicious", "malicious"
    risk_score: float  # 0.0 - 1.0
    resource_sensitivity: str

class ConditionalAccessEngine:
    def evaluate(self, ctx: AccessContext) -> dict:
        """アクセス要求を評価して決定を返す"""

        # Rule 1: 悪意あるIPは無条件ブロック
        if ctx.ip_reputation == "malicious":
            return self._deny("Malicious IP detected")

        # Rule 2: 制限リソースへのアクセス
        if ctx.resource_sensitivity == "restricted":
            if not ctx.mfa_completed:
                return self._step_up("Require MFA for restricted resource")
            if ctx.mfa_method != "phishing_resistant":
                return self._step_up("Require phishing-resistant MFA (FIDO2)")
            if not ctx.device_managed:
                return self._deny("Managed device required")

        # Rule 3: リスクスコアベースの動的ポリシー
        if ctx.risk_score > 0.8:
            return self._deny("Risk score too high")
        elif ctx.risk_score > 0.5:
            if not ctx.mfa_completed:
                return self._step_up("Elevated risk - MFA required")
            return self._allow_limited(session_duration="1h")

        # Rule 4: 非管理デバイス
        if not ctx.device_managed:
            if ctx.resource_sensitivity in ["confidential", "restricted"]:
                return self._deny("Managed device required")
            return self._allow_limited(
                session_duration="4h",
                block_download=True
            )

        return self._allow()

    def _allow(self):
        return {"decision": "allow", "session_duration": "8h"}

    def _allow_limited(self, **kwargs):
        return {"decision": "allow_limited", **kwargs}

    def _deny(self, reason: str):
        return {"decision": "deny", "reason": reason}

    def _step_up(self, reason: str):
        return {"decision": "step_up_auth", "reason": reason}

MFA強度ピラミッド：

   最強   ▲
          │  ┌─────────────────────────┐
          │  │  FIDO2/WebAuthn         │ ← ハードウェアキー (YubiKey)
          │  │  (フィッシング耐性)     │   パスキー (Passkey)
          │  └─────────────────────────┘
          │  ┌─────────────────────────┐
          │  │  証明書ベース           │ ← デバイス証明書
          │  │  (Certificate-based)    │   スマートカード
          │  └─────────────────────────┘
          │  ┌─────────────────────────┐
          │  │  アプリベース Push/TOTP │ ← Authenticatorアプリ
          │  │                         │   時間ベースOTP
          │  └─────────────────────────┘
          │  ┌─────────────────────────┐
   最弱   │  │  SMS/Email OTP          │ ← SIMスワッピング脆弱
          ▼  │  (フィッシング可能)     │   メール侵害時に無力化
             └─────────────────────────┘

# Okta条件付きMFA設定例
authentication_policies:
  - name: "High Security Resources"
    conditions:
      applications:
        - "production-admin"
        - "financial-systems"
        - "customer-data-platform"
    actions:
      require_mfa: true
      allowed_factors:
        - "fido2_webauthn"
        - "okta_verify_push"
      factor_lifetime: "1h"
      re_authentication_frequency: "every_request"

  - name: "Standard Resources"
    conditions:
      applications:
        - "email"
        - "chat"
        - "wiki"
    actions:
      require_mfa: true
      allowed_factors:
        - "fido2_webauthn"
        - "okta_verify_push"
        - "okta_verify_totp"
      factor_lifetime: "12h"

  - name: "Unknown Location Policy"
    conditions:
      network_zones:
        exclude:
          - "corporate_network"
          - "known_vpn_endpoints"
    actions:
      require_mfa: true
      allowed_factors:
        - "fido2_webauthn"
      session_lifetime: "4h"

Device Trust評価フロー：

  [デバイス] → エージェントが状態を収集
       │
       ▼
  ┌──────────────────────────────────┐
  │     Device Trust Signal          │
  │                                  │
  │  OSバージョン/パッチ状態 ── 20%  │
  │  ディスク暗号化 ────────── 15%  │
  │  ファイアウォール有効 ──── 10%  │
  │  EDRインストール/実行 ──── 20%  │
  │  MDM管理状態 ──────────── 15%  │
  │  証明書の有効性 ────────── 10%  │
  │  最近のセキュリティスキャン 10%  │
  │                                  │
  │  → Trust Score: 0-100            │
  └──────────────────────────────────┘
       │
       ▼
  アクセスポリシーにTrust Scoreを反映
  Score >= 80 → フルアクセス
  Score >= 60 → 制限付きアクセス
  Score < 60  → ブロック + 案内

# Microsoft Intuneコンプライアンスポリシー例
compliance_policy:
  name: "Zero Trust Device Compliance"
  platforms:
    - windows
    - macos
    - ios
    - android

  windows_rules:
    os_minimum_version: "10.0.19045"  # Windows 10 22H2+
    bitlocker_required: true
    secure_boot_required: true
    tpm_required: true
    firewall_required: true
    antivirus_required: true

  macos_rules:
    os_minimum_version: "14.0"  # Sonoma+
    filevault_required: true
    firewall_required: true
    gatekeeper_required: true
    system_integrity_protection: true

  non_compliance_actions:
    - action: "notify_user"
      grace_period_hours: 0
    - action: "mark_non_compliant"
      grace_period_hours: 24
    - action: "block_access"
      grace_period_hours: 72
    - action: "retire_device"
      grace_period_hours: 720  # 30日

セグメンテーションの進化：

1. 従来型：VLANベース
   ┌──────────┐  ┌──────────┐  ┌──────────┐
   │  VLAN 10 │  │  VLAN 20 │  │  VLAN 30 │
   │  (開発)  │  │  (本番)  │  │  (DB)    │
   └──────────┘  └──────────┘  └──────────┘
   → 同じVLAN内で自由通信（問題！）

2. ファイアウォールベース：ゾーンセグメンテーション
   ┌──────────┐     ┌──────────┐
   │  Trust   │─FW─▶│  DMZ     │─FW─▶ Internet
   │  Zone    │     │  Zone    │
   └──────────┘     └──────────┘
   → ゾーン間制御、ゾーン内自由（不十分）

3. マイクロセグメンテーション：ワークロードレベル
   ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐
   │A │─│B │ │C │─│D │ │E │
   └──┘ └──┘ └──┘ └──┘ └──┘
     │         │
     └────X────┘  ← AとC間の通信をブロック
   → ワークロード間の個別ポリシー（理想的）

# 1. デフォルトポリシー：全トラフィック拒否（Default Deny）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# 2. フロントエンド → バックエンドAPIのみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080
---
# 3. バックエンドAPI → DBのみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend-api
      ports:
        - protocol: TCP
          port: 5432
---
# 4. DNSアクセス許可（全Pod）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

# Istio PeerAuthentication：メッシュ全体にmTLSを強制
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # mTLS必須。平文トラフィック拒否
---
# AuthorizationPolicy：サービス間アクセス制御
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
    # Rule 1: order-serviceのみ決済API呼び出し許可
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/order-service"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/v1/payments", "/api/v1/payments/*"]
    # Rule 2: モニタリングサービスはヘルスチェックのみ許可
    - from:
        - source:
            principals:
              - "cluster.local/ns/monitoring/sa/prometheus"
      to:
        - operation:
            methods: ["GET"]
            paths: ["/health", "/metrics"]
  # 残りの全アクセスは暗黙的に拒否

VPN（従来型）：

  [ユーザー] ──VPNトンネル──▶ [会社ネットワーク全体にアクセス]
                                    │
                          全内部リソースが露出
                          （不要なサーバーも見える）

ZTNA（Zero Trust）：

  [ユーザー] ──暗号化チャネル──▶ [許可されたアプリAのみアクセス]
                                      │
                            残りのネットワークは見えない
                            （Dark Cloud原則）

# Cloudflare Accessポリシー例
application:
  name: "Internal Dashboard"
  domain: "dashboard.company.com"
  type: "self_hosted"

  identity_providers:
    - name: "Okta"
      type: "saml"
    - name: "GitHub"
      type: "oauth"

  policies:
    - name: "Allow Engineering"
      decision: "allow"
      include:
        - group: "engineering@company.com"
      require:
        - mfa: true
        - device_posture:
            - serial_number_check: true
            - disk_encryption: true
            - os_version:
                operator: ">="
                version: "14.0"

    - name: "Block Countries"
      decision: "block"
      include:
        - country:
            - "KP"
            - "IR"
            - "SY"

  session_duration: "12h"

SASE = ネットワーク(SD-WAN) + セキュリティ(SSE)をクラウドで統合

  ┌─────────────────────────────────────────────────────┐
  │                    SASE Platform                     │
  │                                                      │
  │  ┌─────────────────┐  ┌──────────────────────────┐  │
  │  │   SD-WAN         │  │   SSE (Security)          │  │
  │  │                  │  │                           │  │
  │  │  - WAN最適化     │  │  - ZTNA                  │  │
  │  │  - トラフィック  │  │  - CASB                  │  │
  │  │    制御          │  │  - SWG                   │  │
  │  │  - QoS           │  │  - FWaaS                 │  │
  │  │  - マルチリンク  │  │  - DLP                   │  │
  │  └─────────────────┘  └──────────────────────────┘  │
  │                                                      │
  │  ┌──────────────────────────────────────────────┐   │
  │  │  共通：統合ポリシー、統合コンソール、API統合  │   │
  │  └──────────────────────────────────────────────┘   │
  └─────────────────────────────────────────────────────┘
         │              │              │
    ┌────┴────┐   ┌────┴────┐   ┌────┴────┐
    │ 本社    │   │ 支社    │   │ リモート│
    └─────────┘   └─────────┘   └─────────┘

Kubernetes Zero Trustレイヤー：

Layer 1: クラスターアクセス
├── RBAC (Role-Based Access Control)
├── OIDC認証 (kubectl + IdP)
├── Admission Control (OPA/Kyverno)
└── API Server Audit Logging

Layer 2: Pod間通信
├── NetworkPolicy (基本L3/L4)
├── Service Mesh mTLS (L7)
├── DNS Policy
└── Egress Control

Layer 3: ワークロードアイデンティティ
├── ServiceAccount Token (Projected)
├── SPIFFE/SPIRE
├── Workload Identity Federation
└── Secret Management (Vault)

Layer 4: データ保護
├── Encryption at Rest (etcd)
├── Encryption in Transit (TLS)
├── Secret Encryption (KMS)
└── PodSecurity Standards

# OPA Gatekeeper：Pod Security強制
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredsecuritycontext
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredSecurityContext
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredsecuritycontext

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.runAsNonRoot
          msg := sprintf(
            "Container '%v' must set runAsNonRoot to true",
            [container.name]
          )
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not container.securityContext.readOnlyRootFilesystem
          msg := sprintf(
            "Container '%v' must set readOnlyRootFilesystem",
            [container.name]
          )
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          container.securityContext.privileged
          msg := sprintf(
            "Container '%v' must not be privileged",
            [container.name]
          )
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredSecurityContext
metadata:
  name: must-have-security-context
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces:
      - "production"
      - "staging"
  enforcementAction: deny

SPIFFE/SPIREアーキテクチャ：

  ┌──────────────────────────────┐
  │       SPIRE Server           │
  │                              │
  │  - CA（証明書発行）          │
  │  - Registration API          │
  │  - Node/Workload Attestation │
  └──────────┬───────────────────┘
             │
    ┌────────┴────────┐
    ▼                 ▼
┌──────────┐   ┌──────────┐
│  SPIRE   │   │  SPIRE   │
│  Agent   │   │  Agent   │
│ (Node 1) │   │ (Node 2) │
└────┬─────┘   └────┬─────┘
     │               │
  ┌──┴──┐         ┌──┴──┐
  │Pod A│         │Pod C│
  │Pod B│         │Pod D│
  └─────┘         └─────┘

  各PodはSVID (SPIFFE Verifiable Identity Document)を受け取る：
  spiffe://company.com/ns/production/sa/payment-service

Phase 1: 可視性の確保（1-3ヶ月）
├── 資産インベントリ（ユーザー、デバイス、アプリ、データ）
├── ネットワークフローマッピング
├── アクセスパターン分析
├── 現在のセキュリティギャップ評価
└── 成功指標（KPI）の定義

Phase 2: アイデンティティ基盤（3-6ヶ月）
├── 集中化されたIdPの構築/統合
├── SSO実装（SAML/OIDC）
├── MFA全社展開
├── 条件付きアクセスポリシー
└── デバイス登録と管理

Phase 3: ネットワークセグメンテーション（6-12ヶ月）
├── マイクロセグメンテーション設計
├── East-Westトラフィック制御
├── DNSセキュリティ
├── 暗号化通信（mTLS）
└── ZTNAパイロット（VPN置換開始）

Phase 4: ワークロードセキュリティ（12-18ヶ月）
├── アプリケーションレベルのアクセス制御
├── APIセキュリティ（認証、レート制限）
├── データ分類とDLP
├── CI/CDパイプラインセキュリティ
└── ランタイムセキュリティ（CWPP）

Phase 5: 自動化と最適化（18-24ヶ月）
├── SOAR統合（自動対応）
├── MLベースの異常検知
├── 継続的コンプライアンスモニタリング
├── 自動ポリシー最適化
└── VPN完全廃止

zero_trust_kpis:
  identity:
    - metric: "MFA適用率"
      target: "100%"
    - metric: "フィッシング耐性MFA（FIDO2）比率"
      target: ">= 80%"
    - metric: "SSO適用アプリ比率"
      target: ">= 95%"

  device:
    - metric: "管理デバイス比率"
      target: ">= 95%"
    - metric: "パッチ適用SLA遵守率"
      target: ">= 90%"

  network:
    - metric: "マイクロセグメンテーション適用率"
      target: ">= 80%"
    - metric: "mTLS適用サービス比率"
      target: ">= 95%"
    - metric: "VPNユーザー数"
      target: "0（ZTNAに完全移行）"

  incident:
    - metric: "横移動検知時間"
      target: "< 1時間"
    - metric: "MTTD (Mean Time To Detect)"
      target: "< 24時間"

Zero Trust実装時のよくある間違い：

1. 「VPNをZTNAに置き換えれば完了」という考え
   → Zero Trustは製品ではなく戦略
   → ネットワーク、ID、デバイス、アプリ、データ全層が必要

2. 一度に全てを変えようとする試み
   → 段階的な移行が必須
   → 最もリスクの高いものから優先適用

3. ユーザー体験の無視
   → セキュリティが不便すぎると回避行動が発生
   → SSO + パスキーでセキュリティと利便性を両立

4. 「内部 = 信頼」の前提がコードに埋め込まれている
   → IPベースのアクセス制御をIDベースに移行が必要
   → レガシーアプリのマイグレーション計画を策定

5. 可視性なしでポリシーを適用
   → まずモニタリングモードでトラフィックを把握
   → その後段階的にブロックポリシーを適用

6. DevOps/CI-CDパイプラインの見落とし
   → サービスアカウント、APIキーもZero Trustの対象
   → Workload Identityの導入