CUI Boundaryは、CUIを扱うシステムの範囲を決めるための言葉として使われます。しかし、本当に重要なのは、境界線をどこに引くかではありません。CUIがどこで発生し、どこを通り、どの資産によって保護され、誰の責任で管理されているのかを説明できることです。

はじめに

CMMC対応で最初に迷うのは、「どこまでが対象なのか」です。ファイルサーバーだけなのか。Microsoft 365まで含むのか。設計用ワークステーションは含むのか。EDR、IdP、SIEM、バックアップ、管理者端末、MSPはどう扱うのか。

この問いに答えるための中心概念が、CUI Boundaryです。

ただし、CUI Boundaryを「CUIフォルダの場所」や「ネットワークセグメント」として理解すると、ほぼ必ず判断を誤ります。CUI Boundaryは、単なる保存場所ではありません。CUIを処理・保存・送信する資産、その資産を保護する仕組み、CUIに到達できる管理経路、ログや設定情報を扱う外部サービスまで含めて考える必要があります。

結論

CUI Boundaryとは、CUIを処理・保存・送信する資産と、それを保護するために必要な資産・運用・責任範囲を、評価可能な形で整理した境界です。

CMMCの文脈では、CUIを扱う資産だけでなく、CUI環境にセキュリティ機能を提供する資産も重要です。32 CFR Part 170では、CMMC Programが、FCIまたはCUIを処理・保存・送信する contractor information systems だけでなく、それらのシステムにセキュリティ保護を提供するシステム、またはそれらと論理的・物理的に分離されていないシステムに対する評価要件を扱うと説明されています。

つまり、CUI Boundaryは「CUIが置いてある場所」ではなく、CUIを守るための構造全体です。

CUI BoundaryとCMMC Assessment Scopeの違い

実務では、CUI BoundaryとCMMC Assessment Scopeを近い意味で使うことがあります。ただし、厳密には分けて考えた方がよいです。

CUI Boundaryは、CUIが存在し、移動し、アクセスされ、保護される範囲を理解するための設計上の考え方です。

CMMC Assessment Scopeは、CMMC評価で実際に対象として扱われる資産の範囲です。

CMMC Level 2では、資産を次のように分類して考えます。

資産分類 意味
CUI Asset CUIを処理・保存・送信する資産
Security Protection Asset CUI環境にセキュリティ機能を提供する資産
Contractor Risk Managed Asset CUIを処理できる可能性はあるが、方針・手順・運用で処理しないよう管理されている資産
Specialized Asset OT、IoT、試験装置、GFEなど、完全には通常のIT要求を適用しにくい資産
Out-of-Scope Asset CUIを処理・保存・送信できず、CUI Assetを保護する機能も持たない資産

ここで重要なのは、Out-of-Scopeにしたい資産は、「CUIを扱わないつもり」では不十分だということです。CUIを処理・保存・送信できないこと、またはCUI Assetから物理的・論理的に分離されていることを説明できなければなりません。

境界はネットワークではなく、説明責任で決まる

多くの企業は、境界をネットワーク図で表そうとします。もちろんネットワーク図は必要です。しかし、ネットワーク図だけではCUI Boundaryは説明できません。

なぜなら、CUIはネットワークだけを流れるわけではないからです。

メール、チャット、クラウドストレージ、PLM、CAD、CI/CD、バックアップ、ログ、エクスポート、スクリーンショット、ローカルキャッシュ、VDI、管理者セッション、API連携。CUIは、業務の流れに沿って移動します。

したがって、境界を決めるときは、次の問いに答える必要があります。

  • CUIはどこで受領されるのか
  • CUIはどこで作成されるのか
  • CUIはどこに保存されるのか
  • 誰が閲覧・編集・ダウンロードできるのか
  • CUIはどの経路で社外へ送信されるのか
  • CUIを保護するID、MFA、EDR、SIEM、DLP、鍵管理はどこにあるのか
  • それらの保護資産を誰が管理しているのか
  • ログや設定情報にCUIまたはSecurity Protection Dataが含まれるのか
  • 外部サービスプロバイダーやMSPはどの情報にアクセスできるのか

CUI Boundaryは、これらの問いに対する答えの集合です。

日本企業で起きやすい境界の曖昧さ

日本企業では、CUI Boundaryが特に曖昧になりやすい構造があります。

第一に、米国子会社と日本本社の関係です。米国子会社がDoD関連契約を持ち、日本本社がIT管理、ID管理、SOC、ヘルプデスク、ネットワーク、クラウド管理を支援している場合、日本本社がCUIを直接開いていなくても、CUI環境を保護する側に入る可能性があります。

第二に、設計・製造・品質保証の分業です。設計データは米国側、製造指示は日本側、検査データは別拠点というように、CUIに該当し得る情報が工程ごとに分散することがあります。この場合、「CUIは米国にある」という説明だけでは不十分です。どの工程で、どのデータが、どのシステムへ渡るのかを追う必要があります。

第三に、MSPや外部SOCの利用です。MSPがCUI本文を扱わなくても、CUI環境のログ、設定、脆弱性情報、管理者権限を扱う場合、そのサービスはCMMC上のスコープ判断に関係します。32 CFR Part 170では、External Service ProviderがCUIまたはSecurity Protection Dataを処理・保存・送信するかを考慮し、その関係やサービス内容をSSPおよびCustomer Responsibility Matrixに文書化することが求められます。

