暗号化はCUI保護において非常に重要です。しかし、暗号化されたからといって、CUIが自動的にCUIでなくなるわけではありません。暗号化はCUIを消すものではなく、CUIを保護された状態に置くための手段です。

はじめに

CUI対応でよく出る質問があります。

「暗号化されたCUIは、もうCUIではないのか」

この問いは、実務上とても重要です。もし暗号化によってCUIではなくなるのであれば、クラウドストレージ、バックアップ、転送経路、外部委託、ログ管理の考え方が大きく変わります。しかし、この問いに単純な答えを出すのは危険です。

結論から言えば、暗号化はCUIの保護手段であって、通常はCUI性を消すものではありません。暗号化されたCUIをどう評価するかは、暗号化方式、鍵の管理、復号可能性、メタデータ、契約条件、CUI指定元の指示、CMMC評価範囲によって判断する必要があります。

結論

暗号化されたCUIは、原則として「保護されたCUI」と考えるべきです。

暗号化は、CUIへの不正アクセスを防ぐための強力な保護策です。しかし、暗号化されたことだけを理由に、「これはCUIではない」「スコープ外である」「契約上の保護義務が消える」と判断するのは危険です。

CUIは、政府が作成・保有する情報、または政府のために作成・保有する情報であり、法律・規則・政府全体方針により保護または配布制限が求められる情報です。暗号化は、この保護または配布制限を実現する一手段です。暗号化によって情報の意味や契約上の性質が消えるわけではありません。

なぜこの誤解が起きるのか

この誤解が起きる理由は、暗号化されたデータが人間には読めないからです。

たしかに、適切に暗号化されたファイルは、鍵を持たない者から見ると意味のない文字列です。クラウド事業者、ネットワーク中継者、バックアップ媒体の管理者が平文を読めない設計にすることは、スコープとリスクを考えるうえで重要です。

しかし、CUIの判断は「第三者が読めるかどうか」だけで決まりません。

重要なのは、誰が復号できるのか、どこで復号されるのか、鍵を誰が管理しているのか、復号後のデータがどのシステムで処理されるのか、暗号化データのメタデータやファイル名にCUI性を示す情報が含まれるのか、という点です。

つまり、暗号化されたCUIの判断は、暗号文だけを見るのではなく、暗号化の運用全体を見る必要があります。

暗号化で変わるものと変わらないもの

暗号化によって変わるものは、主にアクセス可能性とリスクです。

鍵を持たない主体は、平文の内容を読むことができません。通信中や保存中に第三者がデータを取得しても、適切に暗号化されていれば内容の漏えいリスクは低くなります。クラウドや外部委託の設計では、この点が非常に重要です。

一方で、暗号化しても変わらないものがあります。

  • 元の情報がCUIに該当するという性質
  • 契約上の保護義務
  • 復号権限を持つユーザーやシステムの責任
  • 鍵管理の責任
  • 復号後の処理・保存・送信に対する要求
  • CUIのマーキングや配布制限に関する判断

暗号化は、「CUIをなくす」のではなく、「CUIを読めない状態にする」技術です。この違いを曖昧にすると、設計も契約判断も危うくなります。

サーバー側暗号化とクライアント側暗号化を分ける

暗号化されたCUIを考えるときは、少なくともサーバー側暗号化とクライアント側暗号化を分ける必要があります。

サーバー側暗号化は、クラウドストレージやデータベースなどのサービスが保存時に暗号化を行う方式です。多くのクラウドサービスでは保存データが標準で暗号化されます。Azure Storageでも、新しいストレージアカウントのデータは既定でMicrosoft管理キーにより暗号化され、顧客管理キーや暗号化スコープを選べる構造が用意されています。

サーバー側暗号化は重要ですが、サービスが通常の読み書き処理で平文を返せる場合、そのサービスはCUIを処理・保存・送信する環境として扱われる可能性があります。

一方、クライアント側暗号化は、データをクラウドへアップロードする前に、利用者側のアプリケーションで暗号化する方式です。鍵を顧客側で管理し、クラウド側が平文にアクセスできない設計にできる場合があります。Azure Blob Storageのクライアント側暗号化でも、クライアントライブラリがアップロード前にデータを暗号化し、Key Vaultなどと連携して鍵管理を行う構造が説明されています。

ただし、クライアント側暗号化でも、CUI判断が消えるわけではありません。復号する端末、復号権限を持つID、鍵管理システム、復号後の保存場所、ログ、バックアップが新たに重要になります。

鍵は境界の一部である

暗号化を境界設計に使うなら、鍵管理を境界の中心に置く必要があります。

暗号化されたファイルだけを見ても、保護状態は判断できません。鍵が誰に配布され、どこに保存され、どの条件で使われ、誰がローテーションし、誰が失効できるのかを見なければなりません。

実務では、次の観点を確認します。

観点 確認内容
鍵の所有 Microsoft管理キー、顧客管理キー、顧客提供キー、ローカル鍵のどれか
鍵の保管 Key Vault、HSM、専用KMS、端末内、個人管理のどれか
復号権限 誰が、どの条件で復号できるか
ローテーション 鍵を誰が、どの周期で更新するか
失効 退職者、委託終了、契約終了時に復号権限を止められるか
監査 鍵操作、復号、アクセス要求を記録できるか
分離 CUIと非CUI、契約ごと、顧客ごとに鍵を分けられるか

