ダークデータ（dark data）の解説：見えないデータがセキュリティ問題になる理由

ほとんどのセキュリティプログラムは、既知のデータ（known data）を中心に設計されています。つまり、インベントリ化(inventoried)され、分類(classified)され、アクティブな統制(active controls)の範囲（perimeter）内にあるデータです。多くの組織では、既知のデータは全体の中では少数派です。

もう半分は、管理されず分類されておらず、しばしば完全に忘れ去られています。そここそが、侵害のフォレンジック（breach forensics）や監査（audit findings）の指摘がますます多く向けられている場所です。

Splunk の『State of Dark Data』によると 調査では、企業データの平均 55% が“ダークデータ”です。組織はそれを保存しているものの、所在を特定したり、分類したり、アクセスを統制（ガバナンス）したりできません。

この割合は業界全体の平均です。レガシーなインフラがある環境、SaaS の導入が多い環境、あるいはガバナンスへの投資が限られている環境では、その割合は大幅に高くなります。

実務上の含意は明確です。組織が投資しているあらゆるセキュリティ対策（DLP、SIEM、 access governance、暗号化）は、それが把握しているデータに対してのみ保護を提供します。

ダークデータとは？

ダークデータとは、組織が収集して保存したものの、忘れ去ってしまったデータのことです。そのため、データが積極的に管理・分類・監視されることがなくなり、所在、機密性、アクセス権限が事実上不明のままとなります。

ここにはもちろん 機密性の高いデータが含まれます。たとえば、PII、PHI、支払いカード情報、そして管理対象のシステム外に流出してしまった認証情報（クレデンシャル）です。さらに、運用によって生成されるデータ（ログ、テレメトリ、エクスポート、バックアップ）の中には、誰も記録されていたとは気づいていなかった識別子が含まれていることがあります。

どちらのカテゴリも、永続的な規制対象データの保管場所として設計されたわけではありませんが、実際のセキュリティおよびコンプライアンス上のリスク（エクスポージャー）を生み出します。

ダークデータは、同じ会話の中でしばしば登場するデータスプロール（data sprawl）などの隣接する概念とは異なります。データスプロールとは、システム全体にわたってデータが無制御に生成・増殖していくことです。組織はコピーの存在は把握しているものの、それらをガバナンス（統制・管理）できていない状態を指します。

それぞれには異なる是正（リメディエーション）の道筋があります。これらを混同すると、誤った問題を対象にしたガバナンス施策につながってしまいます。

ダークデータの種類

ダークデータは、組織が通常の運用の中でデータを生成・蓄積する方法を反映して、異なる形態として現れます。各形態にはそれぞれ異なるリスクプロファイルがあります。

• 運用データおよびテレメトリデータ： 保持期間の境界なく保管される Web サーバーログ、アプリケーショントレース、SIEM アーカイブ、テレメトリパイプラインには、セッショントークン、IPアドレス、さらにクエリパラメータや API 呼び出しによって取得された個人データが含まれることがよくあります。
• 冗長なコピーと放置されたエクスポート： 一度きりのプロジェクトのために作成された CRM、ERP、HR、または臨床システムからの CSV、Excel、JSON のエクスポートが、共有ドライブに放置されており、現在のオーナーもいなければ削除計画もありません。
• テストおよび開発データ： マスキングや保持（リテンション）制御を行わずに、運用データを開発（dev）、テスト、またはサンドボックス環境へコピーすることです。存在しなくなったアプリケーション向けに、顧客または患者のテーブルの完全コピーが含まれる場合もあります。
• 孤立したバックアップとレガシーアプリケーションデータ： 廃止されたシステムのバックアップやアーカイブセットには、何年もセンシティブな記録が保持されたままになっていることがあります。削除の判断に責任を負う割り当てられたオーナーがいないためです。

ハイブリッド環境における暗号データ（ダークデータ）の所在

上記のタイプは、予測可能なインフラ上の場所に蓄積しがちで、標準的なセキュリティおよびガバナンスのツールの適用範囲外になっていることがよくあります。

クラウドストレージとオブジェクトバケット

移行、概念実証（PoC）、または一回限りの分析ジョブのために作成され、決して廃止（decommission）されない S3、Azure Blob、GCS のバケットは、統制されないデータストアとして残り続けます。

