Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
クラウド環境で起きるセキュリティインシデントの多くは、ゼロデイ脆弱性やマルウェアではなく、「ありふれた構成ミス」から始まります。S3バケットの公開設定、IAMロールの過剰権限、セキュリティグループの全開放——いずれもクラウドコンソール上では「正常稼働中」と表示されます。しかし、攻撃者の視点で見れば、侵入や権限拡大につながる格好の入口になり得ます。
本記事は、クラウドアカウントの増加に伴う構成管理の煩雑化に課題を感じているセキュリティ担当者・CISO、および DevSecOps を推進する SRE／プラットフォームエンジニアを主な読者と想定しています。
そのうえで、構成ミスを継続的に検知・是正する CSPM（Cloud Security Posture Management）の役割と限界、KSPM／CWPP／CDR との関係、さらに Sysdig Secure による実装像までを体系的に整理します。
特に「大量のアラートに埋もれて CSPM が形骸化する」「コンプライアンス対応が年1回の儀式になっている」「構成ベースラインが本番環境のドリフトに追いつかない」といった、多くの組織が直面する運用上の難題に対し、Sysdig ならではの現実的な解決アプローチを提示します。
1. CSPMとは何か — 定義と背景
CSPM（Cloud Security Posture Management）とは、クラウド構成を継続的に監査し、設定ミスやコンプライアンス基準からの逸脱を検知・是正するセキュリティカテゴリです。
CSPM は結局「何を見る」カテゴリなのか。そして、なぜ独立した製品カテゴリとして成立してきたのか。まずはその輪郭から確認していきます。
1-1. クラウド「構成管理」というセキュリティカテゴリ
CSPM（Cloud Security Posture Management）は、IaaS／PaaS のクラウドアカウントを対象に、リソースの構成情報、IAM 設定、ネットワーク設定、暗号化設定などを継続的にスキャンし、ベストプラクティスやコンプライアンス基準からの逸脱、すなわちポスチャ違反を検出するセキュリティカテゴリです。
CSPM の主な対象は、ワークロード内部の挙動、たとえばプロセスの起動、通信内容、ファイル変更といったランタイムの振る舞いではありません。あくまで、クラウドプロバイダー上で定義されている「設定面」を可視化・評価することにあります。
CSPM が参照するのは、AWS／Azure／GCP などの API から取得できる構成情報です。たとえば、S3 バケットのパブリックアクセス可否、EC2 に紐づくセキュリティグループ、IAM ポリシーの Allow／Deny、KMS キーのローテーション設定、CloudTrail の有効化状態などが該当します。
これらの構成項目を、CIS Benchmarks などのベンチマークや社内ポリシーに基づく数百〜数千のルールに照らし合わせ、準拠しているか、逸脱しているかを継続的に判定していくのが CSPM の基本的な役割です。
1-2. IaaS／PaaS／SaaSの境界と責任共有モデル
CSPM が成立する前提には、クラウドの責任共有モデルがあります。一般に IaaS／PaaS 領域では、物理インフラやハイパーバイザーなどの「クラウドそのもの」はクラウドプロバイダーの責任範囲に含まれます。一方で、クラウド上に構築するワークロード、アプリケーション、IAM、ネットワーク、暗号化、ログ取得などの設定は、多くの場合、利用者側の責任範囲に属します。
もちろん、すべてが単純に二分されるわけではありません。マネージドサービスのコントロールプレーン、AWS Config／GuardDuty／Security Hub のような基盤ログ・検知機構、マネージド Kubernetes の一部 Control Plane 設定など、プロバイダーが一定の管理責任を担う領域も存在します。しかし、日々のクラウド運用で利用者が作成・変更する構成設定の多くは、依然としてユーザー責任側にあります。
CSPM は、このユーザー責任に属する「構成面」を継続的かつプログラム的に監査する仕組みです。クラウドアカウント内のリソース設定、IAM 権限、ネットワーク公開範囲、暗号化設定、ログ有効化状態などを定期的に評価し、ベストプラクティスやコンプライアンス基準からの逸脱を検出します。
責任共有モデルの詳細は、「クラウドセキュリティとは？責任共有モデルと利用者が担う対策を解説」をご覧ください。本記事では、「構成設定の大半はユーザー責任に属し、CSPM はその領域を継続的に監査するための仕組みである」という前提を押さえたうえで、CSPM の役割と限界を整理していきます。
1-3. CSPMが生まれた背景
2010年代後半、クラウド環境で発生するセキュリティ事故の多くが、外部からの高度な侵入ではなく、自社の設定ミスに起因することが明らかになってきました。Capital One の WAF サーバーへの SSRF 攻撃を起因とする大規模な個人情報漏洩、S3 バケットの公開設定ミス、IAM の過剰権限を悪用した不正アクセスなどは、その代表的な例です。
これらの問題は、従来の境界型セキュリティ、たとえばファイアウォール、IDS、EDRだけでは検知しにくい性質を持っています。なぜなら、攻撃者は必ずしもマルウェアを実行したり、不審な通信を発生させたりするわけではなく、公開されたリソースや過剰に付与された権限を利用し、正規の API 呼び出しとして操作を行うことがあるためです。
こうした背景から、クラウド環境の構成状態そのものを継続的に監査し、ベストプラクティスやコンプライアンス基準からの逸脱を検出する仕組みとして CSPM が注目されるようになりました。Gartner が CSPM をセキュリティカテゴリとして定義したのは 2018〜2019 年頃とされ、その後 CSPM は、CNAPP（Cloud-Native Application Protection Platform）を構成する主要要素の一つとして位置付けられるようになりました。
現在では、CSPM 単体で構成ミスを検出するだけでなく、CWPP（Cloud Workload Protection Platform）、CIEM（Cloud Infrastructure Entitlement Management）、CDR（Cloud Detection and Response）などと連携し、クラウドネイティブ環境全体のリスクを統合的に管理する流れが強まっています。CSPM から CNAPP へと発展する潮流については、「CNAPPとは何か？」で詳しく解説しています。
2. なぜ今 CSPM が必要か — クラウド構成ミスのインシデント実例
では、CSPM が対処すべき典型的な構成ミスとは、具体的にどのようなものなのでしょうか。ここでは、クラウド環境で頻発しやすい構成起因によるインシデントを例に見ていきます。
2-1. S3バケットの公開設定／IAMの過剰権限／セキュリティグループ全開放
代表的な構成起因のインシデントは、主に次の 3 パターンに整理できます。
1. オブジェクトストレージの公開設定ミス
S3／GCS／Blob Storage などのバケットが「Public Read」のまま放置され、本来は社内限定で管理すべき顧客データやログが、インターネット経由で取得可能になるケースです。過去には、大手企業の顧客情報や業務データが、認証なしの GET リクエストで取得可能だった事例も複数報告されています。
2. IAM の過剰権限
開発時に付与した Administrator ロールをそのまま本番運用に流用、*:* の Allow ポリシーを残したり、退職者や退役済みサービスに紐づくアクセスキーを放置したりするケースです。このような状態では、1 つのアクセスキーが漏洩しただけで、広範なリソースの操作や権限昇格につながるおそれがあります。
3.セキュリティグループ／ファイアウォール全開放
踏み台 EC2 や検証用 RDS で 0.0.0.0/0 に対する SSH や 3306 ポートの開放を一時的に許可し、そのまま忘れられているケースです。こうした設定は、インターネット側からのスキャンや SSH ブルートフォース攻撃の標的になりやすく、初期侵入の入口になり得ます。
これらに加えて、コンテナレジストリ（ECR／GCR）のパブリック設定、Secrets Manager などを利用せず認証情報を平文で管理している構成、KMS で暗号化されていない EBS／RDS ボリュームなども、CSPM が検出すべき代表的な構成リスクに含まれます。
2-2. マルチクラウド時代の「構成のスケール問題」
管理対象のリソースが 100 個程度であれば、月次のスポット監査でも構成ミスをある程度把握できます。しかし、実際のエンタープライズ環境では、AWS／Azure／GCP の複数クラウド、複数アカウント、数万規模のリソースを横断的に管理するケースが増えています。
このような環境では、手作業による点検はリソース数の増加に比例して運用負荷が増大し、見落としのリスクも急速に高まります。特に、クラウドリソースは開発・検証・本番環境で日々作成・変更・削除されるため、ある時点で問題がなかったとしても、その状態が継続するとは限りません。
さらに、IaC（Infrastructure as Code、Terraform／CloudFormation など）と手動オペレーションが混在する現場では、「IaC 上は正しく定義されているが、本番環境では意図しない設定変更、すなわちドリフトが発生している」という状態が起こり得ます。
CSPM が継続的にスキャンを行う最大の意義は、この「規模」と「ドリフト」の問題を機械的に把握できる点にあります。人手では追いきれないクラウド構成の変化を継続的に監視し、ベースラインからの逸脱を早期に検出することで、構成ミスがインシデントにつながる前に是正しやすくなります。
2-3. コンプライアンスの自動化要求
CSPM が求められるもう一つの背景に、コンプライアンス対応の自動化要求があります。PCI DSS／HIPAA／SOC 2／ISMAP／FISC など、業界・地域別のコンプライアンス要件の多くは、クラウド構成のチェック項目に落とし込むことができます。
たとえば、保存データの暗号化に関する要件は、AWS であれば EBS／S3／RDS の暗号化設定として検査できます。また、CIS AWS Foundations Benchmark の各項目は、IAM、ネットワーク、ログ、暗号化などの構成ルールとして CSPM に実装しやすい代表例です。
監査対応における CSPM の価値は、「年 1 回の監査時点で証跡を集める」だけでなく、「日次で継続的にコンプライアンス状態を確認し、その証跡を自動的に蓄積できる」点にあります。これにより、監査人にとっては確認作業がしやすくなり、運用側にとっても証跡収集や是正状況の説明にかかる負荷を大きく削減できます。
3. CSPM の主要機能
CSPM 製品が共通して備える主要機能を、機能カテゴリごとに整理します。CSPM は単に構成ミスを一覧化するだけでなく、クラウド API から取得した構成情報を正規化し、コンプライアンス基準や社内ポリシーと照合したうえで、リスクの優先度付けや是正アクションにつなげる役割を担います。
以下では、それぞれの機能カテゴリについて、設計上のポイントを順に見ていきます。
3-1. 構成スキャン（インベントリ収集とドリフト検知）
CSPM の出発点は、対象クラウドアカウント内のリソースを継続的に列挙し、正規化されたインベントリとして保持することにあります。クラウド API 経由で EC2、S3、IAM、VPC、KMS、RDS、Lambda などの構成情報を取得し、クラウドやアカウントをまたいで比較・検索できる状態に整えます。
スキャンは一定間隔で繰り返され、前回のスナップショットとの差分を確認することで、「いつ、誰が、何を変更したのか」という構成変更を可視化できます。これにより、単発の監査では見落とされやすい設定変更や、本番環境で発生したドリフトを継続的に検知できます。
特に、IaC で宣言したベースラインと実際の本番環境を比較できるようになると、Terraform 上では private と定義されているバケットが、手動操作によって public-read に変更されたようなケースを早期に把握できます。CSPM は、IaC と実環境の差分を検出することで、「コード上は安全だが、本番環境は安全ではない」という状態を可視化する役割を担います。
3-2. コンプライアンスチェック
CSPM のコンプライアンス機能は、大きく「ベンチマーク」と「業界・地域別規格」の 2 層で提供されることが一般的です。前者には CIS Benchmarks や NIST など、後者には PCI DSS、HIPAA、SOC 2、ISMAP などが含まれます。
各規格の管理要件は、CSPM 内部のルールセットに変換されます。たとえば、ログ取得の有効化、保存データの暗号化、公開範囲の制限、IAM 権限の最小化といった要件が、具体的なクラウド構成のチェック項目として評価されます。各ルールでは、合否、該当リソース、影響度、修正手順がレポート化されるため、監査対応や是正計画に活用しやすくなります。
日本市場では、業界・業態ごとに異なる規格対応が求められます。政府系では ISMAP、金融系では FISC 安全対策基準、自動車・製造業では JAMA／JAPIA サイバーセキュリティガイドライン、医療系では 3 省 2 ガイドライン、重要インフラ系では各業界の所管ガイドラインなどが代表例です。
これらの国内要件は、CIS Benchmarks、PCI DSS、SOC 2、NIST、ISO 27017 などの国際的な基準と重複する部分も多くあります。そのため、セキュリティ設計の段階で、どの規格のどの管理策を、どの CSPM ルールで確認するのかをクロスマッピングしておくことが重要です。これにより、監査時の照合作業を効率化し、後工程での認証取得や継続監査を進めやすくなります。
なお、こうした国内外の多様なコンプライアンス要件を手動ではなく自動で継続監査する具体的な仕組みについては、後述の「Sysdig Secure の CSPM 機能」で扱います。
3-3. IAM 分析と過剰権限の可視化
IAM は、CSPM の中でも特に難易度の高い領域です。単一ポリシーの記述ミスだけでなく、複数ポリシーを組み合わせた結果、ロール継承の連鎖、サービスごとのアクション粒度、リソースベースポリシーとの相互作用まで踏まえて評価する必要があるためです。
代表的なチェック項目としては、*:* を含む過剰な Allow ポリシー、本番運用ロールへの AdministratorAccess 付与、90 日以上未使用のアクセスキー、MFA 未設定のルートアカウント、サービスアカウントに対する過剰な iam:PassRole 権限などが挙げられます。
IAM 分析で重要なのは、単に「強すぎる権限がある」と指摘するだけではありません。その権限が実際にどのリソースへ到達できるのか、外部公開されたリソースや脆弱なワークロードと組み合わさった場合にどのようなリスクになるのかを評価することです。
この領域は CIEM（Cloud Infrastructure Entitlement Management）とも重なります。CIEM は、クラウド権限の可視化、過剰権限の削減、最小権限化を担うカテゴリです。近年の CNAPP 製品では、CSPM と CIEM が統合され、構成リスクと権限リスクをあわせて評価できるようになっています。
3-4. ネットワーク・暗号化の構成検証
ネットワーク層では、外部公開範囲や通信経路の安全性を検査します。代表的なチェック対象には、0.0.0.0/0 に対する SSH／RDP／データベースポートの開放、ALB／NLB の TLS バージョンやサイファースイート、API Gateway の認証設定、VPC Flow Logs の有効化、PrivateLink 経由ではなくインターネット越しに公開されている内部 API などがあります。
暗号化層では、保存データと通信経路の両面を確認します。EBS、S3、RDS、DynamoDB、EFS などの保存データ暗号化、通信路の TLS バージョン、KMS キーのローテーション設定、カスタマー管理キーとクラウドプロバイダー管理キーの使い分けなどが主なチェック対象です。
これらの検証は、単なる設定確認にとどまりません。たとえば、外部公開されているデータベース、暗号化されていないストレージ、ログが無効化されたアカウントが組み合わさると、単独では中程度に見える構成不備が、重大なインシデントリスクに発展する可能性があります。CSPM では、こうした構成要素の組み合わせを把握し、優先的に是正すべきリスクを見極めることが重要です。
3-5. 自動修復（Auto Remediation）と手動承認のバランス
CSPM の自動修復は強力な機能ですが、本番運用では「全自動」と「全手動」の中間設計が現実的です。検出されたすべてのリスクを即座に自動修復すると、業務影響を引き起こす可能性があります。一方で、すべてを手動対応にすると、アラートが蓄積し、CSPM が形骸化しやすくなります。
そのため、検出ルールごとに修復モードを切り替える設計が重要です。たとえば、明らかに不要な公開 S3 バケットの非公開化は自動、セキュリティグループルールの削除は手動承認、IAM ポリシーの変更はチケット駆動といった形です。リスクの深刻度、業務影響、リソース所有者、変更履歴を踏まえて、どこまでを機械に任せ、どこから人が承認するのかを定義します。
特に注意すべきなのは、修復アクションそのものがサービス停止につながる可能性です。たとえば、静的サイトホスティング用に意図して公開しているバケットを誤って非公開化すれば、ユーザー向けサービスに影響が出ます。あるいは、業務上必要な通信を許可しているセキュリティグループルールを削除すれば、アプリケーション間通信が遮断される可能性があります。
したがって、自動修復は単なる機能ではなく、運用設計の問題として捉える必要があります。所有者、SLA、承認フロー、例外管理、ロールバック手順を含めて設計することで、CSPM を安全かつ継続的に活用できます。これらの詳細は、後述の「CSPM の導入・運用設計」で扱います。
4. CSPM が扱うスコープと限界 — 「構成は見えるがランタイムは見えない」
ここは、本記事における重要な差別化ポイントです。CSPM がカバーできる範囲と、そこから先に必要になる Run 段階の検知、すなわち CWPP／CDR との役割分担を明確にしていきます。
4-1. 構成検査だけでは検知できない攻撃
CSPM は強力なセキュリティカテゴリですが、基本的に可視化できるのは「構成状態」までです。クラウドリソースの設定、IAM 権限、ネットワーク公開範囲、暗号化設定などは評価できますが、その設定を悪用した実際の挙動までは把握できません。
たとえば、次のような攻撃や異常は、構成スキャンだけでは検知が困難です。
1. 正規権限内での悪用
漏洩したアクセスキーを使って s3:GetObject が実行された場合、IAM ポリシー上その操作が許可されていれば、CSPM はそれを構成違反として検出できません。CloudTrail 上でも正規の API 呼び出しとして記録されるため、アクセス元、頻度、対象データ、過去の行動との差分などを見なければ、不正アクセスとして判断しにくいケースがあります。
2. ワークロード内部の不正挙動
コンテナ内でクリプトマイナーが起動した、想定外のシェルが生成された、/etc/passwd が読み取られたといった事象は、構成ミスではなくランタイムイベントです。これらは、クラウド設定のスキャンではなく、ワークロード内部のプロセス、システムコール、ファイルアクセス、ネットワーク通信を監視することで検知する必要があります。
3. ライブラリ脆弱性の悪用
脆弱性が CVE として既知であっても、それが実際に攻撃に使われているか、該当するライブラリが実行中のプロセスでロードされているかは、構成情報だけでは判断できません。単に「脆弱なパッケージが存在する」ことと、「その脆弱性が実環境で悪用可能、または悪用中である」ことの間には大きな隔たりがあります。
4. データ持ち出しの実態
CSPM は、「そのデータにアクセスできる状態か」を示すことはできます。しかし、「誰が、いつ、どのデータに、どの程度アクセスしたのか」「通常とは異なる量のデータが外部に送信されたのか」までは、構成情報だけでは判断できません。実際のデータアクセスや外部送信を把握するには、ログ分析やランタイム検知が必要になります。
これらは、Run 段階の検知、すなわち CWPP（Cloud Workload Protection Platform）や CDR（Cloud Detection and Response）が担う領域です。システムコールや eBPF を用いたランタイム検知の仕組みについては、「コンテナランタイムセキュリティとは？Falco によるリアルタイム検知の仕組み」で詳しく解説しています。Run 段階の設計については、そちらも参照してください。
4-2. CSPM 単体運用のアンチパターン
CSPM はクラウド構成リスクを可視化するうえで不可欠ですが、CSPM だけでクラウドセキュリティ全体を担おうとすると、いくつかのアンチパターンに陥りやすくなります。
1. アラート疲れ
CSPM の検出ルールは、ベンチマークや規格を含めると数百から数千に及ぶことがあります。優先度付けをせずに検出結果をすべてチケット化すると、開発・運用チームが対応しきれず、重要なリスクが埋もれてしまいます。その結果、CSPM は「大量の未対応アラートを出すだけのツール」となり、運用上の価値が低下します。
2. 「設定上は安全」の罠
CSPM 上ですべてのチェックが合格していても、それは「構成上の逸脱が見つかっていない」ことを意味するに過ぎません。実際に侵害が起きていないこと、正規権限が悪用されていないこと、ワークロード内部で不正挙動が発生していないことまでは証明できません。ランタイム検知がなければ、攻撃の成立を被害発生後にしか把握できない可能性があります。
3. コンプライアンス報告だけの存在になる
CSPM が監査資料の生成ツールとしてだけ使われ、日々のセキュリティ運用に組み込まれない状態も典型的なアンチパターンです。年 1 回の監査対応では活用されても、検出されたリスクが開発・運用チームの是正プロセスやインシデント対応に接続されていなければ、実質的なリスク低減にはつながりません。
CSPM は、Plan／Design 段階でクラウド構成のベースラインを整え、継続的に逸脱を検出するための入口として重要です。しかし、それ単体でクラウドセキュリティ全体を担うことはできません。構成リスクを把握する CSPM、ワークロード内部を監視する CWPP、実際の攻撃挙動を検知・対応する CDR を組み合わせ、Plan・Build・Run・Respond を貫く設計として捉える必要があります。
この全体像については、「クラウドセキュリティ完全ガイド｜構成ミスからランタイム脅威まで『Code to Runtime』で守るには」を参照してください。
5. KSPM（Kubernetes Security Posture Management）との関係
CSPM と並列で語られることが多いカテゴリに、KSPM（Kubernetes Security Posture Management）があります。両者はいずれも「構成状態」を評価するポスチャ管理の仕組みですが、対象とするレイヤが異なります。ここでは、CSPM と KSPM の違いと、実運用でどのように統合すべきかを整理します。
5-1. K8s マニフェスト・RBAC・NetworkPolicy の構成検査
KSPM は、Kubernetes クラスタの構成面に特化したポスチャ管理カテゴリです。CSPM がクラウドプロバイダー側の設定を評価するのに対し、KSPM は Kubernetes API を通じて、クラスタ内部のマニフェスト、権限、ネットワーク制御、ワークロード設定を検査します。
EKS／AKS／GKE などのマネージド Kubernetes 環境では、「外側」のクラウド設定と、「内側」の Kubernetes 設定が連動して攻撃経路を形成します。たとえば、kube-apiserver の公開範囲、IRSA／Workload Identity、ノードや Pod に付与された権限、Egress 制御、Secrets の扱い、暗号化キー連携などは、クラウドレイヤと Kubernetes レイヤの両方にまたがる論点です。
そのため、CSPM が「クラウドの外殻」を見て、KSPM が「クラスタの内側」を見るという二段構造で捉える必要があります。片側だけを監査していても、クラウド設定と Kubernetes 設定が組み合わさった攻撃経路や、実際に優先して是正すべきリスクを正しく把握できない可能性があります。
5-2. CSPM と KSPM はどう統合すべきか
実運用では、CSPM と KSPM を別々の製品や運用フローで管理すると、アラートの重複、抜け漏れ、優先度ロジックの不整合が起こりやすくなります。
たとえば、「EKS クラスタの Public Endpoint が有効になっている」という CSPM の検出と、「特定の Pod が hostNetwork: true で動作している」という KSPM の検出は、本来、一連の攻撃経路として評価すべきものです。しかし、別々のツールで管理していると、それぞれが独立したアラートとして扱われ、リスクの全体像が見えにくくなります。
CNAPP の文脈では、CSPM と KSPM は同一プラットフォーム上で統合し、さらに CWPP、CIEM、CDR と相関させることが重要です。これにより、単独の構成ミスではなく、「外部から到達可能か」「過剰権限があるか」「実行中のワークロードにリスクがあるか」「実際の不審挙動が発生しているか」といった観点を組み合わせ、攻撃経路ベースで優先度を判断できます。
初期設計の段階で、CSPM と KSPM を別管理にしない方針を決めておくことは、後の運用負荷を大きく左右します。クラウドレイヤと Kubernetes レイヤを分断せず、共通のリスクモデルと優先度付けのもとで管理することで、アラート対応、是正計画、監査対応を一貫したプロセスとして運用しやすくなります。
6. CSPM と CNAPP の関係 — 入口であり、入口で終わらせない
CSPM は、CNAPP 全体の中でどの位置にあるのでしょうか。ここでは、CSPM を計画・設計フェーズの入口として位置付けたうえで、CNAPP 全体との関係を整理します。
CNAPP の価値は、CSPM、CWPP、CIEM、CDR などの機能を単に並べることではありません。重要なのは、Plan 段階で定義した構成ベースラインを Run 段階で継続的に検証し、さらに Run 段階で得られた知見を Plan 段階の優先度付けや構成改善へ還流できる点にあります。
この「Plan ↔ Run の往復」という観点は、以降の各論、特に後述する「Sysdig Secure の CSPM 機能」を理解するうえで重要な軸になります。
6-1. CNAPP の構成要素としての CSPM／CWPP／CIEM／CDR
CNAPP は単一の機能ではなく、Code／Build／Plan／Run／Respond を横断的に支える複合的なセキュリティカテゴリです。主な構成要素は次のとおりです。
なお、表中の「主な担当段階」は、各カテゴリを示すものであり、フェーズを排他的に区切るものではありません。CSPM／KSPM は主に Plan 段階で構成ベースラインを定義・評価する役割を担いますが、実際には Run 段階でも継続スキャン、ドリフト検知、継続的コンプライアンス監査を実行します。
つまり、CNAPP における CSPM／KSPM は、計画・設計フェーズだけの機能ではなく、Plan から Run までをつなぐ基盤機能として位置付けられます。
CNAPP プラットフォーム全体については「CNAPP とは何か？」、CWPP については「CWPP とは？クラウドワークロードを守る最新セキュリティ基盤」、CDR については「CDRとは、クラウドを守るリアルタイム防御とSysdigのアプローチ 」、CTEM（Continuous Threat Exposure Management、継続的脅威露出管理）については「CTEMとは何か、攻撃者視点でクラウドの弱点を可視化する新しいセキュリティ戦略」で詳しく解説しています。
6-2. Plan → Build → Run → Respond の各段階で CSPM が果たす役割
CSPM の役割は、計画・設計フェーズに重心があります。しかし、他の段階と接続することで、その効果は大きく高まります。
たとえば、Plan 段階で「S3 バケットは原則非公開」「RDS は暗号化必須」「管理者権限は例外承認制」といったベースラインを定義します。Build 段階では、そのルールを IaC スキャンに展開し、デプロイ前に同じ基準でチェックします。Run 段階では、本番環境のドリフトを検知し、さらにランタイムで観測された攻撃兆候や実行中ワークロードの情報をもとに、どの構成リスクを優先的に修正すべきかを判断します。
シフトレフトの詳細については、「シフトレフト（Shift Left）とは？コンテナセキュリティを CI/CD に組み込む実践ガイド」で扱っています。
6-3. CSPM だけ・CWPP だけ・CDR だけの「点導入」が抱える限界
実務でよく見られるのが、「CSPM だけを先に導入した」「ランタイム検知ツールだけを入れた」「ログ SIEM だけを運用している」といった導入のパターンです。
これらが運用上の成果につながりにくい理由は、概ね共通しています。
- 構成情報と実行情報が紐づかず、優先度判定の根拠が弱くなる
- 同一資産に対して複数ツールから別々のアラートやチケットが発行され、対応工数が重複する
- 共通の脆弱性・露出・攻撃経路ビューが存在せず、経営報告でも個別ツールのスコアを並べるだけになってしまう
CSPM は CNAPP の入口として重要です。しかし、入口だけで止まってしまうと、構成リスクの一覧化にとどまり、実際の攻撃可能性やランタイムの状況を踏まえた優先度付けまではできません。
そのため、初期設計の段階で「CSPM を入口にしつつ、Build／Run／Respond まで接続する」方針を決めておくことが重要です。これは、CSPM をコンプライアンスチェックツールで終わらせないための、最も重要な設計判断の一つです。
7. CSPM の導入・運用設計
CSPM を「ツール導入」で終わらせないためには、導入そのものを運用設計として組み立てる必要があります。ここでは、初期導入から継続運用までの基本的な進め方を整理します。
7-1. 導入の 3 ステップ（スキャン → 優先度付け → 修正フロー設計）
CSPM 導入は、次の 3 ステップで進めると整理しやすくなります。
初回スキャンでは、数百件から数千件単位の検出が出ることも珍しくありません。重要なのは、検出件数そのものではなく、「どれから直すべきか」を判断できる状態にすることです。
たとえば、「インターネットから到達可能で、機密データを含み、過剰権限を持つロールからアクセスできるリソース」は、単なる暗号化漏れやタグ不備よりも優先度が高くなります。CSPM 導入時には、このようなトリアージ基準をあらかじめ定義しておくことが重要です。
7-2. 開発チームへのフィードバック（IaC のシフトレフト連携）
CSPM の検出を本番環境だけで修正しても、同じミスが IaC テンプレートに残っていれば再発します。したがって、CSPM の検出結果は、本番環境の是正だけでなく、IaC や CI/CD の改善にも還流させる必要があります。
たとえば、CSPM で「S3 バケットが公開されている」「RDS が暗号化されていない」「セキュリティグループが 0.0.0.0/0 に開放されている」と検出された場合、その原因が Terraform や CloudFormation のテンプレートにあるなら、同じルールを IaC スキャンにも展開します。
Terraform であれば tfsec や Checkov、Kubernetes マニフェストや Helm Chart であれば kube-linter や kubesec などの OSS と CSPM のルールセットを揃えることで、Plan と Code の境界で同じ判定基準を適用できます。
これにより、本番環境で検出された構成ミスを、次回以降は Pull Request の段階でブロックまたは警告できるようになります。CSPM は、本番環境の監査ツールであると同時に、開発プロセスへフィードバックを返す仕組みとして設計することが重要です。
シフトレフトの設計指針と CI/CD への組み込み方については、「シフトレフト（Shift Left）とは？コンテナセキュリティを CI/CD に組み込む実践ガイド」で詳しく解説しています。
7-3. 役割分担と SLA
CSPM 検出の修正責任は、原則としてリソースのオーナーチームが持つべきです。つまり、開発チーム、プラットフォームチーム、データチームなど、該当リソースを作成・運用しているチームが一次対応の主体になります。
一方、セキュリティチームの役割は、すべての修正作業を肩代わりすることではありません。ルールセットの定義、リスク優先度の判定、例外承認、横断レポート、運用状況の可視化を担うことが主な役割です。
SLA は、重大度や露出度に応じて段階的に設計します。たとえば、インターネット公開され、機密データを含むリソースの構成不備は短い期限で対応し、内部ネットワーク内に限定された低リスクの設定不備は、より長い期限で対応するといった設計です。
重要なのは、すべての検出を同じ期限で扱わないことです。公開範囲、データ機密度、到達可能性、権限範囲、ランタイムでの利用状況を踏まえて、現実的に運用可能な SLA を設計します。
Critical 件のランタイム連動 SLA や RACI の具体設計については、「DevSecOps とコンテナセキュリティ」で個別に扱っています。運用設計を具体化する段階では、そちらも併せて参照してください。
8. Sysdig Secure の CSPM 機能
最後に、ここまで整理してきた観点が、Sysdig Secure の CSPM 機能ではどのように実装されているかを概観します。
8-1. 構成スキャン・コンプライアンス自動化・Risk Spotlight
まず前提として、以下で述べる実行中ワークロードやランタイムリスクを含む統合ビューは、CSPM 単体が構成情報の先まで直接見ているという意味ではありません。CNAPP として CWPP／CIEM／CDR と統合されることで、構成リスクとランタイムリスクが同一の文脈で扱えるようになる、という位置付けです。
Sysdig Secure の CNAPP プラットフォームでは、CSPM 機能を通じて主要クラウド環境や Kubernetes 環境を統一的に可視化します。AWS／Azure／GCP／OCI などのクラウドアカウントに加え、EKS／AKS／GKE／OpenShift／オンプレミス Kubernetes などの環境を対象に、構成リスクやコンプライアンス状態を継続的に評価できます。
また、CIS Benchmarks、PCI DSS、HIPAA、SOC 2、ISMAP、NIST 800-53 などのコンプライアンスパックを活用することで、各種規格への準拠状況を継続的に確認できます。検出されたリスクは、単なるルール違反として並べるのではなく、リソースの公開度、データ機密度、脆弱性の有無、権限範囲などの文脈を踏まえて優先度付けされます。
特徴的なのが、Risk Spotlight に代表されるリスク集約ビューです。CSPM が検出した構成リスクと、CWPP／CDR が捉えるランタイムリスクを、同一アセット単位で関連付けて確認できます。
これにより、たとえば「外部公開されているリソース」「そのリソースへ到達可能な IAM ロール」「そのロールを利用している実行中ワークロード」「該当ワークロードで観測された不審な挙動」といった複数領域の情報を、個別アラートではなく一連のリスクとして評価しやすくなります。
8-2. アラート疲れを解消する — Run の知見を CSPM に還流する Sysdig の設計思想
Sysdig のアプローチで重要なのは、CSPM で検出した構成リスクを、Run 段階の情報で重み付けする点です。
たとえば、IAM ポリシー上は広範な権限が付与されていても、その権限が実際には使われていない場合、緊急度は相対的に下がる可能性があります。一方で、構成上は妥当に見えるロールであっても、ランタイムで普段とは異なる API 呼び出しや不審な挙動が観測されれば、優先度は高くなります。
このように、構成情報だけではなく、実行中ワークロード、実際に使われているパッケージ、プロセス、通信、クラウド API の利用状況などを組み合わせることで、「理論上危険なもの」ではなく、「実際に悪用される可能性が高いもの」から対応しやすくなります。
Sysdig のランタイム可視化・検知の中核には、Falco をベースにした eBPF／Syscall レベルの観測があります。これにより、コンテナやクラウドワークロードで発生している実際の挙動を捉え、CSPM の構成リスクと組み合わせて優先度を判断できます。
実運用では、CSPM の初回スキャンで多数の Critical や High が検出されることがあります。しかし、そのすべてを同じ優先度で対応しようとすると、セキュリティチームも開発チームも疲弊します。Sysdig Secure では、実行中かどうか、外部から到達可能か、機密データや過剰権限と結びついているか、実際の不審挙動があるかといった観点を組み合わせることで、優先対応すべきリスクを絞り込みやすくなります。
これにより、「Critical が大量に並んでいるが、誰も対応しきれない」という典型的なアラート疲れの状態から、実際の攻撃可能性や業務影響に基づいたトリアージへ移行できます。
具体的な削減率やお客様事例、Runtime Insights の詳細については、「コンテナランタイムセキュリティとは？Falco によるリアルタイム検知の仕組み」で詳しく説明しています。CISO や経営層向けに ROI を説明したい場合は、そちらも併せて参照してください。
CSPM 単独では実現しにくい「Plan ↔ Run の往復」を、CNAPP プラットフォーム上で閉じること。これが、Sysdig Secure における CSPM 活用の重要な設計思想です。
9. まとめ — CSPM を入口に、Run まで貫く設計へ
CSPM は、クラウド構成のミスを継続的に検知するための、計画・設計フェーズの入口となるセキュリティカテゴリです。S3 バケットの公開設定、IAM の過剰権限、セキュリティグループの全開放、暗号化漏れといった典型的な構成リスクを、CIS Benchmarks や各種コンプライアンス規格と突き合わせて自動評価します。
また、日次レベルで監査証跡を生成できる点は、コンプライアンス対応の省力化という意味でも大きな価値があります。年 1 回の監査対応に追われるのではなく、日々の運用の中で継続的に準拠状況を確認できるようになるためです。
一方で、CSPM は構成状態を可視化する仕組みであり、ランタイムの異常挙動、正規権限の悪用、攻撃の成立可否までは単体では判断できません。これらは CWPP や CDR が担う領域です。CSPM だけで運用すると、「設定上は安全」という錯覚を生み、実際の攻撃や侵害の兆候を見逃す可能性があります。
そのため、セキュリティ設計では、CSPM／KSPM を CNAPP の構成要素として位置付け、Build／Run／Respond と接続することが前提になります。構成リスクを把握するだけでなく、IaC へのフィードバック、ランタイム情報による優先度付け、インシデント対応時のコンテキスト活用までを一連の流れとして設計することが重要です。
導入においては、ツール選定よりも先に、「優先度付けの基準」「所有者と SLA」「IaC へのシフトレフト連携」を決めることが、CSPM の形骸化を防ぐ最大のポイントになります。
初期設計の段階で定義した構成ベースラインを、Run 段階の知見で継続的に更新し続ける。この往復こそが、CSPM を単なるコンプライアンスレポートツールに矮小化させず、クラウドセキュリティの実効的な仕組みとして機能させる鍵になります。
次のステップ
Risk Spotlight によるアラート削減効果や、Plan から Run までをつなぐ Sysdig Secure のアプローチを、ぜひデモでご確認ください。