AWS Key Management Service よくある質問

AWS KMS はお客様が定義した使用および管理ポリシーを実行します。自分のアカウントや他のアカウントの IAM ユーザーやロールに、キーの使用や管理を許可するかどうかを選択できます。

AWS KMS では、AWS の従業員を含めて誰もこのサービスからプレーンテキストの KMS キーを取得できないように設計されています。AWS KMS は、FIPS 140-2 に基づき検証済みまたは検証段階にあるハードウェアセキュリティモジュール (HSM) を使用して、キーの機密性と完全性を保護しています。HSM に残っているユーザーのプレーンテキスト KMS キーがディスクに書き込まれることはなく、ユーザーがリクエストする暗号化操作の実行に必要な時間に HSM の揮発性メモリでのみ使用されます。サービスホストのソフトウェアと AWS KMS HSM ファームウェアへのアップデートは、Amazon 内の独立したグループおよび FIPS 140-2 を順守した NIST 認証のラボによる監査と確認がなされたマルチパーティーアクセスコントロールで制御されています。

セキュリティ管理に関する詳細は、AWS KMS cryptographic details tech paper をご覧ください。AWS KMS HSM に対する FIPS 140-2 証明書と関連するセキュリティポリシーを確認して、AWS KMS HSM がどのようにして FIPS 140-2 のセキュリティ要件を満たしているかの詳細を確認できます。また、AWS Artifact から System and Organization Controls (SOC) レポートのコピーをダウンロードすると、KMS キーを保護するためにサービスで使用されているセキュリティ管理についてさらに詳しくご確認いただけます。

何もする必要はありません。作成日やオリジンに関係なく、すべての AWS KMS キーは FIPS 140-2 セキュリティレベル 3 で検証された HSM を使用して自動的に保護されます。

FIPS 140-2 セキュリティレベル 3 の検証済みの HSM は、AWS KMS が提供されているすべての AWS リージョンにデプロイされています。
注: 規制により、中国リージョンの AWS KMS は NIST FIPS HSM を使用でません。代替として中国の国家商業暗号管理局 (OSCCA) 認定の HSM を使用します。

AWS KMS は 2 階層のサービスです。API エンドポイントは、完全な前方秘匿性をサポートする TLS 暗号スイートのみを用いた HTTPS 接続上でのクライアントリクエストを受け取ります。これらの API エンドポイントは、AWS KMS HSM または KMS カスタムキーストア機能を使用している場合は AWS CloudHSM クラスターに、リクエストを暗号化操作のために送る前に、これを認証、承認します。

お使いのアプリケーションを、リージョン固有の FIPS 140-2 で検証された HTTPS エンドポイントに接続するように設定します。AWS KMS FIPS 140-2 で検証された HTTPS エンドポイントは OpenSSL FIPS オブジェクトモジュールを用いています。OpenSSL モジュールのセキュリティポリシーはこちらで確認できます。FIPS 140-2 で検証された API エンドポイントは、AWS KMS が提供されているすべての商用リージョンでご利用いただけます。

はい。AWS KMS は、PCI DSS 3.2.1 の暗号化とキー管理要件 (主に セクション 3.5 と 3.6 で参照) を満たすのに役立つ機能とセキュリティ管理を有していることが検証されています。

AWS の PCI DSS 準拠サービスの詳細については、「PCI DSS のよくある質問」を参照してください。

AWS KMS がデータキーを生成し、お客様独自のアプリケーションで使用するために返却するようにリクエストできます。データキーはお客様が AWS KMS で定義したルートキーによって暗号化されます。そのため、暗号化されたデータキーは暗号化されたデータと合わせて安全に保存できます 。オリジナルのルートキー (暗号化されたデータキーの復号化に使用されたもの) の使用許可のあるユーザーのみが、暗号化されたデータキー (およびソースデータ) を復号化できます。

いいえ。AWS KMS キーは、その安全性を検証し、一貫して実施されるお客様のポリシーを実装し、一元化した使用状況のログを提供するために、サービス内でのみ作成および使用されます。

