レッスン7：横断機能——継続的検証・可視化・自動化

このレッスンで学ぶこと

継続的検証が、一度きりの認証とどう違うかを説明できる
信頼スコアの考え方と、その危うさの両方を理解する
振る舞い検知の仕組みを把握する
SIEM を「検知装置」から「認可の入力源」へ位置づけ直す発想を理解する
自動遮断がもたらす利点とリスクを、誤検知の観点から理解する
ガバナンスと例外管理の必要性を理解する

前回のレッスンでは、アプリケーションとデータという 2 つの柱を扱い、分類を権限につなげる連鎖を見てきました。ここまでの 4 つのレッスンで、5 つの柱のうち 4 つ（アイデンティティ・デバイス・ネットワーク・アプリケーションとワークロード・データ）を扱ってきました。今回のレッスンでは、レッスン 2 で紹介した 3 つの横断的機能——可視化と分析、自動化とオーケストレーション、ガバナンス——を、深く掘り下げます。柱ごとの設計を、組織全体としてどう束ねるかという視点です。

横断的機能が必要な理由

5 つの柱を、それぞれ独立に成熟させていくだけでは、ゼロトラストは完成しません。アイデンティティの柱が集めた利用者のリスク情報、デバイスの柱が集めた端末の健全性シグナル、ネットワークの柱が記録した通信の状況、アプリケーションとデータの柱が記録したアクセスの履歴。これらの情報がそれぞれの柱の中に閉じたままでは、組織全体としての判断力にはつながりません。

横断的機能は、この柱ごとの情報を束ね、組織全体で活用できる形に変えるための機能です。本レッスンでは、可視化と分析の中核にある継続的検証と信頼スコア、振る舞い検知、そして SIEM の位置づけ直しを見たあと、自動化とオーケストレーション、ガバナンスへと進みます。

継続的検証——セッションの途中でも確かめ続ける

レッスン 1 で確認した NIST SP 800-207 の 3 番目の原則、「個々の企業リソースへのアクセスは、セッション単位で許可する」を思い出してください。この原則をさらに一歩進め、セッションが始まったあとも、状況の変化に応じて評価をやり直す仕組みが、継続的検証です。

従来型の認証は、ログインの瞬間にだけ厳格な確認を行い、いったんセッションが確立すれば、そのセッションが終わるまで信頼を維持し続けるのが一般的でした。継続的検証は、この発想を変えます。セッションの途中であっても、デバイスポスチャが悪化した、普段と異なる操作パターンが検知された、利用者のリスク評価が急に高まった、といった変化があれば、そのセッションを再評価し、必要であれば追加の確認を求めたり、アクセスを打ち切ったりします。

flowchart LR
  A[アクセス開始時の評価] --> S[セッション継続中]
  S --> R{状況の変化を検知}
  R -->|変化なし| S
  R -->|リスク上昇| E[再評価と対応]

例えば、ログイン直後は健全な状態だった端末が、セッションの途中でマルウェア対策ソフトが停止した状態になったとします。従来の一度きりの認証であれば、この変化に気づく仕組みがありません。継続的検証があれば、この変化をリアルタイムに近い形で捉え、セッションを打ち切る、あるいはアクセスできる範囲を制限する、といった対応につなげられます。

💡 ポイント 継続的検証は、レッスン 1 で扱った Never Trust, Always Verify という標語の、最も徹底された実装形態です。「アクセスのたびに確かめる」だけでなく、「アクセスしている最中も確かめ続ける」ところまで踏み込む発想だと理解してください。

信頼スコアの考え方とその危うさ

継続的検証を実務で運用するにあたって、多くの仕組みが採用しているのが、信頼スコアという考え方です。利用者のリスク、サインインのリスク、デバイスポスチャ、行動パターンなど、複数のシグナルを一つの数値に集約し、その数値の高さ・低さでアクセス判断を行う方式です。