鍵管理が弱い暗号化は、境界設計としては弱いです。

メタデータも見落としてはいけない

暗号化された本文が読めなくても、ファイル名、フォルダ名、オブジェクトキー、タグ、検索インデックス、サムネイル、プレビュー、ログ、監査イベント、メール件名、チャット本文、チケット情報にCUI性を示す情報が残ることがあります。

たとえば、本文は暗号化されていても、ファイル名に兵器システム名、部品番号、契約番号、試験名、図面番号が入っていれば、それ自体が管理対象情報になり得ます。

暗号化を過信してはいけない理由はここにあります。CUIを守るとは、ファイル本文だけでなく、周辺情報も含めた保護状態を設計することです。

CMMCスコープへの影響

CMMCのスコープ判断では、CUIを処理・保存・送信する資産が中心になります。加えて、CUI環境にセキュリティ機能を提供する資産、Security Protection Dataを扱う資産、CUI環境と分離されていない資産も問題になります。

暗号化されたデータを保存しているシステムがスコープに入るかどうかは、単に「暗号化されているか」ではなく、次の要素を見て判断します。

  • そのシステムが平文CUIを処理するか
  • そのシステムが復号機能を持つか
  • 鍵が同じ環境に存在するか
  • ユーザーがその環境でCUIを閲覧・編集するか
  • そのシステムがCUI環境を保護する機能を提供するか
  • ログや設定情報がSecurity Protection Dataに該当するか
  • 契約上、そのサービスをどのように扱うよう指定されているか

暗号化はスコープを整理するための重要な手段ですが、スコープから外すための魔法の言葉ではありません。

よくある誤解

「暗号化されているのでクラウド事業者は関係ない」という理解は不十分です。サーバー側暗号化では、サービスが平文を返す前提で動いていることがあります。クラウド事業者の認証状態、顧客側設定、責任分界、CRM、SSPへの記述が必要になります。

「パスワード付きZIPなら十分」という理解も危険です。パスワードの共有、強度、失効、監査、鍵管理、復号後の保存先が管理されていなければ、CUI保護の設計とは言えません。

「暗号化すればマーキングしなくてよい」という理解も誤りです。マーキングは、保有者にCUIの存在と取り扱いを知らせるための仕組みです。NARAのCUI Marking Handbookも、マーキングがCUIの存在や保護対象部分を知らせる役割を持つことを説明しています。暗号化はマーキングや契約上の指示を置き換えるものではありません。

実務上の判断フロー

暗号化されたCUIを扱う場合は、次の順に整理します。

  1. 元の情報がCUIかどうかを確認する
  2. 契約、マーキング、CUI Registry、顧客指示を確認する
  3. 暗号化方式を確認する
  4. 鍵を誰が管理しているか確認する
  5. 復号できる主体と条件を確認する
  6. 復号後にCUIが流れるシステムを確認する
  7. メタデータ、ログ、バックアップを確認する
  8. CSP、MSP、SOCの責任分界を確認する
  9. SSP、資産台帳、データフロー図、CRMへ反映する

この順番で見れば、暗号化を過小評価することも、過大評価することも避けられます。

本質

暗号化されたCUIは、CUIではなくなった情報ではありません。保護手段が適用されたCUIです。

暗号化の本質は、境界を消すことではなく、境界を技術的に強化することにあります。CUIを誰が読めるのか。どこで復号されるのか。鍵を誰が管理するのか。復号後の情報がどこへ流れるのか。

この問いに答えられる組織だけが、暗号化をCUI保護の設計として使えます。

深掘り：暗号化されたCUIはCUIではないのかを実務判断に落とす

暗号化されたCUIを「CUIではない」と扱うかどうかは、暗号化の有無だけでは決まりません。重要なのは、復号権限、鍵管理、処理状態、アクセス制御、契約上の保護義務がどこに残っているかです。

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

暗号化をデータ分類の解除条件のように扱うと、鍵を持つ管理者、復号可能なアプリケーション、一時ファイル、検索インデックス、ログ、DLPイベント、バックアップが見落とされます。暗号化は保護手段であって、必ずしもスコープを消す手段ではありません。

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

暗号化方式を評価するときは、保存時暗号化、転送時暗号化、ファイル単位暗号化、アプリケーション層暗号化、クライアント側暗号化を分けて考えます。どの方式がどのリスクを低減し、どのリスクを残すのかをSSPで説明する必要があります。

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

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

日本企業では、米国側から受け取った技術図面を暗号化ZIPやIRM付きファイルで共有することがあります。このとき、ファイル本体が暗号化されていても、受信者端末、復号後の閲覧環境、鍵配布、添付メール、監査ログがCUI保護の論点になります。

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

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

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

鍵の所有者、鍵の保管場所、復号可能な主体、アクセスログ、復号操作の記録、例外時の鍵回復手順が証跡になります。

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

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

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

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

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

運用成熟度の見方

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

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

組織間の責任分界

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

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

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

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

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

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

確認すべき問い

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

次に読む記事

次は「CUIデータフロー設計」です。暗号化を正しく位置づけるには、CUIがどこからどこへ流れるのかを先に把握する必要があります。

参考資料