Azure Resource GraphでAzure Storageの露出レビューを効率化する実務シナリオ

Azure Storage の設定確認は、サブスクリプションが増えるほど「どのストレージアカウントが外部公開されているのか」「SFTPやNFS 3.0が有効なものはどれか」「TLS設定は安全か」を追いにくくなります。結論から言うと、2026年4月21日に Microsoft が公開した Azure Resource Graph 向けの Azure Storage 設定確認ガイダンスは、こうした棚卸し作業を スクリプト作成中心の運用から、KQLによる横断レビュー中心の運用へ変える ものです。 (TECHCOMMUNITY.MICROSOFT.COM)

特に Power users、管理者、ソリューションオーナーにとって重要なのは、「確認できる項目が増えた」というより、確認の起点を個別リソース画面から全体検索へ移せる ことです。Azure Portal の Resource Graph Explorer から複数サブスクリプションを対象にクエリを実行できるため、セキュリティレビュー、移行前調査、コスト最適化、監査対応の初動が速くなります。 (Microsoft Learn)

Azure Resource Graph / Azure Storage の最新動向で何が変わるのか

今回取り上げる Microsoft の記事は、Azure Storage アカウントの設定を Azure Resource Graph で確認する具体的な KQL クエリを示しています。対象は、SFTP、最小 TLS バージョン、Hierarchical Namespace、Blob の匿名パブリックアクセス、NFS 3.0、既定アクセス層、ネットワーク公開状態などです。 (TECHCOMMUNITY.MICROSOFT.COM)

ポイントは、これらを Azure CLI、PowerShell、REST API で個別に取得するのではなく、Azure Resource Graph Explorer で microsoft.storage/storageaccounts を横断検索する流れに置き換えられることです。Azure Resource Graph は、サブスクリプションをまたいだリソース探索や、プロパティによるフィルタリング、集計、並べ替えに使える Azure のサービスです。 (Microsoft Learn)

現場のワークフローで見ると、変化は次のようになります。

従来の作業	Azure Resource Graph 活用後
サブスクリプションごとに Storage account を開いて確認する	複数サブスクリプションを対象に KQL で一括抽出する
PowerShell / CLI スクリプトを作成・保守する	Azure Portal 上の Resource Graph Explorer で即時確認する
設定漏れを人手でチェックする	条件に合うアカウントだけを抽出してレビューする
監査時に都度リストを作る	クエリを保存し、定期レビューの型として使う
問題の有無をリソース所有者に聞く	対象アカウント名、リソースグループ、リージョンを一覧で渡す

この変化は、セキュリティ担当者だけでなく、アプリケーションオーナーやデータ基盤担当者にも影響します。たとえば「このプロジェクトで使っている Azure Storage は本当に閉じているのか」「本番環境で SFTP が有効なアカウントはどれか」を、会議中にその場で確認しやすくなります。

まず理解したい「storage account exposure review」とは

storage account exposure review は、Azure Storage アカウントが意図せず外部に露出していないかを確認する作業です。日本語では「ストレージアカウントの露出レビュー」と考えると分かりやすいでしょう。

ここでいう露出は、単に「インターネットから見えるか」だけではありません。実務では、次のような観点をまとめて確認します。

確認観点	代表的な確認項目	現場での意味
ネットワーク公開	Public network access、Firewall の既定動作	どこから接続できるか
データ公開	Blob public access	匿名アクセスの余地があるか
転送プロトコル	SFTP、NFS 3.0	想定外の接続経路が有効でないか
暗号化・通信	Minimum TLS version	古い TLS を許容していないか
データ基盤機能	Hierarchical Namespace	Data Lake 用の構成か
コスト・運用	Default access tier	Hot / Cool の選択が用途に合うか

重要なのは、これらの項目を別々のチームが見ていることです。ネットワーク担当はファイアウォール、セキュリティ担当は匿名アクセス、データ基盤担当は HNS、アプリ担当は SFTP を気にします。Azure Resource Graph を使うと、各チームが同じ Azure Storage インベントリを基準に会話できます。

Azure Resource Graph Explorer で確認する基本フロー

Azure Resource Graph Explorer は Azure Portal から利用できます。Microsoft Learn でも、Azure Portal で Resource Graph Explorer を開き、クエリを貼り付けて実行する流れが説明されています。 (Microsoft Learn)

実務で使う場合は、次の流れにするとレビュー作業が進めやすくなります。

