BLOB データへの匿名読み取りアクセスを修復する (Azure Resource Manager デプロイ環境)

[アーティクル]
08/13/2024

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 のストレージアカウントに移動します。 [監視] セクションで、 [メトリック] を選択します。
[メトリックの追加] を選択します。 [メトリック] ダイアログで、次の値を指定します。
1. [スコープ] フィールドは、ストレージアカウントの名前に設定したままにします。
2. [Metric Namespace](メトリックの名前空間) を [Blob](BLOB) に設定します。このメトリックでは、BLOB ストレージに対する要求のみが報告されます。
3. [メトリック] フィールドを [トランザクション] に設定します。
4. [集計] フィールドを [合計] に設定します。
新しいメトリックには、指定された期間中の BLOB ストレージに対するトランザクション数の合計が表示されます。結果のメトリックは、次の図のように表示されます。
次に、 [フィルターの追加] ボタンをクリックして、匿名要求のメトリックにフィルターを作成します。
[フィルター] ダイアログで、次の値を指定します。
1. [プロパティ] の値を [認証] に設定します。
2. [演算子] フィールドを等号 (=) に設定します。
3. [値] フィールドを [匿名] に設定します。そのためには、ドロップダウンから選択するか、入力します。
右上隅で、メトリックを表示する期間を選択します。 1 分から 1 か月の範囲で間隔を指定して、要求の集計のきめ細かさを指示することもできます。

メトリックを構成すると、匿名要求がグラフに表示されるようになります。次の図は、過去 30 分間に集計された匿名要求を示しています。

BLOB ストレージに対する匿名要求の集計を示すスクリーンショット

ストレージアカウントに対して一定数の匿名要求が行われたら通知する警告ルールも構成できます。詳細については、「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 で分析するには、まず、データをログに記録する要求の種類とストレージサービスを指示する診断設定を作成する必要があります。ストレージアカウントのログ記録を構成した後、Log Analytics ワークスペースでログを使用できます。ワークスペースを作成するには、「Azure portal で Log Analytics ワークスペースを作成する」を参照してください。

Azure portal で診断設定を作成する方法については、「Azure Monitor の診断設定を作成する」をご覧ください。

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 の匿名アクセスを許可する] を [無効] に設定します。

PowerShell を使用してストレージアカウントの匿名アクセスを禁止するには、Azure PowerShell バージョン 4.4.0 以降をインストールします。次に、新規または既存のストレージアカウントに AllowBlobPublicAccess プロパティを構成します。

次の例では、ストレージアカウントを作成し、明示的に AllowBlobPublicAccess プロパティを false に設定しています。かっこ内のプレースホルダー値を独自の値に置き換えることを忘れないでください。

$rgName = "<resource-group>"
$accountName = "<storage-account>"
$location = "<location>"

# Create a storage account with AllowBlobPublicAccess set to false.
New-AzStorageAccount -ResourceGroupName $rgName `
    -Name $accountName `
    -Location $location `
    -SkuName Standard_GRS `
    -AllowBlobPublicAccess $false

# Read the AllowBlobPublicAccess property for the newly created storage account.
(Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName).AllowBlobPublicAccess

Azure CLI を使用してストレージアカウントの匿名アクセスを禁止するには、Azure CLI バージョン 2.9.0 以降をインストールします。詳細については、「 Azure CLI のインストール」を参照してください。次に、新規または既存のストレージアカウントに allowBlobPublicAccess プロパティを構成します。

次の例では、ストレージアカウントを作成し、明示的に allowBlobPublicAccess プロパティを false に設定しています。かっこ内のプレースホルダー値を独自の値に置き換えることを忘れないでください。

az storage account create \
    --name <storage-account> \
    --resource-group <resource-group> \
    --kind StorageV2 \
    --location <location> \
    --allow-blob-public-access false

az storage account show \
    --name <storage-account> \
    --resource-group <resource-group> \
    --query allowBlobPublicAccess \
    --output tsv

テンプレートを使用したストレージアカウントの匿名アクセスを禁止するには、AllowBlobPublicAccess プロパティを false に設定してテンプレートを作成します。次の手順は、Azure portal でテンプレートを作成する方法について説明しています。

