VPNレス Zero Trust ネットワークアクセス制御の実現
概要
Verified Access が解決する課題
主な特徴
アーキテクチャ
Zero Trust Network Access（ZTNA）の概念
コアコンポーネント
主要ユースケース（12+）
設定・操作の具体例
類似サービス比較表
ベストプラクティス・チェックリスト
2025-2026 最新動向
学習リソース・参考文献
実装チェックリスト
まとめ

AWS Verified Access 完全ガイド v2.0

VPNレス Zero Trust ネットワークアクセス制御の実現

AWS Verified Access は、VPN レスで社内アプリケーションへの Zero Trust Network Access（ZTNA）を実現するフルマネージドサービスです。各リクエストごとにアイデンティティ（IAM Identity Center・Okta・Azure AD）とデバイスセキュリティ状態（CrowdStrike・Jamf・JumpCloud）を検証し、アプリケーション単位の最小権限アクセス制御（Cedar ポリシー）を実行します。Application Load Balancer・Network Load Balancer・EC2 インスタンス・オンプレミスアプリを保護。2025-2026 年には 非 HTTP リソース（RDS・SSH・TCP）への拡張対応、AWS WorkSpaces 統合強化、AI 駆動の Zero Trust 推奨設定など、組織の「VPN 廃止」「ラテラルムーブメント防止」を加速する最新動向を網羅した完全リファレンスです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： VPN と Verified Access の違い、Zero Trust の概念を学びたい方
セキュリティエンジニア向け： Trust Provider・Endpoint Policy・Device Posture 設定の実装
ネットワークアーキテクト向け： ALB / NLB / PrivateLink 統合アーキテクチャ設計
CISO / 情報セキュリティ責任者向け： VPN 廃止ロードマップ・Zero Trust 組織移行戦略
意思決定者向け： Cloudflare Zero Trust・Tailscale・Twingate・Zscaler との比較・投資判断

2025-2026 年の Verified Access エコシステム

非 HTTP リソース対応（GA: 2025 年 5 月）: RDS・SSH・TCP ベースリソースへの VPN レスアクセス拡大
AWS WorkSpaces 統合強化: Desktop Streaming + Verified Access でエンタープライズワークスペース完全 VPN レス化
Zero Trust 2026 トレンド: 60% の組織が VPN から ZTNA への移行を計画
Device Posture 評価強化: CrowdStrike Falcon・Jamf MDM との深い統合。暗号化・OS バージョン・脆弱性スキャン等をリアルタイム検証
Cedar ポリシー統合: Verified Permissions の Cedar ポリシーエンジンと統合。アプリケーション単位の微細な ABAC ポリシー定義が可能
PrivateLink 深化: AWS PrivateLink を経由した保護されたトランスポート・多層検証が標準化

概要

初心者向けメモ： VPN の代わりに Verified Access を使う理由は「セキュリティと利便性」です。

従来の VPN:
    VPN 接続 → 社内ネットワーク全体へのアクセス可能
    → 一度つながれば、広い範囲にアクセス（横展開リスク高い）
    → VPN ライセンス・デバイス管理コスト高い

Verified Access（Zero Trust）:
    ユーザー・デバイス検証 → アプリごとに許可判定
    → 許可されたアプリのみアクセス可能
    → VPN 不要。リモートワークでもセキュア。管理負荷も低い

Verified Access が実現する価値

価値	説明
VPN 廃止	VPN ライセンス・デバイス管理コスト削減。ユーザー満足度向上（VPN 遅延解消）
Zero Trust	毎回アイデンティティ・デバイス検証。ラテラルムーブメント防止。最小権限アクセス
デバイス信頼度検証	CrowdStrike・Jamf と統合。マルウェア感染・セキュリティパッチ未適用デバイス自動ブロック
アプリ単位制御	Cedar ポリシーで「このユーザーはこのアプリのみ」と制御。ロール・時間帯・リソース属性ベースも可
ハイブリッド対応	AWS・オンプレミス・SaaS アプリ全てに対応。複数クラウドへの統一アクセス制御

Verified Access が解決する課題

1. VPN の運用負荷・セキュリティリスク

課題：

従来 VPN 環境:
    • VPN デバイス・ライセンスの購入・保守
    • VPN キー・証明書の更新・配布
    • VPN 接続数の監視・容量管理
    • VPN に一度つながれば社内 LAN 全体へアクセス可能
      → 侵害されたノートパソコンが社内を横断移動（ラテラルムーブメント）
    • VPN ユーザー数増加時の追加投資

Verified Access の解決：

VPN レス Zero Trust:
    • VPN デバイス不要。サーバーレス
    • オンデマンド・スケール。インフラ投資不要
    • アプリごとの検証。全社内ネットワークへのアクセスは不可
      → 特定アプリへのアクセスのみ
    • デバイス侵害検知時、アプリアクセス即座にブロック
    • ユーザー・デバイス情報のみで管理可能

2. リモートワークでの多様なデバイス・ネットワークへの対応

課題： 自宅・カフェ・移動中など、安全性が保証されないネットワークからのアクセス。個人 PC・BYOD デバイスの管理が困難。

Verified Access の解決：

ネットワークの安全性に依存しない。各リクエストで個人認証・デバイス状態を検証
Jamf（Mac）・Intune（Windows）・JumpCloud（Linux）と統合。デバイス OS・ファイアウォール・暗号化状態を検証

3. 買収企業の一時的なアクセス付与の複雑性

課題： M&A で子会社社員を本社システムにアクセスさせる場合、VPN 設定・ネットワーク構築が数週間。逆に期間終了時のアクセス削除漏れリスク。