手順	作業	判断ポイント
1	Azure Portal で Resource Graph Explorer を開く	対象ディレクトリ、管理グループ、サブスクリプションを確認する
2	Azure Storage 用の KQL を実行する	まずは全体一覧、その後にリスク条件で絞り込む
3	結果をリソースグループ、所有者、環境で分類する	本番、検証、共有基盤を分けて見る
4	問題候補をリソースオーナーへ確認する	仕様なのか設定漏れなのかを切り分ける
5	修正後に同じクエリを再実行する	変更が反映されたかを確認する
6	クエリを保存・共有する	月次レビューや監査前チェックに再利用する

Azure Resource Graph では、権限のあるリソースだけが結果として返ります。Microsoft Learn では、対象リソースに少なくとも読み取り権限が必要で、権限がない Azure オブジェクトは結果に出ないと説明されています。つまり、結果がゼロでも「全社に該当なし」とは限らず、検索範囲と権限の確認が必要です。 (Microsoft Learn)

利用シナリオ：外部公開されている Azure Storage を洗い出す

最も実務に直結するのは、ネットワーク制限が緩い Azure Storage アカウントの洗い出しです。Microsoft の記事では、Public network access が有効または未設定で、かつネットワーク ACL の既定動作が Allow のストレージアカウントを抽出するクエリが示されています。 (TECHCOMMUNITY.MICROSOFT.COM)

Resources
| where type =~ "microsoft.storage/storageaccounts"
| where (properties.publicNetworkAccess == "Enabled"
    or isnull(properties.publicNetworkAccess))
    and properties.networkAcls.defaultAction == "Allow"
| project name, resourceGroup, location

このクエリは、「外部公開されている可能性が高い候補」を最初に見つけるために使います。ここで大切なのは、抽出されたアカウントをすぐに「危険」と決めつけないことです。公開が業務要件として必要なケースもあります。

実務では、次のように分類して対応します。

抽出結果の状態	判断	次のアクション
本番環境で公開、用途不明	優先度高	所有者へ確認し、必要ならネットワーク制限を設定
検証環境で公開、期限不明	優先度中	利用期限を確認し、不要なら停止または制限
公開が仕様として必要	要管理	例外理由、責任者、レビュー期限を記録
共有基盤で公開	要詳細確認	Private Endpoint、Firewall、認証方式を含めて確認

このシナリオでよくある失敗は、クエリ結果だけで一括修正しようとすることです。公開設定を変更すると、アプリケーション、バッチ、外部連携、データ転送処理に影響する可能性があります。まずは「候補抽出」、次に「所有者確認」、最後に「変更」という順序にするのが安全です。

利用シナリオ：Blob の匿名パブリックアクセスを確認する

Azure Storage のレビューでは、ネットワーク到達性とあわせて Blob の匿名パブリックアクセス設定も確認します。Microsoft の記事では、properties.allowBlobPublicAccess == false により、匿名パブリック読み取りアクセスを許可しないストレージアカウントを抽出する例が紹介されています。 (TECHCOMMUNITY.MICROSOFT.COM)

Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.allowBlobPublicAccess == false
| project name, resourceGroup, location

現場では、逆に「許可されている、または未確認のもの」を見たい場面もあります。その場合は、まず次のように一覧化して状態を把握します。

Resources
| where type =~ "microsoft.storage/storageaccounts"
| project
    name,
    resourceGroup,
    location,
    allowBlobPublicAccess = properties.allowBlobPublicAccess

レビュー時の見方はシンプルです。

allowBlobPublicAccess	見方
false	アカウントレベルでは匿名パブリック読み取りアクセスが許可されていない
true	匿名公開が必要な用途か確認する
空または想定外	API バージョン、古いリソース、取得結果を確認する

公開 Web コンテンツ、静的サイト、外部配布用ファイルなど、Blob の公開が正当化されるケースはあります。ただし、社内データ、ログ、バックアップ、顧客関連データを扱うストレージでは、匿名アクセスの余地があるだけでリスクになります。

利用シナリオ：SFTP が有効な Storage account を棚卸しする

SFTP は外部取引先やレガシー連携で便利ですが、有効なストレージアカウントが増えると、接続元、認証、運用責任の管理が難しくなります。Microsoft の記事では、SFTP が有効なアカウントを抽出する KQL が示されています。 (TECHCOMMUNITY.MICROSOFT.COM)

Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.isSftpEnabled == true
| project name, resourceGroup, location

