CUIを守るには、まずCUIがどこにあるかではなく、どこから来て、どこで使われ、どこへ出ていくかを理解する必要があります。CUIデータフロー設計は、CMMC対応のための資料作成ではなく、CUI保護の設計そのものです。

はじめに

CUI対応を始めると、多くの企業は最初に資産台帳を作ろうとします。もちろん資産台帳は必要です。しかし、資産台帳だけではCUIを守れません。

CUIは静止していません。契約書、仕様書、設計図、試験データ、ソースコード、製造指示、品質記録、ログ、バックアップ、メール、チャット、チケット、PLM、CAD、クラウドストレージを通じて移動します。

CUIを守るには、CUIがどこに置かれているかだけでなく、どの業務プロセスの中で、どのシステムを通り、どの人が触り、どの外部サービスへ渡るのかを把握する必要があります。

これが、CUIデータフロー設計です。

結論

CUIデータフロー設計とは、CUIの受領、作成、分類、保存、利用、共有、送信、バックアップ、アーカイブ、削除までを、業務・システム・責任の観点から可視化する作業です。

これは、CMMC評価のためだけの図ではありません。CUI Boundary、SSP、資産分類、アクセス制御、暗号化、ログ管理、外部サービスの責任分界を決めるための土台です。

データフローがないままCMMC対応を進めると、「どのシステムが対象なのか」「どのログが必要なのか」「誰がアクセスできるのか」「MSPはスコープに入るのか」「クラウドはどこまで責任を持つのか」を説明できません。

CUIデータフローの出発点

最初に確認するべきことは、CUIがどこから来るかです。

CUIは、政府から直接渡される場合もあれば、プライム契約企業や米国子会社から流れてくる場合もあります。また、契約履行の過程で自社が作成した情報がCUIになる場合もあります。

NARAのCUI定義では、CUIは政府が作成・保有する情報だけでなく、政府のために組織が作成・保有する情報も含み得ます。したがって、受け取ったファイルだけでなく、自社が生成する派生データ、試験結果、分析結果、図面更新、ソフトウェア、品質記録も確認対象になります。

最初に見るべき入力は、次の通りです。

  • 契約書
  • Statement of Work
  • 技術仕様書
  • DFARS条項
  • 顧客からのCUI指示
  • CUIマーキング
  • Distribution Statement
  • 輸出管理分類
  • 既存のファイル共有・メール・PLM・CAD・開発環境

ここを見ずに、システム構成だけを見てもCUIデータフローは描けません。

データフローで見るべき10の段階

CUIデータフローは、次の10段階で整理すると実務に落とし込みやすくなります。

段階 確認内容
受領 誰から、どの経路で、どの形式でCUIを受け取るか
識別 CUIカテゴリ、マーキング、契約上の指示をどう確認するか
分類 社内でCUIとしてどのようにラベル付け・分類するか
保存 どのストレージ、リポジトリ、端末、バックアップに保存するか
利用 誰が、どの端末・アプリケーションで閲覧・編集するか
加工 派生データ、変換ファイル、スクリーンショット、印刷物をどう扱うか
共有 社内外の誰へ、どの条件で共有するか
送信 メール、API、SFTP、クラウドリンク、物理媒体をどう制御するか
記録 アクセス、変更、送信、削除、権限変更をどうログ化するか
廃棄 契約終了、保持期間満了、顧客指示時にどう削除・返却するか

この10段階を追うと、CUIがシステム上だけでなく、業務プロセス上どこに現れるかが見えてきます。

図に入れるべき要素

CUIデータフロー図には、単に矢印を描くだけでは足りません。評価や設計に使うなら、少なくとも次の要素を入れるべきです。

  • データの種類
  • CUIカテゴリまたは想定される管理区分
  • データの発生源
  • 保存先
  • 利用者の役割
  • 認証・認可の仕組み
  • 暗号化の有無
  • 鍵管理の場所
  • ログ取得ポイント
  • バックアップ先
  • 外部サービス
  • 管理者経路
  • 国境を越える転送の有無
  • 顧客または契約上の制限

特に見落とされやすいのは、管理者経路とログの流れです。ユーザーがCUIファイルを開く経路だけを描いても、実際には管理者がストレージ設定を変え、EDRがファイル情報を収集し、SIEMがログを集約し、バックアップが別リージョンへ複製することがあります。

CUIデータフロー設計では、本文データだけでなく、CUIを保護するための情報の流れも追う必要があります。

CUIを増やさない設計

CUIデータフロー設計の目的は、CUIを見つけることだけではありません。CUIが無秩序に広がることを防ぐことです。

CUIがメール添付、ローカルPC、個人用クラウド、開発チケット、チャット、バックアップ、ログに広がると、CUI Boundaryは急速に膨らみます。境界が膨らむほど、評価対象も増え、責任分界も曖昧になります。

したがって、データフロー設計では、次のような制御を考えます。

  • CUIの保存場所を限定する
  • メール添付ではなく承認済みリポジトリで共有する
  • ダウンロードを制御する
  • ローカル保存を制限する
  • プレビュー、サムネイル、検索インデックスの扱いを確認する
  • CUIを含むチケットやコメントを避ける
  • CUIを含むログを最小化する
  • バックアップとアーカイブの範囲を明確にする
  • 契約終了時の削除・返却手順を定義する

