クラウド セキュリティの現状 | Datadog
クラウド セキュリティの現状

research / security / cloud security / aws / google cloud / azure / security research / threat detection

2025 年 10 月更新

本レポートは、2024 年 10 月に公開された 2024 年版を基にアップデートしたものです。各データのグラフは、こちらからダウンロードできます

クラウドネイティブなアーキテクチャを採用する組織は、攻撃者がますます多様な手法を用いて、サービスやツール、環境の脆弱性を悪用しようとする状況に直面しています。油断は大きな損失につながります。急速に進化し続ける脅威から、攻撃対象領域を守るためには、クラウド スタックのあらゆるレイヤーにわたるリスクを正確に把握することが必要不可欠です。

2025 年版「クラウド セキュリティの現状」では、AWS、Azure、Google Cloud を利用している数千の組織から抽出したセキュリティに関するデータを分析しました。今回の分析結果から、長期間有効な認証情報の削減やデフォルトでセキュアな仕組みの適用、過剰な権限を持つ IAM ロールの廃止といった取り組みは着実に進んでいる一方で、依然として多くの組織において、重要なリソースが既知の脆弱性や潜在的な攻撃にさらされたままになっていることが明らかになりました。データ境界や一元管理されたマルチアカウント環境といった新しい戦略は採用が広がりつつあり、強力な制御を提供します。しかし、これらは多くの場合デフォルトでは有効化されておらず、適切に構成されていない場合は、新たな攻撃ベクトルを生み出す可能性があります。

事実 1

マルチアカウント環境により、AWS で組織的なガードレールを適用

単一の AWS アカウント内で権限の最小化を徹底することは容易ではありません。同様に、開発や本番といった異なるステージのワークロードを同じ AWS アカウントで運用すると、クォータ、IAM、ネットワーク、パフォーマンスなどの問題により、大きな負担が生じる可能性があります。こうした理由から、AWS のガバナンス サービスである AWS Organizations を使用し、複数の AWS アカウントを一元的に管理することが、セキュリティ面と運用面の両方から広く推奨されています。なお、“AWS Organization” は、AWS Organizations 内で構成される AWS アカウント群を指す用語であり、一般的な意味での Organization (組織) とは異なる点にご注意ください。

調査の結果、少なくとも 84% の組織が複数の AWS アカウントを使用しており、86% の組織が AWS Organizations を利用する AWS アカウントを保有していることがわかりました。AWS Organizations はマルチアカウント環境を一元管理する方法として広く普及しており、約 3 分の 2 (70%) の組織はすべての AWS アカウントをひとつの AWS Organization にまとめて運用しています。また、全 AWS アカウントのうち約 4 分の 3 (74%) が AWS Organization に所属しています。一方で、14% の組織は、いずれの AWS アカウントに対しても AWS Organizations をまったく利用していません。

「AWS Organizations 利用状況別の組織分布」を示す棒グラフ。AWS Organizations を使用していないアカウントのみの組織が 14%、一部のアカウントで利用している組織が 16%、すべてのアカウントで利用している組織が 70% を占める。右側には大きな文字で「AWS Organizations の導入は広く普及している」と表示。

AWS Organizations を使ってマルチアカウント環境を管理する場合、組織レベルのガードレールによって、すべての AWS アカウントにセキュリティの不変条件を適用できます。今回の調査では、AWS Organizations を利用している組織のうち、約 5 社に 2 社 (40%) がサービス コントロール ポリシー (SCP) を活用していることがわかりました。また、6% は、リソースレベルで適用される新しいタイプの組織ポリシーであるリソース コントロール ポリシー (RCP) を利用していました。

これらのポリシーの明示的な否定ステートメントで使用されている IAM 条件キーを分析したところ、SCP は主に、メンバー アカウントにデプロイされた共有インフラストラクチャや “ランディング ゾーン”、そして CloudTrail や GuardDuty といったセキュリティ機能を保護する目的で利用されていることがわかりました。一方、RCP が定義されている場合は、組織内のすべての S3 バケットに対して暗号化を強適用し、同一の AWS Organization に属するプリンシパルのみがバケットへアクセスできるようにする用途が最も一般的でした。

しかし、AWS Organizations を利用する際には注意すべき点もあります。設計上、Organization の管理アカウントに属する権限を持つプリンシパルは、すべての子アカウントへアクセスできるため、非常に強力な横展開の経路となり得ます。これを防ぐために、AWS は管理アカウント上でワークロードを実行しないことを推奨しており、こうすることで管理アカウントが侵害されるリスクを抑えることができます。それにもかかわらず、今回の調査では、管理アカウントで EC2 インスタンスを稼働させている組織が 9% 存在し、これは 2024 年の 6% から増加していることがわかりました。このような構成では、攻撃者が EC2 インスタンスを 1 つでも侵害できる場合、権限を昇格させて、すべての子アカウントにアクセスできる可能性があります。

事実 2

データ境界の導入が進む一方で、多くの組織では一元管理の仕組みが欠如

クラウドでは、ID が新たな境界となっています。クラウド API は、設計上インターネットに公開されているため、オンプレミスで想定されるような “内部ネットワーク” という概念はほとんど存在しません。その結果、攻撃者がクラウドの認証情報を盗み取ると、内部ネットワークに侵入しなくても、世界中のどこからでもクラウド API を呼び出すことが可能になります。認証情報の窃取が主要な攻撃経路となっている中、近年注目されているのがデータ境界という概念です。データ境界を活用することで、特定のクラウド API 呼び出しを制限し、許可されたネットワークや信頼されたクラウド アカウントからのアクセスのみを成功させることができます。

