CUIとは何か

はじめに

CMMCを理解するうえで、CUIは最も重要な概念の一つです。同時に、最も誤解されやすい概念でもあります。

CUIを「政府の秘密情報」や「CUIマークが付いたファイル」とだけ理解すると、実務判断を誤ります。CUIは、単なるファイル名でも、感覚的な機密度でもありません。CUIは、根拠を持って保護または配布制限が求められる情報の状態です。

結論

CUIとは、classified informationではないが、法律、規則、政府全体方針に基づいて、保護または配布制限が求められる情報です。NARAはCUIを、Executive Order 13526やAtomic Energy Act上のclassified informationではないが、適用法令、規則、政府全体方針に従って safeguarding または dissemination controls が必要な情報として説明しています。32 CFR Part 2002も、政府が作成・保有する情報、または政府のために企業等が作成・保有する情報で、法律・規則・政府全体方針により保護または配布制限が求められるものと定義しています。参考: 32 CFR Part 2002 – Controlled Unclassified Information, NARA – About Controlled Unclassified Information (CUI)

ここで重要なのは、CUIが「classifiedではない」ことです。つまり、CUIは国家機密そのものではありません。しかし、公開してよい情報でもありません。

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

実務でよくある誤解は、CUIをファイルの種類として理解することです。

たとえば、ある図面ファイルがCUIなのか、あるExcelがCUIなのか、あるメールがCUIなのか、という問いだけで考えると、CUIの扱いを狭く見すぎます。

本当に重要なのは、次の問いです。

その情報は政府契約に基づいて提供または生成されたものか
その情報に保護または配布制限を求める根拠があるか
その情報はCUI Registry上のカテゴリに該当するか
契約、仕様書、配布制限、マーキング、DFARS条項により保護義務が示されているか
その情報をどのシステムで処理・保存・送信しているか

CUIは、単独のファイルとしてだけでなく、データフロー、アクセス権、保存先、送信先、管理者権限を含めて考える必要があります。

CUIとclassified informationの違い

CUIはclassified informationではありません。ここを曖昧にすると、CMMC、NIST SP 800-171、ITAR/EAR、NISPOMなどの制度が混ざります。

classified informationは、国家安全保障上の機密指定を受けた情報です。一方、CUIはunclassifiedです。しかし、unclassifiedであっても、法令や政府方針により保護または配布制限が必要な情報があります。CUIはその領域を標準化するための制度です。

実務上のポイントは、CUIを「機密ではないから安全」または「機密だから別制度」と極端に分けないことです。CUIは、非機密でありながら制御対象です。

CUIと社内機密の違い

もう一つ重要なのは、CUIと社内機密の違いです。

企業が独自に「Confidential」「社外秘」「Internal Use Only」とラベルを付けた情報は、必ずしもCUIではありません。CUIになるには、政府が作成・保有する情報、または政府のために作成・保有する情報であり、法律・規則・政府全体方針により保護または配布制限が求められる必要があります。参考: 32 CFR Part 2002 – Controlled Unclassified Information

逆に、企業にとっては日常的な設計情報でも、DoD契約のために作成され、配布制限やCUIカテゴリに該当する場合は、CUIとして扱う必要が生じます。

つまり、CUI判断では「自社にとって重要か」だけでは足りません。「政府契約上、保護義務があるか」を確認する必要があります。

防衛分野で特に重要なControlled Technical Information

日本企業が防衛サプライチェーンで特に注意すべきCUIカテゴリの一つがControlled Technical Informationです。

NARAのCUI Registryでは、Controlled Technical Informationは、軍事または宇宙用途を持ち、アクセス、使用、複製、修正、表示、開示、配布などが制限される技術情報とされています。例として、研究・エンジニアリングデータ、設計図、仕様、標準、プロセスシート、マニュアル、技術レポート、データセット、ソフトウェアの実行コードやソースコードなどが示されています。参考: NARA CUI Registry – Controlled Technical Information