Verified Access の解決：

子会社ユーザーを IAM Identity Center に登録（一時ユーザー）
→ Verified Access ポリシーで「3 ヶ月間のみアクセス」と期限設定
→ 期限自動失効 → 管理者による手動削除不要

4. エンドポイント・アプリケーション単位のセキュリティ制御の欠落

課題： VPN に接続すれば社内全体。「このユーザーはこのアプリの読み取りのみ」という制御が VPN では困難。

Verified Access の解決： Cedar ポリシーでアプリケーション単位・アクション単位の最小権限制御が可能。

主な特徴

特徴	説明
VPN 不要	VPN デバイス・ライセンス廃止。HTTPS・TCP で直接アプリアクセス
Zero Trust	毎回リクエストごとにアイデンティティ・デバイス検証
Trust Provider 統合	IAM Identity Center・Okta・Azure AD・OIDC 対応
Device Posture	CrowdStrike・Jamf・JumpCloud・AWS Systems Manager とネイティブ統合
Cedar ポリシー	Verified Permissions のポリシーエンジン対応。微細な ABAC 制御
アプリケーション多様性	ALB・NLB・EC2・RDS・SSH・オンプレミスアプリ対応
PrivateLink	AWS PrivateLink 経由の暗号化・保護されたトランスポート
エンドポイント多層検証	ユーザー認証・デバイス健全性・リソース属性・時間帯等を複合判定
監査ログ	CloudTrail で全アクセス試行（許可・拒否）記録。HIPAA・PCI DSS 準拠
EventBridge 統合	アクセス拒否時に自動通知・対応可能

アーキテクチャ

┌──────────────────────────────────────────────────────────────┐
│ ユーザー（社外ネットワーク：自宅・カフェ・移動中）        │
│ • ノートパソコン（Windows / Mac）                          │
│ • スマートフォン（iOS / Android）                          │
└────────────────┬─────────────────────────────────────────┘
                 │ HTTPS / TCP（VPN 不要）
                 ▼
┌──────────────────────────────────────────────────────────────┐
│ AWS Verified Access エンドポイント                           │
├──────────────────────────────────────────────────────────────┤
│ • アイデンティティ検証:                                     │
│   ├─ IAM Identity Center: SAML・OIDC JWT 検証              │
│   ├─ Okta / Azure AD: OAuth 2.0 認可コード取得・検証       │
│   └─ OIDC Provider: 任意の OIDC Provider 対応              │
│                                                             │
│ • Device Posture 評価（毎リクエスト実施）:                 │
│   ├─ CrowdStrike Falcon: エージェント状態・脅威スコア      │
│   ├─ Jamf: Mac デバイス OS バージョン・セキュリティ更新    │
│   ├─ JumpCloud: Linux デバイスディスク暗号化・ファイアウォ│
│   └─ AWS SSM: EC2 パッチコンプライアンス                  │
│                                                             │
│ • Cedar ポリシー評価:                                       │
│   ├─ 「このユーザーはこのアプリへアクセス可能か」          │
│   ├─ 「操作は読み取りのみか、書き込みか」                  │
│   ├─ 「現在時刻が営業時間か」                              │
│   └─ 「IP レンジは許可対象か」                             │
│                                                             │
│ • 結果: Allow / Deny 判定                                  │
│   ├─ Allow: バックエンドへ転送                             │
│   └─ Deny: HTTP 403・カスタムエラーページ返却              │
└────────────┬──────────────────────────────────────┬────────┘
             │ Allow                                 │ Deny
             ▼                                       ▼
┌──────────────────────────────┐      ┌──────────────────────┐
│ バックエンドアプリケーション  │      │ 拒否ログ             │
├──────────────────────────────┤      ├──────────────────────┤
│ • ALB（HTTP/HTTPS）           │      │ EventBridge 通知     │
│ • NLB（TCP/UDP）              │      │ CloudTrail 記録      │
│ • EC2 アプリケーション        │      │ Slack 即座通知       │
│ • RDS（ポート 5432 等）        │      │ → 管理者対応         │
│ • SSH（ポート 22）             │      └──────────────────────┘
│ • Custom TCP アプリ            │
│ • オンプレミスアプリ           │
│  （AWS PrivateLink 経由）     │
│                              │
│ 認証・認可は VA が実施済み    │
│ バックエンド側で再検証不要     │
└──────────────────────────────┘

信頼チェーン:
ユーザー デバイス
    ↓（検証）
IAM Identity Center / Okta → JWT 生成
    ↓（検証）
CrowdStrike / Jamf → Device Posture 評価
    ↓（検証）
Cedar ポリシー → ビジネスロジック判定
    ↓
Allow / Deny 決定 → CloudTrail 記録 → SLA 監査証跡

Zero Trust Network Access（ZTNA）の概念

VPN モデル vs ZTNA（Verified Access）

┌──────────────────────────────┬──────────────────────────────┐
│ 従来 VPN（城と堀モデル）      │ ZTNA（Verified Access）     │
├──────────────────────────────┼──────────────────────────────┤
│ 境界内/外：二分法             │ すべてのリクエスト検証       │
│ → VPN 接続 → 全社内可視域    │ → ユーザー・デバイス毎回   │
│                              │                              │
│ チェック：初回のみ            │ チェック：毎リクエスト      │
│ → VPN パスワード・証明書      │ → ID・デバイス状態・時間帯  │
│                              │                              │
│ 権限：全社内ネットワーク      │ 権限：特定アプリ・操作のみ  │
│ → サーバー・ファイル全て      │ → 最小権限（ABAC）          │
│                              │                              │
│ リスク：高い                  │ リスク：低い                │
│ → 侵害ノート = 社内全横展開   │ → 侵害ノート = アプリ限定  │
└──────────────────────────────┴──────────────────────────────┘

