DSPMベンダーの評価方法：企業購買担当者の選定フレームワーク

データセキュリティ態勢管理ソリューションの選定は、セキュリティチームが今年下す調達決定の中でも、特に重要なものの一つです。適切な選択ができれば、機密データがどこに存在し、誰がアクセスでき、実際にどの程度リスクにさらされているかについて、継続的に可視化できるようになります。 しかし、選択を誤れば、誰も対応しないアラートばかりを生成する高価なダッシュボードを購入することになってしまいます。課題は、この分野のベンダーはいずれもデモでは見栄えがよいという点にあります。精巧に作り込まれた分類エンジンが厳選されたテスト環境をスキャンし、洗練されたリスクヒートマップが表示され、スライドには連携機能が一覧で示されます。しかし、ベンダーのデモで見る内容と本番環境で実際に体験することとの間にギャップがあり、そこがDSPM導入の多くが失敗に終わる原因となっています。

本ガイドは、DSPMプラットフォームを評価するための、体系化されたベンダー中立のフレームワークを提供します。本ガイドは、フォレスターやガートナーといったアナリスト企業が「Wave」やMagic Quadrant 用いている評価軸――発見、分類、リスク分析、是正措置、統合の深度、運用成熟度――を基に構成されていますが、これらの評価軸を、貴社のチームが候補の絞り込みや概念実証（PoC）テストの際に適用できる実用的な採点手法へと変換しています。 クラウド・セキュリティ・アライアンス（CSA）のDSPMガイダンスでは、効果的な評価には機能チェックリストにとどまらず、実際のデータ環境、アクセスパターン、コンプライアンス要件に対してソリューションがどのように機能するかを評価する必要があることがさらに強調されています。

ビジネスケースを作成するCISOであれ、規制上の証拠要件を整理するDPOであれ、APIのカバー範囲に対するストレステストを行うクラウドセキュリティエンジニアであれ、あるいは総所有コスト（TCO）を算出する調達責任者であれ、以下に示すフレームワークは、単一かつ統一された評価プロセスの中で、各ステークホルダーに明確な役割を割り当てます。

概念実証（PoC）の現実検証

ベンダーによるデモは、その性質上、最適化された環境で行われます。テストデータはクリーンで、権限構造は単純であり、分類モデルは、デモで提示される特定のシナリオに対して最適なパフォーマンスを発揮するよう調整されています。効果的な概念実証（PoC）評価を行うには、必要に応じて実際の運用データやエンタープライズ規模のSaaS環境を取り入れるべきです。なぜなら、簡略化されたテストデータセットでは、複雑なMicrosoft 365やマルチクラウド環境の展開において生じる運用、可視性、ガバナンス上の課題が明らかになることはめったにないからです。

M365の問題

ほぼすべての企業におけるDSPM評価で、次のようなシナリオが繰り返されています。ベンダーによるデモでは、数百件のドキュメントと単純なアクセス権限設定を持つテスト用のSharePointサイトがスキャンされます。分類精度は非常に優れており、PII検出の精度は95％以上、リスクスコアリングも正確で、誤検知も最小限に抑えられています。そして、これを実際のMicrosoft 365環境に接続してみると――。

ベンダーが説明しなかったのは、スキャナーが以下の状況に遭遇した際に何が起こるかということです。すなわち、チャネル階層間で継承されたネストされたTeamsのアクセス権限、複雑な共有リンク（リンクを知っている全員、特定のユーザー、組織全体）を持つSharePointサイト、グループメンバーシップの3階層下に埋もれたゲストユーザーのアクセス許可、Teamsチャットを通じて共有されたOneDriveファイル（これにより、SharePoint管理画面では確認できない共有権限が生成される）、そして事業部門間で一貫性なく適用された機密ラベルなどです。 こうした実環境では、分類精度が大幅に低下することが多く、スキャナーが権限の継承チェーンを解決できず、すべてを「過度に公開されている」としてフラグを立てるデフォルト動作をとるため、誤検知が急増します。その結果、リスクダッシュボードはノイズが多くなり、数週間も経たないうちにセキュリティチームがそれを無視し始めるほどになります。

