【緊急共有5】AWSゼロトラスト実装の全体像: システムを全部AWSに上げてゼロトラスト化を完璧にするアプローチ: ディープリサーチレポート

さっつーのAIエージェントを監修している今泉大輔です。昨年後半から今年1月にかけて、アサヒグループやアスクルのランサム被害に対する抜本的な対策を、リサーチャー目線で調査して知見をシェアする経営企画部向けのセミナーを3本やりました。その最後の方「ランサムウェア対策の最終解答：米政府推奨ゼロトラストアーキテクチャ移行の必須知識」（一般社団法人 企業研究会主催。終了セミナーの告知ページは残さない慣行なので今はありません）で配布したA4 100ページの資料、6部から成る内容をアップデートして共有します。これは第5部。

一連のランサムウェア対策セミナーでは、日本企業が長年怠ってきた社内システムのクラウド化を抜本的に推し進め、その上で、最新のゼロトラストアーキテクチャを実装することが最上の方策である...コストはかかるが...という建付けにして、対策費用を捻出できる立場にある経営企画部の方々にロジックを伝授しました。

従来のIT投資の数倍、ともすれば10倍かかるこの巨大事業を敢行するするには、一にも二にも、社長を説得するしかないとお伝えしました。【戦時】である今が、その好機だと言えるでしょう。

AWSベースのゼロトラストを1〜2年で実装に落とすとき、移行とルール実装の量を出すヴィークルとして、インドのAWS大手4社（TCS、Infosys、Wipro、HCLTech。いずれもAWSの最上位パートナー）を工場として使うのが、現時点で最も再現性が高いと考えています。英語の技術文書を作業に落とし、古いシステムをAWSへ載せる人月を並行して出せる厚みでは、この4社に分があります。東欧や南米にも同水準の会社はありますが、認定者の規模と同時に受けられる件数では、インド4社が厚いです。

ただし「4社以外に方法はない」という意味ではありません。方針の確定、既存システムの理解、監査対応、日本語での経営報告と長期運用は、国内の主契約ベンダーに残すのが現実的です。深刻な事案が重なると、国内の提案・設計の枠は先に埋まります。そこで方針と監査は国内に置き、載せ替えと確認ルールの実装量をインド4社に出す形が、短期間に量を出すうえでの実務的な答えになります。契約と運用の全体を4社に渡す必要はありません。

依頼先の切り方、予算の付け方、最初の90日で見る数字は、次のレポート【緊急共有6】で論じます。

【本レポートのイントロダクション】

【レポート本文】

1. 2026年におけるAWSゼロトラスト主要コンポーネントと設計パラダイムの進化

企業ネットワークの境界がクラウド、リモート環境、SaaSへと不可逆的に拡散した結果、従来のペリメタ（境界型）防御モデルは実効性を喪失した1。2026年におけるAWSのゼロトラストアーキテクチャは、「暗黙の信頼を完全に排除し、アイデンティティ、デバイス、コンテキストをすべてのトランザクションで継続的に検証する」という原則を具現化している4。近年の機能拡張により、ネットワークインフラの結合度を下げつつ、アプリケーション層とデータ層に直接ポリシーを適用するネイティブ機能群が成熟期を迎えている2。

AWS Verified Access によるコンテキスト認識型アクセス制御

AWS Verified Access（AVA）は、従来の企業向けリモートアクセスVPNを刷新するゼロトラストネットワークアクセス（ZTNA）の中核である2。エンドユーザーがプライベートな業務アプリケーションへ接続する際、AVAはネットワークの接続元IPアドレスではなく、アイデンティティ情報と端末の健全性をトランザクションごとにリアルタイム評価する1。 ポリシーエンジンにはオープンソースの認可記述言語「Cedar」が全面的に統合されており、数学的に検証可能な厳格な認可ロジックを実行する1。外部Identity Provider（IdP）から渡されるクレームやロール情報に加え、CrowdStrike、Jamf、Microsoft Intuneといったデバイス管理・EDRパートナーから収集した端末の暗号化状態、OSパッチ適用状況、リアルタイム脅威スコアを単一のポリシー内で動的に突き合わせる1。 2026年の設計において特筆すべきは、Application Load Balancer（ALB）やENI（Elastic Network Interface）に対するHTTP/HTTPSエンドポイントの保護にとどまらず、ダイレクトCIDRルーティングやLattice Resource Gatewayとの相互運用により、内部データベース接続や管理用ポート通信（SSH/RDP）に対してもコンテキスト依存の動的アクセス制御が拡張されている点である4。

Amazon VPC Lattice によるサービス間通信のゼロトラスト化

