CUIをクラウドストレージに置けるかどうかは、クラウド名だけでは決まりません。契約、CUIカテゴリ、CSPの認証状態、顧客側設定、責任分界、SSP、ログ、鍵管理を合わせて判断する必要があります。

はじめに

CUI対応でよく聞かれる質問があります。

「CUIをクラウドストレージに保存してよいのか」

この問いに対して、「Commercialは不可」「GCC Highなら可」「Azureなら可」「FedRAMPなら可」と単純に答えるのは危険です。

CUIとクラウドストレージの判断は、サービス名だけでは決まりません。契約で何が求められているのか。CUIを処理・保存・送信するのか。CSPがどの認証・承認を持つのか。顧客側はどの設定を行うのか。誰が鍵を管理するのか。外部共有やログをどう扱うのか。これらを合わせて見る必要があります。

結論

CUIをクラウドストレージに保存できるかどうかは、クラウド製品名ではなく、CUIを扱う環境全体の保護状態で判断します。

CMMCでは、CSP、つまりCloud Service ProviderがCUIを処理・保存・送信する場合、DFARS 252.204-7012に基づくFedRAMP関連要件や同等性の確認、CSPと顧客の責任分界、SSPへの記述が重要になります。32 CFR Part 170でも、CSPやESPがCUIまたはSecurity Protection Dataを処理・保存・送信するかを考慮し、利用関係やCustomer Responsibility MatrixをSSPに文書化する考え方が示されています。

クラウドストレージは使えるか使えないかではなく、どう使うかです。

CMMCはクラウドサービスそのものの認証ではない

重要な点として、CMMCはクラウドサービスそのものに直接適用される認証ではありません。

MicrosoftのAzure CMMC説明でも、CMMCはAzureのようなクラウドサービスプラットフォームに直接適用されるものではなく、DIB contractorの実装状態を評価する制度であると説明されています。そのうえで、クラウドベースのソリューションを提供するDIB contractorは、基盤となるクラウドサービスが少なくともFedRAMP Moderate authorizationを維持していることを確認する必要があると説明されています。

つまり、クラウド事業者が何らかの認証や承認を持っていても、顧客側のCMMC対応が自動的に完了するわけではありません。

顧客側には、次の責任が残ります。

  • どのCUIをクラウドに置くかを判断する
  • 適切なクラウドサービスを選ぶ
  • アクセス制御を設計する
  • MFA、条件付きアクセス、管理者権限を管理する
  • 暗号化と鍵管理を設計する
  • 外部共有を制御する
  • ログを収集・レビューする
  • バックアップと削除を管理する
  • SSPとCRMに責任分界を書く

クラウドは責任を消すものではなく、責任を分けるものです。

FedRAMPだけで判断してはいけない

FedRAMPは重要です。クラウドサービスのセキュリティベースラインや承認状態を確認するための重要な枠組みです。FedRAMP Marketplaceは、FedRAMP認証済みクラウドサービスや関連情報を確認するための公式な検索場所です。

しかし、FedRAMPだけでCUIクラウド利用の判断が完結するわけではありません。

確認すべき点は次の通りです。

  • 該当サービスがFedRAMP Marketplaceでどの状態にあるか
  • その承認がどのクラウド環境、リージョン、サービス範囲に適用されるか
  • 契約上FedRAMP Moderate、High、DoD IL要件、同等性が求められているか
  • CUIカテゴリやControlled Technical Informationに特別な制限があるか
  • ITAR/EARやNOFORNなどの配布制限が関係するか
  • 顧客側がCRMで実装すべき設定を満たしているか

特にMicrosoft 365やAzureでは、Commercial、Government、GCC High、DoD、Azure Governmentなど、環境によって前提が異なります。製品ブランドではなく、対象サービス、対象テナント、対象リージョン、対象ワークロードを見なければなりません。

クラウドストレージで見るべき設計要素

CUIをクラウドストレージに保存するなら、最低限、次の設計要素を確認します。

要素 確認内容
テナント CUI用テナントか、一般業務と共用か
リージョン データ所在地、顧客指示、輸出管理上の制約
サービス範囲 FedRAMPやDoD ILの対象範囲に該当するか
ストレージ構造 アカウント、コンテナ、フォルダ、ライブラリの分離
アクセス制御 RBAC、ABAC、外部共有、管理者権限
認証 MFA、フィッシング耐性、条件付きアクセス
暗号化 保存時暗号化、転送時暗号化、顧客管理キー、クライアント側暗号化
ネットワーク Private Endpoint、許可IP、公開アクセス禁止
ログ 読み取り、書き込み、共有、削除、管理操作、鍵操作
バックアップ 複製、保持、削除、復元時のCUI扱い
DLP ダウンロード、共有、外部送信、ラベル連動
SSP/CRM CSP、MSP、顧客の責任分界

クラウドストレージのCUI対応は、ストレージ設定だけではありません。ID、ネットワーク、鍵、ログ、共有、運用を一体で設計する必要があります。

Commercial環境は絶対に無理なのか

よくある問いとして、「Commercial環境ではCUIは絶対に無理なのか」があります。

