CUI 保護：受控非密情報を安全に取り扱う

Controlled unclassified information（CUI）は、機密ではないもののセンシティブであり、連邦法、規則、または政府全体に適用される方針に基づいて保護または流通（共有）に関する統制が必要な情報です。国防、エネルギー、ヘルスケアなど、その他の規制対象分野における連邦機関および契約業者にとって、CUI を適切に取り扱う義務は、重要なコンプライアンス上および契約上の影響を伴います。

それでも多くの組織では、連邦の要件を満たすために必要な手順、システム上の統制（コントロール）、そして可視性が依然として不足しています。CMMC Phase 1 implementation が進行中であり、政府が FAR CUI rule を通じて、契約業者の取り扱い要件をより一様にしていく動きにあるため、CUI のコンプライアンスはもはや“願望”ではありません。契約上の前提条件です。

CUI に対して適切な識別、マーキング、保護、および配布（分配）制御を適切に実証できない組織は、不利な監査結果、契約の遅延、ならびに将来の受賞資格の喪失というリスクがあります。

このガイドでは、CUI が実際に何であるか、保護要件がどのような内容になるのか、そしてそれを安全に取り扱うための実践的なアプローチをどのように構築するかを分かりやすく解説します。

管理対象の非機密情報（CUI）とは？

管理対象の非機密情報（CUI）とは、連邦政府が作成または保有する情報、または政府のために作成・保有する主体の情報のうち、適用される法律、規則、および政府全体に共通する方針に整合する形で、保護または配布（分配）に関する統制を必要とする情報を指します。

正式な情報区分として、CUI は Executive Order 13556 によって制定され、32 CFR Part 2002 において成文化されました。これにより、FOUO、LES、SBU などの従来のバラバラなマーキングを、連邦各機関およびその請負業者全体にわたって「機密ではないが機微な情報」を保護するための、単一で一貫した枠組みに置き換えました。

プログラム全体を支える重要な原則があります。連邦法、規則、または政府全体に適用される方針に基づいて保護が必要な情報のみが CUI として指定できます。機関は、管理上の好みだけを理由に CUI のカテゴリを作成することはできません。

CUI は、取り扱いの2つのカテゴリに分かれます。

• CUI Basic がデフォルトです。NARA CUI Registry がカテゴリを CUI Specified として特に注記していない限り、32 CFR Part 2002 の一律の基準がすべての CUI に適用されます。バナーマーキングは CUI または CUI//PRVCY のように見えます。
• CUI Specified は、承認する法律または規則に、CUI Basic のデフォルトと異なる具体的な取り扱い管理が含まれている場合に適用されます。これらのカテゴリには「SP-」という接頭辞が付きます（例：CUI//SP-CTI）。

違いは、感度レベルではなく管理（統制）措置の出どころにあります。CUI Basic は、特定の権限機関が沈黙している部分を補完します。

NARA CUI Registry は権威ある情報源であり、125 を超えるカテゴリを網羅しています。契約者は、遭遇したあらゆる CUI について、適切な分類、マーキング、および取り扱いを判断するためにここを参照する必要があります。

CUIのよくある例

すべての 機微なデータ が CUI であるわけではありません。CUI Registry に掲載されている権限（authority）に紐づけられている必要があります。主要なカテゴリにおけるよくある CUI の例は以下のとおりです：

• 防衛（CTI）： 制御対象の技術情報（CTI）には、技術図面、システム設計文書、軍事用途向けに開発されたソースコードが含まれます。DFARS 252.204-7012 の権限のもとで CUI//SP-CTI としてマーキングされます。
• 輸出管理： 米国の軍需品リスト（U.S. Munitions List）に掲載されている防衛用資材に関する技術図面、および輸出ライセンスの対象となる技術データは、CUI Registry の輸出管理カテゴリでカバーされています。
• 法執行： 犯罪歴記録情報、DNA プロファイル、情報提供者の識別データは、法執行関連の CUI カテゴリに該当します。
• プライバシー： 社会保障番号、金融口座番号、生体データ、そして HIPAA 対象となる健康情報は、プライバシー／ヘルス関連の CUI カテゴリで取り扱われます。
• 重要インフラ： 化学テロの脆弱性情報、重要なエネルギー・インフラ情報、そして情報システムの脆弱性情報は、重要インフラのカテゴリに該当します。

これらの例は参考であり、確定的なものではありません。取り扱いルールを設定する前に、CUI Registry と契約文言で、該当するカテゴリ、権限、および必要な標記を必ず確認してください。

CUI保護の主要な要件

