Azure Resource Graph / Azure Storage の管理者が今回の更新でまず行うべきことは、全ストレージアカウントを横断検索し、「外部から到達しやすい設定」「匿名アクセスを許可し得る設定」「SFTP・NFS など追加プロトコルの有効化」「TLS の下限」を棚卸しすることです。
Microsoft は 2026年4月21日に、Azure Resource Graph Explorer を使って Azure Storage の構成を大規模に確認するガイダンスを公開しました。内容は新機能の発表というより、管理者が監査・セキュリティレビュー・設定差分確認で使いやすい KQL クエリ集に近いものです。特に、複数サブスクリプションにまたがる Storage account exposure review、つまりストレージアカウントの露出レビューを短時間で始めたい IT admins、operations owners、deployment planners にとって実用性があります。(TECHCOMMUNITY.MICROSOFT.COM)
結論として、発表直後にやるべき作業は「クエリを実行する」だけでは不十分です。結果を資産台帳・タグ・所有者・変更計画と結び付け、影響確認、周知、段階的な是正まで含めて運用に落とし込む必要があります。
Azure Resource Graph / Azure Storage の最新動向で管理者が押さえるべきポイント
Microsoft のガイダンスでは、Azure Resource Graph Explorer から KQL を実行し、microsoft.storage/storageaccounts を対象に Storage account の構成を確認する方法が紹介されています。対象項目には、SFTP、最小 TLS バージョン、Hierarchical Namespace、Blob の匿名パブリックアクセス、NFS 3.0、既定のアクセス層、ネットワーク制限の有無が含まれます。(TECHCOMMUNITY.MICROSOFT.COM)
Azure Resource Graph は Kusto Query Language、つまり KQL をベースにしたクエリで Azure リソースを検索できます。Azure Storage だけでなく、他の Azure リソースにも同じ考え方を展開できるため、単発の確認ではなく「構成レビューの標準手順」として整備する価値があります。(Microsoft Learn)
今回の更新を管理者目線で見ると、重要なのは次の3点です。
| 観点 | 管理者が確認すべきこと | 実務上の意味 |
|---|---|---|
| 露出レビュー | パブリックネットワーク、匿名アクセス、SFTP、NFS 3.0 を横断確認する | 意図せず外部到達可能なストレージを早期に見つける |
| 設定差分 | 前回の棚卸し結果と比較する | 変更申請なしの有効化、例外設定、運用ミスを検知しやすくする |
| 展開計画 | クエリ、所有者確認、是正、周知を順序化する | いきなり設定変更して業務アプリを止めるリスクを下げる |
最初に確認するべき Azure Storage の露出レビュー項目
Azure Storage の露出レビューでは、「危険そうな設定」を単純に悪と決めつけるのではなく、業務要件と照合して判断します。たとえば SFTP が有効でも、取引先連携で必要な場合があります。一方で、所有者不明のストレージアカウントで SFTP や NFS が有効なら、優先度を上げて確認すべきです。
| 確認項目 | 参照する主なプロパティ | 優先度 | 判断基準 |
|---|---|---|---|
| 全ネットワークからの到達可能性 | properties.publicNetworkAccess、properties.networkAcls.defaultAction | 高 | publicNetworkAccess が有効または未設定で、defaultAction が Allow の場合は最優先で確認 |
| Blob の匿名アクセス許可 | properties.allowBlobPublicAccess | 高 | true の場合、コンテナー側の設定次第で匿名アクセスが成立し得るため確認 |
| 最小 TLS バージョン | properties.minimumTlsVersion | 中〜高 | 古い TLS を許可していないか、組織の基準と比較 |
| SFTP 有効化 | properties.isSftpEnabled | 中 | 取引先連携、ローカルユーザー、鍵管理、不要アカウントの有無を確認 |
| NFS 3.0 有効化 | properties.isNfsV3Enabled | 中〜高 | ネットワーク制御とワークロード要件を確認 |
| HNS 有効化 | properties.isHnsEnabled | 中 | Data Lake Storage Gen2 や SFTP/NFS 利用の前提として管理対象に含める |
| 既定アクセス層 | properties.accessTier | 低〜中 | セキュリティよりもコスト・運用設計の確認に使う |
allowBlobPublicAccess は「そのストレージアカウント配下の Blob がすでに公開されている」という意味ではありません。アカウント単位で匿名アクセスを許可できるかどうかを示す設定であり、実際の匿名公開はコンテナー側の設定も関係します。ただし、アカウントで匿名アクセスを禁止すると、そのアカウント内のコンテナー設定を上書きし、以後の匿名要求は失敗するため、変更前にアプリケーション影響を確認する必要があります。(Microsoft Learn)
また、Azure Storage のネットワーク規則は defaultAction を Deny にしないと効果がありません。既存アプリが接続している環境では、許可する仮想ネットワーク、IP アドレス、Private Endpoint を先に整理してから変更します。(Microsoft Learn)
導入前チェックリスト
Azure Resource Graph を使った Azure Storage の露出レビューを始める前に、次の項目を確認します。ここを飛ばすと、クエリ結果が不完全だったり、是正作業でアプリ停止を招いたりします。
| チェック項目 | 確認内容 | 完了基準 |
|---|---|---|
| 対象スコープ | 管理グループ、サブスクリプション、環境区分、本番・非本番を決める | レビュー対象のサブスクリプション一覧がある |
| 権限 | クエリ実行者が対象リソースに読み取り権限を持つか確認する | 少なくとも対象サブスクリプションの Reader 相当の参照権限がある |
| 所有者情報 | タグ、CMDB、IaC リポジトリ、運用台帳と突き合わせる | 各ストレージアカウントの owner / system / environment が分かる |
| 基準値 | 組織として許容するネットワーク、TLS、匿名アクセス、SFTP/NFS の基準を決める | 「許可」「要確認」「原則禁止」の分類がある |
| 影響確認 | Storage を利用するアプリ、バッチ、SFTP クライアント、分析基盤を確認する | 設定変更前に連絡すべきチームが分かる |
| 記録方法 | クエリ結果の保存先、差分比較方法、チケット化ルールを決める | レビュー結果を後から追跡できる |
| 例外管理 | 業務上必要な公開・SFTP・NFS をどう承認するか決める | 期限付き例外、承認者、再レビュー日が記録される |
Azure Resource Graph の結果は、実行者がアクセスできるサブスクリプションに依存します。明示的にサブスクリプション一覧を渡す場合、読み取り権限がない範囲を含めると権限エラーになることがあります。大規模環境では、実行アカウントと対象スコープを先にそろえることが重要です。(Microsoft Learn)
Azure Resource Graph Explorer で露出レビューを始める手順
Azure Portal から始める場合は、Azure Resource Graph Explorer を使うのが最も簡単です。Microsoft のガイダンスでも、ポータルの検索バーから Resource Graph Explorer を開き、KQL を貼り付けて実行する流れが示されています。(TECHCOMMUNITY.MICROSOFT.COM)
| 手順 | 作業 | 補足 |
|---|---|---|
| 1 | Azure Portal にサインインする | レビュー対象に読み取り権限があるアカウントを使う |
| 2 | 検索バーで Resource Graph Explorer を開く | 複数サブスクリプションの確認に向く |
| 3 | 対象スコープを確認する | 必要に応じてサブスクリプションを選択 |
| 4 | KQL クエリを貼り付ける | まずは検出用クエリ、次に詳細確認用クエリを実行 |
| 5 | 結果を CSV などにエクスポートする | チケット化、差分比較、所有者確認に使う |
| 6 | 高リスク項目からレビューする | open network、匿名アクセス、古い TLS、不要な SFTP/NFS を優先 |
初回はすべての項目を一度に直そうとせず、検出、分類、所有者確認、是正の順に進めます。特に本番環境のストレージアカウントでは、ネットワーク設定や匿名アクセス設定の変更がアプリケーション接続に影響する可能性があります。
そのまま使える KQL クエリ
以下のクエリは、管理者が発表直後に全体像をつかむための例です。環境に合わせて、subscriptionId、タグ、リソースグループ名、命名規則で絞り込んでください。
ストレージアカウントの露出候補を一覧化する
まずは、外部到達性、匿名アクセス許可、SFTP、NFS、TLS をまとめて確認します。
Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend defaultAction = tostring(properties.networkAcls.defaultAction)
| extend allowBlobPublicAccess = tostring(properties.allowBlobPublicAccess)
| extend minimumTlsVersion = tostring(properties.minimumTlsVersion)
| extend isSftpEnabled = tostring(properties.isSftpEnabled)
| extend isNfsV3Enabled = tostring(properties.isNfsV3Enabled)
| extend isHnsEnabled = tostring(properties.isHnsEnabled)
| extend defaultAccessTier = tostring(properties.accessTier)
| extend skuName = tostring(sku.name)
| extend openNetwork = (publicNetworkAccess == "Enabled" or isempty(publicNetworkAccess)) and defaultAction == "Allow"
| extend publicBlobAllowed = allowBlobPublicAccess == "true"
| extend sftpEnabled = isSftpEnabled == "true"
| extend nfsEnabled = isNfsV3Enabled == "true"
| extend tlsNeedsReview = minimumTlsVersion in ("TLS1_0", "TLS1_1") or isempty(minimumTlsVersion)
| where openNetwork or publicBlobAllowed or sftpEnabled or nfsEnabled or tlsNeedsReview
| project
subscriptionId,
resourceGroup,
name,
location,
kind,
skuName,
openNetwork,
publicNetworkAccess,
defaultAction,
publicBlobAllowed,
allowBlobPublicAccess,
minimumTlsVersion,
sftpEnabled,
nfsEnabled,
isHnsEnabled,
defaultAccessTier,
tags
| order by subscriptionId asc, resourceGroup asc, name ascこのクエリで出た結果は「即時に設定変更すべき一覧」ではなく、「優先レビュー対象」です。たとえば CDN や静的コンテンツ配信用に意図的に公開しているアカウントもあり得ます。重要なのは、所有者、用途、承認履歴、現在のアクセス経路を確認することです。
全ネットワークから到達可能なストレージアカウントを抽出する
Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend defaultAction = tostring(properties.networkAcls.defaultAction)
| where (publicNetworkAccess == "Enabled" or isempty(publicNetworkAccess))
and defaultAction == "Allow"
| project subscriptionId, resourceGroup, name, location, publicNetworkAccess, defaultAction, tags
| order by subscriptionId asc, resourceGroup asc, name ascこの結果は最優先で確認します。修正候補は、Private Endpoint 化、特定 VNet / IP への制限、defaultAction = Deny、または publicNetworkAccess = Disabled です。ただし、許可ネットワークを作る前に遮断するとアプリケーションが接続できなくなるため、変更順序を必ず設計します。
Blob の匿名アクセスを許可し得るアカウントを確認する
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.allowBlobPublicAccess == true
| project subscriptionId, resourceGroup, name, location, allowBlobPublicAccess = properties.allowBlobPublicAccess, tags
| order by subscriptionId asc, resourceGroup asc, name ascこのクエリでは、実際に公開されているコンテナーまでは確定できません。次の確認として、対象ストレージアカウントのコンテナー単位の匿名アクセス設定、アクセスログ、アプリケーション要件を見ます。公開が必要なコンテナーがある場合は、匿名公開専用のストレージアカウントへ分離する設計も検討します。
最小 TLS バージョンを棚卸しする
Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend minimumTlsVersion = tostring(properties.minimumTlsVersion)
| project subscriptionId, resourceGroup, name, location, minimumTlsVersion, tags
| order by minimumTlsVersion asc, subscriptionId asc, resourceGroup asc, name ascminimumTlsVersion は、ストレージへの要求で許可される最小 TLS バージョンを示すプロパティです。Microsoft.Storage のリファレンスでは TLS1_0、TLS1_1、TLS1_2、TLS1_3 が値として示されています。組織の基準が TLS 1.2 以上であれば、TLS1_0 や TLS1_1 は是正候補です。(Microsoft Learn)
SFTP が有効なストレージアカウントを確認する
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.isSftpEnabled == true
| project subscriptionId, resourceGroup, name, location, isSftpEnabled = properties.isSftpEnabled, isHnsEnabled = properties.isHnsEnabled, tags
| order by subscriptionId asc, resourceGroup asc, name ascAzure Blob Storage の SFTP は、ローカルユーザー、パスワードまたは SSH 鍵、コンテナー単位の権限管理が関係します。SFTP エンドポイントでは Microsoft Entra ID がサポートされない制約もあるため、不要な有効化、放置されたローカルユーザー、古い鍵、取引先退職者のアカウントを重点的に確認します。(Microsoft Learn)
NFS 3.0 が有効なストレージアカウントを確認する
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.isNfsV3Enabled == true
| project subscriptionId, resourceGroup, name, location, isNfsV3Enabled = properties.isNfsV3Enabled, isHnsEnabled = properties.isHnsEnabled, tags
| order by subscriptionId asc, resourceGroup asc, name ascNFS 3.0 は、Linux クライアントから Blob Storage をマウントする用途で有効です。一方で、NFS 3.0 のデータ保護はネットワーク制御に強く依存します。Microsoft のドキュメントでも、データを保護する方法として仮想ネットワークやネットワークセキュリティ設定が重要であることが示されています。(Microsoft Learn)
設定差分を確認する運用フロー
発表直後のレビューでは、単発のスキャンで終わらせず、前回結果との比較を作ることが重要です。差分が分かると、誰が、いつ、どの設定を変えたのかを追いやすくなります。
| フェーズ | 作業 | 成果物 |
|---|---|---|
| 初回棚卸し | 全サブスクリプションでクエリを実行 | baseline CSV |
| 分類 | 高リスク、要確認、承認済み例外に分ける | review list |
| 所有者確認 | タグ、CMDB、リソースグループ、IaC から担当を確認 | owner mapping |
| 是正計画 | 影響、変更手順、ロールバック方針を整理 | change plan |
| 変更 | 非本番、本番低影響、本番高影響の順に展開 | change record |
| 再確認 | 同じクエリで変更後の状態を確認 | after CSV |
| 定期化 | 週次・月次・リリース前に再実行 | recurring review |
差分レビューでは、次のような観点で見ると実務に落とし込みやすくなります。
| 差分 | 優先度 | 対応 |
|---|---|---|
defaultAction が Deny から Allow に変わった | 高 | 変更申請と所有者を即確認 |
allowBlobPublicAccess が false から true に変わった | 高 | 公開理由、対象コンテナー、期間を確認 |
isSftpEnabled が false から true に変わった | 中〜高 | ローカルユーザー、接続元、鍵管理を確認 |
isNfsV3Enabled が false から true に変わった | 中〜高 | ネットワーク制限とワークロード要件を確認 |
minimumTlsVersion が低い値になった | 高 | 互換性理由の有無を確認し、是正計画を作成 |
| タグの owner / environment が消えた | 中 | 管理不能リソースとして台帳更新を依頼 |
是正の優先順位は「露出度」と「業務影響」で決める
Azure Storage の設定変更は、セキュリティ上は望ましくても、業務アプリに影響することがあります。したがって、優先順位はリスクだけでなく、業務影響と変更難易度を含めて判断します。
最優先で対応するケース
次の条件に当てはまる場合は、速やかに所有者確認と是正計画を開始します。
- [ ] 本番環境で
defaultAction = Allowのまま公開ネットワークが有効 - [ ] 所有者不明のストレージアカウントで匿名アクセス許可が有効
- [ ] 機密データを扱うアカウントで SFTP または NFS 3.0 が有効
- [ ] 古い TLS バージョンを許可している
- [ ] タグや台帳がなく、用途が判断できない
すぐに無効化せず確認するケース
次のケースでは、設定だけを見て即時変更すると障害につながる可能性があります。
- [ ] Web サイトや CDN 向けに Blob 公開が業務要件になっている
- [ ] 取引先とのファイル連携で SFTP を使用している
- [ ] HPC、分析基盤、オンプレ連携で NFS 3.0 を使っている
- [ ] 古いクライアントの互換性維持で TLS 設定に例外がある
- [ ] 移行期間中で一時的にパブリックネットワークを許可している
このような場合は、無効化ではなく、期限付き例外、アクセス元制限、専用アカウントへの分離、監査ログ確認、変更期限の設定を行います。
設定変更前に周知すべき内容
Azure Storage の露出レビューは、セキュリティチームだけで完結しません。アプリ担当、ネットワーク担当、データ基盤担当、運用監視担当、外部連携先に影響することがあります。
| 周知先 | 伝える内容 | 伝えないと起きる問題 |
|---|---|---|
| アプリケーション担当 | 対象ストレージ、予定変更、影響確認依頼 | 接続断、バッチ失敗、アップロード失敗 |
| ネットワーク担当 | Private Endpoint、VNet、IP 許可リストの変更 | 名前解決や経路設計の不整合 |
| セキュリティ担当 | 高リスク設定、例外、是正期限 | 監査指摘への説明不足 |
| データ基盤担当 | HNS、NFS、アクセス層の確認 | 分析ジョブやマウント処理の停止 |
| ヘルプデスク | 変更予定、想定問い合わせ、切り戻し窓口 | 障害時の一次対応が遅れる |
| 外部連携先 | SFTP 接続元、鍵、接続試験日 | 取引先連携の失敗 |
周知文には、技術用語だけでなく「何が変わるのか」「誰が確認すべきか」「いつまでに返答が必要か」を明記します。
周知文の例
件名: Azure Storage ネットワーク・匿名アクセス設定レビューのご確認
対象:
該当サブスクリプション内の Azure Storage アカウント
背景:
Microsoft の Azure Resource Graph ガイダンスを踏まえ、Storage account exposure review を実施しています。
パブリックネットワーク、Blob 匿名アクセス、SFTP、NFS 3.0、最小 TLS バージョンを確認します。
依頼事項:
対象ストレージアカウントについて、業務利用の有無、公開・SFTP・NFS が必要な理由、変更不可期間を回答してください。
回答期限:
YYYY/MM/DD
注意:
回答がない場合でも即時停止は行いませんが、所有者不明リソースとして追加確認対象にします。
設定変更が必要な場合は、別途変更申請と影響確認を行います。展開順序のおすすめ
露出レビューの展開は、全社一斉ではなく段階的に進めます。特にグローバル環境では、地域ごとの運用時間、規制、ネットワーク構成、外部連携先が異なるため、同じ設定変更でも影響が変わります。
| 順序 | 対象 | 目的 |
| -: | ———— | ————————– |
| 1 | 非本番サブスクリプション | クエリ精度、タグ不足、例外分類を確認 |
| 2 | 本番の低リスク環境 | 変更手順と周知テンプレートを検証 |
| 3 | 本番の高リスク候補 | 所有者確認後に個別計画で是正 |
| 4 | グローバル拠点・外部連携 | タイムゾーン、取引先、ネットワーク制約を踏まえて展開 |
| 5 | 定期レビュー化 | 月次、四半期、リリース前チェックに組み込む |
最初から完璧な基準を作るより、初回レビューで実態を把握し、2回目以降に基準を厳密化する方が現実的です。たとえば「匿名アクセス許可は原則禁止。ただし公開コンテンツ専用アカウントは承認済み例外」といった形で、例外の扱いを明文化します。
共有クエリとして標準化する
運用チームが同じ KQL を毎回貼り付けて使うと、クエリの改変や列不足が起きやすくなります。Azure Resource Graph Explorer ではクエリを Private query または Shared query として保存できます。Shared query は Azure Resource Manager リソースとして保存され、Azure RBAC で管理できます。(Microsoft Learn)
共有クエリ化する場合は、次のように分けると使いやすくなります。
| クエリ名 | 用途 |
|---|---|
| storage-exposure-overview | 露出候補をまとめて検出 |
| storage-open-network | 全ネットワーク許可の確認 |
| storage-blob-public-access | Blob 匿名アクセス許可の確認 |
| storage-sftp-enabled | SFTP 有効アカウントの確認 |
| storage-nfs-enabled | NFS 3.0 有効アカウントの確認 |
| storage-tls-review | TLS 下限の棚卸し |
Shared query を保存するリソースグループには、更新権限を限定します。閲覧者が勝手に基準を変更できる状態だと、監査結果の再現性が失われます。クエリ本文を GitHub、Azure Repos、または社内 Wiki にも保管し、変更履歴を残すと運用しやすくなります。
よくある失敗と回避策
クエリ結果を「危険リスト」としてそのまま共有してしまう
Azure Resource Graph の結果は、あくまで構成上の候補です。たとえば allowBlobPublicAccess = true は「匿名アクセスを許可し得る」状態であり、必ずしも全 Blob が公開されているとは限りません。
回避策は、結果を「検出」「確認中」「承認済み例外」「是正予定」「対応完了」に分類することです。セキュリティ指摘として投げる前に、所有者と用途を確認します。
ネットワーク設定を先に閉じてアプリを止める
defaultAction = Deny や publicNetworkAccess = Disabled は有効な対策ですが、許可ルールや Private Endpoint が整っていない状態で変更すると、アプリケーション、SFTP クライアント、分析ジョブが接続できなくなります。
回避策は、接続元の棚卸し、許可ルール作成、名前解決確認、非本番テスト、本番変更の順に進めることです。
SFTP のローカルユーザーを見落とす
SFTP が有効かどうかだけを確認しても不十分です。ローカルユーザー、認証方式、SSH 鍵、コンテナー権限、利用期限を確認しなければ、退職者や不要な取引先アカウントが残る可能性があります。
回避策は、SFTP 有効アカウントを抽出した後、ローカルユーザー一覧と権限を別途確認し、棚卸し対象に含めることです。
タグ不足で所有者確認が止まる
露出候補が出ても、owner や application タグがないと確認先が分かりません。結果として、是正が長期化します。
回避策は、Storage account exposure review と同時にタグ整備を進めることです。最低限、owner、application、environment、data-classification、exception-expiry を使うと、後続作業が楽になります。
運用に組み込む最終チェックリスト
最後に、発表直後の対応から定期運用までをチェックリスト化します。
初日〜3日以内
- [ ] Microsoft のガイダンス内容を確認した
- [ ] レビュー対象サブスクリプションを決めた
- [ ] 実行アカウントの読み取り権限を確認した
- [ ] 露出候補クエリを実行した
- [ ] 結果を CSV などで保存した
- [ ] open network、匿名アクセス、古い TLS、SFTP、NFS を優先分類した
1週間以内
- [ ] 所有者不明のストレージアカウントを抽出した
- [ ] 高リスク候補をアプリ担当に確認依頼した
- [ ] 承認済み例外と未承認設定を分けた
- [ ] 変更が必要な項目をチケット化した
- [ ] 周知文と変更手順を作成した
- [ ] 非本番で設定変更の影響を確認した
1か月以内
- [ ] Shared query として標準化した
- [ ] 月次または四半期レビューに組み込んだ
- [ ] 例外の期限管理を始めた
- [ ] タグ不足の是正ルールを作った
- [ ] Azure Policy、Defender for Cloud、監査ログとの連携方針を決めた
- [ ] 前回結果との差分レビューを開始した
まとめ
Azure Resource Graph / Azure Storage の管理者にとって、2026年4月21日の Microsoft ガイダンスは、ストレージアカウントの露出レビューを標準化する良いきっかけになります。
まず実行すべきことは、Azure Resource Graph Explorer で Storage account を横断検索し、パブリックネットワーク、Blob 匿名アクセス、TLS、SFTP、NFS 3.0、HNS を棚卸しすることです。そのうえで、検出結果を所有者確認、例外管理、変更計画、周知、定期レビューへつなげます。
クエリは発見の入口であり、設定変更のゴールではありません。次に取るべき行動は、自社環境の対象スコープを決め、露出候補クエリを実行し、結果を「すぐ是正」「要確認」「承認済み例外」に分類することです。そこまでできれば、Azure Storage の露出レビューは単発対応ではなく、継続的な運用品質の改善に変えられます。
コメント