Verified Access による多層検証

リクエスト到達
    ↓
Step 1: アイデンティティ検証（誰か）
    ├─ Okta から JWT 検証 → alice@company.com
    └─ IAM Identity Center から SAML 検証 → alice@company.com
    ↓ OK なら Step 2 へ
    ↓ NG なら HTTP 401 Unauthorized
    
Step 2: Device Posture 評価（どのデバイスか）
    ├─ CrowdStrike Agent: ThreatScore < 50 か確認
    ├─ Jamf: OS 最新 5 バージョン以内か確認
    ├─ ファイアウォール有効か
    ├─ ディスク暗号化有効か
    └─ 既知マルウェア・脆弱性検出なしか
    ↓ OK なら Step 3 へ
    ↓ NG なら HTTP 403 Forbidden
    
Step 3: Cedar ポリシー評価（何ができるか）
    ├─ principal == alice
    ├─ action == ReadFile OR action == EditFile か
    ├─ resource == /home/alice/projects か
    ├─ device.posture.encrypted == true か
    └─ context.hour >= 9 AND context.hour < 18 か（営業時間）
    ↓ OK なら Allow
    ↓ NG なら Deny（HTTP 403）
    
Step 4: バックエンドへ転送
    ├─ CloudTrail に記録（監査証跡）
    ├─ X-Ray でトレース
    └─ ユーザーがアプリアクセス可能

MITRE Framework:
従来 VPN: Assume Trust（内部は信頼）
    ↓
Verified Access: Zero Trust（何も信頼しない。毎回検証）
    ↓ MITRE ATT&CK T1021 Lateral Movement 防止
    ↓ CIS Control 5: Account Management

コアコンポーネント

1. Trust Provider（信頼プロバイダー）

┌─────────────────────────────────────────────┐
│ Trust Provider の種類                       │
├─────────────────────────────────────────────┤
│                                             │
│ 1. AWS IAM Identity Center                 │
│    （AWS Organizations 内の全アカウント）  │
│    - SAML / OIDC 対応                      │
│    - 最も推奨（AWS ネイティブ）             │
│                                             │
│ 2. Okta                                    │
│    - OAuth 2.0 Authorization Code          │
│    - SAML 対応（Okta Identity Platform）  │
│    - 最もポピュラー（エンタープライズ）    │
│                                             │
│ 3. Azure Active Directory                  │
│    - SAML / OpenID Connect 対応             │
│    - Microsoft 環境統一                     │
│                                             │
│ 4. Custom OIDC Provider                   │
│    - 独自 Identity Provider 対応            │
│    - Keycloak・Auth0 等をサポート          │
│                                             │
│ 5. その他 SAML 対応 IdP                    │
│    - PingOne・JumpCloud・Atlassian 等      │
│                                             │
└─────────────────────────────────────────────┘

Trust Provider 選定フロー:
AWS Organizations を使っているか
    ├─ YES: IAM Identity Center（推奨）
    │   理由: 完全無料・AWS ネイティブ統合
    │
    └─ NO: Okta / Azure AD / Custom OIDC
        理由: 既存企業 IdP との連携

2. Endpoint（エンドポイント）

エンドポイント = Verified Access が保護するアプリケーション

対応バックエンド:
├─ ALB / NLB
│  ├─ HTTP/HTTPS Web アプリ（フロントエンド）
│  └─ マイクロサービス
├─ EC2 アプリケーション（非 AWS 環境との連携）
├─ RDS（ポート転送）
├─ SSH（ポート 22 ～）
├─ Custom TCP Application
└─ オンプレミスアプリ（PrivateLink 経由）

エンドポイント設定例:
Endpoint: my-web-app
├─ Protocol: HTTP
├─ Domain: app.internal.mycompany.com
├─ Target: ALB (arn:aws:elasticloadbalancing:...)
├─ Trust Provider: IAM Identity Center
├─ Device Posture Requirements: CrowdStrike
└─ Policy: Cedar ポリシーを適用

3. Endpoint Policy（エンドポイントポリシー）

Verified Access Policy は Cedar ポリシー言語で記述

基本構造:
permit (
  principal == User::"alice@company.com",
  action == Action::"GetObject",
  resource == Resource::"documents",
  context.device.posture.encrypted == true
);

forbid (
  principal == User::"*",
  action in [Action::"DeleteUser", Action::"DeleteRole"],
  context.hour < 8 OR context.hour > 18  // 営業時間外は禁止
);

4. Device Posture（デバイスの信頼度）

Device Posture Sources（優先順）:

1. CrowdStrike Falcon
   - エージェント状態（オンライン/オフライン）
   - Threat Score（脅威スコア）
   - Patch Status（パッチ状態）
   - OS Status（OS ステータス）

2. AWS Systems Manager Fleet Manager
   - EC2 Patch Manager コンプライアンス
   - CloudWatch Agent 状態
   - SSM Agent バージョン

3. Jamf（Apple デバイス向け）
   - macOS バージョン
   - FileVault 暗号化状態
   - Gatekeeper・SIP 状態
   - セキュリティアップデート

4. JumpCloud
   - Linux デバイス LUKS 暗号化
   - ファイアウォール有効化
   - SELinux モード

Device Posture チェック例:
if (
  device.posture.crowdstrike.threat_score < 50
  AND device.posture.jamf.filevault_enabled == true
  AND device.posture.ssm.patch_compliant == true
) {
  // デバイスは信頼できる → アプリアクセス許可
} else {
  // デバイスは信頼できない → アクセス拒否
}

