ファイルレベル暗号化とCMMC

ファイルレベル暗号化は、CUIをデータ単位で保護するための有力な手段です。ただし、ファイルを暗号化しただけでCMMC対応が完了するわけではありません。鍵、権限、ログ、復号後の利用、責任分界まで含めて設計しなければ、暗号化は単なる機能で終わります。

はじめに

CUIを守るために、ファイルレベル暗号化を検討する企業は多いです。クラウドストレージ、メール、外部共有、委託先とのデータ交換、ノートPCの持ち出しを考えると、ファイルそのものを保護したいという発想は自然です。

ファイルレベル暗号化は、CUI保護において非常に有効です。ネットワーク境界やストレージ境界を越えても、ファイル自体に保護を持たせることができるからです。

しかし、CMMCの文脈では、ファイルレベル暗号化を「万能の解決策」として扱うべきではありません。暗号化は、アクセス制御、鍵管理、監査、運用、責任分界と結びついて初めて意味を持ちます。

結論

ファイルレベル暗号化は、CMMC対応において有効な保護手段です。ただし、単独ではCMMC対応になりません。

CMMCで問われるのは、「暗号化機能を使っているか」ではなく、CUIを扱う情報システムが要求事項に沿って保護されているかです。CUIを処理・保存・送信する資産、CUI環境にセキュリティ機能を提供する資産、外部サービス、ログ、鍵管理、運用手順を含めて説明できる必要があります。

ファイルレベル暗号化は、CUI Boundaryを小さくし、外部共有時のリスクを下げ、データ中心の保護を実現するための強力な部品です。しかし、それは設計全体の中で位置づけるべき部品です。

ファイルレベル暗号化とは何か

ファイルレベル暗号化とは、ストレージ全体やディスク全体ではなく、ファイル単位で暗号化を行う考え方です。

暗号化の対象は、文書、図面、CADファイル、PDF、ソースコード、試験データ、CSV、圧縮ファイルなどです。暗号化されたファイルは、保存場所や転送経路を移動しても、復号権限を持たない主体には内容を読みにくくなります。

ファイルレベル暗号化は、次のような場面で有効です。

社外とのファイル共有
クラウドストレージ利用
メール添付の代替または補強
委託先とのデータ交換
端末紛失時の情報漏えい対策
契約終了後のアクセス失効
プロジェクト単位のCUI隔離

ただし、「ファイルが暗号化されている」という事実だけでは十分ではありません。誰が復号できるのか、復号後にどこへ保存されるのか、復号操作がログに残るのか、鍵を誰が管理するのかを確認する必要があります。

ディスク暗号化、ストレージ暗号化、ファイル暗号化の違い

暗号化と一口に言っても、実務では複数の層があります。

種類	主な対象	特徴
ディスク暗号化	端末やサーバーのディスク	紛失・盗難対策として有効。ただしログイン後のファイル利用は別途制御が必要
ストレージサービス暗号化	クラウドストレージやデータベース	保存時の暗号化。サービス利用者には通常どおり平文が返ることが多い
ファイルレベル暗号化	個別ファイル	ファイル移動後も保護を維持しやすい。鍵管理と復号権限が重要
クライアント側暗号化	アップロード前のデータ	クラウド側に平文を渡さない設計に使える。実装・鍵管理の難易度が上がる

CMMC対応では、これらを排他的に考える必要はありません。むしろ、複数の層を組み合わせます。

端末にはディスク暗号化、クラウドには保存時暗号化、CUIファイルにはファイルレベル暗号化、特に高い隔離が必要なデータにはクライアント側暗号化、というように、データの重要度と利用方法に応じて設計します。

ファイルレベル暗号化がCUI Boundaryに与える効果

ファイルレベル暗号化の価値は、データが境界を越えても保護を維持しやすい点にあります。

例えば、通常のファイル共有では、ファイルがダウンロードされると、共有元のアクセス制御が効きにくくなります。ローカルに保存され、別のメールで転送され、個人用クラウドへ移されると、元のストレージの権限管理だけでは追跡できません。

ファイルレベル暗号化を使えば、ファイルが移動しても復号権限を制御できます。契約終了、プロジェクト終了、委託終了、担当者変更に合わせて、復号権限を失効させる設計も可能です。

ただし、これは理想形です。実際に機能するには、次の条件が必要です。

暗号化がユーザー任せではなく、ポリシーで適用される
復号権限がIDと役割に紐づく
鍵が個人管理ではなく組織管理される
復号、共有、印刷、コピー、ダウンロードが記録される
外部ユーザーの権限失効ができる
暗号化後のファイル名やメタデータも管理される
例外運用が記録される

これらがない場合、ファイルレベル暗号化は「鍵付きファイルを作っただけ」になってしまいます。

CMMCで見るべき論点

ファイルレベル暗号化は、CMMCの複数の要求領域に関係します。

特に関係が深いのは、アクセス制御、識別認証、監査と説明責任、構成管理、メディア保護、システム通信保護、インシデント対応です。

実務では、次のように整理します。