このクエリは、次のような場面で役立ちます。

場面	使い方
外部連携の棚卸し	SFTP を使っているアカウントを抽出し、取引先・用途・責任者を確認する
移行前調査	オンプレミス SFTP サーバーから Azure へ移行した範囲を確認する
監査対応	SFTP が有効なアカウントの一覧を作り、アクセス管理状況を確認する
コスト・運用見直し	使われていない SFTP 有効アカウントを廃止候補にする

注意点は、SFTP が有効であること自体が悪いわけではない点です。問題は「誰が使っているか分からない」「接続元制限や認証管理が確認されていない」「不要になったのに有効のまま」という状態です。

利用シナリオ：NFS 3.0 有効アカウントをデータ基盤・HPC用途として確認する

NFS 3.0 は、Linux クライアントから Azure Blob Storage をマウントする用途で使われます。Microsoft の記事では、NFS 3.0 が有効なストレージアカウントを抽出するクエリが紹介されています。 (TECHCOMMUNITY.MICROSOFT.COM)

Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.isNfsV3Enabled == true
| project name, resourceGroup, location

このクエリは、データ分析基盤、HPC、機械学習、バッチ処理環境のレビューで特に有効です。NFS 3.0 が有効なストレージは、通常のアプリケーション用 Blob ストレージとは利用パターンが異なることがあります。

確認すべきポイントは次の通りです。

確認項目	理由
利用している計算基盤	VM、HPC、分析基盤など、接続元を特定するため
ネットワーク制限	想定外の場所からマウントできないようにするため
データ分類	大量データ、研究データ、機密データなどの扱いを確認するため
所有者	データ基盤チームかアプリチームかを明確にするため
継続利用の必要性	一時プロジェクト終了後も有効なままになりやすいため

NFS 3.0 の有効化は、技術的には便利でも、運用上は「誰が管理する共有ストレージなのか」が曖昧になりがちです。Resource Graph で定期的に棚卸しすることで、利用実態のないアカウントを早期に見つけやすくなります。

利用シナリオ：Hierarchical Namespace の有効アカウントを Data Lake として把握する

Hierarchical Namespace、つまり HNS は Azure Data Lake Storage Gen2 に関係する重要な設定です。Microsoft の記事では、HNS が有効なストレージアカウントを抽出するクエリが示されています。 (TECHCOMMUNITY.MICROSOFT.COM)

Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.isHnsEnabled == true
| project name, resourceGroup, location

HNS が有効なアカウントは、単なるファイル置き場ではなく、データレイク、分析基盤、ETL処理、データ共有の中心になっている可能性があります。そのため、セキュリティレビューだけでなく、データガバナンスの観点でも重要です。

実務では、HNS 有効アカウントに対して次の情報を紐づけると管理しやすくなります。

追加で確認したい情報	目的
データオーナー	データの責任者を明確にする
利用部門	全社基盤か部門基盤かを分類する
連携サービス	Synapse、Databricks、Data Factory などとの関係を把握する
データ分類	機密性、個人情報、外部共有可否を判断する
バックアップ・保持方針	データ消失や過剰保持を防ぐ

HNS の有効・無効だけではリスク判断はできません。しかし、HNS 有効アカウントを一覧化することで、「データ基盤として管理すべき Azure Storage」を見つける入口になります。

利用シナリオ：最小 TLS バージョンを確認する

通信セキュリティのレビューでは、Azure Storage アカウントごとの最小 TLS バージョンを確認します。Microsoft の記事では、properties.minimumTlsVersion を投影して一覧化するクエリが紹介されています。 (TECHCOMMUNITY.MICROSOFT.COM)

Resources
| where type =~ "microsoft.storage/storageaccounts"
| project
    StorageAccount = name,
    resourceGroup,
    location,
    MinimumTLS = properties.minimumTlsVersion

このクエリの価値は、設定のばらつきを見つけられることです。特定のサブスクリプションだけ古い設定が残っている、検証環境では更新されたが本番環境は未対応、といった差分を見つけやすくなります。

実務では、結果を次のように見ます。

状態	対応の考え方
組織標準と一致	記録して完了
組織標準より古い	影響調査後に更新を検討
空または不明	リソースの状態、API、古い構成を確認
環境によって差がある	本番・検証・開発で理由を確認

