Data-centric Securityとは何か

Data-centric Securityは、ネットワークや場所ではなく、データそのものを保護の中心に置く考え方です。CUIを「特定フォルダ内のファイル」ではなく「保護状態を持つ情報」として扱うなら、この考え方は避けて通れません。

はじめに

従来のセキュリティは、境界を守る発想に大きく依存してきました。社内ネットワークの内側は信頼し、外側を危険と見る。VPNで内側に入れば、一定の信頼を与える。ファイルサーバーのフォルダ権限でアクセスを制御する。

しかし、CUIを扱う実務では、この発想だけでは足りません。

CUIは、メール、クラウド、端末、外部委託、米国子会社、設計環境、製造環境、ログ、バックアップを通じて移動します。ネットワーク境界を一度越えたら保護が弱くなるような設計では、CUIを継続的に守ることはできません。

そこで重要になるのが、Data-centric Securityです。

結論

Data-centric Securityとは、データそのものに着目し、分類、アクセス制御、暗号化、利用制限、監査、ライフサイクル管理を適用する考え方です。

CUIの文脈では、「どのネットワークにあるか」だけでなく、「そのデータが何であり、誰が、どの目的で、どの条件で、どの操作をできるのか」を制御することが重要になります。

これは、CMMCやNIST SP 800-171の要求を置き換えるものではありません。むしろ、CUI Boundary、Zero Trust、ABAC、暗号化、DLP、監査ログを統合するための設計原則です。

Data-centric Securityが必要になる理由

CUIは、固定された場所に留まりません。

図面はCADで開かれ、PDFに変換され、メールで共有され、クラウドストレージに置かれ、レビューコメントがチケットに書き込まれ、試験データが分析され、バックアップに複製され、ログにファイル名やアクセス履歴が残ります。

このような環境では、「CUIフォルダだけ守る」という発想では不十分です。

Data-centric Securityでは、次の問いを中心にします。

このデータは何か
CUIに該当するか
どのカテゴリ・契約・配布制限に関係するか
誰がアクセスできるべきか
どの操作を許すべきか
どの場所・端末・条件なら利用できるか
共有後も制御を維持できるか
利用や共有を監査できるか
契約終了時に失効・削除できるか

これは、場所ではなく意味に基づくセキュリティです。

CUIはファイルではなく保護状態である

CUIを理解するうえで大切なのは、CUIを単なるファイルとして見ないことです。

CUIは、法律・規則・政府全体方針により、保護または配布制限が求められる情報です。NARAの定義でも、CUIは政府が作成・保有する情報、または政府のために組織が作成・保有する情報であり、法令等により safeguarding または dissemination controls が求められるものと説明されています。

この定義から見れば、CUIは「ファイル名」ではありません。情報の性質と、その情報に求められる取り扱いです。

つまり、CUIは保護状態です。

同じPDFでも、内容、契約、マーキング、配布制限、作成目的によって扱いが変わります。同じクラウドストレージでも、CUIが入っているかどうか、誰がアクセスできるか、どの保護策が適用されているかで評価が変わります。

Data-centric Securityは、この考え方と相性がよいです。

Data-centric Securityの構成要素

Data-centric Securityは、単一の製品ではありません。複数の仕組みを組み合わせる設計です。

主な構成要素は次の通りです。

要素	役割
データ分類	CUI、社外秘、一般情報などを識別する
ラベル	データに保護状態を示す属性を付与する
アクセス制御	誰がどの操作をできるかを決める
暗号化	保存中・転送中・ファイル単位で内容を保護する
鍵管理	復号権限と鍵のライフサイクルを管理する
DLP	不適切な共有・送信・コピーを検知または防止する
ABAC	主体、客体、操作、環境条件に基づいて認可する
監査ログ	誰が、いつ、何をしたかを記録する
ライフサイクル管理	保持、アーカイブ、削除、失効を管理する

この中で特に重要なのは、分類とアクセス制御です。何がCUIか分からなければ、適切な保護はできません。誰が何をできるかを制御できなければ、暗号化やDLPも十分に機能しません。

Zero Trustとの関係

Data-centric Securityは、Zero Trustと深く関係します。

NIST SP 800-207は、Zero Trustが静的なネットワーク境界から、ユーザー、資産、リソースに焦点を移す考え方であると説明しています。Zero Trustは、ネットワーク上の場所だけを理由に暗黙の信頼を与えないという原則を持ちます。

