日曜の夜、あるシニアエンジニアが、認証サービスに一見すると通常のアップデートをプッシュします。変更セットは大規模なリファクタリングの中に埋もれており、単体テストも結合テストもすべて通過しています。ところが、その中には、ハードコードされたバイパストークンを受け入れ、有効な認証情報を内部のデバッグストリームへひそかに記録する、目立たないコードパスが仕込まれていました。その後1週間にわたり、同じエンジニアは、それまで触れたことのない多数のリポジトリをクローンし始め、競合他社への転職を発表する数日前には、それらを管理対象外のノートPCに同期し始めます。Gitにおける異常なアクセスパターンや、認証イベントの不審な急増に誰かが気づく頃には、貴社の中核サービスはすでに改ざんされ、中核的な知的財産（IP）は持ち出された後です。これこそが、最も深刻な形のインサイダーリスクです。正規のID、使い慣れたツール、そして適切なコンテキストで見なければ通常業務にしか見えないアクティビティとして実行される、コード窃取やコード改ざんです。
インサイダーリスクとは、システム、データ、プロセスに正当なアクセス権を持つ人が、意図的または非意図的に損害を引き起こすリスクです。インサイダー脅威は、その中でも明確に敵対的な行為にあたるもので、知的財産の窃取、システムの妨害、アクセス権の売買などが含まれます。実際の環境では、不注意によるミス、侵害されたID、そして強い悪意を持つ内部関係者まで、その全体像が現れます。
構造的に見ると、これは外部脅威検知とは異なります。外部攻撃は通常、信頼境界の外側から始まり、脆弱性や設定不備を突いて内部へ侵入してきます。一方、インサイダーインシデントは、有効なID、承認済みデバイス、そしてGit、Google Workspace、Microsoft 365、Slack、Salesforce、クラウドコンソールといった正規のチャネルから始まります。プロトコルレベルでは、こうしたトラフィックの多くは通常業務とまったく同じように見えます。
インサイダーリスクのコストに関する最近の調査では、組織あたりの年間平均コストは約1,700万ドルと推計されています。さらに、記録されたインサイダーインシデントの約4分の3は、明確な悪意を持つ内部関係者ではなく、不注意なユーザーや攻撃者にだまされたユーザーといった、悪意のない内部者によって引き起こされています。悪意ある内部関係者や侵害されたアカウントは依然として大きく報じられますが、日常的なコストの大部分は、強力なツールを扱う一般ユーザーがリスクの高い判断を下すことによって生じています。
インサイダーリスクの3つの典型類型
インサイダーに関する議論の多くは、実運用環境でセキュリティチームが実際に目にする、次の3つの典型類型に集約されます。
- ミスをしたり、危険な近道を取ったりする、不注意なユーザーまたは過度な負荷がかかっているユーザー
- 窃取、妨害、恐喝を目的として、意図的にアクセス権を悪用する悪意ある内部関係者
- 外部の攻撃者に正規アカウントを乗っ取られた、侵害済みのID
不注意なユーザーと意図しない情報露出
Toyota T-Connectの事案は、悪意のないインサイダーリスクの典型例です。委託先の担当者が、テレマティクスサービスのソースコードの一部を誤って公開GitHubリポジトリにプッシュしてしまい、その中には顧客データサーバーにアクセスするためのハードコードされたアクセスキーも含まれていました。そのキーは約5年間にわたって公開されたままとなり、約30万人の顧客に影響が及んだ可能性があります。エクスプロイトチェーンも、新しいマルウェアもありません。ただ、コード内のシークレット情報と、通常の作業をしているつもりだった人物の公開リポジトリがあっただけです。
セキュリティチームは、これと似たパターンを日常的に目にしています。たとえば、利便性のために社内ツールを個人のGitHubにプッシュするエンジニア、機密レポートを個人のクラウドストレージにエクスポートするアナリスト、納期に間に合わせるため承認されていない保存先へデータをコピーする従業員などです。
悪意ある内部関係者と報復
その対極にいるのが、環境を理解したうえで、その知識を意図的に悪用する内部関係者です。つい最近、CrowdStrikeは、内部関係者が社内システムのスクリーンショットを撮影し、SSO認証CookieとともにTelegram上のScattered Lapsus$ Huntersグループに共有していたことを確認しました。報道によれば、その見返りとして報酬が支払われたとされています。同社はこのインシデントを迅速に封じ込めましたが、高度な統制を敷くセキュリティベンダーであっても、内部から狙われ得ることを改めて示す事例です。
ヒューストンの廃棄物管理に関する事例は、オフボーディングの失敗パターンを非常に明確に示しています。解雇された元請負業者が、別の請負業者になりすまして再びアクセス権を獲得し、その後PowerShellスクリプトを実行して約2,500件のパスワードをリセットしました。この行為により、全米の従業員がシステムから締め出され、記録上86万ドル超の損失が発生しました。これは、完全に正規のツールと権限を使った、報復的な悪用でした。
内部関係者のように振る舞う侵害済みID
侵害されたIDは、内部者と外部攻撃者の境界を曖昧にします。Ponemonの調査でも、認証情報が盗まれて悪用される「だまされた内部者」が、インサイダーインシデントの主要カテゴリとして明確に追跡されています。実際には、こうしたアカウントは悪意ある内部関係者とほぼ同じように振る舞います。
攻撃者が有効なSSOセッションや利用可能なVPN認証情報を入手すれば、Gitリポジトリのクローン、Google DriveやSharePointファイルの持ち出し、SaaSプラットフォーム上での特権操作、放置されたサービスアカウントを経由した横展開などが可能になります。SIEMから見れば、それは成功したログインと許可済みAPIコールの連続にすぎません。このアクティビティを現実的に見抜く唯一の方法は、その時点の業務コンテキストに照らして、そのIDの行動パターンが不自然であることを捉えることです。
なぜUEBAや異常検知はインサイダーに苦戦するのか
多くのセキュリティアーキテクチャは依然として、外部脅威、すなわち悪意ある攻撃者を外にとどめることを主目的として最適化されています。これに対し、インサイダー脅威の検出が本質的に難しいのは、クエリ実行やファイルダウンロードといった通常業務と悪意ある行為の違いが、しばしば行為そのものではなく意図にあるからです。この微妙な違いのため、SIEMやUEBAのような従来型ツールは、あらゆる異常を検知してアナリストをノイズに埋もれさせるか、しきい値を下げて微妙で長期的なデータ窃取を見逃すかという、厳しいトレードオフを迫られます。
AI SOCツールは、検知感度を犠牲にせずにこのジレンマを解消します。これらのプラットフォームは、検知段階で絞り込むのではなく、不審なシグナルを広く取り込み、そのうえで、フィルタリングされた深い組織コンテキストと技術コンテキストを与えられた大規模言語モデル（LLM）を活用できます。たとえば、プロジェクト都合による正当なアクセス増加と、不正なダウンロードを見分けるように、「何が起きたか」だけでなく「なぜ起きたか」を瞬時に分析することで、AIは誤検知を積極的に除外し、本当にリスクを示す事象だけを浮かび上がらせることができます。
UEBA製品やSIEM製品は、たとえば通常と異なる場所からのログインといった異常は検出できますが、一般には「それがなぜ重要なのか」という問いには答えられません。そこに業務コンテキストや技術コンテキストが欠けているからです。組織図、プロジェクトの担当情報、人事イベントなどは通常別々のシステムに存在するため、セキュリティチームが全体像を把握できるのは、検知時ではなく手動調査の段階になってからです。
テレメトリ上でインサイダーリスクはどう現れるか
抽象論を実際の統制に落とし込むには、具体的な挙動と、それがログ上でどう見えるかを確認するのが有効です。以下のシナリオは、不注意な内部者、悪意ある内部者、侵害済みIDを組み合わせたものであり、セキュリティプラットフォームがサポートすべき検出パターンに直接対応します。
異常なソースコードアクセスとクローン
退職を予定しているエンジニアが、機密性の高いサービスを含め、これまで関与していなかった多数のリポジトリをクローンし始めるケースを考えてみましょう。あるいは、侵害されたSSOセッションが悪用され、ビルドランナーから大量のgit clone処理がスクリプト化されて実行されるケースもあります。
テレメトリ上では、単一のIDによるGitアクセスが急増し、その多くはユーザーの過去の担当範囲に含まれないリポジトリに向けられています。プロトコル自体は正常です。異常なのはパターンです。
有効な検出は、各ユーザーおよびピアグループのベースラインとなるアクセスパターンを動的に学習し、特に高機密または制限付きとしてタグ付けされたリポジトリに対する急激な逸脱を特定します。さらに、真のリスクとノイズを見分けるために、システムはGitやSSOログから得られる技術的テレメトリと、重要な業務コンテキストを統合し、一貫したインシデントナラティブを構築します。
ドキュメントおよびSaaSデータの大量ダウンロード
営業責任者による商談履歴全体のエクスポート、経理担当者による数年分の台帳データの取得、侵害されたアカウントによるGoogle DriveやSharePointファイルの大量ダウンロードは、インサイダー調査で繰り返し見られるパターンです。
ログ上では、大量エクスポート、レポートのダウンロード、管理操作に関するSaaS監査イベントに加え、ドキュメントアクセスや同期アクティビティの急増として現れます。Google Cloud DLPのようなシステムからデータ分類情報が取得できれば、単に件数を数えるだけでなく、機密度に応じてイベントを重み付けできます。
ノイズと有益なシグナルの違いは、たいていベースラインとコンテキストにあります。優れたプラットフォームは、経理部門における四半期末の通常アクセスがどのようなものか、退職予定のエンジニアによる不自然な情報収集がどのようなものかを理解しています。また、どのオブジェクトが給与ファイルで、どれが知的財産を多く含む設計文書なのかも把握しています。
オフボーディングや組織変更の前後に起きるアクティビティ急増
ヒューストンの請負業者の事例は、オフボーディング失敗の極端な例です。これより小規模でも深刻なインシデントとして、退職予定者がひそかに文書を持ち出す、社内異動者が不要になった旧権限を保持し続ける、請負業者が契約終了後も長期間ログインを継続するといったケースが数多くあります。
ここで重要になるシグナルは、退職予定日や契約終了日といったHRデータ、アカウント状態に関するIDシステム上の記録、さらに特権操作やデータアクセスの異常です。優れたセキュリティプラットフォームであれば、退職者や異動者を高感度対象としてマークするコンテキストルールを追加でき、そうした移行の前後数週間に発生した異常の優先度を引き上げ、推奨される緩和策も提示できます。
休眠アカウントと過剰権限アカウント
休眠中のアカウントやスコープ設定が不適切なアカウントは、比較的小さな侵害でも大きな被害へと発展させかねません。典型例としては、ほとんど使われないにもかかわらずドメイン全体に及ぶ権限を持つサービスアカウント、明確な所有者がいない緊急用管理者アカウント、あるいは1つか2つのSaaSプラットフォーム上でまだ有効なままの元従業員アカウントなどがあります。
IDインベントリ、IAM監査ログ、権限グラフを見れば、ほとんど何もしていないにもかかわらず広範な権限を持つアカウントが見えてきます。そうしたアカウントのいずれかが、異常なログイン、新しい場所からのアクセス、または影響の大きい操作を始めた時点で、操作者が社内か社外かにかかわらず、それはインサイダー型インシデントです。
セキュリティプラットフォームは、影響度の高い休眠IDを継続的に可視化し、それらをオフボーディングや権限レビューのプロセスに組み込み、そうしたアカウントからの新たなアクティビティを高優先度のシグナルとして扱うべきです。
インサイダーを意識したセキュリティの設計指針
インサイダーリスクを検出するセキュリティプラットフォームは、IDが時間を通じて機密資産とどのように相互作用しているかに注目する必要があります。
関連するテレメトリを、IDプロバイダー、IAMシステム、SaaSプラットフォーム、コラボレーションツール、開発者向けツール、そして可能であればエンドポイントやネットワークから取り込みます。目的はログをため込むことではなく、誰が、何を、どこで、どのデータに対して行ったのかを再構築することです。
また、Google Cloud DLPのようなシステムから出力されるデータ分類結果を統合し、すべての検知において、行動だけでなく対象オブジェクトの機密性も評価できるようにします。
さらに、ベースラインとピアグループをファーストクラスのエンティティとして構築・維持し、それらを検知ロジックに直接反映させます。これにより、たとえばシニアエンジニアが新しいコードベースに立ち上がる過程で行う探索的なアクセスと、同じエンジニアが退職前にIPを持ち出しているようなアクセスとを区別できます。
加えて、どのVPN接続元が通常想定されるのか、どの従業員や請負業者が高リスクなのかといった、組織固有の知識を反映するコンテキストを追加できる必要があります。
そして最後に、重視すべきはイベントではなくインシデントです。関連性の薄い多数のアラートを提示するのではなく、たとえば退職予定のエンジニアが同じ時間帯に新しいリポジトリをクローンし、機密文書をダウンロードし、アクセス制御まで変更した、といった一連の活動を、説明可能なケースとして集約することが重要です。
インサイダー検知と調査に対するエクサフォースのアプローチ
エクサフォースでは、これらの機能を、SOCライフサイクル全体を支援する統合プラットフォーム内で、具体的な機能として提供しています。このプラットフォームは、インサイダー脅威に限らず、あらゆる脅威を高精度に検知・トリアージ・コンテキスト化し、明確でガイド付きの対応推奨を提供します。必要に応じて、自動修復も利用できます。
セマンティックな関連性と行動ベースラインに基づく脅威ファインディング
エクサフォースは、コード利用、SaaSドキュメントアクセス、クラウドIAMアクティビティ、管理操作などの領域にわたり、ユーザー、アカウント、部門、ピアグループ、そして組織全体の行動ベースラインに基づいて脅威ファインディングを生成します。誰かが突然、それまで触れたことのない多数のリポジトリをクローンしたり、異常な量のGoogle Workspaceファイルをダウンロードしたりした場合、システムは何百件もの個別アラートではなく、1件の脅威ファインディングとして提示します。このベースライン駆動型アプローチにより、アラート疲れを大幅に軽減しつつ、本当に疑わしい逸脱のみを、アナリストが迅速に判断するために必要な完全なコンテキスト付きで可視化できます。
組織固有のコンテキストを反映するBusiness Context Rules
エクサフォースのBusiness Context Rulesにより、チームは特定の人物やチームに関するコンテキストをエクサボットの調査コンテキストウィンドウに追加できます。たとえば、契約終了が近い請負業者をより厳しく監視したり、通常と異なるVPN接続元からの管理操作を高リスクとして扱ったり、四半期末や計画的休暇の時期のような、業務上正当なアクセス急増時にはしきい値を緩和したりできます。この柔軟なルールシステムにより、セキュリティチームは、長い学習サイクルを待たずに、組織の知識や業務ロジックを直接検知ロジックへ反映できます。
自動ノイズ低減と誤検知抑制
エクサフォースの自動ノイズ低減と誤検知抑制は、顧客ごとに最適化された、業務・技術・過去履歴に関する深い知識に基づいています。さらに、エクサフォースは関連シグナルを、トリアージやエスカレーションに必要なコンテキストをすでに含む1つのケースへ集約します。相関するイベントをインテリジェントにまとめ、既知の正常パターンを除外することで、チームは真にリスクを示すごく一部のアラートに調査リソースを集中できます。
自動およびトリガー実行型の対応アクション
エクサフォースにより、セキュリティチームは、自動実行される対応アクションと、人がトリガーする対応アクションの両方を通じて、インサイダーリスクインシデントへ迅速に対処できます。これらのアクションは即時実行も、承認のためのエスカレーションも可能です。たとえば、退職予定の従業員が機密リポジトリをクローンしていることを検知した場合、エクサフォースはその行動について本人と上長への確認を自動実行したり、アクティビティ要約の定期レポートをトリガーしたり、調査中のアクセス一時停止を実行したりできます。人による判断が必要なシナリオでは、アナリストが推奨アクションを確認し、ワンクリックで実行できる承認ワークフローもサポートします。チームは、一般的なインサイダーシナリオ向けの標準レスポンスアクションを利用することも、IDプロバイダー、SaaSプラットフォーム、コミュニケーションツールをまたいで複数段階の対応を調整するカスタムAutomation Agentワークフローを構築することもできます。
インサイダー脅威調査と脅威ハンティングの簡素化
エクサフォースは、Data ExplorerのBIライクなインターフェースと、エクサボット検索の自然言語クエリにより、インサイダー脅威の調査を簡素化します。これにより、セキュリティアナリストは、IDのタイムライン、アクセスパターン、資産間の関係性をすばやくたどれます。最前線のアナリストでも、複雑なクエリを書くことなく、また脅威ハンティングの専門担当者を待つことなく、潜在的なインサイダーインシデントを即座に調査できます。
未使用または過剰権限アカウントの継続的な検出
エクサフォースは、依然として広範な有効アクセス権を持つ未使用アカウントや過剰権限アカウントを継続的に検出し、それをインサイダーリスク検知と、影響範囲の縮小やオフボーディング強化につながる修復ワークフローの双方に反映します。利用頻度の低い認証情報や過剰な権限を、悪用される前に事前特定することで、組織は攻撃対象領域を縮小し、単にインシデントを検出するだけでなく、未然に防ぐことができます。
高リスクユーザーへのタグ付けによる適切な強度の監視
エクサフォースでは、退職予定者や外部請負業者など、特定のユーザーを高リスクとしてタグ付けし、その行動に対する感度を高めることができます。この追加コンテキストにより、Knowledge Modelは重要な対象に対して適切な強度で監視を行い、組織全体のユーザーからのアラートでアナリストを圧倒することなく、機微なアカウントにおける不審な振る舞いを捉えられます。
SaaSプラットフォームのネイティブコンテキストの活用
エクサフォースは、Google Workspaceなどのシステムが持つネイティブなデータ分類ラベルを統合し、既存の機密性ラベルを自動的に取り込みます。これらのラベルにより、対象となるファイルや資産に、機密情報やPIIが含まれているかどうかが、常に検知やリスクスコアへ反映されます。既存のデータ分類システムと直接統合することで、重複したラベル付けが不要になり、すべての資産について、真の業務価値と機密性がリスク評価に自動反映されるようになります。
SaaS、クラウド、ID、AIプラットフォームにまたがる包括的なデータソースカバレッジ
エクサフォースは、Google Workspace、Microsoft 365、Slack、GitHub、GitLab、Salesforce、Okta、AWS、Azure、GCP、OpenAIをはじめとする、現代のエンタープライズ環境における幅広いプラットフォームからテレメトリを取り込みます。この広範なカバレッジにより、分散したツール環境全体で発生する重要なアクティビティを見逃すことなく、IDが利用され、機密データが存在するあらゆるシステムにわたって、不審な挙動を相関分析できます。
セキュリティの重要分野としてのインサイダーリスク
インサイダーリスクは、セキュリティ計画における例外的なテーマではなく、運用上の中核課題へと変化しています。組織あたり年間1,700万ドル、しかもインシデントの4分の3が悪意のない行為に起因するという現実から見ても、この脅威は高コストかつ広範です。現在では、あらゆる正規認証情報が、クラウド環境、SaaSプラットフォーム、コードリポジトリへのアクセスを握っており、これらを誤って扱えば事業に重大な損害を与えかねません。そのため、この課題は、意図的な妨害だけでなく、一般社員のミスへの対応でもあります。
インサイダーリスクを第一級のセキュリティ分野として扱うには、部門横断的なプログラムと、コンテキストが豊富なプラットフォームの両方への投資が必要です。プログラムは、自組織において何が許容できない行動なのか、どのように監視と適正な配慮のバランスを取るのか、シグナルが現れた際にどう対応するのかを定義します。プラットフォームは、そうしたシグナルを早期に把握し、一貫して行動するために必要なテレメトリ、分類、ベースライン、業務コンテキストを提供します。ここで、従来型セキュリティツールからAI活用型プラットフォームへの転換が重要になります。従来のSIEMやUEBAでは、四半期末レポートを準備する経理アナリストと、退職前に顧客データを持ち出している同じアナリストとを区別できません。エクサフォースは、コンテキストをファーストクラスの機能として扱い、行動ベースライン、Business Context Rules、データ分類を組み合わせることで、技術的な異常しか見ないツールでは見逃されるインサイダーリスクのパターンを正確に検出します。
最もうまく対応できる企業は、重大インシデントに追い込まれる前に、今のうちからインサイダーに対する可視性と対応力を構築し始める企業です。不注意、侵害、悪意のいずれであっても、内部者は常に貴重なシステムやデータへ至る経路を持っています。セキュリティおよびリスクの責任者に問われているのは、通常のアクセスが通常ではなくなり、真のリスクに変わる瞬間を組織が見極められるかどうか、そしてその違いを大規模に見分けられるプラットフォームを備えているかどうかです。