CUI Boundaryを小さくするという発想

CUI Boundaryは、大きければ安全というものではありません。むしろ、必要以上に大きい境界は、評価対象、運用負荷、証跡管理、アクセス制御、教育、ログ管理をすべて膨らませます。

重要なのは、CUIを守る場所を限定することです。

例えば、全社のファイルサーバーやメールボックスにCUIが散らばっている状態では、境界を絞ることができません。一方、CUIを扱うリポジトリ、専用ワークスペース、承認済み端末、専用アカウント、制御された共有経路に集約すれば、境界は説明しやすくなります。

境界を小さくする設計では、次のような考え方が有効です。

  • CUIを保存できる場所を限定する
  • CUIを扱える端末を限定する
  • CUIを扱うIDと権限を限定する
  • CUIの社外共有経路を限定する
  • CUIを扱わない一般業務環境と分離する
  • CUIに関係するログ、バックアップ、鍵、管理経路を明確にする
  • 外部サービスの責任範囲を文書化する

これは、単に「分離する」という話ではありません。守る対象を小さくし、説明できる状態にするという設計判断です。

境界設計で確認すべき実務ポイント

CUI Boundaryを設計するときは、最初に次の確認を行います。

確認項目 見るべきポイント
契約 CUI、CDI、DFARS、CMMC Level、flowdownの有無
情報 CUIカテゴリ、マーキング、配布制限、輸出管理との関係
データフロー 受領、作成、保存、編集、送信、削除、アーカイブ
システム ストレージ、端末、ID、ネットワーク、バックアップ、ログ、SIEM
保護資産 EDR、MFA、IdP、DLP、暗号鍵、管理者端末
外部サービス CSP、MSP、SOC、開発委託先、サポートベンダー
証跡 SSP、資産台帳、ネットワーク図、CRM、運用ログ

この整理をしないまま製品を選んでも、CMMC対応は進みません。境界が曖昧なままでは、どの要求を誰が実装しているのかを説明できないからです。

よくある誤解

最も多い誤解は、「CUI専用フォルダを作ればCUI Boundaryができる」というものです。フォルダは保存場所の一部にすぎません。そこへアクセスする端末、ID、管理者、ログ、バックアップ、共有経路、権限変更の運用まで見なければ、境界は成立しません。

次に多い誤解は、「クラウドに置けばクラウド事業者の責任になる」というものです。クラウドは責任分界を変えるだけで、顧客側の責任を消すわけではありません。CSPの責任、顧客の責任、MSPの責任はSSPとCRMで説明する必要があります。

もう一つの誤解は、「暗号化すればCUI Boundaryの外に出せる」というものです。暗号化は重要な保護手段ですが、暗号化されたことだけで自動的にCUI判断やスコープ判断が消えるわけではありません。鍵、復号権限、メタデータ、アクセス経路、運用責任まで含めて判断する必要があります。

本質

CUI Boundaryの本質は、線を引くことではありません。

CUIを扱う組織が、どの情報を、どのシステムで、どの権限で、どの保護機能により、誰の責任で守っているのかを説明できる状態にすることです。

CUI Boundaryが曖昧な組織では、CUIの保護も曖昧になります。逆に、境界が明確な組織では、技術、運用、契約、責任分界を同じ地図の上で議論できます。

CMMC対応の出発点は、チェックリストではありません。CUI Boundaryを描くことです。

深掘り：CUI Boundaryとは何かを実務判断に落とす

CUI Boundaryは、CUIが存在する場所を囲む線ではなく、CUIを処理・保存・送信する資産と、それを保護するために機能する資産を識別するための判断枠組みです。境界を引く目的は、できるだけ広く囲うことではなく、評価対象、管理対象、責任対象を説明できる形にすることです。

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

境界が曖昧なまま運用すると、CUI AssetとSecurity Protection Assetの区別が崩れます。その結果、実際にはCUIに影響するIdP、EDR、ログ基盤、バックアップ、管理端末がSSPから抜け落ち、評価時に「なぜこの資産がスコープ外なのか」を説明できなくなります。

このため、設計時には「対象を狭く見すぎていないか」と「責任を広く曖昧にしすぎていないか」の両方を確認します。前者はスコープ漏れを生み、後者は運用不能な過大スコープを生みます。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、バックアップ、管理端末、ネットワーク制御も、判断対象に入ることがあります。

境界設計では、CUIの保管場所、アクセス経路、管理経路、ログ経路、バックアップ経路を別々に描き、どの経路がCUIそのものを扱い、どの経路が保護機能を担うのかを分けて考えます。

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

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

日本本社が米国子会社のMicrosoft 365、Entra ID、Intune、Sentinelを管理しているケースでは、CUIファイルを直接開いていなくても、日本側の管理者権限や運用プロセスがCUI環境の保護に影響することがあります。

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

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

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

SSP、資産台帳、データフロー図、ネットワーク図、ID権限一覧、管理者ロール一覧、外部サービス一覧を相互に整合させることが証跡の中心になります。

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

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

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

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

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

運用成熟度の見方

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

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

組織間の責任分界

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

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

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

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

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

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

確認すべき問い

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

次に読む記事

次は「暗号化されたCUIはCUIではないのか」です。CUI Boundaryを考えるうえで、暗号化されたデータをどう扱うかは避けて通れません。

参考資料