しかし、データ境界はデフォルトで有効化されているわけではありません。SCP や RCP、あるいは S3 バケットや VPC エンドポイントといったリソース単位でのリソースベース ポリシーなど、複数のポリシーを組み合わせて設定する必要があります。また、データ境界を適切に機能させるためには、aws:SourceAccount や aws:PrincipalOrgID といった高度な IAM ポリシーの条件キーを使用する必要があります。

今回の調査では、SCP、RCP、VPC エンドポイント、または S3 バケット ポリシーのいずれかを通じてデータ境界を利用している組織が、約 5 社に 2 社 (40%) にのぼることがわかりました。

「実装方法別の AWS データ境界採用状況」を示す棒グラフ。全手法を合わせた利用率は約 40% で、S3 バケット ポリシーが 33%、VPC エンドポイント ポリシーが約 15%、SCP および RCP は 1% 未満です。左側にはグラデーションの大きな文字で「データ境界はリソース レベルでの実装が主流」と表示。

総合的に見て、データ境界の実装方法として最も一般的なのは、次のとおりです。

  • S3 バケット ポリシー (32% の組織): 主に aws:SourceAccount 条件キーを使用。これにより、ACL や個々のファイルが誤ってパブリックになってしまった場合でも、特定の AWS アカウント外のユーザーによるバケットへのアクセスを防ぐことができます。
  • VPC エンドポイント ポリシー (13% の組織): 主に aws:PrincipalAccount 条件キーを使用。これにより、攻撃者の AWS アカウントにデータが持ち出されるのを防止できます。
  • SCP (0.6% の組織): 主に aws:PrincipalAccount 条件キーを使用。
  • RCP (0.1% の組織): 主に aws:PrincipalOrgID、aws:SourceOrgID、aws:SourceAccount 条件キーを使用。これにより、特定の種類のリソースが誤設定されている場合でも、組織外のユーザーによるアクセスを防ぐことができます。

データ境界は高度なセキュリティ プラクティスと見なされていますが、すでに 3 分の 1 以上の組織が導入しています。これは、認証情報の窃取への懸念が高まっていること、そしてクラウド データ向けのプロバイダー提供の保護機能を積極的に採用しようとする姿勢を反映しています。しかし、今回の分析から、多くのデータ境界が依然としてリソース単位で適用されていることも明らかになりました。データ境界の利用を始めたばかりの組織は、より最新の制御である RCP のような仕組みへ移行することで、組織レベルでガードレールを強制的に適用し、適用範囲の抜け漏れをなくすことができます。

事実 3

長期間有効な認証情報の蔓延とリスクは依然として深刻

長期間有効なクラウド認証情報は、依然として重大なセキュリティ リスクとなっています。過去の本レポートでも、公開されているクラウド セキュリティ侵害の最も一般的な原因であることが示されてきました。2025 年の調査では、AWS、Azure、Google Cloud 全体で、人間およびアプリケーションの認証において、レガシーの認証方式と最新の認証方式がどのように使われているのかを追跡しました。

調査の結果、AWS コンソールへの人間ユーザーのアクセスには、大半 (79%) の組織が AWS IAM Identity Center や Okta などによるフェデレーション認証を引き続き使用していることがわかりました。これは 2024 年の 76% から増加しており、一部の組織がフェデレーション認証のみへの完全移行を進めていることを示しています。しかしその一方で、約 5 分の 2 (39%) の組織は依然として IAM ユーザーを何らかの形で利用しており、5 分の 1 の組織は IAM ユーザーのみに依存しています。このことは、クラウド環境へのアクセスにおいて一元管理的な “人間の ID” を採用する動きが進む一方で、人間による IAM ユーザー利用といった従来の IAM プラクティスを完全には排除できていない現状を示しています。新しいセキュアな認証方式を追加することは、リスクの高いレガシー方式を廃止することよりも容易です。しかし、プロアクティブなセキュリティを実現しリスクを低減するためには、新しいソリューションを導入するだけでなく、技術的負債を解消する取り組みも欠かせません。

「AWS コンソールの認証方法別の組織分」を示す棒グラフ。2024 年と 2025 年を比較すると、2024 年は、IAM ユーザーのみが 24%、IAM とフェデレーション認証の併用が 22%、フェデレーション認証のみが 54%。2025 年は、それぞれ 21%、18%、61% へと推移している。右側にはグラデーションの大きな文字で「多くの組織が依然として IAM ユーザーに依存している」と表示。

昨年と同様、長期間有効なクラウド認証情報の多くが古いまま、あるいは未使用のまま残っていることがわかりました。こうした状態は、これらの認証情報に伴うリスクをさらに高めます。

  • AWS では、59% の IAM ユーザーが 1 年以上前に作成された有効なアクセス キーを保持しています。さらに、その半数以上は 90 日以上使用されていない認証情報であり、本来であれば容易に削除できるリスクの高い状態にあります。重要なのは、この割合が 2024 年から減少していない点です。これは、この領域におけるセキュリティ体制の改善が頭打ちになっていることを示唆しています。
  • Google Cloud のサービス アカウントも同様の傾向を示していますが、前年比では改善が見られます。Google Cloud のサービス アカウントの 55% が 1 年以上前に作成された有効なサービス アカウント キーを保持しており、これは前年の 62% から減少しています。この改善は、サービス アカウント自体の数が減った (サービス アカウントは、サービス アカウントの偽装や Workload Identity Federation など、短期認証情報の発行にも使用可能) ためではなく、これらのサービス アカウントに紐づくサービス アカウント キーの数が減少したことによるものと考えられます。
  • 同様に、Microsoft Entra ID アプリケーションの 40% が 1 年以上前に作成された認証情報を保持しており、これは前年の 46% から減少しています。

