MENU

Azure StorageのTrusted Azure servicesとは？2026年更新点とネットワーク設定の確認ポイント

Azure

Azure Storageでファイアウォールや「選択したネットワーク」を使っている場合、Trusted Azure services for Azure Storage network securityの更新は、単なるサービス一覧の確認で終わらせてはいけません。重要なのは、「どのAzureサービスを例外として許可しているか」「そのサービスに必要なマネージドID、Azureロール、ACLが設定されているか」「不要な例外が残っていないか」を確認することです。

2026年5月7日付で確認できる公式情報では、Trusted Azure servicesの一覧にAzure Container Registryが含まれています。実質的な対応ポイントは、Azure Storageのネットワーク例外を広く許可するのではなく、必要なサービス・必要なストレージアカウント・必要な権限だけに絞って見直すことです。対象ページはMicrosoft Learn上で「Last updated on 2026-05-07」と表示され、Azure Container RegistryのリソースプロバイダーとしてMicrosoft.ContainerRegistry/registriesが掲載されています。(Microsoft Learn)

目次

Trusted Azure services for Azure Storage network securityとは

Trusted Azure services for Azure Storage network securityは、Azure Storageのネットワーク制限を有効にしている場合でも、特定のAzureサービスからのアクセスを例外的に許可できる仕組みです。

Azure Storageのファイアウォール規則は、ストレージアカウントのパブリックエンドポイントに対するネットワークアクセスを制御します。Microsoft Learnでは、構成できるネットワーク規則として、仮想ネットワーク規則、IPネットワーク規則、リソースインスタンス規則、信頼されたサービス例外の4種類が説明されています。ネットワーク規則を設定すると、明示的に許可された送信元だけがストレージアカウントへアクセスできます。(Microsoft Learn)

ただし、Trusted Azure servicesは「認証なしで通す」設定ではありません。ネットワーク境界外で動作するAzureサービスに対して例外を追加できる仕組みであり、これらのサービスは強力な認証を使ってストレージアカウントへ接続します。さらに、許可された送信元からの要求であっても、ストレージアカウント側の認可要件を満たす必要があります。(Microsoft Learn)

つまり、実務では次のように考えると分かりやすいです。

観点役割
ネットワーク規則どこからストレージアカウントに到達できるかを制御する
Trusted Azure servicesAzureサービスの一部をネットワーク例外として許可する
マネージドID・Azureロール・ACL到達後に、どのデータへ何ができるかを制御する
監査・ログ確認意図しない例外や失敗したアクセスを検出する

2026年5月7日更新で押さえるべき変更点

今回の更新で管理者が特に確認すべき点は、マネージドIDベースの信頼されたアクセスの一覧にAzure Container Registryが追加されていることです。GitHub上のMicrosoftDocs/azure-docsの差分でも、Azure Container RegistryとMicrosoft.ContainerRegistry/registriesの行が追加されたことが確認できます。(GitHub)

確認項目内容実務上の意味
更新日Microsoft Learnの対象ページで2026年5月7日更新として確認できる社内手順書や設計書の参照日を更新する
追加されたサービスAzure Container RegistryACR関連の構成で、Storageファイアウォール越しのアクセス可否を再確認する
リソースプロバイダーMicrosoft.ContainerRegistry/registriesリソースインスタンスや権限棚卸しで確認対象に含める
変更の性質公式差分上は1行追加既存サービスの削除や強制移行ではなく、許可可能なサービス一覧の拡張として扱う
注意点追加されたからといって自動的に全ACRがアクセスできるわけではないネットワーク例外、マネージドID、AzureロールまたはACLを分けて確認する

この変更は、すべてのAzure Storage利用者に即時の作業を強制するものではありません。影響を受けやすいのは、ストレージアカウントのネットワークアクセスを制限しつつ、Azure Container Registryやデータ処理・監査・バックアップ系サービスと連携している環境です。

影響範囲：まず確認すべきAzure Storageアカウント

すべてのストレージアカウントを同じ優先度で確認する必要はありません。最初に見るべきなのは、次の条件に当てはまるアカウントです。

