マネージドサービス部 佐竹です。
AWS re:Inforce 2025 に現地参加してきましたので、そのログを順番に記述しています。今回はついに AWS re:Inforce 2025 の基調講演（キーノート）のまとめとポイントとなっています。
- はじめに
- 序章：新たな CISO が語る、セキュリティという名の「イノベーションの加速器」
- 主要な発表内容まとめ
- 第一章：基本の徹底 - IDおよびアクセス管理
- 第二章：境界線の強化 - データおよびネットワーク保護
- 第三章：統合セキュリティ運用 - モニタリングおよびインシデント対応
- 第四章：リフト＆シフトを越える - クラウド移行とモダナイゼーション
- 終わりに
- 関連記事等
- まとめ
はじめに
2025年6月16日から18日にかけて、ペンシルベニア州フィラデルフィアで AWS のセキュリティに特化したカンファレンス「AWS re:Inforce 2025」が開催されました。
本ブログは「【AWS re:Inforce 2025】現地参加レポート 2日目 6月17日(火) 佐竹版」よりキーノート（基調講演）である SEC200 Simplifying security at scale (AWS re:Inforce 2025 - Keynote with Amy Herzog) について記載します。
キーノートのまとめは既に様々出ているかと思いますため、ここでは私なりの視点も含め、個別のアップデートを点としてそれらがどのように線として繋がるかという、主にナラティブ（物語）にフォーカスした内容を記載していきます。
なお、本ブログは Amy Herzog 自身が記載した「How AWS is simplifying security at scale: Four keys to faster innovation from AWS re:Inforce 2025」も合わせてその情報源として利用し、情報の正確性に注意を払っています。
序章：新たな CISO が語る、セキュリティという名の「イノベーションの加速器」
2025年の AWS re:Inforce は、単なる新機能発表の場ではありませんでした。それはクラウドセキュリティの役割そのものを再定義し、未来の方向性を示したものとなっていました。
物語の語り部は、新たに AWS の CISO に就任した Amy Herzog です*1。
先の Amy Herzog 自身が記載したブログ本文にもある通り、Amy は「システムを保護することは生産性を犠牲にするという事実を多くの人が受け入れていました」と記載しています。つまりセキュリティと生産性には「トレードオフの関係があった」ということです。
ですが、AWS クラウドにおいては、もはやそれは成り立ちません。むしろセキュリティが安全性を担保し、イノベーションを加速させるのです。
この点については、私も同意します。
本画像は、「AWS Organizations における推奨 OU 構成のベストプラクティス2025年度最新版を学ぶ」で紹介したプレゼン（ブースセッション）資料からの抜粋ですが、私も長らくこのナラティブを大事にして話をしています。つまり「ガードレールが敷設されることで、安心して AWS を利用することが可能となる」のです。
Amy が提示した核心的なメッセージも同様で、このキーノート全体のテーマとなります。
「適切に実践されたセキュリティは、ビジネスの障壁ではなく、真の加速器（business accelerator）であり、生成 AI のような新技術導入の実現要因（enabler）である」、と。
このビジョンは、現代のテクノロジーが直面する「複雑性の増大」という課題認識から生まれています。
ツールの乱立とそれによる「認知負荷（Cognitive load）」*2がイノベーションを阻害する中、AWS は「簡素化（Simplifying）」を戦略の中心に据えました。これは単なるスローガンではなく、生成 AI の活用というイノベーションの波を、すべての企業が安全に乗りこなせるようにするための、意図的な戦略です。
Amy 自身が記載した先のブログ本文にも「彼らはイノベーションに熱心ですが、その意欲的な取り組みをセキュリティ基盤がしっかりと支えられるという安心感を必要としています」と記載している通りでもあります。
キーノートは、イノベーションを加速させる強固なセキュリティ基盤を構築するための4つの柱を中心に展開されました。
本ブログでは、その物語の流れに沿って、私なりに解釈した以下の章立てで各アップデートを解説していきます。
- 第一章：基本の徹底 - IDおよびアクセス管理
- 第二章：境界線の強化 - データおよびネットワーク保護
- 第三章：統合セキュリティ運用 - モニタリングおよびインシデント対応
- 第四章：リフト＆シフトを越える - クラウド移行とモダナイゼーション
上記の章立てを用いて、本ブログを掲載していきます。
主要な発表内容まとめ
先に、キーノートで発表された主要な発表をまとめます。順序はキーノートでの発表順となっています。
| 発表・機能名 | 関連サービス | 状況 | 主要機能 |
|---|---|---|---|
| IAM Access Analyzer 内部アクセス検出 | AWS IAM Access Analyzer | GA*3 | 組織内のプリンシパルがどの重要リソースにアクセス可能かを自動推論で検証 |
| ルートユーザーへの MFA 強制 | AWS IAM | 適用済み | 全ての AWS アカウントタイプでルートユーザーの MFA を必須化 *4 |
| ACM 公開証明書のエクスポート機能 | AWS Certificate Manager | GA | ACM で発行した公開証明書と秘密鍵をエクスポートし、AWS 内外のワークロードで使用可能に |
| AWS Shield ネットワークセキュリティディレクター | AWS Shield | Preview | ネットワーク構成をプロアクティブに分析し、セキュリティリスクを可視化・優先順位付け |
| AWS WAF コンソールの簡素化 | AWS WAF | GA | 設定ウィザードと保護パックにより、設定ステップを最大80%削減 |
| CloudFront コンソールの簡素化 | Amazon CloudFront | GA | WAF、Route 53、ACM の設定を統合し、Web アプリの配信と保護を単一の UI で簡素化 |
| AWS Network Firewall アクティブ脅威防御 | AWS Network Firewall | GA | AWS 独自の脅威インテリジェンス(MadPot)を活用し、既知の悪意ある通信を自動ブロック |
| GuardDuty EKS 向け拡張脅威検出 | Amazon GuardDuty | GA | EKS クラスターを対象に、コンテナランタイムや K8s 監査ログを分析し、多段階攻撃を検出 *5 |
| AWS Security Hub の機能強化 | AWS Security Hub | Preview | 複数のセキュリティシグナルを相関分析し、攻撃経路を可視化。アクティブなリスクを優先順位付けする統合プラットフォームへ進化 |
| AWS MSSP コンピテンシーの強化 | AWS Partner Network | 適用済み | パートナーの専門分野（サードパーティ製品含む）を検証し、顧客が最適な MSSP を特定しやすくするようカテゴリを更新 |
第一章：基本の徹底 - IDおよびアクセス管理
物語のはじまりは、ゼロトラストの基礎である ID 管理からです。ここでの AWS の戦略は明確です。
それは基本的なセキュリティ衛生管理（Security Hygiene）をコモディティ化させ、すべてのユーザーのセキュリティの最低基準（ベースライン）を底上げすることです*6。
外部から内部へ：IAM Access Analyzer internal access
まずは IAM Access Analyzer の内部アクセス検出機能の一般提供が発表されました。
従来、外部との共有リソース特定に主眼を置いていたこのツールは、自動推論（automated reasoning）という AI 関連技術を用いて、組織の内部で「誰が」「どの重要リソースに」アクセスできるかを数学的に証明可能なレベルで可視化します。これにより、従来は専門スキルや高価なツールが必要だった最小権限の検証作業が、プラットフォームの標準機能として提供されることになりました*7。
ルートユーザー保護の新しい標準：MFA の強制適用
そして、AWS は全てのアカウントタイプにおいて、ルートユーザーへの MFA 必須化を行ったことが発表されました*8。
| 時期 | 対象となったアカウントの種類 | 説明 |
|---|---|---|
| 2024年5月頃～ | AWS Organizationsの管理アカウント | 複数のAWSアカウントを束ねる「親」にあたる、最も重要な管理アカウントのルートユーザーから MFA が必須化されました |
| 2024年6月頃～ | スタンドアロンアカウント | どの AWS Organizations にも所属していない、独立した単一のAWSアカウントのルートユーザーが対象となりました |
| 2025年6月17日〜 | AWS Organizationsのメンバーアカウント | AWS Organizations に所属する「子」にあたる、メンバーアカウントのルートユーザーが対象となり、これをもって全てのアカウントが対象範囲に含まれました |
これは、これまで顧客の責任とされてきた基本的なセキュリティ対策を、クラウドプロバイダー側がプラットフォーム全体の安全性を高めるために強制するという、共有責任モデルにおける重大な一歩となりました。この一つの変更が、アカウント乗っ取りのリスクを劇的に低減させます。実際に、99%以上のパスワード関連の攻撃を防ぐことができるとのこと。
これらの動きから、AWS がセキュリティの「面倒な作業（undifferentiated heavy lifting）」を顧客から引き受け、より高度な価値創出へとリソースをシフトするために在るという、変わらないメッセージを見て取ることができます。
第二章：境界線の強化 - データおよびネットワーク保護
そして、物語はネットワークとデータの保護へと移ります。
ここでの AWS の戦略は、これまで「舞台裏」にあった脅威インテリジェンスを顧客が直接利用可能な製品として提供する点、そして先に触れた「簡素化（Simplifying）」というキーワードを体現する点にあります。
境界を越える管理：ACM からの証明書エクスポート
この章の幕開けは、一見地味ながらも、戦略的に極めて重要なアップデートでした。正直なところ、このアップデートにはかなり驚かされました*9。
AWS Certificate Manager (ACM) が公開証明書と秘密鍵のエクスポートをサポートしました。
これにより、ACM のライフサイクル管理の恩恵を受けつつ、オンプレミスや他クラウドといった AWS の境界外のワークロードも保護できるようになります。これは、AWS が自らをハイブリッド/マルチクラウド環境全体に対する中央集権的な『セキュリティ管理プラットフォーム』として動き出したようにも見えるでしょう。そういう意味で、境界を越える動きとなります。
プロアクティブな防御と最前線の簡素化
境界を越えた管理だけでなく、AWS は既存の防御壁そのものも、よりプロアクティブなものへと進化させています。プレビューとして発表された AWS Shield ネットワークセキュリティディレクター (AWS Shield network security director) により、AWS Shield は「ネットワーク構成全体をプロアクティブに分析し、弱点を指摘するセキュリティアドバイザー」へと進化します。
その機能は、AWS アカウント全体のネットワークリソースを自動的に検出＆分析し、AWS のベストプラクティスに基づいてセキュリティリスクに優先順位を付け、SQL インジェクションや DDoS 攻撃などの脅威からアプリケーションを保護するための修復推奨事項を提供するものとなっているとのこと*10。
こうしたプロアクティブな防御と並行して、AWS が最も力を入れたアップデートが、セキュリティ設定の「簡素化」です。
それが2つ紹介されました。
これらのアップデートの通り、AWS WAF と Amazon CloudFront です。
AWS WAF と CloudFront のマネジメントコンソールエクスペリエンスの刷新が発表されました。これは専門家でなくとも高度な保護を数分で展開できるようにする「簡素化」を体現するアップデートです。
AWS は多数の機能を組み合わせて動作させることができますが、各サービスを横断して利用するには知識と慣れが必要です。それが AWS の利用のハードルを意図せず上げてしまっているため、AWS は UI を1つの体験として完了するようにアップデートを重ねています。
グローバルインテリジェンスの活用：MadPot
そして、この章の締めくくりとして、AWS がこれまで舞台裏で培ってきた機能が、顧客の手の届く製品として提供されました。AWS Network Firewallに、新たなマネージドルールグループ「アクティブ脅威防御（Active Threat Defense）」が追加されています。
本機能は、AWS 独自のグローバルな脅威インテリジェンスシステム「MadPot」を活用し、マルウェアの URL やボットネット C2 サーバーといった攻撃インフラをリアルタイムで特定。これにより、AWS ワークロードに対するアクティブな脅威との通信を自動でブロックし、迅速かつ継続的な保護を実現します。
さらに、Amazon GuardDuty が特定した脅威も自動でブロック対象に加えるとのことで、セキュリティ運用を効率化し、より強固な防御体制を構築できるようになります。
第三章：統合セキュリティ運用 - モニタリングおよびインシデント対応
ここが起承転結の「転」であり、キーノートのクライマックスです。
本章での AWS の戦略は、個別のセキュリティツール群を、リスクを基軸とした統合セキュリティオペレーションプラットフォームへと生まれ変わらせるところにあります。
この目的は、増え続けるアラートの洪水からセキュリティチームを解放し、「本当に重要な脅威への迅速な対応」に集中させるためです。
GuardDuty の EKS 向けカバレッジ拡張
まず、物語のクライマックスへの布石として、既存機能の強化が発表されました。Amazon GuardDuty が EKS クラスターの脅威検出をサポートするよう拡張されました。
Kubernetes 監査ログ、コンテナランタイム、AWS API アクティビティを横断的に分析し、見過ごされがちな複雑で多段階にわたる攻撃を検出するこの機能は、コンテナ環境における脅威への対応能力を進化させることでしょう。
ただ、このように検出能力が向上すればするほど、個別のシグナルが増加することとなり、セキュリティ運用チームはアラートの増加により悩まされることになってしまうというジレンマが存在します。
これに関して、キーノートで Amy は、「監視とログ記録の重要性」を説き、インシデント対応戦略がなければ意味がないと強調。そして、その価値を示す事例として、ある大手金融機関の話を共有しました。
その機関は、監視ツールによって決済処理システムの異常な API コールを数分で検知しました。
彼らは事前に訓練されたインシデント対応手順を持っていたため、即座に影響システムを隔離し、レジリエントなアーキテクチャ設計のおかげで取引をバックアッププロセッサに迂回させ、顧客オペレーションを維持しました。これは、単なる「検知」の成功事例ではありません。「検知」から「対応」へとシームレスに移行し、ビジネスインパクトを最小化した「統合された運用」のおかげです。
個々のシグナル（検知）を、いかにして意味のある対応（アクション）に繋げるか。その答えが、全く新しく生まれ変わる AWS Security Hub となります。
AWS Security Hub の変革
今回のキーノート全体のコアとも言える発表がこちらです。プレビューが発表された AWS Security Hub の大規模な再設計です。
これは単なる機能強化ではありません。これまでアラートやコンプライアンス状況を集約する場所であった Security Hub が、リスクの優先順位付けと対応を大規模に実現するための「統合セキュリティハブ（unified cloud security solution）」 へと進化します。
キーノートのデモでは、その機能が調査から対応までの一連の流れとして紹介されました。
- シグナルの相関分析: Security Hub は、GuardDuty が検出した多段階の脅威、Inspector が見つけた脆弱性、その他のシグナルを自動的に集約・相関分析します。デモでは「公開された EC2 インスタンス」「悪用可能性の高い脆弱性」「過剰な権限」という3つの異なるシグナルを組み合わせ、「アクティブなリスク」として特定しました。
- 攻撃経路（Attack Path）の可視化: 個々の検出結果（点）を繋ぎ合わせ、そのリソースがインターネットにどのように公開され、どのネットワークコンポーネントが関与しているかという「攻撃経路（線）」を視覚的に表示します。
これにより、セキュリティ担当者はリスクの全体像と緊急性を直感的に理解できます。 - 修復ガイダンスと対応の効率化: 根本原因を特定し、対処法に関する推奨事項（remediation guidance）を提供します。さらに、Jira および ServiceNow のチケットシステムに直接インシデントを起票する機能も備え、担当チームへの連携を効率化します。
この全く新しい AWS Security Hub は、異なるアラートや脆弱性の間の「点と点を結びつけ」、組織のセキュリティ状況をより明確に、そしてリスクに基づいて優先順位を付けて把握できるようにします。これにより、セキュリティチームは「時間のかかる検知」から「より迅速な行動」へとシフトできるのです。
なお既存の AWS Security Hub は Security Hub CSPM と明確に「CSPM 専用」の機能としてこれまで通り存在していますためご安心ください。これまでの AWS Security Hub が AWS Security Hub CSPM となり、AWS Security Hub は全く新しい機能として再設計されたのです。
以下の表で、その比較をしています。
AWS Security Hub の機能に関する比較表
| 機能 | 従来の Security Hub | 新 Security Hub |
|---|---|---|
| 目的 | アラートの集約とコンプライアンス監視 | リスクを予測し、次の一手を示すセキュリティ運用ハブ |
| 中核概念 | Finding (個別のセキュリティアラート) |
Case (インシデント) と Exposure (弱点) でアラートを文脈化 |
| 分析能力 | 点で捉える個別アラート評価 | Attack Pathで攻撃の筋道を線として可視化 |
| リスク優先度 | 静的なSeverity (重大度) による評価 |
環境コンテキストと悪用可能性 (EPSS) を加味した動的スコア |
| インシデント対応 | 手動でのカスタム自動化 (EventBridge) | Caseによる対応追跡とJira等との双方向連携 (簡易SOAR) |
| リソース管理 | アラートに紐づく限定的な表示 | 全リソースの統合インベントリによる横断的な調査 |
| データ連携 | 独自形式 (ASFF) | 業界標準形式 (OCSF) でデータ連携を加速 |
三行でまとめると以下の通りです。
- アラートを「集約」するだけでなく、リスクを「予測」し対処法まで提示
- 個々のアラート(点)を、攻撃シナリオ(線)とインシデント(物語)として捉える
- 静的な評価から、環境の文脈を反映した動的な優先順位付けへと進化
統合運用を支えるパートナーエコシステム：AWS MSSP コンピテンシー強化
そして AWS は、こうしたネイティブツールの進化と並行して、その高度な運用を支えるパートナーエコシステムの重要性も強調しました。キーノートでは、AWS マネージドセキュリティサービスプロバイダー (MSSP) コンピテンシーの強化が発表されています*11。
これは、新しくなった Security Hub のような高度なツールを顧客が最大限に活用し、24時間365日の監視やインシデント対応を実現するためのものです。今回の強化では、パートナーが持つサードパーティ製品に関する知見も含めた専門分野を AWS が検証し、顧客が自社のニーズに最適な MSSP をより簡単に見つけられるようにカテゴリが更新されました。
AWS がネイティブ機能で「何を」守るかの基準を引き上げてくる一方、それを「いかに」効果的に導入し、運用していくかという領域では、信頼できるパートナーの役割がますます重要になるということです。
第四章：リフト＆シフトを越える - クラウド移行とモダナイゼーション
最後の章で語られたのは、セキュリティを土台とした、より高次元のイノベーションです。AWS の戦略は、クラウドへの「移行（Migration）」とその先にある「近代化（Modernization）」を、セキュリティを強化する絶好の機会と捉え、その道のりを可能な限り簡素化することです。
移行がもたらすセキュリティの飛躍
クラウドへの移行は、セキュリティの責任を再定義します。AWS がインフラの物理的なセキュリティという「差別化につながらない重労働」を担うことで、顧客は自社のリソース保護に集中できます。
その成功例として、RedShield が紹介されました。彼らは AWS へ移行し、AWS Global Accelerator を活用することで、インフラを80〜100のデータセンターに拡張。これにより、1.3Tbpsを超える大規模な攻撃を緩和し、顧客の重要なセキュリティ問題を数ヶ月から数日で解決できるようになったとのこと。
モダナイゼーションと「何もしない」パッチ管理
移行の究極の目標は、モダナイゼーションです。AWS Lambda や Amazon S3 のようなマネージドサービスをさらに活用することで、手動設定に起因するヒューマンエラーのリスクを低減します。Amy は、以下のように述べていました。
「結局のところ、最高のパッチとは、適用する必要のないパッチのことです（the best patching is the kind you don't have to do）」
これは、インフラ管理を AWS に全面的に任せることで、企業がよりビジネス価値の高い活動に集中できるという、モダナイゼーションの本質を捉えた言葉です。
もちろん、全てのパッチ適用が不要になるわけではありません。そこで重要になるのが、CI/CD パイプラインによる継続的な自動化です。Amazon Q Developer、ECR Scanning、Code Artifact、Amazon Inspector といったツール群が、開発の初期段階から本番環境まで、スタックのあらゆるレイヤーで脆弱性のスキャンとパッチ適用を支援します。
生成 AI によるセキュリティ運用の革新
そして物語は、イノベーションの最前線である「生成AI」へと繋がります。キーノートの最後は、AWS がいかに生成 AI を自社のセキュリティ運用に取り入れ、そして顧客が同様の革新を実現できるよう支援しているかに焦点が当てられました*12。
ゲストスピーカーとして登壇した George Argyros は、AWS 内部で活用されているツールをデモしました。
- Amazon Q Developer による自動修正: プルリクエスト時にコードのセキュリティ問題を自動で検出し、修正案を提示。開発者は IDE を離れることなく、ワンクリックでパッチをマージできます。
- AppSec レビューのスケーリング: 開発プロセス中にガイダンスを提供する AI チャットボットにより、セキュリティレビューのボトルネックを解消します。
- API テストの自動生成: API ドキュメントを読み込み、テストケースを自動で生成・改良することで、網羅的なテストを効率化します。
AWS のクラウドレスポンスチームも、生成 AI の導入で劇的な成果を上げています。ケース管理システムへの統合により、平均解決時間を40%以上削減。かつては平均9.5時間かかっていたログ分析ジョブは、AI によって数分で完了し、生産性は50倍に向上したといいます。
このイノベーションは顧客にも開かれています。BMW グループは、Amazon Bedrock 上に構築した「in-console cloud assistant (ICCA)」を活用し、1300以上あるクラウドアカウントのインフラを継続的に最適化している事例が紹介されました。
これらの事例は、強固なセキュリティ基盤を持つ企業こそが、生成 AI のような新技術を迅速かつ安全に導入し、競争優位性を築けることを示しています。セキュリティはもはや、イノベーションの足枷ではなく、それを実現し、加速させるための「前提条件」となったのです。
終わりに
AWS が語る「簡素化によるイノベーションの加速」という物語。その裏側も我々は考えなければなりません。一体何を考えればいいでしょうか？一例として以下があります。
- 「簡素化」のパラドックス： AWS は「簡素化」を掲げつつも、実際には多数の新機能を追加しました。これは、個々のツールの設定を簡素化する一方で、AWS プラットフォーム全体を学習・管理するコスト、すなわち認知的負荷はむしろ増大する可能性があります。特に AWS WAF の新しい UI は、利用において既存の細かい設定を施す点において不便さを感じる点が既にあります。長期的には改善されると思われますが、慣れ親しんだ UI の変更はオペレーションが確立されたユーザほど運用変更の負荷を伴います。
- ネイティブ vs パートナー： Inspector によるソースコードやライブラリの脆弱性スキャン、Security Hub による XDR 的な機能強化は、既存のセキュリティパートナーの領域と直接的に競合する可能性が高い機能です。AWS は MSSP コンピテンシーを強化しパートナーを支援する姿勢を見せつつも、その製品戦略は、より多くのセキュリティワークロードをネイティブで完結させることを目指しているようにも感じさせます。パートナーは、AWS が提供するセキュリティの上で、さらなる付加価値を証明する必要に迫られています。これは AWS を扱う上で常に感じさせるところですが、今回も少々危機感を感じているところがあります。
関連記事等
セッションの動画
AWS re:Inforce 2025 で 3 つの主要セキュリティ機能を発表、お客様のセキュリティ対策の簡素化とスケーリングを支援
AWS がセキュリティを大規模に簡素化する方法：AWS re:Inforce 2025 からの迅速なイノベーションのための 4 つの鍵
AWS re:Inforce roundup 2025: top announcements
AWS Organizations における推奨 OU 構成のベストプラクティス2025年度最新版を学ぶ
まとめ
本ブログでは AWS re:Inforce 2025 のキーノート SEC200 Simplifying security at scale (AWS re:Inforce 2025 - Keynote with Amy Herzog) をナラティブの観点からまとめました。
本基調講演は AWS が目指す「セキュリティの簡素化」というビジョンを示していました。その物語において脅威検知から対応までをシームレスに繋ぐ新しい AWS Security Hub の登場は、まさにその象徴と言えるでしょう。
- 第一章：基本の徹底 - IDおよびアクセス管理
- 第二章：境界線の強化 - データおよびネットワーク保護
- 第三章：統合セキュリティ運用 - モニタリングおよびインシデント対応
- 第四章：リフト＆シフトを越える - クラウド移行とモダナイゼーション
本ブログで解説してきたように、AWS は ID 管理、ネットワーク保護、モニタリング、モダナイゼーションという4つのテーマを通じて、ユーザーがより安全かつ迅速にイノベーションを実現できる環境を着々と整備しています。
一方で、「終わりに」で述べたように、「簡素化」がもたらす新たな学習コストや、ネイティブサービスとパートナーエコシステムの関係性（力学）など、我々ユーザー*13が向き合うべき課題も存在します。
AWS が提供する便利なツール群を最大限に活用しつつ、自社にとって最適なセキュリティ戦略とは何かということも、合わせて考え続けなければならないでしょう。セキュリティツール郡が加速器という前提ならば、誤った加速器の選択は、ビジネスに致命的な遅延を与える可能性があると推測するためです。
加えて、クラウドセキュリティ、及び AI に関するセキュリティもまだ過渡期だと感じます。この進化の速い時代に求められる姿勢とは、何かを「シルバーバレット戦略」として依存し切るということではなく、油断なく日々の学習とアップデートを忘れないという点にこそあるでしょう。
そして多層防御（Defense in depth）を忘れずに意識して設計し、運用とブラッシュアップを継続していきたいと感じました。これにて本ブログを終わりにします。
では、またお会いしましょう。
*1:※敬称略
*2:情報過多とも言えます
*3:General Availability or Generally Available の省略で、一般利用可能という意味です
*4:2024年半ばに既に実施されているものの継続対応です https://aws.amazon.com/jp/blogs/news/aws-adds-passkey-multi-factor-authentication-mfa-for-root-and-iam-users/
*5:re:Invent 2024 発表の拡張脅威検出が EKS へサポート拡大。過去の解説はこちら https://blog.serverworks.co.jp/guardduty-extended-threat-detection
*6:これはクラウドの提供者側が現代に必要なセキュリティ機能を担保するためにそれを能動的に強化し、また大衆化させ、一般的に広く浸透させるため努力をするということです。セキュリティの強化はもはや、クラウド提供者の責務となっており、競争のための基盤です
*7:この機能の実装がいかに困難であったかは翌日の追加セッションで明らかになりました。それについては別途記載します
*8:先行して MFA が必須化されていた「AWS Organizations の管理アカウント」と「スタンドアロンアカウント」に加え、最終的に AWS Organizationsの「メンバーアカウント（子アカウント）」も対象となりました
*9:なぜなら、これまでの AWS は KMS しかり「鍵は取り出せないからこそ安全である」という思想を貫いていると考えていたためです
*10:これは期待大ですね
*11:AWS Level 1 MSSP Competency は名称が変更され、「AWS MSSP Competency 」となりました
*12:これに関連して、【AWS re:Inforce 2025】生成 AI が AWS のセキュリティサービスをどう進化させているか (TDR322) のセッションレポートも是非ご覧ください https://blog.serverworks.co.jp/reinforce2025-tdr322
*13:ユーザー及びリセラー
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
セキュリティサービス部所属。AWS資格全冠。2010年1月からAWSを業務利用してきています。主な表彰歴 2021-2022 AWS Ambassadors/2020-2025 Japan AWS Top Engineers/2020-2025 All Certifications Engineers。AWSのコスト削減やマルチアカウント管理と運用を得意としています。