アクセス キーの有効期間を時系列で分析すると、長期間有効な認証情報を使用している組織は、そのローテーションに問題を抱えていることがわかります。3 年超のアクセス キーの割合は、主要クラウドすべてでおおむね増加しており (AWS 21% → 25%、Google Cloud 22% → 25%、Azure は横ばい)、5 年超でも同様の傾向が見られます (AWS 8% → 10%、Google Cloud 6% → 8%、Azure 6% → 10%)。この増加は懸念すべきものであり、アクセス キーは存在し続けて古くなるほど、その危険性が高まります。唯一、拡大が可能な対策は、長期キーの利用を停止し、安全な代替方式へ移行することです。

「3 年超のアクセス キーを保持するクラウド ユーザーの割合」を示す棒グラフ。AWS IAM ユーザー、Google Cloud サービス アカウント、Microsoft Entra ID アプリケーションについて、2023 年、2024 年、2025 年のデータを比較。2025 年時点では、AWS と Google Cloud がいずれも約 25% と最も高い割合を示す。右側にはグラデーションの大きな文字で「リスクの高い長期クラウド認証情報は依然として一般的」と表示。

組織は長期間有効な認証情報の代わりに、有効期間が限定された一時的な認証情報を提供する仕組みを利用すべきです。ワークロードの場合、AWS では EC2 インスタンス向けの IAM ロールや EKS Pod Identity、Azure ではマネージド ID、Google Cloud ではワークロードに紐づくサービス アカウントを使うことで実現できます。人間ユーザーに対しては、AWS IAM Identity Center、Okta、Microsoft Entra ID などのソリューションを用いて ID 管理を一元化し、従業員ごとに個別のクラウド ユーザーを作成する運用を避けることが最も効果的です。個別ユーザー方式は非効率でリスクも高いため、避けるべきです。

“インシデント レスポンスの観点では、IAM ユーザーに紐づくアクセス キーの露出が AWS における主要な初期侵入経路として存在し続けています。従来、アクセスキーが誤って様々なコード共有プラットフォームで公開されてしまうケースが多く見られました。しかし最近のインシデントでは、十分に保護されていない CI/CD パイプラインや、共有の開発者用ワークステーションからアクセス キーが漏洩するケースが増えています。”

Korstiaan Stam 氏
Invictus Incident Response 創業者兼 CEO
事実 4

EC2 インスタンスの半数で IMDSv2 が適用されている一方で、旧インスタンスでは対応に遅れ

EC2 インスタンスにおける認証情報の窃取を防ぐ AWS のセキュリティ機構である IMDSv2 の採用は、引き続き拡大しています。これは主に、IMDSv2 を自動的に有効化する “セキュア バイ デフォルト” の取り組みを AWS が進めていることが要因です。従来、IMDSv2 は EC2 インスタンスやオートスケーリング グループごとに手動で強制適用する必要がありました。

組織が IMDSv2 を強制適用している EC2 インスタンスの割合は平均で 66% に達しており、1 年前の 47%、2 年前の 25% から大きく増加しています。全体では、EC2 インスタンスの 49% で IMDSv2 が強制適用されており、これは 1 年前の 32%、2 年前の 21%、2022 年の 7% から大幅に上昇しています。

「EC2 インスタンスにおける IMDSv2 強制適用の平均値 (経年推移)」を示す折れ線グラフ。2022 年 9 月時点で EC2 インスタンスの約 10% が IMDSv2 を強制適用していた状態から、2025 年 9 月には約 70% まで着実に上昇している様子を示している。左側にはグラデーションの大きな文字で「IMDSv2 の強制適用は引き続き拡大」と表示。

こうした結果は継続的な傾向を裏付ける一方で、すべての EC2 インスタンスが同じ状況にあるわけではないことも明らかになりました。本レポート用データ収集の直前 2 週間以内に作成されたインスタンス (全 EC2 インスタンスの 3 分の 2 を占める) のうち、IMDSv2 を強制適用しているのは半数を超えています。しかし、2 年以上前に作成されたインスタンスでは、IMDSv2 を強制適用しているのはわずか 14% にとどまっています。

「EC2 インスタンスの IMDSv2 強制率とインスタンス年齢別の割合」を示すバブル チャート。6 か月未満の新しいインスタンスでは IMDSv2 の強制率が約 55〜60% と高い一方、2 年超のインスタンスでは約 20% まで低下している。左側にはグラデーションの大きな文字で「旧世代 EC2 インスタンスでは IMDSv2 の強制が遅れている」と表示。

IMDSv2 を重視する組織が増えていることも確認できました。3 分の 1 を超える組織 (37%) が、すべての EC2 インスタンスで IMDSv2 を強制適用しており、これは 2024 年の 4 分の 1 未満から大きく増加しています。さらに、半数の組織が EC2 インスタンスの少なくとも 80% で IMDSv2 を強制適用しており (前年比では 3 分の 1 から増加)、IMDSv2 を 20% 未満のインスタンスでしか強制適用していない組織は 24% に減少しています (39% から大幅に改善)。

「EC2 インスタンスにおける IMDSv2 強制の平均値」を示す棒グラフ。2024 年には、EC2 インスタンスの 80%以上で IMDSv2 を強制適用していた組織は約 32% に留まっていたが、2025 年にはほぼ 50% に増加。すべてのインスタンスで IMDSv2 を強制適用していた組織も、約 20% から 40% 近くまで上昇している。左側にはグラデーションの大きな文字で「多くの組織が EC2 インスタンスの大半で IMDSv2 を強制適用」と表示。

