DSPMが存在するのは、機密データがもはや一か所に留まっていないからです。
データベース以外にも、機密データはログ、キュー、SaaSツール、サポートシステム、分析パイプライン、データウェアハウス、バックアップ、そして現在ではAIのプロンプトやベクトルストアにも存在します。アプリケーションがデータを移動させるため、データも移動するのです。 顧客のメールアドレスは、登録フォームで入力され、APIを経由してPostgresに書き込まれ、アプリケーションログに記録され、Snowflakeにコピーされ、サポートツールに流れ込み、Stripeに送信され、その後、AIワークフローに取り込まれることもあるかもしれません。そして、これはごく一般的なワークフローと見なされています。
つまり、DSPM（データ・セキュリティ・ポスチャー・マネジメント）について語られる際、その基本的な考え方は非常に明快です。チームが、機密データがどこにあるか、どのようなデータか、誰が、あるいは何がアクセスできるか、どのように保護されているか、そしてどこで漏洩のリスクがあるかを把握できるよう支援することです。
多くの企業では、機密データがどこに存在しているかについて、完全な把握ができていません。顧客データ、決済情報、トークン、従業員データ、そして最近ではあらゆる種類のAIコンテキストを保有していることは認識しています。しかし、それらのデータが最終的にどこに保存されているのか、誰がアクセスできるのか、あるいは自社のセキュリティやコンプライアンスの要件に沿った方法で取り扱われているのかについては、必ずしも把握できていないのが実情です。
可視性こそが、従来のDSPMが解決しようとしている問題である。
従来のDSPMは、データが到着した地点から始まります
従来のDSPMでは、多くの場合、データ資産の把握から始まります。これは通常、ストレージシステムや接続されたプラットフォームのスキャンを意味します。S3バケット、データベース、データウェアハウス、SaaSアプリ、そしてバックアップなどが対象となります。
このツールは、機密データを検出し、分類し、アクセス権限や情報漏洩のリスクを確認することで、セキュリティチームが重要な課題に優先的に取り組めるよう支援します。例えば、S3バケットに個人識別情報（PII）が含まれていること、データウェアハウスのテーブルに支払い関連のデータがあること、ファイル共有へのアクセス範囲が広すぎることを指摘したり、バックアップに本番環境の顧客レコードが含まれているにもかかわらず、その場所が1年間誰も確認していない状態にあることを指摘したりすることがあります。
これは明らかに有用です。現代の環境では、多くの機密データが至る所に存在しており、その多くはコピー、複製、エクスポート、ログ記録、同期、アーカイブされた後、忘れ去られてしまいます。従来のDSPMは、チームがそうしたデータを見つけ出すのを支援します。これにより、セキュリティチームは、単に周囲のクラウドリソースにとどまらず、実際のデータ資産全体をより明確に把握できるようになります。
しかし、開発者やアプリセキュリティチームにとっては、それは往々にして物語の後半に過ぎない。
前半では、そのデータがどのようにしてそこにたどり着いたのかについて説明します。
欠けているのはコードパスです
従来のDSPMツールであれば、「このログストアからPIIが検出されました」と表示されるでしょう。
しかし、開発者は依然として、なぜその個人情報が存在するのか、アプリケーションのどの部分がそれを書き込んだのか、意図的なものだったのか、そして実際にどのような変更を加えれば修正できるのかを突き止めなければなりません。そのためには、コードを確認する必要があります。
このアプリケーションはデータを収集・処理し、APIどのフィールドを返すかを決定しました。その後、リクエスト本文をログに記録し、トークンをワーカーに渡して、顧客のメタデータをベンダーに送信し、機密性の高いコンテキストを含むプロンプトを作成しました。
したがって、開発者視点の質問は、「機密データはどこに保存されているか？」というレベルにとどまらず、「どのコードパスが情報漏洩の原因となったのか？」といった内容であるべきです。これこそが、DSPMの「シフト・レフト」版なのです。
コードベースのDSPMは、ストレージ層ではなくアプリケーションから分析を開始します。API、ORMモデル、ロギング呼び出し、キューのコンシューマー、CI/CD 、AIとの統合などを調査します。その目的は、機密データがどのようにシステムに入り、どのように移動し、どこに保存され、どこから流出するか、そしてどこで不適切な取り扱いが行われる可能性があるかを把握することにあります。
コードベースのDSPMおよびデータ漏洩監査
『 Aikidoにおいて、コードベースのDSPMを最も明確に説明する方法は、「データ露出監査」と呼ぶことだと思います。これは、AIを活用してコード内の機密データの流れやセキュリティリスクを特定するものです。
データ漏洩監査はこれとは異なります。コードを精査し、機密データがこのアプリケーション内でどのように流通しているか、またその流通のどの段階でリスクが生じているかを分析します。対象範囲には、PII、PHI、PCI、シークレット、トークン、顧客コンテンツ、およびAI関連のデータ処理が含まれます。各結果には証拠が添付されており、データストアに直接接続することなく、コードレベルでの是正措置が提示されます。
コードを読み解くことで、データ保護の脆弱性を見つけることもできます。例えば、暗号化されずに保存されている機密フィールド、ソースコードにハードコードされた鍵、暗号化であるかのように使用されているMD5やSHA1、base64、リポジトリにコミットされた秘密情報、および安全でない通信経路を介して送信される機密データなどを検出できます。
このことを別の角度から捉えることもできます。従来のDSPMでは、実際のデータにアクセスし、S3バケット、データベース、データウェアハウスに接続して、その中身をスキャンする必要があります。一方、コードベースのDSPMは、そのデータを作成・移動させるコードを読み取るため、アクセスを要求したり、何かをダウンロードしたりすることは一切ありません。コードから読み取る方式であれば、本番環境への新たなアクセス権を付与する必要がないため、導入のハードルが低くなります。
また、クロールする対象がないため、処理も高速になります。さらに、9桁の数字であれば何でも社会保障番号であると仮定するのではなく、フィールドが実際にどのように使用されているかを読み取るため、精度も高くなります。その結果、アーキテクチャ内の機密データの所在と保護状況を示すマップが生成されますが、これはすべてコードから構築されたものです。
『 Aikidoでは、これはAIコード分析の一環として実施されるため、データ露出監査は、独立したデータアクセス統合としてではなく、他のコードレビューと並行して行われます。
調査結果の質にどのような違いがあるのか
簡単な例として、ロギングを挙げてみましょう。
従来のDSPM製品であれば、アプリケーションログにPIIが含まれていることを最終的に通知してくれるかもしれません。これもまた有用です。しかし、その場合は誰かがその発生源を探し出さなければなりません。
コードベースのデータ露出監査では、データ、コードパス、送信先、露出リスク、および修正策を関連付けることで、より包括的な全体像を把握することができます。これにより、開発者にとってより有用なものとなります。
例えば、決済の承認に失敗した場合、チェックアウトコントローラーは「billingDetails」オブジェクトの全情報をログに記録します。このオブジェクトには、メールアドレス、電話番号、請求先住所、およびカード番号の下4桁が含まれています。これらのログはDatadogに送信されます。修正策としては、ログ記録の前にこれらのフィールドをマスキングし、顧客ID、決済インテントID、およびエラーコードのみを残すようにします。
これは、従来のDSPMから得られる情報とは大きく異なります。
これはシークレット トークンシークレット 同様です。たとえば、GitHub、GitLab、Bitbucketからコードを読み取るために使用されるSCMトークンを考えてみましょう。ストレージ重視の観点からは、そのトークンがデータベース内で暗号化されているかどうかが問われるかもしれません。しかし、それだけでは全体像を捉えきれていません。
トークンはプラットフォームのどこで取り込まれるのでしょうか？OAuthトークン、GitHubアプリトークン、それともユーザーが送信したPATでしょうか？どのようなスコープを持っていますか？どのように検証されますか？どこで暗号化されますか？どこに保存されますか？いつ復号化されますか？キャッシュされますか？クローンURLに埋め込まれますか？ワーカーに渡されますか？ログ、トレース、エラー、プロセス引数、あるいはテレメトリを通じて漏洩する可能性はありますか？ これはデータセキュリティの問題ですが、その動きについて知るべきことはコードが教えてくれます。
ダッシュボードから修正まで
ここでこそ、コードベースのDSPMが面白くなってくると思います。
この機能の理想的な形は、「機密データがあります」と表示するだけの、ありきたりなダッシュボードではありません。それは誰もが知っていることです。より優れた体験とは、機密データのインベントリ、データの流れ、漏洩リスク、関連する管理措置、そしてリスクを低減するためのコード変更案を、すべて提示してくれるものです。
その不具合がコードによって引き起こされたのであれば、修正は恐らくそのコード内で行うべきでしょう。
したがって、一般的な開発者のワークフローは以下のようになるはずです：
- ログに記録する前に、機密性の高いフィールドを伏せてください。
- より小さなAPI オブジェクトを返す。
- テナントの所有権確認機能を追加する。
- URLにトークンを含めるのはやめてください。
- ステージング環境に復元する前に、マスクのデータをマスカリングしてください。
- 保存前に暗号化を行ってください。
- LLMのプロンプトから顧客データを削除する。
- 削除ロジックを修正し、下流のレコードが実際に削除されるようにする。
そのエンジニアは、どの具体的なコードパスが特定のデータ漏洩リスクを引き起こしているのか、そしてそれをどのように修正すればよいのかを知りたいと考えています。
これにより、セキュリティおよびコンプライアンスのフレームワークとの関連性もより具体的になります。トークンの取り扱いに不備があった場合、認証情報の管理、伝送時の保護、最小権限の原則、監査ログの保護といった面で問題となる可能性があります。 PIIがマスキングされずにログに記録された場合、プライバシー、保存期間、データ最小化、および監視管理に影響を及ぼす可能性があります。顧客データがマスキングされずにステージング環境にコピーされた場合、アクセス制御、環境の分離、およびコンプライアンス上の義務に影響を及ぼす可能性があります。削除要求後もレコードが残存したり、保存期間を超えてデータが保持されたりした場合、それはGDPRやCCPAの義務に直接関連するため、削除および保存ロジックそのものを修正する必要があります。
単に「安全でないロギングパターン」とだけ記された発見事項は、その有用性がかなり限定的です。しかし、「このコードパスを経由して顧客の個人識別情報（PII）がログに流れ込むことで、データ漏洩のリスクが生じ、これらの統制に影響を及ぼしており、ログ記録前にこれらのフィールドをマスキングすることで修正可能である」といった内容であれば、具体的な対応策として活用できます。
そうすれば、エンジニアリング、アプリケーションセキュリティ、コンプライアンスを同じ議論の場に持ち込む上で、はるかに良い方法になります。
簡略版
従来のDSPMは依然として重要です。これにより、チームは実環境内で機密データがどこに存在しているかを把握することができます。また、見落とされていたバケット、外部にさらされているデータベース、シャドウデータ、権限が過剰に付与されたストレージなどを特定することも可能です。
しかし、コードベースのDSPMは、これまで欠けていたアプリケーション層を補完します。これにより、機密データがどのようにその場所に到達するのか、どのように移動するのか、漏洩のメカニズムがどこにあるのか、そして開発者がそれに対してどのような対策を講じることができるのかが明らかになります。
つまり、簡略版は次のようになります：
従来のDSPMは、機密データが保存されている場所を特定します。
コードベースのDSPMは、機密データがどのように漏洩するかを特定します。
データ漏洩監査では、その流れをコード、管理上の不備、および修正策へと結びつけます。
これがDSPMの「シフトレフト」版です。開発者やアプリケーションセキュリティ（AppSec）チームにとって、おそらくこのバージョンこそが、チームにとって最も役立つものとなるでしょう。
Aikido コードベースのDSPMにおいて、業界初の ソリューションを提供します。 データベースに接続することなく、データを保護し 、追跡することができます。