AWS KMS によって生成された単一リージョンの KMS キーは、それが作成されたリージョンでのみ保存および使用されます。AWS KMS マルチリージョンキーを使用すると、マルチリージョンのプライマリキーを同じ AWS パーティション内の複数のリージョンにレプリケートすることを選択できます。

AWS CloudTrail のログは、管理リクエスト (作成、更新、無効化、ポリシーの編集など) および暗号化リクエスト (暗号化/復号化など) など、すべての AWS KMS API リクエストを表示します。アカウントで CloudTrail を有効にすると、このログを確認できます。

CloudHSM では、Amazon 仮想プライベートクラウド (VPC) でのキーの保存と使用のために、検証済みシングルテナント HSM クラスターを利用できます。ユーザーは、AWS とは独立した認証メカニズムで、ユーザーのキーがどのように使われるかについて自分だけのコントロールができます。ユーザーは、Amazon EC2 で実行するアプリケーションを操作するのと同様のやり方で、ユーザーの CloudHSM クラスター内のキーを操作します。CloudHSM を使用して様々なユースケースをサポートでき、これにはデジタル著作権管理、パブリックキーインフラストラクチャー (PKI)、ドキュメントへの署名、また PKCS#11、Java JCE、またはMicrosoft CNG インターフェイスを用いた暗号化機能などを含みます。
 

AWS KMS では、アプリケーションおよびサポートされている AWS のサービスが世界中の複数のリージョンで使用する暗号化キーを単一のコンソールから作成、制御できます。このサービスは、FIPS 140-2 で検証された、あるいは検証中の FIPS HSM を使用して、キーのセキュリティを保護します。AWS KMS ですべてのキーを一元管理することにより、キーを使用できるユーザーとその条件、更新する時期、管理できるユーザーを設定できます。AWS KMS と CloudTrail との統合により、キーの使用状況の監査が可能になるため、規制およびコンプライアンスの対応をサポートできます。アプリケーションからの AWS KMS の操作は、サービス API を直接呼び出す場合は AWS SDK を用いて行い、クライアント側の暗号化を実行する場合は、AWS KMS と統合されている他の AWS のサービス経由か AWS Encryption SDK を用いて行います。

AWS KMS については、お客様が使用した分に対してのみ料金が発生します。最低料金はありません。サービスの利用を開始するためのセットアップ料金や契約はありません。月末に、その月の使用料金が自動的にお客様のクレジットカードに請求されます。

作成したすべての KMS キー、および毎月のサービスに対して行われた API リクエストで無料利用枠を超過した分に対して請求されます。
 

料金の最新情報については、「AWS KMS の料金ページ」を参照してください。

はい。AWS 無料利用枠を利用すれば、すべてのリージョンで AWS KMS の使用を無料*で開始できます。AWS のサービスによってお客様のために作成された AWS 管理の AWS KMS キーは、無料でお客様のアカウントに保存できます。使用に対しても無料利用枠があるため、毎月、無料で決められた数のリクエストをサービスに対して実行できます。無料利用枠を含む料金の最新情報については、「AWS KMS の料金ページ」を参照してください。

*非対称 KMS キー含む API リクエスト、および GenerateDataKeyPair と GenerateDataKeyPairWithoutPlaintext API への API リクエストは無料利用枠に含まれません。

別途記載がない限り、表示される料金には VAT、売上税その他取引に対して適用される一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS サービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細については、こちらを参照してください。

はい。独自のキー管理インフラストラクチャから AWS KMS にキーのコピーをインポートして、統合された AWS のサービスで、または独自のアプリケーションでそれを使用できます。

インポートされたキーを使用して、AWS KMS におけるキーの作成、ライフサイクル管理、および耐久性をより確実に制御できます。インポートされたキーは、コンプライアンス要件を満たすように設計されています。これには、インフラストラクチャのキーの安全なコピーを生成または維持する機能、および AWS インフラストラクチャからキーのインポートのコピーを直接削除する機能が含まれます。

対称キー、非対称キー (RSA および楕円曲線)、および HMAC キーをインポートできます。