優先度対象確認理由
高Public network accessを制限しているストレージアカウントTrusted Azure servicesやリソースインスタンス規則の影響を受けやすい
高networkRuleSet.bypassにAzureServicesが含まれるアカウント信頼されたサービス例外が有効になっている可能性がある
高監査ログ、診断ログ、バックアップ、DR用のストレージアカウントAzure Monitor、Azure Backup、Azure Site Recoveryなどが関係しやすい
中Data Factory、Synapse、Databricks、Stream Analyticsなどと連携するアカウントマネージドIDとデータプレーン権限の不足で失敗しやすい
中Azure Container Registryと関連する構成を持つアカウント今回追加されたサービスに該当する可能性がある
中ADLS Gen2、階層型名前空間を有効にしたアカウントAzureロールだけでなくACL設計も必要になる
低完全にプライベートエンドポイント中心で設計されたアカウントただしパブリックエンドポイント側の例外が残っていないかは確認する

特に注意したいのは、Public network accessを無効化した場合でも、以前に設定したリソースインスタンスや信頼されたサービス例外が残る場合がある点です。Microsoft Learnでは、信頼されたサービスからのアクセスは他のネットワークアクセス制限より優先され、以前に構成された例外が有効なままになる可能性があると説明されています。(Microsoft Learn)

Trusted Azure servicesの一覧は2種類に分けて理解する

公式情報では、Azure Storageへの信頼されたアクセスは大きく2つに整理されています。

1つ目は、同じMicrosoft Entraテナントに登録されたリソースによるアクセスです。ログの書き込みやバックアップなど、選択された操作のためにストレージアカウントへアクセスできます。これらのサービスは、ストレージアカウントと同じMicrosoft Entraテナント内のサブスクリプションに登録されている必要があります。(Microsoft Learn)

サービスリソースプロバイダー主な用途
Azure BackupMicrosoft.RecoveryServicesIaaS VMのアンマネージドディスクのバックアップと復元
Azure Data BoxMicrosoft.DataBoxAzureへのデータインポート
Azure Data ExplorerMicrosoft.Kusto取り込み、外部テーブルの読み書き
Azure DevTest LabsMicrosoft.DevTestLabカスタムイメージ作成、成果物インストール
Azure Event GridMicrosoft.EventGridBlobイベント発行、ストレージキューへの発行
Azure Event HubsMicrosoft.EventHubEvent Hubs Captureによるアーカイブ
Azure File SyncMicrosoft.StorageSyncAzureファイル共有の同期、DR、クラウド側バックアップ
Azure HDInsightMicrosoft.HDInsightHDInsightクラスターの既定ファイルシステム初期化
Azure Import/ExportMicrosoft.ImportExportAzure Storageへのインポート、Azure Storageからのエクスポート
Azure MonitorMicrosoft.Insightsリソースログ、監査ログ、Intuneログなどの書き込み
Azure networking servicesMicrosoft.NetworkNetwork Watcherなどのネットワークログ保存・分析
Azure Site RecoveryMicrosoft.SiteRecoveryIaaS VMのディザスターリカバリー用レプリケーション

2つ目は、マネージドIDベースの信頼されたアクセスです。対象サービスのリソースインスタンスに適切なアクセス許可がある場合に、ストレージアカウントデータへアクセスできます。(Microsoft Learn)