マイクロサービスアーキテクチャやマルチアカウント環境の普及に伴い、VPC間のサービス間通信（Service-to-Service）におけるゼロトラストの確立が不可欠となった2。Amazon VPC Latticeは、基礎となる物理・仮想ネットワークのルーティングやIPアドレッシングからアプリケーション層の通信を切り離し、一元的な「サービスネットワーク」として抽象化する2。 VPC Latticeの根幹を成すのが、AWS IAMの署名バージョン4（SigV4）を用いたサービス間相互認証と、Cedarシンタックスに基づくLattice Auth Policy（認可ポリシー）である1。呼び出し元のIAMロール、送信元VPC、HTTPリクエストメソッド、URIパスを評価し、最小権限アクセスをトランザクション単位で強制する9。 2026年のリファレンス構成では、「Resource Configuration」および「Resource Gateway」の導入が標準化されている4。これにより、VPC Latticeエンドポイントを直接持たないAmazon RDSインスタンスやオンプレミスのレガシーシステム、他リージョンに存在するデータストアに対しても、IPアドレスの重複（Overlapping CIDR）を意識することなく、IAMベースの認可を付与したサービスメッシュ接続を透過的に提供できる4。リソース共有にはAWS Resource Access Manager（AWS RAM）が用いられ、中央集権的なガバナンスと各システム部門の自律的運用が両立される4。

AWS IAM Identity Center と Trusted Identity Propagation（TIP）

アイデンティティガバナンスの中心であるAWS IAM Identity Centerは、組織全体のIDフェデレーションを提供するだけでなく、OAuth 2.0に基づく「Trusted Identity Propagation（信頼されたアイデンティティの伝播：TIP）」を通じてデータアクセスの可視性と制御を大幅に刷新した15。 従来のアーキテクチャでは、フロントエンドやBIツールがバックエンドのデータストアにアクセスする際、汎用的なIAMロールを引き受ける（AssumeRole）ことで元のユーザーIDが隠蔽され、過剰な権限付与や監査ログの追跡不能を招いていた18。TIPはこの課題を根本から解消する15。クライアントアプリケーションが外部IdPのトークンをIAM Identity Centerのトークンと安全に交換し、AWS STSのsts:identity_contextを注入することで、バックエンドまでエンドユーザー自身の属性を透過させる17。 この仕組みにより、Amazon S3 Access Grants、Amazon Athena、Amazon Redshift、Amazon OpenSearch Service、さらにはAmazon Q Business等の生成AIサービスに至るまで、実ユーザーのIDに基づいた動的認可が実行される16。監査ログであるAWS CloudTrailにはonBehalfOfフィールドとして元のユーザー情報が直接記録され、厳格な監査可能性が担保される20。

データ境界（Data Perimeter）と Resource Control Policies（RCPs）

ゼロトラストをAWS組織全体に展開する基盤が「データ境界（Data Perimeter）」である21。AWSでは従来、Service Control Policies（SCPs）によるアイデンティティ統制と、VPCエンドポイントポリシーによるネットワーク経路制御を組み合わせていたが、新たにResource Control Policies（RCPs）が実装体系の中核に組み込まれた5。 RCPsは、AWS Organizations配下のリソース（Amazon S3、AWS KMS、AWS Secrets Manager、Amazon SQS、Amazon DynamoDB等）に適用される集中型リソース境界ポリシーである23。SCPsが自社組織内のIAMプリンシパルの最大権限を規定するのに対し、RCPsは「外部アカウントや未承認ネットワークからの自社リソースへの直接アクセス」を組織横断で拒否する23。aws:PrincipalOrgID、aws:ResourceOrgID、aws:SourceOrgID、aws:SourceVpcといった条件キーを連携させることで、「信頼されたIDが、信頼されたリソースにのみ、意図されたネットワークからアクセスする」という3条件を不可逆的に強制できる5。

2. CISA ZTMM v2.0 に基づくAWS 5本柱実装リファレンス

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）の「ゼロトラスト成熟度モデル（ZTMM）v2.0」は、組織が段階的にセキュリティを高めるための枠組みであり、「Identity」「Devices」「Networks」「Applications & Workloads」「Data」の5つの柱と、それらを支える3つの横断的機能（Visibility & Analytics、Automation & Orchestration、Governance）で定義される3。AWSネイティブ機能を活用し、最高水準である「Optimal（最適化）」段階を達成するための設計思想を各柱に沿って展開する3。

第1の柱：Identity（アイデンティティ）

CISA ZTMM v2.0におけるOptimal水準は、全アクセスにおけるフィッシング耐性のある多要素認証（MFA）の義務化、リスクコンテキストに基づく動的な認可、ジャストインタイム（JIT）での最小権限付与を要求する5。 AWSにおける実装では、AWS IAM Identity Centerを組織のマスターアカウントまたは委任管理者アカウントに配備し、Entra IDやOktaなどのエンタープライズIdPとSAML 2.0およびSCIMプロトコルで同期する16。FIDO2/WebAuthn規格に準拠したパスキーおよびハードウェアトークンを用いたフィッシング耐性MFAを全体に適用する。 さらに、Trusted Identity Propagationを活用してバックエンドのS3 Access Grantsや分析基盤にまでユーザーコンテキストを伝播させ、静的なIAMポリシーではなくユーザー属性に基づくアクセス制御（ABAC）を動的に実行する16。未使用の権限や過剰な権限に対しては、AWS IAM Access AnalyzerがCloudTrailログを継続的に解析し、実際の利用実績に即した最小権限ポリシーを自動生成・適用することで、権限の陳腐化を自律的に排除する。

