Azure Storage Accountのファイアウォール設定で困ることが多いので設定方法まとめ

Last updated at 2025-12-25Posted at 2025-12-25

Azure のストレージアカウントでは、ファイアウォール設定をするときに、設定すべき場所がいくつかあって、正しく設定できずに困ったことありませんか？
そういうときのために、こういう構成だったらここで設定するというのをまとめてみました。

TL;DR

ストレージアカウントのファイアウォール構成は、アクセス経路によって複雑なので、シナリオ毎にまとめてみました。

No.	シナリオ	設定方法
1	ストレージアカウントと同一リージョン内のVMからのアクセス	仮想ネットワーク規則
2	ストレージアカウントとペアリージョンからパブリックIPアドレス経由でのアクセス	IPネットワーク規則
3	ストレージアカウントとペアリージョン内からサービスエンドポイント経由でのアクセス	仮想ネットワーク規則
4	ストレージアカウントとペアリージョン以外のリージョンからアクセス	IPネットワーク規則
5	ストレージアカウントとペアリージョン内のAzure Firewall経由でアクセス	仮想ネットワーク規則

ストレージアカウントのファイアウォール設定とこの記事の範囲

ストレージアカウントでは、パブリックエンドポイントへのアクセスを制御するための仕組みが準備されています。
主には、以下の四種類のネットワーク規則を構成することが可能です。

仮想ネットワークルール: Azure Virtual Network 内の特定のサブネットからのトラフィックを許可する
IP ネットワーク規則: 特定のパブリック IP アドレス範囲からのトラフィックを許可する
リソースインスタンスルール: 仮想ネットワークまたは IP 規則を使用して分離できない特定の Azure リソースインスタンスからのトラフィックを許可する
信頼されたサービスの例外: ネットワーク境界外で動作する特定の Azure サービスからのトラフィックを許可する

このうち、仮想ネットワークとIP ネットワーク規則 の使い分けがとても難しいので、この記事ではここにフォーカスして記載します。

なお、同様の記事として Azure のサポートチームから公開されている記事がいくつかあります。

これらの記事には、もちろん正しいことが書かれているのですが、エンタープライズの現場ではもう少し複雑な経路でアクセスすることがほとんどかと思いますので、この観点で補足します。

ストレージアカウントのファイアウォールのポイント

ストレージアカウントのファイアウォールでは、基本的にストレージアカウントにアクセスする際の経路上で、最後にどのリソースやどの場所を通ったか が重要になります。
この理由は、以下のドキュメントにも記載の通り、ストレージアカウントと同じAzureリージョン内のクライアントからのアクセスに関しては、パブリックIPアドレス規則を用いた制限ではなく、仮想ネットワーク規則を用いた制限をしないといけないことにあります。

参考: Azure Storage ファイアウォールのガイドラインと制限事項 - IP ネットワーク規則の制限

IP ネットワーク規則を使用して、ストレージアカウントと同じ Azure リージョン内のクライアントへのアクセスを制限することはできません。 IP ネットワークルールは、ストレージアカウントと同じ Azure リージョンから送信された要求には影響しません。同じリージョンの要求を許可するには、仮想ネットワーク規則を使用します。
IP ネットワーク規則を使用して、サービスエンドポイントを持つ仮想ネットワーク内にあるペアリージョン内のクライアントへのアクセスを制限することはできません。

そのため、この記事では、以下のいくつかのシナリオに関して、IP ネットワーク規則と仮想ネットワーク規則のどちらに設定が必要かをまとめます。

シナリオ：

ストレージアカウントと同一リージョン内のVMからのアクセス
ストレージアカウントとペアリージョンからパブリックIPアドレス経由でのアクセス
ストレージアカウントとペアリージョン内からサービスエンドポイント経由でのアクセス
ストレージアカウントとペアリージョン以外のリージョンからのアクセス
ストレージアカウントとペアリージョン内のAzure Firewall経由でアクセス

検証で利用したソースコードについて

本検証で利用したソースコードは、GitHub上で公開しています。
ストレージアカウント検証用のソースコード

なお、このソースコードはあくまでも検証用で、セキュリティ設定等に関して不十分な部分が多くあります。そのため、利用用途は検証目的のみとし、自己責任で利用してください。また、前述の通りセキュリティ設定等が不十分な箇所が多くありますので、デプロイされたリソースは検証後に削除することを推奨します。
本ソースコードを利用したことによって発生したいかなる問題も、作成者は関与しいたしかねます。

シナリオ1: ストレージアカウントと同一リージョン内のVMからのアクセス

ストレージアカウントファイアウォールの設定方法

