Cloud Security

誤設定、権限リスク、脆弱性を 1 製品で見る (旧称 CSM)

Cloud Security は、クラウド基盤の設定監査、ID 権限のリスク評価、脆弱性検出を 1 つの基盤で提供する製品です。製品名は Cloud Security に改められ、旧称は Cloud Security Management (CSM) で、料金ページのカード名は 2026 年 9 月時点で CSM Pro / CSM Enterprise のままです (出典: Cloud Security)。Misconfigurations は本番環境の設定の衛生状態とコンプライアンス姿勢を追い、監査証跡の収集を自動化します。Identity Risks は AWS IAM / Azure / GCP の権限リスクを継続的に洗い出します。Vulnerabilities はコンテナイメージ、ホストイメージ、稼働中ホストの脆弱性を検出して優先順位を付けます。ログから攻撃の痕跡を見つける仕事は Cloud SIEM の領分で、本製品は構成と中身の危なさを見る側です。

Agent なしで何が見え、Agent を足すと何が変わるか

公式の導入手順は、Agentless Scanning を有効にしてから重要なホストへ Datadog Agent を配備する順です。Agentless Scanning は AWS / Azure / GCP を最も広く覆い、全てのホストと稼働中コンテナを走査します。Agent を足すと、実行時の文脈に基づく脆弱性の優先付け、リアルタイムの更新が加わり、脆弱性の更新頻度は Agentless の 12 時間からリアルタイムに変わります (2026 年 9 月時点・出典: Setting Up Cloud Security)。裏返すと、Agent だけでは Identity Risks とホストのベンチマークは埋まらず、Agentless だけでは実行時の文脈が付きません。Agent が既にあるホストは Agent 側、無い所は Agentless という分け方が公式の推奨と一致します。

誤設定と脆弱性はどう違うか

誤設定 (Misconfiguration) は、クラウドやインフラの設定の状態が検出ルールに照らして望ましくないことで、ルールは設定の状態を走査して規定に合わない資源を見つけます (2026 年 9 月時点・出典: Cloud Security)。脆弱性 (Vulnerability) は、ホストやコンテナイメージ、サーバーレス関数に含まれるパッケージに既知の弱点 (CVE) があることで、設定が正しくても存在し得ます。Identity Risks は付与された権限と実際に使われた権限の差が大きいユーザーやロールを見つけるもので、AWS CloudTrail のログを取り込むと精度が上がると公式は説明しています (出典: Setting Up Cloud Security)。切り分けの効き目は担当の違いに出ます。誤設定は設定変更で直す基盤担当の仕事、脆弱性はイメージの再ビルドやパッケージ更新をする開発側の仕事になりやすく、同じ一覧に並んでいても直す人が違います。

Security Posture Score は何の割合か

Misconfigurations には security posture score という指標があり、有効になっている既製のクラウド設定ルールとインフラ設定ルールを全て満たしている環境の割合を表します (2026 年 9 月時点・出典: Cloud Security)。スコアを上げる手段は 2 つで、誤設定そのものを直すか、その誤設定をミュートするかです (出典: Datadog Glossary)。ここが運用の分岐で、ミュートは「意図してこの設定にしている」という例外の記録として使い、理由を残さずスコア目当てで消すと監査時に説明できなくなります。週次ダイジェストは利用者ごとに購読し、直近 7 日で見つかった重要な問題の要約が届きます。直した件数ではなく「環境全体の何割が規定を満たしているか」で会話できるのが、この指標の効き目です。

CVSS だけで並べない - 実行時の文脈で優先順位を付け直す

CVSS の高い順に並べただけの一覧では、本番で動いていないパッケージが上位を占めます。公式ドキュメントは Datadog Severity Score という独自の重大度を置き、基本の CVSS に機微データの有無、環境の重要度、攻撃への露出、悪用コードの有無、脅威インテリジェンスを重ねて悪用可能なものを先頭に出すと説明しています (2026 年 9 月時点・出典: Cloud Security Vulnerabilities)。コンテナイメージではレイヤー単位で辿れ、ビルド時に OCI イメージ注釈を付けておけば CVE から Dockerfile と該当コミットまでたどれます。Infrastructure Packages Catalog では全パッケージの在庫 (SBOM) を検索して、新しい CVE の影響範囲を見積もれます。アプリのライブラリの脆弱性は Code Security 側の Software Composition Analysis が担います。

料金表の CSM Pro と CSM Enterprise は何が違うか

2026 年 9 月時点の料金ページでは、CSM Pro と CSM Enterprise がいずれもホストあたりの月額で示され、年契約 / 月契約 / オンデマンドの契約形態ごとに単価が並びます (出典: Datadog Pricing)。Enterprise は Pro の全機能に、ファイル整合性監視、Workload Protection (Linux / Windows / Kubernetes / Docker / AWS Fargate)、コンテナ割当の上乗せを足したものです。境目は「実行中の挙動まで見るか」で、設定と脆弱性までなら Pro、プロセスやファイルの挙動から脅威を検出するなら Enterprise です。ホスト単価とコンテナ単価の実額は料金ページの公開価格表で確認してください。監視側の Pro / Enterprise の違いは別記事に、料金の全体像は料金の読み解きに委ねます。

本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。

監視の Agent が既にいるホストで追加になる費用は何か

インフラ監視で Agent を入れているホストなら、公式が挙げる「既に配備している unified Datadog Agent を使う」経路で同じ Agent から有効化できます (2026 年 9 月時点・出典: Cloud Security Vulnerabilities)。上乗せは CSM 単価で、課金対象のホストは料金ページ FAQ の定義で、Datadog が監視する物理または仮想の OS インスタンス (サーバー / VM / Kubernetes ノードなど) です (出典: Datadog Pricing)。上乗せの月額は「課金対象のホスト数 × 選んだプランの単価」で決まるので、Agent があるホストの全数で有効化すれば、その全数分がそのまま乗ります。重要ホストだけ Agent 側で有効化し、残りを Agentless で覆うのが費用の初手です。AWS 連携のロールはインテグレーション、Kubernetes での配置はコンテナ監視、閲覧権限は RBAC に委ねます。

有効化の順番はどう決めるか

Agentless Scanning の有効化、重要ホストへの Agent 配備、追加機能 (CI/CD でのコンテナイメージ走査、AWS CloudTrail ログ、クラウド連携経由の資源走査) の有効化、という順で公式の手順は書かれています (2026 年 9 月時点・出典: Setting Up Cloud Security)。運用の型に置き直すなら、1 週目は Agentless だけで Findings と posture score の初期値を取り、2 週目に Agent があるホストで機能を有効化して実行時の文脈つきの優先順位を得て、その後に CI へ走査を入れる順が手戻りを減らします。所見は重要度順に並ぶ Security Inbox に集まり、対応はケースと Workflow Automation で回します。順番を守る理由は 1 つで、Agentless の初期値が無いと Agent を足した効果を測れないからです。