Azure Storage セキュリティ ガイドAzure Storage security guide

Azure Storage で提供される包括的なセキュリティ機能のセットを利用して、開発者はセキュリティで保護されたアプリケーションを構築できます。Azure Storage provides a comprehensive set of security capabilities that together enable developers to build secure applications:

  • Azure Storage に書き込まれるすべてのデータ (メタデータを含む) は、Storage Service Encryption (SSE) を使用して自動的に暗号化されます。All data (including metadata) written to Azure Storage is automatically encrypted using Storage Service Encryption (SSE). 詳しくは、「Announcing Default Encryption for Azure Blobs, Files, Table and Queue Storage (Azure Blob、Files、Table、Queue Storage 用の既定の暗号化の発表)」をご覧ください。For more information, see Announcing Default Encryption for Azure Blobs, Files, Table and Queue Storage.
  • Azure Active Directory (Azure AD) とロールベースのアクセス制御 (RBAC) は、Azure Storage のリソース管理操作とデータ操作の両方でサポートされます。Azure Active Directory (Azure AD) and Role-Based Access Control (RBAC) are supported for Azure Storage for both resource management operations and data operations, as follows:
    • ストレージ アカウントを対象とする RBAC ロールをセキュリティ プリンシパルに割り当て、Azure AD を使用して、キー管理などのリソース管理操作を承認できます。You can assign RBAC roles scoped to the storage account to security principals and use Azure AD to authorize resource management operations such as key management.
    • Azure AD の統合は、BLOB およびキュー データ操作でサポートされています。Azure AD integration is supported for blob and queue data operations. サブスクリプション、リソース グループ、ストレージ アカウント、または個々のコンテナーやキューを対象とする RBAC ロールをセキュリティ プリンシパルまたは Azure リソースのマネージド ID に割り当てることができます。You can assign RBAC roles scoped to a subscription, resource group, storage account, or an individual container or queue to a security principal or a managed identity for Azure resources. 詳細については、「Azure Active Directory を使用して Azure Storage へのアクセスを認証する」を参照してください。For more information, see Authenticate access to Azure Storage using Azure Active Directory.
  • アプリケーションと Azure の間で送信されるデータを、 クライアント側暗号化、HTTPS、または SMB 3.0 使用して保護できます。Data can be secured in transit between an application and Azure by using Client-Side Encryption, HTTPS, or SMB 3.0.
  • Azure 仮想マシンに使用する OS とデータ ディスクは、Azure Disk Encryption を使用して暗号化できます。OS and data disks used by Azure virtual machines can be encrypted using Azure Disk Encryption.
  • Azure Storage 内のデータ オブジェクトに対する委任されたアクセス権は、 Shared Access Signatureを使用して付与できます。Delegated access to the data objects in Azure Storage can be granted using Shared Access Signatures.

この記事では、Azure Storage で使用できる各セキュリティ機能の概要について説明します。This article provides an overview of each of these security features that can be used with Azure Storage. また、各トピックの詳細を簡単に調べられるように、各機能の詳細を説明した記事のリンクも紹介します。Links are provided to articles that will give details of each feature so you can easily do further investigation on each topic.

この記事では次のトピックについて扱います。Here are the topics to be covered in this article:

  • 管理プレーンのセキュリティ - ストレージ アカウントのセキュリティ保護Management Plane Security – Securing your Storage Account

    管理プレーンは、ストレージ アカウントの管理に使用するリソースが構成されます。The management plane consists of the resources used to manage your storage account. このセクションでは、Azure Resource Manager デプロイ モデルと、ロールベースのアクセス制御 (RBAC) を使用してストレージ アカウントへのアクセスを制御する方法について説明します。This section covers the Azure Resource Manager deployment model and how to use Role-Based Access Control (RBAC) to control access to your storage accounts. また、ストレージ アカウント キーの管理とその再生成方法についても説明します。It also addresses managing your storage account keys and how to regenerate them.

  • データ プレーンのセキュリティ - データへのアクセスのセキュリティ保護Data Plane Security – Securing Access to Your Data

    このセクションでは、Shared Access Signature と保存されたアクセス ポリシーを使用して、BLOB、ファイル、キュー、テーブルなど、ストレージ アカウントの実際のデータ オブジェクトに対してアクセスを許可する方法について説明します。In this section, we'll look at allowing access to the actual data objects in your Storage account, such as blobs, files, queues, and tables, using Shared Access Signatures and Stored Access Policies. サービスレベルの SAS とアカウントレベルの SAS の両方が対象です。We will cover both service-level SAS and account-level SAS. また、特定の IP アドレス (または IP アドレスの範囲) に対するアクセスを制限する方法、HTTPS に使用されるプロトコルを制限する方法、Shared Access Signature が期限切れになる前に無効にする方法についても説明します。We'll also see how to limit access to a specific IP address (or range of IP addresses), how to limit the protocol used to HTTPS, and how to revoke a Shared Access Signature without waiting for it to expire.

  • 転送中の暗号化Encryption in Transit

    このセクションでは、Azure Storage とのデータの送受信時にデータをセキュリティで保護する方法について説明します。This section discusses how to secure data when you transfer it into or out of Azure Storage. Azure ファイル共有に対して SMB 3.0 による暗号化と HTTPS の推奨される使用方法について説明します。We'll talk about the recommended use of HTTPS and the encryption used by SMB 3.0 for Azure file shares. また、クライアント側の暗号化についても取り上げます。クライアント側の暗号化の場合、クライアント アプリケーションで Storage にデータを転送する前にデータを暗号化し、Storage からデータを転送した後にデータを復号化することができます。We will also take a look at Client-side Encryption, which enables you to encrypt the data before it is transferred into Storage in a client application, and to decrypt the data after it is transferred out of Storage.

  • 保存時の暗号化Encryption at Rest

    新規および既存のストレージ アカウントに対して自動的に有効になる Storage Service Encryption (SSE) について説明します。We will talk about Storage Service Encryption (SSE), which is now automatically enabled for new and existing storage accounts. また、Azure Disk Encryption の使用方法についても取り上げ、Disk Encryption、SSE、およびクライアント側認証の基本的な違いと、例についても説明します。We will also look at how you can use Azure Disk Encryption and explore the basic differences and cases of Disk Encryption versus SSE versus Client-Side Encryption. さらに、米国政府のコンピューターの FIPS 準拠についても簡単に取り上げます。We will briefly look at FIPS compliance for U.S. Government computers.

  • Storage Analytics を使用して Azure Storage のアクセスを監査するUsing Storage Analytics to audit access of Azure Storage

    ここでは、要求のストレージ分析ログから情報を検索する方法について説明します。This section discusses how to find information in the storage analytics logs for a request. 実際のストレージ分析ログ データを見て、要求の作成元がストレージ アカウント キー、Shared Access Signature、または匿名のいずれであるか、要求が成功したか失敗したかを特定する方法を確認します。We'll take a look at real storage analytics log data and see how to discern whether a request is made with the Storage account key, with a Shared Access signature, or anonymously, and whether it succeeded or failed.

  • CORS を使用してブラウザーベースのクライアントを有効にするEnabling Browser-Based Clients using CORS

    このセクションでは、クロス オリジン リソース共有 (CORS) を許可する方法について説明します。This section talks about how to allow cross-origin resource sharing (CORS). また、クロスドメイン アクセスと、Azure Storage に組み込まれている CORS 機能を使用して処理する方法について話します。We'll talk about cross-domain access, and how to handle it with the CORS capabilities built into Azure Storage.

管理プレーンのセキュリティManagement Plane Security

管理プレーンは、ストレージ アカウントに影響がある操作から構成されます。The management plane consists of operations that affect the storage account itself. たとえば、ストレージ アカウントの作成または削除、サブスクリプションのストレージ アカウント一覧の取得、ストレージ アカウント キーの取得、ストレージ アカウント キーの再生成などの操作です。For example, you can create or delete a storage account, get a list of storage accounts in a subscription, retrieve the storage account keys, or regenerate the storage account keys.

新しいストレージ アカウントを作成するときに、クラシックまたは Resource Manager のデプロイ モデルを選択します。When you create a new storage account, you select a deployment model of Classic or Resource Manager. Azure にリソースを作成するクラシック モデルでは、サブスクリプション (つまりストレージ アカウント) に対するオールオアナッシング形式のアクセス権のみを許可します。The Classic model of creating resources in Azure only allows all-or-nothing access to the subscription, and in turn, the storage account.

このガイドでは、ストレージ アカウント作成で推奨される手法である Resource Manager モデルを中心に説明します。This guide focuses on the Resource Manager model that is the recommended means for creating storage accounts. Resource Manager ストレージ アカウントでは、サブスクリプション全体にアクセス権を付与するのではなく、ロールベースのアクセス制御 (RBAC) を使用して、より細かいレベルで管理プレーンに対するアクセス権を制御できます。With the Resource Manager storage accounts, rather than giving access to the entire subscription, you can control access on a more finite level to the management plane using Role-Based Access Control (RBAC).

ロールベースのアクセス制御 (RBAC) を使用してストレージ アカウントをセキュリティで保護する方法How to secure your storage account with Role-Based Access Control (RBAC)

それでは、RBAC の概要と、その使用方法について説明します。Let's talk about what RBAC is, and how you can use it. 各 Azure サブスクリプションには Azure Active Directory があります。Each Azure subscription has an Azure Active Directory. そのディレクトリのユーザー、グループ、アプリケーションに対して、Resource Manager デプロイ モデルを使用する Azure サブスクリプション内にあるリソースを管理するアクセス権を付与できます。Users, groups, and applications from that directory can be granted access to manage resources in the Azure subscription that use the Resource Manager deployment model. この種のセキュリティは、ロールベースのアクセス制御 (RBAC) と呼ばれます。This type of security is referred to as Role-Based Access Control (RBAC). このアクセスを管理するには、Azure PortalAzure CLI ツールPowerShell、または Azure Storage Resource Provider REST API を使用できます。To manage this access, you can use the Azure portal, the Azure CLI tools, PowerShell, or the Azure Storage Resource Provider REST APIs.