インポート処理中、サポートされているラッピングアルゴリズムを使用して AWS KMS が提供するパブリックキーでキーをラップする必要があります。これは、暗号化されたキーが AWS KMS のみによって復号化されることを検証します。

大きな違いは次の 2 点です。
 

1. KMS にキーをインポートする場合は、随時それを再インポートできるように、キーのコピーをキー管理インフラストラクチャに維持する責任があります。ただし、AWS KMS により生成したキーの場合は、ユーザーがそのキーの削除を予定に入れるまで、AWS によりキーの可用性、セキュリティ、および耐久性を確認します。
2. インポートしたキーには有効期限を設定できます。有効期間を過ぎると、AWS KMS は自動的にキーマテリアルを削除します。インポートしたキーマテリアルをオンデマンドで削除することもできます。いずれの場合でもキーマテリアル自体は削除されますが、将来、キーマテリアルを再度インポートできるように、AWS KMS の KMS キーリファレンスと関連するメタデータは保持されます。AWS KMS によって生成されたキーには有効期限はなく、すぐに削除することはできません。7 日から 30 日の待機期間が必須です。カスタマ―管理の KMS キーはすべて、キーマテリアルがインポートされたものかどうかに関わらず、手動で無効にすることも、削除予定を設定することも可能です。この場合、内在するキーマテリアルだけでなく、KMS キー自体が削除されます。

元の AWS KMS キーを使用して、有効期限が有効なキーマテリアルのコピーを AWS KMS に再インポートすることにより、使用できます。

はい。キーを一旦お客様の AWS KMS キーにインポートすると、インポートされたキーの有効期限までの時間を知らせる CloudWatch メトリクスが数分ごとに届きます。また、AWS KMS キーにインポートされたキーの有効期限が切れると、CloudWatch イベントが送信されます。可用性のリスクを回避するために、こうしたメトリクスとイベントに基づいて動作し、新しい有効期間で自動的にキーを再インポートするロジックを構築できます。

AWS KMS は、暗号化と復号化のための KMS キーを作成する際に 256 ビットのキーをサポートします。発信者に返される生成済みデータキーは、256 ビット、128 ビット、または最大 1024 バイトまでの任意の値にすることができます。AWS KMS がお客様の代わりに 256 ビットの KMS キーを使用して暗号化または復号化を行う場合、Galois Counter Mode の AES アルゴリズム (AES-GCM) が使用されます。

AWS KMS では、RSA 2048、RSA 3072、RSA 4096、ECC NIST P-256、ECC NIST P-384、ECC NIST-521、ECC SECG P-256k1 の非対称キータイプをサポートしています。 AWS KMS では、RSAES_OAEP_SHA_1 と RSAES_OAEP_SHA_256 の暗号化アルゴリズムおよび RSA 2048、RSA 3072、RSA 4096 のキータイプをサポートしています。暗号化アルゴリズムは、楕円曲線キータイプ (ECC NIST P-256、ECC NIST P-384、ECC NIST-521、ECC SECG P-256k1) とともに使用することはできません。

楕円曲線キータイプを使用する場合、AWS KMS は ECDH キーアグリーメントアルゴリズムをサポートします。

RSA キータイプを使用する場合、AWS KMS では、RSASSA_PSS_SHA_256、RSASSA_PSS_SHA_384、RSASSA_PSS_SHA_512、RSASSA_PKCS1_V1_5_SHA_256、RSASSA_PKCS1_V1_5_SHA_384、RSASSA_PKCS1_V1_5_SHA_512 の署名アルゴリズムをサポートします。楕円曲線キータイプを使用する場合、AWS KMS では、ECDSA_SHA_256、ECDSA_SHA_384、ECDSA_SHA_512 の署名アルゴリズムをサポートします。

非対称キーマテリアルの公開部分は AWS KMS で生成されます。この公開部分は、「Verify」API を呼び出すことでデジタル署名検証に使用し、「Encrypt」API を呼び出すことでパブリックキー暗号化に使用できます。パブリックキーは、検証または暗号化を行うために AWS KMS 以外の場所で使用することもできます。GetPublicKey API を呼び出して非対称 KMS キーの公開部分を取得できます。

