MENU

Azure VNetフローログ作成がBad Gateway（AuthorizationFailed）で失敗する原因と対処法｜別サブスクリプションのストレージアカウントに保存するRBAC設定

Azure

NSG フローログの廃止に伴い、Virtual Network（VNet）単位のフローログへ移行する場面が増えています。ところが保存先に「別サブスクリプション（SIEM 用）」のストレージアカウントを指定すると、作成の最終段階で “Bad Gateway” となり失敗することがあります。この記事では、裏で起きている AuthorizationFailed の正体と、再発しない RBAC 設計を具体的に解説します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

現象：VNet フローログ作成が “Bad Gateway” で止まる

次のような構成で VNet フローログ（VNET 単位のフローログ）を作成しようとすると、デプロイの最後で失敗するケースがあります。

項目内容（よくある構成）
対象アプリ用サブスクリプション内の VNet（Hub/Spoke どちらでも発生）
ログ保存先別サブスクリプション（SIEM/監査用）にあるストレージアカウント（Blob）
作成方法Azure ポータル、ARM/Bicep、Terraform、CI/CD（サービスプリンシパル）など
表面上のエラー“Bad Gateway”
実体のエラーAuthorizationFailed（Microsoft.Storage/storageAccounts/read が許可されていない）

ポイントは、画面に見える “Bad Gateway” が原因ではなく、裏側の認可エラー（AuthorizationFailed）が本体であることです。ここを見誤ると「Azure 側の一時障害かな？」として再試行を繰り返し、時間だけが溶けます。

エラーの読み解き：Bad Gateway の裏にある AuthorizationFailed

エラーの文面は環境により多少異なりますが、核心は次のパターンです。

  • AuthorizationFailed：クライアント（ユーザー／サービスプリンシパル）が、保存先ストレージアカウントのスコープで Microsoft.Storage/storageAccounts/read を実行する権限がない
  • スコープ：/subscriptions/<SIEM 側サブスク>/resourceGroups/<RG>/providers/Microsoft.Storage/storageAccounts/<保存先>

“Bad Gateway” はポータルや一部 API の返し方として出ているだけで、根本原因は RBAC（Azure ロールベースアクセス制御）の不足です。まずは「どの ID が」「どのスコープで」「どのアクションを拒否されたか」を正確に押さえます。

まず確認したい場所（原因特定が速くなる）

確認先見るべきポイント補足
デプロイのエラー詳細AuthorizationFailed の本文、拒否されたアクション“Bad Gateway” だけ見て終わらない
アクティビティログ失敗した操作名、呼び出し元（呼び出し元のオブジェクト ID）CI/CD 実行者やポータル操作ユーザーの特定に有効
保存先ストレージ側の IAM該当 ID にロール割り当てがあるか（スコープが正しいか）“別サブスク” だと割り当て忘れが起きやすい

原因：保存先ストレージに対する RBAC 不足（別サブスクリプションが落とし穴）

結論から言うと、フローログ作成に使われるユーザー／サービスプリンシパル（デプロイ実行者）や、フローログを書き込む主体（Network Watcher 側のサービス、もしくはフローログに紐づくマネージド ID）が、保存先ストレージアカウントに対する権限を持っていないことが原因です。

特に「保存先が別サブスクリプション」の場合、ネットワーク側（VNet があるサブスク）の権限だけ整っていても、SIEM 側（ストレージがあるサブスク）の権限は別物です。結果として、最終段階でストレージ参照（read）が失敗し、作成全体がロールバックされます。

“管理プレーン” と “データプレーン” を分けて考えると整理しやすい

ストレージ周りのトラブルシュートで最も多いのが、管理系の権限（ARM 操作）と、データ書き込みの権限（Blob への書き込み）が混線することです。VNet フローログも例外ではありません。

区分代表的な操作関連する権限不足するとどうなる？
管理プレーン（Control/Management plane）ストレージアカウントの存在確認、設定の参照Microsoft.Storage/storageAccounts/read など作成時点で AuthorizationFailed になりやすい
データプレーン（Data plane）Blob コンテナー作成、ログファイル（blob）書き込み例：Storage Blob Data Contributor など作成は通るのにログが出ない／後から失敗する

今回のエラーは明確に Microsoft.Storage/storageAccounts/read（管理プレーン）不足を指しています。つまり、「Blob に書けるロール」だけ付けても直らないことがあるというのが実務での落とし穴です。

解決策：保存先ストレージアカウント（SIEM 側）に RBAC を付与する

対処の基本方針はシンプルです。保存先ストレージアカウントの IAM に、正しい ID に対して、必要なロールを、正しいスコープで割り当てる。これだけで解消するケースが大半です。

