BLOB データへの匿名読み取りアクセスを修復する (クラシック デプロイ)
Azure Blob Storage では、コンテナーと BLOB へのオプションの匿名読み取りアクセスがサポートされています。 ただし、匿名アクセスはセキュリティ リスクをもたらす可能性があります。 最適なセキュリティのためには、匿名アクセスを無効にすることをお勧めします。 匿名アクセスを禁止することで、望ましくない匿名アクセスによって発生するデータ侵害を防ぐことができます。
既定では、BLOB データへの匿名アクセスは常に禁止されています。 ただし、従来のストレージ アカウントの既定の構成では、適切なアクセス許可を持つユーザーが、ストレージ アカウントのコンテナーおよび BLOB への匿名アクセスを構成することができます。 従来のストレージ アカウントへの匿名アクセスを防ぐには、匿名アクセスをブロックするようにアカウント内の各コンテナーを構成する必要があります。
ストレージ アカウントでクラシック デプロイ モデルを使用している場合は、できるだけ早く Azure Resource Manager デプロイ モデルに移行することをお勧めします。 アカウントを移行した後は、アカウント レベルで、匿名アクセスを許可しないように構成できます。 Azure Resource Manager アカウントの匿名アクセスを許可しない方法については、BLOB データへの匿名読み取りアクセスの修復 (Azure Resource Manager デプロイ)に関する記事を参照してください。
今のところ従来のストレージ アカウントを移行できない場合は、すべてのコンテナーをプライベートに設定して、それらのアカウントへの匿名アクセスを今すぐ修復する必要があります。 この記事では、従来のストレージ アカウント内のコンテナーへのアクセスを修復する方法について説明します。
クラシック デプロイ モデルを使用している Azure Storage アカウントは、2024 年 8 月 31 日に廃止される予定です。 詳細については、「Azure クラシック ストレージ アカウントは 2024 年 8 月 31 日に廃止される」を参照してください。
警告
匿名アクセスでは、セキュリティ リスクがもたらされます。 お客様のシナリオで特に匿名アクセスが必要な場合を除き、次のセクションで説明するアクションを実行して、従来のストレージ アカウントすべてについて匿名アクセスを修復することをお勧めします。
コンテナーへの匿名アクセスをブロックする
従来のストレージ アカウントの匿名アクセスを修復するには、アカウント内の各コンテナーの匿名アクセス レベルを [プライベート] に設定します。
Azure portal で 1 つ以上のコンテナーの匿名アクセスを修復するには、以下の手順を実行します。
Azure portal でご利用のストレージ アカウントの概要に移動します。
メニュー ブレードの [データ ストレージ] で、 [BLOB コンテナー] を選択します。
匿名アクセス レベルを設定するコンテナーを選択します。
[アクセス レベルの変更] ボタンを使用して、アクセスの設定を表示します。
[Anonymous access level](l匿名アクセス レベル) ドロップダウンから [Private (no anonymous access)](プライベート (匿名アクセスなし)) を選択し、[OK] ボタンをクリックして、選択したコンテナーに変更を適用します。
複数のコンテナーの匿名アクセス設定の確認
コンテナーを一覧表示して匿名アクセス設定を確認することによって、1 つ以上のストレージ アカウントのどのコンテナーが匿名アクセス用に構成されているか確認できます。 この方法は、ストレージ アカウントに多数のコンテナーが含まれていない場合や、少数のストレージ アカウントにまたがって設定を確認する場合に実用的な選択肢です。 ただし、多数のコンテナーを列挙しようとすると、パフォーマンスが低下する可能性があります。
次の例では、PowerShell を使用して、ストレージ アカウントのすべてのコンテナーの匿名アクセス設定を取得します。 かっこ内のプレースホルダー値を独自の値に置き換えることを忘れないでください。
$rgName = "<resource-group>"
$accountName = "<storage-account>"
$storageAccount = Get-AzStorageAccount -ResourceGroupName $rgName -Name $accountName
$ctx = $storageAccount.Context
Get-AzStorageContainer -Context $ctx | Select Name, PublicAccess
一括修復のためのサンプル スクリプト
次のサンプル PowerShell スクリプトは、サブスクリプション内の従来のクラシック ストレージ アカウントすべてに対して実行され、それらのアカウント内のコンテナーの匿名アクセス設定が [プライベート] に設定されます。
注意事項
コンテナーの数が非常に多いストレージ アカウントに対してこのスクリプトを実行すると、大量のリソースが必要になり、長い時間がかかることがあります。 コンテナーの数が非常に多いストレージ アカウントがある場合は、匿名アクセスの修復のために異なる方法を考え出すことをお勧めします。
# This script runs against all classic storage accounts in a single subscription
# and sets containers to private.
## IMPORTANT ##
# Running this script requires a connected account through the previous version
# of Azure PowerShell. Use the following command to install:
# Install-Module Azure -scope CurrentUser -force
#
# Once installed, you will need to connect with:
# Add-AzureAccount
#
# This command may fail if there are modules installed that conflict with it.
# One known conflicting module is AzureRm.Accounts
# You will need to remove conflicting modules using the following:
# Remove-Module -name <name>
#
# The Azure PowerShell module assumes a current subscription when enumerating
# storage accounts. You can set the current subscription with:
# Select-AzureSubscription -subscriptionId <subscriptionId>
#
# Get-AzureSubscription lists all subscriptions available to the Azure
# module. Not all subscriptions listed under your name in the portal may
# appear here. If a subscription does not appear, you may need to use
# the portal to remediate public access for those accounts.
# After you have selected your subscription, verify that it is current
# by running:
# Get-AzureSubscription -current
#
# After the current subscription runs, you can run this script, change
# to another subscription after it completes, and then run again as necessary.
## END IMPORTANT##
# Standard operation will enumerate all accounts and check for containers with public
# access, then allow the user to decide whether or not to disable the setting.
# Run with BypassConfirmation=$true if you wish to remove permissions from all containers
# without individual confirmation
# Run with BypassArmUpgrade=$true if you wish to upgrade your storage account to use the
# Azure Resource Manager deployment model. All accounts must be upgraded by 31 August 2024.
param(
[boolean]$BypassConfirmation=$false,
[boolean]$BypassArmUpgrade=$false
)
#Do not change this
$convertAccounts = $false
foreach($classicAccount in Get-AzureStorageAccount)
{
$enumerate = $false
if(!$BypassArmUpgrade)
{
write-host "Classic Storage Account" $classicAccount.storageAccountname "found"
$confirmation = read-host "Convert to ARM? [y/n]:"
}
if(($confirmation -eq 'y') -and (!$BypassArmUpgrade))
{
write-host "Conversion selected"
$convertAccounts = $true
}
else
{
write-host $classicAccount.StorageAccountName "conversion not selected. Searching for public containers..."
$enumerate = $true
}
if($enumerate)
{
foreach($container in get-azurestoragecontainer -context (get-azurestorageaccount -storageaccountname $classicAccount.StorageAccountName).context)
{
if($container.PublicAccess -eq 'Off')
{
}
else
{
if(!$BypassConfirmation)
{
$selection = read-host $container.Name $container.PublicAccess "access found, Make private?[y/n]:"
}
if(($selection -eq 'y') -or ($BypassConfirmation))
{
write-host "Removing permissions from" $container.name "container on storage account" $classicaccount.StorageAccountName
try
{
Set-AzureStorageContainerAcl -context $classicAccount.context -name $container.name -Permission Off
write-host "Success!"
}
catch
{
$_
}
}
else
{
write-host "Skipping..."
}
}
}
}
}
if($convertAccounts)
{
write-host "Converting accounts to ARM is the preferred method, however there are some caveats."
write-host "The preferred method would be to use the portal to perform the conversions and then "
write-host "run the ARM script against them. For more information on converting a classic account"
write-host "to an ARM account, please see:"
write-host "https://learn.microsoft.com/en-us/azure/virtual-machines/migration-classic-resource-manager-overview"
}
write-host "Script complete"