Continuous Verificationとは何か

はじめに

多くの環境では、ログインに成功した瞬間に“安全な利用者”として扱われます。しかし、CUI環境では、ログイン後に端末状態が変わる、権限が過剰になる、セッションが乗っ取られる、外部共有が発生する、といったリスクを無視できません。Continuous Verificationは、この一度きりの確認を前提にしない考え方です。

結論

Continuous Verificationとは、アクセスの前後を通じて、主体、端末、権限、操作、環境、振る舞いを継続的に確認し、必要に応じて再認証、制限、遮断、調査へつなげる設計です。Zero Trustを実務に落とすときの中心は、認証そのものではなく、確認を継続する仕組みです。

背景

クラウドやSaaSでは、境界内に入った後の通信を一枚のネットワークで囲い込むことが難しくなっています。NIST SP 800-207は、Zero Trustがネットワーク位置ではなく、ユーザー、資産、リソースに焦点を移す考え方であると整理しています。継続的な検証は、このリソース中心の防御に不可欠です。

構造整理

事前確認

アクセス開始時に、ID、MFA、端末準拠、場所、リスク、権限、Objectの感度を確認します。これは入口の確認ですが、ここで終わるわけではありません。

セッション中の確認

セッション中の振る舞い、ダウンロード量、異常な操作、権限昇格、トークン利用、管理操作を監視します。異常時には再認証、読み取り専用化、セッション終了を行える設計が必要です。

事後確認

ログ、アラート、監査証跡、インシデント対応、権限レビューを通じて、判断が妥当だったかを確認します。CMMCでは、証跡として説明できることが重要です。

実務上の重要ポイント

Continuous Verificationは、ツール単体ではなく、ID、端末、ログ、運用判断の連動で成立します。

条件付きアクセスで端末準拠、MFA、場所、リスクを評価する
CUIへの高リスク操作に追加認証や承認を求める
ログをSIEMに集約し、アクセス後の異常を検出する
管理者セッションを通常ユーザーセッションと分離する
例外許可は期限付きにし、理由と承認者を残す

よくある誤解

ログイン時MFAだけで継続的検証ができていると考える
検出した異常に対する運用手順を決めていない
アクセス許可の判断条件をSSPに書けない
CUIダウンロード後の利用をまったく追跡しない

本質

Continuous Verificationの本質は、信頼を状態として固定せず、変化する条件として扱うことです。

深掘り：Continuous Verificationとは何かを実務判断に落とす

Continuous Verificationは、一度認証したら終わりではなく、アクセスの前後とセッション中に状態を確認し続ける考え方です。CUI環境では、利用者・端末・権限・データ感度・リスクが変化する前提で設計する必要があります。

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

ログイン時のMFAだけに依存すると、端末の感染、権限変更、異常ダウンロード、場所の変化、セッション乗っ取りを見逃します。継続的検証がない環境では、許可後の振る舞いを説明できません。

このため、設計時には「対象を狭く見すぎていないか」と「責任を広く曖昧にしすぎていないか」の両方を確認します。前者はスコープ漏れを生み、後者は運用不能な過大スコープを生みます。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、SIEM、UEBA、特権アクセス管理をつなぎ、検証結果に応じて許可、制限、再認証、遮断を切り替えます。

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

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

日本と米国の時差をまたいで共同作業する場合、通常時間外アクセスや大量ダウンロードが正当作業なのか異常なのかを、コンテキストに基づいて判断する必要があります。

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

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

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

リスクイベント、条件付きアクセス結果、DLPイベント、セッション制御ログ、アラート対応記録、例外承認が証跡です。

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

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

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

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

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

運用成熟度の見方

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

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

組織間の責任分界

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

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

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

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

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

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

確認すべき問い

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

まとめ

CUI環境では、認証済みであることと安全であることは同じではありません。Continuous Verificationは、アクセスの前後を通じてCUI保護状態を維持するための運用設計です。

次に読む記事

次は「Replay Resistanceとは何か」を読むと、この論点を別の角度から確認できます。