Azure Blob StorageとCUI

Azure Blob Storageは、CUIを扱うストレージ候補になり得ます。しかし、Blob Storageを使うこと自体がCMMC対応を意味するわけではありません。テナント、リージョン、FedRAMP範囲、鍵管理、ネットワーク、アクセス制御、ログ、SSPへの記述を合わせて設計する必要があります。

はじめに

Azure Blob Storageは、非構造化データを保存するための代表的なクラウドストレージです。設計図、PDF、ログ、試験データ、画像、ソフトウェア成果物、バックアップなど、多くの種類のデータを保存できます。

CUIを扱う企業にとって、Blob Storageは便利な選択肢になり得ます。しかし、CUIをBlob Storageに置く場合、通常のクラウドストレージ設計とは違う注意が必要です。

「Azureだから安全」「暗号化されているから大丈夫」「Private Endpointを使えばよい」という単純な判断では足りません。

結論

Azure Blob StorageでCUIを扱う場合、重要なのはBlob Storage単体ではなく、CUIを扱うAzure環境全体の設計です。

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

どのAzure環境を使うのか
対象サービスが契約上求められるFedRAMPまたはDoD IL要件に対応しているか
CUIを保存するストレージアカウント、コンテナ、Blobをどう分離するか
Microsoft管理キー、顧客管理キー、顧客提供キー、クライアント側暗号化をどう使うか
Private Endpoint、ファイアウォール、公開アクセス禁止をどう設計するか
RBAC、ABAC、Managed Identity、SAS tokenをどう制御するか
ログ、監査、アラート、保持、バックアップをどう扱うか
CSP、MSP、顧客の責任分界をSSPとCRMにどう書くか

Azure Blob Storageは、CUI保護の部品です。CMMC対応の答えではありません。

Azure Blob StorageをCUIに使う前に確認すること

最初に確認すべきことは、契約です。

CUIを保存するクラウドサービスに対して、契約、DFARS、顧客指示、プライムからのflowdownが何を求めているかを確認します。CMMCの文脈では、CSPがCUIを処理・保存・送信する場合、FedRAMP関連要件やCustomer Responsibility Matrix、SSPへの記述が重要になります。

次に確認するのは、Azure環境です。

Azure Commercial、Azure Government、Azure Government DoDなど、利用するクラウド環境によって、対象顧客、分離、リージョン、監査範囲、利用可能サービスが異なります。Microsoft Learnでは、Azure Governmentが米国政府機関および規制対象組織向けのcommunity cloudであり、DoD IL5ワークロードのセキュリティ要求を満たすよう設計されていること、Commercialリージョンとは別のネットワークとIDモデルを使うことが説明されています。

ただし、Azure Governmentを使えば自動的に全てのCUI要件を満たすわけではありません。対象サービス、リージョン、構成、顧客側設定、契約条件を確認する必要があります。

ストレージアカウントとコンテナの分離

Blob StorageでCUIを扱う場合、まず分離設計が重要です。

CUIと非CUIを同じストレージアカウント、同じコンテナ、同じ命名規則、同じ権限で扱うと、境界が曖昧になります。

現実的には、次のような分離を検討します。

CUI専用ストレージアカウント
契約または顧客単位のストレージ分離
CUIカテゴリ単位のコンテナ分離
本番、開発、分析、バックアップの分離
管理者権限の分離
ログ保存先の分離
鍵の分離

Blob Storageは柔軟ですが、柔軟性はそのままリスクになります。誰でも新しいコンテナを作れる、SASを発行できる、公開アクセスを有効化できる、共有キーを使える、という状態ではCUI環境として弱くなります。

暗号化設計

Azure Storageでは、新しいストレージアカウントのデータは既定でMicrosoft管理キーにより暗号化されます。また、Blob StorageとAzure Filesでは顧客管理キーを指定でき、Azure Key VaultまたはKey Vault Managed HSMで鍵を管理できます。Blob Storageでは、リクエストごとに顧客提供キーを含める方式や、コンテナまたはBlob単位の暗号化スコープも用意されています。

CUI設計では、どの暗号化方式を使うかを明確にします。

方式	特徴	CUI設計上の論点
Microsoft管理キー	既定で使いやすい	鍵管理責任は主にMicrosoft側。顧客側の追加統制が必要か確認
顧客管理キー	Key VaultまたはManaged HSMで管理	鍵ローテーション、アクセス、監査、失効を顧客側で設計
顧客提供キー	リクエストごとに鍵を提供	アプリケーション側の鍵管理が重要
暗号化スコープ	コンテナまたはBlob単位で鍵スコープを分ける	顧客、契約、CUIカテゴリごとの境界設計に使いやすい
クライアント側暗号化	アップロード前に暗号化	クラウド側に平文を渡さない設計に使えるが、実装と鍵管理が難しい

暗号化を選ぶときは、セキュリティだけでなく、運用性、監査性、復旧性も考えます。鍵を失えばデータは復号できません。鍵管理者が強すぎれば、CUIの分離が壊れます。

ネットワーク設計

Blob StorageのCUI利用では、公開インターネットからのアクセスをどう制御するかが重要です。

検討すべき要素は次の通りです。

Private Endpoint
Storage firewall
許可された仮想ネットワーク
許可IPアドレス
Secure transfer required
Public network accessの制限
Anonymous accessの禁止
Shared Key accessの制御
SAS tokenの制限

