『2025 年クラウド セキュリティの現状』の調査で得られた主な知見

当社は『2025 年クラウド セキュリティの現状』の調査をリリースしました。このドキュメントでは、AWS、Azure、Google Cloud を使用している数千の組織について、セキュリティ体制を分析しています。特に、以下が明らかになりました。

• 多くの組織が AWS Organizations を使用してマルチアカウント環境を一元管理
• データ境界の導入が進む一方で、多くの組織では一元管理の仕組みが欠如
• 長期間更新されていないクラウド認証情報の蔓延とリスクが依然として深刻
• EC2 インスタンスの半数で IMDSv2 が適用されている一方で、旧インスタンスでは対応に遅れ
• クラウド ストレージ サービスにおけるパブリック アクセス ブロックの導入は頭打ち
• 組織では依然としてリスクの高いワークロードが稼働中

この投稿では、上記の調査結果に基づいて主な推奨事項を提供し、組織のセキュリティ体制を強化する目的で Datadog Cloud Security を使用する方法について説明します。

AWS マルチアカウント アーキテクチャで組織的なガードレールを使用

AWS クラウド環境は通常、複数のチーム、アプリケーション、および事業領域にわたっています。AWS アカウントは、アイデンティティおよびアクセス管理 (IAM)、コスト追跡、およびクォータ割り当ての分離境界として機能しています。このため、セキュリティ侵害の “被害範囲” を最小限に抑え、確実に各チームが独立して効率的な方法で作業できるように、複数の AWS アカウントを使用することが推奨されています。

同じ組織内に複数の AWS アカウントを導入する最良の方法は、AWS Organizations を使用することです。これは、シングル サインオン (SSO)、コスト追跡、バックアップ ポリシーなどの重要な機能を実装できる無料の AWS サービスです。標準的な構成では、ネットワーク管理、ログ記録、セキュリティなどの重要な機能を担当する “コア” AWS アカウントと、通常はアプリケーションごとに 1 つのアカウントを環境ステージごとに作成する “ワークロード” AWS アカウントを組み合わせて使用します。

AWS Organizations には追加のセキュリティ機能が多数装備されており、そのうちの 2 つはサービス コントロール ポリシー (SCP) とリソース コントロール ポリシー (RCP) です。これらを使用すると、AWS アカウントの全部または一部にガードレールを設定でき、危険な、または不要なアクションを未然にブロックできます。通常、組織に堅牢な SCP と RCP を実装すると組織全体で一貫したセキュリティ ベースラインを確保しつつ、開発者に権限を委譲できます。

組織レベルの推奨ポリシーの例をいくつか示します。

• ルート ユーザーのアクセスをブロックする (SCP)
• 承認されていないリージョンの使用を拒否する (SCP)
• AWS アカウントを AWS 組織から削除する機能を拒否する (SCP)
• すべての S3 バケットのアクセスを、暗号化した TLS 接続経由にのみ限定する (RCP)
• GitHub Actions とアイデンティティ フェデレーションを併用する場合、信頼できる OIDC ID プロバイダーへのアクセスを制限する (RCP)

詳細および実装のガイダンスについては、AWS のテクニカル ホワイト ペーパー『複数アカウントを使用した AWS 環境の構成』(英語) を参照してください。また、re:Invent コンベンションでの対談『AWS での構成と運用に関するベスト プラクティス』(英語) もご覧ください。現在当社のセキュリティ エンジニアアリング担当 VP である Bianca Lankford が出演しています。

組織全体のクラウド インフラストラクチャのセキュリティを向上させる Datadog Cloud Security の仕組み

Datadog 製品を導入すると、組織の AWS アカウントがいくつあっても、リソースを 1 つの画面に表示して、クラウド インフラストラクチャのモニタリングと保護ができます。

Close dialog

AWS CloudFormation StackSets、Terraform (オープンソース)、または AWS Control Tower を使用して、Datadog 製品を AWS Organizations レベルで統合できます。

データ境界を AWS に実装して認証情報窃取の影響を最小限に低減

クラウド環境のセキュリティ侵害の多くは、クラウド認証情報の漏洩に起因しています。クラウド認証情報の漏洩は一般的に、開発者による意図しない漏洩、または攻撃者による公開 Web アプリケーションの悪用からの窃取により発生しています。データ境界を使用すると、想定したネットワーク、VPC、またはサブセットから信頼できる ID を受信した場合にのみ、組織のリソースへのアクセスを許可することで、認証情報の漏洩リスクを低減できます。

AWS では、VPC エンドポイント ポリシー、SCP、RCP と、aws:PrincipalOrgID などのグローバル IAM 条件キーを組み合わせて、データ境界を実装できます。条件キーは、認証プロセスでソース ID またはターゲット リソースの場所に関して詳細なコンテキストを提供するものです。