信頼スコアには、明確な利点があります。複数のシグナルを個別に判断するよりも、一つの数値にまとめる方が、ポリシーの設計がシンプルになります。「スコアが一定の水準を下回ったら追加確認を求める」というルールは、条件を一つひとつ書き並べるより扱いやすく、レッスン 3 で扱った条件付きアクセスの設計を、実務でスケールさせやすくします。

一方で、信頼スコアには、いくつかの危うさもあります。

不透明になりやすい：複数のシグナルがどう重み付けされて一つの数値になっているかが見えにくく、なぜアクセスを拒否されたのかを利用者に説明しにくくなります
精度への過信を生みやすい：数値化されると、その数値があたかも客観的で正確な指標であるかのように受け止められがちですが、元になっているシグナルの質が低ければ、数値自体の信頼性も低くなります
陳腐化する：スコアの計算方法は、脅威の状況や業務の実態の変化に合わせて見直し続ける必要があります。一度設計したまま放置すると、実態とずれていきます

⚠️ 注意 信頼スコアを導入する際は、「なぜこのスコアになったのか」を、少なくとも運用担当者が追跡できる形にしておくことが重要です。完全なブラックボックスとしてスコアを運用すると、誤ったアクセス拒否が起きたときに、原因を特定できず、修正のしようがなくなります。

振る舞い検知

信頼スコアを構成するシグナルの一つとして、近年重要性が高まっているのが、振る舞い検知です。振る舞い検知は、利用者やシステムの普段の行動パターンを学習し、そのパターンから外れた行動を異常として検知する仕組みです。この考え方は UEBA（利用者とエンティティの行動分析）と呼ばれる領域で扱われます。

例えば、ある利用者が普段は平日の日中にしかアクセスしない業務システムに、深夜に、しかも大量のデータをダウンロードする形でアクセスしたとします。認証情報そのものは正しく、パスワードも多要素認証も通過しているため、従来型の認証だけでは異常として検知できません。しかし、普段の行動パターンと比較すれば、この振る舞いは明らかに異質です。振る舞い検知は、こうした「認証は正しいが、行動が普段と違う」というケースを捉えるための仕組みです。

振る舞い検知の価値は、盗まれた認証情報を使った不正アクセスへの対処にあります。攻撃者が正規の認証情報を手に入れてログインに成功したとしても、その後の行動パターンまで完全に本人を模倣することは難しいため、振る舞いの異常から不正を検知できる可能性が生まれます。

振る舞い検知は、利用者だけでなく、レッスン 6 で扱ったワークロードにも適用できます。あるサービスが、普段は特定のデータベースにしかアクセスしないにもかかわらず、突然、これまでアクセスしたことのない別のシステムへ大量の通信を始めたとすれば、それはサービス自体が侵害された兆候かもしれません。振る舞い検知の対象を、人の利用者に限らずシステムやサービスにまで広げることで、レッスン 5 で見たラテラルムーブメントの初期段階を、より早く捉えられるようになります。

📝 補足 振る舞い検知は、導入した直後から高い精度を発揮するわけではありません。「普段の行動パターン」を学習するための一定の観察期間が必要であり、組織の業務サイクル（月末の集中作業、決算期の特殊な操作など）を十分に反映できるまでには、時間がかかります。導入初期は誤検知が多くなりがちである点を、運用計画に織り込んでおく必要があります。

SIEM を「検知装置」から「認可の入力源」へ位置づけ直す

情報セキュリティ関連の入門コースでも触れられているとおり、SIEM は、組織内の各種システムから集まるログを一元的に集約し、相関分析を行う仕組みです。従来、SIEM は主に、インシデントが起きたあとに調査するための道具、あるいは SOC がリアルタイムに異常を監視するための道具として位置づけられてきました。事後の検知と対応が、その主な役割です。

ゼロトラストの文脈では、この位置づけを一歩広げる発想が求められます。SIEM に集約されるログや相関分析の結果は、インシデント対応のためだけでなく、ポリシーエンジンがアクセスを判断するための入力材料としても使えます。ある利用者のアカウントが、SIEM 上で不審な兆候を示していると分析されていれば、その情報を条件付きアクセスのポリシーに反映し、次のアクセス要求に対してより厳しい確認を求める、という連携が可能になります。