Resource Manager モデルでは、Azure Active Directory を使用して、リソース グループにストレージ アカウントを追加し、特定のストレージ アカウントの管理プレーンに対するアクセス権を制御します。With the Resource Manager model, you put the storage account in a resource group and control access to the management plane of that specific storage account using Azure Active Directory. たとえば、ストレージ アカウント キーへのアクセス権を特定のユーザーに付与し、他のユーザーはそのストレージ アカウントに関する情報を読み取ることはできても、ストレージ アカウント キーにはアクセスでないようにすることができます。For example, you can give specific users the ability to access the storage account keys, while other users can view information about the storage account, but cannot access the storage account keys.

アクセス権を付与するGranting Access

正しいスコープで、ユーザー、グループ、およびアプリケーションに適切な RBAC ロールを割り当てることで、アクセス権が付与されます。Access is granted by assigning the appropriate RBAC role to users, groups, and applications, at the right scope. サブスクリプション全体にアクセス権を付与するには、サブスクリプションのレベルでロールを割り当てます。To grant access to the entire subscription, you assign a role at the subscription level. リソース グループ内のすべてのリソースに対してアクセス権を付与するには、リソース グループにアクセス許可を付与します。You can grant access to all of the resources in a resource group by granting permissions to the resource group itself. また、ストレージ アカウントなど、特定のリソースに対して特定のロールを割り当てることもできます。You can also assign specific roles to specific resources, such as storage accounts.

ここでは、RBAC を使用して、Azure Storage アカウントの管理操作にアクセスする場合に知る必要がある主な点について説明します。Here are the main points that you need to know about using RBAC to access the management operations of an Azure Storage account:

  • アクセス権を割り当てるときは、基本的に、アクセス権を付与するアカウントに対してロールを割り当てます。When you assign access, you basically assign a role to the account that you want to have access. アカウントのデータ オブジェクトではなく、ストレージ アカウントの管理に使用する操作に対するアクセス権を制御できます。You can control access to the operations used to manage that storage account, but not to the data objects in the account. たとえば、Blob Storage のコンテナーやコンテナー内のデータではなく、ストレージ アカウントのプロパティ (冗長性など) を取得するアクセス許可を付与できます。For example, you can grant permission to retrieve the properties of the storage account (such as redundancy), but not to a container or data within a container inside Blob Storage.

  • ストレージ アカウントのデータ オブジェクトにアクセスするアクセス許可を持つユーザーがいる場合、ストレージ アカウント キーを読み取るアクセス許可をそのユーザーに付与できます。また、そのユーザーは、そのストレージ アカウント キーを使用して BLOB、キュー、テーブル、ファイルにアクセスできます。For someone to have permission to access the data objects in the storage account, you can give them permission to read the storage account keys, and that user can then use those keys to access the blobs, queues, tables, and files.

  • ロールは、特定のユーザー アカウント、ユーザー グループ、または特定のアプリケーションに割り当てることができます。Roles can be assigned to a specific user account, a group of users, or to a specific application.

  • 各ロールには、Actions と Not Actions の一覧があります。Each role has a list of Actions and Not Actions. たとえば、仮想マシン共同作成者ロールには、ストレージ アカウント キーを読み取ることができる "listKeys" というアクションがあります。For example, the Virtual Machine Contributor role has an Action of "listKeys" that allows the storage account keys to be read. また、共同作成者には、Active Directory 内のユーザーのアクセスを更新するなどの "Not Actions" があります。The Contributor has "Not Actions" such as updating the access for users in the Active Directory.

  • ストレージには、次のようなロールがあります。Roles for storage include (but are not limited to) the following roles:

    • 所有者 - アクセス権を含めすべてを管理できます。Owner – They can manage everything, including access.

    • 共同作成者 - アクセス権の割り当てを除き、所有者ができるすべての操作を実行できます。Contributor – They can do anything the owner can do except assign access. このロールを持つユーザーは、ストレージ アカウント キーの読み取りと再生成を行うことができます。Someone with this role can view and regenerate the storage account keys. ストレージ アカウント キーを使用すると、データ オブジェクトにアクセスできます。With the storage account keys, they can access the data objects.

    • 閲覧者 - シークレットを除き、ストレージ アカウントに関する情報を読み取ることができます。Reader – They can view information about the storage account, except secrets. たとえば、ストレージ アカウントの閲覧者アクセス許可を持つロールを誰かに割り当てると、そのユーザーはストレージ アカウントのプロパティを読み取ることができますが、プロパティを変更したり、ストレージ アカウント キーを読み取ったりすることはできません。For example, if you assign a role with reader permissions on the storage account to someone, they can view the properties of the storage account, but they can't make any changes to the properties or view the storage account keys.

    • ストレージ アカウント共同作成者 - ストレージ アカウントを管理できます。また、サブスクリプションのリソース グループとリソースを読み取って、サブスクリプションのリソース グループ デプロイを作成し、管理することができます。Storage Account Contributor – They can manage the storage account – they can read the subscription's resource groups and resources, and create and manage subscription resource group deployments. ストレージ アカウント キーにアクセスすることもできます。したがって、データ プレーンにもアクセスできます。They can also access the storage account keys, which in turn means they can access the data plane.

    • ユーザー アクセス管理者 - ストレージ アカウントに対するユーザー アクセスを管理できます。User Access Administrator – They can manage user access to the storage account. たとえば、特定のユーザーに対して閲覧者アクセス権を付与できます。For example, they can grant Reader access to a specific user.

    • 仮想マシン共同作成者 - 接続しているストレージ アカウント以外の仮想マシンを管理できます。Virtual Machine Contributor – They can manage virtual machines but not the storage account to which they are connected. このロールは、ストレージ アカウント キーの一覧を取得できます。つまり、このロールが割り当てられたユーザーは、データ プレーンを更新できます。This role can list the storage account keys, which means that the user to whom you assign this role can update the data plane.

      ユーザーが仮想マシンを作成できるようにするには、ストレージ アカウントで対応する VHD ファイルを作成できるようにする必要があります。In order for a user to create a virtual machine, they have to be able to create the corresponding VHD file in a storage account. この処理には、ストレージ アカウント キーを取得し、VM を作成する API に渡すことができるようにする必要があります。To do that, they need to be able to retrieve the storage account key and pass it to the API creating the VM. したがって、このアクセス許可を付与して、ストレージ アカウント キー一覧を取得できるようにする必要があります。Therefore, they must have this permission so they can list the storage account keys.

  • カスタム ロールを定義する機能は、Azure リソースに対して実行できる可能なアクションの一覧から、1 組のアクションを構成できる機能です。The ability to define custom roles is a feature that allows you to compose a set of actions from a list of available actions that can be performed on Azure resources.

  • ユーザーにロールを割り当てる前に、Azure Active Directory にユーザーを設定する必要があります。The user must be set up in your Azure Active Directory before you can assign a role to them.

  • PowerShell または Azure CLI を使用して、アクセス権の付与したユーザーまたは無効にしたユーザー、アクセス権の種類、アクセス権が付与されたユーザーまたは無効にされたユーザー、アクセス権のスコープについて、レポートを作成できます。You can create a report of who granted/revoked what kind of access to/from whom and on what scope using PowerShell or the Azure CLI.


ストレージ アカウント キーを管理するManaging Your Storage Account Keys

ストレージ アカウント キーは、Azure で作成される 512 ビットの文字列です。ストレージ アカウント名と共に使用して、ストレージ アカウントに保存されているデータ オブジェクト (BLOB、テーブル内のエンティティ、キュー メッセージ、Azure ファイル共有上のファイルなど) へのアクセスに使用できます。Storage account keys are 512-bit strings created by Azure that, along with the storage account name, can be used to access the data objects stored in the storage account, for example, blobs, entities within a table, queue messages, and files on an Azure file share. ストレージ アカウント キーに対するアクセス権の制御によって、そのストレージ アカウントのデータ プレーンに対するアクセス権を制御します。Controlling access to the storage account keys controls access to the data plane for that storage account.

各ストレージ アカウントには、Azure Portal と PowerShell コマンドレットで "キー 1" と "キー 2" と呼ばれる 2 つのキーがあります。Each storage account has two keys referred to as "Key 1" and "Key 2" in the Azure portal and in the PowerShell cmdlets. これらのキーは、 Azure ポータル、PowerShell、Azure CLI、プログラム (.NET ストレージ クライアント ライブラリや Azure Storage Services REST API を使用) など、いずれかの方法を使用して手動で再生成できます。These can be regenerated manually using one of several methods, including, but not limited to using the Azure portal, PowerShell, the Azure CLI, or programmatically using the .NET Storage Client Library or the Azure Storage Services REST API.

ストレージ アカウント キーは、さまざまな理由で再生成することがあります。There are any number of reasons to regenerate your storage account keys.

  • また、セキュリティ上の理由で、定期的に再生成する場合もあります。You might regenerate them on a regular basis for security reasons.
  • 誰かが何らかの方法でアプリケーションをハッキングし、構成ファイルにハードコーディングまたは保存されたキーを取得して、ストレージ アカウントに対してフル アクセス権を獲得した場合も、ストレージ アカウント キーを再生成します。You would regenerate your storage account keys if someone managed to hack into an application and retrieve the key that was hardcoded or saved in a configuration file, giving them full access to your storage account.
  • キー再生成のもう 1 つの例として、ストレージ アカウント キーを保存するストレージ エクスプローラー アプリケーションをチームが使用していて、チームのメンバーがチームから外れた場合があります。Another case for key regeneration is if your team is using a Storage Explorer application that retains the storage account key, and one of the team members leaves. メンバーがチームから外れた後も、アプリケーションは継続して動作し、そのメンバーのストレージ アカウントに対するアクセス権は無効になりません。The application would continue to work, giving them access to your storage account after they're gone. 実際のところ、これがアカウントレベルの Shared Access Signature を作成した主な理由です。構成ファイルにアクセス キーを保存するのではなく、アカウントレベルの SAS を使用できます。This is actually the primary reason they created account-level Shared Access Signatures – you can use an account-level SAS instead of storing the access keys in a configuration file.

キーの再生成計画Key regeneration plan

通常は、計画もなく使用するキーをただ再生成することはありません。You don't want to just regenerate the key you are using without some planning. 無計画にキーを再生成すると、そのストレージ アカウントに対するすべてのアクセス権が削除され、結果として大きな混乱が起こる可能性があります。If you do that, you could cut off all access to that storage account, which can cause major disruption. 2 つのキーがあるのは、このためです。This is why there are two keys. 一度に 1 つのキー再生成することをお勧めします。You should regenerate one key at a time.