CUIの保護は、ファイルをロックダウンすることだけではありません。CUIの保護には、マーキング、物理的およびデジタルの保護、さらに誰が情報にアクセスし、共有できるかを制御することが含まれます。これらはいずれも特定の連邦要件を伴い、いずれか一つでも欠けると、あなたのコンプライアンス体制全体を損なう可能性があります。ここでは、3つの主要な保護の柱にまたがって、正しく整える必要があるポイントを紹介します。

CUIのマーキングとラベリング

一貫性のないマーキングは、コンプライアンス評価に失敗する最も速い方法の一つです。マーキングは、CUIの取り扱いに関わる一連の流れ全体を左右します。つまり、承認された保有者に対して、誰が情報にアクセスできるのか、どのように共有できるのか、そしてどの保護が適用されるのかを示します。

標準的なマーキング例：

• カテゴリなしの CUI Basic：CUI
• 指定された CUI：CUI//SP-CTI
• 伝達制御付きで指定された CUI：CUI//SP-SGI//FEDONLY

実務では、正確なバナーマーキングに加えて、一貫した下流でのラベリング（メールの件名、ファイルヘッダー、カバーページ、リポジトリ）が、CUIが管理されていないチャネルへ漏えいするのを防ぎます。

すべての CUI 文書には、主管機関（controlling agency）を特定する指定表示（designation indicator）を含める必要があります。ガイダンスでは、メールに CUI が含まれる場合、メールの件名行および本文にも CUI のバナーマーキングを適用することが推奨されています。

保護と制御された環境

CUIは、十分な アクセス制御 と、不正な閲覧や盗聴に対する保護を備えた制御された環境で取り扱わなければなりません。

NIST SP 800-171 Rev. 1 は基準を示しました。CUIの機密性への影響値は、FIPS 199のmoderate（中程度）以上である必要があります。FIPS 199によれば、moderateとは「機密性の喪失が、組織の業務、組織の資産、または個人に対して重大な悪影響を及ぼすことが見込まれる」ことを意味します。

組織は、System Security Plan (SSP) の中で、運用環境、要求事項がどのように実装されるか、他のシステムとの接続を含めて、CUIシステムの境界を説明しなければなりません。

物理的セキュリティの要件には、許可された人のみへのアクセスを制限すること、来訪者に付き添うこと、アクセス監査ログを維持すること、ならびに代替の作業拠点で保護策を適用することが含まれます。

アクセス制御および伝達（配布）制御

CUI へのアクセスは明確な原則に従います。つまり、正当な need-to-know（知る必要性）があり、適切なトレーニングを受けた許可されたユーザーのみがアクセスできます。

NIST SP 800-171 Rev. 3 はアカウント管理を強化し、許可されたアカウント種別を定義すること、正当な need（必要性）と意図した使用目的に基づいてアクセスを承認すること、システムアカウントの使用を継続的に監視することを求めています。

「32 CFR 2002.16 」に従い、伝達（配布）は、CUI のカテゴリーを定めた法律に従うこと、合法な政府目的をさらに推進すること、かつ認可された限定的な伝達管理によって制限されないことが求められます。

外部の当事者と CUI を共有する前に、受領者に正当な need-to-know（知る必要性）があること、CUI の要件を理解していること、そして情報を適切に保護できることを確認してください。

ここでもトレーニングは重要です。2025年1月の FAR CUI 規則では、契約者は、従業員が適切なトレーニングを完了していない限り、その従業員に CUI を取り扱わせてはならないと定めています。また契約者は、要請があった場合にトレーニングの証拠を提示する必要があります。

CUI とサイバーセキュリティのフレームワーク

CUI 保護の義務は、単独で存在するものではありません。これは、政策上の要件を具体的で監査可能なセキュリティ管理策へと落とし込む、連邦のサイバーセキュリティ・フレームワークの多層的な積み重ねの中に位置しています。

これらのフレームワークがどのようにつながっているのかを理解することは、特に異なる契約が異なる改訂版やベースラインを参照している場合に、準拠した環境を構築するために不可欠です。

NIST SP 800-171 と CUI

NIST SP 800-171 は、CUI 保護の義務を、非連邦システム向けの具体的なセキュリティ要件に落とし込んでいます。現在のバージョンである Rev. 3 には、17 の制御ファミリーにまたがる 97 のセキュリティ要件が含まれています。Rev. 2 には、14 のファミリーにまたがる 110 の要件がありました。

CUI の取り扱いに直接影響する主要領域には、次のものがあります。

• アクセス制御： アカウント管理、最小権限、職務の分離、情報フロー制御
• 監査および説明責任： イベントの種類、タイミング、発信元、結果、および識別情報を記録する監査ログ。保管期間は、組織および契約要件に合わせる
• インシデント対応： 組織が定義した頻度で、運用上の対応能力、追跡、およびテストを実施する
• メディア保護： 廃棄前のサニタイズ、輸送中の暗号学的保護