主要ユースケース（12+）

1. VPN 廃止・リモートワーク環境整備

要件： 全 1,000 従業員のリモートワークを VPN レスで実現。年間 VPN ライセンス 200 万円削減。

実装：

# IAM Identity Center 有効化
aws identitycenter create-account-assignment \
  --instance-arn arn:aws:sso:::instance/... \
  --target-account-id 111111111111 \
  --target-type AWS_ACCOUNT \
  --principal-type USER \
  --principal-id alice

# Verified Access Endpoint 作成
aws ec2 create-verified-access-endpoint \
  --verified-access-group-id vagp-... \
  --endpoint-type ALB \
  --network-interface-options SubnetId=subnet-...,SecurityGroupIds=[sg-...]
  --load-balancer-options LoadBalancerArn=arn:aws:elasticloadbalancing:...

# Cedar ポリシー適用
aws ec2 modify-verified-access-endpoint-policy \
  --verified-access-endpoint-id vae-... \
  --policy 'permit (
    principal in Group::"employees",
    action == Action::"GetObject",
    context.device.posture.encrypted == true
  );'

成果： VPN ライセンス廃止。デバイス侵害時もアプリアクセス即座にブロック。ユーザー満足度向上（VPN 遅延解消）。

2. BYOD（Bring Your Own Device）環境の安全な統制

要件： 自分所有のデバイス使用を許可しつつ、セキュリティ要件を満たすか自動検証。

実装：

# Device Posture で CrowdStrike Falcon 統合
aws ec2 create-verified-access-trust-provider \
  --trust-provider-type device \
  --device-options TrustProviderType=crowdstrike-endpoint-detection_and_response,\
                   ApiKey=...,ApiUrl=https://api.crowdstrike.com

# Policy: 脅威スコア > 50 なら拒否
aws ec2 modify-verified-access-endpoint-policy \
  --verified-access-endpoint-id vae-... \
  --policy 'forbid (
    principal == User::"*",
    context.device.posture.crowdstrike.threat_score > 50
  );'

成果： BYOD 許可。デバイスが侵害されたら自動的にアクセス拒否。スマートワークの推進。

3. 医療機関の患者データ・HIPAA コンプライアンス

要件： EHR（電子カルテ）アプリへのアクセスを Verified Access で統制。監査ログを CloudTrail に記録。

実装：

# ALB 背後の EHR アプリケーション
aws ec2 create-verified-access-endpoint \
  --verified-access-group-id vagp-... \
  --endpoint-type ALB \
  --load-balancer-options LoadBalancerArn=arn:aws:...:ehr-app-alb

# Policy: 医師のみ患者情報アクセス
permit (
  principal in Group::"physicians",
  action == Action::"ReadPatientRecord",
  resource.organization_id == principal.organization_id,
  context.device.posture.encrypted == true
);

# 監査ログ有効化
aws ec2 describe-verified-access-logs \
  --verified-access-instance-id vai-...

成果： HIPAA コンプライアンス（アクセス制御・監査ログ）自動達成。患者データ漏洩リスク低減。

4. M&A 子会社社員への一時的アクセス付与

要件： 買収した子会社の 100 名に、本社ポータルサイト・CRM へ 3 ヶ月間のアクセスを付与。期間自動失効。

実装：

# IAM Identity Center で子会社ユーザーを一時グループ作成
aws identitycenter create-group \
  --group-name "subsidiary-employees-temp" \
  --description "3-month access for subsidiary company"

# ユーザー追加
aws identitycenter create-group-membership \
  --group-id grp-... \
  --member-id <100 subsidiary users>

# Permission Set で 3 ヶ月間の期限設定
aws sso create-permission-set \
  --instance-arn arn:aws:sso:::instance/... \
  --name "subsidiary-crm-access" \
  --duration "PT3M"  # 3 months

# Verified Access ポリシーで自動失効
forbid (
  principal in Group::"subsidiary-employees-temp",
  context.time > "2026-07-27T00:00:00Z"
);

成果： 子会社アクセスの一括付与・自動失効。管理者の手動削除不要。セキュリティ漏れ防止。

5. SaaS 企業によるテナント分離・マルチテナント認可

要件： 複数の顧客テナント。テナント A のユーザーがテナント B のデータにアクセスできないよう分離。

実装：

# Cedar ポリシー: テナント ID ベース分離
permit (
  principal == User::"alice@customerA.com",
  action == Action::"ReadData",
  resource.tenant_id == "customerA",
  resource.data_classification == "public"
);

forbid (
  principal == User::"alice@customerA.com",
  resource.tenant_id != "customerA"  // 他テナントアクセス禁止
);

成果： アプリケーションコードの修正不要。テナント分離ロジックを Verified Access で保証。コンプライアンス達成。

6. 金融機関の管理画面への厳密なアクセス制御

要件： AWS コンソール・RDS 管理画面へのアクセスは「営業時間・本社 IP・デバイス暗号化有効」の全て条件を満たした場合のみ。

実装：

# Cedar ポリシー: 複合条件
permit (
  principal in Group::"admins",
  action == Action::"AssumeRole",
  resource.resource_type == "aws_console",
  context.time.hour >= 9 AND context.time.hour < 18,  // 営業時間
  context.source_ip in IpRange::"office_network",      // 本社 IP
  context.device.posture.encrypted == true              // 暗号化有効
);

成果： 細粒度なアクセス制御。アドホック夜間アクセス防止。内部脅威・外部侵害時の横展開防止。