サイズ制限は 4 KB です。4 KB よりも大きいデータにデジタル署名を行う必要がある場合は、データのメッセージダイジェストを作成して、AWS KMS に送信できます。デジタル署名は、データのダイジェストに対して作成され、返されます。Sign API リクエストでパラメータとしてメッセージ全体を送信するか、メッセージダイジェストを送信するかどうかを指定します。非対称オペレーションを使用する必要がある Encrypt API、Decrypt API、Re-Encrypt API に送信されるデータも 4 KB 未満にする必要があります。

コンソールで、[キータイプ] という新しいフィールドが各キーに用意されます。このフィールドには、キーのタイプを示す Asymmetric Key または Symmetric Key という値が表示されます。DescribeKey API を呼び出すと [KeyUsage] フィールドが返されます。このフィールドでは、キーを署名、HMAC の生成、または暗号化に使用できるかどうかを指定します。

いいえ。非対称 または HMAC KMS キーの自動キー更新はサポートされていません。一般に、非対称キーや HMAC キーをローテーションすると、過去に他のユーザーと共有していたキーのインスタンスをすべて廃棄して置き換える必要があるため、既存のワークロードに大きな支障をきたす可能性があります。必要に応じて、新しい KMS キーを作成し、古い KMS キーから新しい KMS キーに既存のキーエイリアスをマッピングすることで、手動で更新できます。

いいえ。KMS キーを作成するときに、キーを復号オペレーションに使用できるのか、署名オペレーションに使用できるのかを指定する必要があります。RSA キータイプは、署名オペレーションまたは暗号化オペレーションに使用できますが、両方には使用できません。楕円曲線キータイプは、署名オペレーションにのみ使用できます。

はい。1 秒あたりのリクエスト数の制限は、キータイプとアルゴリズムによって異なります。詳細については、「AWS KMS の制限」に関するページを参照してください。

いいえ。カスタムキーストア機能は非対称キーでは使用できません。

直接はできません。AWS KMS では、デジタル証明書を保存したり、デジタル証明書を作成した非対称 KMS キーと関連付けたりしません。AWS Private Certificate Authority などの認証機関に非対称 KMS キーの公開部分に対して証明書を発行してもらうことができます。こうすることで、お客様のパブリックキーを使用しているエンティティで、そのパブリックキーが本当にお客様に属することを確認できます。

AWS KMS カスタムキーストア機能は CloudHSM によって提供された制御機能を AWS KMS の一元化や使いやすさと結び付けます。独自の CloudHSM クラスターを設定し、デフォルトの AWS KMS キーストアというよりは、お使いのキーの専用キーストアとして使用することを AWS KMS に許可します。AWS KMS にキーを作成すると、CloudHSM クラスターでキーマテリアルを生成することを選択できます。カスタムキーストアで生成した KMS キーは、CloudHSM クラスターの HSM をプレーンテキストのままにして置くことは絶対になく、こうしたキーを使用する AWS KMS 操作はお使いの HSM のみで実行されます。他のあらゆる点において、カスタムキーストアに保存された KMS キーは、他の AWS KMS キーと一致します。

カスタムキーストアを使用するのが適切であるかどうかを判断するためのもう 1 つのガイダンスが、こちらのブログに記載されています。

CloudHSM クラスターを制御しているため、AWS KMS とは無関係に KMS キーのライフサイクルを管理するオプションがあります。カスタムキーストアが便利であると言える理由は 3 つあります。まず、明らかにシングルテナントの HSM か直接管理する HSM で保護することが必要なキーがある場合があります。2 番目として、キーマテリアルを AWS KMS からすぐに削除し、自律的な方法でそれを証明できることが必要な場合があります。3 番目に、AWS KMS または CloudTrail とは無関係に、使用しているすべてのキーを監査できるという要件がある場合があります。