この転換は、「SIEM は事後に振り返るための装置」という理解から、「SIEM はリアルタイムの判断を支える情報源の一つ」という理解への転換です。横断的機能の中の可視化と分析が、単なる監視ダッシュボードではなく、ほかの柱の判断材料を供給する役割を担うようになる、という変化だと言えます。

📝 補足 この位置づけ直しは、SIEM という仕組み自体を入れ替えることを意味しません。多くの場合、既存の SIEM の分析結果を、ポリシーエンジンが参照できる形で連携させる、統合の設計課題です。製品の導入というより、情報の流れをどう設計するかという課題である点を押さえておいてください。

自動化とオーケストレーション——自動遮断の怖さ

継続的検証や振る舞い検知によって異常が検知されたとき、その対応を人手で行うか、自動化するかは、横断的機能における重要な設計判断です。自動化とオーケストレーションは、判断や対応を、人の介在なしに実行する機能を指します。

自動化には明確な利点があります。深夜や休日であっても、異常を検知した瞬間に対応できるため、対応の遅れによる被害の拡大を防げます。人手による判断を待っていては、対応が間に合わない場面も少なくありません。

しかし、自動化には、それと表裏一体のリスクがあります。誤検知にもとづいて自動的にアカウントをロックしたり、通信を遮断したりすると、正当な業務が突然止まってしまいます。深夜に海外出張中の役員が、普段と異なる場所からアクセスしただけで自動的にアカウントがロックされ、緊急の意思決定ができなくなる、といった事態は、決して珍しい話ではありません。

自動遮断の怖さは、判断の速さそのものにあります。人が確認する時間的な余裕がないまま、影響の大きい対応が実行されてしまうため、誤検知が起きたときの被害が、検知の見逃しとは別の形で組織に跳ね返ってきます。

この怖さに対処するために、実務では、対応の影響度に応じて自動化の水準を段階的に分けることが一般的です。

影響度	対応の例
低い（通知のみ）	管理者に警告を通知するだけで、アクセス自体は止めない
中程度（一時的な制限）	追加の確認を自動的に要求し、通過すればアクセスを継続できる
高い（遮断）	アクセスを自動的に遮断するが、解除には人の確認を必須とする

すべての異常検知に対して、いきなり最も強い自動遮断を適用するのではなく、影響度に応じて対応の強さを分け、特に業務への影響が大きい対応には、人の確認を組み込む設計が、自動化とオーケストレーションを安全に運用する鍵になります。

自動化の範囲を広げる順序にも、考慮すべき点があります。まずは「通知のみ」の水準から自動化を始め、誤検知の発生率を実際の運用で確認しながら、精度に自信が持てた領域から段階的に「遮断」まで踏み込んでいくのが、安全な進め方です。導入初期からすべての対応を自動遮断で構成してしまうと、振る舞い検知の節で触れたとおり、学習期間中の誤検知がそのまま業務停止に直結してしまいます。オーケストレーションという言葉が示すとおり、複数の仕組みをどの順序で、どう組み合わせて動かすかという設計そのものが、この横断的機能の実質的な作業です。

⚠️ 注意 「自動化すればするほど安全になる」という発想は、この節で見た誤検知のリスクを見落としています。自動化とオーケストレーションの成熟度を上げるとは、単に自動化の範囲を広げることではなく、影響度に応じた適切な自動化の水準を設計することを意味します。

ガバナンスと例外管理

横断的機能の 3 つ目、ガバナンスは、ここまで見てきたポリシーの策定、信頼スコアの計算方法、自動化の範囲といった判断を、誰が、どのように決め、見直していくかという仕組みです。

ゼロトラストの設計は、一度作って終わりではありません。脅威の状況、業務の実態、組織の構造は、時間とともに変化します。ガバナンスが弱い組織では、ポリシーが一度設計されたまま放置され、業務の変化に合わなくなった例外的な設定が積み重なっていきます。レッスン 3 で触れた「例外だらけになり形骸化する」というつまずきは、まさにガバナンスの弱さから生じる典型的な症状です。

