Microsoft Azure Storage のクライアント側の暗号化と Azure Key VaultClient-Side Encryption and Azure Key Vault for Microsoft Azure Storage

概要Overview

.NET 用 Azure Storage クライアント ライブラリ は、Azure Storage にアップロードする前にクライアント アプリケーション内のデータを暗号化し、クライアントにダウンロードするときにデータの暗号化を解除する作業を支援します。The Azure Storage Client Library for .NET supports encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. また、このライブラリは Azure Key Vault の統合にも役立ち、ストレージ アカウント キー管理に利用することもできます。The library also supports integration with Azure Key Vault for storage account key management.

クライアント側の暗号化と Azure Key Vault を使用して BLOB を暗号化するプロセスを紹介するステップ バイ ステップ チュートリアルについては、「 チュートリアル: Azure Key Vault を使用した Microsoft Azure Storage 内の BLOB の暗号化と復号化」をご覧ください。For a step-by-step tutorial that leads you through the process of encrypting blobs using client-side encryption and Azure Key Vault, see Encrypt and decrypt blobs in Microsoft Azure Storage using Azure Key Vault.

Java によるクライアント側の暗号化については、「 Java による Microsoft Azure Storage のクライアント側の暗号化」を参照してください。For client-side encryption with Java, see Client-Side Encryption with Java for Microsoft Azure Storage.

エンベロープ手法による暗号化と復号化Encryption and decryption via the envelope technique

暗号化と復号化のプロセスは、エンベロープ手法に倣います。The processes of encryption and decryption follow the envelope technique.

エンベロープ手法による暗号化Encryption via the envelope technique

エンベロープ手法による暗号化は、次の方法で機能します。Encryption via the envelope technique works in the following way:

  1. Azure ストレージ クライアント ライブラリは、1 回使用の対称キーであるコンテンツ暗号化キー (CEK) を生成します。The Azure storage client library generates a content encryption key (CEK), which is a one-time-use symmetric key.

  2. ユーザー データは、この CEK を使用して暗号化されます。User data is encrypted using this CEK.

  3. CEK は、キー暗号化キー (KEK) を使用してラップ (暗号化) されます。The CEK is then wrapped (encrypted) using the key encryption key (KEK). KEK は、キー識別子によって識別され、非対称キー ペアまたは対称キーのどちらでもよく、ローカルに管理することも、Azure Key Vault に保存することもできます。The KEK is identified by a key identifier and can be an asymmetric key pair or a symmetric key and can be managed locally or stored in Azure Key Vaults.

    ストレージ クライアント ライブラリ自体が KEK にアクセスすることはありません。The storage client library itself never has access to KEK. ライブラリは、Key Vault によって提供されるキー ラップ アルゴリズムを呼び出すだけです。The library invokes the key wrapping algorithm that is provided by Key Vault. ユーザーは、必要な場合は、キー ラップ/ラップ解除にカスタム プロバイダーを使用できます。Users can choose to use custom providers for key wrapping/unwrapping if desired.

  4. 暗号化されたデータは、Azure Storage サービスにアップロードされます。The encrypted data is then uploaded to the Azure Storage service. ラップされたキーは追加の暗号化メタデータと共にメタデータとして (BLOB に) 格納されるか、暗号化されたデータ (キュー メッセージやテーブル エンティティ) によって補間されます。The wrapped key along with some additional encryption metadata is either stored as metadata (on a blob) or interpolated with the encrypted data (queue messages and table entities).

エンベロープ手法による復号化Decryption via the envelope technique