Data-centric Securityも同じ方向を向いています。

CUIが社内ネットワークにあるから安全とは見ません。VPN経由だから信頼するとも考えません。ユーザー、端末、データ、操作、コンテキストを見て、アクセスを判断します。

たとえば、同じユーザーでも、管理された端末から業務時間内に承認済みアプリで閲覧する場合と、未管理端末から海外ネットワーク経由で一括ダウンロードする場合では、判断を変えるべきです。

Data-centric Securityは、Zero Trustをデータ保護の側から具体化する考え方です。

ABACとの関係

ABAC、つまりAttribute-Based Access Controlは、Data-centric Securityを実装するうえで重要です。

NIST SP 800-162では、ABACは、主体、客体、要求された操作、場合によっては環境条件に関連する属性を評価し、ポリシーに照らして認可を決定する論理アクセス制御方法として説明されています。

CUIの文脈では、ABACは次のような判断を可能にします。

ユーザーの所属部門
プロジェクト参加状況
契約番号
CUIカテゴリ
配布制限
デバイス準拠状態
MFAの強度
接続元
時間帯
操作内容

このような属性を組み合わせることで、「設計部なら全部見られる」という粗い権限ではなく、「この契約のこのCUIカテゴリについて、承認済み端末から閲覧はできるが外部共有はできない」といった制御が可能になります。

Data-centric Securityの落とし穴

Data-centric Securityは有効ですが、誤った導入も多いです。

最も多い失敗は、ラベルだけを導入することです。ファイルに「CUI」と表示されても、そのラベルが権限、暗号化、DLP、ログ、共有制限に結びついていなければ、実質的な保護は弱いままです。

次に多い失敗は、ユーザー任せにすることです。すべての分類を手動にし、判断基準も曖昧なままでは、重要なCUIがラベルなしで流れます。自動検出と人による確認を組み合わせる必要があります。

もう一つの失敗は、データ中心と言いながらシステム管理を軽視することです。Data-centric Securityは、端末、ID、ネットワーク、ログ、鍵管理を不要にするものではありません。むしろ、それらをデータ保護の目的に合わせて統合する考え方です。

日本企業での実務上の使い方

日本企業がData-centric SecurityをCUI対応に使う場合、最初から完璧な自動分類を目指す必要はありません。

まずは、CUIを扱う業務と保存場所を限定し、CUIに該当し得るデータを明確にします。そのうえで、ラベル、権限、暗号化、ログを段階的に結びつけます。

実務では、次の順番が現実的です。

CUIに該当し得るデータ種別を洗い出す
CUIデータフローを作成する
CUI保存場所を限定する
ラベル体系を定義する
ラベルとアクセス制御を結びつける
ラベルと暗号化を結びつける
ラベルとDLPを結びつける
ラベルとログレビューを結びつける
例外承認と定期レビューを設計する

重要なのは、ラベルを貼ることではなく、ラベルが運用を変えることです。

よくある誤解

「Data-centric Securityは製品の名前」という誤解があります。実際には、製品ではなく設計思想です。分類、暗号化、ABAC、DLP、ログ、鍵管理をどう組み合わせるかが重要です。

「データを守ればシステムは見なくてよい」という誤解もあります。CMMCでは、CUIを処理・保存・送信するシステム全体が評価対象になります。データ保護はシステム保護を置き換えるものではありません。

「AIで自動分類すれば終わる」という誤解も危険です。自動分類は有効ですが、契約、CUIカテゴリ、配布制限、輸出管理、顧客指示を理解した運用が必要です。

本質

Data-centric Securityの本質は、CUIを場所ではなく意味と状態で守ることです。

CUIがどこにあるかだけでなく、それが何であり、誰に、どの条件で、どの操作を許すのかを制御する。ファイルが移動しても、保護状態を維持する。アクセスと利用を記録する。契約終了時には失効できる。

これは、CMMCを単なるチェックリストではなく、情報保護の設計として捉えるための中心的な考え方です。

CUIは境界の中に閉じ込めるだけでは守れません。CUIそのものに保護状態を持たせる必要があります。

深掘り：Data-centric Securityとは何かを実務判断に落とす