分類対象サービス・リソースプロバイダー確認ポイント
API・アプリ連携Azure API Management Microsoft.ApiManagement/service、Logic Apps Microsoft.Logic/workflows Microsoft.Logic/integrationAccountsポリシーやワークフローからStorageへアクセスする場合、マネージドIDと権限を確認する
AI・検索Azure AI Search Microsoft.Search/searchServices、Foundry Tools Microsoft.CognitiveService/accounts、Azure Machine Learning関連インデックス作成、モデル出力、ログ保存先の権限不足に注意する
データ分析Azure Data Factory Microsoft.DataFactory/factories、Azure Databricks Microsoft.Databricks/accessConnectors、Azure Synapse Analytics Microsoft.Synapse/workspaces、Azure Stream Analyticsランタイム、ワークスペース、ジョブ単位でIDと権限を確認する
データベース・SQLAzure SQL Database Microsoft.Sql、Azure SQL Servers Microsoft.Sql/servers、Azure Database for PostgreSQL Microsoft.DBForPostgreSQL監査データ、COPY、PolyBase、外部テーブルの利用時に影響する
IoTAzure IoT Hub Microsoft.Devices/IotHubs、Azure IoT Central Microsoft.IoTCentral/IoTApps、Azure Device Registry Microsoft.DeviceRegistry/schemaRegistriesBlob Storageへのデータ書き込みやスキーマ関連のアクセスを確認する
監視・コスト・ガバナンスMicrosoft Cost Management Microsoft.CostManagementExports、Microsoft Purview Microsoft.Purview/accounts、Security Center Microsoft.Security/dataScannersエクスポート、スキャン、ガバナンス用ストレージで例外が必要か確認する
バックアップ・DR・移行Azure Backup Vault Microsoft.DataProtection/BackupVaults、Azure Site Recovery Microsoft.RecoveryServices/vaults、Azure Migrate Microsoft.Migrate/migrateprojects障害時にアクセスできないと復旧手順が止まるため、事前検証が重要
コンテナ・実行基盤Azure Container Registry Microsoft.ContainerRegistry/registries、Azure Managed Redis Microsoft.Cache/Redis、Azure Storage Actions Microsoft.Storageactions/Storagetasks今回の追加対象であるACRを含め、必要な範囲だけ許可する
イベント・メッセージングAzure Event Gridのdomains、topics、systemTopics、partnerTopicsイベント配信先やストレージキュー連携の失敗を確認する
業務・業界サービスMicrosoft Fabric Microsoft.Fabric、Healthcare APIs、Power Platform、Video Indexer、Media Servicesサービスごとのデータ保存先と権限境界を確認する
その他FarmBeats、Autonomous Systems、ExpressRoute、Project Arcadia、Data Catalog、Singularity、DevTest Labs、Data Share、Key Vault Managed HSM利用実態がないものまで例外で広げない

管理者が確認すべき設定

ネットワーク例外の状態を確認する

Azureポータルでは、ストレージアカウントのメニューから「Security + networking」配下の「Networking」を開き、仮想ネットワーク、IPアドレス、例外、リソースインスタンスの設定を確認します。Microsoft Learnでは、例外を付与する場合は「Exceptions」で対象を選択し、保存する手順が案内されています。(Microsoft Learn)

CLIで棚卸しする場合は、次のようにpublicNetworkAccess、defaultAction、bypass、resourceAccessRulesをまとめて確認すると実務で扱いやすくなります。

az storage account show \
  --resource-group <resource-group-name> \
  --name <storage-account-name> \
  --query "{
    publicNetworkAccess: publicNetworkAccess,
    defaultAction: networkRuleSet.defaultAction,
    bypass: networkRuleSet.bypass,
    resourceAccessRules: networkRuleSet.resourceAccessRules
  }"

bypassにAzureServicesが含まれている場合は、Trusted Azure servicesの例外が有効になっている可能性があります。例外を設定する場合は、Azure CLIで--bypass Logging Metrics AzureServicesを指定でき、削除する場合は--bypass Noneを指定できます。(Microsoft Learn)

# 例外を設定する例
az storage account update \
  --resource-group <resource-group-name> \
  --name <storage-account-name> \
  --bypass Logging Metrics AzureServices

# 例外を削除する例
az storage account update \
  --resource-group <resource-group-name> \
  --name <storage-account-name> \
  --bypass None

リソースインスタンス規則を確認する

特定のAzureリソースだけを許可したい場合は、広いTrusted services例外よりもリソースインスタンス規則を優先して検討します。Microsoft Learnでも、特定のリソースにアクセスを許可するにはリソースインスタンス規則の利用が推奨されています。(Microsoft Learn)

リソースインスタンス規則は、Azureポータルの「Resource instances」セクションでリソース種類とインスタンス名を選択して追加できます。CLIでは、許可済みのリソースインスタンス一覧を次のように確認できます。(Microsoft Learn)

az storage account network-rule list \
  --resource-group <resource-group-name> \
  --account-name <storage-account-name>

ただし、リソースインスタンス規則はネットワーク到達性を許可するだけです。データアクセスには、そのAzureリソースのシステム割り当てマネージドIDなどに適切なAzureロールを割り当てる必要があります。(Microsoft Learn)

ADLS Gen2ではACLも確認する