CloudHSM にバックアップされたカスタムキーストアのキーの管理を、デフォルト AWS KMS キーストアと比較すると、2 つの相違点があります。キーマテリアルをカスタムキーストアにインポートすることはできないので、AWS KMS に自動でキーを更新させることはできません。生成可能なキーの種類、キーでエイリアスを使用する方法、ポリシーの定義方法など、他のあらゆる点において、カスタムキーストアに保存されたキーは、他の AWS KMS カスタマー管理の KMS キーと同じ方法で管理されます。

いいえ、CloudHSM にバックアップされた AWS KMS のカスタムキーストアに保存、管理できるのは、カスタマー管理の KMS キーのみです。データを暗号化するために AWS の他のサービスによって作成された AWS 管理の KMS キーは、常に AWS KMS のデフォルトのキーストアで生成され、保存されます。

いいえ、AWS KMS に KMS キーを使用してデータの暗号化と復号化をするように要求する API は、同じように処理されます。認証と認可の処理は、キーが保存されている場所とは無関係に作動します。CloudHSM にバックアップされたカスタムキーストアでキーを使用するアクティビティはすべて、同じように CloudTrail にもログされます。ただし、実際の暗号化操作は、カスタムキーストアまたはデフォルトの AWS KMS キーストアのいずれか一方でのみ行われます。

AWS KMS が CloudTrail にログするアクティビティに加えて、カスタムキーストアの使用には、3 種類以上の監査メカニズムがあります。まず、CloudHSM はクラスターの作成や HSM の追加および削除など、すべての API アクティビティも CloudTrail にログを記録しています。第 2 に、各クラスターもまた、ユーザーとキー管理アクティビティを記録するために、独自のローカルログを残します。第 3 に、CloudHSM インスタンスは、ローカルユーザーとキー管理アクティビティログを AWS CloudWatch にコピーします。

AWS KMS カスタムキーストアを使用すると、キーを AWS KMS で使用できるかどうかを検証する責任はお客様が負うことになります。CloudHSM の設定でエラーになったり、CloudHSM クラスター内のキーマテリアルを削除したりすると、可用性に影響が出る場合があります。使用する HSM の数とアベイラビリティーゾーン (AZ) の選択も、クラスターの復旧に影響します。どんなキー管理システムの場合でも、キーの可用性が、暗号化されたデータのリカバリーにどのように影響するかを把握することが重要です。

AWS KMS API 呼び出し経由で使用できる CloudHSM にバックアップされた AWS KMS カスタムキーストアにキーが保存される比率は、デフォルトの AWS KMS キーストアにキーが保存される比率よりも低くなります。現在のパフォーマンス制限については、「AWS KMS デベロッパーガイド」を参照してください。

AWS KMS の料金にはカスタムキーストアの使用による影響はありません。ただし、各カスタムキーストアを使用するには、AWS CloudHSM クラスターに少なくとも 2 つの HSM が必要となります。こうした HSM は、標準の AWS CloudHSM 料金を請求されます。カスタムキーストアの使用に追加料金はかかりません。

カスタムキーストアを使用したい AWS KMS ユーザーは、AWS CloudHSM クラスターを設定し、HSM を追加し、HSM ユーザーを管理する必要があり、バックアップから HSM のリストアを行う場合もあります。これらはセキュリティ性の高い作業なので、適切なリソースと組織的コントロールがすべて整っていることを確認することができます。

いいえ、独自のキーマテリアルを AWS KMS カスタムキーストアにインポートする機能はサポートされていません。カスタムキーストアに保存されたキーは、お使いの CloudHSM クラスターを形成する HSM でのみ生成できます。

いいえ、タイプの異なる AWS KMS キーストアの間でキーを移動する機能は現在サポートされていません。独自のキーマテリアルをデフォルトの AWS KMS キーストアにインポートする場合を除いて、キーはすべて使用するキーストアで作成する必要があります。

AWS KMS カスタムキーストアのキーマテリアルを自動的に更新する機能はサポートされていません。キーの更新は、新しいキーを作成し、将来の暗号化操作でその新しいキーを使用するために、アプリケーションコードで使用される AWS KMS キーエイリアスを再マッピングすることで、手動で実行する必要があります。