キーを再生成する前に、ストレージ アカウントに依存するすべてのアプリケーションと、Azure で使用しているその他のサービスの一覧を取得しておきます。Before you regenerate your keys, be sure you have a list of all of your applications that are dependent on the storage account, as well as any other services you are using in Azure. たとえば、ストレージ アカウントに依存する Azure Media Services を使用している場合は、アクセス キーを再生成した後で、そのキーをメディア サービスと再同期する必要があります。For example, if you are using Azure Media Services that are dependent on your storage account, you must resync the access keys with your media service after you regenerate the key. ストレージ エクスプローラーなどのアプリケーションを使用している場合、そのアプリケーションにも新しいキーを提供する必要があります。If you are using any applications such as a storage explorer, you will need to provide the new keys to those applications as well. VHD ファイルがストレージ アカウントに格納されている VM がある場合、ストレージ アカウント キーの再生成によって影響を受けることはありません。If you have VMs whose VHD files are stored in the storage account, they will not be affected by regenerating the storage account keys.

キーの再生成は、Azure ポータルで行うことができます。You can regenerate your keys in the Azure portal. キーを再生成すると、Storage サービス全体に同期されるまで最大 10 分間かかる可能性があります。Once keys are regenerated, they can take up to 10 minutes to be synchronized across Storage Services.

準備ができたら、キーを変更する場合の一般的なプロセスを次に示します。When you're ready, here's the general process detailing how you should change your key. この例では、現在キー 1 を使用していて、すべてにキー 2 を使用するように変更します。In this case, the assumption is that you are currently using Key 1 and you are going to change everything to use Key 2 instead.

  1. セキュリティで保護されるようにキー 2 を再生成します。Regenerate Key 2 to ensure that it is secure. この処理は、Azure ポータルで実行できます。You can do this in the Azure portal.
  2. ストレージ キーが格納されているすべてのアプリケーションで、キー 2 の新しい値を使用するようにストレージ キーを変更します。In all of the applications where the storage key is stored, change the storage key to use Key 2's new value. アプリケーションをテストし、発行します。Test and publish the application.
  3. すべてのアプリケーションとサービスが起動し、正常に動作したら、キー 1 を再生成します。After all of the applications and services are up and running successfully, regenerate Key 1. こうすることで、新しいキーを明示的に付与していない相手は、ストレージ アカウントに対してアクセスできなくなります。This ensures that anybody to whom you have not expressly given the new key will no longer have access to the storage account.

現在キー 2 を使用している場合、同じプロセスを使用できますが、キー名を逆にしてください。If you are currently using Key 2, you can use the same process, but reverse the key names.

数日かけて移行し、新しいキーを使用するように各アプリケーションを変更し、公開できます。You can migrate over a couple of days, changing each application to use the new key and publishing it. すべてが完了したら、戻って古いキーを再生成することをお勧めします。再生成後は古いキーが動作しなくなります。After all of them are done, you should then go back and regenerate the old key so it no longer works.

また、ストレージ アカウント キーをシークレットとして Azure Key Vault に格納し、アプリケーションでそこからキーを取得する方法もあります。Another option is to put the storage account key in an Azure Key Vault as a secret and have your applications retrieve the key from there. 次にキーを再生成し、Azure Key Vault を更新するときに、アプリケーションを再デプロイする必要はありません。Azure Key Vault から新しいキーが自動的に選択されます。Then when you regenerate the key and update the Azure Key Vault, the applications will not need to be redeployed because they will pick up the new key from the Azure Key Vault automatically. アプリケーションで必要になるたびにキーを読み取るか、メモリにキャッシュし、使用に失敗した場合に、Azure Key Vault からキーを取得し直すことができます。Note that you can have the application read the key each time you need it, or you can cache it in memory and if it fails when using it, retrieve the key again from the Azure Key Vault.

Azure Key Vault を使用すると、ストレージ キーのセキュリティ レベルも 1 つ追加されます。Using Azure Key Vault also adds another level of security for your storage keys. この方法を使用する場合、構成ファイルにストレージ キーはハードコーディングされなくなります。そのため、特定のアクセス許可を持たない誰かがキーへのアクセス権を取得する抜け道がなくなります。If you use this method, you will never have the storage key hardcoded in a configuration file, which removes that avenue of somebody getting access to the keys without specific permission.

Azure Key Vault を使用するもう 1 つの利点は、Azure Active Directory を使用してキーへのアクセス権を制御することもできる点です。Another advantage of using Azure Key Vault is you can also control access to your keys using Azure Active Directory. つまり、Azure Key Vault からキーを取得する必要がある多数のアプリケーションに対してアクセス権を付与できます。また、アクセス許可が明示的に付与されていない他のアプリケーションが、キーにアクセスできないことを把握できます。This means you can grant access to the handful of applications that need to retrieve the keys from Azure Key Vault, and know that other applications will not be able to access the keys without granting them permission specifically.


Microsoft では、すべてのアプリケーションで、同時にいずれかのキーのみを使用することをお勧めします。Microsoft recommends using only one of the keys in all of your applications at the same time. キー 1 を使用する場所とキー 2 を使用する場所がある場合、キーを循環させるときに、一部のアプリケーションがアクセス権を失います。If you use Key 1 in some places and Key 2 in others, you will not be able to rotate your keys without some application losing access.


データ プレーンのセキュリティData Plane Security

データ プレーンのセキュリティとは、Azure Storage に格納されているデータ オブジェクト (BLOB、キュー、テーブル、ファイル) をセキュリティで保護するために使用される方法のことを指します。Data Plane Security refers to the methods used to secure the data objects stored in Azure Storage – the blobs, queues, tables, and files. これまで、データの転送中にデータを暗号化する方法とセキュリティについて説明してきましたが、オブジェクトへのアクセスを制御するにはどうすればよいのでしょうか。We've seen methods to encrypt the data and security during transit of the data, but how do you go about controlling access to the objects?

Azure Storage 内のデータ オブジェクトへのアクセスを承認するための 3 つのオプションがあります。You have three options for authorizing access to data objects in Azure Storage, including:

  • Azure AD を使用してコンテナーとキューへのアクセスを承認する。Using Azure AD to authorize access to containers and queues. 他の承認方法と比較した Azure AD の利点には、コード内にシークレットを格納する必要がないことが含まれます。Azure AD provides advantages over other approaches to authorization, including removing the need to store secrets in your code. 詳細については、「Azure Active Directory を使用して Azure Storage へのアクセスを認証する」を参照してください。For more information, see Authenticate access to Azure Storage using Azure Active Directory.
  • ストレージ アカウント キーを使用して、共有キーを介したアクセスを承認する。Using your storage account keys to authorize access via Shared Key. 共有キーを介した承認では、ストレージ アカウント キーをアプリケーション内に格納する必要があるため、可能であれば、代わりに Azure AD を使用することをお勧めします。Authorizing via Shared Key requires storing your storage account keys in your application, so Microsoft recommends using Azure AD instead where possible.
  • 共有アクセス署名を使用して、特定のデータ オブジェクトへの制御されたアクセス許可を特定の期間付与する。Using Shared Access Signatures to grant controlled permissions to specific data objects for a specific amount of time.

さらに、Blob Storage の場合、BLOB に対してパブリック アクセスを許可するには、その BLOB を保持するコンテナーのアクセス レベルを設定します。In addition, for Blob Storage, you can allow public access to your blobs by setting the access level for the container that holds the blobs accordingly. コンテナーから BLOB またはコンテナーに対するアクセス権を設定すると、そのコンテナー内の BLOB に対してパブリック読み取りアクセスが許可されます。If you set access for a container to Blob or Container, it will allow public read access for the blobs in that container. つまり、誰でも、そのコンテナー内の BLOB を指す URL をブラウザーで開くことができます。Shared Access Signature を使用する必要や、ストレージ アカウント キーを持っている必要はありません。This means anyone with a URL pointing to a blob in that container can open it in a browser without using a Shared Access Signature or having the storage account keys.

承認を使用してアクセスを制限する以外に、ファイアウォールと仮想ネットワークを使用し、ネットワーク ルールに基づいてストレージ アカウントへのアクセスを制限する方法もあります。In addition to limiting access through authorization, you can also use Firewalls and Virtual Networks to limit access to the storage account based on network rules. このアプローチを使用すると、パブリック インターネット トラフィックに対するアクセスを拒否し、特定の Azure Virtual Network またはパブリック インターネット IP アドレスの範囲にのみアクセスを許可することができます。This approach enables you deny access to public internet traffic, and to grant access only to specific Azure Virtual Networks or public internet IP address ranges.

ストレージ アカウント キーStorage Account Keys

ストレージ アカウント キーは、Azure で作成される 512 ビットの文字列です。ストレージ アカウント名と共に使用して、ストレージ アカウントに保存されているデータ オブジェクトへのアクセスに使用できます。Storage account keys are 512-bit strings created by Azure that, along with the storage account name, can be used to access the data objects stored in the storage account.

たとえば、BLOB の読み取り、キューへの書き込み、テーブルの作成、ファイルの変更などを行うことができます。For example, you can read blobs, write to queues, create tables, and modify files. このようなアクションの多くは、Azure ポータル、または数多くのストレージ エクスプローラー アプリケーションを使用して実行できます。Many of these actions can be performed through the Azure portal, or using one of many Storage Explorer applications. また、REST API またはストレージ クライアント ライブラリを使用してこれらの操作を実行するコードを作成することもできます。You can also write code to use the REST API or one of the Storage Client Libraries to perform these operations.

管理プレーンのセキュリティ」のセクションで説明したように、クラシック ストレージ アカウントでストレージ キーに対してアクセス権を付与するには、Azure サブスクリプションに対するフル アクセス権を付与します。As discussed in the section on the Management Plane Security, access to the storage keys for a Classic storage account can be granted by giving full access to the Azure subscription. Azure Resource Manager モデルを使用したストレージ アカウントのストレージ キーに対するアクセス権は、ロールベースのアクセス制御 (RBAC) で制御できます。Access to the storage keys for a storage account using the Azure Resource Manager model can be controlled through Role-Based Access Control (RBAC).

Shared Access Signature と Stored Access Policy を使用してアカウントのオブジェクトに対するアクセス権を委任する方法How to delegate access to objects in your account using Shared Access Signatures and Stored Access Policies

