MENU

Azure Resource GraphでAzure Storageの露出を確認する初動ガイド

Azure

Azure Resource Graph / Azure Storage の今回の更新で最初に押さえるべき点は、Storage Accountの公開状態やセキュリティ設定を、Azure Resource Graph ExplorerからKQLで横断的に棚卸しできることです。Azure Storage自体の仕様が大きく変わったというより、複数サブスクリプションに散らばるStorage Accountを、SFTP、HNS、NFS、TLS、匿名Blobアクセス、ネットワーク制限の観点で素早くレビューするための実務ガイダンスと捉えると分かりやすいです。Microsoftは2026年4月21日のTech Community投稿で、Azure Resource Graphを使ってStorage Account構成を確認するKQL例を示しています。(TECHCOMMUNITY.MICROSOFT.COM)

特にCloud governance teams、storage admins、security auditorsが最初に確認すべきなのは、「外部公開されているか」だけではありません。匿名Blobアクセスを許可しているか、パブリックネットワークが全許可になっていないか、SFTPやNFS 3.0が有効か、TLS最小バージョンが期待どおりかを、同じ棚卸しの中で確認する必要があります。

目次

今回の更新は「Storage Account露出レビューの標準クエリ集」として見る

Microsoftの投稿では、Azure Resource Graph Explorerを使い、microsoft.storage/storageaccounts のリソースを対象に、Storage Accountの構成プロパティをKQLで確認する方法が紹介されています。PowerShell、Azure CLI、REST APIでも確認はできますが、モジュール管理やスクリプト保守が必要になりやすいため、Azure Portal上のResource Graph Explorerで横断検索するアプローチが実務向きです。(TECHCOMMUNITY.MICROSOFT.COM)

実務上の意味は、次の3つです。

観点これまで起きやすかった課題今回のガイダンスでやりやすくなること
ガバナンスサブスクリプションごとにStorage Accountを個別確認していた複数サブスクリプションを横断して一覧化できる
セキュリティ監査「公開されているか」の判断材料が分散していたネットワーク、匿名アクセス、TLS、SFTP、NFSなどを同じKQLで確認できる
運用改善CLIやPowerShellのスクリプトが属人化しやすいAzure Portal上でクエリを共有し、CSV出力やダッシュボード化につなげやすい

重要なのは、この更新を「新機能が追加された」というより、「監査・棚卸しの初動を標準化しやすくなった」と理解することです。大規模なAzure環境では、Storage Accountの数が増えるほど、個別確認では見落としが発生します。Azure Resource Graphを使えば、まず全体像を把握し、リスクの高いアカウントから優先順位を付けられます。

最初に確認すべきStorage Accountの設定項目

Azure Storageの露出レビューでは、1つの設定だけを見ても十分ではありません。たとえば、allowBlobPublicAccess が無効でも、パブリックネットワークが広く開いていれば別のリスクがあります。逆に、パブリックネットワークが有効でも、ファイアウォールやVNet制限で絞られている場合があります。

まずは次の項目を確認してください。

確認項目ARGで見る主なプロパティ実務上の見方初動
パブリックネットワーク公開properties.publicNetworkAccess、properties.networkAcls.defaultActionすべてのネットワークから到達できる状態かを確認するEnabled かつ defaultAction == Allow を優先確認
匿名Blobアクセスproperties.allowBlobPublicAccessアカウントレベルで匿名アクセスを許可しているかを確認する業務上不要なら無効化を検討
最小TLSバージョンproperties.minimumTlsVersion古いTLSを許容する設定や未設定を洗い出すTLS 1.2を基準に例外を確認
SFTPproperties.isSftpEnabledSFTP経由のファイル転送が有効かを確認する利用部門、ローカルユーザー、接続元を確認
HNSproperties.isHnsEnabledData Lake Storage Gen2向けの階層型名前空間が有効かを確認する変更可否と連携サービスへの影響を確認
NFS 3.0properties.isNfsV3EnabledNFSマウント用途のアカウントかを確認する有効化の意図、ネットワーク制限、冗長性要件を確認
アクセス層properties.accessTierHot / Coolなどの既定アクセス層を確認するコスト最適化やデータ利用頻度の確認に使う

