翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のベストプラクティス AWS Encryption SDK
AWS Encryption SDK は、業界標準とベストプラクティスを使用してデータを簡単に保護できるように設計されています。デフォルト値では多くのベストプラクティスが選択されており、一部のプラクティスはオプションですが、実用的であるときは常に推奨されます。
**最新バージョンを使用する**
の使用を開始するときは AWS Encryption SDK、任意の[プログラミング言語で](programming-languages.md)提供されている最新バージョンを使用します。を使用している場合は AWS Encryption SDK、できるだけ早く各最新バージョンにアップグレードしてください。そうすると、推奨設定を使用し、新しいセキュリティプロパティを利用してデータを保護できるようになります。移行とデプロイのガイダンスなど、サポート対象バージョンの詳細については、「[サポートとメンテナンス](introduction.md#support)」と「[のバージョン AWS Encryption SDK](about-versions.md)」を参照してください。
新しいバージョンでコード内の要素が非推奨になった場合は、できるだけ早く置き換えてください。非推奨の警告とコードコメントにより、通常は適切な代替手段が推奨されます。
大幅なアップグレードを容易にし、エラーの発生を抑えるために、一時的または移行的なリリースが提供されることがあります。これらのリリースとそれに付随するドキュメントを使用すると、本番ワークフローを中断することなくアプリケーションをアップグレードできます。
**デフォルト値を使用する**
は、ベストプラクティスをデフォルト値に AWS Encryption SDK 設計します。可能な限り、デフォルト値を使用してください。デフォルトが実用的でない場合は、署名なしのアルゴリズムスイートなどの代替手段が提供されます。上級ユーザーは、カスタムキーリング、マスターキープロバイダー、暗号化マテリアルマネージャー (CMM) などのカスタマイズも可能です。これらの上級者向けの代替手段は慎重に使用し、可能な限りセキュリティエンジニアがその代替手段を検証してください。
**暗号化コンテキストを使用する**
暗号化オペレーションのセキュリティを向上させるには、データを暗号化するためのすべてのリクエストに、意味のある値で[暗号化コンテキスト](concepts.md#encryption-context)を含めます。暗号化コンテキストの使用はオプションですが、暗号化のベストプラクティスとして使用することをお勧めします。暗号化コンテキストでは、 AWS Encryption SDKで認証された暗号化に追加認証データ (AAD) が提供されます。暗号化コンテキストはシークレットではありませんが、暗号化データの[整合性と真正性を保護](https://aws.amazon.com/blogs/security/how-to-protect-the-integrity-of-your-encrypted-data-by-using-aws-key-management-service-and-encryptioncontext/)できます。
では AWS Encryption SDK、暗号化時にのみ暗号化コンテキストを指定します。復号時、 は が AWS Encryption SDK 返す暗号化されたメッセージのヘッダーで暗号化コンテキスト AWS Encryption SDK を使用します。アプリケーションでプレーンテキストのデータを返す前に、メッセージの暗号化に使用した暗号化コンテキストが、メッセージの復号化に使用した暗号化コンテキストに含まれていることを確認します。詳細については、プログラミング言語の例を参照してください。
コマンドラインインターフェイスを使用すると、 AWS Encryption SDK は暗号化コンテキストを検証します。
**ラッピングキーを保護する**
は、各プレーンテキストメッセージを暗号化するための一意のデータキー AWS Encryption SDK を生成します。次にデータキーは、指定したラッピングキーで暗号化されます。ラッピングキーが失われたり削除されたりすると、暗号化されたデータは回復できません。キーが保護されていない場合、データが脆弱になる可能性があります。
[AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (AWS KMS) など、安全なキーインフラストラクチャで保護されているラッピングキーを使用してください。Raw AES キーまたは Raw RSA キーを使用する場合は、セキュリティ要件を満たすランダム性と耐久性のあるストレージのソースを使用します。ラッピングキーを生成してハードウェアセキュリティモジュール (HSM)、または HSMs AWS CloudHSMを提供するサービスに保存することがベストプラクティスです。
キーインフラストラクチャの認可メカニズムを使用して、ラッピングキーへのアクセスを、必要とするユーザーのみに制限してください。最小特権などのベストプラクティスの原則を実装します。を使用する場合は AWS KMS keys、[ベストプラクティスの原則](https://docs.aws.amazon.com/kms/latest/developerguide/iam-policies.html#iam-policies-best-practices)を実装するキーポリシーと IAM ポリシーを使用します。
**ラッピングキーを指定する**
復号化時にも暗号化時にも、明示的に [ラッピングキーを指定する](configure.md#config-keys) ことが常にベストプラクティスです。これを行うと、 は指定したキーのみ AWS Encryption SDK を使用します。この方法では、意図した暗号化キーのみを使用することが保証されます。ラッピングキーの場合、別の AWS KMS AWS アカウント または リージョンでキーを誤って使用したり、使用権限のないキーで復号化しようとしたりするのを防ぐことで、パフォーマンスも向上します。
暗号化時に、 AWS Encryption SDK 供給するキーリングとマスターキープロバイダーでは、ラッピングキーを指定する必要があります。使用されるのは、ユーザーが指定したすべてのラッピングキーであり、またそれらのみです。RAW AES キーリング、Raw RSA キーリング、および JCEMasterKey で暗号化および復号化する場合も、ラッピングキーを指定する必要があります。
ただし、 AWS KMS キーリングとマスターキープロバイダーで復号する場合、ラッピングキーを指定する必要はありません。は、暗号化されたデータキーのメタデータからキー識別子を取得 AWS Encryption SDK できます。ただし、ベストプラクティスとして、ラッピングキーを指定することをお勧めします。
AWS KMS ラッピングキーを使用する際にこのベストプラクティスをサポートするには、以下をお勧めします。
+ ラッピング AWS KMS キーを指定するキーリングを使用します。暗号化および復号化を行う場合、これらのキーリングでは、指定したラッピングキーのみが使用されます。
+ AWS KMS マスターキーとマスターキープロバイダーを使用する場合は、 [のバージョン 1.7.*x*](about-versions.md#version-1.7)で導入された strict モードコンストラクタを使用します AWS Encryption SDK。指定したラッピングキーでのみ暗号化および復号化するプロバイダーが作成されます。ラッピングキーで常に復号化するマスターキープロバイダーのコンストラクタは、バージョン 1.7.*x* で非推奨となり、バージョン 2.0.*x* で削除されました。
復号化の AWS KMS ラッピングキーを指定するのが実用的ではない場合、検出プロバイダーを使用できます。C および JavaScript AWS Encryption SDK の [AWS KMS は検出キーリング](use-kms-keyring.md#kms-keyring-discovery)をサポートします。検出モードのマスターキープロバイダーは、バージョン 1.7.*x* 以降の Java および Python で使用できます。これらの検出プロバイダーは、 AWS KMS ラッピングキーによる復号にのみ使用され、データキーを暗号化したラッピングキーを使用する AWS Encryption SDK ように に明示的に指示します。
検出プロバイダーを使用する必要がある場合は、検出フィルター機能を使用して、使用するラッピングキーを制限します。例えば、[AWS KMS リージョン検出キーリング](use-kms-keyring.md#kms-keyring-regional)では、特定の AWS リージョンのラッピングキーのみを使用します。特定の の[ラッピング](migrate-keyrings-v2.md) AWS KMS キーのみを使用するようにキーリングと AWS KMS [マスターキープロバイダー](migrate-mkps-v2.md#migrate-mkp-discovery-mode)を設定することもできます AWS アカウント。また、常にキーポリシーと IAM ポリシーを使用して、 AWS KMS ラッピングキーへのアクセスを制御します。
**デジタル署名を使用する**
アルゴリズムスイートを署名とともに使用することがベストプラクティスです。[デジタル署名](concepts.md#digital-sigs)では、メッセージ送信者がメッセージを送信する権限があることが確認され、メッセージの整合性が保護されます。のすべてのバージョンでは、デフォルトで署名付きのアルゴリズムスイート AWS Encryption SDK が使用されます。
セキュリティ要件にデジタル署名が含まれていない場合は、デジタル署名なしのアルゴリズムスイートを選択できます。ただし、あるユーザーのグループがデータを暗号化し、別のユーザーグループがそのデータを復号化する場合は特に、デジタル署名の使用をお勧めします。
**キーコミットメントを使用する**
キーコミットメントセキュリティ機能を使用することがベストプラクティスです。[キーコミットメント](concepts.md#key-commitment) では、データを暗号化した一意の [データキー](concepts.md#DEK) の ID が確認され、暗号文を復号化して複数のプレーンテキストメッセージが生成されることが防止されます。
AWS Encryption SDK は、[バージョン 2.0.*x* 以降のキーコミットメントによる暗号化と復号化を完全にサポートします](about-versions.md#version-2)。デフォルトでは、すべてのメッセージの暗号化と復号化はキーコミットメントで行われます。[のバージョン 1.7.*x*](about-versions.md#version-1.7) では、キーコミットメントを使用して暗号文を復号 AWS Encryption SDK できます。前バージョンのユーザーでも、バージョン 2.0.*x* を正常にデプロイできるように設計されています。
キーコミットメントでは[新しいアルゴリズムスイート](supported-algorithms.md)および[新しいメッセージ形式](message-format.md)がサポートされ、キーコミットメントを使用しない暗号化テキストと比較してわずか 30 バイトだけ大きい暗号化テキストを生成できます。この設計により、パフォーマンスへの影響が最小限に抑えられるため、ほとんどのユーザーはキーコミットメントの利点を享受できます。アプリケーションがサイズとパフォーマンスに非常に敏感である場合は、[コミットメントポリシー](concepts.md#commitment-policy)設定を使用してキーコミットメントを無効にするか、コミットメントなしでメッセージを復号 AWS Encryption SDK することを に許可しますが、必要な場合に限ります。
**暗号化されたデータキーの数を制限する**
復号化するメッセージ、特に信頼できないソースからのメッセージでは、[暗号化されたデータキーの数を制限する](configure.md#config-limit-keys) ことがベストプラクティスです。多数の暗号化されたデータキーでメッセージを復号化すると、復号化できない場合に、遅延の延長、コストの拡大、アプリケーションやアカウントを共有する他のユーザーの制限が発生し、キーインフラストラクチャを使い果たす可能性があります。制限がない場合、暗号化されたメッセージには最大 65,535 (2^16 - 1) の暗号化されたデータキーを使用できます。詳細については、「[暗号化されたデータキーの制限](configure.md#config-limit-keys)」を参照してください。
これらのベストプラクティスの基礎となる AWS Encryption SDK セキュリティ機能の詳細については、 *AWS セキュリティブログ*の[「クライアント側の暗号化の改善: 明示的な KeyIds とキーコミットメント](https://aws.amazon.com/blogs/security/improved-client-side-encryption-explicit-keyids-and-key-commitment/)」を参照してください。