エンベロープ手法による復号化は、次の方法で機能します。Decryption via the envelope technique works in the following way:

  1. クライアント ライブラリでは、ユーザーがキー暗号化キー (KEK) をローカルまたは Azure Key Vault のいずれかで管理することを前提としています。The client library assumes that the user is managing the key encryption key (KEK) either locally or in Azure Key Vaults. ユーザーは、暗号化に使用された特定のキーを把握しておく必要はありません。The user does not need to know the specific key that was used for encryption. 代わりに、さまざまなキー識別子をキーに解決する Key Resolver を設定、使用できます。Instead, a key resolver which resolves different key identifiers to keys can be set up and used.
  2. クライアント ライブラリは、暗号化されたデータおよびサービスに格納されている暗号化に関する情報 (ある場合) をダウンロードします。The client library downloads the encrypted data along with any encryption material that is stored on the service.
  3. 次に、ラップされたコンテンツ暗号化キー (CEK) が、キー暗号化キー (KEK) によりラップ解除 (復号化) されます。The wrapped content encryption key (CEK) is then unwrapped (decrypted) using the key encryption key (KEK). ここでも、クライアント ライブラリが KEK にアクセスすることはありません。Here again, the client library does not have access to KEK. これは、単にカスタムの、または Key Vault プロバイダーのラップ解除アルゴリズムを起動するだけです。It simply invokes the custom or Key Vault provider's unwrapping algorithm.
  4. 次に、コンテンツ暗号化キー (CEK) を使用して、暗号化されたユーザー データを復号化します。The content encryption key (CEK) is then used to decrypt the encrypted user data.

暗号化メカニズムEncryption Mechanism

ストレージ クライアント ライブラリは AES を使用して、ユーザー データを暗号化します。The storage client library uses AES in order to encrypt user data. 具体的には、AES で 暗号ブロック チェーン (CBC) モードを使用します。Specifically, Cipher Block Chaining (CBC) mode with AES. サービスごとに動作が多少異なるため、以下でそれぞれについて説明します。Each service works somewhat differently, so we will discuss each of them here.

BLOBBlobs

現在、クライアント ライブラリでは BLOB 全体の暗号化のみがサポートされています。The client library currently supports encryption of whole blobs only. 具体的には、UploadFrom メソッドや OpenWrite メソッドを使用するときに暗号化がサポートされます。Specifically, encryption is supported when users use the UploadFrom methods or the OpenWrite method. ダウンロードについては、完全ダウンロードと一部の範囲のダウンロードの両方がサポートされています。For downloads, both complete and range downloads are supported.

暗号化中、クライアント ライブラリは 16 バイトのランダムな初期化ベクトル (IV) と 32 バイトのランダムなコンテンツ暗号化キー (CEK) を生成し、この情報を使用して BLOB データのエンベロープ暗号化を実行します。During encryption, the client library will generate a random Initialization Vector (IV) of 16 bytes, together with a random content encryption key (CEK) of 32 bytes, and perform envelope encryption of the blob data using this information. ラップされた CEK と一部の追加暗号化メタデータが、サービスの暗号化された BLOB と共に、BLOB メタデータとして格納されます。The wrapped CEK and some additional encryption metadata are then stored as blob metadata along with the encrypted blob on the service.

警告

BLOB のメタデータを編集またはアップロードする場合は、このメタデータを保持している必要があります。If you are editing or uploading your own metadata for the blob, you need to ensure that this metadata is preserved. このメタデータなしで新しいメタデータをアップロードした場合、ラップされた CEK、IV、その他のメタデータは失われ、BLOB コンテンツが再度取得可能になることはありません。If you upload new metadata without this metadata, the wrapped CEK, IV, and other metadata will be lost and the blob content will never be retrievable again.

暗号化された BLOB のダウンロードには、便利なメソッド DownloadTo/BlobReadStream を使用した BLOB 全体のコンテンツの取得も含まれます。Downloading an encrypted blob involves retrieving the content of the entire blob using the DownloadTo/BlobReadStream convenience methods. ラップされた CEK はラップ解除され、復号化されたデータをユーザーに返すために IV (この場合 BLOB メタデータとして格納された) と共に使用されます。The wrapped CEK is unwrapped and used together with the IV (stored as blob metadata in this case) to return the decrypted data to the users.

暗号化された BLOB での任意の範囲 (DownloadRange メソッド) のダウンロードでは、ユーザーが指定した範囲が調整されます。これは、少量の追加データを取得して、要求された範囲を正常に復号化するためです。Downloading an arbitrary range (DownloadRange methods) in the encrypted blob involves adjusting the range provided by users in order to get a small amount of additional data that can be used to successfully decrypt the requested range.