昨年のデータと同様に、IMDSv2 の強制適用は進んでいるものの、多くのインスタンスは依然として脆弱なままです。しかし、EC2 インスタンスで IMDSv2 が強制適用されていない場合でも、そのインスタンス上のアプリケーションやプロセスは IMDSv2 を利用することができます。CloudTrail のログを確認したところ、IMDSv2 を強制適用している EC2 インスタンスは全体の 49% にとどまる一方、過去 2 週間に IMDSv2 のみを使用していたインスタンスは 82% に上りました。これは、機能的な影響なしに IMDSv2 を強制適用できたはずのインスタンスが多数存在することを示しています。この結果は、特にデフォルトで IMDSv2 が有効化されていなかった旧世代の EC2 インスタンスにおいて、“実際の使用状況” と “強制適用” の間に依然としてギャップがあることを示唆しています。IMDSv2 のようなメカニズムがデフォルトで有効化されていない場合、開発者の作業を妨げたり影響を与えたりしなくても、セキュリティ設定が後回しになりがちです。

IMDSv2 を強制適用したい組織は、AMI での IMDSv2 デフォルト有効化や、2024 年 3 月に導入されたリージョン単位で “新規インスタンスに IMDSv2 をデフォルトで強制する” 設定など、セキュア バイ デフォルトの仕組みを活用すべきです。今回の調査では、この設定を利用している組織は 3% 未満と少数でしたが、有効化している組織では IMDSv2 の強制率が 95% 以上に達していました。多くの場合、セキュア バイ デフォルトは単純な構成変更で実現でき、脆弱性のギャップを大幅に解消するうえで極めて効果的です。

“IMDSv2 の採用率は年々向上しているものの、AWS が設定可能なデフォルトを導入したにも関わらず、その強制適用はまだ追いついていません。組織は、これらのセキュリティのデフォルトを有効化し、SCP を通じて環境全体で IMDSv2 を強制適用すべきです。IMDSv2 は、SSRF 脆弱性の影響を大幅に低減できる、シンプルで効果的な手段です。しかし、IMDSv1 が利用可能な限り、攻撃者は引き続きそれを悪用します。こうしたギャップを完全に解消する唯一の方法は、AWS が IMDSv1 を廃止することです。”

Adam Pietrzycki 氏
Zapier シニア インフラ セキュリティ エンジニア
事実 5

クラウド ストレージにおけるパブリック アクセス ブロックの導入は頭打ち

“舗装された道路” と “ガードレール” は、プロセスの標準化を容易にし、人為的なミスがデータ侵害につながることを防ぐための 2 つの重要なセキュリティ対策です。パブリックなストレージ バケットは、依然として数多くの大規模なデータ侵害の原因となっているため、近年のガードレール系対策の多くは、バケットが誤ってパブリックにならないようにすることを目的として設計されています。

今年のレポートでは、パブリック アクセス ブロックの導入は引き続き増加しているものの、その伸びは前年までと比べて鈍化していることがわかりました。S3 バケットのうち実質的にパブリックになっているものは 1% で、これは 2024 年および 2023 年の 1.5% から減少しています。また、S3 バケットの 5 分の 4 超 (83%) が、アカウント全体またはバケット単位の Amazon S3 パブリック アクセス ブロックによって保護されており、これは 1 年前の 79%、2023 年の 73% からわずかに増加しています。この改善は、問題に対する認識の拡大が続いていること、そして 2023 年 4 月以降、AWS が新規作成された S3 バケットに対して積極的にパブリック アクセスをブロックするようになったことが要因と考えられます。

「パブリック アクセス ブロックが適用されているバケットの割合」を示す棒グラフ。AWS のバケットは 2024 年で約 78%、2025 年には 80% 超と保護範囲が拡大している。一方 Azure のバケットは、同期間でおよそ 40% から 60% 近くへと大幅に増加している。右側にはグラデーションの大きな文字で「AWS はデフォルトでのパブリック アクセス遮断で先行、Azure はより速い成長率を示す」と表示。

Azure では、実質的にパブリックになっている Azure Blob Storage コンテナーは 1.3% で、1 年前の 2.6%、2023 年の 5% から減少しています。また、Azure Blob Storage コンテナーのほぼ 3 分の 2 (58%) がパブリック アクセスを積極的にブロックするストレージ アカウント内にあり、これは 1 年前の 42% から大きく増加しています。この改善は、2023 年 11 月以降に作成されたストレージ アカウントに対し、Microsoft がデフォルトでパブリック アクセスをプロアクティブにブロックするようにしたことが要因と考えられ、セキュア バイ デフォルトの効果が現れていると言えます。

S3 バケットを誤って公開してしまうことを防ぐために、組織はアカウント レベルで S3 パブリック アクセス ブロックを有効化し、その設定を SCP で保護すべきです。さらに組織レベルでは、RCP を適用することで、AWS Organization 内のすべての S3 バケットにデータ境界を構成し、バケット ポリシーや ACL が誤設定されている場合でも、外部からの不正なアクセスを防ぐことが可能です。Azure では、ストレージ アカウントの設定でパブリック アクセスをブロックすることができ、この設定により、そのストレージ アカウント内の Blob Storage コンテナーが誤ってパブリック化されることを防止できます。

静的 Web アセットなど、一般的で正当なパブリック ストレージ バケットのユース ケースにおいては、Amazon CloudFront のようなコンテンツ配信ネットワーク (CDN) を使用する方が、通常はより安全で、効率的かつコスト効果にも優れています。

事実 6