この問いに一律の答えを出すべきではありません。判断は、契約条項、CUIの種類、顧客指示、CSPのFedRAMP状態、DFARS要件、輸出管理、データ所在地、サービス範囲によります。

ただし、防衛契約でCovered Defense InformationやCUIをクラウドサービスに保存・処理・送信する場合、DFARS 252.204-7012やCMMC関連の要求を無視することはできません。CSPのFedRAMP Moderate相当以上の要件や、CSPが関係する責任分界の文書化が問題になります。

したがって、実務上は次のように判断します。

  • 契約にCUI/CDI/DFARS/CMMC要求があるか
  • クラウドサービスがCUIを処理・保存・送信するか
  • そのクラウドサービスのFedRAMPまたは同等性を説明できるか
  • 顧客側設定がCRMどおりに実装されているか
  • CUIカテゴリや輸出管理上、追加制約がないか
  • 顧客またはプライムから特定環境の指定があるか

「Commercialだから可」「Commercialだから不可」ではなく、契約と保護状態で判断する必要があります。

外部共有を甘く見てはいけない

クラウドストレージの最大のリスクの一つは、外部共有です。

便利な共有リンク、匿名リンク、組織外ユーザー招待、SAS token、期限なしリンク、再共有、同期クライアント。これらは業務効率を高めますが、CUI保護では厳密に管理する必要があります。

CUIの外部共有では、少なくとも次を制御します。

  • 匿名リンクの禁止
  • 期限付きリンク
  • 共有先ドメインの制限
  • 外部ユーザーの本人確認
  • MFA要求
  • ダウンロード制限
  • 再共有制限
  • 共有承認フロー
  • 共有後の定期レビュー
  • 共有ログの確認
  • 契約終了時のアクセス失効

CUIの共有では、「リンクを知っている人が見られる」は基本的に危険です。共有とは、権限付与であり、責任発生です。

クラウドストレージとログ

クラウドストレージでは、ログが非常に重要です。

誰がCUIファイルを開いたのか。ダウンロードしたのか。削除したのか。共有したのか。権限を変更したのか。鍵を操作したのか。公開アクセスを有効化したのか。これらを記録できなければ、インシデント対応も継続的な検証もできません。

特に注意すべきなのは、ログ自体の扱いです。

ログには、ファイル名、パス、ユーザー、IPアドレス、操作内容、場合によってはCUI性を示す情報が含まれます。また、CUI環境を保護するために使うログは、CMMC上のSecurity Protection Dataとして扱われる可能性があります。

クラウドストレージのCUI対応では、データ本体だけでなく、ログの保存先、アクセス権、保持期間、SIEM連携、MSP/SOCのアクセス権も設計に入れる必要があります。

よくある誤解

「クラウド事業者が認証を持っているから顧客側は何もしなくてよい」という誤解があります。クラウドの認証は基盤の一部を説明するものであり、顧客側設定、ID、アクセス制御、ログ、鍵管理、共有制御は顧客の責任として残ります。

「データ所在地だけで判断できる」という誤解もあります。データ所在地は重要ですが、CUI保護では、誰がアクセスできるか、どのサービスが処理するか、どのログがどこへ行くか、契約で何が求められているかも重要です。

「暗号化されていればクラウドに置いてよい」という誤解も危険です。暗号化方式、鍵管理、復号権限、メタデータ、ログ、CSPの責任分界を確認する必要があります。

本質

CUIとクラウドストレージの本質は、クラウドを使うかどうかではありません。

クラウド上でCUIをどの境界の中に置き、誰がアクセスし、どの保護機能で守り、どの責任分界で運用し、どの証跡で説明するかです。

クラウドストレージは、CUI保護を強くすることも、曖昧にすることもできます。差を生むのは、製品名ではなく設計です。

深掘り：CUIとクラウドストレージを実務判断に落とす

CUIとクラウドストレージの論点は、「クラウドに置けるか」ではなく、「どのクラウド環境で、どの契約条件のもと、誰が、どの操作を、どの証跡を残して扱うか」です。クラウド利用の可否は製品名だけでは決まりません。

ここで重要なのは、概念を知識として理解するだけで終わらせないことです。CMMCやCUI保護の実務では、どの情報を、どのシステムで、誰が、どの権限で、どの条件のもと扱うのかを説明できなければなりません。CUIとクラウドストレージという論点も、最終的には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、暗号化、監査ログ、ゲスト管理、保持ポリシー、デバイス制御、管理者権限分離を一体で設計します。

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

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

日本企業がOneDrive、SharePoint、Box、Google Drive、Azure Storageなどを使う場合でも、CUIがどのテナント、どのライセンス、どの契約条件、どの管理者権限で扱われるかによって判断が変わります。

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

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

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

テナント設定、共有ポリシー、監査ログ、アクセスレビュー、外部共有レポート、CSP/ESP情報、責任分界表をSSPと整合させます。

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

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

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

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

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

運用成熟度の見方

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

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

組織間の責任分界

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

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

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

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

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

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

確認すべき問い

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

次に読む記事

次は「Azure Blob StorageとCUI」です。クラウドストレージの一般論を、Azure Blob Storageの設計論点に落とし込みます。

参考資料