Shared Access Signature は、セキュリティ トークンを含む文字列です。セキュリティ トークンを URI にアタッチすることで、ストレージ オブジェクトへのアクセスを委任し、アクセス許可やアクセスの日時の範囲などの制約を指定することができます。A Shared Access Signature is a string containing a security token that can be attached to a URI that allows you to delegate access to storage objects and specify constraints such as the permissions and the date/time range of access.

BLOB、コンテナー、キュー メッセージ、ファイル、テーブルに対してアクセス権を付与できます。You can grant access to blobs, containers, queue messages, files, and tables. テーブルの場合、実際にテーブル内のエンティティの範囲に対してアクセス許可を付与するには、ユーザーにアクセス権を持たせるパーティションと行キーの範囲を指定します。With tables, you can actually grant permission to access a range of entities in the table by specifying the partition and row key ranges to which you want the user to have access. たとえば、地理的な状態のパーティション キーが格納されたデータがある場合、カリフォルニア州のデータに対するアクセス権のみを特定のユーザーに付与することができます。For example, if you have data stored with a partition key of geographical state, you could give someone access to just the data for California.

また、キューにエントリを書き込むことができる SAS トークンを Web アプリケーションに与え、キューからメッセージを取得して処理する SAS トークンを worker ロール アプリケーションに与えることもできます。In another example, you might give a web application a SAS token that enables it to write entries to a queue, and give a worker role application a SAS token to get messages from the queue and process them. また、Blob Storage 内のコンテナーに画像をアップロードするときに使用できる SAS トークンを 1 人のユーザーに与え、その画像を読み取るアクセス許可を Web アプリケーションに与えることもできます。Or you could give one customer a SAS token they can use to upload pictures to a container in Blob Storage, and give a web application permission to read those pictures. いずれの場合も、関係を分離できます。つまり、各アプリケーションには、タスクを実行するために必要なアクセス権のみを付与できます。In both cases, there is a separation of concerns – each application can be given just the access that they require in order to perform their task. この処理は Shared Access Signature を使用して実行できます。This is possible through the use of Shared Access Signatures.

Shared Access Signature を使用する理由Why you want to use Shared Access Signatures

ストレージ アカウント キーを付与するだけの方がはるかに簡単なのに、SAS を使用する理由はなぜでしょうか。Why would you want to use an SAS instead of just giving out your storage account key, which is so much easier? ストレージ アカウント キーの付与は、ストレージ王国の鍵を共有するようなものです。Giving out your storage account key is like sharing the keys of your storage kingdom. 完全なアクセス権が付与されます。It grants complete access. 自分のキーを誰かが使用すると、ストレージ アカウントに他人の音楽ライブラリ全体がアップロードされる可能性があります。Someone could use your keys and upload their entire music library to your storage account. また、ウイルスに感染したバージョンのファイルに置き換えられたり、データが盗用されたりする可能性があります。They could also replace your files with virus-infected versions, or steal your data. ストレージ アカウントに無制限のアクセス権を付与することは慎重に検討する必要があります。Giving away unlimited access to your storage account is something that should not be taken lightly.

Shared Access Signature を使用すると、一定時間、必要なアクセス許可のみをクライアントに付与できます。With Shared Access Signatures, you can give a client just the permissions required for a limited amount of time. たとえば、自分のアカウントに誰かが BLOB をアップロードする場合、BLOB のアップロードに必要な時間のみ、書き込みアクセス権を付与することができます (当然ながら、BLOB のサイズに応じて時間は変わります)。For example, if someone is uploading a blob to your account, you can grant them write access for just enough time to upload the blob (depending on the size of the blob, of course). また、気が変わったら、そのアクセス権を無効にすることができます。And if you change your mind, you can revoke that access.

さらに、SAS を使用して行われる要求を、Azure の外部の特定 IP アドレスまたは IP アドレスの範囲に制限することもできます。Additionally, you can specify that requests made using a SAS are restricted to a certain IP address or IP address range external to Azure. また、要求に特定のプロトコル (HTTPS または HTTP/HTTPS) を使用することを必須にすることもできます。You can also require that requests are made using a specific protocol (HTTPS or HTTP/HTTPS). つまり、HTTPS トラフィックのみを許可する場合、必須のプロトコルを HTTPS のみに設定することで、HTTP トラフィックをブロックすることができます。This means if you only want to allow HTTPS traffic, you can set the required protocol to HTTPS only, and HTTP traffic will be blocked.

Shared Access Signature の定義Definition of a Shared Access Signature

Shared Access Signature は、リソースを指す URL に付加するクエリ パラメーターのセットです。A Shared Access Signature is a set of query parameters appended to the URL pointing at the resource

許可されるアクセスに関する情報と、アクセスが許可される時間が指定されています。that provides information about the access allowed and the length of time for which the access is permitted. たとえば、次の URI は、BLOB に対して 5 分間の読み取りアクセス権を付与します。Here is an example; this URI provides read access to a blob for five minutes. SAS クエリ パラメーターは、URL エンコードする必要があります。たとえば、コロン (:) は %3A、スペースは %20 と指定します。Note that SAS query parameters must be URL Encoded, such as %3A for colon (:) or %20 for a space. (URL to the blob)
?sv=2015-04-05 (storage service version)
&st=2015-12-10T22%3A18%3A26Z (start time, in UTC time and URL encoded)
&se=2015-12-10T22%3A23%3A26Z (end time, in UTC time and URL encoded)
&sr=b (resource is a blob)
&sp=r (read access)
&sip= (requests can only come from this range of IP addresses)
&spr=https (only allow HTTPS requests)
&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D (signature used for the authentication of the SAS)

Azure Storage サービスで Shared Access Signature を承認する方法How the Shared Access Signature is authorized by the Azure Storage Service

Storage サービスが要求を受け取ると、入力クエリ パラメーターを取得し、呼び出し元プログラムと同じ方法で署名を作成します。When the storage service receives the request, it takes the input query parameters and creates a signature using the same method as the calling program. 次に、2 つの署名を比較します。It then compares the two signatures. 一致する場合、ストレージ サービスでは、ストレージ サービスのバージョンをチェックする、有効であることを確認する、現在の日時が指定した期間内であることを検証する、要求されたアクセス権が実行された要求に対応していることを確認するなどの処理を実行できます。If they agree, then the storage service can check the storage service version to make sure it's valid, verify that the current date and time are within the specified window, make sure the access requested corresponds to the request made, etc.

たとえば、上記の URL で、URL が BLOB ではなくファイルを指していた場合、Shared Access Signature が BLOB 用と指定されているため、この要求は失敗します。For example, with our URL above, if the URL was pointing to a file instead of a blob, this request would fail because it specifies that the Shared Access Signature is for a blob. BLOB を更新する REST コマンドが呼び出された場合、Shared Access Signature は読み取りアクセス権のみを付与することを指定しているので、コマンドは失敗します。If the REST command being called was to update a blob, it would fail because the Shared Access Signature specifies that only read access is permitted.

Shared Access Signature の種類Types of Shared Access Signatures

  • サービスレベルの SAS を使用して、ストレージ アカウントの特定のリソースにアクセスできます。A service-level SAS can be used to access specific resources in a storage account. たとえば、コンテナー内の BLOB 一覧を取得する、BLOB をダウンロードする、テーブル内のエンティティを更新する、メッセージをキューに追加する、ファイルをファイル共有にアップロードするなどの操作です。Some examples of this are retrieving a list of blobs in a container, downloading a blob, updating an entity in a table, adding messages to a queue, or uploading a file to a file share.
  • アカウントレベルの SAS は、サービスレベルの SAS を使用できる任意のリソースへのアクセスに使用できます。An account-level SAS can be used to access anything that a service-level SAS can be used for. さらに、サービスレベルの SAS で許可されないリソースに対して、コンテナー、テーブル、キュー、ファイル共有を作成できる機能などの選択肢を与えることができます。Additionally, it can give options to resources that are not permitted with a service-level SAS, such as the ability to create containers, tables, queues, and file shares. また、一度で複数のサービスに対するアクセス権を指定することもできます。You can also specify access to multiple services at once. たとえば、ストレージ アカウントの BLOB とファイルの両方に対するアクセス権を誰かに付与することができます。For example, you might give someone access to both blobs and files in your storage account.

SAS URI の作成Creating a SAS URI

  1. URI をオンデマンドで作成し、毎回、すべてのクエリ パラメーターを定義することができます。You can create a URI on demand, defining all of the query parameters each time.

    これは柔軟性の高いアプローチですが、毎回の論理パラメーター セットが類似している場合は、Stored Access Policy を使用することをお勧めします。This approach is flexible, but if you have a logical set of parameters that are similar each time, using a Stored Access Policy is a better idea.

  2. Stored Access Policy は、1 つのコンテナー全体、ファイル共有全体、テーブル全体、またはキュー全体に対して作成できます。You can create a Stored Access Policy for an entire container, file share, table, or queue. また、作成する SAS URI の基礎として、Stored Access Policy を使用できます。Then you can use this as the basis for the SAS URIs you create. Stored Access Policy に基づくアクセス許可は、簡単に無効にすることができます。Permissions based on Stored Access Policies can be easily revoked. コンテナー、キュー、テーブル、またはファイル共有ごとに、最大 5 個のポリシーを定義できます。You can have up to five policies defined on each container, queue, table, or file share.

    たとえば、特定のコンテナー内の BLOB を多数のユーザーが読み取る場合、"読み取りアクセス権を付与する" という Stored Access Policy を作成し、他の設定も毎回同じようにすることができます。For example, if you were going to have many people read the blobs in a specific container, you could create a Stored Access Policy that says "give read access" and any other settings that will be the same each time. 次に、Stored Access Policy の設定を使用し、有効期限の日時を指定して SAS URI を作成できます。Then you can create an SAS URI using the settings of the Stored Access Policy and specifying the expiration date/time. この方法の利点は、毎回すべてのクエリ パラメーターを指定する必要がないことです。The advantage of this is that you don't have to specify all of the query parameters every time.


たとえば、SAS が侵害された場合や、企業のセキュリティや規制への準拠要件のために SAS を変更する場合があるとします。Suppose your SAS has been compromised, or you want to change it because of corporate security or regulatory compliance requirements. その SAS を使用するリソースに対するアクセス権を無効にするには、どうすればよいでしょうか。How do you revoke access to a resource using that SAS? 無効にする方法は SAS URI を作成した方法によって変わります。It depends on how you created the SAS URI.