サードパーティ連携の IAM ロールの過剰権限や誤設定が、依然として AWS アカウントのリスク要因に

サードパーティ ベンダーが IAM ロールを通じて顧客の AWS アカウントと連携するケースが増える中、プロバイダー側の AWS アカウントが侵害されると、攻撃者がプロバイダーと同じデータへアクセスできてしまう可能性が高いため、クラウド サプライチェーン リスクが高まります。

この分析では、SaaS プロバイダーに対応する既知の AWS アカウントを信頼している IAM ロールを対象に調査を行いました。その結果、1 組織あたり平均 13 個のサードパーティ連携用ロールをデプロイしていることがわかりました (2024 年の 10.2 個から増加)。また、これらのロールが連携しているベンダー数は平均 2.5 社でした (2024 年と同水準)。

次に、これらの連携ロールにおける一般的な 2 種類のセキュリティ リスクを調査しました。その結果、サードパーティ連携の 12.2% が危険な過剰権限を有しており、ベンダーがアカウント内のすべてのデータへアクセスできてしまう、あるいは AWS アカウント全体を乗っ取ることが可能性があることがわかりました。これは 2024 年の 10% からわずかに増加しています。また、2.25% のサードパーティ連携ロールでは外部 ID の使用が強制されていないことも判明しました。これらの結果は、クラウド環境におけるサードパーティ リスクが依然として深刻であり、組織は未使用ロールの削除や最小権限の付与を継続的に進める必要があることを示唆しています。

「サードパーティ連携ロールは依然として攻撃者の潜在的標的となり得る」を示すグラフィック。右側には次の 2 つのデータ ポイントが強調表示されている。12.2% のサードパーティ連携ロールが過剰権限 (2024 年比 +2.2 ポイント)、2.25% が外部 ID の使用を強制していない (+0.25 ポイント)。これら 2 つの数値が太枠のボックスで強調されている。
事実 7

不十分なデフォルト設定が、Kubernetes クラスターの重大な脆弱性に

Amazon EKS、Azure AKS、Google Cloud GKE などの一般的なマネージド Kubernetes サービスは、etcd のような複雑なコントロール プレーン コンポーネントではなく、アプリケーション ワークロードにチームが注力できるよう支援します。しかし、これらのサービスはデフォルト設定に十分なセキュリティが備わっていないことが少なくありません。これらのクラスターは本質的にクラウド環境上で稼働しているため、マネージド クラスターが侵害されると、攻撃者が基盤となるクラウド インフラへ横展開するさまざまな可能性が生まれます。また、インターネットに公開されたものはすべてスキャンされ、大量のノイズが発生し、本当の脅威への対応を妨げる恐れがあります。インターネットに面しているクラスターは、攻撃者がアイデンティティを悪用し、権限を昇格するための追加の侵入口ともなります。

まず、マネージド Kubernetes クラスターが管理 API サーバーをインターネットに公開している割合は、昨年と比べて減少したものの、依然として高い水準にあることがわかりました。EKS クラスターの 5 分の 2 (39%)、AKS クラスターの 3 分の 1 (34%) がインターネットに公開されています。GKE クラスターではこの比率がさらに高く、2 分の 1 超 (54%) に達します。興味深いことに、EKS と GKE のどちらについても、インターネットに公開される確率はクラスターの新旧とは無関係であり、新しいクラスターが古いものより非公開化されているわけではないことが確認されました。

「インターネットに公開されているマネージド Kubernetes クラスターの割合」を示す棒グラフ。2025 年時点で、Amazon EKS クラスターは約 40%、Azure AKS クラスターは約 30%、Google Cloud GKE クラスターは約 55% が依然として公開状態にある。右側にはグラデーションの大きな文字で「多くのマネージド Kubernetes クラスターが依然としてインターネットに公開されている」と表示。

また、これらのマネージド Kubernetes クラスターに付与されている IAM ロールを分析し、クラスターが侵害された場合に攻撃者がクラウド環境へ横展開できる可能性も評価しました。EKS では、13% のクラスターが危険なノード ロールを持っていることが判明しました。これらのロールは、アカウント全体へのフル管理者アクセス、権限昇格、過度に広いデータアクセス (全 S3 バケットなど)、アカウント内の全ワークロードへの横展開を可能にするなどのリスクを含んでいます。Google Cloud では、GKE クラスターの 10% が特権付きサービス アカウントを使用していました。内訳は、制限のない cloud-platform スコープを持つデフォルトの Compute Service Account によるものが 3%、顧客管理の Google Cloud サービス アカウントによるものが 8% でした。

「リスクの高い権限を持つマネージド Kubernetes クラスターの割合」を示す棒グラフ。2025 年時点で、Amazon EKS クラスターの 13%、Google Cloud GKE クラスターの 11% がリスクのある権限を保持しており、2024 年の 10% (EKS) および 15% (GKE) から増加している。GKE クラスターについては、デフォルト サービス アカウントとカスタム サービス アカウントの 2 種類に分けて表示されている。右側にはグラデーションの大きな文字で「マネージド Kubernetes クラスターの安全でないノード権限は依然としてリスク」と表示。

マネージド Kubernetes クラスターのインターネット公開は減少傾向にあるものの、多くのクラスターは依然として公開されたままです。これにより、自動攻撃やスキャンによるノイズ、(認証情報の窃取や悪用といった) 初期侵入リスク、さらには侵害後にクラウド環境へ横展開されるピボット リスクが発生します。つまり、クラスターが侵害されれば、その背後にあるクラウド環境も危険に晒されることになります。