実際のPOCで何をテストすべきか

DSPMプラットフォームに実際に負荷をかけるシナリオを中心に、概念実証（PoC）を構築してください。ベンダーを、テストテナントではなく、代表的な本番環境のM365環境に接続してください。共有設定が実際に複雑になっているテナントセグメントを選択してください。例えば、外部パートナーと密接に連携している部門、ネストされた非公開チャンネルがあるTeams環境、長年にわたってアドホックな共有権限が蓄積されているSharePointサイトなどです。

分類結果を真値と比較します。POCの実施前に、感度レベルごとに200～500件の文書をサンプルとして手動でタグ付けしてください。DSPMによるスキャン終了後、その分類結果を真値と比較してください。 精度（フラグが立てられた項目のうち、実際に機密情報であるものの割合）と再現率（実際に機密情報である項目のうち、検出されたものの割合）を算出します。調整済みのPOCにおいて、実際のデータで85％以上の精度と80％以上の再現率を達成できないベンダーは、本番環境ではより低いパフォーマンスしか発揮できません。

権限解決の深さをテストします。既知の複雑な権限チェーンを含むテストシナリオを作成します。具体的には、Teamsの会議チャット経由で共有されたドキュメント、ゲストユーザーを含むネストされたセキュリティグループを通じて継承されたSharePointファイル、M365グループと共有されたOneDriveフォルダーなどです。DSPMが、単に名目上の権限を持つユーザーだけでなく、実際にアクセス権を持つユーザーを正確に特定できることを確認します。

偽陽性のトリアージワークフローを評価する。トリアージと却下のワークフローが効率的であれば、偽陽性率が高くても対応可能である。一方、トリアージのインターフェースが使いづらい状態で偽陽性率が中程度である場合は、状況はさらに悪化する。アナリストが検知結果をレビューし、検証し、却下またはエスカレーションするまでに要する時間を計測する。その時間を、予測される1日あたりのアラート件数で乗算する。

是正措置の往復テストを実行します。POCスキャンから、実際に過剰露出が確認された5件の検出結果を選びます。DSPMのワークフローを通じて、共有リンクの無効化、権限の調整、機密ラベルの適用といった是正措置を試みます。その是正措置がM365で実際に反映されているか、また次のスキャンサイクルにおいてDSPMが更新されたセキュリティ状態を反映しているかを測定します。

実際のデータ規模でテストを行ってください。組織が M365 と AWS S3 に合計 50 TB のデータを保有している場合、500 GB をスキャンするだけの PoC では、パフォーマンス、スキャン所要時間、あるいは増分スキャンの効率性について何ら証明にはなりません。本番データのボリュームの少なくとも 20% を反映した PoC の範囲を設定するよう働きかけてください。

ベンダーに尋ねるべき質問

ありきたりなRFPチェックリストでは、ありきたりな回答しか得られません。以下の質問は、ベンダーのマーケティング資料からは明らかにならない、具体的な能力の不足や業務上の実情を明らかにするために考案されたものです。

分類精度について：「ユーザー数が10,000人を超えるM365環境における非構造化データについて、測定された偽陽性率はどの程度ですか？ 同規模の導入事例を持つ顧客を紹介し、チューニング後の精度指標を共有してもらうことは可能ですか？」制御された環境での精度数値のみを提示したり、精度に関する議論のために導入事例の顧客との連絡を拒否したりするベンダーは、その点で課題を抱えていることを示唆しています。

