AWS Verified Access

AWS Verified Access は、VPN を使わずに社内向けのアプリケーションへ安全にアクセスさせるための、ゼロトラストに基づくサービスです。アクセス要求が来るたびに、利用者の ID とデバイスの状態をポリシーに照らして評価し、条件を満たした場合のみ対象アプリへの到達を許可します。これにより、ネットワークへの接続そのものを信頼の前提とせず、アプリ単位での細かなアクセス制御を実現します。

解決する課題

リモートワークが一般化し、社内アプリへのアクセスを VPN で提供する構成が広く使われてきました。しかし VPN ベースの方式にはいくつかの課題があります。

• VPN で一度ネットワークに入ると、その内側のリソースへ広く到達できてしまい、必要以上のアクセスを許してしまいがちになる。ネットワークへの接続が暗黙の信頼につながる。
• VPN クライアントの配布や設定、接続トラブルの対応など、利用者と管理者の双方に運用負荷がかかる。
• アクセスのたびに ID やデバイスの状態を細かく確認する仕組みを自前で組み込むのは手間がかかり、アプリごとに認証認可の実装がばらつきやすい。

Verified Access は、ネットワークへの接続を信頼の前提にせず、リクエストのたびに ID とデバイスの信頼性を検証する発想でこれらを解決します。利用者は VPN クライアントを介さずにアプリへアクセスでき、管理者はアプリ単位で「誰が」「どのような状態のデバイスから」到達してよいかをポリシーとして一元的に定義できます。アクセスの可否は接続ごとに評価されるため、最小権限を保ちやすくなります。

主要概念と用語

• Verified Access インスタンス: Verified Access の中心となるリソース。複数のアプリ（グループやエンドポイント）をまとめて束ね、信頼プロバイダーやポリシーを関連付ける土台となる。
• 信頼プロバイダー（Trust Provider）: アクセス要求の判断材料となる信頼情報の提供元。利用者の ID を提供するユーザー信頼プロバイダーと、デバイスの状態を提供するデバイス信頼プロバイダーの 2 種類がある。
• ユーザー信頼プロバイダー: 利用者の ID を検証する仕組み。OIDC に対応した外部 ID プロバイダーや、AWS の ID 基盤と連携できる。利用者の所属グループやメールアドレスなどの属性をアクセス評価に使える。
• デバイス信頼プロバイダー: 端末管理（デバイス管理）サービスと連携し、デバイスがポリシーに準拠しているか、管理下にあるかといった姿勢情報を取得する。
• Verified Access グループ: 共通のセキュリティ要件を持つエンドポイントをまとめる単位。グループにポリシーを設定すると、配下のエンドポイントへ共通の基準を適用できる。
• Verified Access エンドポイント: 実際に保護する個々のアプリへの接続点。背後のアプリをロードバランサーやネットワークインターフェースで指定し、エンドポイント単位でもポリシーを設定できる。
• アクセスポリシー: 誰がどの条件で到達してよいかを定義する規則。ゼロトラストの判断ロジックを表現する Cedar というポリシー言語で記述し、ユーザー属性とデバイス姿勢を条件にできる。

仕様・制限・クォータ

Verified Access を設計する際に意識すべき仕様上の性質は次のとおりです。具体的な上限値はリージョンや時期で変わりうるため、定性的に把握し、正確な数値は公式ドキュメントとサービスクォータの画面で確認してください。

• 保護対象は主に HTTP や HTTPS のアプリケーションで、エンドポイントの背後にロードバランサーやネットワークインターフェースを指定して接続する。
• ユーザー信頼プロバイダーは OIDC に対応した ID プロバイダーと連携でき、利用者の ID 検証に用いる。デバイス信頼プロバイダーは対応するデバイス管理サービスと連携する。
• アクセスポリシーは Cedar 言語で記述する。グループ単位とエンドポイント単位の両方でポリシーを設定でき、両者が評価される。
• 1 つのアカウントやインスタンスあたりに作成できるグループやエンドポイントの数などには、それぞれクォータがある。多数のアプリを保護する場合は事前に上限を見積もる。
• アクセスの可否はリクエストのたびに評価される。利用者の ID とデバイスの状態の双方を条件に組み込めるため、ネットワーク到達性だけでなく文脈に応じた制御ができる。
• アクセスのログを詳細に記録でき、出力先として CloudWatch Logs などを選べる。

内部の仕組み

Verified Access は、利用者とアプリの間に立ち、アクセス要求のたびに信頼の評価を行います。

利用者がアプリへアクセスしようとすると、その要求は Verified Access のエンドポイントを経由します。Verified Access は、関連付けられたユーザー信頼プロバイダーを通じて利用者の ID を検証し、所属グループやメールアドレスなどの属性を取得します。デバイス信頼プロバイダーが設定されている場合は、あわせて端末が管理下にあるか、必要なセキュリティ要件を満たしているかといった姿勢情報も取得します。

これらの信頼情報がそろうと、Verified Access はグループとエンドポイントに設定されたアクセスポリシーを Cedar で評価します。ポリシーの条件をすべて満たせば、要求は背後のアプリへ転送されます。条件を満たさなければアクセスは拒否されます。重要なのは、この評価がネットワークへの一度きりの入場ではなく、アクセス要求ごとに行われる点です。これにより、ネットワークに到達できること自体を信頼の根拠にしない、ゼロトラストの原則が実現されます。背後のアプリ側は Verified Access が前段で認証認可を担うため、個々のアプリに認証ロジックを実装する負担を減らせます。