階層型名前空間を有効にしていないストレージアカウントでは、各リソースインスタンスのマネージドIDにAzureロールを割り当てることで権限を付与できます。一方、階層型名前空間を有効にしている場合は、ディレクトリやBlobのACLにマネージドIDを追加する設計も可能です。AzureロールとACLを組み合わせることもできます。(Microsoft Learn)

実務では、次のように分けて確認するとミスを減らせます。

ストレージ構成確認すべき権限
通常のBlob StorageマネージドIDへのデータプレーンAzureロール
ADLS Gen2Azureロール、ディレクトリACL、ファイルACL
複数サービスからの共有ストレージサービスごとのID、スコープ、最小権限
ログ・監査専用ストレージ書き込み専用で足りるか、読み取り権限が不要ではないか

移行・展開時の注意点

「AzureServicesをオンにすれば解決」と考えない

障害対応中にやりがちな失敗が、アクセスエラーを解消するためにAzureServices例外を安易に有効化することです。確かに短期的にはジョブやログ書き込みが復旧する場合がありますが、許可範囲が広がりすぎる可能性があります。

まずは、対象サービスが公式リストに含まれているか、特定のリソースインスタンス規則で足りるか、マネージドIDに必要なロールだけを割り当てられるかを確認します。恒久対応では、例外を最小化し、ストレージアカウント単位で「なぜこの例外が必要か」を記録しておくべきです。

パブリックアクセス無効化後も例外が残る可能性を確認する

Public network accessをDisabledにしたからといって、過去に設定した例外が完全に消えるとは限りません。Microsoft Learnでは、以前に構成されたリソースインスタンスや例外が残り、ストレージアカウントへアクセスできる可能性があると説明されています。(Microsoft Learn)

セキュリティレビューでは、publicNetworkAccessだけでなく、必ず次の値も確認してください。

az storage account show \
  --resource-group <resource-group-name> \
  --name <storage-account-name> \
  --query "{
    publicNetworkAccess: publicNetworkAccess,
    defaultAction: networkRuleSet.defaultAction,
    bypass: networkRuleSet.bypass,
    resourceAccessRules: networkRuleSet.resourceAccessRules
  }"

IPネットワーク規則でAzureサービスを絞り込もうとしない

IPネットワーク規則は、主にオンプレミスやインターネット側の固定IPからのアクセス制御に向いています。Azure Storageのファイアウォールでは、同じリージョンのAzureサービスからのアクセスをIPネットワーク規則で制限できないなどの制約があります。Microsoft Learnでも、同じリージョンのAzureサービスはプライベートAzure IPアドレスで通信するため、パブリック送信IP範囲では特定サービスに絞れないと説明されています。(Microsoft Learn)

Azureサービス間連携では、IP許可リストよりも次の順で検討するのが現実的です。

優先度選択肢向いているケース
高プライベートエンドポイント自社アプリやVNet内ワークロードから閉域アクセスしたい
高リソースインスタンス規則特定のAzureリソースだけ許可したい
中Trusted Azure services例外サービスの性質上、VNet/IP規則で表現しにくい
低IPネットワーク規則オンプレミス、固定グローバルIP、ExpressRouteのNAT IPなど

IaCテンプレートの差分も確認する

Azureポータルで一時的に例外を追加し、その後Bicep、ARMテンプレート、TerraformなどのIaCで上書きされるケースがあります。逆に、IaC側に古いbypass設定が残っていて、削除したはずのTrusted Azure services例外が再作成されることもあります。

展開前には、少なくとも次の項目をレビューしてください。

設定確認内容
publicNetworkAccessEnabled、Disabled、Selected networks相当の設計が意図どおりか
networkRuleSet.defaultAction原則Denyになっているか
networkRuleSet.bypassAzureServices、Logging、Metricsが本当に必要か
resourceAccessRules許可対象のリソースIDとテナントIDが正しいか
ロール割り当てマネージドIDに必要最小限のデータ権限があるか
ADLS Gen2 ACLディレクトリ階層ごとのACLが不足していないか

開発者が確認すべきポイント

開発者側では、「ストレージにアクセスできない」というエラーを単純な接続文字列やSASの問題として扱わないことが重要です。Azure Storageでは、ネットワーク規則と認可の両方を満たす必要があります。ネットワーク的に許可されていてもロールやACLが不足すれば失敗し、逆にロールがあってもネットワーク規則で拒否されればアクセスできません。