はい、AWS KMS だけで CloudHSM クラスターを独占的に利用する必要はありません。既にクラスターを所有している場合は、カスタムキーストアとして使用しながら、他のアプリケーションでもそのクラスターを継続して使用できます。ただし、お使いのクラスターが AWS KMS 以外に大きなワークロードをサポートしている場合、カスタムキーストアで KMS キーを使用する操作を行う際にスループットの低下が発生する可能性があります。同様に、カスタムキーストアへの AWS KMS リクエストの比率が高いと、他のアプリケーションに影響が出る可能性があります。

「AWS CloudHSM ウェブサイト」を参照して、サービスの概要をご確認ください。サービスの設定と使用の詳細については、AWS CloudHSM ユーザーガイドを参照してください。

外部キーストアとは、AWS の外部でお客様が所有、管理する外部キー管理インフラストラクチャを基盤とするカスタムキーストアです。外部キーストア内の KMS キーを使用するすべての暗号化または復号化操作は、お客様の管理下にある暗号キーと操作でお客様のキーマネージャで実行され、AWS に物理的にアクセスできません。

XKS は、お客様の管理下にある AWS の外部で暗号キーを保管および使用する必要がある規則や規制への準拠に役立ちます。

お客様に代わって統合された AWS サービスから、またはお客様自身のアプリケーションから AWS KMS へのリクエストは、ネットワーク内の XKS Proxy と呼ばれるコンポーネントに転送されます。XKS Proxy はオープンソースの API 仕様で、お客様とキー管理ベンダーが、これらのリクエストを受け付け、キー管理インフラストラクチャに転送し、そのキーを使用して暗号化および復号化を行うサービスを構築するのに役立ちます。

タレス、Entrust、Atos、Fortanix、DuoKey、Securonix、Utimaco、Salesforce、T-Systems、HashiCorp には、XKS プロキシ仕様と統合するソリューションがあります。これらのベンダーのソリューションの利用可能性、料金、使用方法については、それぞれのドキュメントを参照してください。キー管理インフラストラクチャのパートナーとともに、オープンソースの XKS Proxy 仕様を活用し、ニーズに合ったソリューションを構築することをお勧めします。XKS Proxy の API 仕様は、こちらで公開されています。

外部キーは、Encrypt、ReEncrypt、Decrypt、GenerateDataKey の対称暗号化操作をサポートしています。

XKS のキーは、カスタマー管理のキーを使用して、AWS KMS と統合するすべての AWS サービス内のデータを暗号化するために使用できます。サポートの対象になっているサービスのリストについてはこちらをご覧ください。AWS サービスは AWS KMS GenerateDataKey API を呼び出し、お客様のデータを暗号化するための一意の平文データキーを要求します。平文のデータキーは、暗号化されたデータと一緒に保存されるデータキーの暗号化されたコピーと一緒にサービスに返されます。データキーの暗号化されたコピーを作成するために、まず平文データキーは、お客様の AWS アカウントに固有の AWS KMS に保存されているキーで暗号化されます。この暗号化されたデータキーは、外部キーマネージャに接続された XKS Proxy 実装に転送され、外部キーマネージャで定義したキーの下で 2 回目の暗号化が行われます。生成された二重暗号化されたデータキーは、GenerateDataKey API リクエストのレスポンスとして返されます。

AWS KMS、XKS Proxy 実装、外部キーマネージャ間のネットワーク接続は、TLS のようなポイントツーポイントの暗号化プロトコルで保護されている必要があります。しかし、AWS KMS から外部キーマネージャに届くまでのデータを保護するために、AWS KMS はまず外部キーストアで定義された各 KMS キーに特化したあなたのアカウントで内部管理された KMS キーで暗号化します。その結果、暗号文は外部キーマネージャに転送され、外部キーマネージャのキーを使用して暗号化されます。二重暗号化により、外部キーマネージャーのキーマテリアルを使用しない限り、暗号文は決して復号化されないというセキュリティコントロールが得られます。また、AWS ネットワークから出る暗号文は、FIPS 140 認証を受けた AWS KMS HSM を使用して暗号化されているというセキュリティ制御も提供します。外部キーマネージャはデータを復号するために使用する必要があるため、AWS KMS へのアクセスを無効にすると、基盤となる暗号化されたデータにはアクセスできなくなります。