Azure portal で、 [リソースの作成] を選択します。
[Marketplace を検索] で「template deployment」と入力し、Enter キーを押します。
[Template deployment (deploy using custom templates) (preview)] (テンプレートのデプロイ (カスタムテンプレートを使用してデプロイ))、[作成]、[エディターで独自のテンプレートを作成する] の順に選びます。

テンプレートエディターで、次の JSON を貼り付けて新しいアカウントを作成し、AllowBlobPublicAccess プロパティを false に設定します。山かっこ内のプレースホルダーは、実際の値に置き換えてください。

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {},
    "variables": {
        "storageAccountName": "[concat(uniqueString(subscription().subscriptionId), 'template')]"
    },
    "resources": [
        {
        "name": "[variables('storageAccountName')]",
        "type": "Microsoft.Storage/storageAccounts",
        "apiVersion": "2019-06-01",
        "location": "<location>",
        "properties": {
            "allowBlobPublicAccess": false
        },
        "dependsOn": [],
        "sku": {
          "name": "Standard_GRS"
        },
        "kind": "StorageV2",
        "tags": {}
        }
    ]
}

テンプレートを保存します。
リソースグループパラメーターを指定し、 [レビューと作成] ボタンを選択してテンプレートをデプロイし、allowBlobPublicAccess プロパティが構成されたストレージアカウントを作成します。

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 ($null -eq $account.AllowBlobPublicAccess -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 効果を持つポリシーで、匿名アクセスが許可されないよう要求されているとき、匿名アクセスを許可するストレージアカウントを作成しようとした場合に発生するエラーを示しています。

ポリシーに違反するストレージアカウントを作成したときに発生したエラーを示すスクリーンショット

次の方法で共有

BLOB データへの匿名読み取りアクセスを修復する (Azure Resource Manager デプロイ環境)

Azure Resource Manager と従来のストレージアカウントの修復

匿名読み取りアクセスについて

クライアントアプリケーションからの匿名要求の検出

メトリックスエクスプローラーを使用した匿名要求の監視

ログを分析して匿名要求を受信しているコンテナーを識別する

Azure portal での診断設定の作成

匿名要求のログのクエリ

匿名要求への応答

ストレージアカウントの匿名アクセスを修復する

匿名アクセスを禁止するためのアクセス許可

ストレージアカウントの AllowBlobPublicAccess プロパティを False に設定する

一括修復のためのサンプルスクリプト

複数のアカウントの匿名アクセス設定を確認する

Azure Policy を使用してコンプライアンスを監査する

Audit 効果を持つポリシーを作成する

ポリシーを割り当てる

コンプライアンスレポートを表示する

Azure Policy を使用して承認されたアクセスを適用する

次のステップ

フィードバック

その他のリソース

次の方法で共有

BLOB データへの匿名読み取りアクセスを修復する (Azure Resource Manager デプロイ環境)

Azure Resource Manager と従来のストレージ アカウントの修復

匿名読み取りアクセスについて

クライアント アプリケーションからの匿名要求の検出

メトリックス エクスプローラーを使用した匿名要求の監視

ログを分析して匿名要求を受信しているコンテナーを識別する

Azure portal での診断設定の作成

匿名要求のログのクエリ

匿名要求への応答

ストレージ アカウントの匿名アクセスを修復する

匿名アクセスを禁止するためのアクセス許可

ストレージ アカウントの AllowBlobPublicAccess プロパティを False に設定する

一括修復のためのサンプル スクリプト

複数のアカウントの匿名アクセス設定を確認する

Azure Policy を使用してコンプライアンスを監査する

Audit 効果を持つポリシーを作成する

ポリシーを割り当てる

コンプライアンス レポートを表示する

Azure Policy を使用して承認されたアクセスを適用する

次のステップ

フィードバック

その他のリソース

Azure Resource Manager と従来のストレージアカウントの修復

クライアントアプリケーションからの匿名要求の検出

メトリックスエクスプローラーを使用した匿名要求の監視

ストレージアカウントの匿名アクセスを修復する

ストレージアカウントの AllowBlobPublicAccess プロパティを False に設定する

一括修復のためのサンプルスクリプト

コンプライアンスレポートを表示する