第2の柱：Devices（デバイス）

デバイスの柱におけるOptimal水準では、組織が管理するすべての端末およびBYOD端末のリアルタイムインベントリ把握、継続的な健全性検証、および非準拠端末からのアクセス遮断が求められる3。 AWS上では、AWS Verified Access（AVA）のDevice Trust Provider連携がこの役割を担う4。CrowdStrike FalconやJamf ProなどのEDR/MDM基盤とAPIレベルで接続し、端末のディスク暗号化の有無、EDRエージェントの稼働状態、最新OSパッチの適用状況、リアルタイムなリスクスコアを取得する4。AVAのCedarポリシーにおいて「デバイスの脅威スコアが基準値以上であること」を通信許可の前提条件と定義することで、一度認証を通過した端末であっても、マルウェア感染や設定改変が検知された瞬間にセッションを無効化する動的アクセス遮断を実現する4。 また、機密データを端末ローカルに保持させないアプローチとしてAmazon WorkSpaces Secure BrowserやAppStream 2.0を併用し、暗号化ピクセルストリーミングによるデータ分離を徹底する2。

第3の柱：Networks（ネットワーク）

ネットワークの柱におけるOptimal水準は、IPアドレスやサブネットCIDRに依存した大括りの境界防御を完全に解体し、アプリケーションワークフローを中心とした分散型マイクロセグメンテーションの構築と、全通信経路の完全暗号化を規定する。 AWSでは、Amazon VPC Latticeを中核に据えたアーキテクチャがこの要件を満たす2。ワークロード間の通信は、フラットなVPCピアリングや広域Transit Gatewayメッシュを介さず、Latticeサービスネットワークを通じてL7レベルで接続される4。通信はトランスポート層で相互TLS（mTLS）により自動暗号化され、さらにアプリケーション層においてIAM SigV4によるリクエスト単位の署名検証とCedar認可ポリシーが評価される2。 境界の出入口においては、AWS Network FirewallおよびRoute 53 Resolver DNS Firewallを配置して外部宛て通信をFQDNベースで厳格にフィルタリングし、不審なC2サーバーへの通信をプロアクティブに遮断する。これらすべてのルーティングおよびアクセス制御はTerraform等のIaCによって宣言的に定義され、手動による設定ドリフトを根絶する3。

第4の柱：Applications & Workloads（アプリケーションとワークロード）

アプリケーションの柱におけるOptimal水準は、認可ロジックの中央集権的な外部化、CI/CDパイプライン全体へのセキュリティ検証の統合、およびイミュータブルな実行基盤の維持を志向する5。 AWSでの中核コンポーネントはAmazon Verified Permissions（AVP）である1。個々のマイクロサービス内にハードコードされがちだった認可ロジックを排除し、Cedar言語で記述されたポリシーとしてAVPへ外部化する4。これにより、アプリケーションの再デプロイを伴わずに認可ポリシーの追加・変更・監査が可能となる4。 コンテナ実行環境（Amazon EKSおよびECS）では、IAM Roles for Service Accounts（IRSA）やEKS Pod Identityを採用し、Pod単位での一時的最小権限IAMクレデンシャルを動的に払い出す。さらに、コンテナイメージやサーバーレスコードに対してはAWS Signerを用いた暗号署名を義務付け、デプロイ時に署名検証を行うことで、改ざんされたコードの実行を防止する。

第5の柱：Data（データ）

データの柱におけるOptimal水準は、保存時・転送時の包括的な暗号化、データ分類に基づく動的アクセス制御、不正持ち出しの防止、および耐タンパー性を持つ不変バックアップの保持を要求する3。 AWSにおける実装では、AWS KMSカスタマーマネージドキー（CMK）による多重暗号化を基本とし、キーポリシーにおいて未承認の組織外プリンシパルや想定外のネットワーク経路からの復号操作を厳密に制限する5。Amazon Macieを活用してS3バケット内の機密情報（PII、機密データ）を常時検出・分類し、その分類タグに連動してS3 Access Grantsが最小権限のアクセス権を動的に割り当てる20。 組織横断のデータ境界としては、Resource Control Policies（RCPs）とVPCエンドポイントポリシーを適用し、意図しない外部アカウントへのデータ転送をアーキテクチャレベルで防護する5。そして、ランサムウェア等の破壊的インシデントに備え、AWS Backup Vault Lock（Compliance Mode）およびS3 Object LockによるWORMストレージを構成し、データの改変・削除を物理的・論理的に遮断する30。

