データ暗号化モデル
暗号化のさまざまなモデル、およびそれらの長所と短所を理解することは、Azure でさまざまなリソース プロバイダーが実装している保存時の暗号化の方法を理解するために不可欠です。 これらの定義は、共通の言語と分類を確立するため Azure 内のすべてのリソース プロバイダーで共有されます。
サーバー側暗号化には 3 つのシナリオがあります。
サービス管理キーを使用したサーバー側暗号化
- Azure リソース プロバイダーが暗号化操作と複合化操作を実行する
- マイクロソフトがキーを管理する
- 完全なクラウド機能
Azure Key Vault でのユーザーが管理するキーを使用したサーバー側暗号化
- Azure リソース プロバイダーが暗号化操作と複合化操作を実行する
- Azure Key Vault でユーザーがキーを管理する
- 完全なクラウド機能
ユーザーが管理するハードウェア上での、ユーザーが管理するキーを使用したサーバー側暗号化
- Azure リソース プロバイダーが暗号化操作と複合化操作を実行する
- ユーザーが管理するハードウェア上のキーをユーザーが管理する
- 完全なクラウド機能
サーバー側暗号化モデルとは、Azure のサービスによって実行される暗号化を指します。 このモデルでは、リソース プロバイダーが暗号化および複合化操作を実行します。 たとえば、Azure Storage では、プレーンテキスト操作でデータを受け取り、暗号化および複合化操作を内部で実行します。 リソース プロバイダーは、Microsoft または指定された構成によってはユーザーが管理している暗号化キーを使用します。
保存時サーバー側暗号化の各モデルには、キー管理独特の特性があります。 これには、いつどのように暗号化キーが作成、保存されるか、アクセス モデル、およびキー ローテーションの手順が含まれます。
クライアント側の暗号化の場合、次の点を考慮してください。
- Azure のサービスは複合化されたデータを認識できません
- ユーザーがオンプレミス (または別のセキュリティで保護されたストア) でキーを管理および保管します キーは Azure のサービスでは使用できません
- 制限されたクラウド機能
Azure でサポートされている暗号化モデルは、2 つの主なグループに分割されます。「クライアント側暗号化」と既に説明した「サーバー側暗号化」です。 使用されている保存時暗号化モデルとは無関係に、Azure サービスでは常に、TLS や HTTPS などのセキュリティで保護されたトランスポートを使用することをお勧めしています。 そのため、転送中の暗号化の問題は、トランスポート プロトコルによって解決され、どの保存時暗号化モデルを使用するかを決定する主な要因ではなくなります。
クライアント側暗号化モデル
クライアント側暗号化モデルとは、リソース プロバイダーまたは Azure の外でサービスまたは呼び出し元アプリケーションによって実行される暗号化を指します。 暗号化は、Azure 内のサービス アプリケーション、またはお客様のデータ センターで実行されているアプリケーションによって実行できます。 いずれの場合も、この暗号化モデルを利用する場合は、Azure リソース プロバイダーは、データを解読する、または暗号化キーにアクセスすることを許可されないまま、暗号化されたデータの BLOB を受け取ります。 このモデルでは、キー管理は呼び出し元のサービスまたはアプリケーションによって行われ、Azure サービスにとっては不透明になります。
サービス管理キーを使用したサーバー側暗号化
多くのお客様にとって、保存時に確実にデータを暗号化することは必須要件です。 サービス管理キーを使用したサーバー側暗号化により、お客様が暗号化のために特定のリソース (ストレージ アカウント、SQL DB など) を指定し、キーの発行、ローテーション、バックアップなどのキー管理のすべての側面を Microsoft に任せることで、このモデルが実現されています。 暗号化をサポートするほとんどの Azure サービスでは、通常、暗号化キーの管理を Azure に一任するこのモデルがサポートされます。 Azure リソース プロバイダーは、キーを作成し、セキュリティ保護されたストレージに保存し、必要なときに取得します。 つまり、サービスはキーにフル アクセスでき、資格情報のライフサイクル管理を完全に管理します。
サービス管理キーを使用したサーバー側暗号化は、このようにして、お客様のオーバーヘッドを軽減しながら、保存時の暗号化ニーズに迅速に対応しています。 Azure Portal を使用できる場合、お客様は、Azure Portal を開いてターゲット サブスクリプションとリソース プロバイダーにアクセスし、ボックスをオンにしてデータを暗号化するかどうかを指定します。 Resource Manager のサーバー側暗号化ではサービス管理型のキーが既定でオンになっているものもあります。
Microsoft がキーを管理するサーバー側暗号化では、サービスがストアにフル アクセスでき、キーを管理することになります。 自分でキーを管理する方がより強力なセキュリティを実現できると感じるお客様もいらっしゃるでしょうが、このモデルを評価する際には、カスタム キー ストレージ ソリューションに伴うコストとリスクを考慮に入れる必要があります。 多くの組織で、リソースの制約またはオンプレミス ソリューションのリスクが、保存時の暗号化キーのクラウドでの管理のリスクより大きいと判断されています。 ただし、暗号化キーの作成またはライフサイクルを管理することを要件としている組織や、サービスの管理を担当する社員ではない社員にサービスの暗号化キーを管理させる (つまり、サービスの全体的な管理モデルからキー管理が分離されている) ことを要件としている組織にとっては、このモデルが十分でない場合があります。
キーへのアクセス
サービス管理キーを使用するサーバー側暗号化を導入すると、キーの作成、保存、サービスへのアクセスは、すべてサービスによって管理されます。 通常、基盤となる Azure リソース プロバイダーは、データの近くにあり、すぐに使用アクセスできるストアにデータ暗号化キーを格納し、キー暗号化キーはセキュリティで保護された内部ストアに格納されます。
長所
- 設定が簡単
- Microsoft がキー ローテーション、バックアップ、および冗長性を管理
- お客様には、実装に関連するコスト、またはカスタム キー 管理スキームのリスクが発生しません。
短所
- お客様が暗号化キー (キーの仕様、ライフサイクル、失効など) を管理できない
- サービスの全体的な管理モデルとキーの管理を分離できない
Azure Key Vault でのユーザーが管理するキーを使用したサーバー側暗号化
保存データを暗号化し、暗号化キーを管理することが要件であるシナリオの場合、Key Vault のユーザー管理キーを使用したサーバー側暗号化を利用できます。 一部のサービスでは Azure Key Vault のルート キー暗号化キーのみを保存し、暗号化されたデータ暗号化キーは、データに近い内部の場所に保存されます。 このシナリオでは、お客様は Key Vault に自分のキーを使用 (BYOK – Bring Your Own Key) するか、新しいものを生成して、必要なリソースを暗号化します。 リソース プロバイダーは、すべての暗号化操作のルート キーとして、構成されたキーの暗号化キーを使用して、暗号化と暗号化解除の操作を実行します。
キーの暗号化キーを失うことは、データを失うことを意味します。 そのため、キーは削除しないでください。 キーは作成またはローテーションのたびにバックアップしてください。 不注意または悪意による暗号化削除から保護するため、キー暗号化キーを格納するコンテナーでは、必ず論理的な削除と消去保護を有効にしてください。 キーを削除する代わりに、キー暗号化キーを enabled ではなく、 false に設定することをお勧めします。 アクセス制御を使用して、Azure Key Vault またはマネージド HSM 内の個々のユーザーまたはサービスへのアクセスを取り消します。
キーへのアクセス
Azure Key Vault のユーザー管理キーを使用するサーバー側暗号化モデルには、必要に応じて暗号化と複合化を行うためのキーにアクセスするサービスが含まれます。 保存時の暗号化キーは、アクセス制御ポリシーを介してサービスに提供されます。 このポリシーによって、キーを受け取るためのサービス ID アクセス許可が付与されます。 関連付けられたサブスクリプションの代理として実行されている Azure のサービスは、そのサブスクリプション内の ID で構成できます。 サービスでは、Microsoft Entra 認証を実行でき、サブスクリプションを代行するサービスとして認識される認証トークンを受け取れます。 このトークンを Key Vault に提示することにより、アクセスが付与されているキーを取得します。
暗号化キーを使用した操作として、複合化、暗号化、キーのラップ解除、キーのラップ、確認、署名、取得、一覧表示、更新、作成、インポート、削除、バックアップ、復元のいずれかの操作へのアクセスをサービス ID に付与できます。
保存データの暗号化または復号化で使用するキーを取得するには、Resource Manager サービス インスタンスとして実行されるサービス ID は UnwrapKey (複合化のためのキーを取得するため) と WrapKey (新しいキーの作成時にキー コンテナーにキーを挿入するため) を取得する必要があります。
注意
Key Vault の承認の詳細については、Azure Key Vault ドキュメントのキー コンテナーのセキュリティ保護に関するページを参照してください。
長所
- 使用するキーに対する完全な制御 – 暗号化キーは、ユーザーの管理下にあるユーザーの Key Vault で管理されます。
- 1 つのマスターで複数のサービスを暗号化する機能
- サービスの全体的な管理モデルとキーの管理を分離できる
- 地域間共通のサービスとキーの保存先を定義できる
短所
- キーへのアクセス管理の全責任をユーザーが負う
- キーのライフサイクル管理の全責任をユーザーが負う
- 追加のセットアップと構成のオーバーヘッド
ユーザーが管理するハードウェアでユーザーが管理するキーを使用したサーバー側暗号化
一部の Azure サービスでは、Host Your Own Key (HYOK) キー管理モデルが可能です。 この管理モードは、保存データを暗号化しても、キーの管理を Microsoft の管理外の独自のリポジトリで行う必要があるシナリオで有用です。 このモデルでのサービスは、外部サイトのキーを使って、データ暗号化キー (DEK) を解読する必要があります。 パフォーマンスと可用性の保証が影響を受け、構成は複雑です。 さらに、サービスは暗号化および複合化操作中に DEK にアクセスできるため、このモデルの全体としてのセキュリティ保証は、キーが Azure Key Vault でユーザーによって管理される場合と似ています。 この結果、特定のキー管理の要件がない限り、このモデルはほとんどの組織に適していません。 これらの制限により、ほとんどの Azure サービスでは、ユーザーが制御するハードウェアでのカスタマー マネージド キーを使用したサーバー側暗号化はサポートされていません。 二重キー暗号化の 2 つのキーのうちの 1 つは、このモデルに従います。
キーへのアクセス
ユーザーが制御するハードウェアでカスタマー マネージド キーを使用したサーバー側暗号化を利用する場合、キー暗号化キーはユーザーが構成したシステムで管理されます。 このモデルをサポートする Azure サービスでは、ユーザーが提供したキー ストアに対しセキュリティ保護された接続を確立できます。
長所
- 使用されるルート キーを完全に制御 – 暗号化キーはユーザーが提供した ストアによって管理されます
- 1 つのマスターで複数のサービスを暗号化する機能
- サービスの全体的な管理モデルとキーの管理を分離できる
- 地域間共通のサービスとキーの保存先を定義できる
短所
- キーの保存、セキュリティ、パフォーマンスおよび可用性の全責任を負う
- キーへのアクセス管理の全責任を負う
- キーのライフサイクル管理の全責任を負う
- 多額のセットアップ、構成、および継続的なメンテナンスのコスト
- ユーザーのデータ センターと Azure データ センター間のネットワークの可用性への依存度が高くなる。
カスタマー マネージド キー (CMK) をサポートするサービス
カスタマー マネージド キーを使ったサーバー側の暗号化をサポートするサービスは、次のとおりです。
* このサービスはデータを保持しません。 一時的なキャッシュがある場合は、Microsoft キーで暗号化されます。
** このサービスでは、カスタマー マネージド キーを使用してサーバー側での暗号化を既にサポートしている、独自の Key Vault、ストレージ アカウント、またはその他のデータ永続化サービスへのデータの格納がサポートされています。
*** ページファイルやスワップ ファイルなどのディスクに一時的に格納される一時的なデータは、Microsoft キー (すべての層) またはカスタマー マネージド キー (Enterprise および Enterprise Flash レベルを使用) で暗号化されます。 詳細については、「Azure Cache for Redis でディスク暗号化を構成する」をご覧ください。