BLOB データへの匿名読み取りアクセスを修復する (Azure Resource Manager デプロイ環境)
Azure Blob Storage では、コンテナーと BLOB へのオプションの匿名読み取りアクセスがサポートされています。 ただし、匿名アクセスはセキュリティ リスクをもたらす可能性があります。 最適なセキュリティのためには、匿名アクセスを無効にすることをお勧めします。 匿名アクセスを禁止することで、望ましくない匿名アクセスによって発生するデータ侵害を防ぐことができます。
既定では、BLOB データへの匿名アクセスは常に禁止されています。 Azure Resource Manager ストレージ アカウントの既定の構成では、ストレージ アカウントのコンテナーおよび BLOB へ匿名アクセスを構成することができません。 この規定の構成では、個々のコンテナーでのアクセス設定に関係なく、Azure Resource Manager ストレージ アカウントへのすべての匿名アクセスが禁止されています。
ストレージ アカウントの匿名アクセスが許可されていない場合、Azure Storage は BLOB データに対する匿名読み取り要求をすべて拒否します。 ユーザーは、そのアカウント内のコンテナーに対する匿名アクセスを後で構成することはできません。 匿名アクセス用に既に構成されているコンテナーは、匿名要求を受け付けなくなります。
警告
匿名アクセス用にコンテナーを構成すると、任意のクライアントがそのコンテナー内のデータを読み取ることができます。 匿名アクセスは潜在的なセキュリティ リスクをもたらすため、Microsoft では、シナリオで必要な場合を除き、ストレージ アカウントに対してこれを禁止するようお勧めします。
Azure Resource Manager と従来のストレージ アカウントの修復
この記事では、DRAG (Detection-Remediation-Audit-Governance) フレームワークを使って、Azure Resource Manager デプロイ モデルを使っているストレージ アカウントの匿名アクセスを継続的に管理する方法について説明します。 すべての汎用 v2 ストレージ アカウント、Premium ブロック BLOB ストレージ アカウント、Premium ファイル共有アカウント、BLOB ストレージ アカウントは、Azure Resource Manager デプロイ モデルを使います。 一部の古い汎用 v1 アカウントと Premium ページ BLOB アカウントでは、従来のデプロイ モデルを使っている場合があります。
ストレージ アカウントでクラシック デプロイ モデルを使用している場合は、できるだけ早く Azure Resource Manager デプロイ モデルに移行することをお勧めします。 クラシック デプロイ モデルを使用している Azure Storage アカウントは、2024 年 8 月 31 日に廃止される予定です。 詳細については、「Azure クラシック ストレージ アカウントは 2024 年 8 月 31 日に廃止される」を参照してください。
現時点で従来のストレージ アカウントを移行できない場合は、それらのアカウントへの匿名アクセスを今すぐ修復する必要があります。 従来のストレージ アカウントの匿名アクセスを修復する方法の詳細については、「BLOB データへの匿名読み取りアクセスの修復 (クラシック デプロイ)」を参照してください。 Azure デプロイ モデルの詳細については、「Resource Manager デプロイとクラシック デプロイ」を参照してください。
匿名読み取りアクセスについて
データへの匿名アクセスは既定で常に禁止されています。 匿名アクセスに影響を与える 2 つの個別の設定があります。
ストレージ アカウントの匿名アクセスの設定。 Azure Resource Manager ストレージ アカウントは、アカウントの匿名アクセスを許可または禁止する設定を提供します。 最適なセキュリティを確保するために、Microsoft はストレージ アカウントに対する匿名アクセスを禁止することをお勧めします。
アカウント レベルで匿名アクセスを許可すると、ユーザーがコンテナーの匿名アクセス設定を明示的に構成する追加の手順を実行しない限り、BLOB データは匿名読み取りアクセス用に使用できません。
コンテナーの匿名アクセスの設定。 既定では、コンテナーの匿名アクセス設定は無効になっています。つまり、コンテナーやそのデータへのすべての要求には承認が必要となります。 ストレージ アカウントの匿名アクセスを許可している場合のみ、適切なアクセス許可を持つユーザーはコンテナーの匿名アクセス設定を変更して、匿名アクセスを有効化できます。
次の表に、この 2 つの設定がコンテナーの匿名アクセスにどのように影響するのかまとめます。
コンテナーの匿名アクセス レベルがプライベートに設定されている (既定の設定) | コンテナーの匿名アクセス レベルがコンテナーに設定されている | コンテナーの匿名アクセス レベルが BLOB に設定されている | |
---|---|---|---|
ストレージ アカウントの匿名アクセスが禁止されている | ストレージ アカウントのどのコンテナーにも匿名アクセスできない。 | ストレージ アカウントのどのコンテナーにも匿名アクセスできない。 ストレージ アカウントの設定は、コンテナーの設定をオーバーライドする。 | ストレージ アカウントのどのコンテナーにも匿名アクセスできない。 ストレージ アカウントの設定は、コンテナーの設定をオーバーライドする。 |
ストレージ アカウントの匿名アクセスが許可されている | このコンテナーへの匿名アクセスはできない (既定の構成)。 | このコンテナーとその BLOB への匿名アクセスが許可される。 | このコンテナーの BLOB への匿名アクセスは許可されるが、コンテナーそのものに対しては許可されない。 |
匿名アクセスがストレージ アカウントで許可され、特定のコンテナーに対して構成されると、Authorization
ヘッダー "なし" で渡されたそのコンテナー内の BLOB を読み取る要求はサービスによって受け入れられ、その BLOB のデータが応答で返されます。 しかし、要求が Authorization
ヘッダー "有り" で渡された場合、ストレージ アカウント上の匿名アクセスは無視され、要求は指定された資格情報に基づいて承認されます。
クライアント アプリケーションからの匿名要求の検出
ストレージ アカウントで匿名読み取りアクセスを禁止すると、現在匿名アクセスが構成されているコンテナーと BLOB への要求が拒否されるリスクがあります。 ストレージ アカウントで匿名アクセスを禁止すると、そのストレージ アカウント内の個々のコンテナーのアクセス設定がオーバーライドされます。 ストレージ アカウントで匿名アクセスを禁止すると、以後、そのアカウントに対する匿名要求は失敗します。
匿名アクセスを禁止するとクライアント アプリケーションにどのような影響があるかを理解するために、そのアカウントでログ記録とメトリックを有効にし、一定の期間内の匿名要求のパターンを分析することをお勧めします。 ストレージ アカウントに対する匿名要求の数をメトリックを使って調べ、匿名でアクセスされているコンテナーをログから特定します。
メトリックス エクスプローラーを使用した匿名要求の監視
ストレージ アカウントに対する匿名要求を追跡するには、Azure portal で Azure メトリックス エクスプローラーを使用します。 メトリックス エクスプローラーの詳細については、「Azure Monitor メトリックス エクスプローラーでメトリックを分析する」を参照してください。
匿名要求を追跡するメトリックを作成するには、次の手順に従います。
Azure Portal のストレージ アカウントに移動します。 [監視] セクションで、 [メトリック] を選択します。
[メトリックの追加] を選択します。 [メトリック] ダイアログで、次の値を指定します。
- [スコープ] フィールドは、ストレージ アカウントの名前に設定したままにします。
- [Metric Namespace](メトリックの名前空間) を [Blob](BLOB) に設定します。 このメトリックでは、BLOB ストレージに対する要求のみが報告されます。
- [メトリック] フィールドを [トランザクション] に設定します。
- [集計] フィールドを [合計] に設定します。
新しいメトリックには、指定された期間中の BLOB ストレージに対するトランザクション数の合計が表示されます。 結果のメトリックは、次の図のように表示されます。
次に、 [フィルターの追加] ボタンをクリックして、匿名要求のメトリックにフィルターを作成します。
[フィルター] ダイアログで、次の値を指定します。
- [プロパティ] の値を [認証] に設定します。
- [演算子] フィールドを等号 (=) に設定します。
- [値] フィールドを [匿名] に設定します。そのためには、ドロップダウンから選択するか、入力します。
右上隅で、メトリックを表示する期間を選択します。 1 分から 1 か月の範囲で間隔を指定して、要求の集計のきめ細かさを指示することもできます。
メトリックを構成すると、匿名要求がグラフに表示されるようになります。 次の図は、過去 30 分間に集計された匿名要求を示しています。
ストレージ アカウントに対して一定数の匿名要求が行われたら通知する警告ルールも構成できます。 詳細については、「Azure Monitor を使用してメトリック アラートを作成、表示、管理する」を参照してください。
ログを分析して匿名要求を受信しているコンテナーを識別する
Azure Storage のログには、要求の承認方法など、ストレージ アカウントに対して行われた要求の詳細が記録されます。 ログを分析して、どのコンテナーが匿名要求を受信しているかを特定できます。
Azure Monitor の Azure Storage ログ記録を使用すると、Azure Storage アカウントに対する要求をログに記録して、匿名要求を評価することができます。 詳細については、「Azure Storage を監視する」を参照してください。
Azure Monitor の Azure Storage ログ記録では、ログ クエリを使用したログ データの分析がサポートされています。 ログに対してクエリを実行するために、Azure Log Analytics ワークスペースを使用できます。 ログ クエリの詳細については、「チュートリアル: Log Analytics クエリの使用方法」を参照してください。
Azure portal での診断設定の作成
Azure Monitor で Azure Storage のデータをログに記録し、Azure Log Analytics で分析するには、まず、データをログに記録する要求の種類とストレージ サービスを指示する診断設定を作成する必要があります。 Azure portal で診断設定を作成するには、これらの手順に従います。
自分の Azure Storage アカウントが含まれるサブスクリプションに、新しいログ分析ワークスペースを作成します。 ストレージ アカウントのログ記録を構成した後、Log Analytics ワークスペースでログを使用できるようになります。 詳細については、「Azure ポータルで Log Analytics ワークスペースを作成する」を参照してください。
Azure Portal のストレージ アカウントに移動します。
[監視] セクションで、[診断設定] を選択します。
BLOB ストレージに対して行われた要求をログに記録するには、 [Blob](BLOB) を選択します。
[診断設定の追加] を選択します。
診断設定の名前を指定します。
[カテゴリの詳細] の [ログ] セクションで、ログを記録する要求の種類を選択します。 すべての匿名要求は読み取り要求であるため、匿名要求をキャプチャするには StorageRead を選択します。
[宛先の詳細] で、 [Log Analytics への送信] を選択します。 以下の図に示すように、ご利用のサブスクリプションと、先ほど作成した Log Analytics ワークスペースを選択します。
診断設定を作成した後、ストレージ アカウントに対する要求が、その設定に従ってログに記録されるようになります。 詳細については、Azure でリソース ログとメトリックを収集するための診断設定の作成に関するページを参照してください。
Azure Monitor の Azure Storage ログで使用できるフィールドのリファレンスについては、「リソース ログ」を参照してください。
匿名要求のログのクエリ
Azure Monitor の Azure Storage ログには、ストレージ アカウントに要求を行うために使用された承認の種類が記録されます。 匿名要求を表示するには、ログ クエリで AuthenticationType プロパティをフィルターにします。
BLOB ストレージに対する匿名要求の過去 7 日間のログを取得するには、Log Analytics ワークスペースを開きます。 次に、以下のクエリを新しいログ クエリに貼り付けて実行します。
StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri
このクエリに基づいて警告ルールを構成し、匿名要求の通知を受けることもできます。 詳細については、「Azure Monitor を使用してログ アラートを作成、表示、管理する」を参照してください。
匿名要求への応答
Blob Storage で匿名要求を受信したときにその要求が成功するのは、以下のすべての条件が満たされる場合です。
- ストレージ アカウントの匿名アクセスが許可されている。
- 匿名アクセスを許可するように対象コンテナーが構成されている。
- 要求は読み取りアクセス用である。
これらの条件のいずれかが満たされない場合、要求は失敗します。 失敗時の応答コードは、ベアラー チャレンジをサポートするバージョンのサービスを使用して匿名要求が行われたかどうかによって異なります。 ベアラー チャレンジは、サービス バージョン 2019-12-12 以降でサポートされています。
- ベアラー チャレンジをサポートするサービス バージョンで匿名要求が行われた場合は、サービスからエラー コード 401 (未承認) が返されます。
- ベアラー チャレンジをサポートしていないサービス バージョンで匿名要求が行われ、ストレージ アカウントで匿名アクセスが許可されていない場合は、サービスからエラー コード 409 (競合) が返されます。
- ベアラー チャレンジをサポートしていないサービス バージョンで匿名要求が行われ、ストレージ アカウントで匿名アクセスが許可されている場合は、サービスからエラー コード 404 (見つかりません) が返されます。
ベアラー チャレンジの詳細については、「ベアラー チャレンジ」を参照してください。
ストレージ アカウントの匿名アクセスを修復する
ストレージ アカウントのコンテナーと BLOB への匿名要求を評価したら、アカウントの AllowBlobPublicAccess プロパティを False に設定して、アカウント全体の匿名アクセスを修復するアクションを実行できます。
ストレージ アカウントに対する匿名アクセス設定は、そのアカウント内のコンテナーに対する個別設定をオーバーライドします。 ストレージ アカウントに対して匿名アクセスを禁止すると、匿名アクセスを許可するように構成されているコンテナーに匿名でアクセスできなくなります。 アカウントの匿名アクセスを許可していない場合は、個々のコンテナーの匿名アクセスも無効にする必要はありません。
シナリオで特定のコンテナーを匿名アクセスに使用できるようにする必要がある場合は、それらのコンテナーとその BLOB を、匿名アクセス専用に予約されている個別のストレージ アカウントに移動する必要があります。 その後、他のストレージ アカウントの匿名アクセスを禁止できます。
匿名アクセスを修復するには、Azure Storage リソース プロバイダーのバージョンが 2019-04-01 以降である必要があります。 詳細については、Azure Storage リソース プロバイダー REST API」 に関するページを参照してください。
匿名アクセスを禁止するためのアクセス許可
ストレージ アカウントの AllowBlobPublicAccess プロパティを設定するには、ストレージ アカウントを作成および管理するためのアクセス許可が必要です。 これらのアクセス許可を提供する Azure ロールベースのアクセス制御 (Azure RBAC) ロールには、Microsoft.Storage/storageAccounts/write アクションが含まれています。 このアクションの組み込みロールには、次のようなロールがあります。
- Azure Resource Manager の所有者ロール
- Azure Resource Manager の共同作成者ロール
- Storage Account の共同作成者ロール
ユーザーがストレージ アカウントの匿名アクセスを禁止できるようにするには、ロールの割り当てのスコープをストレージ アカウント以上のレベルにする必要があります。 ロール スコープの詳細については、「Azure RBAC のスコープについて」を参照してください。
これらのロールを割り当てる際には、ストレージ アカウントを作成したり、そのプロパティを更新したりする機能を必要とする管理ユーザーにのみ割り当てるように、注意してください。 最小限の特権の原則を使用して、ユーザーに、それぞれのタスクを実行するのに必要な最小限のアクセス許可を割り当てるようにします。 Azure RBAC でアクセスを管理する方法の詳細については、「Azure RBAC のベスト プラクティス」を参照してください。
これらのロールでは、Microsoft Entra ID を使用してストレージ アカウントのデータにアクセスすることはできません。 ただし、アカウント アクセス キーへのアクセスを許可する Microsoft.Storage/storageAccounts/listkeys/action が含まれています。 このアクセス許可では、ユーザーがアカウント アクセス キーを使用して、ストレージ アカウント内のすべてのデータにアクセスできます。
Microsoft.Storage/storageAccounts/listkeys/action 自体では、アカウント キーを介してデータ アクセスが許可されますが、ストレージ アカウントの AllowBlobPublicAccess プロパティを変更する機能はユーザーに付与されません。 ストレージ アカウントのデータにアクセスする必要があるが、ストレージ アカウントの構成を変更できないようにする必要があるユーザーの場合は、ストレージ BLOB データ共同作成者、ストレージ BLOB データ閲覧者、閲覧者とデータ アクセスなどのロールを割り当てることを検討してください。
Note
従来のサブスクリプション管理者ロールであるサービス管理者と共同管理者には、Azure Resource Manager の所有者ロールと同等のものが含まれています。 所有者ロールにはすべてのアクションが含まれているため、これらの管理者ロールのいずれかを持つユーザーも、ストレージ アカウントを作成し、アカウント構成を管理することができます。 詳細については、「Azure ロール、Microsoft Entra ロール、従来のサブスクリプション管理者ロール」を参照してください。
ストレージ アカウントの AllowBlobPublicAccess プロパティを False に設定する
ストレージ アカウントの匿名アクセス禁止するには、アカウントの AllowBlobPublicAccess プロパティを False に設定します。
重要
ストレージ アカウントで匿名アクセスを禁止すると、そのストレージ アカウント内のすべてのコンテナーのアクセス設定がオーバーライドされます。 ストレージ アカウントで匿名アクセスを禁止すると、以後、そのアカウントに対する匿名要求は失敗します。 この設定を変更する前に、「クライアント アプリケーションからの匿名要求の検出」で説明されている手順に従って、ストレージ アカウント内のデータに匿名でアクセスしている可能性があるクライアント アプリケーションに与える影響を必ず理解しておいてください。
Azure portal でストレージ アカウントの匿名アクセスを禁止するには、次の手順を実行します。
Azure Portal のストレージ アカウントに移動します。
[設定] から [構成] 設定を探します。
[BLOB の匿名アクセスを許可する] を [無効] に設定します。
Note
ストレージ アカウントの匿名アクセスを禁止しても、そのストレージ アカウントでホストされている静的な Web サイトには影響しません。 $web コンテナーは常にパブリック アクセスが可能です。
ストレージ アカウントの匿名アクセス設定を更新した後、変更が完全に反映されるまでに最大で 30 秒かかることがあります。
一括修復のためのサンプル スクリプト
次のサンプル PowerShell スクリプトは、サブスクリプション内のすべての Azure Resource Manager ストレージ アカウントに対して実行され、これらのアカウントの AllowBlobPublicAccess 設定を False に設定します。
<#
.SYNOPSIS
Finds storage accounts in a subscription where AllowBlobPublicAccess is True or null.
.DESCRIPTION
This script runs against all Azure Resource Manager storage accounts in a subscription
and sets the "AllowBlobPublicAccess" property to False.
Standard operation will enumerate all accounts where the setting is enabled and allow the
user to decide whether or not to disable the setting.
Classic storage accounts will require individual adjustment of containers to remove public
access, and will not be affected by this script.
Run with BypassConfirmation=$true if you wish to disallow public access on all Azure Resource Manager
storage accounts without individual confirmation.
You will need access to the subscription to run the script.
.PARAMETER BypassConformation
Set this to $true to skip confirmation of changes. Not recommended.
.PARAMETER SubscriptionId
The subscription ID of the subscription to check.
.PARAMETER ReadOnly
Set this parameter so that the script makes no changes to any subscriptions and only reports affect accounts.
.PARAMETER NoSignin
Set this parameter so that no sign-in occurs -- you must sign in first. Use this if you're invoking this script repeatedly for multiple subscriptions and want to avoid being prompted to sign-in for each subscription.
.OUTPUTS
This command produces only STDOUT output (not standard PowerShell) with information about affect accounts.
#>
param(
[boolean]$BypassConfirmation=$false,
[Parameter(Mandatory=$true, ValueFromPipelineByPropertyName='SubscriptionId')]
[String] $SubscriptionId,
[switch] $ReadOnly, # Use this if you don't want to make changes, but want to get information about affected accounts
[switch] $NoSignin # Use this if you are already signed in and don't want to be prompted again
)
begin {
if ( ! $NoSignin.IsPresent ) {
login-azaccount | out-null
}
}
process {
try {
select-azsubscription -subscriptionid $SubscriptionId -erroraction stop | out-null
} catch {
write-error "Unable to access select subscription '$SubscriptionId' as the signed in user -- ensure that you have access to this subscription." -erroraction stop
}
foreach ($account in Get-AzStorageAccount)
{
if($account.AllowBlobPublicAccess -eq $null -or $account.AllowBlobPublicAccess -eq $true)
{
Write-host "Account:" $account.StorageAccountName " isn't disallowing public access."
if ( ! $ReadOnly.IsPresent ) {
if(!$BypassConfirmation)
{
$confirmation = Read-Host "Do you wish to disallow public access? [y/n]"
}
if($BypassConfirmation -or $confirmation -eq 'y')
{
try
{
set-AzStorageAccount -Name $account.StorageAccountName -ResourceGroupName $account.ResourceGroupName -AllowBlobPublicAccess $false
Write-Host "Success!"
}
catch
{
Write-output $_
}
}
}
}
elseif($account.AllowBlobPublicAccess -eq $false)
{
Write-Host "Account:" $account.StorageAccountName " has public access disabled, no action required."
}
else
{
Write-Host "Account:" $account.StorageAccountName ". Error, please manually investigate."
}
}
}
end {
Write-Host "Script complete"
}
複数のアカウントの匿名アクセス設定を確認する
Azure portal の Azure Resource Graph エクスプローラーを使用すると、複数のストレージ アカウントにまたがって最も高速に匿名アクセス設定を確認できます。 Resource Graph エクスプローラーの使用方法については、「クイックスタート: Azure Resource Graph エクスプローラーを使用して初めての Resource Graph クエリを実行する」を参照してください。
Resource Graph エクスプローラーで次のクエリを実行すると、ストレージ アカウントの一覧が返され、各アカウントの匿名アクセス設定が表示されます。
resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess
| project subscriptionId, resourceGroup, name, allowBlobPublicAccess
次の図は、サブスクリプション全体におけるクエリの結果を示しています。 AllowBlobPublicAccess プロパティが明示的に設定されているストレージ アカウントの場合、結果に true または false として示されます。 ストレージ アカウントに対して AllowBlobPublicAccess プロパティが設定されていない場合、クエリ結果には空白 (または null) として示されます。
Azure Policy を使用してコンプライアンスを監査する
多数のストレージ アカウントがある場合、監査を実行して、それらのアカウントが匿名アクセスを防止するように構成されていることを確認したい場合があります。 一連のストレージ アカウントのコンプライアンスを監査するには、Azure Policy を使用します。 Azure Policy は、Azure リソースにルールを適用するポリシーの作成、割り当て、管理に使用できるサービスです。 Azure Policy を使用すると、それらのリソースが会社の標準やサービス レベル アグリーメントに準拠した状態を維持するのに役立ちます。 詳細については、Azure Policy の概要に関するページを参照してください。
Audit 効果を持つポリシーを作成する
Azure Policy では、ポリシー規則がリソースに対して評価されたときに実行される動作を決定する効果がサポートされています。 Audit 効果を使用すると、リソースが準拠していなければ警告が生成されますが、要求は停止されません。 効果の詳細については、「Azure Policy 効果について」を参照してください。
Azure portal でストレージ アカウントの匿名アクセスを設定するために Audit 効果を持つポリシーを作成するには、次の手順を実行します。
Azure portal で、Azure Policy サービスに移動します。
[作成] セクションで [定義] を選択します。
[ポリシー定義の追加] を選択して、新しいポリシー定義を作成します。
[定義の場所] フィールドで、 [More](詳細) ボタンを選択して、監査ポリシーのリソースがある場所を指定します。
ポリシーの名前を指定します。 必要に応じて説明およびカテゴリを指定することもできます。
[ポリシー規則] で、次のポリシー定義を policyRule セクションに追加します。
{ "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "not": { "field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "false" } } ] }, "then": { "effect": "audit" } }
ポリシーを保存します。
ポリシーを割り当てる
次に、ポリシーをリソースに割り当てます。 ポリシーのスコープは、そのリソースとその下にあるすべてのリソースに対応します。 ポリシー割り当ての詳細については、「Azure Policy の割り当ての構造」を参照してください。
Azure portal でポリシーを割り当てるには、次の手順を実行します。
- Azure portal で、Azure Policy サービスに移動します。
- [作成] セクションで [割り当て] を選択します。
- 新しいポリシー割り当てを作成するために、 [ポリシーの割り当て] を選択します。
- [スコープ] フィールドで、ポリシー割り当てのスコープを選択します。
- [ポリシー定義] フィールドで、 [More](詳細) ボタンを選択して、前のセクションで定義したポリシーを一覧から選択します。
- ポリシー割り当て用の名前 を入力します。 説明は省略できます。
- [ポリシーの適用] を "有効" のままに設定しておきます。 この設定は、監査ポリシーには影響しません。
- [確認および作成] を選択して割り当てを作成します。
コンプライアンス レポートを表示する
ポリシーを割り当てたら、コンプライアンス レポートを表示できます。 監査ポリシーのコンプライアンス レポートでは、ポリシーに準拠していないストレージ アカウントに関する情報が提供されます。 詳細については、ポリシーのコンプライアンス データを取得することに関する記事を参照してください。
ポリシー割り当てが作成された後、コンプライアンス レポートが使用可能になるまで数分かかる場合があります。
Azure portal でコンプライアンス レポートを表示するには、次の手順を実行します。
Azure portal で、Azure Policy サービスに移動します。
[コンプライアンス] を選択します。
前の手順で作成したポリシー割り当ての名前の結果をフィルター処理します。 レポートには、ポリシーに準拠していないリソースの数が示されます。
レポートをドリルダウンすると、準拠していないストレージ アカウントの一覧などの詳細を表示できます。
Azure Policy を使用して承認されたアクセスを適用する
Azure Policy は、Azure リソースが要件と標準に準拠していることを保証することによって、クラウド ガバナンスをサポートします。 組織内のストレージ アカウントが承認された要求のみを許可するようにするために、匿名要求を許可する匿名アクセス設定で新しいストレージ アカウントを作成できないようにするポリシーを作成できます。 このポリシーでは、そのアカウントの匿名アクセス設定がポリシーに準拠していない場合に、既存のアカウントに対するすべての構成変更も防止されます。
強制ポリシーでは、匿名アクセスを許可するためにストレージ アカウントを作成または変更する要求を防ぐための Deny 効果が使用されます。 効果の詳細については、「Azure Policy 効果について」を参照してください。
匿名要求を許可する匿名アクセス設定の Deny 効果を持つポリシーを作成するには、「Azure Policy を使用してコンプライアンスを監査する」で説明されている手順に従いますが、ポリシー定義の policyRule セクションに次の JSON を指定します。
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Storage/storageAccounts"
},
{
"not": {
"field":"Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"equals": "false"
}
}
]
},
"then": {
"effect": "deny"
}
}
Deny 効果を持つポリシーを作成し、これをスコープに割り当てると、ユーザーは匿名アクセスを許可するストレージ アカウントを作成できなくなります。 また、ユーザーは、現在匿名アクセスを許可している既存のストレージ アカウントに対して構成変更を行うこともできません。 この操作を行おうとすると、エラーが発生します。 アカウントの作成または構成を続行するには、ストレージ アカウントの匿名アクセス設定を false に設定する必要があります。
次の図は、Deny 効果を持つポリシーで、匿名アクセスが許可されないよう要求されているとき、匿名アクセスを許可するストレージ アカウントを作成しようとした場合に発生するエラーを示しています。