3. AWSゼロトラスト構成コンポーネント対応表

CISA ZTMM v2.0の各柱および横断的機能要件に対して、AWSネイティブサービス、技術的役割、制御レイヤー、および達成される成熟度レベルの体系的な対比を下表に示す5。

4. 不変バックアップとクリーンルーム復旧環境（IRE / DRaaS）の耐ランサムウェア設計

ゼロトラストモデルでは、境界防御の突破や内部特権アカウントの侵害を想定内に置く「Assume Breach（侵害受容）」の姿勢が根本にある34。攻撃者が管理権限を掌握した場合でも、事業継続性を担保し得る耐タンパー性を持った不変バックアップと、感染拡大を防ぎつつシステムを再建するクリーンルーム環境（Isolated Recovery Environment: IRE）の設計が不可欠である31。

AWS Backup Vault Lock と S3 Object Lock の設計基準

現代のランサムウェアは、本番データを暗号化する前にバックアップの無効化や削除を試みる32。これに対抗するため、WORM（Write Once, Read Many）特性を備えたストレージロックを構成する30。 AWS Backup Vault Lockには「ガバナンスモード」と「コンプライアンスモード」が存在するが、ゼロトラスト環境では「コンプライアンスモード」の適用が標準要件となる31。コンプライアンスモードでは、初期設定時に設定した猶予期間（changeable_for_days、最低3日間）を過ぎると、AWSアカウントのルートユーザー、IAM特権管理者、さらにはAWSサポートであっても、ロックの無効化や保持期間内の復旧ポイント（Recovery Point）の削除が技術的に不可能となる31。Amazon S3上の独自ストレージに対しても、S3バージョニングとS3 Object Lock（Compliance Mode）を組み合わせ、保持期間中のオブジェクト削除や上書きを完全に遮断する。 ここで重要なトレードオフは暗号鍵（KMS）のライフサイクル管理である33。バックアップボールトをカスタマーマネージドキー（CMK）で暗号化している場合、攻撃者によってCMK自体が無効化または削除スケジュールに投入されると、ボールト内のデータが保護されていても復号不能に陥る危険がある33。このリスクを回避するため、CMKのキーポリシーにおいてkms:ScheduleKeyDeletionやkms:DisableKeyをSCPで組織的に禁止するか、あるいは暗号鍵自体の削除が不可能なAWSサービス所有キー（AWS-owned key）を採用する二重の防御策を講じる31。

論理的エアギャップボールト（Logically Air-Gapped Vault）

AWS Backupの論理的エアギャップボールトは、バックアップデータを顧客のAWSアカウントから物理的・論理的に隔離された「AWSサービス所有のアカウント」配下の不変ボールトに格納するアーキテクチャである。 この設計により、本番アカウントのIAMコントロールプレーンが全面的に侵害された場合でも、バックアップデータの実体に対するアクセス経路が隠蔽される。DynamoDB、S3、EFSなどのフルマネージドサービスは、追加のストレージ転送コストを発生させることなく、サービス所有アカウント内の不変ボールトへ直接バックアップを配置できる。

クリーンルーム復旧環境（IRE / DRaaS）のアーキテクチャパターン

本番環境が深刻な侵害を受けた際、汚染された既存環境内でリストア作業を行うことは、マルウェアの再活性化や潜在的なバックドアの見落としにつながるため厳禁である。したがって、本番環境から完全に切り離された「クリーンルーム（IRE）」を独立したアカウントとして立ち上げ、安全に復旧・検証・リビルドを行う構成を採用する21。

単一AWS Organizations内でのIRE展開モデルでは、本番アカウントと同一組織内の隔離された「IREアカウント」を用意する。本番アカウントとIREアカウント間には、VPCピアリング、Transit Gatewayアタッチメント、IAMの信頼関係を一切設定しない。本番アカウントが保持する論理的エアギャップボールトは、AWS Resource Access Manager（AWS RAM）を介してのみIREアカウントに共有される。IRE側は共有されたボールトから、隔離されたVPC内のクリーンなコンピュート環境へ復旧ポイントをリストアする。この環境は外部インターネットへの出口を持たず、AWSマネージドサービスとの通信はすべてVPCエンドポイント（AWS PrivateLink）経由に限定される。

さらに高度な脅威モデルに対応するため、組織全体のルートアカウントや統合IdPの侵害を想定した「2つのAWS Organizations構成」が策定されている。この構成では、本番用のプライマリOrganizationとは完全に分離された、独立したIdPと管理者を持つ「復旧専用Organization（Recovery Organization）」を構築する。 復旧Organization内のIREアカウントからバックアップデータへアクセスする際には、マルチパーティ承認（MPA: Multi-party approval）プロセスを介在させる。複数の指定承認者による暗号署名と承認が完了して初めて、プライマリ側のボールトを読み取り専用マウントする「復元アクセス用バックアップボールト（Restore Access Backup Vault）」が払い出される。この方式は物理的なデータコピーを伴わないため、数百テラバイトを超えるデータであっても、データ転送コストと時間をゼロにして瞬時にクリーンルームへマウントできる利点を持つ。

