エンタープライズ企業を襲うデータ発見ギャップ──その盲点と解決策
シャドーデータは、主に技術的な問題ではありません。これは、技術的な問題として表面化する組織のチェンジマネジメントの課題です。クラウド移行の際にデータが取り残されることがあります。開発環境がテスト用に本番データのコピーで構築され、そのまま放置されることもあります。プロジェクトのためにクラウドストレージバケットが用意され、プロジェクト終了後には忘れ去られることもあります。SaaSアプリケーションが入れ替えられても、移行時にエクスポートされたファイルは、作成者がすでに異動してしまったため、誰も管理しない共有フォルダに残り続けます。
これらは決して珍しいことではありません。日常的に起こる組織の出来事です。問題は、多くの組織のデータガバナンスプロセスが、こうした事象にリアルタイムで対応できるよう設計されていないことです。定期的な監査や手動のカタログ更新に依存するデータガバナンスフレームワークは、実際の運用に追いついていません。次回の監査で放置されたバケットや古いエクスポートが発見される頃には、データはすでに数か月間放置されていることが多いのです。
DSPMツールは自動検出によって支援しますが、検出だけでは不十分です。シャドーデータを見つけることは、すでに問題が発生している場所を特定するだけであり、次のプロジェクトで同じ問題が別の場所で発生するのを防ぐことはできません。ガバナンスアーキテクチャは両方に対応する必要があります。つまり、データを作成・移動するプロセス自体にポリシーを組み込むことが求められます。事後的にスキャンするプロセスだけでは不十分です。
5つの重要なポイント
1. 定期的な検出スキャンで、消えたと思われていたデータが表面化する。
放置されたクラウドストレージバケット、古い開発環境、レガシーSaaSエクスポートには、組織がすでに廃止したと考えていた機密性の高い顧客データが残っていることがよくあります。SchellmanのCEOであるAvani Desai氏は、これを一貫して目にしています。組織は自社のデータマップがどれだけ完全かを過大評価し、運用の変化がガバナンスをどれだけ速く追い越すかを過小評価しています。クラウド移行、買収、SaaSの廃止、インフラの再編成のたびに、現実を反映しないデータマップが生まれます。
2. M&Aの場面では、買い手が一貫して過小評価する集中したデータリスクが生じる。
買い手が企業を買収すると、その企業がこれまでに作成・収集・保存してきたすべてのデータを引き継ぎます。これには、過去の買収で取得したデータ、何年も誰も触れていないレガシーシステム、保存期間が明確に定められていない顧客データも含まれます。クロージング後の検出スキャンで、売り手も存在を知らなかったデータセットが表面化します。その結果、GDPRや各州のデータプライバシー法、HIPAAに基づく侵害通知義務が発生したり、デューデリジェンス時に想定していなかった統合の遅延が生じたりします。
3. 責任の空白こそがシャドーデータの温床となる。
「運用変更後のデータマップを誰が検証するのか？」多くの組織では、明確な責任者を挙げることができません。責任はIT、法務、コンプライアンス、セキュリティの間に分散しており、いずれも隣接する業務を担っているものの、運用変更後に現状のインフラとデータマップを突き合わせて整合させるという具体的なタスクの担当者はいません。まさにその隙間でシャドーデータが蓄積されていきます。運用変更と次回のガバナンスレビューの間に生まれる空白が問題なのです。
4. アーキテクチャの上に重ねたガバナンスでは追いつけない。
ある時点でのコンプライアンス対応によって正確なデータマップが作成されても、次の移行や買収、システム廃止が発生した瞬間に、そのマップは現実と乖離します。DSPMツールは自動検出で支援しますが、検出だけでは不十分です。シャドーデータを見つけることは、すでに問題が発生している場所を特定するだけであり、次のプロジェクトで同じ問題が別の場所で発生するのを防ぐことはできません。
5. アーキテクチャに組み込まれたガバナンスこそ、事後的なガバナンスでは解決できない課題を解消する。
データ交換のタイミングでポリシーが強制されていれば、すべての取引がすでに記録されています。データマップは運用の副産物であり、別途作成するものではありません。ゼロトラスト・データ保護の原則では、データへのアクセス、移動、共有のすべてのリクエストが検証・承認・記録されることが求められ、その結果として継続的なデータマッピングが構造的な副産物として生まれます。
組織のセキュリティを信じていますか？その証明はできますか？
Read Now
M&Aにおけるデータ問題は、実は侵害通知問題である
合併・買収（M&A）は、データガバナンスの失敗が最も直接的に法的・財務的リスクへと転化する場面です。買い手が企業を買収すると、その企業がこれまでに作成・収集・保存してきたすべてのデータを引き継ぎます。これには、買収先企業が過去に買収した企業のデータ、何年も誰も触れていないインフラ上のレガシーシステム、保存期間が明確に定められていない場所にある顧客データも含まれます。
クロージング後に実施される検出スキャンで、売り手が存在を把握していなかったデータセットが発見され、その中には買い手が法的に所有することになった顧客データが含まれています。そのデータが一度でも無許可の第三者にアクセス可能だった場合—特に誰も監視していない廃止済みシステムでは、その可能性を排除することが困難です—買い手はGDPRや各州のデータプライバシー法、またはその両方に基づく侵害通知義務を負う可能性があります。コストは通知だけにとどまりません。統合の遅延、規制当局からの監視、そして継承した侵害を開示しなければならなくなった場合の取引の評判への影響も含まれます。
データ分類と文書化されたデータフローは、こうしたリスクを軽減するためのクロージング前のデューデリジェンス項目です。完全かつ最新のデータマップを提示できる組織は、そうでない組織に比べてM&Aリスクが大幅に低くなります。完全な監査ログを備えたセキュアな仮想データルームは、両当事者に「何が、どの条件で、誰と共有されたか」の明確な記録を提供し、デューデリジェンス期間中もクロージング後も重要な役割を果たします。
「運用変更後のデータマップ検証の責任者は誰か？」
Desai氏のこの問いは、多くのデータガバナンスフレームワークが見過ごしている運用上の現実を突いています。データマップはカタログ化作業によって作成されます。この作業自体は実施時点では正確です。しかし、その後組織は変化します。新しいクラウド環境が用意されたり、SaaSアプリケーションが廃止されたり、買収が完了したり、チームが再編成されたりします。これらの出来事が発生するたびに、データマップの一部が無効化されても、自動的な更新プロセスが起動することはありません。
多くの組織では、運用変更後のデータマップ検証が明確な担当者の業務になっていません。責任はIT、法務、コンプライアンス、セキュリティの間に分散しており、いずれも隣接する業務を担っているものの、具体的なタスクの担当者はいません。まさにその隙間でシャドーデータが蓄積されていきます。
GDPRのようなデータコンプライアンスフレームワークは、個人データの処理活動について正確な記録を求めていますが、これらの記録をどのように最新に保つかまでは規定していません。最も効果的にコンプライアンスを実現している組織は、データ追跡を運用プロセスに組み込んでおり、定期的なクリーンアップとしてではなく日常業務の一部としています。ガバナンスされたデータ交換の副産物として自動生成される証拠保管の連鎖ドキュメントは、定義上、常に最新であり、整合性を取るための追加作業は不要です。
アーキテクチャに組み込むガバナンス、上乗せではなく組み込み
GDPRは、プライバシー・バイ・デザインが事後的なプライバシー対策よりも優れた結果をもたらすことを示しました。データガバナンスも同じ論理に従います。データ交換アーキテクチャにガバナンスを組み込んでいる組織は、データマップと運用現実の間にギャップが生じません。ギャップ自体が存在しないのです。マップ＝ログとなります。
機密性の高いコンテンツ交換にKiteworksを利用する場合、監査ログは「何が、どこで、いつ、どのポリシーで」移動したかを継続的に記録します。別途データマッピング作業を行う必要はありません。データマップは運用の副産物として自動生成されます。規制当局、監査人、M&Aの相手方からデータ取扱いの証拠を求められた際も、必要なのはレポートであり、再構築プロジェクトではありません。Kiteworksのプライベートデータネットワークは、メール、ファイル共有、MFT、SFTP、Webフォーム、APIを単一のポリシーエンジンと統合監査ログで管理します。
レガシーSaaSエクスポートや廃止済みシステムに潜むシャドーデータ
組織がSaaSアプリケーションを置き換える際、移行プロセスでエクスポートファイルが生成されます。これには、顧客記録、取引履歴、従業員データなどを含む大容量のCSVやデータベースダンプが含まれます。一部は新しいシステムにインポートされますが、一部は移行を担当したチームによって共有ドライブに残され、そのチームが再編成や異動でいなくなった後は、誰も探しに行きません。
これらのファイルこそがシャドーデータです。これらは本番システムと同じ機密情報を含みながら、現行の組織構造に合わせたアクセス制御も保存ポリシーもなく、誰も監視していません。しかも移行から何年も経過している場合、存在自体が忘れ去られ、検出スキャンで発見されるまで、あるいは規制当局からの問い合わせがあるまで誰も気づきません。
証拠保管の連鎖が記録されるセキュアマネージドファイル転送は、この問題を根本から解決します。データ移行やエクスポートがガバナンスされたプラットフォームを通じて行われる場合、移動するすべてのファイルが作成時点からログに記録され、責任の所在が明確になり、定められた保存ポリシーが適用されます。
「運用変更後のデータマップ」に本当に必要なこと
責任の空白を埋めるには、データマップの検証を監査サイクルの一部ではなく、運用プロセスとして扱う必要があります。つまり、データ交換インフラにポリシー強制を組み込み、マップが継続的に更新されるようにし、ガバナンス層外でインフラ変更が発生した場合には、変更後の検証について明確な責任者を定めることが重要です。
データとともに移動するデータ分類情報によって、どのシステムにデータが存在してもマップ上の機密度が一貫して維持されます。ガバナンスされたデータ交換を利用する組織のリスク評価プロセスは、過去のデータマップではなく、現時点のデータフローからスタートします。インシデント対応プロセスが始動した際も、どのデータが関与していたかを迅速に把握でき、数週間かけて再構築する必要はありません。
シャドーデータが蔓延する中でのデータガバナンスについてさらに詳しく知りたい方は、カスタムデモを今すぐご予約ください。
よくあるご質問
シャドーデータとは、ガバナンス管理外に存在する機密情報のことです。放置されたクラウドストレージバケット、忘れられたSaaSエクスポート、レガシーバックアップ、本番データのコピーを含む開発環境などが該当します。シャドーITは、しばしばシャドーデータを生み出す未承認のインフラですが、シャドーデータは承認済みインフラにも蓄積されることがあります。いずれも定期的なスキャンだけではリスクが増大します。DSPMツールや継続的なデータ分類により、シャドーデータが見逃される期間を短縮できます。
買収が完了すると、買い手は買収先企業が保有していたすべてのデータに対して法的責任を引き継ぎます。クロージング後の検出スキャンで、廃止済みまたは十分に保護されていないシステム内に顧客データが見つかり、無許可アクセスの可能性を排除できない場合、GDPRや各州のデータプライバシー法、HIPAAに基づく通知義務が発生する可能性があります。クロージング前に顧客データの所在をマッピングし、アクセス制御を確認し、保存ポリシーを文書化することで、このリスクを低減できます。また、完全な監査ログを備えたガバナンスプラットフォームでデューデリジェンスを実施することも有効です。
これは、データが移動するシステム自体にデータ取扱い管理が組み込まれており、後から別のコンプライアンス層として追加されるのではないことを意味します。すべての転送が記録され、すべての共有イベントに責任の所在が明確になり、すべてのアクセス判断がトランザクションの一部として記録されます。データマップは運用によって継続的に生成されるため、常に最新です。プライバシー・バイ・デザインやゼロトラスト・データ保護の考え方は、こうしたモデルこそが持続的なコンプライアンスを実現すると示しています。運用変更までしか有効でないコンプライアンスとは異なります。
エクスポートファイルは、何がエクスポートされ、どこに保存され、どの保存ポリシーが適用されるかを記録するプロセスで作成すべきです。これを省略すると、数年後の検出スキャンで発見されるシャドーデータが生まれます。すなわち、完全な顧客記録を含むエクスポートファイルが、アクセス制御も保存スケジュールもなく放置されるのです。証拠保管の連鎖が記録されるセキュアマネージドファイル転送を利用すれば、移行記録が完全になり、作成時点から保存ポリシーが適用されます。
Kiteworksは、プラットフォームを通じて行われるすべてのファイル転送、共有イベント、アクセス判断の継続的な監査記録を生成します。そのため、データマップは実際の運用のレポートであり、再構築作業ではありません。運用変更（新しいクラウド環境、システム廃止、買収など）が発生しても、ガバナンスされた交換記録が移行中にどのデータが動いたかを把握します。ゼロトラスト・データ保護の原則により、この継続的なマップはインフラの構造的な特徴となり、別途プログラムや人員を割く必要がありません。
追加リソース
- ブログ記事 国際共同研究における臨床試験データの保護方法
- ブログ記事 CLOUD法と英国データ保護：管轄権が重要な理由
- ブログ記事 ゼロトラスト・データ保護：セキュリティ強化のための実装戦略
- ブログ記事 プライバシー・バイ・デザイン：GDPR管理をMFTプログラムに組み込む方法
- ブログ記事 国境を越えたセキュアなファイル共有でデータ侵害を防ぐ方法