【Azure】Public Network Access が Disabled なのに VNet Flow Log を保存できるのはなぜ？検証してみた
「Azure Storage Account の Public Network Accessを Disabled に設定しているのに、なぜか VNet Flow Logが問題なく保存され続けている…」
一見すると設定の矛盾のように見えますが、気になったので実際に Azure 環境で挙動を検証・調査してみました。
今回は、その検証結果と「なぜ保存できるのか」のメカニズムを解説します。
疑問のきっかけと検証環境
以下のような設定のストレージアカウントを作成し、VNet Flow Log の出力先として指定しました。
検証したストレージアカウントの構成
-
Storage Account名:
vnetflowlogsa123 -
Networking（ネットワーク）設定:
Public network access = Disabled
近年、Azure Portal の UI 上では「信頼された Microsoft サービスによるこのストレージ アカウントへのアクセスを許可する（Allow trusted Microsoft services...）」というチェックボックスが表示されないケースが増えています。
ポータル画面上は「パブリックアクセスが無効化されており、例外設定もない」ように見えるため、「なぜアクセスを拒否されているはずの VNet Flow Log が書き込めているのか？」という疑問が生じました。
検証結果：
StorageAccoutのPublicAccessを無効にしているのに、VnetFlowlogは以前中に保管されます。
Azure CLI で設定プロパティを確認してみた
設定の裏側を確認するため、Azure CLI を使ってストレージアカウントの内部パラメータ（JSON）を出力してみました。
az storage account show \
-g vNETFLOWLOG \
-n vnetflowlogsa123 \
--query "{publicNetworkAccess:publicNetworkAccess, bypass:networkRuleSet.bypass}"
実行結果
{
"bypass": "AzureServices",
"publicNetworkAccess": "Disabled"
}
ここで重要になってくるのが、"bypass": "AzureServices" というパラメータです。
なぜ保存できるのか？理由とメカニズム
結論から言うと、「Public network access = Disabled」 と 「Trusted Azure Services (bypass)」 は内部的に独立した別々の設定として管理されています。
1. bypass = AzureServices とは？
Storage Account にはファイアウォール制御の例外設定として 「Trusted Azure Services（信頼された Azure サービス）」 という仕組みが存在します。この設定が有効な場合、特定条件を満たす Azure のファーストパーティサービスは Storage ファイアウォールをバイパスしてアクセス可能です。
2. ネットワークログ機能は対象サービスに含まれる
Trusted Azure Services の対象リストには Azure Networking Services (Microsoft.Network) が含まれており、以下のサービスによるログ書き込みが許可されています。
- Network Watcher
- NSG Flow Log
- VNet Flow Log
3. Disabled にしても bypass 設定は残る仕様
Microsoft Learn にも記載がありますが、Public network access を Disabled に変更しても、過去に構成されていた bypass（例外許可）設定は有効なまま保持される仕様があります。
そのため、「Disabled にしたから絶対にアクセスできない」とは言えないのが実態です。
ポータルでチェックボックスが見えない理由と確実な確認方法
現在の Azure Portal（特にストレージアカウントの「ネットワーク」ブレード）では、パブリックネットワークアクセスを「無効（Disabled）」に設定すると、例外許可のチェックボックス自体が非表示・マスクされる画面設計になっています。
そのため、画面上の見た目だけで判断せず、Azure CLI や PowerShell で直接パラメータを確認するのが一番確実です。
判定コマンド
az storage account show \
-g <リソースグループ名> \
-n <ストレージアカウント名> \
--query "networkRuleSet.bypass"
-
"AzureServices"が返ってきた場合 ➔ Trusted Azure Services が有効（VNet Flow Log 保存可能） -
"None"が返ってきた場合 ➔ Trusted Services も無効（完全遮断）
おわりに
「パブリックアクセスを無効にしたのにログが届く」という疑問から検証してみましたが、Public network access だけでなく networkRuleSet.bypass の値も合せて確認する必要があることが分かりました。
ポータルの表示だけに頼らず、CLIで内部パラメータまで追うことの大切さを再確認した検証でした！