自動検証パイプライン（AWS Backup Restore Testing）

リストア手順が有事の際に確実に動作するかを担保するため、AWS Backupの「Restore Testing」機能を用いた自動検証パイプラインを運用する37。 Restore Testingは、スケジュールに従ってIRE環境内のテスト用VPCへ自動的に復旧ポイントをリストアする26。リストア完了時に発行されるEventBridgeイベントをトリガーとしてAWS LambdaまたはStep Functionsが起動し、データベースへのヘルスチェッククエリ実行、データの整合性検証、およびAmazon GuardDuty Malware Protectionによるマルウェアスキャンを自律的に実施する38。検証完了後は、生成された一時リソースが自動的に削除（Clean-up）されるため、最小限のコストで継続的な復旧可能性（Restore Viability）を証明し続けることができる26。

5. 経営企画部向け知見：ゼロトラスト推進がもたらす事業アジリティ・内部統制・投資対効果

ゼロトラストアーキテクチャの導入は、単なるIT部門のセキュリティ強化策にとどまらず、全社的な経営基盤の刷新、事業継続性の担保、および企業価値向上に直結する戦略的投資である。経営企画部門が認識・活用すべき主な経営的知見は以下の通りである。

1. ネットワーク統廃合とM&A・事業再編の迅速化（事業アジリティ向上とTCO削減）

従来のペリメタ（境界型）防御モデルでは、企業の合併・買収（M&A）やグループ会社再編の際、ネットワーク同士を物理的・論理的に結合（専用線敷設、IPアドレス重複の解消、広域VPNメッシュ構築）する必要があり、システム統合に半年から1年以上の期間と数千万円から数億円規模のインフラ統合コストが発生していた。 Amazon VPC LatticeやAWS Verified Accessの導入により、インフラ基盤の結合を行わずにアプリケーション層で直接かつ安全に通信を相互接続できるようになる2。これにより、以下の経営的メリットが得られる。

• Time-to-Valueの劇的短縮: M&A対象企業の既存ネットワーク環境に手を加えることなく、必要な業務システムのみを即座に相互接続できるため、事業シナジーの早期創出が可能となる。
• IT保有コスト（TCO）の構造的低減: 拠点ごとに高額な帯域を確保していた閉域網専用線やVPN集約機器の更新費用（CAPEX）、および24時間365日のネットワーク機器保守運用コスト（OPEX）を大幅に削減できる2。

2. Policy-as-Code（コードによる統制）による内部統制と監査コストの最小化

ゼロトラスト環境におけるアクセス認可ロジック（Cedar言語等）やセキュリティ境界をコード化・自動プロビジョニングする仕組みは、経営企画・内部統制部門にとって「統制活動の自律化」をもたらす1。

• ヒューマンエラーと内部不正リスクの排除: 人手による手動設定変更や特権管理者による恣意的な権限変更をシステム的に排除し、全社共通のセキュリティポリシーを均一かつ強制的に適用できる。
• 監査対応工数・費用の劇的圧縮: 「誰が、どの端末から、どのデータにアクセスできるか」というポリシーがコード化され、Gitのコミット履歴およびAWS CloudTrail（onBehalfOf属性）に完全なログとして残るため、J-SOX、個人情報保護法、各業界ガイドラインへの準拠証明が容易になる1。これにより、年次監査対応にかかる現場の稼働負荷および外部監査費用を大幅に低減できる。

3. サイバーレジリエンスと不可逆設定に伴う財務・運用のトレードオフ管理

ランサムウェア攻撃によって基幹業務が全面停止した場合の経済的損失（日商単位の売上喪失、サプライチェーン停止損害賠償、社会的信用の失墜）は、数億円から数十億円に達するケースが散見される。AWS Backup Vault Lock（コンプライアンスモード）による不変バックアップとクリーンルーム復旧環境（IRE）の構築は、いわば「事業継続のための不可欠な損害保険」としての役割を果たす33。 一方で、経営企画部門は導入にあたって以下の「財務・運用上のトレードオフ」を把握し、統制ルールを策定しておく必要がある。

• ストレージコストの固定化リスク: コンプライアンスモードのVault Lockは、猶予期間（最低3日間）を過ぎると、自社の最高経営責任者（CEO）やシステム管理者、さらにはAWS社であっても、指定保持期間中のデータ削除やロック解除が法的に不可能な設計となっている33。万が一、不要な大容量データを誤って不変指定した場合、そのストレージ費用は保持期間終了まで必ず発生し続けることになる33。
• ガバナンス規則の制度化: したがって、全社的に何を守るべき重要データ（Tier 1）と定義し、どの保持期間（RPO/RTO）を設定するのかについて、IT部門任せにせず、事業継続計画（BCP）および財務予算と整合した全社ガイドラインを経営主導で制定することが求められる。

