Azure Storageの公開範囲やSFTP有効化、TLS設定を「どのサブスクリプションに、どれだけ、誰の責任で存在するのか」まで把握できていない場合、最初にやるべきことは個別のストレージアカウント確認ではありません。Azure Resource Graphで横断的に棚卸しし、危険度と例外理由を分類することです。
2026年4月21日にMicrosoft Tech Communityで公開されたAzure Resource Graphクエリ活用ガイダンスは、Azure Storageの設定確認をPowerShellやAzure CLIの都度実行から、KQLによる大規模な構成レビューへ移す流れを示しています。記事では、SFTP、最小TLSバージョン、階層型名前空間、匿名BLOBアクセス、NFS 3.0、アクセス層、ネットワーク制限のないストレージアカウントなどをAzure Resource Graph Explorerで確認するクエリが紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
この更新は単発ニュースとして読むよりも、Azure Resource Graph / Azure Storageの中期的な運用方針を見直す材料として読むべきです。特にProduct owner、IT decision-maker、technical strategistにとって重要なのは、「危険な設定を探す」だけでなく、「継続的に説明できるクラウド資産管理へ移行する」ことです。
2026年4月21日の更新で何が示されたのか
Microsoftのガイダンスで注目すべき点は、Azure Storageの構成確認を「スクリプトで個別取得する作業」ではなく、「Azure Resource Graph Explorerで複数サブスクリプションを横断して確認する作業」として整理していることです。Azure Resource Graphは、サブスクリプション群に対して大規模なクエリを実行し、リソースのプロパティでフィルター、グループ化、並べ替えを行えるサービスです。(Microsoft Learn)
今回のガイダンスでは、Resourcesテーブルからmicrosoft.storage/storageaccountsを抽出し、ストレージアカウントの構成プロパティを確認する形が採られています。Microsoft.Storage/storageAccountsのリソース定義には、allowBlobPublicAccess、isHnsEnabled、isNfsV3Enabled、isSftpEnabled、minimumTlsVersion、networkAcls、publicNetworkAccessなどのプロパティが含まれています。(Microsoft Learn)
| 確認対象 | 何を見ているか | 運用上の意味 |
|---|---|---|
| SFTP有効化 | properties.isSftpEnabled | レガシーなファイル転送経路が有効か |
| 最小TLSバージョン | properties.minimumTlsVersion | 古いクライアント接続を許容していないか |
| 階層型名前空間 | properties.isHnsEnabled | Data Lake / SFTP / NFS系の設計判断に関係するか |
| 匿名BLOBアクセス | properties.allowBlobPublicAccess | コンテナー単位の匿名公開を許可し得る状態か |
| NFS 3.0 | properties.isNfsV3Enabled | Linux / HPC / 分析用途のファイルプロトコル利用があるか |
| 既定アクセス層 | properties.accessTier | コスト最適化やライフサイクル方針と整合しているか |
| ネットワーク制限 | publicNetworkAccessとnetworkAcls.defaultAction | どこからでも到達可能な候補になっていないか |
重要なのは、これらが単なるセキュリティチェック項目ではない点です。SFTPやNFS 3.0は業務要件を満たすために必要な場合があります。一方で、有効化されたまま用途が失われていると、監査、コスト、認証管理、ネットワーク設計の負債になります。
Azure Resource Graph / Azure Storageのロードマップをどう読むべきか
今回のMicrosoft記事は、公式ロードマップ表そのものではありません。しかし、Azure Resource Graph / Azure Storageの今後の運用を考えるうえで、少なくとも3つの方向性を読み取れます。
個別リソース管理からポートフォリオ管理へ移る
Azure Storageは、アプリケーション単位で作られることが多いサービスです。そのため、環境が大きくなると「重要なアカウントだけ知っている」「古いサブスクリプションに残ったストレージは見えていない」という状態になりがちです。
Azure Resource Graphは、各リソースプロバイダーを個別に呼び出さずに、リソースプロバイダーが返すプロパティへアクセスできます。また、過去14日間のリソース構成変更を表示できるとされています。これは、棚卸しだけでなく、変更管理や影響確認にも使えることを意味します。(Microsoft Learn)
今後の運用では、ストレージアカウントを「作成されたリソース」ではなく、「継続的にレビューされる製品ポートフォリオ」として扱うべきです。
スクリプト保守よりもKQL資産化が重視される
PowerShellやAzure CLIは修復作業には有効です。一方で、全社横断の定期レビューでは、モジュール更新、認証、ページング、例外処理、出力整形の保守が負担になります。
MicrosoftのガイダンスがAzure Resource Graph Explorerを前面に出しているのは、KQLクエリを共通資産として管理しやすいからです。Azure Resource Graph ExplorerはAzure portal内でクエリを実行でき、スコープをディレクトリ、管理グループ、サブスクリプションに切り替えられます。(Microsoft Learn)
実務では、次のように分担すると運用しやすくなります。
| 目的 | 向いている手段 | 補足 |
|---|---|---|
| 全体棚卸し | Azure Resource Graph | 横断検索、集計、可視化に向く |
| 例外の説明 | Power BI / ダッシュボード | 経営・プロダクト責任者向けに向く |
| 強制・予防 | Azure Policy | 作成時や更新時のガードレールに向く |
| 修復 | Azure CLI / PowerShell / IaC | 設定変更やテンプレート反映に向く |
| 実アクセス確認 | Azure Monitor / Log Analytics | 匿名アクセスや利用実態の確認に向く |
「公開されているか」ではなく「公開され得る構成か」を見る
ストレージアカウントの露出レビューでありがちな誤解は、「匿名アクセスが有効かどうか」だけを見ればよいという考え方です。実際には、ネットワーク到達性、BLOB匿名アクセス許可、コンテナーの公開設定、認証方式、SFTP / NFSなどのプロトコル、TLS設定を分けて見る必要があります。
たとえば、ストレージアカウントで匿名アクセスを許可していても、ユーザーがコンテナーの匿名アクセス設定を明示的に構成しない限り、BLOBデータは匿名読み取りに使えません。一方、ストレージアカウント側で匿名アクセスを禁止すると、そのアカウント内のコンテナー設定を上書きし、匿名要求は失敗します。(Microsoft Learn)
つまり、Azure Resource Graphで見るべきなのは「事故が起きた証拠」ではなく、「事故につながる構成余地」です。実際のアクセス有無は、Storageログやメトリックで確認します。
まず実行したいAzure Storage露出レビュー用KQL
最初に作るべきクエリは、細かい最適化よりも「誰が見ても危険候補を理解できる」ことを優先します。以下は、パブリックネットワークアクセスが有効または未設定で、ネットワークACLの既定アクションがAllowになっているストレージアカウントを抽出する例です。
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 isHnsEnabled = tostring(properties.isHnsEnabled)
| extend isNfsV3Enabled = tostring(properties.isNfsV3Enabled)
| where (publicNetworkAccess == "Enabled" or isempty(publicNetworkAccess))
and defaultAction == "Allow"
| project
subscriptionId,
resourceGroup,
name,
location,
publicNetworkAccess,
defaultAction,
allowBlobPublicAccess,
minimumTlsVersion,
isSftpEnabled,
isHnsEnabled,
isNfsV3Enabled
| order by subscriptionId asc, resourceGroup asc, name ascMicrosoftのガイダンスでも、publicNetworkAccessが有効またはnullで、networkAcls.defaultActionがAllowのストレージアカウントを、ファイアウォールやネットワーク制限のない候補として抽出する考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
このクエリ結果は、そのまま「危険確定リスト」として扱わないでください。まずは「レビュー対象リスト」として扱います。理由は、パブリックエンドポイントに到達できても、データアクセスには認証が必要な場合があるためです。Azure Storageのネットワークルールでは、明示的に許可されたソース以外のトラフィックを拒否できますが、許可されたソースからの要求でもストレージアカウントの認可要件を満たす必要があります。(Microsoft Learn)
設定別の判断基準と初期対応
Azure Storageの露出レビューでは、1つの設定だけで判断すると誤判定が増えます。プロダクト責任者やIT意思決定者に説明する場合は、次のように「技術設定」「業務上の意味」「初期対応」をセットで整理すると合意形成しやすくなります。
| 設定 | 優先度 | 判断基準 | 初期対応 |
|---|---|---|---|
publicNetworkAccess + networkAcls.defaultAction | 高 | どこからでも到達可能な候補か | 業務要件を確認し、原則は許可ネットワーク、Private Endpoint、サービスエンドポイントへ寄せる |
allowBlobPublicAccess | 高 | 匿名公開を許可し得る状態か | 不要ならFalse。公開が必要なコンテンツは専用アカウントに分離する |
minimumTlsVersion | 高 | TLS 1.2未満を許容していないか | 最低TLSを1.2へ。古いクライアントは移行計画を立てる |
isSftpEnabled | 中〜高 | SFTPが業務上必要か、利用者・鍵・ネットワークが管理されているか | 未使用なら無効化。利用中ならローカルユーザー、権限、接続元、課金を点検する |
isNfsV3Enabled | 中〜高 | NFS 3.0が対象ワークロードに適しているか | VNet前提、ポート、ワークロード適合性を確認する |
isHnsEnabled | 中 | Data Lake / SFTP / NFS設計と整合しているか | 目的のない有効化を避け、データ基盤設計と紐付ける |
accessTier | 中 | Hot / Coolなどの既定層が利用実態と合っているか | コストレビューやライフサイクル管理と合わせて判断する |
TLSについては、Azure StorageがTLS 1.2と1.3をサポートしている一方、ストレージアカウントの最小TLSバージョンとしてTLS 1.3を強制する機能はサポートされていません。Microsoftは推奨される最小TLSバージョンをTLS 1.2としています。(Microsoft Learn)
SFTPについては、Azure Blob StorageでSFTPクライアントによるファイルアクセス、転送、管理が可能です。ただし、SFTPサポートには階層型名前空間が必要で、ローカルユーザーによる認証・権限管理が関係します。また、SFTPの有効化には時間単位のコストがかかるため、使っていないのに有効なままにする設計は避けるべきです。(Microsoft Learn)
NFS 3.0については、高スループットで大規模な読み取り中心ワークロードに適していますが、トランザクションDBやインプレース編集のような用途には向かないとされています。また、NFS 3.0ではネットワークセキュリティ設計が特に重要で、トラフィックは仮想ネットワークなどから発生する必要があります。(Microsoft Learn)
Azure Resource Graphを運用に組み込む設計
Azure Resource Graphは「確認ツール」として使うだけでは効果が限定的です。ロードマップを見据えた運用では、クエリ、例外管理、修復、予防、レポートを一連のプロセスにします。
週次・月次・四半期で見る項目を分ける
すべての項目を毎日レビューすると、アラート疲れが起きます。逆に、年1回の棚卸しではクラウドの変更速度に追いつけません。次のようにレビュー頻度を分けると実務に乗せやすくなります。
| 頻度 | 対象 | 目的 |
|---|---|---|
| 週次 | パブリックネットワーク、匿名BLOBアクセス、TLS | 露出リスクの早期発見 |
| 月次 | SFTP、NFS 3.0、HNS、ローカルユーザー運用 | プロトコル利用と業務要件の整合確認 |
| 四半期 | 例外承認、所有者タグ、アクセス層、Policy適用状況 | 経営・監査・コスト観点での見直し |
| 変更時 | 新規プロダクト、買収環境、リージョン追加、データ基盤刷新 | 設計変更に伴うリスク再評価 |
Azure Resource Graphはユーザーレベルでスロットルされる無料サービスです。大規模かつ高頻度のAPI実行を前提にする場合は、クエリ頻度や取得件数、用途を設計する必要があります。(Microsoft Learn)
Azure PolicyとDefender for Cloudで予防線を張る
Azure Resource Graphは発見に強い一方、望ましくない構成を作らせない仕組みはAzure Policyで担うのが自然です。Azure Storageには、最小TLSバージョンを指定する組み込みポリシーがあり、効果としてAudit、Deny、Disabledを利用できます。(Microsoft Learn)
また、Microsoft Defender for Cloudのネットワーク推奨事項には、ストレージアカウントのファイアウォールと仮想ネットワーク構成によるアクセス制限を推奨する項目があります。(Microsoft Learn)
実務では、次の順で進めると失敗しにくくなります。
| 段階 | 実施内容 | 失敗しやすい点 |
|---|---|---|
| 発見 | Azure Resource Graphで対象を抽出 | クエリ結果を危険確定として扱ってしまう |
| 分類 | 業務要件、データ重要度、所有者で分類 | 例外理由が口頭のまま残る |
| 修復 | ネットワーク制限、TLS、匿名アクセス設定を変更 | 既存アプリの匿名アクセスや古いTLS依存を壊す |
| 予防 | Azure PolicyでAudit / Denyを設定 | いきなりDenyにして開発・運用を止める |
| 監視 | Defender for Cloud、Log Analytics、Power BIで継続確認 | ダッシュボードだけ作って責任者が決まらない |
Power BIとアラートは「経営判断」と「運用検知」に分ける
Azure Resource Graphの結果は、技術者だけが見る一覧で終わらせないことが重要です。Power BIコネクタを使うと、Azure Resource GraphクエリをPower BI DesktopやPower BIサービスで扱えます。既定ではテナントレベルでクエリを実行しますが、サブスクリプションや管理グループにスコープを変更できます。(Microsoft Learn)
一方、運用検知にはLog Analyticsとの連携が選択肢になります。Azure Resource GraphとLog Analyticsを使ったアラート作成は、Azure Resource GraphクエリやAzure Monitorログとの結合を使ってリソース状態のアラートを設定できる仕組みですが、ドキュメント上ではパブリックプレビューとして扱われています。(Microsoft Learn)
したがって、意思決定向けにはPower BI、運用検知向けにはAzure Monitor / Log Analytics、予防制御にはAzure Policyという役割分担が現実的です。
Product ownerとIT decision-makerが決めるべき運用方針
Azure Resource Graph / Azure Storageの運用は、セキュリティチームだけに任せると長続きしません。ストレージアカウントはアプリケーション、データ基盤、外部連携、バックアップ、ファイル転送などに使われるため、ビジネス側の判断が必要です。
例外を「許可」ではなく「期限付きの設計判断」にする
パブリックネットワークアクセス、SFTP、NFS、匿名BLOBアクセスは、必ずしも悪い設定ではありません。問題は、理由・期限・責任者がない状態で残り続けることです。
例外管理では、最低限次の情報を残します。
| 項目 | 記録例 |
|---|---|
| 例外理由 | 外部取引先とのSFTP連携に必要 |
| 対象データ | 請求書PDF、個人情報なし、保存期間90日 |
| 接続元 | 取引先固定IP、社内VNet |
| 代替案 | API連携へ移行予定 |
| 期限 | 2026年9月末に再評価 |
| 責任者 | プロダクトオーナー、セキュリティ承認者 |
この管理をしないと、レビューのたびに同じ設定が検出され、毎回ゼロから説明することになります。クラウド運用で最も無駄なのは、リスクそのものよりも「前回なぜ許可したのか分からない状態」です。
タグ設計を露出レビューに使える形へ変える
Azure Resource Graphのクエリ結果にtagsを追加すれば、所有者、プロダクト、環境、データ分類ごとの集計ができます。たとえば、Environment=ProdかつDataClassification=Confidentialのストレージアカウントで、ネットワーク既定アクションがAllowなら、優先度を上げて確認できます。
タグはコスト配賦だけのものではありません。Azure Storageの露出レビューでは、タグが「誰に修復を依頼するか」「どのプロダクトのリスクか」「例外を誰が承認するか」を決める実務データになります。
新規作成時の標準構成を決める
中期的な運用方針として、既存リソースの修復だけでなく、新規作成時の標準を決める必要があります。
標準構成の例は次のとおりです。
| 項目 | 標準方針 |
|---|---|
| パブリックネットワークアクセス | 原則無効または制限付き |
| 匿名BLOBアクセス | 原則禁止。公開用途は専用アカウントに分離 |
| 最小TLS | TLS 1.2 |
| SFTP | 申請制。利用者、認証方式、接続元、期限を必須化 |
| NFS 3.0 | 対象ワークロードを限定。VNet設計とセットで承認 |
| HNS | Data Lake / SFTP / NFS要件がある場合に設計判断として有効化 |
| 監査 | Azure Resource Graphクエリを定期実行し、例外一覧を更新 |
この標準をIaCテンプレート、Azure Policy、設計レビュー項目に反映すると、Azure Resource Graphで見つける対象は徐々に「過去の負債」と「承認済み例外」に絞られていきます。
露出レビューで失敗しやすいポイント
Azure Resource Graphの結果だけで実アクセスを判断する
Azure Resource Graphは構成を見るために非常に有効ですが、実際に匿名要求が成功しているか、どのコンテナーにアクセスされているかを直接証明するものではありません。匿名要求の検出には、Azure MonitorのメトリックやAzure Storageログを使い、AuthenticationType == "Anonymous"のようなログクエリで確認する方法が示されています。(Microsoft Learn)
構成レビューとアクセスログ分析を混同しないことが、誤検知と過小評価の両方を避けるポイントです。
RBACの範囲不足で「存在しない」と誤認する
Azure Resource Graphは、クエリするリソースに対する少なくとも読み取り権限が必要です。権限がないAzureオブジェクトやオブジェクトグループの結果は返されません。(Microsoft Learn)
グローバル組織では、地域法人、買収した環境、委任管理されたサブスクリプションが混在します。レビュー結果を経営報告に使う場合は、対象スコープと権限範囲を明記しないと、「全社レビュー済み」と言いながら一部環境が抜ける可能性があります。
プロパティの有無を絶対視する
Azure Resource Graphは各リソースプロバイダーの非プレビューAPIを使ってプロパティや値を収集しますが、期待するプロパティが利用できない場合があります。(Microsoft Learn)
そのため、重要な判定に使うクエリは、スキーマブラウザーやMicrosoft.Storage/storageAccountsのリソース定義で確認し、isempty()やisnull()を使って未設定・不明を別カテゴリとして扱うのが安全です。
いきなりDenyポリシーを適用する
Azure PolicyのDenyは強力ですが、既存アプリケーションの作成・更新を止める可能性があります。まずAuditで影響範囲を把握し、例外申請と標準テンプレートを整備してからDenyへ移行する方が現実的です。
特にTLSや匿名アクセス設定を変更する場合、古いクライアント、外部取引先、静的コンテンツ配信、古いSFTP連携が影響を受けることがあります。修復はセキュリティ施策ではなく、プロダクト変更として扱うべきです。
最初の30日でやるべきこと
Azure Resource Graph / Azure Storageの運用方針を見直すなら、最初から完璧なガバナンス基盤を作ろうとしないことが重要です。まずは30日で「見える化」「分類」「修復計画」「予防線」の最小セットを作ります。
| 期間 | 実施内容 | 成果物 |
|---|---|---|
| 1〜3日目 | Azure Resource Graphでストレージアカウントを棚卸し | サブスクリプション別のストレージ一覧 |
| 4〜7日目 | パブリックネットワーク、匿名BLOBアクセス、TLS、SFTP、NFSを分類 | 高優先度レビューリスト |
| 2週目 | プロダクトオーナーと例外理由を確認 | 例外台帳、修復候補リスト |
| 3週目 | 影響の少ない設定から修復。TLSや匿名アクセスは影響確認後に変更 | 修復済みリスト、残課題 |
| 4週目 | Azure Policy、Defender for Cloud、Power BIまたはダッシュボード連携を設計 | 継続運用ルール |
この30日計画で大切なのは、Azure Resource Graphクエリを一度実行して終わらせないことです。クエリを保存し、所有者を決め、例外を期限付きで管理し、次回レビュー時に差分を説明できる状態にします。
まとめ：Azure Storage運用は「棚卸しできる設計」へ移行する
Microsoftの2026年4月21日のガイダンスは、Azure Storageの構成確認をAzure Resource Graphで横断的に行う実務的な例として重要です。SFTP、HNS、NFS 3.0、TLS、匿名BLOBアクセス、ネットワーク制限といった項目は、単なるセキュリティ設定ではなく、プロダクト戦略、データ基盤、外部連携、監査対応に直結します。
次に取るべき行動は明確です。まずAzure Resource Graphで全ストレージアカウントを棚卸しし、パブリックネットワークアクセス、匿名BLOBアクセス、TLS、SFTP、NFSを優先的に分類します。そのうえで、Azure Policyで予防し、Defender for CloudやLog Analyticsで監視し、Power BIなどで意思決定者に説明できる形へ整理します。
Azure Resource Graph / Azure Storageの今後の運用は、「問題が起きたら探す」ではなく、「常に説明できる構成として維持する」方向へ進めるべきです。
コメント