権限の解決について：「スキャナーが、B2Bゲストユーザーを含むネストされたAzure ADセキュリティグループから実効アクセス権が派生するSharePointファイルを検出した場合、実効権限はどのように解決されますか？具体的なAPI呼び出しと権限継承のロジックについて、順を追って説明してください。」これは、ベンダーのアクセスマッピングが真にIDを意識したものなのか、それともグループのネストを解決せずに名目上の権限データに依存しているのかを検証するものです。

分類のカスタマイズについて：「当社には、標準的なPII/PHI/PCI分類器ではカバーされていない、業界特有の機密データタイプがあります。カスタム分類器を作成するにはどのような手順を踏めばよいのでしょうか？ 必要なトレーニングサンプル数はどれくらいか、一般的なチューニングサイクルはどの程度か、また、カスタムタイプと組み込みタイプを比較した場合、どの程度の精度が期待できるのでしょうか？」この点こそが、真に学習可能な分類エンジンを備えたベンダーと、機械学習と称して正規表現（regex）ベースのカスタムルールを提供しているベンダーとを区別する基準となります。

リスクモデルの透明性について：「リスクスコアはどのように算出されていますか？スコアを算出する際にどのような変数が用いられ、それらはどのように重み付けされており、その重み付けを調整することは可能ですか？2つのファイルに同一の個人識別情報（PII）が含まれている場合、一方にアクセスできるユーザーが5人、もう一方が5,000人である場合、御社のリスクモデルはこれらをどのように区別するのですか？」説明も調整もできない不透明なリスクスコアリングは、CISOの精査や監査人の質問に耐えられないでしょう。

統合の仕組みについて：「御社のプラットフォームがSIEMに送信する実際のイベントペイロードを見せてください。どのようなフィールドが含まれていますか？構造化されたCEF/LEEFイベント、JSONウェブフック、それともsyslogダンプですか？転送されるイベントをフィルタリングすることは可能ですか？」SOCの機能を強化するSIEM統合と、利用価値のないイベントでSOCを溢れさせるSIEM統合との違いは、ペイロードの構造とフィルタリングの粒度にかかっています。

是正措置の限界について：「御社のプラットフォームは、どの是正措置をネイティブに実行できますか？　単に推奨するのではなく、実際に実行できるという意味で。具体的にはM365において、共有リンクの取り消し、サイトのアクセス権限の変更、機密ラベルの適用、およびファイルの隔離は可能ですか？」多くのDSPMプラットフォームは是正措置を機能として掲げていますが、実際には、担当者が別のコンソールで手動で実行するよう推奨するにとどまっています。

運用上のオーバーヘッドについて：「初期導入後、当社と同規模の一般的な顧客は、分類の微調整、誤検知の選別、ポリシーの調整、および統合のメンテナンスに、週あたり何FTE時間を費やしているのでしょうか？ これらの微調整のサポートは含まれているのでしょうか、それとも追加費用がかかるプロフェッショナルサービスとなるのでしょうか？」DSPMの総所有コスト（TCO）は、ライセンス料ではなく、運用コストが大部分を占めています。

ステークホルダーの要件の整合

DSPMの評価は、あるステークホルダーの優先事項を最適化するあまり、他のステークホルダーの利益を犠牲にしてしまうと失敗に終わります。評価委員会の各メンバーはそれぞれ異なる視点を持っており、採点基準はそれらすべてを反映したものでなければなりません。

CISO：リスク報告と取締役会への情報伝達

CISOには、単なる技術的な調査結果だけでなく、データセキュリティ態勢が時間の経過とともに改善しているか、あるいは悪化しているかを示す傾向データを含む、経営陣向けのリスクレポートを作成できるDSPMが必要です。 そのプラットフォームが、データの露出指標をビジネスリスクの用語に置き換えた、取締役会に提出可能な要約を生成できるかどうかを評価してください。また、リスクスコアリングを事業部門、データタイプ、または規制領域ごとにセグメント化できるかどうかも確認し、CISOが取締役会が重視する観点に基づいてセキュリティ態勢を報告できるようにしてください。優れた技術的調査結果を生み出すものの、それらを戦略的なリスクストーリーとして集約できないDSPMは、CISOのユースケースを満たすことはできません。

