クラウドセキュリティの議論は抽象化されがちですが、組織の優先度は明確です。守るべき資産を定義し、侵入を前提に「検知から封じ込め・復旧」までを最短距離で回せる状態をつくることです。ここでのキーワードが「責任共有モデル」です。AWSは「クラウドのセキュリティ」を担い、利用者は「クラウド内のセキュリティ」の責任を負います。この境界の理解がすべての出発点になります。

引用：Shared Responsibility Model の要点は、インフラの保護はAWS側、アイデンティティやデータ保護・設定の正しさは利用者側という分担にある
※ 詳細はAWS公式の説明を参照

ゼロトラストの設計思想は「ネットワークの場所ではなく、アイデンティティ中心で評価する」ことに軸足を移します。NISTのガイダンスもこの方向に揃っており、我々の設計判断を裏付けます。

2025年のAWSセキュリティ主要トピック

2024年〜2025年にかけて、運用設計を変えるレベルの更新が続きました。要点を運用インパクトの観点で整理します。

ルートユーザーのMFA必須が全アカウントへ拡大

2025年6月、ルートユーザーへのMFA要件が「すべてのアカウントタイプ」に拡大されました。Organizations配下も含めて前提が変わったため、アカウント管理の設計見直しが必要です。

加えて、2024年から「パスキー」をMFA方式として公式サポート。フィッシング耐性の高いFIDO2系を組織標準に据える判断が現実的になりました。

検知と対応の統合が進展

「Security Hub」の新しい体験（プレビュー）は、リスクの優先度付けとスケール対応を強化する方向です。運用に直結する「見る場所の統合」が進みます。

一方で「GuardDuty」は拡張脅威検出を一般提供し、複数のデータソースをまたぐ攻撃シーケンスを把握できるようになりました。一次分析の負担軽減に効きます。

ガバナンスの強化と標準化

「Control Tower」は2025年4月に管理ルールを大幅拡充し、223のAWS Configマネージドルールをカタログ化。OU単位でのガードレール標準化が加速します。

また「IAM Access Analyzer」はカスタムポリシーチェックで、公開や重要リソースへの過剰権限をデプロイ前に弾けます。変更加速と安全性の両立に有効です。

ゼロトラスト実装の現実解

「Verified Access」が非HTTPSプロトコル（SSHやRDPなど）にも広げるプレビューを提供。VPNレスでゼロトラストを広げる現実解が見えてきました。

アプリ側の認可は「Verified Permissions」が価格改定でコスト障壁を下げ、全アクションにきめ細かな認可チェックをかける設計が取りやすくなりました。

変更リリースと運用監査の安全性

ECSにネイティブな「ブルー/グリーンデプロイ」が入り、合成トラフィック検証や即時ロールバックをECS標準で完結できるようになりました。変更由来のインシデント確率を下げられます。

監査・調査面では「CloudTrail Lake」がイベント拡張やサイズ拡大に対応し、セキュリティデータレイクの実運用に適します。

基盤アーキテクチャの原則と最小構成

設計の土台は「アイデンティティ中心」「データ境界の明確化」「変更の安全性」です。ここでは、AWSの機能に寄せた最小構成の考え方を提示します。

まず、計算基盤の隔離は「Nitro System」のハードウェア分離を前提に取るのが肝です。管理者がゲストOSへ侵入する余地を排した設計は、現代のマルチテナント基盤の安心材料になります。

ストレージについては、S3のデフォルト暗号化とパブリックアクセスブロックを前提にした設計が基本線です。

表 最小構成ベースライン（2025年時点）
以下は、まず押さえるべきベースライン構成と狙いを整理したものです。実装の前提と運用品質の期待値をチーム間で共有するための一覧です。

説明：ベースラインは「全有効→例外申請」の流儀に寄せ、個別チームの自由度はアプリ層の実装で担保します。各領域の一次情報は、それぞれのAWSドキュメント・ブログを根拠としています。

参考：AWS Identity and Access Management が 2 番目の認証要素としてパスキーのサポートを開始

現実的な実装ロードマップ（90日で「見える化」まで）

短期で「効いている」状態をつくるための順序を提示します。手戻りが少ない並べ方です。

設計判断の背景と考察

抽象論を避け、なぜその順序と構成なのかを明確にしておきます。

• 「MFA（パスキー）」を起点にする理由は、権限奪取の最短経路を潰す効果が群を抜いて高いからです。AWS自体がMFA必須を段階的に拡大し、パスキー対応を進めてきた流れはその裏付けと言える
• 「検知の統合」は運用体験の問題であり、Security Hubの統合とGuardDutyの拡張は、一次分析の手間を減らし、真に重大なイベントへ時間を振り向けるための投資
• 「変更の安全性」をセキュリティの守備範囲と捉えるべき、ECSのブルー/グリーンは、リリース由来の障害を減らし、インシデント対応の余力を残す
• 「ゼロトラスト」はツール名ではなく、Verified AccessやVerified Permissionsは、ネットワーク境界依存からの脱却を現実的なコストで支える部品。価格面の改善も進み、適用範囲を広げやすくなっている

よくある落とし穴と回避策

以下は、導入現場で頻出するつまずきと対処の勘所である。

実運用での「観測と継続改善」

Well-Architectedの「セキュリティの柱」は、運用で成熟させるためのチェックリストでもあります。四半期ごとに自己診断し、コントロールの実効性（MFA普及率、検出からチケット起票までの遅延、例外件数など）を定点観測していくと改善が進みます。

観測の基盤はCloudTrail Lakeをハブに据え、GuardDutyの検出、Security Hubの集約、VPC Latticeでのサービス間可視化を合わせると、横移動や権限悪用の痕跡を横断で追いやすくなります。

まとめ――「セキュア・バイ・デザイン」を今の現場に落とす

クラウドは「設定が仕様」です。2025年のAWSは、利用者側の責任を果たしやすくするための標準装備を着実に増やしました。ルートMFAとパスキー、Security HubとGuardDutyの組み合わせ、Control Towerのガードレール、Verified系サービスによるゼロトラストの現実解、ECSの安全なリリース、CloudTrail Lakeの調査基盤。この組み合わせで、スピードと安全性は両立できます。

最後に、AWS自身の責任範囲に過度な期待を寄せず、我々の構成と運用の品質で差がつくことを改めて強調します。責任共有モデルの線引きを理解し、最小構成のベースラインから一歩ずつ固めていくことが、結果として事業の速度を上げます。