Data-centric Securityは、ネットワークやシステムの場所ではなく、データそのものの価値、感度、利用条件に基づいて保護を組み立てる考え方です。CUIのように組織や国境を越えて移動する情報では、この発想が特に重要になります。

ここで重要なのは、概念を知識として理解するだけで終わらせないことです。CMMCやCUI保護の実務では、どの情報を、どのシステムで、誰が、どの権限で、どの条件のもと扱うのかを説明できなければなりません。Data-centric Securityとは何かという論点も、最終的にはSSP、資産台帳、データフロー、責任分界、運用証跡のどこかに接続されます。

境界型の発想だけでCUIを守ろうとすると、境界の外へ共有された瞬間に統制が弱くなります。メール添付、外部共有リンク、ダウンロード、委託先での加工、共同開発環境では、データ中心の制御がなければ保護状態が追跡できません。

このため、設計時には「対象を狭く見すぎていないか」と「責任を広く曖昧にしすぎていないか」の両方を確認します。前者はスコープ漏れを生み、後者は運用不能な過大スコープを生みます。CMMC対応で重要なのは、すべてを一律に厳しくすることではなく、CUIに影響する経路を特定し、そこに必要な統制を説明可能な形で置くことです。

CMMC / CUI環境での見方

CMMCの文脈では、この論点を単独で扱うのではなく、CUI Asset、Security Protection Asset、Contractor Risk Managed Asset、External Service Provider、Cloud Service Providerとの関係で見ます。CUIを直接扱う資産だけでなく、CUI環境を保護するID基盤、監査ログ、EDR、SIEM、バックアップ、管理端末、ネットワーク制御も、判断対象に入ることがあります。

分類、ラベル、暗号化、アクセス制御、DLP、監査ログ、保持期間、削除ルールをデータ単位で接続します。システム境界とデータ境界を重ねて見える化することが重要です。

このとき、「どの製品を使うか」よりも、「その製品がどの要求を、どの範囲で、誰の責任で満たすのか」を先に整理します。クラウドやMSPを利用している場合でも、サービス提供者が担う部分と顧客側が設定・運用・確認する部分は分かれます。したがって、Customer Responsibility Matrixや契約上のサービス範囲を、SSPの記述と一致させる必要があります。

日本企業で起きやすい場面

日本企業が米国プライムと設計レビューを行う場合、CUIはPLM、メール、会議、チャット、PDF、CAD、スクリーンショットという形で派生します。Data-centric Securityは、派生物にも分類・権限・ログを結び付ける発想です。

このような場面では、米国側の契約主体、日本側の親会社、現地子会社、外部MSP、クラウド事業者、業務部門が同じ情報に異なる立場で関わります。日本側が「データを直接見ていない」と考えていても、ID管理、端末管理、ログ監視、バックアップ、ヘルプデスク、インシデント対応を担っている場合、CUI環境の保護に影響している可能性があります。

そのため、最初に確認すべきなのは「誰が契約主体か」だけではありません。誰がCUIにアクセスできるのか、誰がアクセス権を付与できるのか、誰がログを見られるのか、誰が障害時に復旧できるのか、誰がインシデント時に顧客へ説明するのかを分解する必要があります。

SSP・証跡・責任分界への落とし込み

分類ポリシー、ラベル適用率、例外共有記録、DLPアラート、アクセスレビュー、保持・削除記録が、データ中心の保護状態を示す証跡になります。

SSPに書くべきなのは、理想的な方針だけではありません。評価者や顧客が確認したときに、実装状態を追跡できる記述が必要です。たとえば、アクセス制御であれば対象者、対象システム、認証方式、例外条件、レビュー頻度、ログ保存先まで書かなければ、実装の説明としては不足します。

責任分界では、Accountableな主体とResponsibleな主体を分けます。契約上の表明を行う組織、設定を変更する組織、ログを監視する組織、証跡を保管する組織、例外を承認する組織が異なる場合、それぞれを文書化します。ここを曖昧にすると、評価時だけでなく、インシデントや顧客問い合わせの場面でも説明が崩れます。

判断フローとして整理する

Data-centric Securityとは何かを実務に落とすときは、最初に定義から入るのではなく、判断の順番を決めます。第一に、対象となる情報や機能がCUIそのものなのか、CUIを保護するための機能なのかを分けます。第二に、その対象がどの契約、どの業務、どのシステム、どの外部サービスに結び付いているかを確認します。第三に、アクセスする主体を人、端末、アプリケーション、サービスアカウント、管理者、外部委託先に分解します。第四に、その主体が実行できる操作を、閲覧、編集、削除、共有、管理、復旧、ログ閲覧に分けます。