例外管理を機能させるためには、次のような仕組みをセットで運用する必要があります。

例外の申請と承認のプロセス：誰が、どのような理由で、どの期間だけ例外を認めるのかを、明文化された手順で申請・承認する
有効期限の設定：例外は原則として恒久的なものにせず、期限を区切り、期限が来たら再申請するか、通常のポリシーに戻すかを判断する
定期的な棚卸し：どれだけの例外が、どの理由で存在しているかを、定期的に一覧化して見直す
責任の所在の明確化：例外を承認する権限が誰にあるのか、組織として明確にしておく

ガバナンスは、地味で目立たない機能ですが、5 つの柱と、可視化と分析、自動化とオーケストレーションという、ここまで見てきたすべての設計を、長期にわたって機能させ続けるための土台です。柱ごとの技術的な設計がどれだけ精緻でも、ガバナンスが機能していなければ、時間の経過とともに実態と乖離していきます。

例外管理台帳の例

レッスン 5 の講師の現場メモで触れた「残った VPN 経由の通信を一覧化した台帳」は、この例外管理の具体的な実践例でした。同じ発想は、VPN に限らず、ゼロトラストの設計全体に適用できます。

項目	記録する内容の例
例外の対象	どのシステム、どの利用者、どの通信が、通常のポリシーの対象外になっているか
申請理由	なぜ例外が必要なのか、業務上の背景
承認者	誰が、どのような権限にもとづいて例外を承認したか
有効期限	いつまでの例外か、期限が来たらどう再判断するか

このような台帳を整備し、定期的に棚卸しする運用が、ガバナンスを「掛け声」で終わらせず、実際に機能する仕組みに変えます。

横断的機能の成熟度を段階で見る

レッスン 2 で紹介した 4 段階の成熟度を、横断的機能に当てはめると、次のような姿になります。

段階	横断的機能での典型的な状態
伝統的	ログは部門ごとに散在し、異常への対応はすべて手作業。例外の記録も残っていない
初期	一部のログが SIEM に集約され、明らかな異常には手作業で対応している
高度	継続的検証や振る舞い検知が一部の柱で稼働し、影響度の低い対応は自動化されている
最適	5 つの柱の情報がリアルタイムに統合され、影響度に応じた自動化とガバナンスが一貫して機能している

横断的機能は、5 つの柱それぞれの成熟度が一定水準まで上がって初めて、本格的に機能し始める性質を持ちます。柱の情報が乏しい段階で横断的機能だけを高度化しようとしても、集約すべき情報そのものが不足しているため、投資が効果に結びつきにくくなります。この関係を見誤ると、「横断的機能に多額の投資をしたのに、成果が見えない」という不満が経営から出やすくなります。柱の成熟度と横断的機能の成熟度は、常にセットで進捗を管理する必要があります。

まとめ

このレッスンでは、以下のことを学びました。

横断的機能は、5 つの柱が集めた情報を束ね、組織全体で活用できる形に変える役割を担う
継続的検証は、セッションが始まったあとも状況の変化に応じて評価をやり直す仕組みである
信頼スコアは複数のシグナルを一つの数値にまとめる仕組みだが、不透明になりやすく、精度への過信を招きやすい
振る舞い検知は、普段の行動パターンから外れた振る舞いを検知し、盗まれた認証情報による不正アクセスにも対処できる
SIEM は、事後の検知装置から、ポリシーエンジンの判断を支える入力源へと位置づけを広げられる
自動化とオーケストレーションは対応の速さという利点がある一方、誤検知による自動遮断が業務を止めるリスクを持つため、影響度に応じた段階的な設計が必要である
ガバナンスと例外管理は、ここまでのすべての設計を長期にわたって機能させ続けるための土台になる

次のレッスンでは、ここまで学んできた 5 つの柱と横断的機能を、3 年規模の移行ロードマップとして統合します。パイロットの選び方から、経営への説明のしかたまで、実際に組織を動かす段階に踏み込みます。

確認クイズ

このレッスンの理解度をチェックしましょう。