クラウドの4万件超のIDを行動パターンで分類 — Palo Alto Unit 42が、なりすましを見抜くための検知手法を公開

Palo Alto Networksの脅威研究チーム「Unit 42」は2026年9月14日、クラウド上のID（ユーザーやサービスが使うアカウント）が実際に実行した操作を監査ログから学習し、その役割を自動で分類する研究を公開した。125のクラウド環境にまたがる4万件超のIDを2カ月分分析したもので、研究者のOsher Jacob氏が執筆している。分析の対象は、AWSの監査ログであるAWS CloudTrailだ。

研究の狙いは、「そのIDが何をできるか」ではなく「実際に何をしたか」でIDを分類することにある。Unit 42は、割り当てられた権限と実際の行動を分けて扱うことで、攻撃者が正規のIDになりすまして紛れ込む動きを見つけやすくなると説明している。

「権限」と「行動」は別物 — 何を解こうとしたのか

Unit 42は論文の中で、検知の難しさを具体的な問いとして示している。あるIDが環境内の全リソースを列挙したとき、それが日常業務として定期スキャンを行うセキュリティ製品なのか、それとも1つのストレージだけを扱うはずのバックアップ用IDが侵害された動きなのかは、権限を見ただけでは区別できない。

同社は、この違いを「できること」と「実際にやること」の差として整理する。前者は割り当てられた権限の話で、監査にはCSPM（クラウドセキュリティ態勢管理）が使われる。後者は実際に実行された操作の話で、こちらはCDR（クラウド検知・対応）の領域だ。Unit 42は、業界標準として最小権限の原則が推奨されているものの、現実には過剰な権限を持つIDが多く残り、設定の不備や可視性の不足、開発を止めたくない事情などから、何年も問題を起こさずに存在し続けていると指摘する。

対象となる操作の数も膨大だ。AWSが提供する240のサービスに対して、IDが呼び出せる操作は1万5,000以上ある。Unit 42は、この広さの中で「共通の行動パターンは存在するのか」「管理者やDevOps、バックアップ、セキュリティ製品といった役割の足跡を確実に区別できるのか」を問いとして立てた。

4万件超のIDは、役割ごとにはっきり分かれた

Unit 42は、認証（ConsoleLogin、GetSigninToken）や偵察（ListBuckets、ListRoles）といった観測されたAPI操作を手がかりに、IDの行動を分析した。

分析では、それぞれのIDが呼び出した操作を座標として2次元に配置した「行動マップ」を作成している。このマップでは、30の大きなクラスタが約2万件のIDを占め、位置が近いIDほど行動が似ていることを示す。Unit 42によれば、クラウドIDは組織をまたいでも似た行動を取る傾向が強く、同じ役割に対応しやすいという。

Unit 42はこうした傾向を、4つの方法を組み合わせて検証した。

• 操作の頻度: クラスタ内でよく呼ばれる操作を調べる
• クラス別スコア（c-TF-IDF）: そのクラスタだけに特徴的な操作を抽出する
• 属性によるマッピング: 特定の操作やサービス、名前の一部でIDを絞り込む
• 命名パターン: クラスタ内で共通する名前の部分文字列を探す

検証の例としてUnit 42が取り上げたのが、約5,000件のIDが100以上のクラウドプロジェクトにまたがる「管理ユーザー」のクラスタだ。このクラスタでは約94%のIDがConsoleLogin（AWSマネジメントコンソールへのサインイン）を実行しており、他のどのクラスタでもConsoleLoginを実行したIDは1%未満だった。あわせて約60%のIDが、コンソールの既定動作に伴うGetCostAndUsageやGetCostForecastも呼び出していた。

命名パターンの分析でも裏付けが取れた。Unit 42は、恣意的なキーワード検索ではなく一般化接尾辞木（Generalized Suffix Tree）を使ってクラスタ内で頻出する部分文字列を機械的に抽出し、上位に「AWSReservedSSO_AdministratorAccess_」（AWS IAM Identity CenterでAdministratorAccessを割り当てたときに自動生成される接頭辞）を見つけた。同社は、頻度・c-TF-IDF・属性・命名の4つの結果が一致したことから、このクラスタは管理ユーザーだと結論づけている。