TLS 設定の変更は、古いクライアントや外部連携に影響する場合があります。単純に一括変更するのではなく、接続元の把握、影響範囲の確認、変更日時の合意を含めて進めるべきです。

利用シナリオ：既定アクセス層を確認してコスト最適化につなげる

Azure Storage のレビューはセキュリティだけではありません。既定アクセス層の確認は、コスト最適化にもつながります。Microsoft の記事では、properties.accessTier を使って既定アクセス層を確認する例が紹介されています。 (TECHCOMMUNITY.MICROSOFT.COM)

Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend defaultAccessTier = tostring(properties.accessTier)
| project name, resourceGroup, location, kind, sku.name, defaultAccessTier

Hot / Cool のようなアクセス層は、データの利用頻度や取り出し方によって適切な選択が変わります。たとえば、頻繁に読み書きするアプリケーションデータを低頻度アクセス向けにしてしまうと、期待したコスト削減にならない場合があります。一方で、ほとんど参照されない保管データを高頻度アクセス向けのままにしていると、無駄なコストにつながる可能性があります。

レビューでは、次のように考えると判断しやすくなります。

データの使われ方	確認すべきこと
毎日アクセスされる	既定アクセス層が用途に合っているか
月数回しか参照しない	低頻度アクセス向けの選択肢を検討できるか
バックアップ・保管用途	ライフサイクル管理とセットで確認する
用途不明	所有者と利用状況を確認する

Resource Graph のクエリだけで最終的なコスト判断はできません。アクセス頻度、データ量、取り出し要件、可用性要件をあわせて確認する必要があります。ただし、「見直し候補を見つける」には非常に有効です。

管理者・Power users・solution owners 別の使い分け

Azure Resource Graph / Azure Storage の活用は、役割によって見るべき観点が変わります。全員が同じクエリを使っても、判断基準を分けることで実務に落とし込みやすくなります。

役割	主な関心	使うべきクエリ
管理者	セキュリティ、標準準拠、監査	Public network access、Blob public access、TLS
Power users	自チームのリソース把握、設定確認	SFTP、HNS、NFS、アクセス層
Solution owners	アプリ影響、外部連携、運用責任	SFTP、ネットワーク公開、リソースグループ別一覧
セキュリティ担当	露出リスク、例外管理	公開候補、匿名アクセス、TLS
データ基盤担当	データレイク、分析基盤	HNS、NFS、アクセス層

特に solution owners にとって重要なのは、Azure Resource Graph の結果を「セキュリティチームからの指摘」として受け取るのではなく、「自分のサービス構成を説明する材料」として使うことです。リソース一覧、公開理由、依存関係、変更時の影響をセットで整理しておくと、レビュー対応が大幅に楽になります。

実務で使えるレビュー用 KQL テンプレート

ここでは、現場でそのまま使いやすい形に整理した KQL テンプレートを紹介します。まずは一覧系クエリで全体像をつかみ、その後にリスク条件で絞り込むのがおすすめです。

Azure Storage アカウントの主要設定を一覧化する

Resources
| where type =~ "microsoft.storage/storageaccounts"
| project
    name,
    subscriptionId,
    resourceGroup,
    location,
    kind,
    sku = sku.name,
    publicNetworkAccess = properties.publicNetworkAccess,
    defaultNetworkAction = properties.networkAcls.defaultAction,
    allowBlobPublicAccess = properties.allowBlobPublicAccess,
    minimumTlsVersion = properties.minimumTlsVersion,
    isSftpEnabled = properties.isSftpEnabled,
    isHnsEnabled = properties.isHnsEnabled,
    isNfsV3Enabled = properties.isNfsV3Enabled,
    accessTier = properties.accessTier
| order by subscriptionId asc, resourceGroup asc, name asc

このクエリは、月次レビューの起点として使いやすい形式です。まずはすべての主要設定を横並びで確認し、そこから「公開されているもの」「SFTP が有効なもの」「TLS が古いもの」といった個別調査へ進みます。

公開リスク候補を優先的に見る

Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend
    publicNetworkAccess = tostring(properties.publicNetworkAccess),
    defaultNetworkAction = tostring(properties.networkAcls.defaultAction),
    allowBlobPublicAccess = tostring(properties.allowBlobPublicAccess)
| where (publicNetworkAccess == "Enabled" or isempty(publicNetworkAccess))
    or defaultNetworkAction == "Allow"
    or allowBlobPublicAccess == "true"