Microsoftの公式ガイダンスでも、SFTP、最小TLS、HNS、Blob匿名アクセス、NFS 3.0、既定アクセス層、ネットワーク制限なしのStorage Accountを確認するクエリが例示されています。(TECHCOMMUNITY.MICROSOFT.COM)

まず実行したいベースライン棚卸しKQL

最初は、リスク判定を急ぐよりも、Storage Accountの全体像を1枚の一覧にすることをおすすめします。監査対象のサブスクリプションや管理グループを選択したうえで、Azure Resource Graph Explorerに以下のKQLを貼り付けて実行します。

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)
| extend defaultAccessTier = tostring(properties.accessTier)
| project
    subscriptionId,
    resourceGroup,
    name,
    location,
    kind,
    skuName = tostring(sku.name),
    publicNetworkAccess,
    defaultAction,
    allowBlobPublicAccess,
    minimumTlsVersion,
    isSftpEnabled,
    isHnsEnabled,
    isNfsV3Enabled,
    defaultAccessTier,
    tags
| order by subscriptionId asc, resourceGroup asc, name asc

この一覧をCSVで出力し、subscriptionId、resourceGroup、name、tags をもとに、所有部門やシステム名と突き合わせます。Azure Resource Graph Explorerではクエリ結果をCSVとしてダウンロードできますが、ポータルからのCSV出力には結果件数の上限があるため、大規模環境では対象範囲を分けるか、CLIやAPIでの取得も検討します。(Microsoft Learn)

露出リスクが高いStorage Accountを抽出するKQL

次に、インターネット側から広く到達できる可能性があるStorage Accountを抽出します。Microsoftの投稿でも、publicNetworkAccess が有効または未設定で、networkAcls.defaultAction が Allow のStorage Accountを確認するクエリが示されています。(TECHCOMMUNITY.MICROSOFT.COM)

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
| order by subscriptionId asc, resourceGroup asc, name asc

この結果に出たStorage Accountは、すぐに「事故」と断定するのではなく、次の順で確認します。

確認順見る内容判断のポイント
1業務用途静的Webサイト、公開配布、外部連携など、公開が必要な理由があるか
2データ分類個人情報、機密情報、認証情報、ログ、バックアップが含まれていないか
3ネットワーク制限すべてのネットワーク許可ではなく、特定VNetやIPに絞れるか
4代替手段Private Endpoint、SASの期限短縮、Entra ID認証などに置き換えられるか
5例外管理公開が必要な場合、期限・責任者・レビュー日が記録されているか

Azure Storageのファイアウォール規則は、Storage Accountのパブリックエンドポイントに対するネットワークアクセスを制御するもので、既定では任意のネットワークからの接続を許可できます。必要に応じて、仮想ネットワークやIPアドレス範囲などで接続元を制限します。(Microsoft Learn)

匿名Blobアクセスは「アカウント」と「コンテナー」を分けて確認する

Storage Accountの露出レビューで誤解されやすいのが、匿名Blobアクセスです。allowBlobPublicAccess は、アカウントレベルで匿名アクセスを許可するかどうかの設定です。ただし、アカウントで許可されているだけではBlobデータが自動的に匿名公開されるわけではありません。実際に匿名読み取りが成立するには、コンテナー側でも匿名アクセスが設定されている必要があります。(Microsoft Learn)

監査の初動では、まずアカウントレベルで匿名アクセスを許可している候補を洗い出します。

Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend allowBlobPublicAccess = tostring(properties.allowBlobPublicAccess)
| where allowBlobPublicAccess != "false"
| project
    subscriptionId,
    resourceGroup,
    name,
    location,
    allowBlobPublicAccess
| order by subscriptionId asc, resourceGroup asc, name asc