DPO：コンプライアンスの証拠と監査への備え

データ保護責任者（DPO）は、DSPMをコンプライアンスの証拠管理ツールとして活用する必要があります。GDPR、CCPA、HIPAA、PCI DSS、および貴組織が対象となる業界固有の規制に対応した、組み込みのポリシーフレームワークを評価してください。 プラットフォームが、データ分析結果を特定の規制要件に紐付けた、監査対応可能なレポートを生成できるかどうかを検証してください。単なるコンプライアンスダッシュボードではなく、監査人が「発見事項」から「管理措置」、そして「是正措置」へと追跡できる、エクスポート可能な証拠資料である必要があります。また、DPOにはデータ主体からの情報開示請求への対応機能も必要です。DSPMは、スキャン対象のすべてのリポジトリにわたって、特定の個人のデータが保存されているすべての箇所を特定できるでしょうか？

クラウドセキュリティエンジニア：APIのカバー範囲と自動化

クラウドセキュリティエンジニアは、DSPMが既存の「インフラストラクチャ・アズ・コード」およびセキュリティ自動化のワークフローに適合するかどうかを評価します。そのためには、包括的なAPI対応が不可欠です。単に検出結果を取得するためのREST APIだけでなく、スキャンをトリガーしたり、ポリシーを更新したり、プログラムによって是正措置を実行したりする機能も必要です。 Webhookのサポート状況、TerraformやPulumiプロバイダーの利用可能性、CI/CDパイプラインとの統合性を評価します。また、エンジニアはスキャン性能にも注目します。増分スキャンにかかる時間、APIのレート制限、データ量が増加してもスキャンアーキテクチャが水平方向にスケールするかどうかといった点です。

調達：総所有コスト

調達部門は、ライセンス料以外のTCOもモデル化する必要があります。DSPMの価格モデルは、データストア単位、スキャンしたTB単位、ユーザー単位、検出結果単位、定額プラットフォーム料金、あるいはハイブリッドモデルなど、多岐にわたります。 ベンダーに対し、想定される導入規模に基づく詳細な価格内訳を求めましょう。これには、超過利用料、追加コネクタ料金、導入およびチューニングのためのプロフェッショナルサービス、ならびに更新時の価格改定条件を含める必要があります。内部の運用コスト（管理、チューニング、トリアージにかかるFTE時間）を含めた3年間のTCOを算定してください。ライセンス費用は30％安いものの、FTEへの投資が2倍必要となるDSPMは、決して安価な選択肢とは言えません。

購入者がよく犯す間違い

「ディスカバリー・ブレッド」の幅の広さだけを頼りに購入する

最もよくある評価上の誤りは、ベンダーを主に「スキャン可能なデータストアの数」だけでランク付けしてしまうことです。 検出範囲の広さは最低限の要件に過ぎません。ほぼすべてのエンタープライズ向けDSPMベンダーが、主要なIaaSプロバイダー、M365、Google Workspace、および一般的なデータベースプラットフォームをカバーしています。ベンダー間の差別化要因となるのは、分類の深度、リスクの文脈化、および是正措置の能力です。検出範囲を40％以上も重視する評価を行うと、コネクタのリストが最も長いベンダーが選ばれてしまいますが、それは最高のセキュリティ成果をもたらすベンダーとは限りません。

実データを用いたPOCの省略

合成データやクリーンなテストテナントに対して概念実証（POC）を行っても、デモを見るのと大して変わらない。実際のデータには、分類が曖昧なものや、機密情報と非機密情報の境界線上にある曖昧なコンテンツ、そして長年にわたって自然に蓄積された複雑な権限構造などが存在する。ベンダーもこのことを承知しており、そのため評価段階での本番環境への接続を控えるよう勧めるベンダーもいる。本番環境でのPOCを強く求めるべきだ。実際のデータに対して十分なパフォーマンスを発揮できないベンダーは、導入後も期待通りの成果を上げられないだろう。