データ境界を実装する一般的なパターンをいくつか示します。

• S3 バケットへのアクセスを、特定のサブネットから VPC エンドポイント経由で認証済みのプリンシパルに限定する
• 現在のアカウントの S3 バケットへのデータ書き込みを、権限によらず特定サブネットの EC2 インスタンスに限定して、リスク流出のリスクを低減する
• 特定の IAM ロール (EC2 インスタンスに割り当てたものなど) の使用を、特定の VPC から送信されたものに限定して、認証情報の流出リスクを低減する

詳細および実装のガイダンスについては、AWS のテクニカル ホワイト ペーパー『AWS へのデータ境界の構築』(英語) を参照してください。また、fwd:cloudsec カンファレンスでの講演『データ境界の実装戦略: SCP/RCP の展開からの知見』(英語) と『AWS データ境界の構築の全容』(英語) もご覧ください。

データ境界を強化する Datadog Cloud Security の仕組み

Datadog Cloud Security を導入すると、データ境界を実装するときに、製品に用意されているルールを使用して、VPC エンドポイント ポリシーが強化されていない VPC エンドポイントを特定できます。

また、S3 など、重要なサービスの VPC エンドポイントを持たないサブネットを特定するカスタム ルールを簡単に作成することもできます。

1
package datadog
2

3
import data.datadog.output as dd_output
4

5
import future.keywords.contains
6
import future.keywords.if
7
import future.keywords.in
8

9
eval(resource) = "pass" if {
10
  has_s3_vpc_endpoint(resource)
11
} else = "fail"
12

13
has_s3_vpc_endpoint(subnet) if {
14
  some endpoint in input.resources.aws_vpc_endpoint
15
  endpoint.vpc_id == subnet.vpc_id
16
  endpoint.subnet_ids[_] == subnet.id
17
  endswith(endpoint.service_name, ".s3")
18
}
19

20
results contains result if {
21
  some resource in input.resources[input.main_resource_type]
22
  result := dd_output.format(resource, eval(resource))
23
}

上記のコードを使用してダッシュボードを作成し、クラウド セキュリティの履歴を反復的に追跡できます。

長期間更新していない認証情報の削減と制限

認証情報は、静的 (つまり更新されない) で無期限に有効の場合、更新されていないと見なされます。このようなタイプの認証情報が、実際の多数のデータ漏洩インシデントの原因であり、組織ではそれらの認証情報の使用を停止することが推奨されます。

セキュアな環境を構築するには、新規の脆弱性の導入を確実に排除しつつ、セキュリティの低い手法のバックログを確認するという組み合わせの手法が多くの場合に使用されています。未然に、セキュリティの低い、長期間更新されていない認証情報の作成をブロックするオプションがいくつか存在します。AWS では、SCP を使用して IAM ユーザーの作成をブロックできます。Google Cloud では、組織ポリシー iam.managed.disableServiceAccountKeyCreation を有効にすることで、長期間変更されないサービス アカウント キーの作成を拒否しつつ、サービス アカウントを開発者のワークロードに関連付けることができます。

長期間変更されない認証情報の使用を防止する Datadog Cloud Security の仕組み

Datadog Cloud Security には、長期間使用されない認証情報を特定し、修正の優先順位を付けるためのツールがいくつか用意されています。

まず、Cloud Security の［Inventory］を使用して、組織のクラウド環境全体の IAM ユーザー、および Google Cloud のサービス アカウントまたはサービス アカウント キーを特定します。クラウド ID に問題がある (過剰な権限が付与されているなど) 場合、［Inventory］によりフラグが設定されるため、AWS IAM ユーザーのアクセス キーを削除するなどの修正手順に優先順位を付けることができます。

Close dialog

長期間更新されていない認証情報を特定して削除するときに、以下のクラウド構成ルールも役立ちます。

• Google Cloud: 「サービス アカウントでは GCP マネージド キーのみを使用する」(英語) により、アクティブなユーザー管理アクセス キーを持つ Google Cloud サービス アカウントを即座に特定できます。
• AWS: 「‘root’ を付与するアクセス キーを削除する」(英語) により、AWS ルート ユーザーのアクセス キーを追跡して削除できます。
• AWS: 「作成時点からの期間、および非アクティブな期間が 1 年を超える IAM アクセス キーを削除する」
• AWS: 「アクセス キーは 90 日以内に 1 回、ローテーションを行う」

Amazon EC2 インスタンスへの IMDSv2 の導入