これらは正式な資産インベントリに含まれたことがないため、通常は DLP のカバレッジから外れており、作成時の状況から受け継がれた過度に許可されたアクセス構成がそのまま持ち越され、さらにアクセスレビュー自体から完全に除外されます。

レガシーなファイル共有、NAS、コラボレーションスペース

部門のファイル共有や NAS デバイスは、通常の運用が続く何年にもわたって、未確認のコンテンツを蓄積していきます。 SharePoint サイト、Teams チャネル そして完了したプロジェクト由来の OneDrive フォルダーでは、アクティブな所有者がいないまま、契約書、レポート、データ抽出物が保存され続けます。

これらの環境には、組織内で最も古く、かつ最も機密性の高いデータの一部が保存されている一方で、監視ルールや分類ツールの適用範囲に入る可能性は比較的低い場所でもあります。

バックアップ、アーカイブ、ログのリポジトリ

長期バックアップ、クラウドのアーカイブ階層、ログの保存領域には、継続して保持されることを意図していなかった認証情報、セッショントークン、PII、PHI が含まれています。アクティブなデバッグに適したログの詳細度設定も、分類やレビューを行わないままログが複数年の保持期間にわたって個人データを保持するようになると、コンプライアンス上の負債（リスク）になります。

SaaS のエクスポートと AI ツールの統合

中核となる業務システムからマーケティング、HR、または製品の SaaS プラットフォームへエクスポートされたデータは、統制されたデータ環境の外に存在します。AI と自動化プラットフォームは、運用データを独自のストレージ、または長期間保持されるキャッシュ層に取り込みますが、こうしたデータは資産インベントリにほとんど反映されません。その結果、ライフサイクル上の自然な境界がないダークデータのカテゴリが拡大していきます。

ダークデータが蓄積する原因

予防的な統制を設計するセキュリティアーキテクトにとって、根本原因を理解することは重要です。反応的なクリーンアップは、発生源で蓄積を減らすよりも遅く、コストも高くつきます。

データ・ライフサイクルのガバナンスが欠落している

多くの組織では、データ作成プロセスはあるものの、それに対応する削除や再分類のプロセスがありません。データはインジェスト・パイプライン、SaaS 統合、ユーザー生成のワークフローを通じて取り込まれ、ライフサイクルを移し出すための自動化ルール、所有権の割り当て、レビューの起点となるトリガーが存在しないため、無期限に残り続けます。保持期間が上限なしで、分類が任意であるところでは、暗黙の結果としてダークデータが蓄積していきます。

組織的サイロとツールのサイロ

あるチームが作成したデータが、別のチームのガバナンス範囲に入ることはほとんどありません。マーケティングのエクスポート、開発者のデータベースのコピー、財務のアーカイブ、プロジェクトのファイルダンプは、それぞれガバナンス機能が追跡しないデータ成果物を作り出します。

セキュリティおよびデータガバナンスのチームは、通常こうした環境を棚卸しするためのツールを欠いているため、組織の境界を越えて蓄積が静かに続いてしまいます。

AI、オートメーション、そしてクラウドのスプロール

統制要件が導入時点にない場合、あらゆる新しい AI の統合、オートメーションのワークフロー、クラウド サービスは、デフォルトで暗号データ（ダークデータ）の生成源になります。

これらのツールは、派生データセット、推論ログ、統合キャッシュを生成し、所有者やライフサイクルの境界が定義されないまま残り続けます。

AI ツールの接続が最も急速に増加する要因です。LLM ベースのツールに共有されたデータは、組織の統制の範囲外で、AI ベンダーのインフラ内に残り続ける可能性があります。

ダークデータがセキュリティ上の問題になる理由

ダークデータは、侵害コストを増大させ、攻撃対象領域を広げ、規制上のリスクを生み、既知データを保護するために組織が頼りにする統制を弱体化させます。

見えないものは守れません

DLP、SIEM、アクセスガバナンス、暗号化は、把握しているデータ保管場所を保護します。カタログ化または分類されることが一度もないリポジトリは、これらの各統制の対象外になります。IBM 2025 Cost of a Data Breach Reportによれば、データ侵害の35%にはシャドーデータが含まれており、そうした侵害は、シャドーデータ要素のない侵害と比べて平均で16%コストが高く、特定までに26.2%長い時間がかかりました。