このスキームを使用して、すべての BLOB 型 (ブロック BLOB、ページ BLOB、および追加 BLOB) を暗号化/復号化できます。All blob types (block blobs, page blobs, and append blobs) can be encrypted/decrypted using this scheme.

キューQueues

キュー メッセージの書式は一定でないため、クライアント ライブラリでは、メッセージ テキストで初期化ベクトル (IV) と暗号化されたコンテンツ暗号化キー (CEK) を含むカスタム書式が定義されます。Since queue messages can be of any format, the client library defines a custom format that includes the Initialization Vector (IV) and the encrypted content encryption key (CEK) in the message text.

暗号化中、クライアント ライブラリは 16 バイトのランダムな IV と 32 バイトのランダムな CEK を生成し、この情報を使用してキュー メッセージ テキストのエンベロープ暗号化を実行します。During encryption, the client library generates a random IV of 16 bytes along with a random CEK of 32 bytes and performs envelope encryption of the queue message text using this information. 次に、ラップされた CEK と追加の暗号化メタデータのいくつかが、暗号化されたキュー メッセージに追加されます。The wrapped CEK and some additional encryption metadata are then added to the encrypted queue message. この変更されたメッセージ (下記参照) は、サービスに格納されます。This modified message (shown below) is stored on the service.

<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>

復号化中、ラップされたキーがキュー メッセージから抽出され、ラップ解除されます。During decryption, the wrapped key is extracted from the queue message and unwrapped. また、IV もキュー メッセージから抽出され、これをラップ解除されたキーと共に使用して、キュー メッセージ データが復号化されます。The IV is also extracted from the queue message and used along with the unwrapped key to decrypt the queue message data. 暗号化メタデータは小さいため (500 バイト未満)、キュー メッセージの 64 KB という上限を考慮したとき、影響が小さくて済みます。Note that the encryption metadata is small (under 500 bytes), so while it does count toward the 64KB limit for a queue message, the impact should be manageable.

テーブルTables

クライアント ライブラリでは、挿入および置換操作のエンティティ プロパティの暗号化がサポートされます。The client library supports encryption of entity properties for insert and replace operations.

注意

現在、マージはサポートされていません。Merge is not currently supported. 別のキーを使用してプロパティのサブセットが以前に暗号化されている場合、新しいプロパティをマージしたり、メタデータを更新したりするとデータ損失が発生します。Since a subset of properties may have been encrypted previously using a different key, simply merging the new properties and updating the metadata will result in data loss. マージでは、追加のサービス呼び出しをして既存のエンティティをサービスから読み込むか、プロパティごとに新しいキーを使用する必要があります。いずれの方法も、パフォーマンス上の理由でお勧めできません。Merging either requires making extra service calls to read the pre-existing entity from the service, or using a new key per property, both of which are not suitable for performance reasons.

テーブル データの暗号化は、次のように機能します。Table data encryption works as follows:

  1. 暗号化するプロパティをユーザーが指定します。Users specify the properties to be encrypted.
  2. クライアント ライブラリは 16 バイトのランダムな初期化ベクトル (IV) と 32 バイトのランダムなコンテンツ暗号化キー (CEK) を各エンティティごとに生成し、プロパティごとに新しい IV を派生させることで暗号化する個々のプロパティでエンベロープ暗号化を実行します。The client library generates a random Initialization Vector (IV) of 16 bytes along with a random content encryption key (CEK) of 32 bytes for every entity, and performs envelope encryption on the individual properties to be encrypted by deriving a new IV per property. 暗号化されたプロパティは、バイナリ データとして格納されます。The encrypted property is stored as binary data.
  3. 次に、ラップされた CEK と追加の暗号化メタデータが、2 つの追加の予約済みプロパティとして格納されます。The wrapped CEK and some additional encryption metadata are then stored as two additional reserved properties. 最初の予約済みプロパティ (_ClientEncryptionMetadata1) は文字列プロパティで、IV、バージョン、およびラップされたキーに関する情報を保持します。The first reserved property (_ClientEncryptionMetadata1) is a string property that holds the information about IV, version, and wrapped key. 2 番目の予約済みプロパティ (_ClientEncryptionMetadata2) はバイナリ プロパティで、暗号化されたプロパティに関する情報を保持します。The second reserved property (_ClientEncryptionMetadata2) is a binary property that holds the information about the properties that are encrypted. この 2 番目のプロパティ (_ClientEncryptionMetadata2) 内の情報自体が暗号化されます。The information in this second property (_ClientEncryptionMetadata2) is itself encrypted.
  4. これらの暗号化に必要な追加の予約済みプロパティにより、ユーザーが所有できるカスタム プロパティは 252 ではなく、250 個になります。Due to these additional reserved properties required for encryption, users may now have only 250 custom properties instead of 252. エンティティの合計サイズは、1 MB 未満である必要があります。The total size of the entity must be less than 1 MB.