ここで注意すべきなのは、CUIは文書だけではないという点です。CADデータ、ソースコード、解析データ、試験ログ、構成情報、製造条件、技術レポートもCUIになり得ます。

CUIを扱うシステムをどう考えるか

CMMCやNIST SP 800-171の文脈では、CUIを扱うシステムとは、CUIを処理・保存・送信するシステムです。

処理とは、CUIを開く、編集する、生成する、印刷する、変換する、分析するなどの行為です。

保存とは、CUIをファイルサーバー、クラウドストレージ、データベース、端末、バックアップ、メモリ、紙媒体などに保持することです。

送信とは、CUIをメール、チャット、ファイル転送、API、VPN、物理媒体、同期サービスなどで移動することです。

この3つのどれかに該当する資産は、CUI Assetとして評価範囲の中心になります。32 CFR Part 170は、CUI AssetをCUIを処理・保存・送信する資産として扱い、資産台帳、SSP、ネットワーク図に文書化し、Level 2要求に対して評価されるものとしています。参考: 32 CFR Part 170 – Cybersecurity Maturity Model Certification (CMMC) Program

CUI Boundaryという考え方

CUIを理解するうえで、CUI Boundaryは避けられません。

CUI Boundaryとは、CUIが存在し、移動し、保護される範囲です。これはネットワーク境界だけではありません。ユーザー、端末、ID、アプリケーション、ストレージ、ログ、管理者権限、外部サービス、物理エリアまで含みます。

CUI Boundaryを定義しないままCMMC対応を始めると、すべてがスコープに入るか、逆に重要な保護機能を見落とすかのどちらかになります。

CUI Boundary設計では、次を明確にします。

CUIはどこで作成されるか
CUIはどこに保存されるか
CUIは誰に送信されるか
CUIにアクセスできる主体は誰か
CUIを守るセキュリティ機能は何か
CUIを守るログや設定情報はどこにあるか
CUIを扱わないが近接している資産をどう管理するか

CUIは「見つけたらラベルを貼る」だけでは守れません。境界と責任を定義して初めて、保護状態として管理できます。

よくある誤解

第一の誤解は、「CUIマークがなければCUIではない」というものです。マーキングは重要ですが、契約、配布制限、CUI Registry、DFARS条項、政府顧客からの指示と合わせて判断する必要があります。

第二の誤解は、「暗号化すればCUIではなくなる」というものです。暗号化は保護手段であり、情報の性質そのものを消すものではありません。暗号化されたCUIを誰が復号できるのか、鍵を誰が管理するのか、どのシステムで処理するのかが引き続き重要です。

第三の誤解は、「社内機密と同じ扱いでよい」というものです。CUIは政府契約上の保護義務を伴う情報です。社内分類だけでなく、契約・規則・評価要求に接続して管理する必要があります。

第四の誤解は、「CUIは米国側だけで管理すればよい」というものです。日本本社がID、ログ、端末、クラウド、SOC、バックアップ、管理者権限を持つ場合、日本側もCUI保護構造に関係します。

本質

CUIの本質は、情報そのものではなく、政府契約上の保護義務を伴う情報状態です。

CUIを正しく扱うには、ラベルではなく、根拠、境界、流れ、権限、責任を見なければなりません。

まとめ

CUIはclassifiedではありません。しかし、自由に扱ってよい情報でもありません。法律、規則、政府全体方針に基づいて保護または配布制限が求められる情報です。

日本企業にとって重要なのは、CUIを「ファイル」ではなく「保護状態」として理解することです。CUIがどこで処理・保存・送信され、誰がアクセスし、どのシステムが保護機能を担い、どこまでがCUI Boundaryなのかを明確にすることが、CMMC対応の出発点になります。

次は「NIST SP 800-171とは何か」です。CUIを保護するための要求事項を、CMMCとの関係も含めて整理します。