はじめに
現在、日本は 2025年 6月 17日 23時になりました。
深夜ですが、AWS re:Inforce 2025 の Keynote を見るために頑張って起きています。
Keynote の内容を、セキュリティエンジニアの視点でまとめたいと思います。
Keynote
AWS re:Inforce 2025 の Keynote は、AWS CISO Amy Herzog 氏と Noopur Davis 氏によって発表されました。
それぞれ話題になったテーマについて見ていきたいと思います。
Keynote の内容は多岐にわたるため、本ブログでは主にセキュリティサービスのアップデートに焦点を当てて解説します
詳細は、Keynote 本編 をご確認ください。
AWS IAM
AWS IAM は、毎秒 12億件の API コールを処理する、世界最大規模の認可システムとして紹介されました。
AWS のリソースやアプリケーション、ユーザーに対してポリシー言語を用いてアクセス認可を設定できます。
AWS IAM を最小権限の原則に基づいて運用することで、内部不正や外部の脅威から攻撃対象を減らすことができると紹介されていました。
AWS IAM の課題として、AWS のサービスが増えたことで事前にどのレベルの権限が必要か事前に把握することが難しいことがあります。
これを解決するためのソリューションとして、IAM Access Analyzer が紹介されていました。
IAM Access Analyzer
IAM Access Analyzer は、外部アカウントやユーザーによるアクセスが試行される前にスキャンして、意図しない漏洩の可能性を報告する事が可能です。
リソースポリシーをプロアクティブにスキャンし、意図しない漏洩の可能性を報告します。
新しい IAM Access Analyzer
Keynote では、新しい IAM Access Analyzer について紹介されていました。
新しい IAM Access Analyzer のポイントは以下のとおりです。
- 内部アクセスの可視化
- 外部アクセスだけでなく、内部ユーザーによる組織内の重要な AWS リソースに対するアクセスも確認可能です。
- 自動推論
- 様々なポリシータイプを分析し、特定のリソースにアクセスできる IAM ロールとユーザーを特定する。
- シンプルなダッシュボード
- 外部アクセス、内部アクセスがシンプルなダッシュボードで一元管理できます。
これらの新しい IAM Access Analyzer によって、AWS IAM を最小権限の原則に基づいて管理が容易になるとのことです。
長期的な資格情報の排除
次に対処すべきこととして、長期的な資格情報の剥奪について説明されていました。
長期的なアクセス情報は永続的なセキュリティリスクとなり、有効期間が長ければ長いほど、脅威アクターが発見して悪用する期間が長くなります。
最近の例では、脅威アクターが長期的な認証情報を使用して、実際にコンテキストを設定することに成功した場合、顧客指定の暗号鍵 (CSEK) を悪用して顧客のオブジェクトが置き換えられました。
そのため、顧客はデータを復号化できなくなりました。
CSEK は、企業にとって有用なものですが、有効な操作と不正な操作を区別することは困難です。
AWS ではプロアクティブな防御ツールを活用して、 4ヶ月間でほぼ 10億件の不正な操作を阻止しているとのことです。
こういった攻撃を防ぐためにも、 一時的な認証情報の利用を推奨していました。
具体的には、以下のような対策を推奨しています。
- IAM Role の利用
- EC2 Instance Profile など、必要なリソースに対して一時的なアクセス許可を付与。
- ID Federation
- 外部の ID Provider と連携し、シームレスにサインオンするようにする。
- 多要素認証 (MFA) の強制
- どうしても、長期的な資格情報が必要な際は、MFA を有効化する。
- ルートユーザーアカウントの制御
- ルートユーザーの仕様を最小限に抑え、必要な場合のみ一時的に昇格されたアクセス許可を使用する。
これらの手段によって、長期的な資格情報を抑制、管理することが重要とのことです。
AWS Digital Sovereignty Pledge
Digital Sovereignty (デジタル主権) はデータの配置を制御することです。
AWS は、デジタル主権とイノベーションは共存可能と語っていました。
AWS にとってデジタル主権は、AWS が顧客がデータの場所を制御できる唯一のクラウドプロバイダーであったときから最重要事項と紹介されていました。
AWS は、デジタル主権の確保のため、以下の機能や制御を提供するとのことです。
- データの場所に対する制御
- データの場所と移動を制御可能とする。
- データにアクセスできるユーザの検証
- 誰がデータにアクセスできるか検証可能な形で制御する。
- 回復力のある選択
- 中断や切断があっても、運用を維持できる回復力。
- すべての場所で暗号化
- 機密性の高いデータのみだけでなく、すべてのデータを暗号化する。
デジタル証明書
AWS Certificate Manager (ACM) は、デジタル証明書の管理をおこなっています。
ACM により、公開証明書のプロビジョニング管理とデプロイプロセスが簡略化されます。
今回のアップデートにより、ACM が発行したパブリック証明書と、その秘密鍵を内部、外部向けにエクスポートすることが可能となったとありました。
これにより、必要な場所で ACM 発行の証明書をダウンロードして利用する選択肢ができたとのことです。
ACM で証明書を一元管理しながら、必要に応じてダウンロードして利用できるようになりました。
AWS Shield
AWS Shield は、情報やアプリケーションをサイバー攻撃から守る際のネットワーク保護を提供しています。
長らく、AWS Shield は DDoS 攻撃に対する保護手段として機能してきて、可用性に対する攻撃から保護してきました。
AWS Shield に新しい拡張が展開されました。
Network security detector (Preview)
Network security detector の機能は、大きく以下のポイントがあると紹介されていました。
- 包括的なネットワークセキュリティ管理
- DDoS だけでなく、包括的なネットワークセキュリティ管理に対する拡張。
- ネットワーク構成に対する問題の特定
- ネットワーク分析を実施して、ネットワークトポロジーを構成する。
- ネットワークセキュリティに対するベストプラクティス分析
- ネットワーク構成がベストプラクティスを満たしているか評価する。
- 問題の優先順位付け
- どの問題から対応するべきか、決定することができる。
これらの機能によって、AWS Shield は DDoS 保護だけでなくネットワークに対する包括的な監視と、対策を管理することが可能になったとのことです。
AWS WAF
AWS WAF は、Web application を悪用する攻撃をブロックします。
WAF の課題として、設定の煩雑さがあります。
複数のコンソールページ利用や、複雑なルール選択が必要であるなど、設定には時間がかかる場合がありました。
シンプルなコンソールエクスペリエンス
包括的な保護と、使いやすさを両立するため、 AWS WAF 用のシンプルなコンソールエクスペリエンスが導入されました。
これにより、初期の構成に必要な手順が 80% 削減され、セキュリティチームは数分でアプリケーションの保護ができるようになったとのことです。
ワークロード固有のルールパック
一般的なワークロードタイプのためのルールパックが提供されました。
API や PHP Application など、基礎的な保護を簡単に開始できるようになりました。
AWS の専門家により厳選され、新しい脅威に対するため、継続的に更新がされると紹介されていました。
統合ダッシュボード
統合されたセキュリティ指標にアクセスできる新しい統合ダッシュボードが提供されると紹介されていました。
このダッシュボードでは、誤検知を監視して既存のルールを調整したり、潜在的な脅威に対してダッシュボード内から対応することが可能になるとのことです。
レート制限、地理的制限、IP 制限などに対しても、ダッシュボードからカスタマイズが可能になるとのことです。
CloudFront 用の簡素化されたオンボーディング
開発者がコンテンツ配信に CloudFront を利用する場合、技術的な専門知識がなくても高速かつ安全なコンテンツ配信ができるようになりました。
簡素化されたオンボーディングエクスペリエンスにより、CDN 設定に加えて、WAF、Route 53、ACM 設定をクラウドフロントコンソール内から管理可能となりました。
AWS Network Firewall
AWS のネットワーク端には Blackfoot とよばれる内部ネットワークマッピングデバイスがあるとのことです。
パケットが、AWS のネットワーク端に到達すると Blackfoot により外部 IP と内部 IP の変換が行われます。
Blackfoot は 13兆 / 時 を超えるフロー変換を行っているとのことです。
Mad Pot
Mad Pot は、EC2 コレクションを利用したハニーポットです。
AWS は、グローバルネットワーク上で何万もの悪意を持った BOT が実行されており、それらは IP 空間内を移動しています。
Mad Pot は攻撃者を特定する知見を提供し、Blackfoot は攻撃を遮断するためのデータプレーンを提供しているとのことです。
これらにより、脆弱性をスキャンする攻撃を検知して、遮断することが可能となります。
AWS は過去 6ヶ月で 2兆 4000億件の攻撃を防止したとのことです。
IP リストを 3分ごとに測定した結果、Backfoot で軽減された IP の 平均で 12.5% が 3分間の間に変化しています。
そのため、情報を毎日あるいは毎時間更新するだけでは不十分であり、もっと短い間隔での対応が必要だということです。
アクティブな脅威保護で強化された AWS Network Firewall
上述のような知見を活かして、アクティブな脅威保護で強化された AWS Network Firewall がリリースされました。
グローバルインフラストラクチャから得られる脅威インテリジェンスを活用して、脅威を迅速に特定して、AWS 管理のルールによって悪意ある攻撃をブロックできます。
これらにより、複雑さや、業務上のオーバーヘッドなくセキュリティが強化できるとのことです。
GuardDuty
GuardDuty は、機械学習と AI を使用して、誤検知を最小限に押さえてセキュリティの自動化を簡単に実現できます。
AWS は、良いサービスとするため機能の強化に投資を続けているとのことです。
拡張脅威検出
12 月には、拡張脅威検出が一般公開となりました。
AI と機械学習を使用して、AWS サービス全体からセキュリティに関するシグナルを自動的に関連付けし、重大な脅威を検出するとのことです。
この機能により、資格情報の侵害とその後の情報漏洩などの一連の行動を関連付けし、一つの重大なインシデントを特定できるとのことです。
この調査結果には、インシデントの概要や MITRE ATT\&CK の詳細なイベントタイムライン、復旧の推奨事項などが含まれます。
拡張脅威検出は非常に成功しており、米国内で数百万の監視対象 AWS アカウントで、13,000 件を超える信頼性の高い攻撃シーケンスを特定したとのことでした。
アカウントごとでは、2件未満の検出数であり、重大なセキュリティイベントのみを可視化することができているとのことです。
Amazon EKS クラスター侵害
誤検知の減少、ネットワークおよび EKS 監査ログ、ランタイム環境の可視性を組み合わせた EKS クラスター用の新しいカバレッジが提供されます。
これにより、Amazon EKS クラスターが侵害された可能性を示す一連のアクティビティに対してアクションを実施できるようになるとのことです。
たとえば、特権コンテナの展開と暗号化マイニング、リバースシェルの作成など、複数の攻撃手段が GuardDuty runtime センサーによって検出され、一連の攻撃として検出可能となります。
この機能強化によって、AWS 環境全体で包括的な脅威検出が可能となり、迅速に対応することが可能となります。
Security Hub
Security Hub は、AWS 全体のイベントを統合し、Insight に変える統合クラウドセキュリティソリューションです。
強化された AWS Security Hub (Preview)
今回の発表で、AWS 全体からの広範囲かつ詳細なセキュリティシグナルが統合され、相互に関連付けられるようになりました。
多段階の脅威を組み合わせ、 GuardDuty や Inspector など複数のシグナルを組み合わせて脅威検出を拡張することができるようになります。
概要ダッシュボードでは、露出された脆弱性のあるリソースの傾向が表示されます。
たとえば、過剰な権限を持ち、悪用されやすい脆弱性のある、公開された EC2 インスタンスなどが表示されます。
これらを展開すると、関連するすべての情報が表示され、調査可能となります。
調査結果の説明や概要を見て、主要な項目を理解することが可能となります。
まとめ
機能のアップデートは、統合されたインサイトと、継続的な修正という2つの AWS の主要なテーマがみえてくるように感じました。
統合されたインサイトは、セキュリティエンジニアがシグナル一つ一つを確認するのではなく、AI などによって統合された一連の一つのイベントとして管理可能なようにする機能です。
イベントの数は、日々増えており、一つ一つに対応することは難しくなっています。
これらを、一連の攻撃イベントとして捉えることで、組織はより脅威にたいして対応しやすくなると考えています。
継続的な修正は、脆弱性を日々管理していく対応です。
IAM Access Analyzer や強化された Security Hub により、脆弱な状態を可視化して、より簡易に修正を継続できるようにしていると感じました。
Amy Herzog 氏の話にあるように、多くの機能が AWS には存在しており、それらに対して完璧な対応を最初から実施することは難しいです。
継続的に修正を行えるよう、どうしたらよいのか? という知見提供に対して注力しているように感じました。