暗号化できるのは、文字列プロパティのみであることに注意してください。Note that only string properties can be encrypted. 他の種類のプロパティを暗号化する必要がある場合は、文字列に変換する必要があります。If other types of properties are to be encrypted, they must be converted to strings. 暗号化された文字列はバイナリ プロパティとしてサービスで保存され、復号化された後、文字列に変換されて戻されます。The encrypted strings are stored on the service as binary properties, and they are converted back to strings after decryption.

テーブルの場合、暗号化ポリシーに加え、ユーザーは暗号化するプロパティを指定する必要があります。For tables, in addition to the encryption policy, users must specify the properties to be encrypted. これを実行するには、[EncryptProperty] 属性を指定するか (TableEntity から派生した POCO エンティティ用)、または要求オプションで暗号化リゾルバーを指定します。This can be done by either specifying an [EncryptProperty] attribute (for POCO entities that derive from TableEntity) or an encryption resolver in request options. 暗号化リゾルバーは、パーティション キー、行キー、プロパティ名を取得するデリゲートで、プロパティを暗号化するかどうかを示すブール値を返します。An encryption resolver is a delegate that takes a partition key, row key, and property name and returns a Boolean that indicates whether that property should be encrypted. 暗号化時、クライアント ライブラリはこの情報を使用して、ネットワークへの書き込み時にプロパティを暗号化するかどうかを決定します。During encryption, the client library will use this information to decide whether a property should be encrypted while writing to the wire. また、デリゲートは、プロパティの暗号化方法に関するロジックを使用する可能性にも備えます。The delegate also provides for the possibility of logic around how properties are encrypted. (X の場合、プロパティ A を暗号化し、それ以外の場合はプロパティ A および B を暗号化するなど。)エンティティの読み込み中、またはクエリの実行中は、この情報を指定する必要はありません。(For example, if X, then encrypt property A; otherwise encrypt properties A and B.) Note that it is not necessary to provide this information while reading or querying entities.

バッチ操作Batch Operations

バッチ操作では、そのバッチ操作のすべての行で同じ KEK が使用されます。これは、クライアント ライブラリで、各バッチ操作あたり 1 つの options オブジェクト (従って、1 ポリシー/KEK) のみが許可されるためです。In batch operations, the same KEK will be used across all the rows in that batch operation because the client library only allows one options object (and hence one policy/KEK) per batch operation. ただし、クライアント ライブラリは、バッチ内の行ごとに 1 つの新しいランダム IV とランダム CEK を内部的に生成します。However, the client library will internally generate a new random IV and random CEK per row in the batch. ユーザーは、暗号化リゾルバーでこの動作を定義することで、バッチの各操作で個別のプロパティを暗号化することも選択できます。Users can also choose to encrypt different properties for every operation in the batch by defining this behavior in the encryption resolver.

クエリQueries

注意

エンティティは暗号化されているため、暗号化されたプロパティでフィルター処理を行うクエリを実行できません。Because the entities are encrypted, you cannot run queries that filter on an encrypted property. 実行しようとすると、暗号化されたデータと、暗号化されていないデータの比較が行われるため、結果が不正確になります。If you try, results will be incorrect, because the service would be trying to compare encrypted data with unencrypted data.