昨年の主な知見で当社が提示した推奨事項と同様ですが、EC2 インスタンスに Instance Metadata Service Version 2 (IMDSv2) を適用して、攻撃者に悪用される頻度の高い SSRF の脆弱性から保護することが重要です。 EC2 の IMDSv2 は、サーバー側リクエスト偽造攻撃 (SSRF) の脆弱性からアプリケーションを保護するうえで役立ちますが、新規作成された EC2 インスタンスでは多くの場合、デフォルトで脆弱な IMDSv1 プロトコルとよりセキュリティの高い IMDSv2 プロトコルの両方を使用できます。 AWS には、IMDSv2 への移行をサポートするガイドと、このトピックに関するブログがあります。その他にも、いくつかの仕組みを使用できます。

• 特定の Amazon Machine Image (AMI) にデフォルトで IMDSv2 を適用する仕組み (2022 年リリース)
• コンソールから開始される EC2 インスタンス用の、セキュリティがより高いデフォルトセット (2023 年リリース)
• リージョン レベルで IMDSv2 をデフォルトで適用する仕組み (2024 年リリース、Datadog はこの仕組みのサポートを Terraform AWS Provider で提供)

リスクの高いインスタンスを特定する Datadog Cloud Security の仕組み

Datadog Cloud Security の構成ミスに関するルール「EC2 インスタンスで IMDSv2 を使用する」(英語) と CSM の問題「公開アクセス可能な EC2 instance が IMDSv1 を使用している」(英語) を使用して、IMDSv2 を適用していない EC2 インスタンスを特定できます。

さらに、攻撃経路「公開アクセス可能な EC2 ホストが IMDSv1 を実行中で、SSRF の脆弱性を有している」(英語) を使用して、喫緊のリスクの高いインスタンスを容易に特定できます。

Close dialog

クラウド ストレージ サービスの公開アクセスに対してガードレールを実装

クラウド サービスでは、データにより簡単にアクセスできます。残念ながら、適切なガードレールを配置しなければ、正しく構成されていないクラウド ストレージ バケットに、インターネット上の誰でも容易にパブリック (公開) アクセスが可能です。クラウド ストレージが関与する漏洩は 15 年以上にわたって発生していますが、そのようなインシデントは引き続き 2025 年にも発生し、医療記録、データベースのバックアップ、または金融記録が漏洩しています。

そのような脆弱性から保護する最良の方法は、ヒューマン エラー (S3 バケットのポリシーの構成エラーなど) がそのままデータ漏洩に直結しないように、ガードレールでユーザー操作を制限することです。これは、道路脇のガードレールにより、カーブを曲がり損ねた自動車が谷に落ちないように保護することに似ています。

AWS では、S3 のパブリック アクセスのブロックにより、バケット レベルまたはアカウント レベルで過去および将来の S3 バケットがパブリックになることを防止できます。この機能をアカウント レベルで有効にして、この構成を組織の標準アカウントのプロビジョニング プロセスに組み込むことを推奨します。2023 年 4 月から、AWS は新規作成されたバケットによるパブリック アクセスをデフォルトでブロックしています。ただし、この日以前に作成されたバケットはブロックされません。追加の保護に関するベスト プラクティスには、S3 のパブリック アクセス ブロック設定を制限する組織全体の SCP と、組織のすべての S3 バケット (パブリックに構成されている場合も含む) への不正なアクセスを自動的にブロックする組織全体の RCP を作成することも含まれます。

1
{
2
    "Version": "2012-10-17",
3
    "Statement": [
4
        {
5
            "Sid": "DenyS3AccessFromOutsideOrg",
6
            "Effect": "Deny",
7
            "Principal": "*",
8
            "Action": [
9
                "s3:GetObject",
10
                "s3:ListBucket",
11
                "s3:GetBucket*"
12
            ],
13
            "Condition": {
14
                "StringNotEquals": {
15
                    "aws:PrincipalOrgID": "o-xxxxxxxxxx"
16
                },
17
                "Bool": {
18
                    "aws:PrincipalIsAWSService": "false"
19
                }
20
            }
21
        }
22
    ]
23
}

Azure にも類似の仕組みが存在し、ストレージ アカウントの「blob のパブリック アクセスを許可する」パラメーターを使用します。AWS と同様に、2023 年 11 月以降に作成されたすべての Azure ストレージ アカウントは、デフォルトでバブリック アクセスをブロックします。

Google Cloud では、組織のポリシー制約 constraints/storage.publicAccessPrevention を使用して、バケット、プロジェクト、フォルダー、または組織のレベルでGoogle Cloud Storage (GCS) バケットへの公開アクセスを防止できます。

正当な理由 (静的な Web アセットのホスティングなど) でストレージ バケットを公開する必要がある場合、通常はバケットを直接公開するよりも、Amazon CloudFront や Azure CDN などのコンテンツ配信ネットワークを使用するほうが、コストとパフォーマンスで優れています。