既存のセキュリティツールは、それを見つけるために設計されていません

DLP ポリシーは既知のチャネルを対象にし、SIEM はオンボードされたシステムからログを取り込み、そして IAM と IGA はインベントリ内の資産へのアクセスを統制します。これらのいずれのツールも、すでに把握していないものを発見することはできません。ダークデータは、発見（ディスカバリー）のレイヤーで各統制を打ち負かします。ストアが一度も棚卸し（インベントリ化）されないなら、DLP は決してそれをスキャンせず、SIEM は決してそれを監視せず、アクセスレビューも決してそれをカバーしません。

管理されていないデータによる規制上のリスク

GDPR, HIPAA, CCPA そして、ほとんどの業界別フレームワークでは、規制対象情報を含む管理されていないデータ格納がコンプライアンス違反だと見なされます。

データ最小化とプライバシー・バイ・デザイン（privacy by design）では、個人データがどこに存在するのかを実証できること、そしてそれを保持するための文書化された正当な理由が必要です。

Data Subject Access Requests（DSARs）や、消去（right-to-erasure）を求める要求は、完全なデータインベントリがないと構造的に対応が非常に困難であり、そのようなインベントリが欠如していることがダークデータプログラムの特徴になります。

監査・保証（assurance）における逆風

監査人は現在、非構造化でガバナンスされていないデータについて、直接的な質問をします。未知のデータストアはすべて、監査のプレッシャー下で手作業による調査を要するつらい例外になるか、より広範な統制の主張を損なう結果（指摘事項）になります。

定義されたスコープ、文書化された手法、現在のインベントリ、そして是正（リメディエーション）ログを備えた構造化された discovery プログラムがある組織は、現地調査の最中に未知の保存領域が判明する組織よりも、常に良い結果になります。

ダークデータを見つけてガバナンスする方法

目的は、すでに存在するものに対処しながら、未知の保存領域が蓄積されないように可視化とプロセス上の統制を構築することです。

順序が重要です。ポリシーの前に discovery を行う必要があります。なぜなら、不完全なインベントリに基づいて構築されたガバナンスのフレームワークは、誤った確信（false assurance）を生み出してしまうからです。

ステップ1：スコープを定義し、リスクに基づいて優先順位を決めます

階層化されたスコープのリストを作成します。

1. ティア 1：規制対象データを最も保有しやすく、かつ統制が最も弱い保管場所（本番環境に紐づくクラウドのオブジェクトストレージ、レガシーのファイル共有、Microsoft 365、SaaS エクスポーター）。
2. ティア 2：バックアップ、アーカイブ層、ログ格納領域。
3. ティア 3：テストおよび開発環境、ならびに退役済みシステムのアーカイブ。

各ティア（tier）ごとに、次の3つの基準で優先順位を付けます。規制対象範囲（GDPR、HIPAA、PCI DSS）、データ量、そして最後のアクセスレビューからの経過時間です。

3つの基準すべてで深刻度が高いストアは、検出キューの先頭に移します。スコーピング（範囲決定）の判断内容を記録しておくことで、次の評価サイクルでゼロから作り直すのではなく、改善・精緻化できます。

ステップ2：範囲内のストア全体で自動検出と分類を実行する

最優先のストアから順に、検出と分類のツールを展開します。データがどこに存在するかを事前に把握していなくてもよいように、ファイルシステム、オブジェクトストレージ、データベース、コラボレーション環境をスキャンするよう設定してください。

次に、分類ルールを設定して、PII、PHI、クレジットカード情報（payment card data）、認証情報（credentials）、および業界固有の規制対象コンテンツを検出します。

最初のスキャンは読み取り専用モードで実行し、ベースラインを確立します。結果を3つの成果物としてエクスポートしてください：発見されたストアの一覧、ストアごとの感度分類、そして、各ストアに到達できるユーザーとグループを示す有効権限マップ。

この統合された出力が、プログラムの残りの部分が参照して運用するインベントリです。

ステップ 3：所有権をマッピングし、保管（保持）方針を決定する