6. フェーズドアプローチ（1年〜2年）の実装ステップ別更新事項

ゼロトラストアーキテクチャの導入は、広範なインフラ、ネットワーク、アイデンティティ、運用プロセスの刷新を伴うため、2年間のフェーズドアプローチにより段階的にリスクを抑えながら成熟度を向上させる27。

実装ロードマップ概要表

ステップ別実装詳細とアーキテクチャ更新事項

Phase 1: アイデンティティ基盤確立とデータ保護初動（0〜6ヶ月）

移行の最初の半年間は、すべてのセキュリティ制御の拠り所となる信頼性の高いアイデンティティ基盤の構築と、データの初動保護に集中する。AWS Organizations配下でIAM Identity Centerを有効化し、Entra IDやOktaなどのコーポレートIdPとの間でSAML 2.0フェデレーションおよびSCIM自動プロビジョニングを確立する。個別アカウント内に散在していた静的IAMユーザーや長期間有効なアクセスキーは全面的に棚卸しを行い、廃止に向けた猶予期間を設定する。 認証セキュリティにおいては、SMSや認証アプリによるMFAを排除し、FIDO2/WebAuthnに準拠したパスキーおよびハードウェアトークンによるフィッシング耐性MFAを全従業員に義務付ける。 組織統制においては、AWS Control Towerのランディングゾーンを活用し、ガードレールSCPを適用する21。さらに、S3およびKMSを保護対象とするResource Control Policies（RCPs）をパイロット導入し、自社Organization外からのアクセスを一括遮断するデータ境界の基礎を固める1。 データ保護の観点では、AWS Backupを一元展開して重要データベースやストレージのバックアップスケジュールを集約し、運用確認と設定調整のためにまずはガバナンスモードにてVault Lockを構成する33。

Phase 2: 境界レスアクセスとデータアクセスコントロールの展開（6〜12ヶ月）

第2フェーズでは、エンドユーザーの通信経路から旧来のVPNを排除し、データ層に対する直接的なきめ細かな認可を導入する。社内の主要なWebポータルや業務システムを対象にAWS Verified Access（AVA）を配備し、インターネット経由のセキュアなアクセス経路を開設する6。AVAのDevice Trust Provider機能を通じてCrowdStrike Falcon等のEDRエージェントと接続し、Cedar言語によって「端末の暗号化状態が有効であり、セキュリティリスクが一定以下であること」をアクセスの必須要件として組み込む4。 データレイヤーにおいては、大規模なデータレイク環境を中心にAmazon S3 Access Grantsを展開する。IAM Identity CenterのTrusted Identity Propagation（TIP）と連携させることで、従来の肥大化したS3バケットポリシーに依存することなく、企業ディレクトリ内のグループ属性に基づいてS3のプレフィックス単位で直接アクセスを許可する。これにより、エンドユーザーがBIツールやAthenaを介してクエリを実行した際、実際のユーザーIDがCloudTrailのonBehalfOfとして記録され、データアクセスの完全な可監査性が成立する16。 また、Phase 1で安定稼働を確認したAWS Backupのボールトロックをコンプライアンスモードへ昇格させ、3日間の猶予期間満了をもって不可逆なWORMストレージへと確定させる33。

Phase 3: サービス間ゼロトラストと復旧環境（IRE）確立（12〜18ヶ月）

第3フェーズでは、システム内部の東西（East-West）トラフィックのゼロトラスト化と、ランサムウェアに備えたクリーンルーム復旧基盤を構築する。各VPC間のフラットなルーティング（Transit Gatewayやピアリング）を解体し、Amazon VPC Latticeによるサービスメッシュへと移行する2。VPC Latticeサービスに対してauth_type = "AWS_IAM"を義務付け、マイクロサービス間の全通信にIAM SigV4署名とLattice Auth Policy（Cedar）によるリクエスト単位の認可を課す1。 また、Lattice Resource GatewayとResource Configurationをデプロイし、共有RDSインスタンスやオンプレミスのレガシーシステムに対しても、IP枯渇やCIDR重複の制約を受けずにサービスネットワーク経由で安全に接続できる経路を確立する29。 事業継続性の確立においては、本番環境と一切の信頼関係やネットワーク経路を持たない隔離復旧アカウント（IREアカウント）を構築する。本番アカウントの論理的エアギャップボールトをAWS RAMを通じてIREに読み取り専用共有し、外部通信を遮断したサンドボックスVPC内で安全に復旧できるアーキテクチャを整備する。さらに、AWS Backup Restore Testingを導入して週次で自動リストアを実行し、Lambdaを用いたデータ整合性チェックとマルウェアスキャンを実施した後に自動破棄する検証パイプラインを本番稼働させる26。