はい。AWS KMS をキープロバイダーとして使用するクライアント側の対称暗号化ソリューションを使用する場合、XKS キーは独自のアプリケーション内から使用することも可能です。AWS Encryption SDK、S3 Encryption Client、DynamoDB Encryption Client などの AWS オープンソースのクライアント側の暗号化ソリューションが XKS キーをサポートしています。

すべての XKS キーは、KMS で新しいキーとして作成する必要があります。既存の KMS キーを外部キーマネージャーでホストされている XKS キーに移行することはできません。

AWS サービスまたはお客様自身のアプリケーションがそのアクションをサポートしていると仮定すれば、新しく生成された XKS キーの下で既存のデータを再暗号化することができます。多くの AWS サービスは、暗号化されたリソースをコピーし、そのコピーを暗号化するために使用する新しい KMS キーを指定するのに役立ちます。AWS サービスが提供する COPY コマンドで、XKS キーを設定することができます。KMS ReEncrypt API を呼び出して XKS キーを設定することで、クライアント側の暗号化データを独自のアプリケーションで再暗号化できます。

他のカスタマー管理のキーと同様に、XKS キーは削除されるまで 1 キーあたり 1 USD/月です。XKS キーの下でのリクエストは、他の AWS KMS 対称キーと同じレートで課金されます。料金についての詳細は、「AWS KMS の料金」ページをご覧ください。

はい。自動キー更新は XKS 仕様でサポートされており、XKS をサポートするほとんどのベンダーで提供されている機能です。XKS キーの自動更新はすべて外部のキーマネージャで行われ、KMS 内で作成および管理される AWS KMS キーの自動キー更新と同様に機能します。更新された KMS XKS キーを使用してデータを暗号化すると、外部キーマネージャは現在のキーマテリアルを使用します。更新された XKS キーを使用して暗号文を復号化すると、外部キーマネージャは暗号化に使用されたキーマテリアルのバージョンを使用します。以前の暗号文の作成に使用された以前の XKS キーが外部キーマネージャで有効である限り、それらのバージョンの XKS キーで Decrypt API リクエストを正常に実行できます。

キーをキャッシュしないサービスの場合、この XKS KMS キーを使用した次の API 呼び出しは失敗します。サービスによっては、パフォーマンス、レイテンシー、KMS コスト管理のために、データキーのキャッシュやその他のキー導出スキームを実装しているものがあります。これらのキーのキャッシュは、5 分から 24 時間までさまざまです。現在使用中の保護されたリソース (RDS データベースや EC2 インスタンスなど) は、キーへのアクセスを拒否した後、異なる反応を示します。詳細については、関連する AWS サービスのドキュメントを参照してください。

外部キーストアプロキシへの認証を行うために、AWS KMS はプロキシ上で設定し KMS に提供する AWS SigV4 認証情報を使用してプロキシへのすべてのリクエストに署名します。AWS KMS は、サーバーサイドの TLS 証明書を使用して外部キーストアプロキシーを認証します。オプションとして、プロキシは相互 TLS を有効にし、AWS KMS からのリクエストのみを受け入れることをさらに保証できます。

IAM ポリシー、AWS KMS キーポリシー、グラントなど、他の KMS キーで使用する通常の AWS KMS 認証メカニズムはすべて、外部キーストア内の KMS キーでも同じように機能します。