発見されたすべてのストアに、ビジネスオーナーを割り当てます。所有者が特定できない場合は、定められた期間内（ほとんどのプログラムでは 30 日）に割り当てのためデータガバナンスリードへエスカレーションしてください。所有者のいないストアは先へ進めません。

所有権が割り当てられたら、オーナーは次の2つの質問に答えます：このデータはまだ必要ですか。さらに、現在のアクセスは least privilege を反映していますか？

最初の削除キューへの移動に失敗したストア（法的保留および保管期間の確認の後）と、2回目のアクセス是正キューへの移動に失敗したストア。

両方の条件を満たしたストアは、文書化された所有者とレビューの頻度を伴ってガバナンス対象範囲に入ります。

ステップ 4：対象範囲内のストアにライフサイクルポリシーを適用する

各ガバナンス対象ストアに自動化されたライフサイクル規則を適用します。オブジェクトバケットにはクラウドストレージのライフサイクルポリシー、運用データストアにはデータベースの保管ポリシー、アーカイブ階層にはバックアップの保管設定です。

データカテゴリごとにデフォルトの期限切れ間隔を設定し、無期限保管が必要な場合は、明確で期限が定められた例外を必須にします。

各ライフサイクル ルールをステップ 2 で生成された分類に紐づけ、regulate​​d とタグ付けされたデータが自動的に正しい保管（レテンション）の経路をトリガーするようにします。

手動の削除ワークフローはバックログになり、バックログは恒久的なダークデータの蓄積につながります。したがって、基本はデフォルトで自動化し、手動での確認は例外に限定することが目的です。

ステップ 5：継続的なディスカバリーを運用化する

定めた間隔で定期的なディスカバリー スキャンをスケジュールします（多くのプログラムでは Tier 1 を週次、Tier 2 を月次、Tier 3 を四半期ごとに実施） 。既存のインベントリの外側に新しく出現したストアがあれば、それを検知してアラートします。

ディスカバリー プラットフォームを設定し、分類とアクセス結果を SIEM、SOAR、GRC プラットフォームへ取り込めるようにします。これにより、高リスクのロケーションが他のセキュリティ シグナルと同じダッシュボードに表示されます。

明確なエスカレーションのトリガーを定義します。例：新しく追加された高ボリュームの機微データ格納先、規制対象のコンテンツを広範囲に露出させる急な権限変更、または既存の格納先における分類の急増です。

各トリガーは、定義されたレスポンダーにルーティングされ、修復のSLA（サービスレベル合意）が適用されます。アウトプットは、四半期ごとのプロジェクトではなく、運用上の能力として実行される dark data ガバナンスになります。

次の監査があなたの代わりに dark data を見つける前に、適切なアプローチを選びましょう

ほとんどの dark data プログラムは、可視化を達成する前にポリシーから始まります。保管（レテンション）スケジュールと data classification のフレームワークは、記憶をもとに描いたデータマップに基づいて書かれますが、その内容は、本番システム、アーカイブ、SaaS 統合に実際に存在するものと一致することはありません。

Netwrix Access Analyzer は Windows ファイルサーバー、NAS、SharePoint、Microsoft 365、主要データベースにまたがって sensitive data を発見し分類します。さらに各ストアを有効な権限分析に接続し、誰がアクセスできるのかを可視化します。

AWS、Azure、GCP のクラウドネイティブなストアに存在するダークデータに対して、Netwrix DSPM はクラウドのデータリポジトリ全体で検出とポスチャ管理を拡張し、オンプレミスおよびハイブリッドの Microsoft 環境には Access Analyzer のカバー範囲も併せて提供します。

Netwrix Auditor は、機密データがどのようにアクセスされ、どのように変更されるかを継続的に監視することで、その可視性をさらに拡張します。3つが連携することで、静的なインベントリを運用上の data security ガバナンスへと変換します。未知のストアがスコープに入り、是正は証拠に基づいて追跡され、生成されたデータとガバナンスされたデータのギャップはサイクルごとに縮小します。

次の監査がギャップを見つけてしまう前に、Netwrix がダークデータを発見し、アクセスをガバナンスし、コンプライアンス要件を満たす方法をご覧ください。デモをお申し込みください。