Phase 4: 最適化（Optimal）達成と自律的セキュリティ（18〜24ヶ月）

最終フェーズでは、CISA ZTMM v2.0のOptimal水準に到達すべく、アプリケーション認可の外部化とインシデント対応の完全自動化を完備する。業務アプリケーション内に分散していたロール・属性ベースの認可ロジックをAmazon Verified Permissions（AVP）へ移行し、Cedarポリシーによる一元管理と数学的検証を標準化する4。 生成AI基盤（Amazon BedrockやAmazon Q Business）に対してもIAM Identity CenterのTIPを完全適用し、ナレッジ検索（RAG）時にユーザーの権限外データがモデルに取得されないコンテキスト保護を徹底する18。 組織全体のデータ境界においては、SCP、RCP、VPCエンドポイントポリシーの相互補完関係を完成させ、外部からの不正アクセスやデータの持ち出しをアーキテクチャ的に封鎖する1。IAM Access AnalyzerやSecurity Hubがポリシー違反や不審な挙動を検知した際には、EventBridgeを介して侵害された認証情報やリソースを即座に自動無効化・隔離するSOARメカニズムを定着させる4。 さらに、最悪のシナリオである組織全体のID侵害を想定し、復旧専用Organizationを配備した2 Organizations構成のIREモデルを稼働させ、マルチパーティ承認（MPA）に基づく復旧演習を定期実施することで、数時間以内のクリーンルーム復旧を実証可能なサイバーレジリエンスを完成させる。

7. 結論と戦略的提言

2026年におけるAWSのゼロトラストアーキテクチャは、境界防御の単なる補強ではなく、インフラ、アイデンティティ、アプリケーション、データの各レイヤーが疎結合でありながら緊密に連携する統合プラットフォームとして機能する1。

本アーキテクチャを成功裏に実装・運用するために不可欠な技術的指針を以下に総括する。

ネットワーク境界からアイデンティティおよびリソース境界への完全な移行を果たすことが最も重要なパラダイムシフトである。IPアドレスやサブネット設計をセキュリティの根拠とするアプローチを廃止し、AWS Verified Accessによるコンテキスト認識型アクセスと、Amazon VPC Latticeによるサービスメッシュへ切り替えることで、ネットワークトポロジーに縛られない動的な最小権限制御を実現できる1。

次に、アイデンティティコンテキストをデータレイヤーまで透過させる設計の徹底が求められる。IAM Identity CenterのTrusted Identity Propagation（TIP）とAmazon S3 Access Grantsを組み合わせることで、従来のAssumeRoleによるユーザー情報の不可視化を排除し、ストレージや分析基盤に至るまで真の最小権限とエンドツーエンドの監査可能性を確立できる15。

そして、侵害を前提（Assume Breach）とした耐タンパー性の確保がサイバーレジリエンスの根幹を成す。AWS Backup Vault Lock（Compliance Mode）による不可逆なWORMストレージの維持と、本番環境から完全に隔離されたクリーンルーム復旧環境（IRE）の構築は、ランサムウェア攻撃から事業を防御するための防壁である21。これらのインフラおよび復旧プロセスをTerraformによって完全にコード化し、定期的な自動リストアテストを通じて復旧可能性を実証し続けることが、次世代のクラウドセキュリティ戦略において極めて重要となる10。

引用文献