誰に付与する？（まずここを間違えない）

VNet フローログでは、環境や作成方法によって「権限が必要な主体」が変わります。代表パターンを整理します。

パターン権限を付ける相手（例）なぜ必要？見分け方
ポータルで作成（人が操作）ポータル操作ユーザー保存先ストレージを参照して構成を確定するためアクティビティログの「呼び出し元」
CI/CD で作成（SP でデプロイ）CI/CD のサービスプリンシパル同上。ARM テンプレートがストレージ参照を行うデプロイ失敗の詳細に ObjectId が出ることが多い
フローログがマネージド ID を使って書き込みフローログ（または Network Watcher 関連リソース）のマネージド IDログを Blob に書く主体がその ID になるフローログ設定画面に「マネージド ID」情報が表示される

実務上は、「デプロイ実行者」と「ログを書き込む主体」が同一でないことがあります。作成エラー（read 失敗）と、作成後のログ未出力（write 失敗）で切り分けると、対応が速くなります。

どのロールを付与する？（最小権限の考え方）

今回の症状に対して、よく使われるロールを整理します。

目的推奨ロール例できること注意点
ストレージアカウントを参照できるようにする（read）Reader（読み取り）
または Storage Account Contributor		ARM 上でストレージアカウントを読み取れる“Blob に書ける” とは別
Blob にログを書き込めるようにする（write）Storage Blob Data Contributorコンテナー/Blob の作成・書き込みができる管理プレーンの read は含まれないことがある
運用上の管理もまとめて委任したいStorage Account Contributor ＋（必要に応じて）Storage Blob Data Contributorストレージ設定の変更まで含めて広く操作可能最小権限になりにくい。付与範囲を要検討

今回の Microsoft.Storage/storageAccounts/read が不足しているケースでは、まず Reader 相当の管理プレーン権限を付与するのが早道です。そのうえで、ログ書き込み主体に Storage Blob Data Contributor を付与すると、作成と出力の両方で詰まりにくくなります。

どのスコープで割り当てる？（おすすめは “ストレージアカウント”）

RBAC の割り当ては継承されるため、理屈の上ではサブスクリプションやリソースグループでも成立します。ただし、実務では次の理由でハマりやすいため、トラブルシュート時はストレージアカウントをスコープにするのが安全です。

スコープメリットデメリット/落とし穴おすすめ度
ストレージアカウント対象が明確。付与漏れ/付与先間違いを減らせる多数のストレージがあると管理が増える◎（まずここ）
リソースグループ同一 RG に集約しているなら管理しやすい別 RG に移した瞬間に効かなくなる○
サブスクリプション一括付与ができる範囲が広すぎて監査上つらい。付与先サブスクを間違えやすい△

「サブスクや RG で付けたはずなのに直らない」という相談の多くは、付与した場所が “VNet 側サブスク” で、必要なのは “SIEM 側サブスクのストレージ”という取り違えです。スコープをストレージアカウントに固定すると、この事故を防ぎやすくなります。

手順：Azure ポータルで RBAC を付与する（最短ルート）

  1. Azure ポータルで 保存先ストレージアカウント（SIEM 側サブスク） を開く
  2. 左メニューから アクセス制御（IAM） を開く
  3. ＋ 追加 → ロールの割り当ての追加
  4. ロールを選択（例：Reader、Storage Blob Data Contributor）
  5. メンバー（ユーザー／サービスプリンシパル／マネージド ID）を選択して割り当て
  6. 付与後、デプロイを再実行

付与先がマネージド ID の場合、検索で見つからないことがあります。そのときは、フローログ設定画面やデプロイ結果から オブジェクト ID（ObjectId）を確認し、ID で割り当てる手順（後述の CLI/PowerShell）を使うと確実です。

手順：CLI / PowerShell で RBAC を付与する（自動化向け）

権限付与を IaC や運用手順に落とし込む場合は、CLI/PowerShell が便利です。以下は概念例です（値は環境に合わせて置き換えてください）。

Azure CLI（例）

# 変数（例）
SIEM_SUBSCRIPTION_ID="<SIEM-subscription-id>"
SIEM_RG="<siem-rg>"
STORAGE_ACCOUNT_NAME="<siemstorage>"
ASSIGNEE_OBJECT_ID="<object-id-of-user-or-sp-or-mi>"

# スコープ（ストレージアカウント）

SCOPE="/subscriptions/${SIEM_SUBSCRIPTION_ID}/resourceGroups/${SIEM_RG}/providers/Microsoft.Storage/storageAccounts/${STORAGE_ACCOUNT_NAME}"

# 管理プレーンの read（まずは Reader）