論点	説明すべき内容
アクセス制御	誰がCUIファイルを復号・閲覧・編集・共有できるか
識別認証	復号権限が個人IDに紐づいているか、MFAが適用されるか
鍵管理	鍵の保管、ローテーション、失効、監査が管理されているか
ログ	復号、共有、ダウンロード、印刷、権限変更を記録できるか
データフロー	暗号化前、暗号化後、復号後にCUIがどこへ流れるか
外部共有	外部ユーザー、委託先、親会社、子会社への共有条件
例外処理	緊急共有、オフライン利用、旧形式ファイルの扱い

CMMC評価では、暗号化製品名よりも、これらをSSPと証跡で説明できるかが重要です。

パスワード付きZIPは設計ではない

日本企業で今でも多いのが、パスワード付きZIPによるファイル共有です。

パスワード付きZIPは、何もしないよりは良い場合もあります。しかし、CUI保護の設計としては弱いことが多いです。

理由は明確です。

パスワードがメールやチャットで共有される
パスワードの強度が管理されない
誰が開いたか記録されない
退職者や委託終了者のアクセスを失効できない
ファイル転送後の再配布を制御できない
鍵管理が個人依存になる
復号後のファイルが無制御に保存される

CUI保護で必要なのは、「一度だけ開けるパスワード」ではありません。誰が、どの条件で、どのCUIにアクセスできるかを継続的に制御し、説明できることです。

ファイルレベル暗号化と分類ラベル

ファイルレベル暗号化は、分類ラベルと組み合わせると強くなります。

分類ラベルによって、ファイルがCUI、CUI//SP-CTI、Export Controlled、社外秘、一般情報など、どの保護状態にあるかを示します。そして、ラベルに応じて暗号化、共有制限、DLP、保持期間、監査ログを適用します。

このとき大切なのは、ラベルを単なる表示にしないことです。

ラベルは、ポリシーを発動するための属性であるべきです。ラベルがCUIであれば、社外共有が制限される。ダウンロードが制御される。復号権限が特定グループに限定される。ログレビュー対象になる。こうした運用と結びついて初めて意味があります。

外部共有での注意点

CUIファイルを外部へ共有する場合、ファイルレベル暗号化は有効です。しかし、外部共有では暗号化だけでなく、配布制限と契約条件を確認する必要があります。

NARAのCUI Registryでは、Limited Dissemination Controlsが整理されており、NOFORNなどの制限が存在します。CUIのアクセスや配布は、lawful Government purposeや関連する法令・政府方針に沿って判断される必要があります。

つまり、技術的に共有できることと、契約上・規則上共有してよいことは別です。

ファイルレベル暗号化は、共有を安全にする技術です。しかし、共有してよい相手かどうかを判断するのは、契約、顧客指示、CUIカテゴリ、輸出管理、配布制限です。

よくある誤解

「ファイルレベル暗号化を入れればCMMC対応になる」という誤解があります。暗号化は保護手段の一部であり、CMMC全体ではアクセス制御、ログ、構成管理、インシデント対応、教育、責任分界まで必要です。

「暗号化されていればどこに置いてもよい」という誤解もあります。復号できる主体、メタデータ、ログ、バックアップ、鍵管理、契約上の制限を確認しない限り、安全とは言えません。

「ユーザーに暗号化を任せればよい」という誤解も危険です。CUI保護は属人的な努力ではなく、組織的な設計であるべきです。

本質

ファイルレベル暗号化の本質は、CUIを場所ではなくデータとして守ることです。

ただし、データとして守るとは、ファイルに鍵をかけるだけではありません。分類、鍵、ID、権限、ログ、共有、失効、責任分界を一体で設計することです。

CMMCにおける暗号化は、製品機能ではなく、説明可能な保護状態です。暗号化されたCUIが、誰に、どの条件で、どこまで使えるのかを説明できること。それがファイルレベル暗号化の実務上の価値です。

深掘り：ファイルレベル暗号化とCMMCを実務判断に落とす

ファイルレベル暗号化は、CUIをファイル単位で守るための有効な手段ですが、CMMC対応を自動的に完了させるものではありません。保護対象がファイルであっても、評価対象はそれを扱う主体、端末、アプリケーション、鍵、ログ、運用全体です。

ここで重要なのは、概念を知識として理解するだけで終わらせないことです。CMMCやCUI保護の実務では、どの情報を、どのシステムで、誰が、どの権限で、どの条件のもと扱うのかを説明できなければなりません。ファイルレベル暗号化とCMMCという論点も、最終的には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、バックアップ、管理端末、ネットワーク制御も、判断対象に入ることがあります。

ファイルレベル暗号化は、ラベル、権限、鍵、DLP、CASB、監査ログ、条件付きアクセスと組み合わせて設計する必要があります。重要なのは、ファイルが境界外へ移動しても、利用条件を一定程度追従させることです。

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

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

技術図面をIRMやラベル付き暗号化で配布する場合、配布先の端末準拠状態、外部共有制限、オフライン利用、失効処理、退職者権限削除まで含めて運用しないと、CUIの保護状態は維持できません。

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

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

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

ラベルポリシー、暗号化ポリシー、アクセス許可テンプレート、利用ログ、失効ログ、例外承認記録、鍵管理手順をSSPや関連文書から参照できるようにします。

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

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

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

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

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

運用成熟度の見方

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

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

組織間の責任分界

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

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

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

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

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

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

確認すべき問い

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

次に読む記事

次は「Data-centric Securityとは何か」です。CUIをファイル単位で守る発想を、より広いデータ中心のセキュリティ構造として整理します。