7. AWS WorkSpaces + Verified Access によるデスクトップ VPN レス化

要件： 在宅勤務社員が WorkSpaces（仮想デスクトップ）経由で社内アプリにアクセス。完全 VPN レス環境。

実装：

# WorkSpaces を Verified Access と統合
aws workspaces create-workspace \
  --bundle-id wsb-... \
  --user-name alice \
  --workspace-properties RunningMode=ALWAYS_ON

# Verified Access ポリシーを WorkSpaces 内のブラウザに適用
# → ユーザーの ID・デバイス状態が常に検証される
# → WorkSpaces 上のブラウザは VPN 不要で社内アプリアクセス

成果： WorkSpaces が VPN ゲートウェイの役割を果たす。ノートパソコンの盗難時も社内アクセス不可。

8. 非 HTTP リソース（RDS・SSH）へのアクセス（2025 年 5 月 GA）

要件： RDS PostgreSQL・SSH サーバーへの VPN レスアクセス。

実装：

# RDS Endpoint（ポート 5432）を Verified Access 保護
aws ec2 create-verified-access-endpoint \
  --verified-access-group-id vagp-... \
  --endpoint-type network-interface \
  --network-interface-options SubnetId=subnet-...,SecurityGroupIds=[sg-...]
  --domain-name rds.internal.mycompany.com
  --port 5432
  --protocol tcp

# SSH ポート（22）を Verified Access 保護
aws ec2 create-verified-access-endpoint \
  --verified-access-group-id vagp-... \
  --endpoint-type network-interface \
  --domain-name bastion.internal.mycompany.com
  --port 22
  --protocol tcp

# Policy: DBA グループのみアクセス
permit (
  principal in Group::"dba-team",
  action == Action::"Connect",
  context.device.posture.encrypted == true
);

成果： Bastion 不要。RDS・SSH に直接 VPN レスアクセス。管理基盤の簡素化。

9. Cloudflare Zero Trust・Tailscale との統合

要件： Cloudflare・Tailscale と Verified Access を統合。多層 ZTNA。

実装：

# Verified Access + Cloudflare Warp
# ユーザーブラウザ
#   ↓ Cloudflare Warp（第 1 層 ZTNA）
# Cloudflare Gateway
#   ↓ Verified Access（第 2 層 ZTNA）
# AWS Backend App

# Cedar ポリシー: Cloudflare Trust Token 検証
permit (
  principal == User::"alice",
  action == Action::"GetObject",
  context.cloudflare_token.valid == true,          // Cloudflare 検証済み
  context.device.posture.encrypted == true         // Verified Access 検証
);

成果： 多層防御。Cloudflare・Verified Access それぞれ独立して検証。どちらかの侵害も耐性。

10. EventBridge 統合による自動対応

要件： アクセス拒否イベント → Slack 通知・CloudWatch Logs 記録 → 自動調査 Lambda 実行。

実装：

# EventBridge ルール: Verified Access アクセス拒否イベント
aws events put-rule \
  --name verified-access-denial-rule \
  --event-pattern '{
    "source": ["aws.verified-access"],
    "detail-type": ["Verified Access Access Denied"],
    "detail": {
      "decision": ["deny"]
    }
  }'

# Target: Lambda（自動調査）
aws events put-targets \
  --rule verified-access-denial-rule \
  --targets "Id"="1","Arn"="arn:aws:lambda:...:investigate-denial-lambda"

# Lambda 関数: デバイス・ユーザー・ポリシーを自動分析
def lambda_handler(event, context):
    denial = event['detail']
    principal = denial['principal']
    device_id = denial['device_id']
    
    # CrowdStrike API で脅威スコア確認
    threat_score = get_crowdstrike_threat_score(device_id)
    
    # Slack 通知
    slack_notify(f"""
      🔒 Verified Access Denial Alert
      User: {principal}
      Device: {device_id}
      Threat Score: {threat_score}
      Action: {denial['action']}
      Time: {denial['time']}
      
      Recommended Action: {'Isolate Device' if threat_score > 50 else 'Investigate'}
    """)
    
    return {'statusCode': 200}

成果： セキュリティインシデントの自動検知・通知・初期対応の自動化。

11. AWS Organizations マルチアカウント環境での統一 Zero Trust 基盤

要件： 50 アカウント・10 リージョン環境で、Verified Access を統一管理。開発・ステージ・本番環境ごとにポリシー変更。

実装：

# CloudFormation で全アカウントに展開
aws cloudformation create-stack-set \
  --stack-set-name verified-access-global-setup \
  --template-body file://verified-access-cfn.yaml

# 各アカウントに展開
aws cloudformation create-stack-instances \
  --stack-set-name verified-access-global-setup \
  --accounts 111111111111 222222222222 ... \
  --regions us-east-1 eu-west-1 ap-northeast-1

# 環境別ポリシー（Systems Manager Parameter Store で管理）
aws ssm put-parameter \
  --name /verified-access/policy/prod \
  --value 'permit (
    principal in Group::"prod-admins",
    context.device.posture.threat_score < 30,
    context.time.hour >= 9 AND context.time.hour < 18
  );'

成果： 組織全体の統一 Zero Trust 基盤。各環境ごとのカスタマイズ可能。IaC による再現性確保。

12. PrivateLink を経由したオンプレミスアプリケーション保護

要件： オンプレミスのレガシーアプリを Verified Access 保護。AWS VPC・オンプレ間は PrivateLink・VPN で接続。

実装：

# AWS 側: PrivateLink エンドポイント
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-... \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.privatelink