その場限りの URI を使用している場合、次の 3 つの選択肢があります。If you are using ad hoc URIs, you have three options. 有効期間ポリシーが短い SAS トークンを発行し、SAS が期限切れになるまで待つ方法、You can issue SAS tokens with short expiration policies and wait for the SAS to expire. リソースの名前を変更したり、削除したりする方法 (トークンのスコープが 1 つのオブジェクトに指定されていると仮定)、You can rename or delete the resource (assuming the token was scoped to a single object). そして、ストレージ アカウント キーを変更する方法です。You can change the storage account keys. この最後の選択肢は、そのストレージ アカウントを使用しているサービス数によっては大きな影響があるので、おそらく計画なしで実行するような選択肢ではありません。This last option can have a significant impact, depending on how many services are using that storage account, and probably isn't something you want to do without some planning.

Stored Access Policy から派生した SAS を使用している場合、Stored Access Policy を無効にすることで、アクセス権を削除することができます。無効にするには、既に期限切れになっているように変更したり、削除したりすることができます。If you are using a SAS derived from a Stored Access Policy, you can remove access by revoking the Stored Access Policy – you can just change it so it has already expired, or you can remove it altogether. この処理は即時に有効になり、その Stored Access Policy を使用して作成したすべての SAS は無効になります。This takes effect immediately, and invalidates every SAS created using that Stored Access Policy. Stored Access Policy を更新または削除すると、SAS 経由でそのコンテナー、ファイル共有、テーブル、またはキューにアクセスするユーザーに影響が及ぶ可能性がありますが、古い SAS が無効になったときに新しい SAS を要求するようにクライアントを作成すると、問題なく動作するようになります。Updating or removing the Stored Access Policy may impact people accessing that specific container, file share, table, or queue via SAS, but if the clients are written so they request a new SAS when the old one becomes invalid, this will work fine.

Stored Access Policy から派生した SAS を使用すると、その SAS を即時に無効にすることができるので、可能な限り常に Stored Access Policy を使用するベスト プラクティスが推奨されます。Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.


Shared Access Signature と Stored Access Policy の詳しい使用方法と例については、次の記事をご覧ください。For more detailed information on using Shared Access Signatures and Stored Access Policies, complete with examples, refer to the following articles:

転送中の暗号化Encryption in Transit

トランスポートレベルの暗号化 - HTTPS の使用Transport-Level Encryption – Using HTTPS

Azure Storage データのセキュリティを確保するために推奨されるもう 1 つの手順は、クライアントと Azure Storage 間のデータを暗号化することです。Another step you should take to ensure the security of your Azure Storage data is to encrypt the data between the client and Azure Storage. 最初の推奨事項は、 HTTPS プロトコルを常に使用して、パブリック インターネット上の安全な通信を確保することです。The first recommendation is to always use the HTTPS protocol, which ensures secure communication over the public Internet.

REST API を呼び出すときや、ストレージ内のオブジェクトにアクセスするときは、通信チャネルの安全性を確保するために、常に HTTPS を使用することをお勧めします。To have a secure communication channel, you should always use HTTPS when calling the REST APIs or accessing objects in storage. また、Azure Storage オブジェクトへのアクセス権を委任するときに使用できる Shared Access Signatureには、Shared Access Signature の使用時には HTTPS プロトコルのみを使用できると指定するオプションがあるので、誰でも SAS トークンを指定したリンクを送信すると適切なプロトコルが使用されます。Also, Shared Access Signatures, which can be used to delegate access to Azure Storage objects, include an option to specify that only the HTTPS protocol can be used when using Shared Access Signatures, ensuring that anybody sending out links with SAS tokens will use the proper protocol.

ストレージ アカウントの [安全な転送が必須] を有効にすると、ストレージ アカウント内のオブジェクトにアクセスするための REST API を呼び出す際に HTTPS の使用を強制することができます。You can enforce the use of HTTPS when calling the REST APIs to access objects in storage accounts by enabling Secure transfer required for the storage account. このオプションを有効にすると、HTTP を使った接続は拒否されます。Connections using HTTP will be refused once this is enabled.

Azure ファイル共有での転送中の暗号化の使用Using encryption during transit with Azure file shares

Azure Files では、File REST API の使用時に、SMB 3.0 による暗号化と HTTPS の使用をサポートします。Azure Files supports encryption via SMB 3.0 and with HTTPS when using the File REST API. Azure ファイル共有が配置されている Azure リージョン以外の場所 (オンプレミスや別の Azure リージョンなど) でマウントを行う場合は、SMB 3.0 による暗号化が常に必要です。When mounting outside of the Azure region the Azure file share is located in, such as on-premises or in another Azure region, SMB 3.0 with encryption is always required. SMB 2.1 は暗号化をサポートしていないため、同じ Azure リージョン内では既定の接続のみが許可されますが、ストレージ アカウントに対するセキュリティで保護された転送を要求することで、SMB 3.0 による暗号化を使用できます。SMB 2.1 does not support encryption, so by default connections are only allowed within the same region in Azure, but SMB 3.0 with encryption can be enforced by requiring secure transfer for the storage account.

SMB 3.0 による暗号化は、Windows 7 と Windows Server 2008 R2 を除くすべてのサポートされている Windows および Windows Server オペレーティング システムで利用できます (Windows 7 と Windows Server 2008 R2 では SMB 2.1 のみがサポートされます)。SMB 3.0 with encryption is available in all supported Windows and Windows Server operating systems except Windows 7 and Windows Server 2008 R2, which only support SMB 2.1. SMB 3.0 は、macOS と、Linux カーネル 4.11 以降を使用している Linux のディストリビューションでもサポートされます。SMB 3.0 is also supported on macOS and on distributions of Linux using Linux kernel 4.11 and above. SMB 3.0 による暗号化のサポートは、複数の Linux ディストリビューションによって、Linux カーネルの古いバージョンにも移植されています。SMB クライアントの要件に関する記事を参照してください。Encryption support for SMB 3.0 has also been backported to older versions of the Linux kernel by several Linux distributions, consult Understanding SMB client requirements.

クライアント側の暗号化を使用してストレージに送信するデータをセキュリティで保護するUsing Client-side encryption to secure data that you send to storage

クライアント アプリケーションと Storage 間でデータが転送されるときにセキュリティで保護するためのもう 1 つのオプションは、クライアント側の暗号化です。Another option that helps you ensure that your data is secure while being transferred between a client application and Storage is Client-side Encryption. データは暗号化されてから、Azure Storage に転送されます。The data is encrypted before being transferred into Azure Storage. Azure Storage からデータを取得するときは、クライアント側で受け取った後にデータが暗号化されます。When retrieving the data from Azure Storage, the data is decrypted after it is received on the client side. データの転送時に暗号化される場合でも、HTTPS も使用することをお勧めします。データ整合性チェックが組み込まれるので、データの整合性に影響があるネットワーク エラーを軽減することができます。Even though the data is encrypted going across the wire, we recommend that you also use HTTPS, as it has data integrity checks built in which help mitigate network errors affecting the integrity of the data.

クライアント側の暗号化は、データが暗号化された形式で保存されるので、保存データを暗号化する方法でもあります。Client-side encryption is also a method for encrypting your data at rest, as the data is stored in its encrypted form. 詳細については、「 保存時の暗号化」で説明します。We'll talk about this in more detail in the section on Encryption at Rest.

保存時の暗号化Encryption at Rest

Azure には、保存時の暗号化を提供する機能が 3 つあります。There are three Azure features that provide encryption at rest. Azure Disk Encryption は、IaaS Virtual Machines の OS ディスクとデータ ディスクの暗号化に使用されます。Azure Disk Encryption is used to encrypt the OS and data disks in IaaS Virtual Machines. クライアント側の暗号化と SSE は、どちらも Azure Storage 内のデータの暗号化に使用されます。Client-side Encryption and SSE are both used to encrypt data in Azure Storage.

クライアント側の暗号化を使用して転送中のデータ (Storage に暗号化された形式でも保存されます) を暗号化する場合、転送中は HTTPS を使用し、保存時は自動的にデータを暗号化するという方法もあります。While you can use Client-side Encryption to encrypt the data in transit (which is also stored in its encrypted form in Storage), you may prefer to use HTTPS during the transfer, and have some way for the data to be automatically encrypted when it is stored. この処理には、Azure Disk Encryption と SSE という 2 つの方法があります。There are two ways to do this -- Azure Disk Encryption and SSE. 前者は、OS 上のデータや VM に使用されるデータ ディスク上のデータを直接暗号化するために使用され、後者は、Azure Blob Storage に書き込まれたデータを暗号化するために使用されます。One is used to directly encrypt the data on OS and data disks used by VMs, and the other is used to encrypt data written to Azure Blob Storage.

Storage Service Encryption (SSE)Storage Service Encryption (SSE)

SSE は、すべてのストレージ アカウントに対して有効になり、無効にすることはできません。SSE is enabled for all storage accounts and cannot be disabled. SSE は、Azure Storage への書き込み時にデータを自動的に暗号化します。SSE automatically encrypts your data when writing it to Azure Storage. Azure Storage からデータを読み取ると、Azure Storage によって復号化されてから返されます。When you read data from Azure Storage, it is decrypted by Azure Storage before being returned. SSE を使用すると、コードを変更したり、アプリケーションにコードを追加したりする必要なしにデータをセキュリティで保護できます。SSE enables you to secure your data without having to modify code or add code to any applications.

Microsoft 管理キーまたは独自のカスタム キーを使用できます。You can use either Microsoft-managed keys or your own custom keys. Microsoft は、Microsoft の社内ポリシーの定義に従って管理キーを生成し、キーの安全な保存と定期的な循環を処理しています。Microsoft generates managed keys and handles their secure storage as well as their regular rotation, as defined by internal Microsoft policy. カスタム キーを使用する方法の詳細については、Azure Key Vault のユーザー管理キーを使用した Storage Service Encryption に関するページを参照してください。For more information about using custom keys, see Storage Service Encryption using customer-managed keys in Azure Key Vault.