| project
    name,
    subscriptionId,
    resourceGroup,
    location,
    publicNetworkAccess,
    defaultNetworkAction,
    allowBlobPublicAccess
| order by subscriptionId asc, resourceGroup asc, name asc

このクエリは、厳密な脆弱性診断ではなく、レビュー候補の抽出に向いています。結果に出たアカウントは、公開理由、接続元制限、データ分類、所有者を確認します。

プロトコル有効化状況をまとめて見る

Resources
| where type =~ "microsoft.storage/storageaccounts"
| project
    name,
    subscriptionId,
    resourceGroup,
    location,
    isSftpEnabled = properties.isSftpEnabled,
    isNfsV3Enabled = properties.isNfsV3Enabled,
    isHnsEnabled = properties.isHnsEnabled
| where isSftpEnabled == true
    or isNfsV3Enabled == true
    or isHnsEnabled == true
| order by subscriptionId asc, resourceGroup asc, name asc

SFTP、NFS 3.0、HNS は、それぞれ利用目的がはっきりしていることが多い設定です。抽出結果に用途不明のアカウントがあれば、運用ドキュメントや設計書との突き合わせを優先しましょう。

レビュー結果を業務フローに組み込む方法

Azure Resource Graph のクエリは、単発で実行して終わりにすると効果が限定的です。実務で成果を出すには、運用フローに組み込む必要があります。

おすすめは、次の3段階です。

月次の「全体棚卸し」に使う

月次レビューでは、主要設定一覧クエリを実行し、前回との差分を確認します。Resource Graph Explorer では結果を CSV としてダウンロードできます。ただし、Microsoft Learn では Azure Portal からの CSV エクスポートに 55,000 レコードの制限があると説明されています。大規模環境では、対象範囲をサブスクリプションや管理グループで分ける運用を検討してください。 (Microsoft Learn)

月次レビューで見るべき項目は次の通りです。

チェック項目	目的
新規作成された Storage account	未レビューのリソースを早期発見する
公開設定の変更	意図しない公開を見つける
SFTP / NFS の新規有効化	外部連携や共有ストレージの増加を把握する
TLS 設定のばらつき	セキュリティ標準への未対応を確認する
用途不明アカウント	廃止・統合候補を見つける

監査前の「証跡作成」に使う

監査対応では、「確認した」という事実だけでなく、確認対象、条件、日時、結果、対応方針を残すことが重要です。Resource Graph の結果は、レビュー対象の一覧を作るのに向いています。

証跡として残すなら、次の項目をセットにします。

項目	記録例
実行日	2026-04-21 以降のレビュー日
対象範囲	管理グループ名、サブスクリプション ID
使用クエリ	KQL 本文
抽出結果	CSV または表
判断	問題なし、要確認、例外承認、修正予定
責任者	リソースオーナー、承認者
次回確認日	例外の期限管理に使う

「公開されているかどうか」だけでなく、「公開が必要な理由と期限」を残すと、例外管理が属人化しにくくなります。

インシデント初動の「影響範囲確認」に使う

たとえば、外部公開に関するアラートや、特定プロトコルの利用見直しが発生した場合、最初に必要なのは影響範囲の把握です。Azure Resource Graph を使えば、対象条件に合う Azure Storage アカウントを短時間で抽出できます。

インシデント初動では、次の順序が実用的です。

順序	作業
1	条件に合う Storage account を抽出する
2	本番・検証・開発に分類する
3	リソースオーナーを特定する
4	公開設定、プロトコル、データ分類を確認する
5	影響の大きいものから変更計画を立てる

ここでも、クエリ結果だけで即時変更しないことが重要です。特に本番環境では、外部連携、夜間バッチ、データ転送、SaaS 連携が依存している可能性があります。

Azure Resource Graph を使うときの注意点

Azure Resource Graph は強力ですが、万能の監査ツールではありません。現場で使う際は、次の点を押さえておく必要があります。

注意点	実務上の対策
権限がないリソースは見えない	実行者の RBAC と対象範囲を確認する
結果はリソース構成の検索であり、通信ログではない	実際のアクセス状況はログや監視データも見る
クエリ条件によって見落としが起きる	一覧クエリと絞り込みクエリを併用する
設定変更の影響は判断できない	アプリオーナーに確認してから変更する
大規模環境では件数制限や絞り込みが必要	サブスクリプション、環境、リソースグループ単位で分割する
プロパティ名はリソーススキーマに依存する	Microsoft.Storage/storageAccounts のスキーマを確認する