# VPN: AWS <-> オンプレミス接続
aws ec2 create-vpn-gateway \
  --type ipsec.1

# Verified Access: VPC 内から オンプレアプリへのアクセス制御
aws ec2 create-verified-access-endpoint \
  --verified-access-group-id vagp-... \
  --endpoint-type network-interface \
  --domain-name legacy-app.internal.corp.com
  --target-ip 10.0.0.100  # オンプレミス IP

# Policy: VPN・PrivateLink で到達したユーザーのみ
permit (
  principal in Group::"legacy-app-users",
  context.tunnel_type in ["PrivateLink", "VPN"],
  action == Action::"Access"
);

成果： オンプレミスレガシーアプリのモダナイズ不要で Zero Trust 化。セキュリティ向上。

設定・操作の具体例

CLI による設定例

# 1. IAM Identity Center Trust Provider 作成
aws ec2 create-verified-access-trust-provider \
  --trust-provider-type user \
  --user-trust-provider-config \
    AccessUrl=https://my-idcenter.awsapps.com/start,\
    AuthorizationEndpoint=https://my-idcenter.awsapps.com/oauth/authorize,\
    ClientId=...,\
    ClientSecret=...,\
    Issuer=https://my-idcenter.awsapps.com,\
    TokenEndpoint=https://my-idcenter.awsapps.com/oauth/token,\
    UserInfoEndpoint=https://my-idcenter.awsapps.com/oauth/userinfo

# 2. Verified Access Group 作成
aws ec2 create-verified-access-group \
  --verified-access-instance-id vai-... \
  --description "Production Web Applications"

# 3. Endpoint 作成（ALB 背後のアプリ）
aws ec2 create-verified-access-endpoint \
  --verified-access-group-id vagp-... \
  --endpoint-type ALB \
  --network-interface-options SubnetId=subnet-...,SecurityGroupIds=[sg-...]
  --load-balancer-options LoadBalancerArn=arn:aws:elasticloadbalancing:...
  --domain-name app.internal.company.com \
  --protocol HTTP

# 4. Device Posture Policy 作成（CrowdStrike）
aws ec2 create-verified-access-trust-provider \
  --trust-provider-type device \
  --device-options \
    TrustProviderType=crowdstrike_endpoint_detection_and_response,\
    ApiKey=...,\
    ApiUrl=https://api.crowdstrike.com

# 5. Cedar ポリシー適用
aws ec2 modify-verified-access-endpoint-policy \
  --verified-access-endpoint-id vae-... \
  --policy-document 'permit (
    principal in Group::"employees",
    action == Action::"GetObject",
    context.device.posture.crowdstrike.threat_score < 50
  );'

# 6. CloudTrail でログを確認
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceType,AttributeValue=VerifiedAccessEndpoint \
  --max-results 50

SDK（Python）による設定例

import boto3
from botocore.exceptions import ClientError

# Verified Access クライアント初期化
ec2_client = boto3.client('ec2', region_name='us-east-1')

# 1. Verified Access Instance 一覧取得
response = ec2_client.describe_verified_access_instances()
instance_id = response['VerifiedAccessInstances'][0]['VerifiedAccessInstanceId']
print(f"Instance ID: {instance_id}")

# 2. Endpoint 一覧取得
response = ec2_client.describe_verified_access_endpoints(
    Filters=[
        {'Name': 'verified-access-instance-id', 'Values': [instance_id]}
    ]
)
endpoints = response['VerifiedAccessEndpoints']
print(f"Endpoints: {len(endpoints)} 件")

# 3. Endpoint ポリシー修正
def update_endpoint_policy(endpoint_id, new_policy):
    try:
        response = ec2_client.modify_verified_access_endpoint_policy(
            VerifiedAccessEndpointId=endpoint_id,
            PolicyDocument=new_policy,
            ClientToken='idempotency-token-123'
        )
        print(f"Policy updated: {response['VerifiedAccessEndpoint']['PolicyDocument']}")
    except ClientError as e:
        print(f"Error: {e}")

# 4. Device Posture 情報取得
def check_device_posture(device_id):
    # AWS Systems Manager Fleet Manager で Device Posture 確認
    ssm_client = boto3.client('ssm')
    response = ssm_client.describe_instance_information(
        InstanceInformationFilterList=[
            {'key': 'InstanceIds', 'valueSet': [device_id]}
        ]
    )
    instance = response['InstanceInformationList'][0]
    
    posture = {
        'encrypted_volume': instance.get('EncryptedVolume', False),
        'patch_compliant': instance.get('PingStatus') == 'Online',
        'agent_version': instance.get('AgentVersion')
    }
    return posture

# 5. CloudTrail ログ分析
def analyze_access_logs():
    cloudtrail_client = boto3.client('cloudtrail')
    response = cloudtrail_client.lookup_events(
        LookupAttributes=[
            {'AttributeKey': 'ResourceType', 'AttributeValue': 'VerifiedAccessEndpoint'}
        ],
        MaxResults=50
    )
    
    events = response['Events']
    for event in events:
        print(f"User: {event['Username']}")
        print(f"Time: {event['EventTime']}")
        print(f"Event Name: {event['EventName']}")
        print(f"Cloud Trail Event: {event['CloudTrailEvent']}")
        print("---")

# 実行
update_endpoint_policy(
    'vae-1234567890abcdef',
    'permit (principal == User::"alice", action == Action::"GetObject");'
)
check_device_posture('i-1234567890abcdef')
analyze_access_logs()

IaC（CloudFormation）による設定例

AWSTemplateFormatVersion: '2010-09-09'
Description: 'AWS Verified Access Zero Trust Setup with CloudFormation'