az role assignment create 
--assignee-object-id "${ASSIGNEE_OBJECT_ID}" 
--role "Reader" 
--scope "${SCOPE}"

# Blob への書き込み（ログ出力主体に）

az role assignment create 
--assignee-object-id "${ASSIGNEE_OBJECT_ID}" 
--role "Storage Blob Data Contributor" 
--scope "${SCOPE}"

Azure PowerShell（例）

$siemSubId = "<SIEM-subscription-id>"
$siemRg = "<siem-rg>"
$storage = "<siemstorage>"
$objectId = "<object-id-of-user-or-sp-or-mi>"

$scope = "/subscriptions/$siemSubId/resourceGroups/$siemRg/providers/Microsoft.Storage/storageAccounts/$storage"

New-AzRoleAssignment -ObjectId $objectId -RoleDefinitionName "Reader" -Scope $scope
New-AzRoleAssignment -ObjectId $objectId -RoleDefinitionName "Storage Blob Data Contributor" -Scope $scope

コマンドが成功しても、すぐに反映されないことがあります。特にポータルや CLI のログインセッションはトークンを保持しているため、次の “トークン更新” をセットで実施するとトラブルが減ります。

権限付与後に必ずやる：トークン（資格情報）の更新

RBAC を付与した直後に再実行しても、同じエラーで失敗する場合があります。原因は「権限付与前に取得したアクセストークンを使い続けている」ことです。次のいずれかを実施して、トークンを更新します。

  • Azure ポータル：サインアウト → サインイン
  • Azure CLI：az logout → az login
  • PowerShell：Disconnect-AzAccount → Connect-AzAccount
  • CI/CD：サービス接続の再認証、もしくはジョブをリトライ（新しいトークンで実行される形にする）

追加の確認ポイント（RBAC 以外で詰まる定番）

RBAC を直したのにうまくいかない、あるいは作成は成功したのにログが溜まらない場合は、次のポイントを順に潰すと迷子になりません。

Network Watcher が対象リージョンで有効か

VNet フローログは Network Watcher と連動するため、対象リージョンで Network Watcher が有効であることが前提になります。複数リージョンに VNet がある環境では「片方だけ失敗する」原因になりがちです。

保存先ストレージのネットワーク制限（Firewall / Private Endpoint）

ストレージアカウント側で厳しいネットワーク制限をしていると、フローログの書き込みに失敗することがあります。代表的には次のパターンです。

  • パブリックネットワークアクセスを無効化している
  • Firewall で許可 IP を限定している（ログ書き込み主体が通れない）
  • Private Endpoint 前提の設計で、書き込み経路が成立していない

セキュリティ設計としてネットワーク制限は重要ですが、まずは「ログが届く経路があるか」を確認してください。運用では、許可すべき経路だけを残しつつ、不要な経路を閉じる形が現実的です。

“ストレージ側の作り込み” が必要なケース

組織によっては、監査・SIEM 用ストレージに対して次のようなガードを掛けていることがあります。これらがあると、権限が正しくても作成や書き込みがブロックされる場合があります。

制約例影響確認のヒント
Azure Policy で “特定のリージョン/種類以外を拒否”デプロイ終盤で失敗、または保存先の参照が通らないポリシー評価の結果、コンプライアンス状態
リソースロック（削除不可/読み取り専用）設定変更やコンテナー作成が弾かれることがあるストレージアカウントの “ロック”
監査要件で “キー利用禁止”マネージド ID 方式に寄せる必要がある運用ルール、セキュリティレビュー

切り分け早見表：どこで詰まっているかを 1 分で判断する

“Bad Gateway” のように表面のメッセージが曖昧な場合は、次の早見表で当たりを付けると調査が早くなります。

症状起点になりやすい原因最優先で打つ手
作成の最終段階で失敗し、詳細に Microsoft.Storage/storageAccounts/read保存先ストレージに対する管理プレーン権限（read）不足保存先ストレージアカウントに Reader（または相当）を付与
作成は成功するが、Blob にファイルが増えないデータプレーン権限不足、またはストレージのネットワーク制限Storage Blob Data Contributor を付与し、Firewall/Private Endpoint 設定も確認
権限を付けたのに直らない（同じエラー）トークン更新不足／付与先 ID 違い／付与スコープ違い再ログインし、アクティビティログの ObjectId と IAM の割り当てを突合
リージョンによって成否が分かれるNetwork Watcher の有効化漏れ、もしくはリージョン差分の設定対象リージョンで Network Watcher が有効か確認

最小権限を突き詰める：まず通してから “絞る” のが現実的

監査・SIEM 用のストレージは「できるだけ権限を小さくしたい」という要件が強いことが多いはずです。一方で、移行フェーズでいきなり最小権限を目指すと、切り分けが難しくなりがちです。