SSE は、すべてのパフォーマンス レベル (Standard および Premium)、すべてのデプロイ モデル (Azure Resource Manager とクラシック)、すべての Azure Storage サービス (BLOB、Queue、Table、File) のデータを自動的に暗号化します。SSE automatically encrypts data in all performance tiers (Standard and Premium), all deployment models (Azure Resource Manager and Classic), and all of the Azure Storage services (Blob, Queue, Table, and File).

クライアント側の暗号化Client-side Encryption

転送中のデータの暗号化について説明した際に、クライアント側の暗号化について触れました。We mentioned client-side encryption when discussing the encryption of the data in transit. この機能を使用すると、クライアント アプリケーションのデータをプログラムで暗号化してからネットワーク経由で送信し、Azure Storage に書き込むことができます。また、Azure Storage から取得した後にプログラムでデータを復号化することができます。This feature allows you to programmatically encrypt your data in a client application before sending it across the wire to be written to Azure Storage, and to programmatically decrypt your data after retrieving it from Azure Storage.

クライアント側の暗号化には、転送中の暗号化機能だけでなく、保存時の暗号化機能があります。This does provide encryption in transit, but it also provides the feature of Encryption at Rest. 転送中にデータは暗号化されますが、それでも HTTPS を使用して組み込みのデータ整合性チェックを利用することをお勧めします。それによって、データの整合性に影響があるネットワーク エラーを軽減できます。Although the data is encrypted in transit, we still recommend using HTTPS to take advantage of the built-in data integrity checks that help mitigate network errors affecting the integrity of the data.

使用例として、BLOB を保存し、BLOB を取得する Web アプリケーションがあり、アプリケーションとデータを可能な限りセキュリティで保護する場合があります。An example of where you might use this is if you have a web application that stores blobs and retrieves blobs, and you want the application and data to be as secure as possible. このような場合は、クライアント側の暗号化を使用します。In that case, you would use client-side encryption. クライアントと Azure BLOB サービス間のトラフィックには暗号化されたリソースが含まれており、他のユーザーは、転送中のデータを解釈してプライベート BLOB に再構成することはできません。The traffic between the client and the Azure Blob Service contains the encrypted resource, and nobody can interpret the data in transit and reconstitute it into your private blobs.

クライアント側の暗号化は Java と .NET ストレージ クライアント ライブラリに組み込まれているので、Azure Key Vault API を使用して簡単に実装できます。Client-side encryption is built into the Java and the .NET storage client libraries, which in turn use the Azure Key Vault APIs, making it easy for you to implement. データを暗号化および復号化するプロセスには、エンベロープ技術が使用され、暗号化に使用されたメタデータは各ストレージ オブジェクトに保存されます。The process of encrypting and decrypting the data uses the envelope technique, and stores metadata used by the encryption in each storage object. たとえば、BLOB の場合は BLOB のメタデータに保存され、キューの場合は各キュー メッセージに追加されます。For example, for blobs, it stores it in the blob metadata, while for queues, it adds it to each queue message.

暗号化の場合、独自の暗号化キーを生成し、管理することができます。For the encryption itself, you can generate and manage your own encryption keys. また、Azure ストレージ クライアント ライブラリで生成されたキーを使用することや、Azure Key Vault からキーを生成することもできます。You can also use keys generated by the Azure Storage Client Library, or you can have the Azure Key Vault generate the keys. オンプレミスのキー ストレージに暗号化キーを保存することや、Azure Key Vault に保存することができます。You can store your encryption keys in your on-premises key storage, or you can store them in an Azure Key Vault. Azure Key Vault では、Azure Active Directory を使用して、Azure Key Vault のシークレットに対するアクセス権を特定のユーザーに付与できます。Azure Key Vault allows you to grant access to the secrets in Azure Key Vault to specific users using Azure Active Directory. つまり、誰でも Azure Key Vault を読み取ることができるだけでなく、クライアント側の暗号化に使用しているキーを取得することもできます。This means that not just anybody can read the Azure Key Vault and retrieve the keys you're using for client-side encryption.


Azure Disk Encryption を使用して仮想マシンに使用されるディスクを暗号化するUsing Azure Disk Encryption to encrypt disks used by your virtual machines

Azure Disk Encryption を使用すると、IaaS 仮想マシンによって使用される OS ディスクとデータ ディスクを暗号化できます。Azure Disk Encryption allows you to encrypt the OS disks and Data disks used by an IaaS Virtual Machine. Windows の場合、ドライブの暗号化には、業界標準の BitLocker 暗号化テクノロジが使用されます。For Windows, the drives are encrypted using industry-standard BitLocker encryption technology. Linux の場合、ディスクの暗号化には DM-Crypt テクノロジが使用されます。For Linux, the disks are encrypted using the DM-Crypt technology. DM-Crypt は Azure Key Vault と統合されているので、ディスクの暗号化キーを制御および管理できます。This is integrated with Azure Key Vault to allow you to control and manage the disk encryption keys.

このソリューションでは、Microsoft Azure で有効にした場合、IaaS VM の以下のシナリオがサポートされます。The solution supports the following scenarios for IaaS VMs when they are enabled in Microsoft Azure:

  • Azure Key Vault との統合Integration with Azure Key Vault
  • Standard レベルの VM: A、D、DS、G、GS などの IaaS VM シリーズStandard tier VMs: A, D, DS, G, GS, and so forth series IaaS VMs
  • Windows および Linux IaaS VM の暗号化を有効にするEnabling encryption on Windows and Linux IaaS VMs
  • Windows IaaS VM の OS およびデータ ドライブの暗号化を無効にするDisabling encryption on OS and data drives for Windows IaaS VMs
  • Linux IaaS VM のデータ ドライブの暗号化を無効にするDisabling encryption on data drives for Linux IaaS VMs
  • Windows クライアント OS を実行している IaaS VM の暗号化を有効にするEnabling encryption on IaaS VMs that are running Windows client OS
  • ボリュームのマウント パスの暗号化を有効にするEnabling encryption on volumes with mount paths
  • mdadm を使用してディスク ストライピング (RAID) が構成されている Linux VM の暗号化を有効にするEnabling encryption on Linux VMs that are configured with disk striping (RAID) by using mdadm
  • データ ディスクの LVM を使用して Linux VM の暗号化を有効にするEnabling encryption on Linux VMs by using LVM for data disks
  • ストレージ スペースを使用して構成されている Windows VM の暗号化を有効にするEnabling encryption on Windows VMs that are configured by using storage spaces
  • Azure のすべてのパブリック リージョンがサポートされるAll Azure public regions are supported

このソリューションの現在のリリースでは、以下のシナリオ、機能、およびテクノロジはサポートされていません。The solution does not support the following scenarios, features, and technology in the release:

  • Basic レベルの IaaS VMBasic tier IaaS VMs
  • Linux IaaS VM の OS ドライブの暗号化を無効にするDisabling encryption on an OS drive for Linux IaaS VMs
  • 従来の VM の作成方法を使用して作成された IaaS VMIaaS VMs that are created by using the classic VM creation method
  • オンプレミス キー管理サービスとの統合Integration with your on-premises Key Management Service
  • Azure Files (共有ファイル システム)、ネットワーク ファイル システム (NFS)、ダイナミック ボリューム、およびソフトウェアベースの RAID システムで構成されている Windows VMAzure Files (shared file system), Network File System (NFS), dynamic volumes, and Windows VMs that are configured with software-based RAID systems


現時点では、Linux OS ディスク暗号化は、RHEL 7.2、CentOS 7.2n、および Ubuntu 16.04 の Linux ディストリビューションでサポートされています。Linux OS disk encryption is currently supported on the following Linux distributions: RHEL 7.2, CentOS 7.2n, and Ubuntu 16.04.

この機能を使用すると、仮想マシン ディスクのすべてのデータは Azure Storage に保存中に暗号化されます。This feature ensures that all data on your virtual machine disks is encrypted at rest in Azure Storage.


Azure Disk Encryption、SSE、クライアント側の暗号化の比較Comparison of Azure Disk Encryption, SSE, and Client-Side Encryption

IaaS VM とその VHD ファイルIaaS VMs and their VHD files

IaaS VM で使用されるデータ ディスクには、Azure Disk Encryption をお勧めします。For data disks used by IaaS VMs, Azure Disk Encryption is recommended. Azure Marketplace のイメージを使用して非管理対象ディスクを使用している VM を作成する場合、Azure は Azure Storage のストレージ アカウントにイメージのシャロー コピーを実行し、SSE を有効にしている場合でも、イメージが暗号化されません。If you create a VM with unmanaged disks using an image from the Azure Marketplace, Azure performs a shallow copy of the image to your storage account in Azure Storage, and it is not encrypted even if you have SSE enabled. VM を作成し、イメージの更新を開始すると、SSE はデータの暗号化を開始します。After it creates the VM and starts updating the image, SSE will start encrypting the data. そのため、完全に暗号化するには、Azure Marketplace のイメージから作成した非管理対象ディスクを使用した VM で Azure Disk Encryption を使用することをお勧めします。For this reason, it's best to use Azure Disk Encryption on VMs with unmanaged disks created from images in the Azure Marketplace if you want them fully encrypted. 管理対象ディスクで VM を作成した場合、プラットフォームで管理されるキーを使用して SSE によって既定ですべてのデータが暗号化されます。If you create a VM with Managed Disks, SSE encrypts all the data by default using platform managed keys.

事前に暗号化した VM をオンプレミスから Azure に移行する場合、暗号化キーを Azure Key Vault にアップロードし、オンプレミスで使用していた VM に引き続き暗号化を使用できるようになります。If you bring a pre-encrypted VM into Azure from on-premises, you will be able to upload the encryption keys to Azure Key Vault, and continue using the encryption for that VM that you were using on-premises. Azure Disk Encryption を有効にすると、このシナリオに対応できます。Azure Disk Encryption is enabled to handle this scenario.

オンプレミスの暗号化されていない VHD がある場合、カスタム イメージとしてギャラリーにアップロードし、そこから VM をプロビジョニングできます。If you have non-encrypted VHD from on-premises, you can upload it into the gallery as a custom image and provision a VM from it. この処理に Resource Manager テンプレートを使用する場合、VM の起動時に Azure Disk Encryption を有効にするように指示できます。If you do this using the Resource Manager templates, you can ask it to turn on Azure Disk Encryption when it boots up the VM.