設計パターン / ベストプラクティス

• アプリ単位で最小権限に絞る: グループとエンドポイントでポリシーを階層化し、共通要件はグループに、個別要件はエンドポイントに記述する。利用者の属性とデバイスの姿勢を組み合わせ、必要な相手にだけ到達を許可する。
• ID とデバイスの両面で評価する: ユーザー信頼プロバイダーだけでなくデバイス信頼プロバイダーも併用し、「正しい人が」「正しい状態のデバイスから」アクセスしているかを確認する。これがゼロトラストの中核になる。
• 既存の ID 基盤を活用する: OIDC 対応の ID プロバイダーと連携し、既存のユーザーやグループ情報をそのままアクセス条件に使う。アプリごとに認証を実装し直す必要がなくなる。
• VPN からの移行経路として位置づける: ネットワーク全体への広い到達性を与える VPN を、アプリ単位の制御へ置き換える手段として導入する。段階的にアプリを移行していく。
• ログを前提に運用設計する: アクセスのたびに評価される判断結果をログに残し、誰がどのアプリへ到達したか、なぜ拒否されたかを後から追えるようにする。

運用・監視

• アクセスログの活用: アクセスのたびに記録される評価結果を CloudWatch Logs などへ出力し、到達したアプリ、利用者、判断結果を可視化する。許可と拒否の双方を記録することで監査とトラブルシュートに役立つ。
• ポリシー変更の管理: アクセスポリシーは Cedar で記述するため、ポリシーをコードとして版管理し、変更の意図と影響範囲を明確にする。意図しない緩和を検知できる体制にする。
• 信頼プロバイダーの健全性: 連携する ID プロバイダーやデバイス管理サービスが正しく応答しているかを監視する。これらが不調になると正当な利用者のアクセスにも影響するため、依存先の可用性を意識する。
• 段階的なロールアウト: 新しいポリシーをいきなり全体へ適用せず、対象を限定して挙動を確認してから広げる。拒否ログを見て、過度に厳しすぎないか調整する。

コスト

Verified Access の料金は、おおむね次の要素で構成されます。具体的な単価はリージョンや時期で変動するため、最新の料金ページで確認してください。

• アプリケーション単位の料金: 保護するアプリ（エンドポイント）の数や、それらが稼働している時間に応じた料金が発生する。
• データ処理料金: Verified Access を通過して処理したデータ量に応じた処理料金がかかる。
• 設計上の考慮: 保護するアプリの数とトラフィック量がコストに直結する。VPN の運用コストや自前で認証認可を実装・維持するコストと比較して、運用負荷の軽減分も含めて総合的に評価するとよい。

セキュリティ

• ゼロトラストの徹底: ネットワークへの到達を信頼の前提とせず、アクセス要求ごとに ID とデバイスの状態を検証する。これが Verified Access の中核的なセキュリティ価値である。
• 多要素の評価: ユーザー信頼プロバイダーによる ID の確認と、デバイス信頼プロバイダーによる端末の姿勢確認を組み合わせ、文脈に応じた認可を行う。
• 最小権限の徹底: アプリ単位でポリシーを定め、必要な利用者と条件にだけ到達を許可する。VPN のようにネットワーク全体へ広く到達させない。
• アクセスの可視性: すべてのアクセス評価をログに残すことで、誰がどのアプリへ到達したか、拒否がなぜ起きたかを追跡でき、インシデント対応や監査に資する。
• 暗号化との併用: Verified Access はアクセスの認可を担うが、転送中の暗号化（TLS など）はアプリや経路で引き続き適切に設定する。

Well-Architected の観点

セキュリティの柱の観点が中心です。ネットワークへの接続を信頼せず、アクセスごとに ID とデバイスの状態を検証することで、攻撃面を縮小し、最小権限のアクセスを保ちます。アプリ単位のポリシーと詳細なアクセスログは、防御の多層化と可視性の確保に直結します。あわせて、運用上の優秀性の柱の観点では、VPN サーバーや個別の認証実装を自前で運用する負担を減らし、ポリシーをコードとして一元管理できる点が関係します。

試験で問われるポイント

関連サービス・比較

同じくリモートアクセスを担う AWS Client VPN と Verified Access は、しばしば比較されます。Client VPN はネットワーク層で端末を VPC に接続するのに対し、Verified Access はアプリ単位でアクセスのたびに ID とデバイスを検証するゼロトラストの方式です。ネットワーク全体への接続が必要なら前者、Web アプリへの細かなアクセス制御が要るなら後者が向きます。

ハンズオン / CLI例

以下は AWS CLI で Verified Access のインスタンスやグループ、ポリシーの状態を確認する例です。実際の構築では、事前に信頼プロバイダー（OIDC の ID プロバイダーなど）を準備し、保護対象のアプリを指すエンドポイントを用意します。

# Verified Access インスタンスの一覧と状態を確認する
aws ec2 describe-verified-access-instances

# 信頼プロバイダー（ユーザー／デバイス）の一覧を確認する
aws ec2 describe-verified-access-trust-providers

# Verified Access グループの一覧を確認する
aws ec2 describe-verified-access-groups

# 指定したエンドポイントに設定されたアクセスポリシーを確認する
aws ec2 get-verified-access-endpoint-policy \
  --verified-access-endpoint-id vae-0123456789abcdef0