これらの領域をまとめると、CUI の取り扱いが実際に運用として強制されているか（単に文書化されているだけではないか）を監査人が評価する際に確認する、日々の運用上の統制が定義されます。

FIPS 199 の影響レベルと CUI

コンプライアンスの“カスケード（段階的な展開）”は次のように機能します。FIPS 199 が影響レベルを分類し、FIPS 200 が最低限のセキュリティ要件を定め、統制の選定は NIST のセキュリティ管理基線（baseline）から導き出されます。そして、それらの基線を CUI を取り扱う非連邦組織向けに調整したものが NIST SP 800-171 です。

実務上の影響は大きいです：

• クラウドホスティング: クラウド環境における CUI システムでは、FedRAMP Moderate は中程度の影響を与える情報システムに対する最低限の適切なベースラインとして広く扱われています。
• 暗号化: 暗号モジュールは、FIPS 承認済みアルゴリズムを使用しているだけでは不十分で、FIPS 140-2 の検証済みである必要があります。NIST の CMVP ガイダンスでも、検証されていない暗号化は防御を提供しないものと見なされるとされています。
• ネットワーク保護: 中程度のベースラインには、アクセス制御、境界防御、ネットワークの分離、伝送時の機密性と完全性、およびネットワーク監視が含まれます。

重要なプログラムまたは High Value Assets に関連する CUI については、NIST SP 800-172 により強化されたセキュリティ要件が示されていますが、これらは契約条文で明示的に指定されている場合に限り適用されます。

CUI を安全に取り扱うためのベストプラクティス

以下のベストプラクティスは、CUI のコンプライアンス義務を、チームが実行できる具体的な手順へと落とし込みます。初期のデータ発見から、アクセスガバナンス、暗号化、インシデント対応までをカバーします。

1. CUI を正確に特定し、分類する

CUI として情報を指定できるのは連邦政府機関のみです。契約者が、潜在的に未標記の CUI に遭遇した場合、自ら標記するのではなく、公式な判断のために契約担当官（contracting officer）へ報告してください。FAR の CUI ルールでは、潜在的な CUI の発見を 8 時間以内に報告することが求められます。

まずは契約ごとの見直しから始めます。各契約書に指定されている CUI のカテゴリを、実際の情報フローに照らし合わせてマッピングしてください。よくあるスコープ設定上の失敗には、次のようなものがあります。

• 見落とされたシステム： 主な環境の外で CUI を処理しているシステムを見落としてしまう
• サードパーティの見落とし： あなたの代わりに CUI に触れるサービスプロバイダーを考慮しないこと
• シャドーIT： 協業ツールやクラウドサービスのことを忘れてしまい、CUI がそこに入り込む可能性を見落とすこと

トレーニングも同じくらい重要で、次の3つのレベルで実施する必要があります：

• ユニバーサル・アウェアネス： CUI に遭遇する可能性のあるすべての人を対象に
• ロール（役割）別トレーニング： 定期的に CUI を取り扱う従業員を対象に
• 高度な技術トレーニング： CUI 環境を管理するシステム管理者向け

研修への投資は非常に重要です。なぜなら、人為的要因が依然として最大の脆弱性であるためです。 Netwrix 2024 Hybrid Security Trends Report によると、IT プロフェッショナルの 47% が、従業員のミスや不注意を最優先のセキュリティ課題として挙げています。

発見（識別）という課題も同様に広く見られます。Netwrix がスポンサーとなった 2025 SANS Attack Surface Management (ASM) Survey では、ASM プラットフォームが機密ファイルを効果的に特定できていると考える組織は 28% だけで、別の 41% は「部分的にしかできていない」と回答していました。

ここでツールが実際の違いを生みます。例えば First National Bank Minnesota は Netwrix Auditor と Netwrix Data Classification を使って、機密データを発見・分類し、安全な場所へ移動しました。また、Active Directory の再構築を 6 か月ではなく 3 週間で完了しています。

2. オブジェクト（対象）レベルでアクセスを統制する

フォルダー レベルおよびサイト レベルの権限は、CUI に対して十分な粒度を備えていません。NIST SP 800-171 では、CUI の保護を強化するために、アプリケーションおよびサービス レベルでアクセス強制メカニズムを実装できることが認められています。

NIST SP 800-162 で定義されている属性ベースのアクセス制御（ABAC）は、すべてのアクセス要求ごとに、ユーザー、データ、および環境の属性を、定義されたポリシー ルールと照合して評価します。CUI にとっての利点は、動的な最小権限です:

• 役割の変更: ミッションの割り当てが変わると、更新されたサブジェクト属性を通じて、もはや不要になった CUI へのアクセスが自動的に取り消されます
• 分類の変更: データ分類が変わると、影響を受けるすべてのユーザーに対して、手動の再設定なしでアクセス制限が調整されます

3. 送信中および保存中の CUI を暗号化する

NIST SP 800-171では、受制御環境の外部で送信または保存される CUI に暗号化が必要です。保護された環境内では、他の対策によって要件を満たす場合もありますが、その境界を離れる CUI はすべて暗号化されなければなりません

重要な要件は、暗号化モジュールが FIPS 140-2 の検証を受け、証明書番号を文書化しておく必要があることです。特定のモジュールが NIST の Cryptographic Module Validation Program を通過していない場合、単に AES-256 を使うだけでは不十分です。

キー管理にも同等の注意が必要なので、後回しにするものではなく基盤となるインフラとして扱うべきです。

4. インシデントを監視し、ログを記録し、対応する

NIST SP 800-171では、イベントの種類、タイミング、場所、発生元、結果、および関連するアイデンティティを捕捉する監査記録が必要です。個々のユーザーの行動は一意に追跡可能である必要があり、監査記録の保管期間は、組織が定める要件および契約が定める要件に合わせるべきです。

インシデント対応では、タイムラインがますます厳しくなっています。業界によって適用される報告義務は異なります:

• FAR CUI ルール: 疑わしい、または確認された CUI インシデントを報告するための 8時間の猶予
• DFARS 252.204-7012: DoD の請負業者は DIBNet を通じて報告
• CIRCIA: 重要インフラ（critical infrastructure）の事業体は 72時間以内に CISA へ報告

これらのタイムラインを満たすには、検知だけでなく、フォレンジック能力と事前に確立された調査手順が必要です。

ここでは、アクティビティ データとアクセス許可を相関付けることが大きな成果につながります。現実の環境では、ファイル変更における不審なスパイクがたった1回でも、チームが切り離されたログをつなぎ合わせて答えを見つけなければならないと、数日間に及ぶ大混乱になり得ます。

Netwrix が組織の CUI 保護を支援する方法

CUI のコンプライアンスが一夜にして実現する単一のプロセスやチェックリストはありません。請負業者にとっての課題は、評価者が見つけることになる“抜け”が生じてしまうような、切り離されたツール同士をつなぎ合わせることなく、データの発見、アクセス管理、監査の準備状況の間にあるつながりを見出すことです。

環境が、オンプレミスのファイル サーバー、Active Directory、そして Microsoft 365 を混在させた Microsoft インフラで動いている場合は、それらすべてを 1 か所からカバーできるプラットフォームが必要です。

The 1Secure Platform は、ファイル システム、データベース、コラボレーション プラットフォーム、クラウド ストレージにわたる自動的な検出を提供するため、評価者より先に CUI 関連データを見つけられます。

セキュリティが不十分な場所にある機密ファイルを隔離し、安全な領域へ移動し、過剰な権限を削除し、 classification tags をファイルに埋め込むことで、数週間の手作業による棚卸しを、自動化された反復可能なプロセスに変えます。

しかし、発見（検出）だけでは不十分です。難しいのは次の問いです。誰がそのデータにアクセスできるのか、そのアクセスは適切なのか、そしてそれを証明できるのか。1Secure Platform は、過度に露出している機密データオブジェクト、分類コンテンツの詳細な権限構造、機密ファイルやフォルダに関連するアクティビティをレポートします。

つまり、権限が過剰になっている状態でCUIがどこに存在しているかを特定し、それが監査で指摘される前に是正できます。

Netwrix Endpoint Protector はその適用範囲をエンドポイント層まで拡張し、未承認の経路を通じてCUIが管理された環境から外部へ出ることを防ぎます。未承認のUSBデバイスへの転送をブロックし、ブラウザ、メールクライアント、クラウドストレージアプリケーション経由のアップロードを監視・制御します。さらに、承認済みのリムーバブルメディアに対して暗号化を強制し、CUIの取り扱い要件が防ぐよう設計されたデータ持ち出し（エクフィルレーション）のリスクに直接対処します。

あらかじめ用意されたコンプライアンスレポートでは、誰がデータにアクセスしたのか、何が変更されたのか、いつ変更されたのかが分かります。一方、インタラクティブ検索により、監査担当者の質問に数日ではなく数分で回答できるようになります。

Netwrix のデモを依頼する ハイブリッド環境全体で CUI を検出、保護し、コンプライアンスを証明する方法を、1つのプラットフォームで確認できます。