クエリ操作を実行するには、結果セット内のすべてのキーを解決できる Key Resolver を指定する必要があります。To perform query operations, you must specify a key resolver that is able to resolve all the keys in the result set. クエリの結果に含まれたエンティティをプロバイダーに解決できない場合、クライアント ライブラリでエラーがスローされます。If an entity contained in the query result cannot be resolved to a provider, the client library will throw an error. クエリでサーバー側のプロジェクションを実行する場合、クライアント ライブラリは選択した列に特別な暗号化メタデータ プロパティ (_ClientEncryptionMetadata1 と _ClientEncryptionMetadata2) を既定で追加します。For any query that performs server-side projections, the client library will add the special encryption metadata properties (_ClientEncryptionMetadata1 and _ClientEncryptionMetadata2) by default to the selected columns.

Azure Key VaultAzure Key Vault

Azure Key Vault は、クラウド アプリケーションやサービスで使用される暗号化キーとシークレットをセキュリティで保護するために役立ちます。Azure Key Vault helps safeguard cryptographic keys and secrets used by cloud applications and services. Azure Key Vault を使用すると、キーとシークレット (認証キー、ストレージ アカウント キー、データ暗号化キー、PFX ファイル、パスワードなど) をハードウェア セキュリティ モジュール (HSM) で保護されたキーを使用して暗号化できます。By using Azure Key Vault, users can encrypt keys and secrets (such as authentication keys, storage account keys, data encryption keys, .PFX files, and passwords) by using keys that are protected by hardware security modules (HSMs). 詳細については、「 Azure Key Vault とは」を参照してください。For more information, see What is Azure Key Vault?.

ストレージ クライアント ライブラリは Key Vault のコア ライブラリを使用して、Azure 全体でのキー管理用の一般的なフレームワークを提供します。The storage client library uses the Key Vault core library in order to provide a common framework across Azure for managing keys. Key Vault 拡張機能ライブラリを使用すると追加のメリットも得られます。Users also get the additional benefit of using the Key Vault extensions library. 拡張機能ライブラリには、シンプルかつシームレスな対称/RSA ローカルおよびクラウドのキー プロバイダーに関する便利な機能や、集計またはキャッシュに関する機能が用意されています。The extensions library provides useful functionality around simple and seamless Symmetric/RSA local and cloud key providers as well as with aggregation and caching.

インターフェイスと依存関係Interface and dependencies

次の 3 種類の Key Vault パッケージがあります。There are three Key Vault packages:

  • Microsoft.Azure.KeyVault.Core には、IKey と IKeyResolver が含まれています。Microsoft.Azure.KeyVault.Core contains the IKey and IKeyResolver. これは、依存関係のない小型パッケージです。It is a small package with no dependencies. .NET 用ストレージ クライアント ライブラリでは、依存関係としてそれを定義します。The storage client library for .NET defines it as a dependency.
  • Microsoft.Azure.KeyVault には Key Vault REST クライアントが含まれています。Microsoft.Azure.KeyVault contains the Key Vault REST client.
  • Microsoft.Azure.KeyVault.Extensions には、暗号化アルゴリズム、RSAKey、および SymmetricKey の実装を含む拡張機能コードが含まれています。Microsoft.Azure.KeyVault.Extensions contains extension code that includes implementations of cryptographic algorithms and an RSAKey and a SymmetricKey. これは、コアおよび KeyVault 名前空間に依存し、集計リゾルバー (複数のキー プロバイダーを使用する必要がある場合) およびキャッシュ キー リゾルバーを定義する機能を提供します。It depends on the Core and KeyVault namespaces and provides functionality to define an aggregate resolver (when users want to use multiple key providers) and a caching key resolver. ストレージ クライアント ライブラリはこのパッケージに直接依存しませんが、Azure Key Vault を使用してキーを格納するか、Key Vault 拡張機能を使用してローカルおよびクラウドの暗号化プロバイダーを使用する必要がある場合はこのパッケージが必要です。Although the storage client library does not directly depend on this package, if users wish to use Azure Key Vault to store their keys or to use the Key Vault extensions to consume the local and cloud cryptographic providers, they will need this package.

