Azure Storageの公開設定を棚卸しするなら、個別のストレージアカウントをポータルで開いたり、Azure CLIでサブスクリプションごとにループしたりするより、Azure Resource Graphで横断クエリする方法が最短です。2026年4月21日付でMicrosoft Tech Communityに掲載されたガイダンスでは、Azure Resource Graph ExplorerからKQLを実行し、SFTP、階層型名前空間、TLS、匿名BLOBアクセス、NFS 3.0、アクセス層、ネットワーク公開状態をまとめて確認する考え方が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
開発者、Platform Engineer、DevOpsチームにとって重要なのは、「どのストレージアカウントが危ないか」を一度だけ調べることではありません。リリース前チェック、移行前の影響調査、IaCのドリフト検出、監査証跡の出力を同じKQLで回せる点に価値があります。この記事では、Azure Resource Graph / Azure Storageの実装・移行・自動化で何が楽になるのかを、実務で使えるクエリと判断基準に落とし込んで解説します。
Azure Resource Graph / Azure Storageの今回の更新で何が楽になるのか
今回のMicrosoftのガイダンスは、新しいAzure Storage機能の発表というより、Azure Storage構成をAzure Resource Graphでレビューするための実務パターンです。Microsoftの記事では、Resourcesテーブルを使い、microsoft.storage/storageaccountsに絞り込んで、Storage Accountリソーススキーマ上の各プロパティを取得する流れが紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)
Azure Resource Graphは、複数サブスクリプションにまたがるAzureリソースをKQLで効率よく検索するサービスです。Azure Resource Managerの基本的な一覧取得では見にくいリソースプロバイダー由来の詳細プロパティも、リソースごとに個別GETを繰り返さずに参照できます。(Microsoft Learn)
実務で楽になるポイントは、主に次の4つです。
| 領域 | 従来つらかったこと | Azure Resource Graphで楽になること |
|---|---|---|
| 実装前レビュー | 開発チームごとにポータル確認やCLIスクリプトがばらつく | KQLを共通チェックリストとして保存できる |
| 移行判断 | SFTP、Data Lake Storage Gen2、NFS対象のアカウントを手作業で探す | isSftpEnabled、isHnsEnabled、isNfsV3Enabledで候補を抽出できる |
| 自動化 | サブスクリプション数が増えるとCLIループと例外処理が複雑になる | az graph queryやREST APIから同じKQLを実行できる |
| 監査・棚卸し | 監査前にCSVを手作業で作る | 定期実行してJSON/CSV化し、差分を追える |
特にPlatform Engineeringの観点では、Azure Resource Graphを「クラウド資産台帳のクエリ基盤」として扱えます。ポータルで一度確認して終わりではなく、KQLファイルをリポジトリに置き、CI/CDや定期ジョブで実行する設計にすると、Storage Accountの公開範囲レビューを継続運用に組み込めます。
最初に確認すべきAzure Storageのプロパティ
Storage Accountの公開範囲レビューでは、単に「publicかprivateか」だけを見ると判断を誤ります。匿名BLOBアクセス、ネットワーク制御、SFTP/NFSの有効化、TLS設定は別々の論点です。
| プロパティ | 何を見るか | 実務上の判断基準 |
|---|---|---|
properties.publicNetworkAccess | パブリックエンドポイントの利用可否 | Disabledなら原則Private Endpoint経由。Enabledまたは未設定の場合はnetworkAcls.defaultActionも確認 |
properties.networkAcls.defaultAction | 既定で全ネットワークを許可するか | Allowは広く開いている可能性がある。Denyなら許可済みネットワーク/IP/リソースを確認 |
properties.allowBlobPublicAccess | コンテナー単位の匿名公開を許可できるか | 原則falseを基準にする。trueでも即公開ではないが、コンテナー設定次第で匿名読み取りが可能 |
properties.minimumTlsVersion | 許可する最小TLSバージョン | 組織標準未満のアカウントを抽出し、クライアント互換性を確認してから変更 |
properties.isHnsEnabled | 階層型名前空間の有効化 | Data Lake Storage Gen2、SFTP、NFS関連の移行判断に使う |
properties.isSftpEnabled | SFTPの有効化 | 利用目的、ローカルユーザー、ネットワーク制御、コストを確認 |
properties.isNfsV3Enabled | NFS 3.0の有効化 | Linux/HPC/分析用途の有無、ネットワーク制限、不要な有効化を確認 |
properties.accessTier | 既定アクセス層 | セキュリティというよりコスト・性能・移行計画の判断材料 |
匿名BLOBアクセスは誤解しやすい項目です。Microsoft Learnでは、匿名読み取りアクセスはストレージアカウント側の設定とコンテナー側のアクセスレベルの2段階で決まり、ストレージアカウントで匿名アクセスを許可していても、コンテナー側で明示的に許可しなければ匿名読み取りは有効にならないと説明されています。(Microsoft Learn)
一方、ネットワーク公開状態はpublicNetworkAccessだけでは判断できません。Azure Storageのファイアウォール規則では、既定で任意のネットワークからの接続を許可できますが、ネットワークルールを構成することで接続元を制限できます。また、許可されたネットワークからのアクセスであっても、ストレージアカウントの認可要件は別途満たす必要があります。(Microsoft Learn)
まず使うべきStorage Account公開範囲レビュー用KQL
Microsoftのガイダンスでは、SFTP、最小TLS、HNS、匿名BLOBアクセス、NFS 3.0、既定アクセス層、全ネットワークに開いているStorage Accountを確認するクエリ例が示されています。実務では、それらを別々に見るだけでなく、1つの棚卸しクエリにまとめると使いやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend defaultAction = tostring(properties.networkAcls.defaultAction)
| extend allowBlobPublicAccess = tobool(properties.allowBlobPublicAccess)
| extend minimumTlsVersion = tostring(properties.minimumTlsVersion)
| extend isSftpEnabled = tobool(properties.isSftpEnabled)
| extend isHnsEnabled = tobool(properties.isHnsEnabled)
| extend isNfsV3Enabled = tobool(properties.isNfsV3Enabled)
| extend defaultAccessTier = tostring(properties.accessTier)
| extend skuName = tostring(sku.name)
| extend publicEndpointOpen =
(publicNetworkAccess == "Enabled" or isempty(publicNetworkAccess))
and defaultAction == "Allow"
| extend riskRank = case(
publicEndpointOpen and allowBlobPublicAccess == true, 1,
publicEndpointOpen, 2,
allowBlobPublicAccess == true, 3,
publicNetworkAccess == "Disabled", 5,
4
)
| extend finding = case(
riskRank == 1, "Public endpoint open + anonymous blob access can be enabled",
riskRank == 2, "Public endpoint open to all networks",
riskRank == 3, "Anonymous blob access can be enabled",
riskRank == 5, "Public endpoint disabled",
"Review network rules and feature flags"
)
| project
riskRank,
finding,
subscriptionId,
resourceGroup,
name,
location,
kind,
skuName,
publicNetworkAccess,
defaultAction,
allowBlobPublicAccess,
minimumTlsVersion,
isSftpEnabled,
isHnsEnabled,
isNfsV3Enabled,
defaultAccessTier,
id
| order by riskRank asc, id ascこのクエリは、セキュリティ担当だけでなく開発者にも読みやすいように、findingを付けています。riskRank == 1は優先度が高い候補ですが、「匿名BLOBが実際に公開されている」と断定してはいけません。allowBlobPublicAccess == trueは、コンテナー側で匿名公開を設定できる状態を示すため、実際の公開有無はコンテナー設定やアクセスログで追加確認します。
特定サブスクリプションだけを対象にする場合は、次のようにsubscriptionIdで絞ります。
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where subscriptionId =~ "<subscription-id>"
| project name, resourceGroup, location, propertiesAzure Resource Graph Explorerで実行する場合は、Azure Portalで「Resource Graph Explorer」を検索し、スコープをディレクトリ、管理グループ、サブスクリプションから選択してKQLを実行します。Microsoft Learnでは、Resource Graph Explorerでクエリ実行、結果確認、CSVダウンロード、チャート化、ダッシュボードへのピン留めができると説明されています。(Microsoft Learn)
CLIで定期実行する実装例
手元やCI/CDで実行する場合は、Azure CLIのResource Graph拡張を使います。Microsoft Learnでは、Azure CLI 2.22.0以降とResource Graph拡張を使ってaz graph queryを実行する手順が紹介されています。(Microsoft Learn)
az extension add --name resource-graph
az login
QUERY='
Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend defaultAction = tostring(properties.networkAcls.defaultAction)
| extend allowBlobPublicAccess = tobool(properties.allowBlobPublicAccess)
| extend minimumTlsVersion = tostring(properties.minimumTlsVersion)
| extend isSftpEnabled = tobool(properties.isSftpEnabled)
| extend isHnsEnabled = tobool(properties.isHnsEnabled)
| extend isNfsV3Enabled = tobool(properties.isNfsV3Enabled)
| extend publicEndpointOpen =
(publicNetworkAccess == "Enabled" or isempty(publicNetworkAccess))
and defaultAction == "Allow"
| project
id,
subscriptionId,
resourceGroup,
name,
location,
publicNetworkAccess,
defaultAction,
allowBlobPublicAccess,
minimumTlsVersion,
isSftpEnabled,
isHnsEnabled,
isNfsV3Enabled,
publicEndpointOpen
| order by id asc
'
az graph query \
--graph-query "$QUERY" \
--first 1000 \
--output json > storage-exposure.json1000件を超える可能性がある環境では、ページングを前提にします。Azure Resource Graphは既定で1クエリあたり最大1000件を返し、firstの最大値も1000です。大規模環境でskipやページングを使う場合は、結果が安定するようにidなど一意性のある列で並べるのが重要です。(Microsoft Learn)
QUERY='
Resources
| where type =~ "microsoft.storage/storageaccounts"
| project id, subscriptionId, resourceGroup, name, location,
publicNetworkAccess = tostring(properties.publicNetworkAccess),
defaultAction = tostring(properties.networkAcls.defaultAction),
allowBlobPublicAccess = tobool(properties.allowBlobPublicAccess)
| order by id asc
'
: > storage-exposure.jsonl
skip=0
page_size=1000
while true; do
result=$(az graph query \
--graph-query "$QUERY" \
--first "$page_size" \
--skip "$skip" \
--output json)
count=$(echo "$result" | jq '.data | length')
echo "$result" | jq -c '.data[]' >> storage-exposure.jsonl
if [ "$count" -lt "$page_size" ]; then
break
fi
skip=$((skip + page_size))
doneこのJSONLをGitHub Actions、Azure DevOps、Jenkinsなどの定期ジョブで保存すれば、日次のStorage Account公開範囲レビューにできます。おすすめは、単にレポートを作るだけでなく、次のような判定を自動化することです。
| 判定 | 自動化の例 |
|---|---|
新規にpublicEndpointOpen == trueが出た | Slack、Teams、Issue、Azure Boardsに通知 |
allowBlobPublicAccess == trueが本番環境にある | 例外申請がない場合はリリースゲートで止める |
minimumTlsVersionが組織標準未満 | 対象アプリのオーナーに互換性確認タスクを作る |
isSftpEnabled == trueなのにオーナータグがない | 台帳不備としてPlatformチームに戻す |
isHnsEnabled == falseでData Lake移行予定タグがある | HNS移行計画のレビュー対象に入れる |
移行判断で見るべきポイント
Azure Storageの設定は、見つけた瞬間に一律変更すればよいものではありません。特にpublicNetworkAccess、allowBlobPublicAccess、isHnsEnabled、isSftpEnabledは、アプリケーション接続やデータ処理方式に影響します。
パブリックエンドポイントを閉じる前に接続元を洗い出す
publicNetworkAccess == EnabledかつnetworkAcls.defaultAction == Allowは、公開範囲レビューで最初に確認すべき候補です。ただし、すぐにDisabledへ変更すると、アプリ、Functions、AKS、オンプレミス連携、バックアップ、監視ジョブなどが接続できなくなる可能性があります。
Microsoft Learnでは、特定の仮想ネットワークやIPアドレスだけを許可するには既定アクションをDenyにする必要があり、変更前に許可ネットワークやPrivate Endpointを準備するよう注意されています。(Microsoft Learn)
実務では次の順で進めます。
| 手順 | やること |
|---|---|
| 現状把握 | Azure Resource Graphで公開状態、タグ、サブスクリプション、リソースグループを抽出 |
| 接続元確認 | アプリ構成、診断ログ、ネットワーク設計、Private Endpoint有無を確認 |
| 代替経路設計 | Private Endpoint、Service Endpoint、IP許可、信頼されたサービス例外を検討 |
| 検証 | ステージングでdefaultAction=DenyまたはpublicNetworkAccess=Disabledを試す |
| 本番反映 | 変更日時、ロールバック手順、影響範囲を決めて適用 |
修正コマンドの例は次のとおりです。実行前に、必ず対象アプリの接続経路を確認してください。
# 選択したネットワーク/IPのみ許可する前提に変更
az storage account update \
--resource-group "<resource-group>" \
--name "<storage-account>" \
--default-action Deny
# パブリックネットワークアクセス自体を無効化
az storage account update \
--resource-group "<resource-group>" \
--name "<storage-account>" \
--public-network-access Disabled匿名BLOBアクセスは「許可できる状態」と「実際に公開」を分ける
allowBlobPublicAccess == trueは、コンテナーを匿名公開できる状態を意味します。これはリスク候補ですが、即座に「データが公開されている」とは言えません。Microsoft Learnでも、ストレージアカウントで匿名アクセスを許可していても、コンテナー側で明示的に匿名アクセスを構成しなければBLOBデータは匿名で読めないと説明されています。(Microsoft Learn)
とはいえ、最適なセキュリティのためには、不要な匿名アクセスをストレージアカウント単位で無効化することが推奨されています。ストレージアカウントで匿名アクセスを禁止すると、個別コンテナーの公開設定より優先され、匿名リクエストは拒否されます。(Microsoft Learn)
az storage account update \
--resource-group "<resource-group>" \
--name "<storage-account>" \
--allow-blob-public-access false注意点は、静的Webサイト、公開配布用アセット、外部パートナー向けの一時的な公開など、意図的に匿名読み取りを使っているケースです。該当する場合は、Azure CDN、Front Door、SAS、Entra ID認証、アプリ経由配信への置き換えを検討します。
HNS移行は一方通行なので、KQLで対象を絞ってから検証する
isHnsEnabledは、Azure Data Lake Storage Gen2やSFTP/NFS関連の設計で重要です。Microsoft Learnでは、既存のStorage Accountに階層型名前空間を有効化するアップグレードは一方向で、アップグレード後に元へ戻す方法はないため、非本番環境で検証することが推奨されています。(Microsoft Learn)
HNS移行で失敗しやすいのは、次のようなケースです。
| 失敗しやすいポイント | 対策 |
|---|---|
| 既存アプリがBlob API前提で細かい挙動に依存している | 主要処理をテストし、必要ならData Lake Storage APIへ移行 |
| 書き込み中にアップグレードする | 変更時間を決め、書き込みを停止してから実行 |
| 非対応機能が有効 | 事前検証でエラーを確認し、必要な機能を一時的に無効化 |
| WASBドライバーを使うHadoop系ワークロードがある | ABFSドライバーへの移行を検討 |
| コスト・性能影響を見ていない | 本番相当データで読み書き性能と料金を確認 |
KQLでは、HNSが無効なアカウントのうち、Data Lake移行対象タグが付いているものだけを抽出するようにすると、移行計画を作りやすくなります。
Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend isHnsEnabled = tobool(properties.isHnsEnabled)
| where isHnsEnabled != true
| where tostring(tags["workload"]) has_any ("datalake", "analytics", "bigdata")
| project subscriptionId, resourceGroup, name, location, tags, id
| order by id ascSFTP有効化済みアカウントは「使っているか」を確認する
Azure Blob StorageのSFTPサポートは、Blob StorageエンドポイントにSFTPクライアントで接続できる機能です。Microsoft Learnでは、SFTPを有効にする前提として、標準の汎用v2またはPremiumブロックBLOBストレージアカウントであること、階層型名前空間が有効であることが示されています。(Microsoft Learn)
SFTPは、外部取引先とのファイル連携やレガシー連携の移行先として便利です。ただし、不要に有効化したままにすると、運用対象、ローカルユーザー、認証情報、ネットワーク制御、コスト管理が増えます。Microsoft Learnでも、SFTPサポートには時間単位のコストが発生するため、クライアントが利用していない場合は無効化を検討するよう案内されています。(Microsoft Learn)
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.isSftpEnabled == true
| project subscriptionId, resourceGroup, name, location,
isHnsEnabled = properties.isHnsEnabled,
publicNetworkAccess = properties.publicNetworkAccess,
defaultAction = properties.networkAcls.defaultAction,
id
| order by id ascこの結果に対して、次を確認します。
| 確認項目 | 見る理由 |
|---|---|
| 実際の利用者・連携先 | 使われていないSFTPを止められる可能性がある |
| ローカルユーザーと権限 | 過剰な書き込み権限や不要ユーザーを減らす |
| 接続元ネットワーク | SFTPを有効にしても、全ネットワーク公開が必要とは限らない |
| HNSの移行履歴 | 既存Blobワークロードへの影響を追跡する |
| 料金 | 不要な有効化を継続しない |
IaCに落とし込むとドリフト検出がしやすい
Azure Resource Graphのレビュー結果は、最終的にBicep、ARMテンプレート、Terraform、Azure Policyなどの「望ましい状態」に戻すと運用が安定します。Microsoft.Storage/storageAccountsのリソーススキーマには、allowBlobPublicAccess、minimumTlsVersion、isHnsEnabled、isNfsV3Enabled、isSftpEnabled、networkAcls、publicNetworkAccessなどのプロパティが含まれます。(Microsoft Learn)
Bicepで安全寄りの初期値を明示する例です。実際の値は、アプリケーション要件とネットワーク設計に合わせて調整してください。
param storageAccountName string
param location string = resourceGroup().location
resource storageAccount 'Microsoft.Storage/storageAccounts@2025-08-01' = {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Standard_LRS'
}
properties: {
allowBlobPublicAccess: false
minimumTlsVersion: 'TLS1_2'
supportsHttpsTrafficOnly: true
// Private Endpointを前提にする場合の例
publicNetworkAccess: 'Disabled'
networkAcls: {
defaultAction: 'Deny'
bypass: 'AzureServices'
}
// Data Lake Storage Gen2やSFTP/NFSが必要な場合だけtrueにする
isHnsEnabled: false
isSftpEnabled: false
isNfsV3Enabled: false
accessTier: 'Hot'
}
}このようにIaCへ落とし込むと、Azure Resource Graphは「現状」、BicepやTerraformは「あるべき状態」として使えます。夜間ジョブでKQLを実行し、あるべき状態と違うStorage Accountだけを検出すれば、手作業のレビューよりも早くドリフトを見つけられます。
自動修復は段階的に設計する
公開範囲レビューを自動化すると、すぐに「検出したら自動で閉じる」仕組みにしたくなります。しかし、Storage Accountはアプリケーションのデータ入出力に直結するため、強制変更は慎重に行うべきです。
おすすめは、次の3段階です。
| フェーズ | 自動化内容 | 目的 |
|---|---|---|
| 検出 | KQLで対象を抽出し、JSON/CSVとして保存 | 可視化と証跡化 |
| 通知 | 重要度に応じてIssueやチャット通知を作成 | オーナーに対応を促す |
| 修正 | 例外がない設定だけCLI/IaCで変更 | 事故を避けながら標準化 |
たとえば、開発環境の新規Storage AccountでallowBlobPublicAccess == trueが検出された場合は、自動でfalseへ戻しても影響が小さいかもしれません。一方、本番のpublicNetworkAccessをDisabledへ変更する処理は、Private Endpoint、DNS、アプリの接続元、監視・バックアップ連携まで確認してから適用するべきです。
自動修復の判断を安定させるには、例外タグを設計します。
securityException = "storage-public-network"
securityExceptionOwner = "team-data-platform"
securityExceptionExpiresOn = "2026-06-30"KQL側で期限切れ例外だけを検出できます。
Resources
| where type =~ "microsoft.storage/storageaccounts"
| extend publicNetworkAccess = tostring(properties.publicNetworkAccess)
| extend defaultAction = tostring(properties.networkAcls.defaultAction)
| extend publicEndpointOpen =
(publicNetworkAccess == "Enabled" or isempty(publicNetworkAccess))
and defaultAction == "Allow"
| extend exceptionName = tostring(tags["securityException"])
| extend exceptionExpiresOn = todatetime(tags["securityExceptionExpiresOn"])
| where publicEndpointOpen
| where isempty(exceptionName) or exceptionExpiresOn < now()
| project subscriptionId, resourceGroup, name, publicNetworkAccess, defaultAction,
exceptionName, exceptionExpiresOn, id
| order by id ascこの設計にすると、「例外は認めるが、期限と責任者がない例外は認めない」という運用にできます。
Azure Resource Graphを使うときの注意点
Azure Resource Graphは非常に便利ですが、Storage Account公開範囲レビューで使う場合は限界も理解しておく必要があります。
見えているのは管理プレーンの構成
Azure Resource Graphで見ているのは、主にAzure Resource Manager上のリソース構成です。たとえばallowBlobPublicAccess == trueは「匿名公開を許可できる状態」であり、「どのコンテナーが匿名公開され、どのBLOBが読まれたか」までは分かりません。
実際のアクセス有無を確認するには、Storageログ、Azure Monitor、Defender for Cloud、アプリケーションログなどのデータプレーン側の情報と組み合わせます。
権限がないリソースは結果に出ない
Azure Resource Graphを使うには、照会対象リソースに対する適切なAzure RBACの読み取り権限が必要です。Microsoft Learnでは、少なくとも対象Azureオブジェクトへのread権限がなければ結果が返らないと説明されています。(Microsoft Learn)
監査用の自動実行では、サービスプリンシパルやマネージドIDに対して、管理グループまたはサブスクリプション単位でReader相当の権限を付与する設計が現実的です。ただし、最小権限の原則に従い、修復用の書き込み権限は別IDに分ける方が安全です。
大規模環境ではページングとスロットリングを考える
Azure Resource Graphは大規模環境向けですが、無制限に連続実行できるわけではありません。Microsoft Learnでは、クエリ結果の既定上限、ページング、スロットリングヘッダー、クエリの分散実行について説明されています。(Microsoft Learn)
失敗しやすいパターンは次のとおりです。
| 失敗パターン | 対策 |
|---|---|
limitを使っているためページングできない | 大量取得ではlimitやtakeを避け、first/skipやskipTokenを使う |
| 並び順が不安定で重複・欠落が出る | order by id ascなど一意な列で並べる |
| 複数ジョブが同時に大量クエリを投げる | 実行時間をずらし、スロットリングヘッダーを見て待機する |
| 動的プロパティをそのままCSV化する | tostring()、tobool()で型を整える |
| 権限不足を「対象なし」と誤解する | 実行IDのRBACスコープを確認する |
Developers / Platform Engineers / DevOps teams別の活用シーン
同じKQLでも、チームによって使い方は変わります。
| 読者 | 使いどころ | 具体例 |
|---|---|---|
| Developers | 実装前後のセルフチェック | 新規Storage Account作成後に、匿名アクセスやTLS設定が標準どおりか確認 |
| Platform Engineers | 共通基盤のガードレール | 管理グループ横断で公開設定を監視し、例外タグを運用 |
| DevOps teams | CI/CDと監査証跡 | リリース前にKQLを実行し、危険な設定がある場合は承認フローへ回す |
| Security teams | 継続的な露出レビュー | 日次で公開候補を抽出し、期限切れ例外を棚卸し |
| Data platform teams | HNS/SFTP/NFS移行計画 | Data Lake移行対象、SFTP利用中、NFS有効化済みアカウントを分類 |
開発者向けには、難しい監査用語よりも「このStorage Accountはどのネットワークから到達できるのか」「匿名公開を許可できるのか」「SFTPやHNSが有効なのか」をコードで見えるようにすることが重要です。KQLをリポジトリに置き、ops/queries/storage-exposure.kqlのように管理すれば、レビュー観点がチーム間で揃います。
すぐに始める実務チェックリスト
Azure Resource Graph / Azure Storageの公開範囲レビューを始めるなら、次の順番で進めると失敗しにくくなります。
| 順番 | 作業 | 完了条件 |
|---|---|---|
| 1 | Azure Resource Graph Explorerで棚卸しKQLを実行 | 対象Storage Accountが一覧化されている |
| 2 | publicEndpointOpenとallowBlobPublicAccessを優先確認 | 高リスク候補にオーナーが付いている |
| 3 | HNS/SFTP/NFSの有効化状態を確認 | 移行・外部連携・分析基盤の対象が分類されている |
| 4 | CLIまたはCI/CDでKQLを定期実行 | JSON/CSVの証跡が残る |
| 5 | 例外タグと期限を決める | 期限切れ例外が自動検出される |
| 6 | IaCへ望ましい状態を反映 | 新規作成時の安全な既定値が明示されている |
| 7 | 自動修復は低リスク設定から始める | 本番通信断を起こさず標準化できる |
Azure Resource Graphの強みは、Azure Storageの設定を「人が探す」作業から「KQLで継続確認する」作業へ変えられる点です。まずはMicrosoftのガイダンスで示された7種類の観点をベースに、自社の基準に合わせた棚卸しクエリを1本作り、定期実行と例外管理までつなげてください。これだけで、実装レビュー、移行判断、監査対応、自動化の手戻りを大きく減らせます。
コメント