これは、最もシンプルなケースで、MSの公式ドキュメントやブログで記載されている通りです。
即ち、ストレージアカウントと同一リージョン内のVMにパブリックIPを付与してストレージアカウントにアクセスする場合、経路上の最後のリソースは同一リージョン内のVM になりますので、仮想ネットワーク規則 で設定します。

検証環境の構成

構成は上記のような構成で、東日本リージョンに検証用にパブリックIPを持ったVM一台と、ファイアウォール設定をしたストレージアカウントを一つデプロイしました。
そのうえで、このVMからストレージアカウントにアクセスすることで検証を行いました。

検証

まず、アクセス可否を検証するために、ストレージアカウントに対して、VMに設定したパブリックIPアドレス(今回のリソースでは IPアドレスは4.189.169.66 となります)を許可する設定を入れます。

設定後のストレージアカウントのファイアウォール構成は以下の通りです。

>az storage account network-rule list --resource-group storage-test --account-name iboysafwtest100
{
  "ipRules": [
    {
      "action": "Allow",
      "ipAddressOrRange": "4.189.169.66"
    }
  ],
  "ipv6Rules": [],
  "resourceAccessRules": null,
  "virtualNetworkRules": []
}

上記のようにVMに付与されたパブリックIPアドレスである 4.189.169.66 を許可する構成にしました。

上記状態で、VMからストレージアカウント内のAzure Filles に対して、SMBマウント、および azcopy list コマンドで、接続可否を確認します。

補足:
今後のすべてのシナリオでもそうですが、ストレージアカウントのファイアウォールは L7 レイヤーで動作しますので、PowerShell のTest-NetConnection コマンド等では、アクセスが遮断されたことを確認できない場合がありますので注意が必要です。

上記のように、IP ネットワーク規則を設定した場合、SMB接続、azcopy での HTTPS 接続のどちらも失敗していることが確認できます。

また、ストレージアカウントの診断設定を有効にしたうえで、ストレージアカウントのログも併せて取得しましたが、以下のように HTTPS の 403 (AuthorizationFailure) を返していることもわかります。