Parameters:
  IdentityCenterInstanceArn:
    Type: String
    Description: IAM Identity Center Instance ARN
  LoadBalancerArn:
    Type: String
    Description: Application Load Balancer ARN

Resources:
  # Verified Access Instance
  VerifiedAccessInstance:
    Type: AWS::EC2::VerifiedAccessInstance
    Properties:
      Description: Production Zero Trust Network Access
      LoggingOptions:
        CloudWatchLogs:
          Enabled: true
          LogGroup: !Ref VerifiedAccessLogGroup

  # CloudWatch Logs Group
  VerifiedAccessLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: /aws/verified-access/production
      RetentionInDays: 30

  # Trust Provider (IAM Identity Center)
  IdentityCenterTrustProvider:
    Type: AWS::EC2::VerifiedAccessTrustProvider
    Properties:
      TrustProviderType: user
      UserTrustProviderConfig:
        AccessUrl: !Sub '${IdentityCenterInstanceArn}/start'
        AuthorizationEndpoint: !Sub '${IdentityCenterInstanceArn}/oauth/authorize'
        ClientId: !Ref ClientId
        ClientSecret: !Ref ClientSecret
        Issuer: !Ref IdentityCenterInstanceArn
        TokenEndpoint: !Sub '${IdentityCenterInstanceArn}/oauth/token'
        UserInfoEndpoint: !Sub '${IdentityCenterInstanceArn}/oauth/userinfo'

  # Verified Access Group
  VerifiedAccessGroup:
    Type: AWS::EC2::VerifiedAccessGroup
    Properties:
      VerifiedAccessInstanceId: !Ref VerifiedAccessInstance
      Description: Web Application Protection Group

  # Verified Access Endpoint (ALB)
  WebAppEndpoint:
    Type: AWS::EC2::VerifiedAccessEndpoint
    Properties:
      VerifiedAccessGroupId: !Ref VerifiedAccessGroup
      EndpointType: ALB
      NetworkInterfaceOptions:
        SubnetId: !Ref PrivateSubnet
        SecurityGroupIds:
          - !Ref VerifiedAccessSecurityGroup
      LoadBalancerOptions:
        LoadBalancerArn: !Ref LoadBalancerArn
      DomainName: app.internal.mycompany.com
      Protocol: HTTPS
      PolicyDocument: |
        permit (
          principal in Group::"employees",
          action == Action::"GetObject",
          context.device.posture.encrypted == true
        );

  # Security Group for Verified Access
  VerifiedAccessSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Security group for Verified Access endpoint
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: 0.0.0.0/0

  # Verified Access Endpoint Access Logs to CloudWatch
  VerifiedAccessLogPolicy:
    Type: AWS::Logs::ResourcePolicy
    Properties:
      PolicyName: verified-access-policy
      PolicyText: |
        {
          "Version": "2012-10-17",
          "Statement": [
            {
              "Effect": "Allow",
              "Principal": {
                "Service": "verified-access.amazonaws.com"
              },
              "Action": "logs:PutLogEvents",
              "Resource": "arn:aws:logs:*:*:log-group:/aws/verified-access/*"
            }
          ]
        }

Outputs:
  VerifiedAccessInstanceId:
    Description: Verified Access Instance ID
    Value: !Ref VerifiedAccessInstance

  VerifiedAccessGroupId:
    Description: Verified Access Group ID
    Value: !Ref VerifiedAccessGroup

  WebAppEndpointId:
    Description: Web App Endpoint ID
    Value: !Ref WebAppEndpoint

  EndpointDomain:
    Description: Endpoint Domain Name
    Value: app.internal.mycompany.com

類似サービス比較表

項目	AWS Verified Access	Cloudflare Zero Trust	Tailscale	Twingate	Zscaler Private Access
デプロイ	AWS ネイティブ	SaaS	SaaS	SaaS	SaaS
デバイス要件	ID Provider + Posture	Cloudflare Warp Agent	Tailscale Client	Connector + Client	Zscaler Client
Trust Provider 統合	IAM Identity Center・Okta・Azure AD・OIDC	Okta・Azure AD・Google	SAML・OIDC	Okta・Azure AD・SAML	Okta・Azure AD・SAML
Device Posture	CrowdStrike・Jamf・SSM	ネイティブチェック	ネイティブチェック	ネイティブチェック	デバイスポスチャーチェック
Policy 言語	Cedar	Firewall Rules	ACL	Policy Engine	Policy Rules
非 HTTP リソース	○（RDS・SSH・TCP）	×	○	○	○
AWS ネイティブ	○	×	×	×	×
Organizations 統合	○（全アカウント自動）	×	×	×	×
価格帯	従量制（アプリ時間）	月額 $	月額 $	月額 $	月額 $
学習曲線	低（Cedar）	中	低	中	中
エンタープライズ対応	○	◎	○	○	◎◎

ベストプラクティス・チェックリスト

✅ 推奨

[ ] Trust Provider は Organizations・IAM Identity Center を優先選択
[ ] Device Posture を複数ソース（CrowdStrike + Jamf）で多層評価
[ ] Cedar ポリシーで時間帯・IP・リソース属性を複合条件指定
[ ] CloudTrail で全アクセス試行を記録・監査
[ ] EventBridge でアクセス拒否を Slack・PagerDuty に即座通知
[ ] PrivateLink で AWS ↔ オンプレミス通信を暗号化
[ ] 段階的 VPN 廃止（VPN 同時稼働 → VA メインに移行 → VPN 廃止）
[ ] ユーザートレーニング（VPN 廃止後の接続方法）