データ ディスクを追加し、VM にマウントするときに、そのデータ ディスクで Azure Disk Encryption を有効にすることができます。When you add a data disk and mount it on the VM, you can turn on Azure Disk Encryption on that data disk. 有効にすると、まずそのデータ ディスクがローカルで暗号化され、クラシック デプロイ モデル レイヤーでストレージに対して遅延書き込みが行われるので、ストレージ コンテンツは暗号化されます。It will encrypt that data disk locally first, and then the classic deployment model layer will do a lazy write against storage so the storage content is encrypted.

クライアント側暗号化Client-side encryption

クライアント側の暗号化は、転送前にデータが暗号化されるため、データを暗号化する上で最も安全な方法です。Client-side encryption is the most secure method of encrypting your data, because it encrypts data prior to transit. ただし、ストレージを使用してアプリケーションにコードを追加する必要があります。However, it does require that you add code to your applications using storage, which you may not want to do. このような場合は、HTTPS を使用して転送中にデータをセキュリティで保護できます。In those cases, you can use HTTPS to secure your data in transit. データが Azure Storage に到達すると、SSE によって暗号化されます。Once data reaches Azure Storage, it is encrypted by SSE.

クライアント側の暗号化では、テーブル エンティティ、キュー メッセージ、BLOB を暗号化できます。With client-side encryption, you can encrypt table entities, queue messages, and blobs.

クライアント側の暗号化は、アプリケーションによって完全に管理されています。Client-side encryption is managed entirely by the application. これが最も安全なアプローチですが、アプリケーションのプログラムを変更し、キー管理プロセスを組み込む必要があります。This is the most secure approach, but does require you to make programmatic changes to your application and put key management processes in place. 転送中にセキュリティを向上する場合、および保存されているデータを暗号化する場合に利用してください。You would use this when you want the extra security during transit, and you want your stored data to be encrypted.

クライアント側の暗号化は、クライアントにかかる負荷が増加するため、スケーラビリティの計画でこの点を考慮する必要があります。特に、大量のデータを暗号化したり転送したりする場合に重要です。Client-side encryption is more load on the client, and you have to account for this in your scalability plans, especially if you are encrypting and transferring a large amount of data.

Storage Service Encryption (SSE)Storage Service Encryption (SSE)

SSE は Azure Storage で管理されます。SSE is managed by Azure Storage. SSE では転送中のデータはセキュリティで保護されませんが、Azure Storage に書き込まれるときのデータは暗号化されます。SSE does not provide for the security of the data in transit, but it does encrypt the data as it is written to Azure Storage. SSE は、Azure Storage のパフォーマンスに影響しません。SSE does not affect Azure Storage performance.

SSE を使用して、ストレージ アカウントのあらゆる種類のデータ (ブロック BLOB、追加 BLOB、ページ BLOB、テーブル データ、キュー データ、およびファイル) を暗号化できます。You can encrypt any kind of data of the storage account using SSE (block blobs, append blobs, page blobs, table data, queue data, and files).

新しい仮想マシンを作成する際の基礎として使用する VHD ファイルのアーカイブまたはライブラリがある場合、新しいストレージ アカウントを作成してから、VHD ファイルをそのアカウントにアップロードします。If you have an archive or library of VHD files that you use as a basis for creating new virtual machines, you can create a new storage account and then upload the VHD files to that account. これらの VHD ファイルは Azure Storage によって暗号化されます。Those VHD files will be encrypted by Azure Storage.

VM 内のディスクに対して Azure Disk Encryption が有効になっている場合、新規に書き込まれるデータは SSE と Azure Disk Encryption の両方で暗号化されます。If you have Azure Disk Encryption enabled for the disks in a VM, then any newly written data is encrypted both by SSE and by Azure Disk Encryption.

Storage AnalyticsStorage Analytics

Storage Analytics を使用して承認の種類を監視するUsing Storage Analytics to monitor authorization type

各ストレージ アカウントで、Azure Storage Analytics を有効にして、ログを実行し、メトリック データを保存することができます。For each storage account, you can enable Azure Storage Analytics to perform logging and store metrics data. ストレージ アカウントのパフォーマンス メトリックを確認する場合や、パフォーマンスの問題についてストレージ アカウントのトラブルシューティングを行う必要がある場合に便利なツールです。This is a great tool to use when you want to check the performance metrics of a storage account, or need to troubleshoot a storage account because you are having performance problems.

Storage Analytics ログで確認できるもう 1 つのデータは、誰かがストレージにアクセスするときに使用される認証方法です。Another piece of data you can see in the storage analytics logs is the authentication method used by someone when they access storage. たとえば、Blob Storage では、使用されたのが Shared Access Signature かストレージ アカウント キーか、またはアクセスされた BLOB がパブリックかどうかが確認できます。For example, with Blob Storage, you can see if they used a Shared Access Signature or the storage account keys, or if the blob accessed was public.

ストレージへのアクセスを厳密に保護する場合、この方法が推奨されます。This can be helpful if you are tightly guarding access to storage. たとえば、Blob Storage では、すべてのコンテナーを非公開に設定し、アプリケーション全体で SAS サービスの使用を実装できます。For example, in Blob Storage you can set all of the containers to private and implement the use of an SAS service throughout your applications. 次に、ログを定期的にチェックし、BLOB がストレージ アカウント キーを使用してアクセスされたか (セキュリティ違反が発生している可能性があります)、パブリックにすべきではない BLOB がパブリックであるかどうかを確認します。Then you can check the logs regularly to see if your blobs are accessed using the storage account keys, which may indicate a breach of security, or if the blobs are public but they shouldn't be.

ログに記録される情報What do the logs look like?

Azure ポータルでストレージ アカウントのメトリックとログ処理を有効にすると、分析データの蓄積がすばやく開始されます。After you enable the storage account metrics and logging through the Azure portal, analytics data will start to accumulate quickly. 各サービスのログとメトリックは別のものです。ログは、そのストレージ アカウントでアクティビティがある場合にのみ書き込まれます。また、メトリックは、構成方法に応じて 1 分、1 時間、または 1 日ごとにログに記録されます。The logging and metrics for each service is separate; the logging is only written when there is activity in that storage account, while the metrics will be logged every minute, every hour, or every day, depending on how you configure it.

ログは、ストレージ アカウントの $logs というコンテナーのブロック BLOB に保存されます。The logs are stored in block blobs in a container named $logs in the storage account. このコンテナーは、Storage Analytics を有効にすると自動的に作成されます。This container is automatically created when Storage Analytics is enabled. このコンテナーが作成された後にコンテナーを削除することはできませんが、コンテナーの内容を削除することはできます。Once this container is created, you can't delete it, although you can delete its contents.

$logs コンテナーには、各サービスのフォルダーがあります。また、年/月/日/時間のサブフォルダーがあります。Under the $logs container, there is a folder for each service, and then there are subfolders for the year/month/day/hour. 時間フォルダーでは、ログに番号が付けられます。Under hour, the logs are numbered. これでディレクトリ構造は次のようになります。This is what the directory structure will look like:

ログ ファイルの表示

Azure Storage に対するすべての要求がログに記録されます。Every request to Azure Storage is logged. 次の図は、先頭の数フィールドが表示されたログ ファイルのスナップショットです。Here's a snapshot of a log file, showing the first few fields.

ログ ファイルのスナップショット

ログを使用して、ストレージ アカウントに対する任意の種類の呼び出しを追跡できることがわかります。You can see that you can use the logs to track any kind of calls to a storage account.

各フィールドの役割What are all of those fields for?

以下のリソースに記載されている記事には、ログの多数のフィールドとその役割の一覧が含まれています。There is an article listed in the resources below that provides the list of the many fields in the logs and what they are used for. フィールドを一覧の順に説明します。Here is the list of fields in order:

ログ ファイル内のフィールドのスナップショット

ここでは、GetBlob のエントリとその承認方法を扱っているため、operation-type が "Get-Blob" であるエントリを探し、request-status (4 番目の列) と authorization-type (8 番目の列) をチェックする必要があります。We're interested in the entries for GetBlob, and how they are authorized, so we need to look for entries with operation-type "Get-Blob", and check the request-status (fourth column) and the authorization-type (eighth column).

たとえば、上の一覧の先頭数行では、request-status は "Success"、authorization-type は "authenticated" です。For example, in the first few rows in the listing above, the request-status is "Success" and the authorization-type is "authenticated". つまり、要求はストレージ アカウント キーを使用して承認されています。This means the request was authorized using the storage account key.

承認されている BLOB へのアクセス方法How is access to my blobs being authorized?

ここでは、3 つの事例について扱っています。We have three cases that we are interested in.

  1. BLOB がパブリックであり、Shared Access Signature を使用せずに、URL を使用してアクセスできます。The blob is public and it is accessed using a URL without a Shared Access Signature. この場合、request-status は "AnonymousSuccess" であり、authorization-type は "anonymous" です。In this case, the request-status is "AnonymousSuccess" and the authorization-type is "anonymous".


  2. BLOB は非公開であり、Shared Access Signature で使用されました。The blob is private and was used with a Shared Access Signature. この場合、request-status は "SASSuccess" であり、authorization-type は "sas" です。In this case, the request-status is "SASSuccess" and the authorization-type is "sas".


  3. BLOB は非公開であり、ストレージ キーを使用してアクセスされました。The blob is private and the storage key was used to access it. この場合、request-status は "Success" であり、authorization-type は "authenticated" です。In this case, the request-status is "Success" and the authorization-type is "authenticated".


Microsoft Message Analyzer を使用してログを表示し、分析することができます。You can use the Microsoft Message Analyzer to view and analyze these logs. このツールには検索機能とフィルター機能があります。It includes search and filter capabilities. たとえば、GetBlob のインスタンスを検索して、使用方法が想定どおりかどうかを確認し、自分のストレージ アカウントにだれかが不正アクセスしていないことを確認することができます。For example, you might want to search for instances of GetBlob to see if the usage is what you expect, that is, to make sure someone is not accessing your storage account inappropriately.


クロスオリジン リソース共有 (CORS)Cross-Origin Resource Sharing (CORS)

リソースのクロスドメイン アクセスCross-domain access of resources

