キューのクライアント側暗号化

.NET および Python 用の Azure Queue Storage クライアント ライブラリでは、Azure Storage にアップロードする前にクライアント アプリケーション内のデータを暗号化し、クライアントにダウンロードするときにデータの暗号化を解除することができます。 また、クライアント ライブラリは Azure Key Vault との統合にも役立ち、ストレージ アカウント キー管理に利用することができます。

クライアント側の暗号化について

Azure Queue Storage クライアント ライブラリは AES を使用して、ユーザー データを暗号化します。 クライアント ライブラリでは、次の 2 つのバージョンのクライアント側暗号化を使用できます。

• バージョン 2 では、AES で Galois/Counter Mode (GCM) モードが使用されます。
• バージョン 1 では、AES で暗号ブロック チェーン (CBC) モードが使用されます。

アプリケーションのセキュリティの脆弱性を軽減する

Queue Storage クライアント ライブラリの CBC モードの実装においてセキュリティの脆弱性が検出されたため、直ちに次の 1 つ以上の措置をとることをお勧めします。

• クライアント側暗号化でなく、サービス側暗号化機能を使用することを検討してください。 サービス側暗号化機能の詳細については、「保存データに対する Azure Storage 暗号化」をご覧ください。

• クライアント側暗号化を使用する必要がある場合は、クライアント側暗号化 v1 からクライアント側暗号化 v2 にアプリケーションを移行してください。

次の表は、アプリケーションをクライアント側暗号化 v2 に移行する場合に実行する必要がある手順をまとめたものです。

さらに、次の手順を行ってデータをセキュリティ保護することをお勧めします。

• プライベート エンドポイントを使用して、プライベート リンク上の仮想ネットワーク (VNet) とストレージ アカウントの間のすべてのトラフィックをセキュリティ保護するようストレージ アカウントを構成します。 詳細については、「Azure Storage のプライベート エンドポイントを使用する」を参照してください。
• ネットワーク アクセスを特定のネットワークだけに制限します。

クライアント側暗号化の SDK サポート マトリックス

次の表は、どのバージョンの .NET および Python 用クライアント ライブラリが、どのバージョンのクライアント側暗号化をサポートするかを示しています。

アプリケーションが以前のバージョンの .NET または Python クライアント ライブラリでクライアント側暗号化を使用している場合は、最初に、クライアント側暗号化 v2 をサポートするバージョンにコードをアップグレードする必要があります。 次に、クライアント側暗号化 v2 を使用してデータを復号化して再暗号化する必要があります。 必要であれば、コードの移行中に、クライアント側暗号化 v2 をサポートするバージョンのクライアント ライブラリを、以前のバージョンのクライアント ライブラリと並行して使用することができます。

クライアント側暗号化の仕組み

Azure Queue Storage クライアント ライブラリでは、エンベロープ暗号化を使用して、クライアント側のデータを暗号化および復号化します。 エンベロープ暗号化では、キーの暗号化を 1 つ以上の追加キーを使用して行います。

Queue Storage クライアント ライブラリは、クライアント側の暗号化に使用されるキーを保護するために Azure Key Vault に依存しています。 Azure Key Vault の詳細については、「Azure Key Vault とは」をご覧ください。

エンベロープ手法による暗号化と復号化

エンベロープ手法による暗号化は、次のように機能します。

1. Azure Storage クライアント ライブラリは、1 回使用の対称キーであるコンテンツ暗号化キー (CEK) を生成します。

2. ユーザー データが CEK を使用して暗号化されます。

3. CEK は、キー暗号化キー (KEK) を使用してラップ (暗号化) されます。 KEK は、キー識別子によって識別され、非対称キー ペアまたは対称キーのどちらにでもできます。 CEK はローカルで管理するか、Azure Key Vault に保管します。

   Azure Storage クライアント ライブラリ自体が KEK にアクセスすることはありません。 ライブラリは、Key Vault によって提供されるキー ラップ アルゴリズムを呼び出すだけです。 ユーザーは、必要な場合は、キー ラップ/ラップ解除にカスタム プロバイダーを使用できます。

4. その後、暗号化されたデータは Azure Queue Storage にアップロードされます。 ラップされたキーといくつかの追加の暗号化メタデータは、暗号化されたデータによって補間されます。

エンベロープ手法による復号化は、次のように機能します。

1. Azure Storage クライアント ライブラリでは、ユーザーが KEK をローカルまたは Azure Key Vault のいずれかで管理することを前提としています。 ユーザーは、暗号化に使用された特定のキーを把握しておく必要はありません。 代わりに、さまざまなキー識別子をキーに解決する Key Resolver を設定、使用できます。
2. クライアント ライブラリは、暗号化されたデータおよび Azure Storage に格納されている暗号化に関する情報 (ある場合) をダウンロードします。
3. ラップされた CEK は、KEK を使用してラップ解除 (復号化) されます。 クライアント ライブラリはこのプロセス中に KEK にアクセスできませんが、Azure Key Vault または他のキー ストアのラップ解除アルゴリズムのみを呼び出します。
4. クライアント ライブラリは、CEK を使用して暗号化されたユーザー データを復号化します。

メッセージの暗号化/暗号化解除

キュー メッセージの書式は一定でないため、クライアント ライブラリでは、メッセージ テキストで初期化ベクトル (IV) と暗号化されたコンテンツ暗号化キー (CEK) を含むカスタム書式が定義されます。

暗号化中、クライアント ライブラリは 16 バイトのランダムな IV と 32 バイトのランダムな CEK を生成し、この情報を使用してキュー メッセージ テキストのエンベロープ暗号化を実行します。 次に、ラップされた CEK と追加の暗号化メタデータのいくつかが、暗号化されたキュー メッセージに追加されます。 この変更されたメッセージは、サービスに格納されます。

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

復号化中、ラップされたキーがキュー メッセージから抽出され、ラップ解除されます。 また、IV もキュー メッセージから抽出され、これをラップ解除されたキーと共に使用して、キュー メッセージ データが復号化されます。 暗号化メタデータは小さいため (500 バイト未満)、キュー メッセージの 64 KB という上限を考慮したとき、影響が小さくて済みます。 上記のスニペットに示すように、暗号化されたメッセージは Base64 でエンコードされています。これにより、送信されるメッセージのサイズが拡張されます。

キュー内のメッセージの有効期間が短いため、クライアント側暗号化 v2 に更新した後のキュー メッセージの暗号化解除と再暗号化は必要ありません。 セキュリティが低いメッセージは、通常のキュー消費の過程でローテーションされます。

クライアント側暗号化とパフォーマンス

ストレージ データを暗号化すると、パフォーマンスのオーバーヘッドが増えることを忘れないでください。 アプリケーションでクライアント側暗号化を使用するとき、クライアント ライブラリは、CEK と IV を安全に生成し、コンテンツ自体を暗号化し、選択したキーを包み込むためのキーストアと通信し、追加のメタデータを書式設定してアップロードする必要があります。 このオーバーヘッドは、暗号化されるデータの量によって変わります。 開発中に、アプリケーションのパフォーマンスを常にテストすることをお勧めします。

次のステップ

• Azure Storage がセキュリティの脆弱性に対処するために SDK のクライアント側暗号化を更新
• 保存データに対する Azure Storage 暗号化
• Azure Key Vault のドキュメント