10110010011101001011001101101110101018200.devFrom Enterprise.Systems

DSPMとは?データセキュリティポスチャー管理をわかりやすく解説

The 8200.dev Team読了 6 分

Data Security Posture Management — DSPM — は、その定義が確立するよりも先に世に広まってしまった頭字語の一つです。本記事では、DSPMが実際に何を意味するのか、なぜ登場したのか、混同されがちな近縁の頭字語とどう違うのか、そして自組織にDSPMが必要かどうかをどう見極めるかを解説します。

一文での定義

DSPMとは、機密データがどこに存在し、誰が(あるいは何が)それにアクセスできるか、そしてそのアクセスが適切かどうかを継続的に把握し、ギャップがあれば洗い出して是正できるようにする実践です。

重視されているのはデータポスチャー(状態)です。ネットワークでも、エンドポイントでも、境界でもなく、データそのものと、それがどう露出しているかという定常的な状態が焦点になります。

DSPMが登場した理由

セキュリティの歴史の大半において、モデルは境界防御でした。企業ネットワークの周囲に境界線を引き、その境界を防御し、内側にあるものは信頼する、という考え方です。データは自社が所有するサーバー上、自社が管理するデータセンター内に存在していました。

そのモデルは崩れました。今やデータはSaaSアプリケーションやクラウドプラットフォーム——Google Workspace、Microsoft 365、Salesforce、オブジェクトストレージ、データウェアハウス——に存在し、従業員、契約社員、パートナー、そして近年ではAIエージェントによって、あらゆる場所からアクセスされます。守るべき単一の境界は存在しません。データはあらゆる場所に存在し、アクセス権は個々のユーザーによる無数の小さな判断によって付与されているからです。

この世界では、重要な問いが変化しました。

  • 機密データは、これらすべてのシステムの中の*どこ*にあるのか?
  • 外部関係者や非人間アイデンティティを含め、*誰が*そのそれぞれにアクセスできるのか?
  • そのアクセスは*適切*なのか、それとも過剰共有・公開状態・失効すべき状態になっていないか?
  • その状況が変化したことを、どうやって*知る*のか?

DSPMは、これらの問いに対して、年に一度の監査ではなく継続的に答えるために構築された規律です。

DSPMとCSPM、DLP、CIEMとの違い

頭字語の乱立は現実の問題です。近縁の概念との関係を整理します。

  • CSPM(Cloud Security Posture Management)は、クラウド*インフラ*の設定ミス——開放されたストレージバケット、許可範囲の広すぎるセキュリティグループ、暗号化されていないボリューム——に焦点を当てます。「クラウドは安全に構成されているか?」を問うものです。一方DSPMは「データはどこにあろうと露出していないか?」を問います。両者はストレージ層で重なりますが、目指すものは異なります。
  • DLP(Data Loss Prevention)は、機密データが外部に流出するのを*阻止*しようとします——クレジットカード番号を含むメールをブロックする、ファイルのアップロードを防ぐ、といった具合です。DLPは、データが出ていく瞬間、つまり移動中のデータに関するものです。DSPMは定常的なポスチャーに関するものです。つまり、何かが移動する前に、そもそもそのファイルが過剰に共有されていたことを教えてくれます。
  • CIEM(Cloud Infrastructure Entitlement Management)は、クラウドプラットフォームにおけるアイデンティティとその権限——誰が何をできるか——に焦点を当てます。DSPMも権限情報を利用しますが、中心に置くのは*データ*です。アクセスを重要なリソースに紐づけて、露出の度合いを判断します。

有用な考え方としては、CSPMはクラウドを守り、DLPは出口を守り、CIEMは権限のもつれを解きほぐし、DSPMはそもそもデータそのものが露出しないように守る、というものです。

DSPMのアプローチが実際に行うこと

ベンダーの売り込みを取り除くと、DSPMのワークフローには4つの動作があります。

  1. 発見(Discover)。 データが存在するシステムに接続し、リソース、アイデンティティ、そしてそれらを結ぶ権限を洗い出します。棚卸しをしていないものは保護できません。
  2. 分類(Classify)。 どのデータが機密か——個人データ、財務記録、機密情報、規制対象コンテンツなど——を把握し、実際に何が懸かっているかに応じて露出の優先順位を付けられるようにします。
  3. 露出の評価(Assess exposure)。 リソース、アイデンティティ、権限を組み合わせてリスクを見つけます——公開リンク、外部共有、過剰な権限、失効すべき許可、設定ミスなどです。
  4. 優先順位付けと是正(Prioritize and remediate)。 機密度×アクセス範囲×アクセスレベルという実際のリスクに基づいて所見の優先順位を付け、解決へと導き、変更があるたびに再チェックします。