このクエリは、「匿名公開が実際に発生しているStorage Account」ではなく、「匿名公開を許可し得る設定の候補」を洗い出すためのものです。Microsoft Learnでは、匿名アクセスを許可するにはアカウント設定とコンテナー設定の両方が関係し、Microsoftは最適なセキュリティのためにStorage Accountで匿名アクセスを禁止することを推奨しています。(Microsoft Learn)

実務では、次のように扱うと安全です。

状態解釈対応
allowBlobPublicAccess == falseアカウントレベルで匿名アクセスを禁止原則として望ましい状態
allowBlobPublicAccess == trueコンテナー側で匿名公開できる余地があるコンテナー設定と業務理由を確認
空または未設定環境や作成方法によって解釈に注意が必要安全側に倒し、明示的にfalseを検討

公開配布用途がある場合も、無期限の匿名公開に頼るのではなく、公開が必要なデータだけを分離し、責任者・公開理由・レビュー期限を記録しておくべきです。特にバックアップ、ログ、データエクスポート、AI学習用データなどが混在するStorage Accountでは、匿名アクセスの許可は避けるのが基本です。

最小TLSバージョンは「空欄」を見逃さない

TLS設定では、properties.minimumTlsVersion を確認します。Microsoft Learnでは、Azure PortalでStorage Accountを作成した場合は最小TLSバージョンが1.2に設定される一方、PowerShell、Azure CLI、ARMテンプレートで作成した場合は MinimumTlsVersion が既定で設定されず、明示的に構成されるまで値が返らない場合があると説明されています。(Microsoft Learn)

監査では、TLS 1.0 / 1.1だけでなく、空欄や未設定も確認対象に含めます。

Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend minimumTlsVersion = tostring(properties.minimumTlsVersion)
| where isempty(minimumTlsVersion)
    or minimumTlsVersion in ("TLS1_0", "TLS1_1")
| project
    subscriptionId,
    resourceGroup,
    name,
    location,
    minimumTlsVersion
| order by subscriptionId asc, resourceGroup asc, name asc

この結果に出たStorage Accountは、接続元アプリケーション、古いSDK、レガシー機器、外部連携先を確認したうえで、TLS 1.2への統一を検討します。単純に設定を変更すると、古いクライアントからのアクセスが失敗する可能性があるため、変更前にStorageログやアプリケーション側の接続方式を確認してください。

SFTP有効化アカウントは「使っているか」と「誰が接続できるか」を確認する

SFTPは、外部パートナーとのファイル受け渡しやレガシー連携で使われやすい機能です。Microsoftの投稿では、properties.isSftpEnabled == true のStorage Accountを抽出するKQLが示されています。(TECHCOMMUNITY.MICROSOFT.COM)

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

SFTPは、Azure Blob StorageのBlobエンドポイントにSFTPクライアントで接続するための機能です。利用には階層型名前空間が有効であることが前提で、Microsoft Learnでは、SFTPを使っていない場合は時間課金の観点から無効化を検討するよう説明されています。(Microsoft Learn)

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

確認項目見るべき内容
利用実態直近でSFTP接続が使われているか
接続元外部ベンダー、社内拠点、バッチサーバーなど、接続元が明確か
認証ローカルユーザー、SSHキー、パスワード運用が適切か
権限範囲必要なコンテナー・パスだけに権限が絞られているか
ネットワーク全ネットワーク許可ではなく、必要な接続元に制限できるか
コスト使っていないSFTPが有効化されたままになっていないか

SFTPを無効化する場合は、単に設定を切るのではなく、連携先の業務カレンダー、バッチ実行時間、代替の転送方式を確認してから変更します。特にグローバル運用では、別タイムゾーンの夜間バッチが使っているケースがあります。

HNSとNFS 3.0は「後から簡単に戻せない」前提で確認する