運用上のオーバーヘッドを無視する

DSPMの導入において、ライセンス費用は最も目立つ数字ですが、運用コスト（チューニング、トリアージ、ポリシー管理、統合保守にかかるFTE時間）は、通常、3年間でライセンス費用の2～3倍になります。運用上の負担を明確に評価してください。具体的には、許容できる分類精度に達するためにどれだけのチューニングが必要か、チームが1日に処理しなければならない誤検知の件数はどれくらいか、そしてプラットフォームの管理にはどの程度の専門知識が必要か、といった点を検討してください。

DSPMをスタンドアロンとして扱う

DSPMは単独で機能するものではありません。その価値は、より広範なセキュリティアーキテクチャとどれだけうまく統合されるかによって、高まることもあれば低下することもあります。クラウド・セキュリティ・アライアンス（CSA）は、効果的なDSPMの導入には、CSPM、SSPM、UEBA、リアルタイムのアクティビティ監視といった支援機能を提供するSSEプラットフォームが有効であると強調しています。 既存のスタックの文脈で、すべてのDSPMベンダーを評価してください。そのソリューションは、既存のDLPを補完するものか、それとも重複するものか？ 検出結果をCASBにフィードバックして強制措置を講じることができるか？ SIEMにコンテキストデータを付加して機能を強化するのか、それとも単にアラートの量を増やすだけなのか？

AIデータガバナンスの軽視

組織が生成AIツール、コパイロット、RAGパイプラインを導入するにつれ、データガバナンスの要件は従来のコンプライアンスの範疇を超えて拡大しています。PII/PHI/PCIの分類体系に基づいてのみデータを分類するDSPMでは、AIのトレーニングセット、微調整パイプライン、および検索強化生成（RAG）ストアに流入するデータを特定・管理するという、新たに台頭している要件を見逃してしまう可能性があります。 DSPMがAIサービスへの機密データの露出を検出できるかどうか、またその分類体系がAI特有のガバナンス要件を網羅できるほど拡張性があるかどうかを評価してください。

評価プロセスの構築

厳格な評価プロセスにより、スコープの拡大やベンダー主導による方向性の逸脱を防ぐことができる。

第1～2週：要件定義。評価委員会（CISOまたはその代理、DPO、クラウドセキュリティエンジニア、調達担当者）を編成します。「必須」機能と「望ましい」機能を定義します。組織の優先順位に合わせて、重み付け評価表をカスタマイズします。POC環境とグラウンドトゥルースデータセットを構築します。

第3～4週：RFP（提案依頼書）と一次選考。本ガイドに記載されているベンダーへの質問項目を用いて、対象を絞ったRFPを発行します。書面による回答を、重み付けされた評価基準に基づいて採点します。デモを行うベンダーを3～4社に絞り込みます。

第5～6週：体系化されたデモ。ベンダーが希望するデモスクリプトではなく、標準化されたシナリオリストに基づいてデモを実施する。すべてのベンダーに対し、M365の権限解決、カスタム分類器の作成、是正措置の実行、およびSIEMとの統合という、同一のユースケースについてデモを行うことを義務付ける。

第7～10週：概念実証（POC）。最終選考に残った2社のベンダーに対し、本番環境でのPOCを同時に実施する。測定データ（分類精度、誤検知率、スキャン性能、是正措置の往復時間）を用いて、加重基準に基づいてPOCのパフォーマンスを評価する。

第11～12週：最終採点、交渉、決定。すべての評価者による総合スコアを算出する。明確な推奨事項を添えて、採点マトリックスをエグゼクティブ・スポンサーに提示する。選定されたベンダーと契約条件を交渉し、POCのパフォーマンスデータをSLA交渉の材料として活用する。