Microsoft Learn では、Azure Resource Graph は Azure Resource Manager からの更新通知や定期スキャンによってデータを最新に保つ仕組みが説明されています。一方で、業務上は「設定変更直後の確認」や「厳密な監査証跡」では、必要に応じて Azure Portal、Azure Policy、ログ、CLI などと併用するのが安全です。 (Microsoft Learn)

Azure Policy や Defender for Cloud とどう使い分けるか

Azure Storage の管理では、Azure Resource Graph だけでなく、Azure Policy や Microsoft Defender for Cloud も使われます。これらは競合するものではなく、役割が異なります。

ツール	得意なこと	使う場面
Azure Resource Graph	現在の構成を横断検索する	棚卸し、初動調査、レビュー対象抽出
Azure Policy	ルールに基づいて準拠状況を評価する	継続的なガバナンス、標準設定の強制
Defender for Cloud	セキュリティ推奨事項や脅威検知を扱う	セキュリティ態勢管理、リスク対応
Azure Monitor / Log Analytics	ログやメトリックを分析する	実際のアクセス状況、時系列分析

実務では、Azure Resource Graph で「どのリソースが対象か」を見つけ、Azure Policy で「標準に準拠しているか」を管理し、ログで「実際に使われているか」を確認する流れが有効です。

たとえば、Resource Graph で公開設定の候補を抽出し、例外が必要なものは Azure Policy の除外や管理プロセスに載せる。さらに、公開が必要とされたアカウントについてはアクセスログや診断設定を確認する。このように役割を分けると、単発チェックではなく継続的なクラウドガバナンスに近づきます。

導入時にありがちな失敗と回避策

Azure Resource Graph の活用でよくある失敗は、技術的なクエリよりも運用設計にあります。

クエリを作っただけで運用に載せない

KQL を作っても、誰が、いつ、どの範囲で実行し、結果をどう判断するかが決まっていなければ定着しません。最低限、月次レビュー、監査前レビュー、インシデント時レビューの3パターンを決めておくと使いやすくなります。

「公開されている＝違反」と単純化する

外部公開が必要なシステムもあります。重要なのは、公開の有無ではなく、公開理由、責任者、認証、ネットワーク制限、レビュー期限が管理されているかです。

権限不足による見落としに気づかない

Resource Graph の結果は、実行者が読める範囲に依存します。全社レビューでは、管理グループ単位の権限設計や、レビュー専用アカウントの利用を検討する必要があります。

修正を急ぎすぎて業務影響を出す

Storage account の公開設定、SFTP、NFS、TLS を変更すると、アプリや外部連携が停止する場合があります。特に本番環境では、事前の影響確認と変更計画が必須です。

所有者情報が整理されていない

クエリで問題候補を見つけても、所有者が分からなければ対応が止まります。Azure タグ、命名規則、CMDB、チケット管理と組み合わせ、リソースオーナーを追える状態にしておくことが重要です。

まず実行すべき実務アクション

Azure Resource Graph / Azure Storage の今回の更新を業務に活かすなら、最初にやるべきことは多くありません。次の順序で進めると、短期間で効果を出しやすくなります。

優先度	アクション	目的
高	Azure Resource Graph Explorer で主要設定一覧を実行する	全体像を把握する
高	公開候補の Storage account を抽出する	露出レビューの起点を作る
高	SFTP / NFS / HNS 有効アカウントを一覧化する	特殊用途のアカウントを把握する
中	TLS とアクセス層を確認する	セキュリティ標準とコストの見直しにつなげる
中	クエリ結果に所有者情報を紐づける	対応フローを止めない
中	月次レビュー用の保存クエリを整備する	単発作業から継続運用へ移す

最初から完璧なガバナンスを作ろうとする必要はありません。まずは「全 Azure Storage アカウントの主要設定を一覧化できる状態」を作ることが第一歩です。その後、公開設定、SFTP、NFS、HNS、TLS、アクセス層の順にレビュー観点を広げていけば、現場に負担をかけすぎずに運用を改善できます。

Azure Resource Graph の価値は、クラウド管理を「個別リソースを見に行く作業」から「条件で全体を把握する作業」へ変える点にあります。Azure Storage の露出レビューでは、この変化が特に大きく効きます。まずは Azure Portal で Resource Graph Explorer を開き、自社の Storage account がどのような状態にあるかを一覧で確認してみてください。