isHnsEnabled は、Azure Data Lake Storage Gen2で使われる階層型名前空間の有効化状態を示します。HNSは分析基盤やデータレイク用途では重要ですが、Storage Accountの性質に影響するため、通常のBlob用途と同じ感覚で扱うべきではありません。

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

Microsoft Learnでは、Storage Accountで階層型名前空間を有効化すると、フラット名前空間には戻せないと説明されています。バックアップや画像保存など、オブジェクトの構造を別システムで管理しているワークロードでは、HNSのメリットが小さい場合もあります。(Microsoft Learn)

NFS 3.0も同様に、確認には注意が必要です。

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

Microsoft Learnでは、NFS 3.0サポートは既存Storage Accountでは有効化できず、有効化後に無効化もできないと説明されています。さらに、一部の冗長性構成や機能には制約があります。(Microsoft Learn)

したがって、HNSやNFS 3.0が有効なStorage Accountを見つけた場合は、セキュリティだけでなく、設計判断として妥当かを確認します。監査担当者は「有効だから危険」と短絡的に判断せず、データレイク、HPC、Linuxマウント、分析基盤などの用途と整合しているかを見てください。

Cloud governance teamsが取るべき初動

Cloud governance teamsは、今回のガイダンスを単発の確認作業ではなく、継続的なガバナンスプロセスに組み込むべきです。

まず、全サブスクリプションを対象にベースラインクエリを実行し、Storage Account一覧を取得します。次に、組織の基準に合わせて、以下のような判定ルールを作ります。

判定条件例対応
Highすべてのネットワークから許可、かつ機密タグ付き早急に所有者確認、ネットワーク制限を検討
High匿名Blobアクセス許可、かつ用途不明コンテナー公開状態とデータ分類を確認
MediumTLS最小バージョンが空欄または古いアプリ影響確認後、TLS 1.2へ更新
MediumSFTP有効、所有者や利用実態が不明利用ログとローカルユーザー設定を確認
ReviewHNSまたはNFS 3.0有効設計意図、不可逆性、連携サービスを確認

このとき、タグ運用も同時に見直します。Owner、SystemName、DataClassification、Environment、ReviewDate などが不足していると、検出後の対応が遅れます。KQLで見つけるだけではなく、誰が判断し、いつまでに修正するかまで決めることが重要です。

Storage adminsが取るべき初動

Storage adminsは、検出結果をもとに、実際の設定変更や影響確認を担当します。特に注意すべきなのは、セキュリティ設定の変更がアプリケーション停止につながる可能性がある点です。

たとえば、次の変更は事前確認なしに実施しないでください。

変更起こり得る影響
defaultAction を Deny に変更App Service、Functions、VM、外部連携からStorageに接続できなくなる可能性
匿名Blobアクセスを無効化公開配布ページ、静的コンテンツ、外部ダウンロードが失敗する可能性
最小TLSをTLS 1.2に変更古いSDK、古いOS、レガシーアプリが接続できなくなる可能性
SFTPを無効化外部取引先や夜間バッチのファイル転送が停止する可能性
HNS / NFS関連の再設計データ移行やアプリ改修が必要になる可能性

設定変更の前には、最低限、Storage Accountの診断ログ、アプリケーション構成、Private Endpoint、VNet統合、SAS利用状況、ローカルユーザー設定を確認します。変更は本番環境からではなく、影響範囲が明確な開発・検証環境で手順を確認してから進めるのが安全です。

Security auditorsが確認すべき証跡

Security auditorsにとって重要なのは、KQLの結果そのものだけではありません。監査証跡として使うには、いつ、どの範囲を、どの権限で、どのクエリを使って確認したかを残す必要があります。

Azure Resource Graphは、クエリ実行者が読み取り権限を持つリソースを対象に結果を返します。適切なRead権限がないAzureオブジェクトやスコープについては結果が返らないため、監査では「結果が0件だった」ことと「対象全体を確認できた」ことを混同しないようにしてください。(Microsoft Learn)

監査証跡には、次の情報を残すと後から説明しやすくなります。

