クラウド認証ログに潜む死角
クラウドの認証ログには攻撃者が悪用する重大な欠落がある。Azureのサインインログ回避事例から検知エンジニアリングの教訓を読み解く。
Priya Sharma
TrustedSecのセキュリティチームは最近、Azureのサインインログを回避する3つ目と4つ目の手法を公表した。Microsoftのクラウドサービスに、セキュリティチームが検知に頼るログには記録されない形で認証できる独立した手法が4つ揃ったことになる。サインインは実際に行われた。しかしログには残らなかった。そのログで不審な活動を監視していた人は、何も見えていなかった。
これは理論上の問題ではない。攻撃者が認証情報を盗んでAzure環境にアクセスした場合、セキュリティチームがまず確認するのはサインインログだ。そのログが不完全で、認証の種類によってはログが一切残らないとしたら、検知能力には自覚のない穴があることになる。そして、ログは完全だという前提でセキュリティ上の判断を下してきたことになる。
認証ログに欠落が生まれる理由
単純に考えれば、認証ログの仕組みは簡単だ。誰かが認証したら、それをログに記録する。しかし実際のクラウド認証は、数十のプロトコル、エンドポイント、トークン種別が入り組んだ大規模なシステムであり、ログの取得範囲はそれぞれで異なる。
Azure Active Directory（現Entra ID）は、Microsoft 365、Azureリソース、SAML/OIDCで接続するサードパーティアプリ、App Proxy経由のオンプレミスのレガシーアプリ、サービスプリンシパル、マネージドID など、多くの認証経路を扱う。それぞれの経路には専用のバックエンド、ログのパイプライン、固有のエッジケースがある。サインインログは認証サービスが生成するが、一部の認証フローは標準のサービスを経由しなかったり、現在のログ基盤より前からある旧来の経路を使ったりする。
レガシープロトコルの欠落
Microsoftは2000年代初頭の認証プロトコルとの後方互換性を維持している。これらは現在のログ基盤より前に作られたものだ。SMTP、IMAP、POP3の一部の認証は「Basic Auth」というフローを使い、標準のAzure ADトークンエンドポイントではなく、メール転送層で認証を行う。こうした認証は、モダンなOAuth/OIDCフローが生成するのと同じサインインログを残さないことがある。
MicrosoftはBasic Authの非推奨化を何年も前から進めているが、企業環境では移行が遅い。レガシーなメールクライアント、ドキュメントをメール送信するスキャナー、古い基幹業務アプリケーションを抱える組織では、Basic Authがまだ有効になっていることがある。レガシー経路のひとつひとつが、ログの欠落につながる可能性がある。
サービスプリンシパルの認証
サービスプリンシパルは、アプリケーションや自動化処理が使う人間ではないIDであり、ユーザーとは異なる方法で認証する。そのサインインイベントは別のログストリーム（サービスプリンシパルのサインイン、対話型サインイン、非対話型サインイン）に現れる。対話型サインインのログだけを監視しているセキュリティチームは、サービスプリンシパルの活動を完全に見落とす。
これは重要だ。侵害されたサービスプリンシパルは一般的な攻撃経路だからだ。サービスプリンシパルの認証情報や証明書を手に入れた攻撃者は、そのアプリケーションとして認証し、与えられた権限の範囲でリソースにアクセスできる。セキュリティチームがユーザーのサインインだけを見ていれば、この動きは決して見えない。
トークンのリプレイと更新
すべてのアクセスが新たな認証を伴うわけではない。OAuthのリフレッシュトークンは、再認証なしでアクセスを継続させる。攻撃者が有効なリフレッシュトークンを盗めば（侵害されたデバイス、傍受された通信、マルウェアなどによって）、パスワード認証で生じるのと同じサインインログを発生させずに、新しいアクセストークンへ交換できる。最初のサインインはログに残るが、以降のトークン更新は非対話型サインインとして現れることがあり、多くの検知ルールはそれを監視対象にしていない。
検知エンジニアリングの課題
認証ログの欠落は、クラウドセキュリティにおけるより大きな問題を浮き彫りにする。完全だと想定したログの上に検知の仕組みを構築しておきながら、ログを残さない経路を攻撃者が見つけると驚いてしまう、という問題だ。
クラウド環境の標準的なセキュリティ構成は次のようなものだ。クラウドサービスがログを生成 → ログをSIEM（Security Information and Event Management：セキュリティ情報イベント管理システム）に送る → 検知ルールが不審なパターンを分析 → アラートが調査を起動する。これは、ログが関連する活動をすべて捉えている場合に限って機能する。捉えていなければ、SIEMは不完全な全体像を監視するための非常に高価な手段にすぎない。
Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.実際にできること
クラウドプロバイダーのログの欠落を直接修正することはできない。それはMicrosoft（あるいはAWSやGoogle）の仕事だ。しかし、認証ログが完全であることだけに依存しない検知戦略は構築できる。
複数のログソースを監視する
認証ログは信号のひとつにすぎない。アクティビティログも別の信号だ。攻撃者のサインインが認証ログに現れなくても、その後の行動（メールの閲覧、ファイルへのアクセス、データベースへのクエリ、設定の変更など）は、それぞれ独自のログエントリを生成する。アクティビティログと認証ログを相関させると矛盾が見えてくる。直近の対応するサインインがないIDからの活動は、サインインがなぜログに残らなかったかに関係なく不審だ。
-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5 // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypassレガシー認証を無効化する
レガシープロトコル（SMTP、IMAP、POP3のBasic Auth）を使っていないなら、無効化しよう。近代的なログ基盤を迂回する認証経路そのものが使えなくなるため、ログの欠落カテゴリ全体を潰せる。Azureの条件付きアクセスポリシーでは、レガシー認証をユーザー単位、グループ単位、またはテナント全体でブロックできる。
無効化する前に、現在の利用状況を監査すること。皮肉なことに、Azureのサインインログには一部のレガシー認証の試行が記録される。また、レガシー認証向けのEntra IDワークブックを使えば、古いプロトコルをまだ使っているアプリケーションを特定できる。先にそれらのアプリケーションを修正し、その後でレガシー認証をブロックしよう。
トークンの活動を監視する
環境が対応しているなら、継続的アクセス評価（CAE）を導入しよう。CAEを使うと、条件が変化したとき（ユーザーの無効化、高リスクのサインイン検出、IPの位置情報の変化など）にAzure ADがほぼリアルタイムでトークンを失効させられる。CAEがなければ、盗まれたアクセストークンはセキュリティチームが何をしようと、通常は1時間の有効期限が切れるまで有効なままだ。
トークンの有効期間と更新のパターンも監視しよう。リフレッシュトークンが新しいIPアドレス、新しいデバイス、あるいは通常と異なる時間帯から使われた場合は、フラグを立てるべきだ。これはトークン盗用の唯一の兆候であることも多い。
自社のログをテストする
最も効果の大きい施策は、ログが本当に想定どおりの内容を捉えているかを定期的に検証することだ。環境がサポートする各方式で認証してみよう。対話型、非対話型、サービスプリンシパル、レガシープロトコルなどだ。そして、それぞれが期待どおりのログエントリを生成するかを確かめる。生成されなければ、攻撃者より先に穴を見つけたことになる。
これは、体系的に実施している組織がほとんどない検知エンジニアリングのテストだ。多くのチームは検知ルールを書いて、動くと信じ込んでいる。ルールが依存するイベントが実際にログに残っているかを確認し、基盤となるデータ品質を検証することは、ルールそのものよりおそらく重要だ。
より広い教訓
Azureのサインインログの回避は、Microsoftに固有の問題ではない。どのクラウドプロバイダーにも、ログが不完全な認証経路がある。AWS CloudTrailにも既知の欠落があり、一部リージョンの特定のコントロールプレーン操作、特定のサービスリンクロールの引き受け、元のIDを見えにくくするクロスアカウントのロール連鎖パターンなどがある。Google Cloudの監査ログにも似たエッジケースがある。
教訓は「Azureのログは壊れている」ということではない。すべてのログは不完全であり、そう想定しないセキュリティ設計は必ず破綻する、ということだ。多層防御とは、単に複数のセキュリティ対策を持つことではなく、独立した複数の可視化ソースを持つことだ。検知が単一のログソースの完全性だけに依存しているなら、セキュリティ態勢には単一障害点がある。
どのログソースも不完全であったり、迂回されたりしうるという前提で検知を組み立てよう。認証ログ、アクティビティログ、ネットワークログ、エンドポイントのテレメトリを相関させる。ソース間の矛盾を探そう。矛盾はまさに攻撃者が悪用する欠落を指し示していることが多い。そして定期的にログをテストしよう。自分が知らない欠落こそ、攻撃者に使われるものだからだ。