さらに、AWS KMS から XKS Proxy に送信される各リクエストに含まれるリクエストメタデータに基づく認可制御の二次レイヤーを実装する機能が、お客様やお客様の外部キーマネージャのパートナーにあります。このメタデータには、呼び出した AWS ユーザー/ロール、KMS キー ARN、リクエストされた特定の KMS API が含まれています。これにより、AWS KMS からのリクエストを単純に信頼するだけでなく、外部キーマネージャでキーを使用する際にきめ細かい認証ポリシーを適用することができます。これらのリクエスト属性を用いたポリシー適用の選択は、個々の XKS Proxy の実装に委ねられます。

XKS キーを含む AWS KMS に受信するすべてのリクエストに対して生成された一意の ID は、XKS Proxy にも転送されます。XKS プロキシまたは外部キーマネージャからのログデータ (利用可能な場合) を使用して、AWS KMS へのリクエストと外部キーマネージャに行われたリクエストを照合することができます。この機能により、外部キーマネージャのキーを使用するすべてのリクエストが、直接または統合された AWS サービスを通じて AWS KMS への呼び出しから発信されたことを確認できます。

可用性リスク: XKS Proxy と外部キーマテリアルの可用性については、お客様の責任となります。このシステムは、暗号化されたリソースを復号化したり新しいデータを暗号化するために XKS キーが必要なときはいつでも、AWS KMS が XKS Proxy に正常に接続できることを検証するために、高い可用性を有している必要があります。つまり、XKS Proxy 自体がキーを使用して必要な暗号操作を完了するために外部キーマネージャに接続できる必要があります。例えば、XKS キーを使って EBS ボリュームを暗号化し、EC2 インスタンスを起動してその暗号化ボリュームをアタッチしたいとします。EC2 サービスは、そのボリュームに固有の暗号化されたデータキーを AWS KMS に渡して復号化し、そのボリュームに対する読み取り/書き込み操作を復号化して暗号化するために、Nitro Card の揮発性メモリにプロビジョニングすることができるようにします。XKS Proxy や外部キーマネージャーがボリュームキーの復号化に利用できない場合、EC2 インスタンスは起動に失敗します。このようなタイプの失敗の場合、AWS KMS は XKS Proxy が利用できないことを示す KMSInvalidStateException を返します。KMS から提供されるエラーメッセージに基づいて、XKS Proxy とキーマネージャーを利用できない理由を判断するのは、お客様次第です。

耐久性リスク: キーは AWS 外のシステムで管理されるため、作成したすべての外部キーの耐久性については、お客様が単独で責任を負うことになります。XKS キーの外部キーが永久に失われたり削除された場合、XKS キーの下で暗号化されたすべての暗号文は回復不可能です。

パフォーマンスリスク: お客様は、XKS Proxy および外部キーストアインフラストラクチャが、利用者のニーズを満たすのに十分なパフォーマンス特性を持つように設計されていることを確認する責任があります。XKS キーを使用するすべてのリクエストは外部キーストアへの接続を必要とするため、AWS KMS からのリクエスト率が XKS Proxy または外部キーマネージャがサポートできるリクエスト率を超えると、XKS プロキシがボトルネックとなる可能性があります。また、AWS KMS から XKS Proxy への 1 回のリクエスト (1 回の再試行を含む) の経過時間が 500 ミリ秒* を超える場合、AWS KMS は呼び出し元のクライアントに 400 エラーを返し、XKS キーが利用できないため呼び出し元のクライアントは再試行しないよう効果的に伝えます。この動作は、インフラストラクチャへの接続性の問題によって引き起こされる散発的な過度のレイテンシーに対応しなければならない上流の AWS サービスまたはお客様自身のアプリケーションのリスクを最小限に抑えるために設計されています。

*AWS KMS は、250 ミリ秒かかるリクエストに対して 1 回の再試行を試みます。再試行のリクエストにも 250 ミリ秒以上かかる場合、400 エラーが呼び出し元のクライアントに返されます。

AWS は、AWS KMS と外部キーストアインフラストラクチャ間の接続のエンドツーエンドの可用性を制御できないため、パブリック KMS 可用性 SLA では XKS の使用を明示して対象外としています。同様に、XKS キーがサービス内のデータを暗号化するためにお客様によって設定されているすべての AWS サービスで、XKS キーは可用性 SLA の対象外としています。