監査ログは、CUI環境で何が起きたかを後から確認するための証跡です。しかし、CUI対応におけるログは単なる記録ではありません。アクセス制御、インシデント対応、継続的検証、責任分界を成立させるための基盤です。

はじめに

CUI環境では、ログが重要です。

これは誰もが理解しているようで、実際には軽視されがちな領域です。多くの企業は、ログを「何かあったときに見るもの」と考えます。しかし、CMMCやCUI保護の文脈では、ログは後処理のためだけに存在するものではありません。

ログは、CUI環境で誰が、いつ、どの情報に、どの操作を行ったかを説明するための証跡です。アクセス制御が機能しているかを確認し、異常な操作を検知し、インシデント時に影響範囲を特定し、外部サービスとの責任分界を検証するための基盤です。

結論

CUIと監査ログの関係で重要なのは、ログを「保存しているか」ではなく、「CUI保護を説明するために必要なイベントを、適切な粒度、完全性、保持期間、責任分界で管理しているか」です。

NIST SP 800-92は、組織がコンピュータセキュリティログ管理の必要性を理解し、企業全体で効果的なログ管理実務を開発・実装・維持するための実践的ガイダンスを提供しています。

CMMCの文脈では、さらに重要な点があります。CUI環境を保護するためのログや設定情報は、Security Protection Dataとして扱われる可能性があります。32 CFR Part 170では、Security Protection Dataには、SPAが生成または取り込むログファイル、構成データ、脆弱性状態、インスコープ環境へアクセスできるパスワードなどが含まれると説明されています。

つまり、ログはCUIを守る証跡であると同時に、それ自体が保護対象になることがあります。

何をログに残すべきか

CUI環境で最初に決めるべきことは、どのイベントを記録するかです。

記録すべきイベントは、単にログイン成功・失敗だけではありません。CUIのライフサイクルに沿って、アクセス、編集、共有、削除、権限変更、管理操作、鍵操作、外部送信を追える必要があります。

最低限、次のようなイベントを検討します。

領域 ログイベント
認証 ログイン成功・失敗、MFA、条件付きアクセス、特権昇格
認可 権限付与、権限変更、グループ追加、外部ユーザー招待
データアクセス CUIファイルの閲覧、ダウンロード、アップロード、編集
共有 外部共有、リンク作成、リンク変更、共有解除、SAS token発行
管理操作 ストレージ設定変更、公開アクセス有効化、ネットワーク設定変更
暗号化 鍵作成、鍵利用、鍵ローテーション、鍵無効化、Key Vault操作
端末 CUIファイルのローカル保存、USB利用、EDR検知
DLP 送信ブロック、警告、例外承認、ラベル変更
バックアップ バックアップ作成、復元、削除、保持ポリシー変更
インシデント アラート、調査記録、封じ込め、証拠保全

この表は、ツール一覧ではありません。CUI保護を説明するために、どの行為を追うべきかを示すものです。

ログはCUIデータフローと結びつける

ログ設計は、CUIデータフローと切り離してはいけません。

CUIがどこで受領され、どこで保存され、どこで編集され、どこへ共有されるのかが分からなければ、どのログが必要かも分かりません。

たとえば、CUIがAzure Blob Storageに保存されるなら、Blobの読み取り、書き込み、削除、権限変更、ネットワーク設定変更、鍵操作を追う必要があります。CUIがMicrosoft 365で共有されるなら、ファイルアクセス、外部共有、DLP、ラベル変更、監査ログを確認します。CUIがCAD端末で処理されるなら、端末ログ、EDRログ、ローカル保存、印刷、USB、スクリーンショットの扱いも問題になります。

ログは、CUIデータフローの各地点に配置するセンサーです。フローが見えていなければ、センサーを置く場所も分かりません。

ログの完全性と改ざん防止

ログは、記録されているだけでは十分ではありません。

ログが改ざんできる、削除できる、管理者が自由に無効化できる、時刻がずれている、保存先が不明、保持期間が短すぎる、誰もレビューしていない。このような状態では、ログは証跡として弱くなります。

CUI環境では、少なくとも次を設計します。

  • 時刻同期
  • ログソース一覧
  • ログ転送経路
  • 集約先
  • 書き換え・削除権限の制限
  • 保持期間
  • アラート条件
  • レビュー頻度
  • 例外承認
  • インシデント時の証拠保全
  • ログ管理者とシステム管理者の分離

ログの完全性は、セキュリティの完全性に直結します。攻撃者がCUIへアクセスした後、ログを消せるなら、検出も調査もできません。

ログ自体がスコープに入る理由

CUI対応で見落とされやすいのは、ログ自体の扱いです。

ログには、CUIの内容そのものが入る場合もあります。ファイル名、パス、図面番号、部品番号、契約番号、ユーザー名、IPアドレス、アクセス先、操作内容が含まれるからです。

さらに、CUI本文を含まないログでも、CUI環境を保護するために使われるログは、Security Protection Dataとして重要になります。32 CFR Part 170では、Security Protection Dataは、Security Protection Assetが保存または処理するセキュリティ関連情報であり、ログファイル、構成データ、脆弱性状態などを含むと説明されています。