Microsoft LearnのBlob Storageセキュリティ推奨でも、HTTPSによる安全な転送を要求し、HTTP要求を拒否すること、SAS tokenをHTTPS接続のみに制限することが推奨されています。

ただし、ネットワーク制御だけで十分ではありません。Private Endpointを使っていても、認可が粗ければCUIは漏れます。ネットワークは境界の一部であり、認証・認可の代替ではありません。

認可設計：RBAC、ABAC、Managed Identity

Blob Storageでは、ユーザー、アプリケーション、サービスにアクセス権を付与します。CUI環境では、個人ユーザーだけでなく、アプリケーション、ETL、分析基盤、バックアップ、監視、CI/CD、MSPの管理アカウントも確認する必要があります。

設計では、次の考え方が重要です。

共有キーに依存しすぎない
個人IDと管理者IDを分ける
Managed Identityを活用する
RBACを最小権限で設計する
契約やCUIカテゴリに応じたABACを検討する
SAS tokenは短命・最小権限・HTTPS限定にする
外部委託先のアクセスは期限と承認を持たせる
権限レビューを定期的に行う

CUIにおけるアクセス制御は、「アクセスできるか」だけでなく、「なぜアクセスできるのか」を説明できる必要があります。

ログと監査

Blob StorageでCUIを扱うなら、ログは必須の設計要素です。

記録すべきイベントには、次のようなものがあります。

Blobの読み取り
Blobの作成・更新
Blobの削除
コンテナ作成
アクセス権変更
SAS token発行
共有キー利用
ネットワーク設定変更
暗号化設定変更
Key Vaultでの鍵操作
管理者操作
異常な大量ダウンロード

ログは取得して終わりではありません。保管場所、保持期間、改ざん防止、SIEM連携、アラート、レビュー責任者を決める必要があります。

さらに、ログ自体がSecurity Protection Dataになる可能性があります。CUI環境を保護するために使うログ、設定データ、脆弱性情報、構成情報は、CMMC上のスコープ判断に関係します。

バックアップ、バージョン、削除

Blob Storageは、バージョン管理、論理削除、ライフサイクル管理、冗長化、アーカイブなどの機能を持ちます。これらは可用性と復旧に有効ですが、CUIの保持と削除を複雑にします。

CUIを削除したつもりでも、旧バージョン、スナップショット、バックアップ、アーカイブ、別リージョン複製に残ることがあります。

CUI設計では、次を確認します。

CUIの保持期間
契約終了時の返却・削除条件
バージョンやスナップショットの扱い
アーカイブされたCUIの復元権限
バックアップの保存先と暗号化
削除証跡
法的保持との関係

CUIの削除は、ファイル一覧から消すことではありません。ライフサイクル全体から管理する必要があります。

よくある誤解

「Blob Storageは既定で暗号化されているからCUI対応できている」という誤解があります。保存時暗号化は重要ですが、アクセス制御、ネットワーク、鍵管理、ログ、バックアップ、SSP、CRMが必要です。

「Private Endpointを使えばCUI Boundaryから外れる」という誤解もあります。Private Endpointはネットワーク経路を制御しますが、CUIを処理・保存・送信する事実を消すものではありません。

「Azure Governmentなら設定しなくてもよい」という誤解も危険です。Azure Governmentでも、顧客側設定、対象サービス、リージョン、責任分界、契約条件を確認する必要があります。

本質

Azure Blob StorageとCUIの本質は、BlobにCUIを置けるかどうかではありません。

CUIをBlob Storage上でどのように分離し、誰がアクセスし、どの鍵で守り、どの経路で利用し、どのログで検証し、どの責任分界で運用するかです。

Azure Blob Storageは強力な部品です。しかし、CUI保護を成立させるのは部品ではなく設計です。

深掘り：Azure Blob StorageとCUIを実務判断に落とす

Azure Blob StorageをCUIで使う場合、重要なのは「Azureなら安全」という一般論ではなく、ストレージアカウント、コンテナ、認証方式、ネットワーク制限、暗号化、ログ、鍵管理、責任分界をCUI Boundaryに合わせて設計することです。

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

Blob Storageは柔軟なサービスである分、公開アクセス、SASトークン、過剰なRBAC、共有キー、ログ不足、ライフサイクル管理不足がリスクになります。設定の一部だけを見て安全と判断するのは危険です。

このため、設計時には「対象を狭く見すぎていないか」と「責任を広く曖昧にしすぎていないか」の両方を確認します。前者はスコープ漏れを生み、後者は運用不能な過大スコープを生みます。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用のストレージアカウントは、公開アクセス無効化、Private Endpoint、最小権限、Managed Identity、顧客管理キー、診断ログ、Defender for Cloud、保持・削除ポリシーを組み合わせて考えます。

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

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

CUIを含む設計データや解析結果をAzure上のアプリケーションが処理する場合、Blobだけでなく、Compute、Key Vault、Managed Identity、Private Endpoint、Log Analytics、バックアップ、運用者端末まで含めた設計が必要です。

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

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

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

Azure Policy準拠状況、RBAC一覧、SAS発行ログ、Key Vaultアクセスログ、Storageログ、ネットワーク設定、変更履歴を証跡化します。

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

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

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

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

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

運用成熟度の見方

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

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

組織間の責任分界

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

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

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

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

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

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

確認すべき問い

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

次に読む記事

次は「CUIと監査ログ」です。Blob Storageを含むCUI環境では、ログが保護状態を証明する重要な証跡になります。