「継続的」という部分こそが、ポスチャー*管理*を、ある時点でのスキャンと区別するものです。ポスチャーは、人々が共有し、権限を付与し、それを忘れることで、絶えず変化していきます。スナップショットは撮影された瞬間から古くなっています。

DSPMは必要か?

おそらく既にこの問題は存在しています。問われているのは、それを管理できているかどうかです。意図的なDSPMアプローチが必要であることを示すいくつかの兆候を挙げます。

  • データの大部分が、自社が管理するインフラではなく、SaaSやクラウドプラットフォーム上に存在している。
  • 共有がセルフサービス化されている——どのユーザーもアクセス権を付与できる——ため、アクセスの棚卸しが不完全である。
  • コンプライアンス上の義務(SOC 2、ISO 27001、GDPR、HIPAA)があり、誰がデータにアクセスできるかを管理していることを証明する必要がある。
  • 「この機密データフォルダを誰が見られるか?」という問いに、手作業の調査なしには現在答えられない。
  • 自動化されたエージェントやサービスアカウントがデータへのアクセス権を持っているが、誰もそれを管理していない。

これらのいくつかに心当たりがあるなら、見ているかどうかにかかわらず、露出は既に存在しています。DSPMとは、単にそれを継続的に監視し、見つけたことに対して行動する、という決断に他なりません。

Google Workspaceにおける実践的なDSPM

DSPMは理論上はプラットフォームに依存しませんが、実際にはシステムごとに提供されます。Google Workspaceを利用している組織にとってそれは、Driveのリソースとその共有状況を継続的に発見し、それらにアクセスできるアイデンティティ——人間、外部、サービス、AI——をマッピングし、公開リンク、外部共有、過剰な権限、危険なOAuthアプリ、管理設定ミスといった露出を可視化することを意味します。これはまさに、ポスチャーという観点から捉えたGoogle Workspaceのセキュリティの問題です。

実践において優れたDSPMとはどのようなものか

DSPMを抽象的に説明するのは容易ですが、優れた実装を見分けるのは難しいものです。真に有用なポスチャー管理と、ノイズの多いスキャナーとを分けるいくつかの特質があります。

  • 徹底的に優先順位を付ける。 1万件の所見を返すツールは、問題を移動させただけにすぎません。優れたDSPMは、機密度×アクセス範囲×アクセスレベルという実際のリスクに基づいてランク付けを行い、重要な少数を上位に浮かび上がらせ、残りは順番を待たせます。
  • 自ら説明する。 「Q3-financials.xlsxに公開リンクが設定されており、3月4日に共有設定が『リンクを知っている全員』に変更されたため、URLを知っている全員がアクセス可能」という情報は行動につながります。所見コードだけではそうはいきません。説明可能性があるからこそ、専門家でない担当者もエスカレーションなしに行動できます。
  • デフォルトで読み取り専用である。 発見のためにデータへの書き込みアクセスが必要であってはなりません。最も軽量なツールは、変更する能力を持たずに棚卸しと評価を行い、それによってセキュリティツール自体がリスクになることを防ぎます。
  • ループを閉じる。 露出を発見することは仕事の半分にすぎません。それを解決まで追跡し、修正状態が維持されていることを確認するのが残り半分です。測定されるだけで是正されないポスチャーは、より詳細な心配事にすぎません。

よくある誤解

チームの動きを鈍らせるいくつかの誤解があります。

  • 「DLPを導入しているから大丈夫」。 DLPは出口を守るものであり、そもそもそのファイルが社内外で過剰に共有されていたことは教えてくれません。両者は代替関係ではなく補完関係にあります。
  • 「クラウドプロバイダーがデータを守ってくれている」。 プロバイダーはインフラを保護し、各種の制御機能を提供しますが、共有やアクセスを*どう設定するか*——ひいては自社の露出——は、責任共有モデルの下で自組織の責任です。
  • 「昨年監査を実施した」。 ポスチャーは到達すべき状態ではなく、維持し続けるべき状態です。昨年の監査は、もはや存在しない世界を記述したものにすぎません。

こうした誤解を乗り越えた瞬間、多くのチームは、露出がずっと以前から存在していたこと——ただそれを継続的に見ていなかっただけだということ——に気づきます。

8200.devは、Google Workspace専用に構築されたDSPMです。読み取り専用の発見、各所見が*なぜ*リスクなのかについての平易な言葉での説明、そしてポスチャーが現実を反映し続けるための継続的な再チェックを提供します。詳しくは仕組みについてをご覧ください。

現在のデータポスチャーがどうなっているか気になりますか? 無料セキュリティ監査を開始すると、Google Workspace内の最も機密性の高いデータに誰が(何が)アクセスできるかを示す、優先順位付けされたマップを入手できます。

共有X / TwitterLinkedIn

関連記事