証跡内容
実行日例：2026-04-21、またはレビュー実施日
対象範囲テナント、管理グループ、サブスクリプション
実行者使用したアカウントまたは監査用ID
権限Reader以上の権限が対象範囲に付与されているか
クエリ実行したKQL全文
結果CSV、スクリーンショット、チケット番号
例外公開が必要なStorage Accountの業務理由、期限、承認者

この形式にしておくと、内部監査、外部監査、クラウドセキュリティレビュー、インシデント後の振り返りで再利用できます。

よくある失敗と回避策

Azure Storageの露出レビューでは、設定名だけを見て判断すると誤解が生まれます。次の失敗は特に起きやすいです。

失敗しやすいポイントなぜ問題か回避策
allowBlobPublicAccess=false だけで安全と判断する匿名Blobアクセスとネットワーク公開は別の観点ネットワークACL、Private Endpoint、認証方式も確認する
publicNetworkAccess=Enabled だけで危険と断定するファイアウォールで接続元が制限されている場合があるnetworkAcls.defaultAction と許可ルールを合わせて見る
TLSの空欄を問題なしとみなす作成方法によって未設定が返る場合がある空欄もレビュー対象に含める
SFTPを使っていないのに有効化したままにする不要な露出面やコストにつながる利用実態を確認し、不要なら無効化を検討
HNSやNFSを通常の一時設定のように扱う後戻りできない、または制約がある設定が含まれる設計意図とワークロード要件を確認する
ARG結果を完全な棚卸しと誤解する権限不足のリソースは結果に出ない監査用IDのスコープと権限を確認する

実務でのおすすめ運用フロー

今回のMicrosoftガイダンスを実務に落とし込むなら、次の流れが現実的です。

ステップ作業成果物
1Azure Resource Graph Explorerでベースライン棚卸しを実行Storage Account一覧CSV
2パブリックネットワーク、匿名Blobアクセス、TLS、SFTP、NFSを抽出リスク候補リスト
3タグとCMDB、システム台帳を突き合わせる所有者・用途の対応表
4Highリスクから所有者に確認する修正チケットまたは例外申請
5変更前にアプリ影響を確認する影響確認メモ、テスト結果
6設定修正またはAzure Policy / IaCで再発防止する修正済み構成、ポリシー、テンプレート
7定期的に同じKQLを再実行する月次・四半期レビュー記録

一度きりの棚卸しで終わらせず、Azure Policy、IaCテンプレート、タグルール、チケット運用とつなげることが大切です。特にグローバル環境では、地域ごとの管理者がStorage Accountを作成するため、中央チームが定期的に横断レビューできる仕組みを持つ必要があります。

まずやるべきこと

Azure Resource Graph / Azure Storageの利用者が今回のMicrosoftガイダンスを受けて最初に行うべきことは、既存Storage Accountの横断棚卸しです。新しい仕様変更に慌てて対応するというより、「現在どのStorage Accountが、どの程度外部に露出し得るのか」を可視化することが第一歩です。

優先順位は、次の順で進めると実務に落とし込みやすくなります。

優先度対応
最優先すべてのネットワークから許可されているStorage Accountを抽出する
高匿名Blobアクセスを許可し得るStorage Accountを確認する
高TLS最小バージョンが空欄または古い設定を確認する
中SFTP、NFS 3.0、HNSが有効なアカウントの用途を確認する
中結果を所有者、用途、例外期限と紐づける
継続同じKQLを定期実行し、Azure PolicyやIaCで再発を防ぐ

Storage Accountは、アプリケーション、ログ、バックアップ、データ分析、外部連携の入口になりやすいリソースです。Azure Resource Graphを使って全体像を把握し、公開範囲・匿名アクセス・プロトコル・TLSを同じ観点で確認できるようにしておけば、監査対応だけでなく、日常のクラウドガバナンスにもそのまま活用できます。

Azure
セキュリティ監査 Azure Storage Azure Resource Graph クラウドガバナンス

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次