ストレージアカウント診断ログ抜粋
{
    "time": "2025-12-12T11:49:01.5641791Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboysafwtest100/fileServices/default",
    "category": "StorageRead",
    "statusCode": 403,
    "statusText": "AuthorizationFailure",
    "callerIpAddress": "172.30.0.4:50151",
    "location": "japaneast",
    "properties": {
        "accountName": "iboysafwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
    "protocol": "HTTPS",
}

では、この状態から、以下のように仮想マシンが所属しているサブネットに対してアクセス許可を与えるように仮想ネットワーク規則を追加します。

追加した結果が以下の通りです。

>az storage account network-rule list --resource-group storage-test --account-name iboysafwtest100
{
  "ipRules": [
    {
      "action": "Allow",
      "ipAddressOrRange": "4.189.169.66"
    }
  ],
  "ipv6Rules": [],
  "resourceAccessRules": null,
  "virtualNetworkRules": [
    {
      "action": "Allow",
      "state": "Succeeded",
      "virtualNetworkResourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Network/virtualNetworks/je-vnet/subnets/test"
    }
  ]
}

この状態で、同様のリクエストを発行して、接続可能かを検証します。

以下が、先ほど失敗したSMB接続と azcopy によるHTTPSリクエストの結果です。

結果からわかるように問題無く接続できていることが分かります。
念のため、同様にストレージアカウントの診断ログの結果も確認しますが、もちろんアクセスに成功しています。

ログ抜粋：
{
    "time": "2025-12-12T12:00:46.5380410Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboysafwtest100/fileServices/default",
    "category": "StorageRead",
    "operationName": "ListFiles",
    "operationVersion": "2025-07-05",
    "schemaVersion": "1.0",
    "statusCode": 200,
    "statusText": "Success",
    "durationMs": 2,
    "callerIpAddress": "172.30.0.4:50442",
    "correlationId": "891d56a1-701a-00a7-525e-6bc5a5000000",
    "location": "japaneast",
    "properties": {
        "accountName": "iboysafwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
    },
}

結果からも、明白な通り、ストレージアカウントと同一リージョン内のVMにパブリックIPを付与するケースは、ドキュメント記載の通りの仮想ネットワーク規則での制御が必要であることが分かります。

シナリオ2: ストレージアカウントとペアリージョンからパブリックIPアドレス経由でのアクセス

ストレージアカウントファイアウォールの設定方法

IP ネットワーク規則の設定で接続可能。

検証環境の構成

構成は上記のような構成で、西日本リージョンに検証用にパブリックIPを持ったVM一台、東日本リージョンにファイアウォール設定をしたストレージアカウントを一つデプロイしました。
そのうえで、このVMからストレージアカウントにアクセスすることで検証を行いました。

検証

まず、アクセス可否を検証するために、ストレージアカウントに対して、VMに設定したパブリックIPアドレス (今回のリソースでは IPアドレスは52.175.150.77 となります) を許可する設定を入れます。

設定後のストレージアカウントのファイアウォール構成は以下の通りです。

> az storage account network-rule list --resource-group storage-test --account-name iboystragefwtest100
{
  "ipRules": [
    {
      "action": "Allow",
      "ipAddressOrRange": "52.175.150.77"
    }
  ],
  "ipv6Rules": [],
  "resourceAccessRules": null,
  "virtualNetworkRules": []
}

上記のようにVMに付与されたパブリックIPアドレスである 52.175.150.77 を許可する構成にしました。

上記状態で、VMからストレージアカウント内のAzure Filles に対して、SMBマウント、および azcopy list コマンドで、接続可否を確認します。

ログ抜粋:
{
    "time": "2025-12-16T06:24:13.5900703Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboystragefwtest100/fileServices/default",
    "category": "StorageRead",
    "operationName": "ListFiles",
    "operationVersion": "2025-07-05",
    "schemaVersion": "1.0",
    "statusCode": 200,
    "statusText": "Success",
    "durationMs": 5,
    "callerIpAddress": "52.175.150.77:50027",
    "location": "japaneast",
    "properties": {
        "accountName": "iboystragefwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
        "tlsVersion": "TLS 1.3"
    },
    "protocol": "HTTPS",
    "resourceType": "Microsoft.Storage/storageAccounts/fileServices"
}

シナリオ3: ストレージアカウントとペアリージョン内からサービスエンドポイント経由でのアクセス

ストレージアカウントファイアウォールの設定方法

仮想ネットワーク規則でサブネットにアクセス許可を実施することでアクセス可能

検証環境の構成

構成は上記のような構成で、西日本リージョンに検証用にパブリックIPを持ったVM一台、東日本リージョンにファイアウォール設定をしたストレージアカウントを一つデプロイしました。また、上記に加えて、VMの所属する西日本リージョンのサブネットには、Microsoft.Storage のサービスエンドポイントを構成しました。(すなわち、シナリオ2との差は、サブネットにサービスエンドポイントが紐づいているかどうかの差となります)
上記の構成にて、VMからストレージアカウントにアクセスすることで検証を行いました。

検証

まず、アクセス可否を検証するために、ストレージアカウントに対して、VMに設定したパブリックIPアドレス(今回のリソースでは IPアドレスは4.190.216.197)を許可する設定を入れます。

設定後のストレージアカウントのファイアウォール構成は以下の通りです。

設定変更時の出力抜粋:
  "networkRuleSet": {
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [
      {
        "action": "Allow",
        "ipAddressOrRange": "4.190.216.197"
      }
    ],
    "ipv6Rules": [],
    "resourceAccessRules": null,
    "virtualNetworkRules": []
  }

上記のようにVMに付与されたパブリックIPアドレスである 4.190.216.197 を許可する構成にしました。

上記のように、IP ネットワーク規則を設定した場合、SMB接続、azcopy での HTTPS 接続のどちらも失敗していることが確認できます。

ストレージアカウント診断ログ抜粋
{
    "time": "2025-12-16T07:35:04.2373908Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboystragefwtest100/fileServices/default",
    "category": "StorageRead",
    "operationName": "GetDirectoryProperties",
    "operationVersion": "2025-07-05",
    "schemaVersion": "1.0",
    "statusCode": 403,
    "statusText": "AuthorizationFailure",
    "durationMs": 2,
    "callerIpAddress": "172.30.10.4:50149",
    "location": "japaneast",
    "properties": {
        "accountName": "iboystragefwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
        "tlsVersion": "TLS 1.3"
    },
}

追加した結果が以下の通りです。

コマンド実行結果の抜粋: 
  "networkRuleSet": {
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [
      {
        "action": "Allow",
        "ipAddressOrRange": "4.190.216.197"
      }
    ],
    "ipv6Rules": [],
    "resourceAccessRules": null,
    "virtualNetworkRules": [
      {
        "action": "Allow",
        "state": "Succeeded",
        "virtualNetworkResourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Network/virtualNetworks/jw-vnet/subnets/test-west"
      }
    ]
  },

この状態で、同様のリクエストを発行して、接続可能かを検証します。

以下が、先ほど失敗したSMB接続と azcopy によるHTTPSリクエストの結果です。

ログ抜粋：
{
    "time": "2025-12-16T07:38:28.1167863Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboystragefwtest100/fileServices/default",
    "category": "StorageRead",
    "operationName": "ListFiles",
    "operationVersion": "2025-07-05",
    "schemaVersion": "1.0",
    "statusCode": 200,
    "statusText": "Success",
    "durationMs": 3,
    "callerIpAddress": "172.30.10.4:50233",
    "location": "japaneast",
    "properties": {
        "accountName": "iboystragefwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
        "tlsVersion": "TLS 1.3"
    },
}

結果からも、明白な通り、ストレージアカウントとペアリージョン内のVMにパブリックIPを付与しても、VMのサブネットにサービスエンドポイントを設定しているケースは、ドキュメント記載の通りの仮想ネットワーク規則での制御が必要であることが分かります。

シナリオ4: ストレージアカウントとペアリージョン以外のリージョンからのアクセス

ストレージアカウントファイアウォールの設定方法

IP ネットワーク規則の設定で接続可能。

検証環境の構成

これはもう、なくてもお分かりかもしれませんが、念のため、ペアリージョン以外からのアクセスも検証します。
なお、ストレージアカウントの仮想ネットワーク規則では、ストレージアカウントと同じリージョンか、ペアリージョンのVNetしか登録できませんので、これは必然的に IP ネットワーク規則を利用することになり、後述の検証の通り、IP ネットワーク規則にて接続が成功します。

検証

まず、アクセス可否を検証するために、ストレージアカウントに対して、VMに設定したパブリックIPアドレス(今回のリソースでは IPアドレスは23.98.88.133) を許可する設定を入れます。

設定後のストレージアカウントのファイアウォール構成は以下の通りです。

設定の更新結果抜粋: 
  "networkRuleSet": {
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [
      {
        "action": "Allow",
        "ipAddressOrRange": "23.98.88.133"
      }
    ],
    "ipv6Rules": [],
    "resourceAccessRules": null,
    "virtualNetworkRules": []
  },

上記のようにVMに付与されたパブリックIPアドレスである 23.98.88.133 を許可する構成にしました。

上記状態で、VMからストレージアカウント内のAzure Filles に対して、SMBマウント、および azcopy list コマンドで、接続可否を確認します。

ログ抜粋:
{
    "time": "2025-12-25T07:28:09.4209203Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboystragefwtest100/fileServices/default",
    "category": "StorageRead",
    "operationName": "ListFiles",
    "operationVersion": "2025-07-05",
    "schemaVersion": "1.0",
    "statusCode": 200,
    "statusText": "Success",
    "durationMs": 3,
    "callerIpAddress": "23.98.88.133:50092",
    "location": "japaneast",
    "properties": {
        "accountName": "iboystragefwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
        "tlsVersion": "TLS 1.3"
    },
}

シナリオ5: ストレージアカウントとペアリージョン内のAzure Firewall経由でアクセス

ストレージアカウントファイアウォールの設定方法

仮想ネットワーク規則を利用して、東日本リージョンのAzure FirewallをデプロイしているAzureFirewallSubnetに対して、アクセス許可を与えます。

補足：
これは、ストレージアカウントにアクセスする際の経路上の最後が、Azure Firewallになるためにこういった対応が必要になります。Azure Firewall でなくても、例えば Proxy サーバをストレージアカウントと同じリージョンに作成している場合は、同様に Proxy サーバが存在するサブネットに対して許可が必要です。

検証環境の構成

検証

まず、アクセス可否を検証するために、ストレージアカウントに対して、Azure Firewall に設定したパブリックIPアドレス(今回のリソースでは IPアドレスは172.192.48.106)を許可する設定を入れます。
これは、VM 自体は、東南アジアリージョンにデプロイしておりますが、ユーザー定義ルートにて、Azure Firewall を必ず経由してインターネットやパブリックエンドポイントにアクセスするように構成しているからです。

設定後のストレージアカウントのファイアウォール構成は以下の通りです。

設定変更時の出力抜粋:
  "networkRuleSet": {
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [
      {
        "action": "Allow",
        "ipAddressOrRange": "172.192.48.106"
      }
    ],
    "ipv6Rules": [],
    "resourceAccessRules": null,
    "virtualNetworkRules": []
  }

設定後にアクセスを検証すると、以下のようになります。

上記のように、IP ネットワーク規則を設定した場合、SMB接続、azcopy での HTTPS 接続のどちらも失敗していることが確認できます。

ストレージアカウント診断ログ抜粋
{
    "time": "2025-12-25T09:37:06.8573143Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboystragefwtest100/fileServices/default",
    "category": "StorageRead",
    "operationName": "GetDirectoryProperties",
    "operationVersion": "2025-07-05",
    "schemaVersion": "1.0",
    "statusCode": 403,
    "statusText": "AuthorizationFailure",
    "callerIpAddress": "172.30.1.5:50436",
    "location": "japaneast",
    "properties": {
        "accountName": "iboystragefwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
        "metricResponseType": "AuthorizationError",
        "tlsVersion": "TLS 1.3"
    },
    "protocol": "HTTPS",
    "resourceType": "Microsoft.Storage/storageAccounts/fileServices"
}

では、この状態から、以下のようにAzure Firewall が所属しているサブネット(一般的にAzureFirewallSubnetという名前)に対してアクセス許可を与えるように仮想ネットワーク規則を追加します。

追加した結果が以下の通りです。

コマンド実行結果の抜粋: 
  "networkRuleSet": {
    "bypass": "AzureServices",
    "defaultAction": "Deny",
    "ipRules": [
      {
        "action": "Allow",
        "ipAddressOrRange": "172.192.48.106"
      }
    ],
    "ipv6Rules": [],
    "resourceAccessRules": null,
    "virtualNetworkRules": [
      {
        "action": "Allow",
        "state": "Succeeded",
        "virtualNetworkResourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Network/virtualNetworks/je-vnet/subnets/AzureFirewallSubnet"
      }
    ]
  },

この状態で、同様のリクエストを発行して、接続可能かを検証します。

以下が、先ほど失敗したSMB接続と azcopy によるHTTPSリクエストの再実行結果です。

ログ抜粋：
{
    "time": "2025-12-25T09:44:51.4066608Z",
    "resourceId": "/subscriptions/<サブスクリプションID>/resourceGroups/storage-test/providers/Microsoft.Storage/storageAccounts/iboystragefwtest100/fileServices/default",
    "category": "StorageRead",
    "operationName": "ListFiles",
    "operationVersion": "2025-07-05",
    "statusCode": 200,
    "statusText": "Success",
    "callerIpAddress": "172.30.1.5:50656",
    "location": "japaneast",
    "properties": {
        "accountName": "iboystragefwtest100",
        "userAgentHeader": "AzCopy/10.31.0 azsdk-go-azfile/v1.5.2-beta.1 (go1.24.6; Windows_NT)",
        "metricResponseType": "Success",
        "tlsVersion": "TLS 1.3"
    },
    "protocol": "HTTPS",
    "resourceType": "Microsoft.Storage/storageAccounts/fileServices"
}

まとめ

今回は、検証が多く、長くなってしまいましたが、結論は冒頭に記載した通りです。
ストレージアカウントのパブリックエンドポイントにアクセスする場合は、最後に通るリソースがどこのリージョンなのか、そのリソースからサービスエンドポイントを使用してアクセスするのかどうかを気を付けることで、ストレージアカウントのファイアウォール構成をどのようにするかが分かりやすいかと思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Azure Storage Accountのファイアウォール設定で困ることが多いので設定方法まとめ

TL;DR

ストレージアカウント の ファイアウォール 設定とこの記事の範囲

ストレージアカウント の ファイアウォール のポイント

検証で利用したソースコードについて

シナリオ1: ストレージアカウントと同一リージョン内のVMからのアクセス

ストレージアカウント ファイアウォールの設定方法

検証環境の構成

検証

シナリオ2: ストレージアカウントとペアリージョンからパブリックIPアドレス経由でのアクセス

ストレージアカウント ファイアウォールの設定方法

検証環境の構成

検証

シナリオ3: ストレージアカウントとペアリージョン内からサービスエンドポイント経由でのアクセス

ストレージアカウント ファイアウォールの設定方法

検証環境の構成

検証

シナリオ4: ストレージアカウントとペアリージョン以外のリージョンからのアクセス

ストレージアカウント ファイアウォールの設定方法

検証環境の構成

検証

シナリオ5: ストレージアカウントとペアリージョン内のAzure Firewall経由でアクセス

ストレージアカウント ファイアウォールの設定方法

検証環境の構成

検証

まとめ

ストレージアカウントのファイアウォール設定とこの記事の範囲

ストレージアカウントのファイアウォールのポイント

ストレージアカウントファイアウォールの設定方法

ストレージアカウントファイアウォールの設定方法

ストレージアカウントファイアウォールの設定方法

ストレージアカウントファイアウォールの設定方法

ストレージアカウントファイアウォールの設定方法