❌ アンチパターン

[ ] VPN と Verified Access の急激な一本化（ユーザーリスク）
[ ] Device Posture なし（デバイス侵害検知不可）
[ ] Cedar ポリシー設定なし（全員同一権限）
[ ] CloudTrail ログなし（監査非準拠）
[ ] Trust Provider 単一選択（IdP 障害時に全体影響）

2025-2026 最新動向

非 HTTP リソース対応（GA: 2025 年 5 月）

RDS・SSH・カスタム TCP アプリケーションへの VPN レスアクセスが正式サポート。TCP ベースの任意のアプリケーションを Verified Access で保護可能に拡大。

AWS WorkSpaces との統合強化

WorkSpaces（仮想デスクトップ）を Verified Access と統合。デスクトップ内のブラウザがアイデンティティ・デバイス検証を自動実行。WorkSpaces 自体が VPN ゲートウェイ役。

Zero Trust 2026 トレンド

IDC 予測：2026 年までに約 60% の企業が VPN から ZTNA（Zero Trust Network Access）への移行を完了予定。AWS Verified Access が主流選択肢に。

AI 駆動の推奨設定

Bedrock（生成 AI）と統合。組織の脅威プロファイルを分析し、最適な Cedar ポリシーを自動生成・推奨。

学習リソース・参考文献

公式ドキュメント

パートナー・ベンダーリソース

AWS ブログ・セミナー

実装チェックリスト

[ ] Trust Provider（IAM Identity Center / Okta）設定確認
[ ] Device Posture ソース（CrowdStrike / Jamf）統合
[ ] Verified Access Instance・Group 作成
[ ] ALB / NLB / EC2 Endpoint 作成
[ ] Cedar ポリシー設計・記述
[ ] CloudTrail ログ有効化
[ ] EventBridge ルール設定（Slack / PagerDuty 通知）
[ ] ユーザーテスト（VPN 廃止前の並行運用）
[ ] ドキュメント・トレーニング資料作成
[ ] 段階的ロールアウト計画（Team → Department → Organization）

まとめ

AWS Verified Access は、VPN を廃止し Zero Trust セキュリティを実現するフルマネージドサービスです。

主な利点

VPN 廃止: ライセンス・管理コスト削減
毎リクエスト検証: ラテラルムーブメント防止
デバイスポスチャー: 侵害デバイス自動ブロック
Cedar ポリシー: 微細な ABAC 制御
AWS ネイティブ: Organizations・CloudTrail・EventBridge 統合

推奨対象

リモートワーク企業: VPN 廃止で利便性向上
セキュリティ重視: Zero Trust 実装
医療・金融: 監査要件対応

Verified Access は 2026 年の組織セキュリティ投資の最優先課題です。非 HTTP リソース対応・WorkSpaces 統合・AI 推奨設定により、エンタープライズ対応が急速に進行中。今から投資することで、従来の VPN ベース運用との段階的移行を実現し、5 年後の「Zero Trust スタンダード組織」へのスムーズな進化が可能になります。

最終更新：2026-04-27 バージョン：v2.0

目次

AWS Verified Access 完全ガイド v2.0

VPNレス Zero Trust ネットワークアクセス制御の実現

ドキュメントの目的

2025-2026 年の Verified Access エコシステム

概要

Verified Access が実現する価値

Verified Access が解決する課題

1. VPN の運用負荷・セキュリティリスク

2. リモートワークでの多様なデバイス・ネットワークへの対応

3. 買収企業の一時的なアクセス付与の複雑性

4. エンドポイント・アプリケーション単位のセキュリティ制御の欠落

主な特徴

アーキテクチャ

Zero Trust Network Access（ZTNA）の概念

VPN モデル vs ZTNA（Verified Access）

Verified Access による多層検証

コアコンポーネント

1. Trust Provider（信頼プロバイダー）

2. Endpoint（エンドポイント）

3. Endpoint Policy（エンドポイントポリシー）

4. Device Posture（デバイスの信頼度）

主要ユースケース（12+）

1. VPN 廃止・リモートワーク環境整備

2. BYOD（Bring Your Own Device）環境の安全な統制

3. 医療機関の患者データ・HIPAA コンプライアンス

4. M&A 子会社社員への一時的アクセス付与

5. SaaS 企業による テナント分離・マルチテナント認可

6. 金融機関の管理画面への厳密なアクセス制御

7. AWS WorkSpaces + Verified Access による デスクトップ VPN レス化

8. 非 HTTP リソース（RDS・SSH）へのアクセス（2025 年 5 月 GA）

9. Cloudflare Zero Trust・Tailscale との統合

10. EventBridge 統合による自動対応

11. AWS Organizations マルチアカウント環境での統一 Zero Trust 基盤

12. PrivateLink を経由した オンプレミスアプリケーション保護

設定・操作の具体例

CLI による設定例

SDK（Python）による設定例

IaC（CloudFormation）による設定例

類似サービス比較表

ベストプラクティス・チェックリスト

✅ 推奨

❌ アンチパターン

2025-2026 最新動向

非 HTTP リソース対応（GA: 2025 年 5 月）

AWS WorkSpaces との統合強化

Zero Trust 2026 トレンド

AI 駆動の推奨設定

学習リソース・参考文献

公式ドキュメント

パートナー・ベンダーリソース

AWS ブログ・セミナー

実装チェックリスト

まとめ

主な利点

推奨対象

5. SaaS 企業によるテナント分離・マルチテナント認可

7. AWS WorkSpaces + Verified Access によるデスクトップ VPN レス化

12. PrivateLink を経由したオンプレミスアプリケーション保護