脆弱なクラウド ストレージ バケットを特定する Datadog Cloud Security の仕組み

Datadog Cloud Security で以下のルールを使用して、脆弱なクラウド ストレージ バケットを特定できます。

• 「S3 バケットのコンテンツへのアクセスを、承認済みプリンシパルにのみ許可する」(英語)
• 「S3 バケットの『パブリック アクセスのブロック』が有効になっている」(英語)
• 「S3 のパブリック アクセスのブロック機能がアカウント レベルで有効である」(英語)
• 「S3 バケットの ACL でパブリックの書き込み操作をブロックする」(英語)
• 「Blob コンテナへの匿名アクセスを制限する」(英語)
• 「クラウド ストレージ バケットへの匿名アクセスまたはパブリック アクセスを許可しない」(英語)

Close dialog

Datadog 製品は、ストレージ バケットへのパブリック アクセスが可能になるタイミングも判定するため、組織では関連する構成ミスにフィルターを適用して、最も重大な問題を持つ構成エラーに専念できます。

クラウド ワークロードに割り当てる権限を制限

Amazon EC2 インスタンスや Google Cloud Run の機能などのクラウド ワークロードには、ストレージ バケットにファイルをアップロードしたり、クラウド管理データベースにアクセスしたりするなど、クラウド環境をスムーズに操作するための権限が頻繁に付与されます。これらのワークロードは通常インターネットに露出し、攻撃者にとって絶好のターゲットになります。攻撃者によるクラウド ワークロードの侵害では、一般的に、インスタンス メタデータを呼び出したり環境変数を読み取ったりして、関連するクラウド ロールの認証情報を抜き取ります。

このため、クラウド ワークロードに適切な権限を付与することが重要です。そのようにしない場合、攻撃者は単一ワークロードの侵害を手始めに、クラウド環境全体まで侵害するおそれがあります。

開発中には、iamlive などのツールを使用して、ワークロードに必要なクラウド権限を特定できます。実行時には、AWS IAM Access Analyzer や Google Cloud Policy Intelligence などのクラウド プロバイダ ツールを使用し、付与した権限を効果的な使用と比較して、特定のポリシーの適用範囲をより厳密に設定するための提案を行えます。(注: 2024 年 1 月から、Google は Policy Intelligence へのアクセスを、組織レベルで Security Command Center を使用している組織に制限しています。)

一見して無害に思われる権限により権限昇格が有効になるおそれがある点に、注意することが重要です。例えば、AWS マネージド ポリシー AWSMarketplaceFullAccess は無害に見えますが、このポリシーでは、攻撃者がEC2 インスタンスを開始してそれを権限付きロールに割り当てることで、すべての権限を持つ管理者としてアカウントにアクセス可能になります。

リスクの高いワークロードを特定する Datadog Cloud Security の仕組み

構成ミスに関する以下の Cloud Security のルールを使用して、リスクの高いワークロードを特定できます。

• AWS: 「EC2 インスタンスに高い権限を持つ IAM ロールが付与されていてはならない」(英語)
• AWS: 「公開アクセス可能な EC2 インスタンスに高い権限を持つ IAM ロールが付与されていてはならない」(英語)
• AWS: 「Lambda 機能の構成に権限付き実行ロールが含まれていてはならない」(英語)
• Google Cloud: 「インスタンスの構成には、API アクセスを制限した、デフォルト以外のサービス アカウントを使用する」(英語)

Close dialog

Datadog Cloud Security は詳細なコンテキスト グラフを表示するだけでなく、影響を受けたワークロードの “被害範囲” (インスタンスが侵害された場合、さらにアクセス可能になるリソース) も示します。

一般的なクラウドのリスクから組織のインフラストラクチャを保護

当社の『2025 年クラウド セキュリティの現状』の調査では、組織が引き続き、長期間更新されないクラウド認証を削減し、“デフォルトで保護” の仕組みを導入し、AWS、Azure、および Google Cloud での IAM 権限をより正確に管理していることが示されました。それでも依然として、多くの組織の主要なリソースが既知の悪用と起こり得る攻撃にさらされています。データ境界の実装やマルチアカウント環境の一元管理など、強力な保護を提供する新規戦略の導入が増えていますが、多くの場合、新規リスクの発生を避けるために入念な構成が必要です。このブログでは、チームがこれらの課題に取り組み、Datadog Cloud Security を使用して組織のクラウド環境を保護する方法を中心に説明しました。

当社のドキュメントを確認して、Datadog Cloud Security の使用を開始しましょう。Datadog を初めて使用する方は、14 日間の無料トライアルにサインアップしてください。