Key Vault は値の高いマスター キー向けで、Key Vault ごとのスロットルの上限はこれを念頭に設計されています。Key Vault is designed for high-value master keys, and throttling limits per Key Vault are designed with this in mind. Key Vault を使用してクライアント側の暗号化を実行するときに推奨されるモデルは、Key Vault 内のシークレットやローカルにキャッシュされたシークレットとして格納された対象マスター キーを使用することです。When performing client-side encryption with Key Vault, the preferred model is to use symmetric master keys stored as secrets in Key Vault and cached locally. 次の操作を実行する必要があります。Users must do the following:

  1. シークレットをオフラインで作成し、Key Vault にアップロードします。Create a secret offline and upload it to Key Vault.
  2. シークレットのベース識別子をパラメーターとして使用して、シークレットの現在のバージョンを暗号化用に解決し、この情報をローカルでキャッシュします。Use the secret's base identifier as a parameter to resolve the current version of the secret for encryption and cache this information locally. キャッシュ用の CachingKeyResolver の使用: ユーザーが自身のキャッシュ ロジックを実装することは想定されていません。Use CachingKeyResolver for caching; users are not expected to implement their own caching logic.
  3. 暗号化ポリシーの作成時に、入力としてキャッシュ リゾルバーを使用します。Use the caching resolver as an input while creating the encryption policy.

Key Vault の使用方法について詳しくは、 暗号化コードのサンプルを参照してください。More information regarding Key Vault usage can be found in the encryption code samples.

ベスト プラクティスBest practices

暗号化のサポートは、.NET 用のストレージ クライアント ライブラリでのみ使用できます。Encryption support is available only in the storage client library for .NET. Windows Phone と Windows ランタイムでは現在、暗号化はサポートされていません。Windows Phone and Windows Runtime do not currently support encryption.

重要

クライアント側の暗号化を使用する場合は、次の重要な点に注意してください。Be aware of these important points when using client-side encryption:

  • 暗号化された BLOB を読み書きするときは、完全 BLOB アップロード コマンドと範囲/完全 BLOB ダウンロード コマンドを使用してください。When reading from or writing to an encrypted blob, use whole blob upload commands and range/whole blob download commands. Put Block、Put Block List、Write Pages、Clear Pages、または Append Block などのプロトコル操作で暗号化された BLOB に書き込まないでください。暗号化された BLOB が壊れたり、読み取り不可能になったりすることがあります。Avoid writing to an encrypted blob using protocol operations such as Put Block, Put Block List, Write Pages, Clear Pages, or Append Block; otherwise you may corrupt the encrypted blob and make it unreadable.
  • テーブルの場合、同様の制約があります。For tables, a similar constraint exists. 暗号化メタデータを更新せずに暗号化されたプロパティを更新する行為は避けてください。Be careful to not update encrypted properties without updating the encryption metadata.
  • 暗号化された BLOB にメタデータを設定する場合、メタデータの設定は付加的には行われないため、復号化に必要な暗号化関連メタデータが上書きされる可能性があります。If you set metadata on the encrypted blob, you may overwrite the encryption-related metadata required for decryption, since setting metadata is not additive. これはスナップショットにも該当します。暗号化された BLOB のスナップショットを作成するときにメタデータを指定しないでください。This is also true for snapshots; avoid specifying metadata while creating a snapshot of an encrypted blob. メタデータを設定する必要がある場合は、最初に FetchAttributes メソッドを呼び出し、現在の暗号化メタデータを取得してください。メタデータの設定中に、同時書き込みは行わないでください。If metadata must be set, be sure to call the FetchAttributes method first to get the current encryption metadata, and avoid concurrent writes while metadata is being set.
  • 暗号化されたデータのみを処理する必要のあるユーザーについては、既定の要求オプションで、 RequireEncryption プロパティを有効にします。Enable the RequireEncryption property in the default request options for users that should work only with encrypted data. 詳細については、以下をご覧ください。See below for more info.

クライアント API/インターフェイスClient API / Interface