1. Securing Your AWS Infrastructure: A Zero Trust Approach, https://repost.aws/articles/ARDWfm5wKhROyIzu8gghrHKw/securing-your-aws-infrastructure-a-zero-trust-approach
2. Zero trust on AWS | Security, Identity, and Compliance, https://aws.amazon.com/security/zero-trust/
3. 5 Zero Trust Pillars: CISA ZTMM 2.0 Model Explained - InterSec, Inc., https://www.intersecinc.com/blogs/zero-trust-the-five-pillars-of-cisa-maturity-model
4. Amazon VPC Lattice: modernize and simplify your enterprise ... - AWS, https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-vpc-vattice-modernize-and-simplify-your-enterprise-network-architectures/
5. Perimeter overview - Building A Data Perimeter on AWS, https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/perimeter-overview.html
6. AWS Verified Access and Amazon VPC Lattice as PE, https://pages.nist.gov/zero-trust-architecture/VolumeC/HowTo-E4B5.html
7. aws_verifiedaccess_endpoint | Resources | hashicorp/aws | Terraform, https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/verifiedaccess_endpoint
8. Securely Connecting to Private RDS Instances Using AWS Verified, https://towardsaws.com/securely-connecting-to-private-rds-instances-using-aws-verified-access-d044779b539f
9. AWS VPC Lattice Complete Guide - Service-to-Service Networking, https://hidekazu-konishi.com/entry/aws_vpc_lattice_complete_guide.html
10. GitHub - aws-samples/moving-to-a-zero-trust-architecture-in-aws, https://github.com/aws-samples/moving-to-a-zero-trust-architecture-in-aws
11. aws-ia/terraform-aws-amazon-vpc-lattice-module - GitHub, https://github.com/aws-ia/terraform-aws-amazon-vpc-lattice-module
12. Resource configurations for VPC resources - Amazon VPC Lattice, https://docs.aws.amazon.com/vpc-lattice/latest/ug/resource-configuration.html
13. Resource gateways in VPC Lattice - AWS Documentation, https://docs.aws.amazon.com/vpc-lattice/latest/ug/resource-gateway.html
14. Access VPC resource over Lattice? | AWS re:Post, https://repost.aws/questions/QUJsySbrCiSvSM4elbtvU1Vg/access-vpc-resource-over-lattice
15. Trusted Identity Propagation with IAM Center - AWS, https://aws.amazon.com/de/video/watch/30d8c3577ce/
16. Trusted identity propagation overview - AWS IAM Identity Center, https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-overview.html
17. Federating S3 Access Grants with IAM Identity Center Trusted, https://devopstar.com/2024/07/27/federating-s3-access-grants-with-iam-identity-center-trusted-identity-propagation/
18. [レポート] 複数IDプロバイダーをAmazon Qと統合するCognitoとIAM, https://dev.classmethod.jp/articles/reinvent-20240sec-309/
19. IAM Identity Center を使用した Amazon OpenSearch Service の信頼, https://aws.amazon.com/jp/blogs/news/trusted-identity-propagation-using-iam-identity-center-for-amazon-opensearch-service/
20. Amazon S3 Access Grants とは何か。何が嬉しいのか。 - Qiita, https://qiita.com/hayao_k/items/e96471bd1874585985b1
21. Data Perimeters on AWS | AWS Identity | Amazon Web Services (AWS), https://aws.amazon.com/identity/data-perimeters-on-aws/
22. Establishing a data perimeter on AWS: Overview | AWS Security Blog, https://aws.amazon.com/blogs/security/establishing-a-data-perimeter-on-aws/
23. Creating a Data Perimeter with Resource Control Policies (RCPs, https://www.fogsecurity.io/blog/data-perimeters-with-resource-control-policies-and-aws-kms
24. AWS Resource Control Policies (RCPs) Explained - Native Security, https://www.native.security/cloud-docs/aws-rcp
25. Intro to AWS Resource Control Policies (RCPs) - DEV Community, https://dev.to/aws-builders/new-aws-resource-control-policies-rcps-45k2
26. AWS expands Resource Control Policies support to Amazon, https://aws.amazon.com/about-aws/whats-new/2026/02/aws-expands-resource-control-policies-amazon/
27. CISA Zero Trust Maturity Model Whitepaper - Zscaler, Inc., https://www.zscaler.com/resources/white-papers/cisa-zero-trust-maturity-model.pdf
28. Understanding the Zero Trust Maturity Model V 2.0 - ThreatLocker, https://www.threatlocker.com/blog/understanding-the-zero-trust-maturity-model-v-2-0
29. [レポート] VPC LatticeとAmazon Verified Permissionsで構築する, https://dev.classmethod.jp/articles/hands-on-with-zero-trust-building-secure-application-architecture/
30. AWS Architect Job at Black Rock Group in Albany, NY, https://www.ziprecruiter.com/c/black-rock-group/Job/Lead-AWS-Cloud-Security-Architect/-in-Albany,NY?jid=4b4cc9bfb859e5f4
31. Cyber recovery on AWS: A reference approach for recovering from, https://aws.amazon.com/blogs/architecture/cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events/
32. AWS Backup Vault LockでDBバックアップ自体のセキュリティを, https://zenn.dev/aran1201sanjose/articles/aws-backup-vault-lock
33. Controls implemented with resource control policies (RCPs), https://docs.aws.amazon.com/controltower/latest/controlreference/rcp-controls.html
34. Zero Trust Frameworks Crosswalk - ACT-IAC, https://www.actiac.org/system/files/2025-10/Zero%20Trust%20Frameworks%20Crosswalk_1.pdf
35. aws_backup_vault_lock_configu, https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/backup_vault_lock_configuration
36. Ensure that Backup Vault should be locked - CloudGuard GSL KB, https://gsl.dome9.com/D9.AWS.BDR.20.html
37. Restore testing - AWS Backup, https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html
38. Implementing restore testing for recovery validation using AWS, https://aws.amazon.com/blogs/storage/implementing-restore-testing-for-recovery-validation-using-aws-backup/
39. aws_vpclattice_service | Resources | hashicorp/aws | Terraform, https://registry.terraform.io/providers/-/aws/latest/docs/resources/vpclattice_service
40. Trusted identity propagation use cases - AWS Documentation, https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-integrations.html
41. How to setup Corporate Identity Access at scale in AWS?, https://dev.to/afrazkhan/how-to-setup-corporate-identity-access-at-scale-in-aws-3jol