CUIを守る最良の方法の一つは、CUIを不要な場所へ広げないことです。

日本企業に特有のデータフロー

日本企業では、CUIデータフローが国境を越えることがあります。

米国プライムから米国子会社へ、米国子会社から日本本社へ、日本本社から製造拠点へ、製造拠点から検査委託先へ、という流れです。このとき、CMMCだけでなく、ITAR、EAR、契約上の配布制限、US Person制限、顧客指示が関係する可能性があります。

重要なのは、CMMCと輸出管理を混同しないことです。

CMMCは、CUIを扱う情報システムの保護状態を問います。一方、ITAR/EARは、技術情報や物品の輸出・再輸出・みなし輸出などに関する規制です。両者は重なることがありますが、同じ概念ではありません。

したがって、CUIデータフロー図では、セキュリティ境界だけでなく、国、法人、雇用関係、委託先、アクセス主体、輸出管理上の制限も注記する必要があります。

データフローとSSPの関係

SSPは、CUI環境の設計と運用を説明する文書です。しかし、SSPだけを先に書こうとすると、抽象的な文章になりがちです。

良いSSPは、良いデータフローから生まれます。

データフローが明確であれば、SSPに次の内容を具体的に書けます。

  • CUIを扱うシステム境界
  • CUI Assetの範囲
  • Security Protection Assetの範囲
  • 外部サービスとの関係
  • 顧客責任とサービス提供者責任
  • アクセス制御の適用点
  • 暗号化と鍵管理
  • 監査ログの取得点
  • バックアップと廃棄
  • インシデント時の調査対象

逆に、データフローが曖昧なSSPは、評価で必ず弱くなります。文章は整っていても、CUIがどこを流れるのかを追跡できなければ、設計の説明になっていないからです。

よくある誤解

「CUIはファイルサーバーだけ見ればよい」という誤解があります。実際には、CUIはメール、端末、VDI、CAD、PLM、ソースコード管理、バックアップ、ログ、チケット、クラウドストレージに現れます。

「データフロー図は監査資料」という誤解もあります。データフロー図は監査のためだけではなく、設計、運用、権限管理、インシデント対応、教育の基準になります。

「CUIを受け取っていないから関係ない」という誤解も危険です。契約履行のために自社が作成した情報がCUIになる場合があります。

実務で使える最小テンプレート

最初の段階では、複雑な図を作る必要はありません。次の項目を表で整理するだけでも効果があります。

データ名 CUI該当性 発生源 保存先 利用者 送信先 保護策 ログ 責任者
技術図面 要確認 顧客 PLM 設計部 製造部 MFA、暗号化、DLP アクセスログ 設計責任者
試験データ 要確認 自社 Blob Storage 品質保証 米国子会社 RBAC、CMK、Private Endpoint Storage logs 品質保証責任者
仕様変更メモ 要確認 顧客会議 チケット PM、設計 なし ラベル、アクセス制御 チケット監査ログ PM

この表を作るだけで、CUIがどこにあるかではなく、どの業務で使われているかが見えてきます。

本質

CUIデータフロー設計の本質は、CUIを「点」ではなく「流れ」として捉えることです。

CUIはファイルではありません。業務の中を移動し、変換され、複製され、参照され、ログに残り、バックアップされ、時には別の国へ渡ります。

CUIを守るとは、その流れを制御することです。

CMMC対応の質は、データフローの解像度で決まります。CUIの流れが見えていない組織は、境界も責任も説明できません。CUIの流れを説明できる組織だけが、設計としてのセキュリティを語ることができます。

深掘り：CUIデータフロー設計を実務判断に落とす

CUIデータフロー設計は、CUIがどこに保存されているかを調べる作業ではありません。CUIが発生し、受領され、加工され、共有され、参照され、削除されるまでの状態変化を追跡する作業です。

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

データフローを作らずに資産台帳だけを整えると、メール添付、Teamsチャット、ダウンロードフォルダ、印刷、PLM連携、ログ転送、バックアップ、外部委託先との共有が抜けます。評価では「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、バックアップ、管理端末、ネットワーク制御も、判断対象に入ることがあります。

データフローは、業務フロー、システムフロー、権限フロー、ログフローの4層で描くと実務に落ちます。誰が業務上必要としているのか、どのシステムを経由するのか、誰が権限を付与するのか、操作がどこに記録されるのかを分けます。

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

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

日本本社、米国子会社、国内製造拠点、外部MSP、クラウドストレージが同じ案件で関わる場合、CUIは単一システムに閉じません。設計図、試験結果、変更依頼、レビューコメントが複数経路で移動します。

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

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

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

CUI台帳、業務プロセス図、データフロー図、アクセス権レビュー、DLP/監査ログ、外部共有記録、削除・保管期間ルールが必要です。

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

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

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

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

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

運用成熟度の見方

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

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

組織間の責任分界

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

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

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

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

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

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

確認すべき問い

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

次に読む記事

次は「ファイルレベル暗号化とCMMC」です。CUIデータフローを制御するための一つの手段として、ファイル単位の保護を考えます。

参考資料