組織は、特権的なクラウド ロールをクラスターのノードに付与することのリスクについても、以前より認識を深めています。これにより、侵害された Pod がクラスター外のリソースまで侵害を拡大するリスクは低減しています。特にデフォルト権限に関連するリスクは顕著に改善しており、GKE クラスターでは 3% まで低下しました。この変化は、組織がセキュア バイ デフォルトではない設定の危険性をより理解し、それらを修正する行動をとり始めていることを示唆しています。

事実 8

組織では依然としてリスクの高いワークロードが稼働中

EC2 インスタンスや Google Compute Engine (GCE) 仮想マシン (VM) に過剰権限を付与することは、引き続き重大なリスクを生み出します。攻撃者がアプリケーション レベルの脆弱性を悪用するなどしてワークロードを侵害した場合、そのワークロードに紐づく認証情報を窃取し、クラウド環境へアクセスできてしまうためです。

AWS では、管理者権限を持つ EC2 インスタンスは 0.4% 未満である一方、過剰権限を持つインスタンスは 5 分の 1 に近い 19.4% にのぼり、この割合は 2024 年の 19% と比較してほぼ横ばいでした。その内訳は以下のとおりです。

  • 3.8%: SSM Session Manager を用いた他インスタンスへの接続など、アカウント内で横展開を可能にするリスクのある権限を保有 (2024 年の 4.3% からわずかに減少)。横展開が可能になると、攻撃者が単一インフラから攻撃範囲を拡大できます。
  • 2.4% 新たに管理者権限を持つ IAM ユーザーを作成する、といった権限昇格によりアカウント全体を掌握可能な権限を保有 (2024 年の 2.8% から減少)。
  • 17.9% アカウント内のすべての S3 バケットを一覧表示、アクセスできるなど、過度に広いデータ アクセス権限を保有 (2024 年の 17.6% からわずかに増加)。
「機密性の高い権限種別ごとの EC2 インスタンス割合」を示す棒グラフ。全期間 (2023〜2025 年) を通じて、EC2 インスタンスの約 20% が過度に広いデータ アクセス権限を持っており、権限昇格、横展開、管理者アクセスといった他のリスク権限を持つインスタンスも一定数存在する。左側にはグラデーションの大きな文字で「4 台に 1 台近い EC2 インスタンスが過剰な権限を保持」と表示。

Google Cloud では、17% の VM が、制限のない cloud-platform スコープを持つ Compute Engine のデフォルト サービス アカウントを使用しており、実行中のプロジェクトに対するフル管理者 (editor) 権限を保持していることがわかりました。さらに、同じ仕組みにより 6% の VM が Google Cloud Storage (GCS) へのフル読み取りアクセス権を持っています。結果として、Google Cloud の VM のほぼ 4 分の 1 (23%) が、プロジェクトに対して過剰に広いアクセス権限を持っていることになります。

「Compute Engine のデフォルト サービス アカウントを通じてリスクの高い権限を持つ Google Cloud VM の割合」を示す棒グラフ。2023 年は 37%、2024 年は 33%、2025 年は 23% の VM がリスク権限を保持しており、その内訳は管理者アクセス権と機密データアクセス権に分かれている。左側にはグラデーションの大きな文字で「多くの Google Cloud VM が依然として過度に広い権限で稼働」と表示。

2024 年と比較すると、特権権限を持つ Google Cloud VM の総数は減少しています。特に、制限のないスコープ (unrestricted scope) を使用している VM の割合は 3 分の 1 にまで減少しました。一方で、Compute Engine のデフォルト サービス アカウントに起因する特権 VM の割合は変化していません。

Datadog のセキュリティ レポートやイベント、最新情報をお届けします。

Datadog Security Digest を申し込む

方法論

本調査の分析結果は、2025 年 9 月に収集したデータに基づいています。

対象母集団

本レポートでは、数千の組織を対象にクラウド セキュリティの現状を分析しました。本レポートで使用したデータは、Datadog Infrastructure Monitoring、Datadog Logs、Datadog Cloud Security の各サービスをご利用いただいているお客様のデータに基づいています。

Fact 1

For this fact, we analyzed how many AWS accounts each organization has. We take into account both when AWS accounts are integrated individually, and integrated at the AWS Organization level.

When measuring adoption of non-default service control policies (SCPs) and resource control policies (RCPs), we can only analyze organizations that integrate their AWS Organizations management account, and we reflect this in the denominator of the ratios used.

Fact 2

We analyzed SCPs, RCPs, VPC endpoint policies, and S3 bucket policies and considered that they were using an AWS data perimeter when they contained any of the following AWS IAM condition keys in any of the statements:

aws:PrincipalAccount
aws:PrincipalOrgID
aws:PrincipalOrgPaths
aws:ResourceAccount
aws:ResourceOrgID
aws:ResourceOrgPaths
aws:SourceAccount
aws:SourceIp
aws:SourceOrgID
aws:SourceOrgPath
aws:SourceVpc
aws:SourceVpce

For this edition, we did not take into account the condition keys aws:VpceAccount, aws:VpceOrgPaths, or aws:VpceOrgID, which were released a few days before the snapshot of the data in use.

The ratio of organizations using SCPs, RCPs, VPC endpoints, or S3 bucket policies to implement a data perimeter was computed over the number of total organizations having at least one such SCP, RCP, VPC endpoint, or S3 bucket.

Fact 3

AWS console authentication method

To identify the method used to authenticate the AWS console, we used CloudTrail events with the event type ConsoleLogin. Specifically, we considered that the authentication was performed through an IAM user for all events matching:

source:cloudtrail 
  AND @evt.name:ConsoleLogin 
  AND @userIdentity.arn:*user/*
  AND NOT @userIdentity.arn:*:root*

We considered that the authentication was performed through a federated identity provider for all events matching:

source:cloudtrail AND (
(@evt.name:ConsoleLogin @userIdentity.arn:*assumed-role/*)
  OR
  (source:cloudtrail @evt.name:ConsoleLogin 
@userIdentity.arn:*federated-user/*)
)

Long-lived credentials

For AWS, we considered IAM users that have at least one active access key. When an IAM user had several active access keys, we considered only the oldest one.

For Google Cloud, we considered service accounts that are not disabled and have at least one active access key. We excluded from our analysis Google-managed service accounts, for which it’s not possible to create user-managed access keys.

For Microsoft Entra ID, we considered Microsoft Entra ID app registrations that had active “password” credentials (corresponding to static access keys that can be exchanged for OAuth 2.0 access tokens).

Fact 4

In the graph that depicts average enforcement of IMDSv2, we computed for each organization the percentage of its EC2 instances where IMDSv2 is enforced, and averaged this number across all organizations. We used this method so as not to overrepresent organizations that have a large number of EC2 instances and instead to measure adoption trends.

In the bubble chart that depicts average enforcement of IMDSv2 per instance age, we computed for each organization the percentage of its EC2 instances where IMDSv2 is enforced and averaged this number across all EC2 instances within a specific age bucket. The area of each bubble is proportional to how many EC2 instances fall into this age bucket, independently of whether they enforce IMDSv2.

For historical data, we queried 14 days of CloudTrail logs and used the field userIdentity.sessionContext.ec2RoleDelivery to determine if IMDSv2 had been used to request initial session credentials. We only analyzed CloudTrail generated by EC2 instances, meaning where userIdentity.session_name starts with i-.

For data related to the IMDSv2-by-default regional feature, we analyzed the percentage of EC2 instances with IMDSv2 enforced by AWS account and region, and compared the rate depending on whether the “IMDSv2-by-default” feature was enabled in this region and AWS account.

Fact 5

For AWS, we considered an S3 bucket public if both of the following were true:

  • The bucket policy allows s3:GetObject on all objects in the bucket to a wildcard principal.
  • The public access block configuration of neither the bucket nor the AWS account has restrict_public_buckets set to true.

We considered that an S3 bucket is “covered by a public access block” if the bucket public access block configuration or the AWS account public access block configuration has the four settings block_public_acls, block_public_policy, ignore_public_acls, and restrict_public_buckets set to true.

We excluded from the analysis S3 buckets that are made public through the static website feature, as this is a valid use case for public S3 buckets that is not necessarily covered by CloudFront, and also because it gives a strong signal that the bucket was explicitly meant to be public by design.

For Azure, we considered that an Azure blob storage container is publicly accessible if both of the following were true:

  • Its PublicAccess field is set to blob or container.
  • The storage account it resides in does not block public access—i.e., its allowBlobPublicAccess attribute is not set to false.

We considered that an Azure blob storage container is “covered by a public access block” if it’s in a storage account that blocks public access—i.e., whose allowBlobPublicAccess attribute is not set to false.

Fact 6

We considered that an IAM role is an integration role for a known SaaS vendor if its trust policy has a trust relationship with an AWS account from the list of known AWS accounts, with some additional tuning to add known vendors that aren’t part of this list and consulting companies that are not applicable to the SaaS integration use case.

We considered that an IAM role does not enforce an external ID if its trust policy does not have any condition or if it has a condition that does not use the operators StringEquals, StringLike, or ForAnyValue:StringEquals on the condition key sts:ExternalId.

Fact 7

Internet exposure

We determined that an Amazon EKS cluster was exposed to the internet if both of the following were true:

  • Its resources_vpc_config.endpoint_public_access attribute is set to true.
  • Its resources_vpc_config.public_access_cidrs attribute contains 0.0.0.0/0.

We determined that a Google Cloud GKE cluster was exposed to the internet if all of the following were true:

  • Its private endpoint is disabled (i.e., private_cluster_config.enable_private_endpoint was set to false).
  • Its public endpoint is enabled (i.e., private_cluster_config.public_endpoint contained a public IP).
  • Its network configuration allows internet traffic—i.e., it meets one of the following conditions:
    • Its "authorized networks" are disabled (i.e., master_authorized_networks_config.enabled is false).
    • Its "authorized networks" contain 0.0.0.0/0 (master_authorized_networks_config.cidr_blocks).
    • Its "authorized networks" configuration explicitly allows all Google Cloud IPs (gcp_public_cidrs_access_enabled).

We determined that an Azure AKS was exposed to the internet if:

  • It is not configured as a private cluster (i.e., api_server_access_profile.enable_private_cluster was set to false).
  • Its network configuration allows internet traffic—i.e., if one of the following was true:
    • Its authorized IP ranges (api_server_access_profile.authorized_ip_ranges) contained 0.0.0.0/0.
    • It contained no specific IP range, meaning it did not limit ingress traffic.

Node privileges

We determined that an Amazon EKS cluster had nodes with a risky role using the same methodology as described in Fact 7. We considered that an EKS cluster was risky if at least one of its managed node groups had a risky node role.

For Google Cloud, we determined that a GKE cluster had nodes with a risky service account if one of these conditions were met:

  • The service account associated with the cluster nodes is the Compute Engine default one, with an unrestricted cloud-platform scope, and this default service account is mapped to the editor or owner role at the project level.
  • The service account associated with the cluster nodes is any service account mapped to the editor or owner role at the project level.

For Azure AKS, analyzing node permissions requires visibility on both Azure AKS and Entra ID service principals. As our dataset did not have a satisfying number of organizations with both data sources to be representative enough, we did not include Azure AKS in this analysis.

Following a change in methodology to make this number more accurate, we have edited the data for AKS we published in our 2024 edition down from 41% to 32%.

Fact 8

For this fact, AWS data was sourced in August 2025 and October 2025.

For AWS, we considered that an EC2 instance has an administrative role if it has an instance role that’s attached to either the AdministratorAccess AWS-managed policy or to a custom policy that has at least one statement allowing all actions on all resources, with no conditions.

We considered that an EC2 instance has “excessive data access” if one of the following conditions is true:

  • Its instance role has any of the following combinations of permissions on the resource *, through an inline or attached policy:
s3:listallmybuckets, s3:listbucket, s3:getobject
dynamodb:listtables, dynamodb:scan
dynamodb:listtables, dynamodb:exporttabletopointintime
ec2:describesnapshots, ec2:modifysnapshotattribute
ec2:describesnapshots, ebs:listsnapshotblocks, ebs:listchangedblocks, ebs:getsnapshotblock
rds:describedbclustersnapshots, rds:modifydbclustersnapshotattribute
rds:describedbsnapshots, rds:modifydbsnapshotattribute
secretsmanager:listsecrets, secretsmanager:getsecretvalue
ssm:describeparameters, ssm:getparameter
ssm:describeparameters, ssm:getparameters
secretsmanager:getparametersbypath
  • Its instance role is attached to one of the following AWS managed policies (which all meet the criteria above):
AdministratorAccess
AdministratorAccess-Amplify
AmazonApplicationWizardFullaccess
AmazonDataZoneProjectRolePermissionsBoundary
AmazonDocDBConsoleFullAccess
AmazonDocDBElasticFullAccess
AmazonDocDBFullAccess
AmazonDynamoDBFullAccess
AmazonDynamoDBFullAccesswithDataPipeline
AmazonDynamoDBReadOnlyAccess
AmazonEC2FullAccess 
AmazonEC2RoleforDataPipelineRole
AmazonElasticMapReduceforEC2Role
AmazonElasticMapReduceFullAccess
AmazonElasticMapReduceReadOnlyAccess
AmazonElasticMapReduceRole
AmazonGrafanaRedshiftAccess
AmazonLaunchWizard_Fullaccess
AmazonLaunchWizardFullaccess
AmazonLaunchWizardFullAccessV2
AmazonMacieServiceRole
AmazonMacieServiceRolePolicy
AmazonRDSFullAccess
AmazonRedshiftFullAccess
AmazonS3FullAccess
AmazonS3ReadOnlyAccess
AmazonSageMakerFullAccess
AmazonSSMAutomationRole
AmazonSSMFullAccess
AmazonSSMReadOnlyAccess
AWSBackupServiceRolePolicyForBackup
AWSCloudTrailFullAccess
AWSCodePipelineReadOnlyAccess
AWSCodeStarServiceRole
AWSConfigRole
AWSDataExchangeFullAccess
AWSDataExchangeProviderFullAccess
AWSDataLifecycleManagerServiceRole
AWSDataPipelineRole
AWSElasticBeanstalkCustomPlatformforEC2Role
AWSElasticBeanstalkFullAccess
AWSElasticBeanstalkReadOnlyAccess
AWSIoTDeviceTesterForFreeRTOSFullAccess
AWSLambdaFullAccess
AWSLambdaReadOnlyAccess
AWSMarketplaceSellerFullAccess
AWSMarketplaceSellerProductsFullAccess
AWSOpsWorksRole
DatabaseAdministrator
DataScientist
NeptuneConsoleFullAccess
NeptuneFullAccess
ReadOnlyAccess
SecretsManagerReadWrite
ServerMigrationServiceRole
SystemAdministrator
VMImportExportRoleForAWSConnector

We considered that an EC2 instance has “permissions allowing lateral movement” if one of the following conditions was true:

  • Its instance role has any of the following combinations of permissions on the resource *, through an inline or attached policy:
ec2-instance-connect:sendsshpublickey
ssm:startsession
ssm:sendcommand
ec2:getserialconsoleaccessstatus, ec2:describeinstances, ec2:describeinstancetypes, ec2-instance-connect:sendserialconsolesshpublickey
  • Its instance role is attached to one of the following AWS managed policies (which all meet the criteria above):
AdministratorAccess
AmazonApplicationWizardFullaccess
AmazonLaunchWizardFullaccess
AmazonSSMAutomationRole
AmazonSSMFullAccess
AmazonSSMMaintenanceWindowRole
AmazonSSMServiceRolePolicy
AWSOpsWorksCMServiceRole
EC2InstanceConnect

To identify if an EC2 instance was running in an organization’s AWS Organization management account, we selected all Datadog customers who integrate with their AWS Organization management account and identified these where at least one EC2 instance was running in it.

For Google Cloud, we considered that:

  • A VM has administrator privileges on the project when the default compute service account is used with the cloud-platform scope.
  • A VM has read access to the project’s cloud storage when the default compute service account is used with the devstorage.read_only scope.

We excluded VMs in a project where the default compute service account had not been granted editor or owner access. In other words, we did take into account the case where the recommended iam.automaticIamGrantsForDefaultServiceAccounts organization policy is in effect, “neutralizing” the default permissions of the default compute service account.

For Azure, analyzing virtual machine permissions requires visibility on both Azure compute and Entra ID service principals. As our dataset did not have a satisfying number of organizations with both data sources to be representative enough, we did not include Azure virtual machines in our analysis.

Licensing

Report: CC BY-ND 4.0

Images: CC BY-ND 4.0