つまり、ログをSIEMやMSPへ送る場合、そのSIEMやMSPがCUI本文を扱っていないとしても、CUI環境の保護に関わる情報を扱っている可能性があります。

この場合、SSP、資産分類、Customer Responsibility Matrix、MSP契約、ログアクセス権を確認する必要があります。

MSPやSOCがログを扱う場合

日本企業では、SOCやMSPにログ監視を委託しているケースが多いです。

このとき重要なのは、MSPが何にアクセスできるかです。

  • CUI本文を見られるのか
  • CUIファイル名やパスを含むログを見られるのか
  • CUI環境の脆弱性情報を見られるのか
  • 管理者権限を持つのか
  • SIEMのルールやアラートを変更できるのか
  • 証跡を削除できるのか
  • インシデント時にどの範囲まで調査できるのか

32 CFR Part 170では、External Service ProviderがCUIまたはSecurity Protection Dataを処理・保存・送信する場合、その関係やサービス内容をSSPとCustomer Responsibility Matrixに文書化することが求められます。

ログ運用を外部に出すこと自体が悪いわけではありません。問題は、責任分界が曖昧なまま外部に出すことです。

ログレビューは自動化だけでは終わらない

ログは大量です。すべてを人間が読むことは現実的ではありません。したがって、SIEM、アラート、相関分析、自動検知は重要です。

しかし、自動化だけでも不十分です。

CUI環境では、何を異常と見るかを業務文脈で定義する必要があります。たとえば、ある設計者が特定のプロジェクト期間中に図面をダウンロードするのは正常かもしれません。しかし、契約終了後に同じ図面へアクセスする、深夜に大量ダウンロードする、未承認の国からアクセスする、外部共有リンクを作る、という行為は異常かもしれません。

ログレビューでは、技術イベントと業務文脈を結びつけます。

実務上のログ設計テンプレート

CUI環境のログ設計では、次の表を作ると整理しやすくなります。

ログソース 記録するイベント 保存先 保持期間 レビュー者 アラート条件 CUI/SPD該当性
IdP ログイン、MFA、権限変更 SIEM 1年 SOC 失敗急増、国外アクセス SPD
Blob Storage 読み書き、削除、共有、設定変更 Log Analytics/SIEM 契約に応じる Cloud管理者/SOC 大量DL、公開設定変更 SPDまたはCUI含有可能性
Key Vault 鍵利用、作成、削除、ローテーション SIEM 契約に応じる セキュリティ責任者 異常な鍵利用 SPD
EDR マルウェア、ファイル操作、USB EDR管理基盤 1年 SOC CUI端末の重大検知 SPD
DLP 外部送信、例外承認 DLP/SIEM 1年 情報管理責任者 CUIラベル外部送信 CUI/SPD

この表をSSPと紐づければ、ログが単なる運用項目ではなく、CUI保護の設計要素になります。

よくある誤解

「ログはSIEMに送っていればよい」という誤解があります。SIEMに送るだけでは不十分です。何を送るか、誰が見るか、いつ見るか、どの条件でアラートにするか、証跡として保持できるかが重要です。

「ログにはCUIが入らない」という誤解も危険です。ログにはファイル名、パス、契約番号、ユーザー名、操作内容が含まれ、CUI性を示す情報が入ることがあります。

「MSPに任せているから大丈夫」という誤解もあります。MSPが何を見て、何を実装し、どの責任を負い、どの証跡を保持するかをSSPとCRMで説明する必要があります。

本質

CUIと監査ログの本質は、後から見るための記録ではありません。

CUI環境で起きていることを継続的に検証し、異常を検知し、責任を明確にし、インシデント時に説明できる状態にすることです。

ログがなければ、CUI保護は主張にすぎません。ログが設計され、保護され、レビューされて初めて、CUI保護は検証可能になります。

CMMCが求めるのは、努力ではなく説明可能な実装です。監査ログは、その説明を支える最も重要な証跡の一つです。

深掘り：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、バックアップ、管理端末、ネットワーク制御も、判断対象に入ることがあります。

ログ設計では、何を記録するか、誰が見るか、どこに集約するか、どの期間保管するか、どの条件でアラートにするか、どの証跡を評価時に提示するかを決めます。

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

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

日本企業のCUI環境では、IdP、クラウドストレージ、EDR、DLP、SIEM、端末、管理操作、外部共有のログが分散します。どのログがCUIアクセスの説明に必要かをあらかじめ設計する必要があります。

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

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

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

ログソース一覧、SIEMルール、保持設定、アラート対応記録、レビュー記録、改ざん防止設定、インシデント時のログ保全手順が重要です。

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・運用手順で一致しているか。

次に読む記事

次はArchitecture & Zero Trustセクションの「Zero Trustとは何か」です。CUIを守るためのアクセス判断を、ネットワーク境界から継続的検証へ移す考え方を整理します。

参考資料