

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# の主要な管理のベストプラクティス AWS KMS
<a name="key-management"></a>

 AWS Key Management Service (AWS KMS) を使用する場合は、いくつかの基本的な設計上の決定を行う必要があります。これには、キーの管理とアクセスに一元化モデルを使用するか、分散モデルを使用するか、使用するキーのタイプ、使用するキーストアのタイプが含まれます。以下のセクションは、組織やユースケースに適した意思決定を行うのに役立ちます。このセクションでは、データとキーを保護するために実行する必要があるアクションを含め、KMS キーを無効化および削除するための重要な考慮事項をまとめます。

**Topics**
+ [集中型モデルまたは分散型モデルの選択](#key-management-model)
+ [カスタマーマネージドキー、 AWS マネージドキー、または AWS 所有キーの選択](#key-management-types)
+ [AWS KMS キーストアの選択](#key-management-stores)
+ [KMS キーの削除と無効化](#key-management-deletion)

## 集中型モデルまたは分散型モデルの選択
<a name="key-management-model"></a>

AWS では、複数の を使用し AWS アカウント 、それらのアカウントを の 1 つの組織として管理することをお勧めします[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)。 AWS KMS keys マルチアカウント環境で を管理するには、2 つの広範なアプローチがあります。

最初のアプローチは、分散型アプローチです。このアプローチでは、これらのキーを使用する各アカウントにキーを作成します。KMS キーを保護対象のリソースと同じアカウントに保存すると、 AWS プリンシパルとキーのアクセス要件を理解しているローカル管理者にアクセス許可を委任しやすくなります。キーポリシーのみを使用して[キー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)の使用を承認するか、 AWS Identity and Access Management (IAM) でキーポリシーと[アイデンティティベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)を組み合わせることができます。

2 番目のアプローチは、1 つまたは少数の指定された KMS キーを維持する一元化されたアプローチです AWS アカウント。暗号化オペレーションにのみキーを使用することを他の アカウントに許可します。キー、そのライフサイクル、およびアクセス許可は、一元化されたアカウントから管理します。他の AWS アカウント にキーの使用を許可しますが、他のアクセス許可は許可しません。外部アカウントは、キーのライフサイクルまたはアクセス許可について何も管理できません。この一元化されたモデルは、委任された管理者またはユーザーによるキーの意図しない削除や特権のエスカレーションのリスクを最小限に抑えるのに役立ちます。

選択するオプションは、いくつかの要因によって異なります。アプローチを選択するときは、次の点を考慮してください。

1. キーとリソースへのアクセスをプロビジョニングする自動プロセスまたは手動プロセスはありますか? これには、デプロイパイプラインやInfrastructure as Code (IaC) テンプレートなどのリソースが含まれます。これらのツールは、多くの にリソース (KMS キー、キーポリシー、IAM ロール、IAM ポリシーなど) をデプロイして管理するのに役立ちます AWS アカウント。これらのデプロイツールがない場合は、キー管理への一元化されたアプローチがビジネスにとってより管理しやすい場合があります。

1. KMS キーを使用するリソース AWS アカウント を含むすべての を管理することができますか? その場合、一元化されたモデルによって管理が簡素化され、キーを管理する AWS アカウント ための切り替えが不要になります。ただし、キーを使用するための IAM ロールとユーザーアクセス許可は、引き続きアカウントごとに管理する必要があります。

1. 独自の AWS アカウント および リソースを持つ顧客またはパートナーに KMS キーを使用するためのアクセスを提供する必要がありますか? これらのキーの場合、一元化されたアプローチにより、顧客やパートナーの管理上の負担を軽減できます。

1. 一元化されたアクセスアプローチまたはローカルアクセスアプローチのいずれかでより適切に解決された AWS リソースへのアクセスに対する認可要件はありますか? 例えば、異なるアプリケーションやビジネスユニットが独自のデータのセキュリティを管理する場合は、キー管理への分散アプローチの方が適しています。

1. のサービス[リソースクォータ](https://docs.aws.amazon.com/kms/latest/developerguide/resource-limits.html)を超えていますか AWS KMS? これらのクォータは ごとに設定されるため AWS アカウント、分散モデルはアカウント間で負荷を分散し、サービスクォータを効果的に乗算します。
**注記**  
[リクエストクォータ](https://docs.aws.amazon.com/kms/latest/developerguide/requests-per-second.html)を考慮する場合、キーの管理モデルは関係ありません。これらのクォータは、キーを所有または管理するアカウントではなく、キーに対してリクエストを行うアカウントプリンシパルに適用されるためです。

一般に、一元化された KMS キーモデルの必要性を明確にしない限り、分散アプローチから始めることをお勧めします。

## カスタマーマネージドキー、 AWS マネージドキー、または AWS 所有キーの選択
<a name="key-management-types"></a>

独自の暗号化アプリケーションで使用するために作成および管理する KMS キーは、*カスタマーマネージドキー*と呼ばれます。 AWS のサービス は、カスタマーマネージドキーを使用して、サービスがユーザーに代わって保存するデータを暗号化できます。ライフサイクルとキーの使用を完全に制御する場合は、カスタマーマネージドキーをお勧めします。アカウント内でカスタマーマネージドキーを使用する場合、月額料金が発生します。さらに、キーを使用または管理するリクエストには、使用コストが発生します。詳細については、「[AWS KMS 料金表](https://aws.amazon.com/kms/pricing/)」を参照してください。

 AWS のサービス でデータを暗号化したいが、キー管理のオーバーヘッドやコストは不要な場合は、 *AWS マネージドキー*を使用できます。このタイプのキーはアカウントに存在しますが、特定の状況でのみ使用できます。これは、運用 AWS のサービス している のコンテキストでのみ使用でき、キーを含むアカウント内のプリンシパルのみが使用できます。これらのキーのライフサイクルやアクセス許可については、何も管理できません。一部の は AWS マネージドキー AWS のサービス を使用します。 AWS マネージドキーエイリアスの形式は です`aws/<service code>`。たとえば、 `aws/ebs`キーは、キーと同じアカウントの Amazon Elastic Block Store (Amazon EBS) ボリュームの暗号化にのみ使用でき、そのアカウントの IAM プリンシパルのみが使用できます。 AWS マネージドキーは、そのアカウントのユーザーとそのアカウントのリソースに対してのみ使用できます。 AWS マネージドキーで暗号化されたリソースを他のアカウントと共有することはできません。これがユースケースの制限である場合は、代わりにカスタマーマネージドキーを使用することをお勧めします。そのキーの使用を他のアカウントと共有できます。アカウントに AWS マネージドキーが存在する場合は課金されませんが、このキータイプの使用は、キー AWS のサービス に割り当てられた によって課金されます。

 AWS マネージドキーは、2021 年 AWS のサービス の時点で新しい 用に作成されなくなったレガシーキータイプです。代わりに、新しい (およびレガシー) AWS のサービス は *AWS 所有キー*を使用してデフォルトでデータを暗号化します。 AWS 所有キーは、 が複数の で使用するために AWS のサービス 所有および管理する KMS キーのコレクションです AWS アカウント。これらのキーは にはありませんが AWS アカウント、 AWS のサービス はアカウント内のリソースを保護するためにキーを使用できます。

きめ細かな制御が最も重要な場合はカスタマーマネージドキーを使用し、利便性が最も重要な場合は AWS 所有キーを使用することをお勧めします。

次の表に、各キータイプのキーポリシー、ログ記録、管理、および料金の違いを示します。キータイプの詳細については、「 の[AWS KMS 概念](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html)」を参照してください。


****  

| 考慮事項 | カスタマーマネージドキー | AWS マネージドキー | AWS 所有キー | 
| --- | --- | --- | --- | 
| キーポリシー | カスタマーが排他的に制御する | サービスによって制御され、カスタマーは閲覧可能 | 排他的に制御され、データを暗号化 AWS のサービス する でのみ表示可能 | 
| ログ記録 | AWS CloudTrail カスタマー証跡またはイベントデータストア | CloudTrail カスタマー証跡またはイベントデータストア | カスタマーは閲覧できない | 
| ライフサイクル管理 | お客様がローテーション、削除、および AWS リージョン | AWS のサービス がローテーション (年単位）、削除、リージョンを管理する | AWS のサービス がローテーション (年単位）、削除、リージョンを管理する | 
| 料金 | キー存在に対する月額料金 (時間単位で按分）。呼び出し元には API の使用料金が請求されます。 | キーの存在には料金はかかりません。呼び出し元には API の使用料金がかかります。 | カスタマーへの請求はなし | 

## AWS KMS キーストアの選択
<a name="key-management-stores"></a>

*キーストア*は、暗号化キーマテリアルを保存して使用するための安全な場所です。キーストアの業界のベストプラクティスは、セキュリティレベル 3 の [NIST Federal Information Processing Standards (FIPS) 140 暗号化モジュール検証プログラムで検証されたハードウェアセキュリティモジュール (HSM)](https://csrc.nist.gov/Projects/cryptographic-module-validation-program/modules-in-process/IUT-List) と呼ばれるデバイスを使用することです。支払いの処理に使用されるキーストアをサポートする他のプログラムもあります。 [AWS Payment Cryptography](https://docs.aws.amazon.com/payment-cryptography/latest/userguide/what-is.html)は、支払いワークロードに関連するデータを保護するために使用できるサービスです。

AWS KMS は、 AWS KMS を使用して暗号化キーを作成および管理するときにキーマテリアルを保護するのに役立つ複数のキーストアタイプをサポートしています。が提供するすべてのキーストアオプション AWS KMS は、セキュリティレベル 3 の FIPS 140 で継続的に検証されます。 AWS 演算子を含むすべてのユーザーが、プレーンテキストキーにアクセスしたり、アクセス許可なしで使用したりできないように設計されています。使用可能なキーストアのタイプの詳細については、 AWS KMS ドキュメントの[「キーストア](https://docs.aws.amazon.com/kms/latest/developerguide/key-store-overview.html)」を参照してください。

[AWS KMS 標準キーストア](https://docs.aws.amazon.com/kms/latest/developerguide/key-store-overview.html#default-key-store)は、ほとんどのワークロードに最適な選択肢です。別のタイプのキーストアを選択する必要がある場合は、規制やその他の要件 (内部など) でこの選択を必須としているかどうかを慎重に検討し、コストと利点を慎重に検討してください。

## KMS キーの削除と無効化
<a name="key-management-deletion"></a>

KMS キーを削除すると、大きな影響を与える可能性があります。今後使用しない KMS キーを削除する前に、キーの状態を**無効に設定するのが適切かどうかを検討してください**。キーが無効になっている間は、暗号化オペレーションには使用できません。まだ に存在し AWS、必要に応じて後で再有効化できます。無効になっているキーには、引き続きストレージ料金が発生します。キーがデータやデータキーを保護しないと確信できるまでは、キーを削除するのではなく、キーを無効にすることをお勧めします。

**重要**  
キーの削除は慎重に計画する必要があります。対応するキーが削除された場合、データは復号できません。 AWS には、削除されたキーが削除された後に復元する手段はありません。の他の重要なオペレーションと同様に AWS、キーの削除をスケジュールし、キーの削除に多要素認証 (MFA) を必要とするユーザーを制限するポリシーを適用する必要があります。

キーの偶発的な削除を防ぐため、 は、キーを削除する前に、`DeleteKey`呼び出しの実行から 7 日間のデフォルトの最小待機期間 AWS KMS を適用します。[待機期間は](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-scheduling-key-deletion.html)、最大値の 30 日に設定できます。待機期間中、キーは**削除保留中**の状態で AWS KMS に保存されます。暗号化または復号オペレーションには使用できません。暗号化または復号のために**削除保留中**状態のキーを使用しようとすると、 にログ記録されます AWS CloudTrail。これらのイベントの [ Amazon CloudWatch アラームは、CloudTrail ログで設定できます](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys-creating-cloudwatch-alarm.html)。 CloudTrail これらのイベントでアラームを受け取った場合は、必要に応じて削除プロセスをキャンセルすることを選択できます。待機期間が終了するまで、**削除保留中**の状態からキーを復元し、**無効**または**有効**状態に復元できます。

マルチリージョンキーを削除するには、元のコピーの前にレプリカを削除する必要があります。詳細については、[「マルチリージョンキーの削除](https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html)」を参照してください。

インポートされたキーマテリアルでキーを使用している場合は、インポートされたキーマテリアルをすぐに削除できます。これは、いくつかの方法で KMS キーを削除する場合とは異なります。`DeleteImportedKeyMaterial` アクションを実行すると、 はキーマテリアル AWS KMS を削除し、キーの状態は**インポート保留中**に変わります。キーマテリアルを削除すると、そのキーはすぐに使用できなくなります。待機期間はありません。キーを再度使用できるようにするには、同じキーマテリアルを再度インポートする必要があります。KMS キーの削除の待機期間は、インポートされたキーマテリアルを持つ KMS キーにも適用されます。

データキーが KMS キーによって保護されていて、 によってアクティブに使用されている場合 AWS のサービス、関連する KMS キーが無効になっているか、インポートされたキーマテリアルが削除されても、すぐには影響を受けません。たとえば、インポートされたマテリアルを持つキーを使用して [SSE-KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html) でオブジェクトを暗号化したとします。オブジェクトを Amazon Simple Storage Service (Amazon S3) バケットにアップロードしています。オブジェクトをバケットにアップロードする前に、マテリアルをキーにインポートします。オブジェクトがアップロードされたら、インポートされたキーマテリアルをそのキーから削除します。オブジェクトは暗号化された状態でバケットに残りますが、削除されたキーマテリアルがキーに再インポートされるまでオブジェクトにアクセスすることはできません。このフローでは、キーからキーマテリアルをインポートおよび削除するための正確な自動化が必要ですが、環境内で追加のレベルの制御を提供することができます。

AWS は、KMS キーのスケジュールされた削除を (必要に応じて) モニタリングおよび修復するのに役立つ規範的なガイダンスを提供します。詳細については、[「スケジュールされた AWS KMS キーの削除のモニタリングと修復](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-and-remediate-scheduled-deletion-of-aws-kms-keys.html)」を参照してください。