1 つのドメインで実行されている Web ブラウザーで、異なるドメインのリソースに対して HTTP 要求を実行すると、クロスオリジン HTTP 要求と呼ばれます。When a web browser running in one domain makes an HTTP request for a resource from a different domain, this is called a cross-origin HTTP request. たとえば、 から提供される HTML ページでは、 にホストされている JPEG に対して要求を実行します。For example, an HTML page served from makes a request for a jpeg hosted on セキュリティ上の理由から、ブラウザーは、スクリプト (JavaScript など) から開始されるクロスオリジンの HTTP 要求を制限します。For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts, such as JavaScript. つまり、 上の Web ページで実行される一部の JavaScript コードで、 でその JPEG を要求すると、ブラウザーはその要求を許可しません。This means that when some JavaScript code on a web page on requests that jpeg on, the browser will not allow the request.

Azure Storage には、どのような処理が必要でしょうか。What does this have to do with Azure Storage? JSON、XML データ ファイルなどの静的な資産を、Fabrikam というストレージ アカウントを使用して Blob Storage に格納する場合、資産のドメインは になり、 の Web アプリケーションは、ドメインが異なるので、JavaScript を使用してアクセスできなくなります。Well, if you are storing static assets such as JSON or XML data files in Blob Storage using a storage account called Fabrikam, the domain for the assets will be, and the web application will not be able to access them using JavaScript because the domains are different. また、いずれかの Azure Storage サービス (Table Storage など) を呼び出して、JavaScript クライアントで処理される JSON データを返す場合にも当てはまります。This is also true if you're trying to call one of the Azure Storage Services – such as Table Storage – that return JSON data to be processed by the JavaScript client.

考えられる解決策Possible solutions

この問題を解決する 1 つの方法は、"" のようなカスタム ドメインを に割り当てることです。One way to resolve this is to assign a custom domain like "" to 問題は、そのカスタム ドメインを割り当てることができるのは、1 つのストレージ アカウントのみという点です。The problem is that you can only assign that custom domain to one storage account. 資産が複数のストレージ アカウントに格納されている場合はどうなるでしょうか。What if the assets are stored in multiple storage accounts?

この問題を解決するもう 1 つの方法は、Web アプリケーションがストレージ呼び出しの際にプロキシとして動作するようにすることです。Another way to resolve this is to have the web application act as a proxy for the storage calls. つまり、ファイルを Blob Storage にアップロードすると、Web アプリケーションがローカルで書き込み、それを Blob Storage にコピーしたり、すべてをメモリに読み込んで Blob Storage に書き込んだりすることができます。This means if you are uploading a file to Blob Storage, the web application would either write it locally and then copy it to Blob Storage, or it would read all of it into memory and then write it to Blob Storage. また、ファイルをローカルでアップロードし、Blob Storage に書き込む専用の Web アプリケーション (Web API など) を作成することもできます。Alternately, you could write a dedicated web application (such as a Web API) that uploads the files locally and writes them to Blob Storage. いずれの方法でも、スケーラビリティのニーズを決定するときにその機能を考慮する必要があります。Either way, you have to account for that function when determining the scalability needs.

CORS の機能How can CORS help?

Azure Storage では、CORS (クロス オリジン リソース共有) を有効にできます。Azure Storage allows you to enable CORS – Cross Origin Resource Sharing. ストレージ アカウントごとに、そのストレージ アカウントのリソースにアクセスできるドメインを指定できます。For each storage account, you can specify domains that can access the resources in that storage account. たとえば、前述の例のように、 ストレージ アカウントで CORS を有効にして、 へのアクセスを許可するように構成できます。For example, in our case outlined above, we can enable CORS on the storage account and configure it to allow access to 構成すると、Web アプリケーションの から、 のリソースに直接アクセスできるようになります。Then the web application can directly access the resources in

ただし、CORS でアクセスを許可できますが、認証機能はありません。認証機能は、ストレージ リソースのすべての非パブリック アクセスに必要です。One thing to note is that CORS allows access, but it does not provide authentication, which is required for all non-public access of storage resources. つまり、BLOB がパブリックの場合、または Shared Access Signature を含めて適切なアクセス許可を付与した場合にのみ、BLOB にアクセスできます。This means you can only access blobs if they are public or you include a Shared Access Signature giving you the appropriate permission. テーブル、キュー、ファイルにはパブリック アクセスがないので、SAS が必要です。Tables, queues, and files have no public access, and require a SAS.

既定では、すべてのサービスで CORS が無効です。By default, CORS is disabled on all services. CORS を有効にするには、REST API またはストレージ クライアント ライブラリを使用して、サービス ポリシーを設定するいずれかのメソッドを呼び出します。You can enable CORS by using the REST API or the storage client library to call one of the methods to set the service policies. この場合、XML 形式の CORS ルールを含めます。When you do that, you include a CORS rule, which is in XML. 次に、ストレージ アカウントの BLOB サービスで、サービス プロパティの設定操作を使用して設定した CORS ルールの例を示します。Here's an example of a CORS rule that has been set using the Set Service Properties operation for the Blob Service for a storage account. Azure Storage のストレージ クライアント ライブラリまたは REST API を使用してこの操作を実行できます。You can perform that operation using the storage client library or the REST APIs for Azure Storage.


各行の意味は次のとおりです。Here's what each row means:

  • AllowedOrigins 一致しないドメインのうち、Storage サービスに対して要求を実行し、データを受け取ることができるドメインを指示します。AllowedOrigins This tells which non-matching domains can request and receive data from the storage service. たとえば、 と の両方が、特定のストレージ アカウントに対して Blob Storage のデータを要求できます。This says that both and can request data from Blob Storage for a specific storage account. また、これをワイルドカード (*) に設定して、すべてのドメインが要求にアクセスできるようにすることもできます。You can also set this to a wildcard (*) to allow all domains to access requests.
  • AllowedMethods 要求を実行するときに使用できるメソッド (HTTP 要求の動詞) のリストです。AllowedMethods This is the list of methods (HTTP request verbs) that can be used when making the request. この例では、PUT と GET のみを使用できます。In this example, only PUT and GET are allowed. これをワイルドカード (*) に設定して、すべてのメソッドを使用できるようにすることができます。You can set this to a wildcard (*) to allow all methods to be used.
  • AllowedHeaders 元のドメインが要求の実行時に指定できる要求ヘッダーです。AllowedHeaders This is the request headers that the origin domain can specify when making the request. この例では、x-ms-meta-data、x-ms-meta-target、x-ms-meta-abc で始まるすべてのメタデータ ヘッダーが許可されます。In this example, all metadata headers starting with x-ms-meta-data, x-ms-meta-target, and x-ms-meta-abc are permitted. ワイルドカード文字 (*) は、指定したプレフィックスで始まるすべてのヘッダーが許可されることを示しています。The wildcard character (*) indicates that any header beginning with the specified prefix is allowed.
  • ExposedHeaders ブラウザーから要求の発行元に対して公開する必要がある応答ヘッダーを指示します。ExposedHeaders This tells which response headers should be exposed by the browser to the request issuer. この例では、"x-ms-meta-" から始まるすべてのヘッダーが公開されます。In this example, any header starting with "x-ms-meta-" will be exposed.
  • MaxAgeInSeconds ブラウザーがプレフライト OPTIONS 要求をキャッシュする最大時間です。MaxAgeInSeconds This is the maximum amount of time that a browser will cache the preflight OPTIONS request. (プレフライト要求の詳細については、以下の最初の記事を参照してください)。(For more information about the preflight request, check the first article below.)


CORS と CORS を有効にする方法については、次のリソースをご確認ください。For more information about CORS and how to enable it, check out these resources.

Azure Storage のセキュリティについてよく寄せられる質問Frequently asked questions about Azure Storage security

  1. HTTPS プロトコルを使用できない場合、Azure Storage で送受信される BLOB の整合性を検証するにはどうすればよいですか。How can I verify the integrity of the blobs I'm transferring into or out of Azure Storage if I can't use the HTTPS protocol?

    何らかの理由で HTTPS ではなく HTTP を使用する必要があり、ブロック BLOB を使用している場合、MD5 チェックを使用して、転送中の BLOB の整合性を検証することができます。If for any reason you need to use HTTP instead of HTTPS and you are working with block blobs, you can use MD5 checking to help verify the integrity of the blobs being transferred. これは、ネットワーク/トランスポート層のエラーからの保護には役立ちますが、中間攻撃には必ずしも役立つとは言えません。This will help with protection from network/transport layer errors, but not necessarily with intermediary attacks.

    トランスポート レベルのセキュリティを提供する HTTPS を使用できる場合は、MD5 チェックを使用することは冗長となり、不要です。If you can use HTTPS, which provides transport level security, then using MD5 checking is redundant and unnecessary.

    詳細については、 Azure BLOB MD5 の概要に関するブログ記事をご覧ください。For more information, please check out the Azure Blob MD5 Overview.

  2. 米国政府の FIPS 準拠はどうなっていますかWhat about FIPS-Compliance for the U.S. Government?

    米国連邦情報処理規格 (FIPS) には、機密データの保護のために、米国連邦政府のコンピューター システムで使用することが承認されている暗号化アルゴリズムが定義されています。The United States Federal Information Processing Standard (FIPS) defines cryptographic algorithms approved for use by U.S. Federal government computer systems for the protection of sensitive data. Windows Server またはデスクトップで FIPS モードを有効にすると、FIPS が検証された暗号化アルゴリズムのみを使用するように OS に指示されます。Enabling FIPS mode on a Windows server or desktop tells the OS that only FIPS-validated cryptographic algorithms should be used. アプリケーションが準拠していないアルゴリズムを使用している場合、アプリケーションは停止します。If an application uses non-compliant algorithms, the applications will break. .NET Framework バージョン 4.5.2 以降の場合、コンピューターを FIPS モードにすると、FIPS に準拠しているアルゴリズムを使用するようにアプリケーションの暗号化アルゴリズムが自動的に切り替わります。With.NET Framework versions 4.5.2 or higher, the application automatically switches the cryptography algorithms to use FIPS-compliant algorithms when the computer is in FIPS mode.

    FIPS モードを有効にするかどうかは、ユーザーの判断に委ねられます。Microsoft leaves it up to each customer to decide whether to enable FIPS mode. 政府の規制対象ではないユーザーには、既定で FIPS モードを有効にしなければならない理由はないと Microsoft は考えます。We believe there is no compelling reason for customers who are not subject to government regulations to enable FIPS mode by default.