Azureのサービスプリンシパル侵害、7分でリソース全消去された実例と防御策

Azure（Microsoftのクラウド基盤）でリソースの削除権限を持つサービスプリンシパル（アプリケーションやスクリプトがAzureにログインするための非対話型アカウント）を管理している方に向けた内容です。認証情報が漏洩した場合、どこまでの被害が起こり得るかを具体的な数字で確認していきます。

Microsoft Security Researchが2026年9月に公開した調査では、侵害された2つのサービスプリンシパルが1つのテナント（Azure契約単位の組織空間）内で並行して活動し、破壊的な削除シーケンスが約7分で完了したと報告されています。ストレージアカウントの削除試行は100件を超え、大半が成功したうえ、Key Vault（秘密鍵やシークレットの保管サービス）、Function App、App Serviceプランも削除されています。

何が起きたか：偵察から破壊、鍵収集までの流れ

攻撃はいきなり破壊行動から始まったわけではありません。まず1つ目のサービスプリンシパルが約15.5時間にわたり300件以上の読み取り・偵察操作を実行しています。サブスクリプションやVM、リソースグループの一覧取得など、権限の範囲を静かに調べる動きです。

その開始から約90分後、2つ目のサービスプリンシパルが登場し、2つのサブスクリプションにまたがるVMとリソースグループを約5秒で高速列挙しています。この時点ではまだ破壊行為はなく、標的の絞り込みだったとみられます。

最初の偵察開始から約16時間後、この2つ目のサービスプリンシパルが追加の偵察を行ったうえで、既存のAzure RBAC（ロールベースアクセス制御）権限を悪用し、ストレージアカウント、Key Vault、Function App、App Serviceプランを連続削除しています。破壊シーケンス自体は約7分、鍵収集まで含めた一連の操作は約35分で完結しています。

注目すべきは、Site Recoveryやバックアップの保護ロック（誤削除防止の仕組み）の削除も試みられていた点です。これは失敗に終わっていますが、攻撃側が復旧経路そのものを断とうとしていたことを示しています。破壊活動の終了から約30分後には、同じサービスプリンシパルがストレージアカウントを再列挙し、アクセスキーを取得するListKeys要求を30件以上成功させています。

なぜここまで被害が広がるのか：原因の分解

原因1: 過剰な権限付与

サービスプリンシパルがストレージアカウントやKey Vault、App Serviceプランの削除まで実行できていたということは、実際の業務で必要な範囲を超えた書き込み・削除権限が付与されていた可能性が高いといえます。最小権限の原則（必要最低限の権限のみ与える設計方針）が徹底されていれば、偵察はできても破壊はできない状態を作れます。

原因2: 認証情報の非対話的な性質

サービスプリンシパルはMFA（多要素認証）の対象外で運用されるケースが多く、パスワードやクライアントシークレット、証明書が漏洩すると、そのまま正規のAPI呼び出しとして扱われてしまいます。ARM API（Azure Resource Managerが提供する管理操作用のAPI）は認証さえ通れば人間かスクリプトかを区別しません。

原因3: 検知までの時間差

偵察開始から破壊までに約16時間、破壊から鍵収集までさらに30分という時間差があります。この間にAzure Activity Log（Azureのリソース操作履歴を記録するログ）を確認する仕組みが機能していれば、偵察段階で異常な読み取り件数に気づけた可能性があります。

原因4: リソースロックの限界

リソースロック（誤削除・変更を防ぐAzureの機能）は便利ですが、削除ロック自体を削除する権限を攻撃者が持っていれば意味がありません。今回はロック削除の試みが失敗していますが、これは幸運というより権限設計の結果とみるべきです。

自分の環境が該当するか確認する方法

まず、Azure Portalまたは Azure CLI でサービスプリンシパルに割り当てられているロールを棚卸しします。

az role assignment list --assignee <サービスプリンシパルのID> --all -o table

この出力で Owner や Contributor など広範な権限が割り当てられている場合、削除操作を実行できる状態にあると判断できます。次に、Activity Log で過去の削除系操作を確認します。

az monitor activity-log list --resource-group <対象RG> \
  --start-time 2026-01-01T00:00:00Z \
  --query "[?operationName.value=='Microsoft.Storage/storageAccounts/delete']"

短時間に同一プリンシパルから複数の削除操作が記録されていないか、深夜や休日など通常業務外の時間帯に集中していないかを確認します。あわせて、クライアントシークレットの有効期限が長期間（1年以上）に設定されていないか、証明書ベース認証に切り替えているかも確認ポイントです。

対策の手順

手順1: 権限を機能単位で分割する

読み取り専用の監視用サービスプリンシパルと、デプロイ用の書き込み権限を持つサービスプリンシパルを分離します。1つのアカウントに偵察も破壊もできる権限を集約しないことが基本です。

手順2: リソースロックとRBACを併用する

本番環境のストレージアカウントやKey Vaultには CanNotDelete ロックを設定したうえで、ロックの削除権限自体を別のロールに限定します。

az lock create --name protect-storage --resource-group <対象RG> \
  --lock-type CanNotDelete

手順3: 継続的アクセス評価（CAE）を有効化する

Microsoft Entra ID（旧Azure AD）のworkload identity向けCAE（Continuous Access Evaluation）を有効にすると、リスクの高い兆候を検知した際にトークンの有効性をリアルタイムで再評価できます。認証情報が漏洩してもトークンの寿命を短く保てる点が有効です。

手順4: 削除系操作のアラートを設定する

Azure Monitorでストレージアカウントやリソースグループの削除操作に対するアラートルールを作成し、短時間に複数件発生した場合に通知する仕組みを組み込みます。

手順5: シークレットのローテーションと有効期限短縮

クライアントシークレットの有効期限を90日程度に短縮し、証明書ベースまたはマネージドID（Azureが管理する自動発行のID）への移行を検討します。

破壊行為が7分で完了した以上、検知は事後対応ではなく偵察段階でのアラートが実効性を持ちます。

確認しておきたいこと

今回のケースは、認証情報漏洩そのものより「漏洩後にどこまで権限が及ぶか」が被害規模を決めた事例といえます。

サービスプリンシパルの権限が業務範囲を超えていないか az role assignment list で棚卸しする
削除保護ロックとロック削除権限の分離ができているか確認する
Activity Logで異常な読み取り・削除パターンを検知するアラートがあるか見直す
クライアントシークレットの有効期限とローテーション頻度を点検する

これらは新しい技術投資というより、既存のAzure機能の設定見直しで対応できる範囲です。次のメンテナンス作業のタイミングで、権限の棚卸しから着手してみてください。