開発・検証時には、次の観点で切り分けます。

症状よくある原因確認ポイント
403が返るネットワーク拒否、RBAC不足、ACL不足が混在Storage診断ログ、マネージドID、ロール割り当てを確認する
ローカルでは成功するがAzure上で失敗実行環境の送信元が許可されていないVNet、Private Endpoint、リソースインスタンス規則を確認する
Data FactoryやSynapseだけ失敗ランタイムやワークスペースのIDに権限がない使用しているマネージドIDを特定する
ログ出力だけ失敗例外または書き込み権限が不足Azure Monitorや対象ログの保存先を確認する
本番だけ失敗IaC、ポリシー、ネットワーク規則の差分開発・本番のnetworkRuleSetを比較する

特に、マネージドIDを使う構成では「どのIDでStorageにアクセスしているか」を明確にしてください。サービス名ではなく、実際のリソースインスタンスとIDを基準に確認することが、権限ミスを減らす近道です。

よくある失敗と回避策

失敗しやすいポイント何が起きるか回避策
Trusted services例外だけを有効にする到達はできてもデータアクセス権限がなく失敗するマネージドID、Azureロール、ACLをセットで確認する
AzureServicesを恒久的に有効化する想定より広いサービス例外が残るリソースインスタンス規則で代替できないか検討する
パブリックアクセス無効化で安心する過去の例外が残りアクセス可能な場合があるbypassとresourceAccessRulesを明示的に確認する
IP規則でAzureサービスを制御しようとする同一リージョンのAzureサービスでは期待どおり制限できないPrivate Endpoint、VNet規則、リソースインスタンス規則を使う
ADLS Gen2のACLを見落とすロールはあるのに特定ディレクトリで失敗するディレクトリACLとファイルACLを確認する
IaCに古い設定が残る削除した例外が再展開されるテンプレートと実環境の差分をレビューする

実務で使える確認フロー

まず、対象ストレージアカウントを棚卸しします。AzureServices例外が有効なアカウント、リソースインスタンス規則があるアカウント、監査ログやバックアップに使っているアカウントを優先してください。

次に、アクセス元サービスを分類します。Azure Monitor、Azure Backup、Azure Site Recovery、Data Factory、Synapse、Databricks、Stream Analytics、Azure Container Registryなど、公式リストに含まれるサービスかを確認します。

そのうえで、次の順に判断します。

判断ステップ確認すること対応
サービスが公式リストにあるかTrusted Azure servicesまたはマネージドIDベース対象か対象外なら別方式を検討する
特定リソースだけ許可できるかリソースインスタンス規則で表現できるか可能ならリソースインスタンス規則を優先する
どのIDでアクセスするかシステム割り当てID、ユーザー割り当てID、サービス側ID対象IDに必要最小限の権限を付与する
データ権限は足りるかAzureロール、ACL、スコープ読み取り、書き込み、一覧取得の必要範囲を分ける
例外は必要最小限かAzureServices、Logging、Metrics、リソース規則不要な例外は削除する
展開後に検証したかログ、バックアップ、ジョブ、監査データの出力本番反映前にステージングで確認する

まとめ：次に取るべき対応

Trusted Azure services for Azure Storage network securityの更新で最初に行うべきことは、Azure Container Registryの追加そのものを確認するだけではありません。自社のAzure Storageで、どのネットワーク例外が有効になっているか、どのAzureサービスが実際にアクセスしているか、マネージドIDやAzureロール、ACLが最小権限になっているかを確認することです。

管理者は、networkRuleSet.bypassとresourceAccessRulesを棚卸しし、不要なAzureServices例外を削除するか、可能であればリソースインスタンス規則へ寄せてください。開発者は、Storageアクセス失敗時に接続文字列だけを見るのではなく、ネットワーク規則、マネージドID、RBAC、ACLを分けて切り分ける必要があります。

今回の更新をきっかけに、Azure Storageのネットワーク例外を「動けばよい設定」から「必要なサービスだけを説明できる設定」へ見直すことが、セキュリティと運用安定性の両面で最も効果的です。

Azure
ネットワークセキュリティ Azure Azure Storage Microsoft Entra マネージドID

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次