EncryptionPolicy オブジェクトの作成では、キーのみ (IKey の実装)、リゾルバーのみ (IKeyResolver の実装)、またはその両方を指定できます。While creating an EncryptionPolicy object, users can provide only a Key (implementing IKey), only a resolver (implementing IKeyResolver), or both. IKey は基本的なキーの種類で、キー識別子を使用して識別され、ラップ/ラップ解除のロジックを指定します。IKey is the basic key type that is identified using a key identifier and that provides the logic for wrapping/unwrapping. IKeyResolver は復号化プロセス中のキーの解決に使用します。IKeyResolver is used to resolve a key during the decryption process. これは、IKey で指定されたキー識別子を返す ResolveKey メソッドを定義します。It defines a ResolveKey method that returns an IKey given a key identifier. これは、複数の場所で管理されている複数のキーの中から選択するための機能を提供します。This provides users the ability to choose between multiple keys that are managed in multiple locations.

  • 暗号化では、キーは常に使用され、キーがないとエラーが発生します。For encryption, the key is used always and the absence of a key will result in an error.
  • 復号化の場合:For decryption:
    • キーを取得するよう指定した場合にキー リゾルバーが起動します。The key resolver is invoked if specified to get the key. リゾルバーが指定されていても、キー識別子のマッピングがない場合、エラーがスローされます。If the resolver is specified but does not have a mapping for the key identifier, an error is thrown.
    • リゾルバーが指定されていない場合にキーが指定されると、そのキーの識別子が必須キー識別子と一致すると、そのキーが使用されます。If resolver is not specified but a key is specified, the key is used if its identifier matches the required key identifier. 識別子が一致しなければ、エラーがスローされます。If the identifier does not match, an error is thrown.

この記事のコード例では、暗号化ポリシーの設定方法と暗号化されたデータの使用方法を示しますが、Azure Key Vault の使用方法は示していません。The code examples in this article demonstrate setting an encryption policy and working with encrypted data, but do not demonstrate working with Azure Key Vault. BLOB、キュー、テーブルや、Key Vault 統合の詳しいエンド ツー エンド シナリオについては、GitHub で暗号化のサンプルをご確認ください。The encryption samples on GitHub demonstrate a more detailed end-to-end scenario for blobs, queues and tables, along with Key Vault integration.

RequireEncryption モードRequireEncryption mode

すべてのアップロードとダウンロードを暗号化する必要がある場合、オプションで操作のモードを有効にすることができます。Users can optionally enable a mode of operation where all uploads and downloads must be encrypted. このモードでは、暗号化ポリシーを設定せずにデータをアップロードしようとしたり、サービスで暗号化されていないデータをダウンロードしようとしたりすると、クライアントで失敗します。In this mode, attempts to upload data without an encryption policy or download data that is not encrypted on the service will fail on the client. 要求オプション オブジェクトの RequireEncryption プロパティによって、この動作が制御されます。The RequireEncryption property of the request options object controls this behavior. Azure Storage に保存されているすべてのオブジェクトがアプリケーションによって暗号化される場合、サービス クライアント オブジェクトの既定の要求オプションに requireEncryption プロパティを設定できます。If your application will encrypt all objects stored in Azure Storage, then you can set the RequireEncryption property on the default request options for the service client object. たとえば、CloudBlobClient.DefaultRequestOptions.RequireEncryptiontrue に設定して、そのクライアント オブジェクトを介して実行されるすべての BLOB 操作に対して暗号化を要求します。For example, set CloudBlobClient.DefaultRequestOptions.RequireEncryption to true to require encryption for all blob operations performed through that client object.

Blob service 暗号化Blob service encryption

BlobEncryptionPolicy オブジェクトを作成し、それを要求オプションに設定します (API ごとに、または DefaultRequestOptions を使用してクライアント レベルで設定します)。Create a BlobEncryptionPolicy object and set it in the request options (per API or at a client level by using DefaultRequestOptions). その他の操作はすべて、クライアント ライブラリが内部的に処理します。Everything else will be handled by the client library internally.