おすすめは次の進め方です。

  1. まずはストレージアカウントスコープで Reader と Storage Blob Data Contributor を付与して “作成できる・ログが出る” を優先
  2. 動作確認が取れたら、運用要件に合わせて権限とスコープを段階的に絞る

たとえば「特定のコンテナーにだけ書き込みたい」場合は、次のいずれかが検討対象になります。

  • コンテナーを事前作成し、コンテナースコープでデータプレーン権限を付与する
  • 組織標準に合わせて カスタムロール を作成し、必要なアクションだけに絞る

ただし、フローログ側がコンテナー自動作成を前提としている場合、コンテナースコープだけでは初回に失敗することがあります。「最初だけストレージアカウント、安定したらコンテナーへ」という段階的な絞り込みが、実運用では最も事故が少ない進め方です。

作成できたかの確認：成功判定は “ログが出ているか” まで

フローログは「作成に成功した」だけでは安心できません。実運用では次の 2 段階で確認するのが確実です。

確認 1：フローログ設定が “Succeeded” になっているか

  • 対象 VNet のフローログ設定が有効になっている
  • デプロイ履歴で Provisioning State が Succeeded になっている

確認 2：保存先ストレージに “実データ” が作られているか

  • ストレージアカウントの Blob に insights-logs- で始まるコンテナーやプレフィックスが作成されているか
  • VNet 内で通信（疎通）を発生させた後、数分〜しばらくしてファイルが増えるか
  • SIEM 取り込み（Log Analytics / Sentinel など）側の遅延も考慮し、まずは Blob 側の着弾を優先して確認する

「作成はできたのにログが増えない」場合は、データプレーン権限（Storage Blob Data Contributor）やストレージのネットワーク制限が原因になっていることが多いです。作成（read）と出力（write）を切り分けるのがコツです。

よくある質問（現場で詰まるポイントを先回り）

Storage Blob Data Contributor を付けたのに AuthorizationFailed が消えません

エラーが Microsoft.Storage/storageAccounts/read を指している場合、管理プレーンの読み取り権限が不足している可能性が高いです。対策として、保存先ストレージアカウントに対して Reader（または Storage Account Contributor）を追加し、ログインし直して再実行してください。

サブスクリプション（または RG）に権限を付けたはずなのに直りません

RBAC は継承されますが、別サブスクリプション構成では「付けた場所が違う」事故が起きがちです。次を確認してください。

  • 権限を付けたのは SIEM 側サブスクリプションか（VNet 側ではないか）
  • スコープは 保存先ストレージアカウント になっているか
  • 付与先の ID（ユーザー/SP/マネージド ID）が正しいか

権限付与した直後なのに、再実行すると同じエラーになります

トークンが更新されていないケースが多いです。ポータルの再ログイン、CLI/PowerShell の再ログイン、CI/CD の再実行で新しいトークンを取得してから試してください。

再発防止：別サブスクリプション保存を前提にした RBAC 設計のコツ

今回のような “クロスサブスクリプションでログを集約する” 設計は、監査や SIEM 運用の観点ではとても合理的です。一方で、運用の現場では「権限付与の責任境界が分かれる」ため、仕組み化しないと同じトラブルが繰り返されます。

おすすめの運用ルール（例）

テーマおすすめ狙い
ロール付与の標準保存先ストレージに Reader と Storage Blob Data Contributor をセットで割り当てる作成（read）と出力（write）の両方を一度で潰す
スコープの標準まずは ストレージアカウント スコープで統一（必要なら後で絞る）付与漏れ・付与先間違いを防止
自動化CI/CD や IaC でロール割り当てまでコード化する人手の作業を減らし、監査証跡も残す
セキュリティアクセスキー運用を避け、マネージド ID を優先するキー漏えいリスクを下げ、権限の棚卸しを容易にする

VNet フローログはネットワーク可視化の基盤です。作成エラーを単発対応で終わらせず、「誰がどこに書くのか」を RBAC とネットワーク制限の両面で定義しておくと、移行や拡張のたびに苦労しなくなります。

まとめ

  • “Bad Gateway” で止まっても、実体は AuthorizationFailed のことが多い
  • 原因は、保存先ストレージアカウント（別サブスク）に対する RBAC 不足
  • Reader（管理プレーン）とStorage Blob Data Contributor（データプレーン）を、正しい ID に、ストレージアカウントスコープで付与する
  • 付与後は必ずトークン更新（再ログイン）
  • Network Watcher の有効化、ストレージのネットワーク制限も忘れずに確認
Azure
Azure RBAC ストレージアカウント VNetフローログ Network Watcher

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次