この順番で整理すると、曖昧な議論が減ります。たとえば「アクセスできるか」という問いは、閲覧できるのか、ダウンロードできるのか、共有できるのか、管理者として復旧できるのかで意味が変わります。また「自社が責任を持つか」という問いも、設定責任、運用責任、証跡提供責任、契約上の説明責任に分けなければ実務には落ちません。CMMCでは、こうした分解がそのままSSP、CRM、資産台帳、運用手順の質に現れます。

運用成熟度の見方

初期段階では、まず対象と責任を見える化することが優先です。対象システム、CUIの流れ、管理者、外部サービス、例外運用を一覧化し、現状を正直に把握します。次の段階では、ポリシーと実装を一致させます。文書には最小権限と書いているが実際には共有フォルダが広すぎる、ログを取得すると書いているが誰もレビューしていない、という不一致を潰していきます。

成熟した段階では、証跡が日常運用の副産物として残るようになります。アクセスレビュー、変更管理、ログレビュー、例外承認、インシデント対応がチケットやワークフローに組み込まれ、評価前に慌てて証跡を集める必要がなくなります。さらに、事業部門、IT、セキュリティ、法務、輸出管理、経営が同じ境界図と責任分界表を見て判断できる状態になると、制度対応は一時的なプロジェクトではなく、継続的な運用になります。

組織間の責任分界

日本企業にとって特に重要なのは、組織間の責任分界です。米国プライム、米国子会社、日本本社、国内製造拠点、MSP、CSPが関係する場合、CUIの保護状態は単一組織の中だけでは完結しません。誰かが設定を変更し、別の誰かがログを見て、さらに別の誰かが契約上の説明を行うことがあります。この状態を放置すると、評価時には「誰が実装したのか」「誰が確認したのか」「誰が例外を承認したのか」に答えられなくなります。

責任分界は、契約書だけで決まるものでも、システム図だけで決まるものでもありません。契約上の義務、実際の管理権限、運用手順、証跡の所在、インシデント時の連絡経路を合わせて初めて成立します。したがって、Data-centric Securityとは何かを扱う記事でも、最終的には「この論点を誰が所有するのか」「誰が実装するのか」「誰が証跡を提示するのか」を明確にする必要があります。

よくあるつまずきと回避策

この論点で最も多いつまずきは、制度上の言葉、技術上の設定、運用上の責任を同じ言葉でまとめてしまうことです。たとえば「アクセス制御」と言っても、本人確認、認可、条件判定、権限付与、権限レビュー、ログ確認、例外承認は別の活動です。どれか一つを実装しても、全体が成立するわけではありません。Data-centric Securityとは何かを扱うときも、言葉を細かく分解し、各活動に所有者と証跡を対応させる必要があります。

もう一つのつまずきは、評価や監査を意識しすぎて、現場の業務フローから切り離された文書を作ってしまうことです。CMMCで評価されるのは、文書の美しさではなく、実際にCUIが扱われる場面で保護状態が維持されているかです。したがって、業務担当者がどのタイミングでCUIを受け取り、どのツールで加工し、誰に共有し、いつ削除または保管するのかを、現実の流れとして確認する必要があります。

回避策は、記事で扱う概念を必ず「業務」「システム」「責任」「証跡」の四つに戻すことです。業務上なぜ必要なのか。どのシステムで実現しているのか。誰が判断・実装・レビューするのか。証跡はどこに残るのか。この四つに答えられれば、抽象的な概念は実務で使える設計論点に変わります。

確認すべき問い

この論点は、CUIそのものに関係しているのか、CUIを保護する機能に関係しているのか。
対象となる資産、ユーザー、管理者、外部サービスはSSPと資産台帳に記録されているか。
その統制は、誰が実装し、誰がレビューし、誰が例外を承認するのか。
証跡はどこに残り、どの期間保持され、評価時に誰が提示できるのか。
日本本社、米国子会社、MSP、CSPの責任境界は契約・CRM・運用手順で一致しているか。

次に読む記事

次は「ABACによるアクセス制御」です。Data-centric Securityを実際の認可判断に落とし込むための考え方を整理します。