// Create the IKey used for encryption.
 RsaKey key = new RsaKey("private:key1" /* key identifier */);

 // Create the encryption policy to be used for upload and download.
 BlobEncryptionPolicy policy = new BlobEncryptionPolicy(key, null);

 // Set the encryption policy on the request options.
 BlobRequestOptions options = new BlobRequestOptions() { EncryptionPolicy = policy };

 // Upload the encrypted contents to the blob.
 blob.UploadFromStream(stream, size, null, options, null);

 // Download and decrypt the encrypted contents from the blob.
 MemoryStream outputStream = new MemoryStream();
 blob.DownloadToStream(outputStream, null, options, null);

Queue サービス暗号化Queue service encryption

QueueEncryptionPolicy オブジェクトを作成し、それを要求オプションに設定します (API ごとに、または DefaultRequestOptions を使用してクライアント レベルで設定します)。Create a QueueEncryptionPolicy object and set it in the request options (per API or at a client level by using DefaultRequestOptions). その他の操作はすべて、クライアント ライブラリが内部的に処理します。Everything else will be handled by the client library internally.

// Create the IKey used for encryption.
 RsaKey key = new RsaKey("private:key1" /* key identifier */);

 // Create the encryption policy to be used for upload and download.
 QueueEncryptionPolicy policy = new QueueEncryptionPolicy(key, null);

 // Add message
 QueueRequestOptions options = new QueueRequestOptions() { EncryptionPolicy = policy };
 queue.AddMessage(message, null, null, options, null);

 // Retrieve message
 CloudQueueMessage retrMessage = queue.GetMessage(null, options, null);

Table service 暗号化Table service encryption

暗号化ポリシーを作成し、要求オプションにそれを設定するだけでなく、EncryptionResolverTableRequestOptions に指定するか、エンティティに [EncryptProperty] 属性を設定する必要があります。In addition to creating an encryption policy and setting it on request options, you must either specify an EncryptionResolver in TableRequestOptions, or set the [EncryptProperty] attribute on the entity.

リゾルバーの使用Using the resolver

// Create the IKey used for encryption.
 RsaKey key = new RsaKey("private:key1" /* key identifier */);

 // Create the encryption policy to be used for upload and download.
 TableEncryptionPolicy policy = new TableEncryptionPolicy(key, null);

 TableRequestOptions options = new TableRequestOptions()
 {
    EncryptionResolver = (pk, rk, propName) =>
     {
        if (propName == "foo")
         {
            return true;
         }
         return false;
     },
     EncryptionPolicy = policy
 };

 // Insert Entity
 currentTable.Execute(TableOperation.Insert(ent), options, null);

 // Retrieve Entity
 // No need to specify an encryption resolver for retrieve
 TableRequestOptions retrieveOptions = new TableRequestOptions()
 {
    EncryptionPolicy = policy
 };

 TableOperation operation = TableOperation.Retrieve(ent.PartitionKey, ent.RowKey);
 TableResult result = currentTable.Execute(operation, retrieveOptions, null);

属性の使用Using attributes

上記のとおり、エンティティで TableEntity を実装した場合、プロパティは、 EncryptionResolverを指定するのではなく、[EncryptProperty] 属性で修飾できます。As mentioned above, if the entity implements TableEntity, then the properties can be decorated with the [EncryptProperty] attribute instead of specifying the EncryptionResolver.

[EncryptProperty]
 public string EncryptedProperty1 { get; set; }

暗号化とパフォーマンスEncryption and performance

ストレージ データを暗号化すると、パフォーマンスのオーバーヘッドが増えることに注意してください。Note that encrypting your storage data results in additional performance overhead. コンテンツ キーと IV を生成する必要があり、コンテンツ自体を暗号化する必要があります。また、追加のメタデータをフォーマットおよびアップロードする必要もあります。The content key and IV must be generated, the content itself must be encrypted, and additional meta-data must be formatted and uploaded. このオーバーヘッドは、暗号化されるデータの量によって異なります。This overhead will vary depending on the quantity of data being encrypted. 開発中に、アプリケーションのパフォーマンスを常にテストすることをお勧めします。We recommend that customers always test their applications for performance during development.

次の手順Next steps