人間のIDも機械のIDも、同じ手順で分類できた

Unit 42は、管理ユーザーで行ったのと同じ手順をデータセット全体に適用し、人間が使うIDと機械（サービス）が使うIDの双方について、再現性のあるクラスタが得られたと報告している。同社が役割として識別したのは次の7種類だ。

• DevOps
• Infrastructure as Code（IaC）のランナー
• CI/CD（継続的インテグレーション／継続的デリバリー）の仕組み
• セキュリティ製品
• バックアップエージェント
• ネットワーク関連のコンポーネント
• FinOps（クラウド費用管理）のプラットフォーム

分類の仕組み — 操作をベクトルにして、次元を下げてまとめる

Unit 42が公開したパイプラインは、監査ログの取り込み、前処理とベクトル化、次元削減、クラスタリングという4段階で構成されている。

まず同社は、呼び出せる操作の集合を「語彙」とみなし、IDが呼び出した操作の位置をtrueで示すブールベクトルとして各IDを表現した。語彙は1万5,000以上に及ぶため、このベクトルは次元が高く、ほとんどが0で埋まる疎なデータになる。次に同社は、高次元のデータを構造を保ったまま低次元へ圧縮するUMAPを適用し、1回目の処理で1万項目超のブール値からなるベクトルを32個の連続値からなる密なベクトルへ変換した。さらに、密度の高い領域を検出してまとめるHDBSCANで、各IDをクラスタに割り当てるか外れ値として扱った。

検知への実装 — 数十個の操作とSQLで役割を推定する

Unit 42はこの研究を、分析にとどめず検知に使う道筋まで示している。新しいIDの役割を判定するとき、毎回パイプライン全体を動かすのではなく、対象のクラスタごとに分類器を訓練して所属を判定する方式だ。DevOps用の分類器、セキュリティ製品用の分類器といった具合である。

同社は、元の疎なブールベクトルにそのままロジック回帰を適用する方法で精度よく分類できたと説明する。ロジック回帰は判断の理由を追いやすく、どの操作が所属確率をどれだけ押し上げ、あるいは引き下げるかを数値で確認できる。ただし語彙が膨大なため、L1正則化（Lasso）をかけて無関係な操作の係数を0にし、判定に効く数十個の操作と係数の組み合わせまで圧縮した。

この圧縮後のロジックは軽量で、Unit 42は標準的なSQLクエリの中に実装できるとしている。大規模な機械学習のパイプラインを常時動かさなくても、IDの役割を継続的に推定できることが利点だと同社は述べている。

Unit 42が示す位置づけ

Unit 42は結論として、態勢管理が「そのIDに何が許されているか」という基準線を与えるのに対し、行動を分析すると「実際に何を実行しているか」が分かると整理する。IDごとの機能上の基準線が分かれば、防御側はそこからの逸脱を素早くとらえ、防御回避の試みに気づき、インシデント対応を速められるとしている。

その例として同社が挙げるのが、バックアップサービスが突然、管理操作を実行したようなケースだ。権限だけを見る静的な分析では見過ごしやすいが、行動の基準線があれば異常として浮かび上がる。

同社はまた、この手法が他のクラウド事業者やKubernetes、SaaSの監査ログにも応用できると説明する。クラウド環境が複雑になるほど、こうした文脈を踏まえた検知が有効になるとしている。

なお同社は、この研究で示した行動の基準線を自社のCortex Cloudの検知エンジンに組み込み、誤検知の抑制と攻撃者のなりすましや設定変更の検知に役立てると説明している。

日本国内でもAWSを使う企業や自治体は多い。Unit 42は、この手法が他のクラウド事業者やKubernetes、SaaSの監査ログにも応用できると説明しており、静的な権限の確認と並行して、IDが平常時に何をしているかの記録を持つことを検知の出発点として示している。今回の研究はUnit 42が125のクラウド環境を分析した結果であり、同じ考え方を自組織に当てはめる場合は、自組織の監査ログでの確認が必要になる。

出典

• Palo Alto Networks Unit 42「Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection」（2026年9月14日、Osher Jacob氏）
  https://unit42.paloaltonetworks.com/behavioral-clustering-map-to-cloud-identities/
• 図1・図3・図4は上記Unit 42の記事より引用