AWS Key Management Service よくある質問

以下のよくある質問は、Sinnet により運営される AWS 中国 (北京) リージョンおよび NWCD により運営される AWS 中国 (寧夏) リージョンの AWS Key Management Service (KMS) には適用されません。これら 2 つの中国リージョンに関連するコンテンツについては、こちらのよくある質問のリンクを参照してください。

AWS KMS は、暗号化操作に使用されるキーを簡単に作成および管理できるマネージドサービスです。このサービスは、可用性の高いキーの生成、保管、管理、監査ソリューションを提供し、独自のアプリケーション内でデータの暗号化やデジタル署名を行うことや、AWS のサービス全体でデータの暗号化を管理できます。

AWS のサービス全体でデータを保護する責任がある場合は、このサービスを使用して、データへのアクセスをコントロールする暗号化キーを一元管理できます。アプリケーション内のデータを暗号化する必要があるデベロッパーは、AWS KMS を利用して AWS Encryption SDK を使用することをお勧めします。これにより、コード内の対称暗号化キーをより簡単に生成、使用、保護できます。非対称キーを使用してデータのデジタル署名または検証を行う必要があるデベロッパーは、このサービスを使用して、必要なプライベートキーを作成および管理できます。デベロッパーと増え続けるアプリケーションをサポートするためにスケーラブルなキー管理インフラストラクチャを必要としている場合は、このサービスでライセンスコストと運用の負担を軽減できます。規制やコンプライアンスに準拠するためにデータセキュリティを提供する必要がある場合は、このサービスを使用して、データが一貫して保護されていることを容易に証明できます。また、AWS KMS は広範囲にわたる業種および地域的なコンプライアンス体制にも対応しています。

AWS KMS を使い始める最も簡単な方法は、各サービスによって自動的に作成される AWS 所有のルートキーを使用する AWS サービスでデータを暗号化することを選択することです。 アカウント間またはサービス間でキーのアクセスを共有する機能など、キーの管理を完全にコントロールする必要がある場合は、AWS KMS に独自の AWS KMS カスタマー管理のキーを作成できます。ユーザー独自のアプリケーション内で、直接作成した KMS キーを使用することもできます。AWS KMS は KMS コンソールからアクセスできます。KMS コンソールは、AWS KMSコンソールの AWS のサービスホームページの [セキュリティ、アイデンティティ、コンプライアンス] グループに属しています。AWS KMS API は、AWS KMS コマンドラインインターフェイス (CLI) またはプログラムアクセス用の AWS SDK 経由で直接アクセスすることも可能です。AWS KMS API は AWS Encryption SDK を使用して、ユーザー独自のアプリケーション内のデータを暗号化するために間接的に使用することも可能です。詳細は、「開始方法」のページをご覧ください。

利用可能なリージョンの一覧は、世界中を網羅した「製品およびサービス一覧 (リージョン別)」ページでご覧いただけます。

以下のキー管理機能を実行できます。

• サービス内でのみ使用されるキーマテリアルで対称キーおよび非対称キー、HMAC キーを作成する
• キーマテリアルは、AWS CloudHSM または AWS 外の独自の外部キーマネージャのいずれかによってバックアップされ、制御下のカスタムキーストアで生成および使用されている対称キーを作成します。
• 独自の対称キー、非対称キー、HMAC キーマテリアルをインポートして、サポートされている AWS サービスや独自のアプリケーションで使用する
• AWS Identity and Access Management (IAM) のユーザーとロールがキーを管理できるかを定義する
• どの IAM ユーザーとロールがキーを使用してデータを暗号化および復号できるか定義する
• サービスによって生成されたキーが 1 年ごとに自動更新されるように設定する
• 誰にもキーが使用されないように、一時的に無効にする
• 無効にしたキーを再度有効にする
• 使用しなくなったキーの削除をスケジュールする
• AWS CloudTrail でログを調査してキーの使用を監査する

AWS KMS キーの作成をリクエストすることによりサービスの使用を開始できます。カスタマー管理の KMS キーのライフサイクルを管理し、誰がそれを使用または管理できるかを管理します。KMS キーを作成すると、暗号化、復号化、署名、検証、またはこの KMS キーを使用して HMAC を生成または検証するために、サービス AWS KMS に直接データを送信することができます。これらのキーについて、どのユーザーがどのような条件でどのアクションを実行できるかを定義する使用ポリシーを設定できます。

AWS KMS と統合された AWS のサービスおよびクライアント側のツールキットは、エンベロープ暗号化という方法を使用してデータを保護します。この方法では、AWS KMS が AWS のサービスまたはアプリケーションでローカルに暗号化するために使用されるデータキーを生成します。データキー自体は、ユーザーが定義した AWS KMS キーで暗号化されます。AWS KMS によるデータキーの保持や管理は行われません。AWS のサービスでは、データが暗号化され、暗号化されたデータキーのコピーと暗号化されたデータが一緒に保存されます。サービスでデータを復号化する必要がある場合は、KMS キーを使用してデータキーを復号化するように AWS KMS にリクエストします。AWS のサービスからのデータをリクエストしているユーザーが、KMS キーで復号の権限を付与されている場合、AWS のサービスは AWS KMS から復号されたデータキーを受信します。そして、AWS のサービスでデータは復号され、プレーンテキストで返されます。KMS キーの使用リクエストはすべて CloudTrail にログされるため、誰が、いつ、どのような状況で、どのキーを使用したかを把握できます。

AWS KMS を使用してデータを暗号化する方法には、通常 3 つのシナリオがあります。まず、AWS KMS API を直接使用し、サービスに保存されている KMS キーを使ってデータの暗号化と暗号化ができます。2 番目は、サービスに保存されている KMS キーを使用して、AWS のサービスでデータを暗号化させる方法です。この場合、データは KMS キーで保護されているデータキーを使用して暗号化されます。3 番目は、AWS KMS と統合されている AWS Encryption SDK を使用する方法です。ユーザー独自のアプリケーションが AWS 内で動作しているかどうかにかかわらず、アプリケーション内で暗号化を実行できます。

AWS KMS は AWS の他のほとんどのサービスとシームレスに統合されており、それらのサービスにおけるデータの暗号化をより簡単に行うことができます。データが、デフォルトでは AWS KMS に保存されているものの、当該の AWS のサービスによって所有され、管理されているキーを使用して暗号化される場合もあります。多くの場合、AWS KMS キーはユーザーのアカウント内で、ユーザーが所有し、管理します。一部のサービスでは、ユーザー自身でキーを管理したり、ユーザーに代わってサービスがキーを管理するのを許可したりできます。現在 AWS KMS と統合されている「AWS のサービスのリスト」をご覧ください。統合されているサービスによる AWS KMS の使用方法の詳細については、「AWS KMS デベロッパーガイド」を参照してください。

AWS KMS は最大 4 KB のデータを直接暗号化して送信することをサポートしていますが、エンベロープ暗号化にはパフォーマンス面で多大なメリットがあります。AWS KMS で直接データを暗号化する場合、データをネットワーク経由で送信する必要があります。エンベロープ暗号化は、非常に小さいデータキーのリクエストと配信がネットワークを行き交うのみなので、ネットワークの負荷が軽減します。データキーは、アプリケーション内または暗号化を行う AWS のサービスでローカルに使用されるため、データブロック全体を AWS KMS に送信する必要がなく、ネットワークレイテンシーが発生しません。

AWS のサービスがお客様に代わってデータを暗号化する場合に、お客様は使用する特定の KMS キーを選択できます。これらはカスタマー管理の KMS キーと呼ばれ、お客様が完全に管理します。ユーザーが各キーのアクセス制御と使用ポリシーを定義し、他のアカウントやサービスに使用許可を与えることができます。AWS KMS では、カスタマー管理のキーの他に、AWS が管理する 2 種類のキーも用意されています。(1) AWS 管理の KMS キーは、お客様のアカウントで作成され、AWS が管理するキー、(2) AWS 所有のキーは AWS アカウントから完全に所有および運用されるキーです。ユーザーはアカウント内の AWS マネージドキーを追跡することができ、使用はすべて CloudTrail にログされますが、キー自体を直接管理することはできません。AWS 所有のキーは最も自動化されており、AWS 内でデータの暗号化を提供しますが、そのキーのアクティビティに関するポリシー制御や CloudTrail ログを提供しません。

独自の KMS キーを作成すると、AWS 管理の KMS キーを使用するよりもさらに厳重に制御できます。カスタマー管理の対称 KMS キーを作成すると、使用するキーマテリアルを AWS KMS または AWS CloudHSM クラスター、または外部キーマネージャ (カスタムキーストアを通じて) 内で生成されたキーマテリアルで生成するか、独自のキーマテリアルをインポートするかを選択できます。キーのエイリアスと説明を定義でき、キーが AWS KMS によって生成された場合は、1 年ごとに自動更新されるよう選択できます。また、あらゆるアクセス許可を設定してキーを使用または管理できるユーザーを制限できます。カスタマー管理の非対称 KMS キーの場合、管理にはいくつかの注意事項があります。キーマテリアルは AWS KMS HSM でのみ生成でき、キーの自動更新オプションはありません。

はい。キーが AWS KMS HSM で生成された場合は、AWS KMS が KMS キーを毎年自動的に更新するように設定できます。インポートされたキー、非対称キー、AWS KMS カスタムキーストア機能を使用して CloudHSM クラスターで生成されたキーには、自動キー更新はサポートされません。キーを AWS KMS または非対称キーにインポートするか、カスタムキーストアを使用することを選択した場合は、新しい KMS キーを作成し、既存のキーのエイリアスを古い KMS キーから新しい KMS キーにマッピングすることで、手動で更新できます。

AWS KMS が自動キー更新を選択した場合は、データを再暗号化する必要はありません。AWS KMS は過去のバージョンのキーを自動的に保管して、そのキーで暗号化されたデータを復号化できるようにします。AWS KMS のキーに対する新しい暗号化リクエストはすべて、最新バージョンのキーで暗号化されます。インポートしたキーまたはカスタムのキーストアキーを手動で更新する場合、古いバージョンのキーを使用し続けるかどうかに応じて、データを再暗号化する必要がある場合があります。

インポートされたキーまたはカスタムキーストアのキーを手動で更新する場合は、古いバージョンのキーを利用可能にするかどうかによって、データの再暗号化の必要がある場合があります。

はい。AWS KMS で作成したお客様の AWS KMS キーと関連するメタデータは削除を予定できます。削除までの待機期間は 7～30 日の間に設定できます。この待機期間中に、キーを削除することによって、そのキーを使用しているアプリケーションとユーザーが受ける影響を確認できます。デフォルトの待機期間は 30 日です。待機期間中にキーの削除をキャンセルすることもできます。削除を予定したキーを使用することはできません。ただし、待機期間中に削除をキャンセルした場合はその限りではありません。キーは、削除をキャンセルしない限り、待機期間 (設定可能) の最後に削除されます。削除されたキーは使用できなくなります。削除されたルートキーで保護されているデータはすべてアクセスできなくなります。

お客様の AWS KMS キーがインポートされたキーマテリアルの場合は、2 つの方法で AWS KMS キー ID とメタデータを削除せずにキーマテリアルを削除できます。1 つは、待機期間なしで、オンデマンドでインポートされたキーマテリアルを削除する方法です。2 つ目は、AWS KMS キーにキーマテリアルをインポートする際に、AWS でインポートされたキーマテリアルを使用できる有効期限を定義する方法です。再度使用する必要が発生した場合は、キーマテリアルを AWS KMS キーに再インポートできます。

はい。AWS KMS は AWS SDK、AWS Encryption SDK、Amazon DynamoDB Client-side Encryption、および Amazon Simple Storage Service (S3) Encryption Client でサポートされており、実行場所を問わずユーザー独自のアプリケーションのデータ暗号化を可能にします。詳しくは、「AWS Crypto Tools」および「Developing on AWS」のウェブサイトをご覧ください。

1 つのアカウントで、1 リージョンあたり最大 100,000 個の KMS キーを作成できます。有効および無効にされている KMS キーの合計数が上限に近づいたら、無効にされ使用しなくなったキーを削除することをお勧めします。AWS のサービスで使用するためにお客様に代わって作成される AWS 管理の KMS キーはこの数に含まれません。KMS キーで作成され、アプリケーションまたは AWS のサービスでお客様に代わってデータを暗号化するデータキーの数に上限はありません。AWS サポートセンターで KMS キーの制限の引き上げをリクエストできます。

いいえ。全ての KMS キーまたは非対称 KMS キーの非公開部分は、プレーンテキストで HSM からエクスポートすることはできません。非対称 KMS キーの公開部分のみを、コンソールから、または GetPublicKey API を呼び出すことでエクスポートできます。

はい。対称データキーは、GenerateDataKey API または GenerateDataKeyWithoutPlaintext API を使用してエクスポートできます。また、非対称データキーペアの非公開部分と公開部分は、GenerateDataKeyPair API または GenerateDataKeypairWithoutPlaintext API を使用して AWS KMS の外にエクスポートできます。

対称データキーまたは非対称データキーの非公開部分は、AWS KMS にデータキーを生成するようリクエストしたときに定義した対称 KMS キーを使用して暗号化されます。

AWS Private CA サービスは、主に、エンティティを識別し、ネットワーク接続を保護するための公開鍵基盤 (PKI) を構築するために使用します。PKI では、主に X.509 証明書を使用して、パブリックキー暗号化オペレーションに関する体制を構築するためのプロセスとメカニズムを提供します。証明書では、アイデンティティとパブリックキーの間の関連付けが行われます。認証機関によって証明書が発行される認証プロセスでは、信頼された認証機関によって証明書に署名することでもう 1 つのエンティティのアイデンティティを主張できます。PKI では、アイデンティティ、分散型の信頼、キーライフサイクル管理、失効によって公開される証明書ステータスを利用できます。このような機能によって、AWS KMS で提供される基盤となる非対称暗号化キーとアルゴリズムに重要なプロセスとインフラストラクチャが追加されます。

AWS Private CA を使用すると、証明書を発行して、ウェブサーバー、アプリケーションサーバー、サービスメッシュ、VPN ユーザー、内部 API エンドポイント、AWS IoT Core デバイスを識別できます。証明書によって、これらのリソースのアイデンティティを確立し、暗号化された TLS/SSL 通信チャネルを作成できます。ウェブサーバー、アプリケーションサーバー、Elastic Load Balancer、API Gateway エンドポイント、Amazon Elastic Compute Cloud (EC2) インスタンス、コンテナの TLS ターミネーションに非対称キーを使用することを検討している場合は、証明書の発行と PKI インフラストラクチャの構築に AWS Private CA を検討することをお勧めします。

対照的に AWS KMS では、非対称キーを生成、管理し、デジタル署名や証明書を必要としない暗号化オペレーションにそのキーを使用できます。証明書では送信者と受信者のアイデンティティを信頼されていないエンティティ間で検証できますが、AWS KMS によって提供される未加工の非対称オペレーションは、一般に、アイデンティティを証明する別のメカニズムがある場合、またはアイデンティティを証明しなくても必要なセキュリティの利点を得ることができる場合に役立ちます。

その他の暗号化 API プロバイダーを対象としたネイティブの統合は AWS KMS によって提供されていません。署名機能や暗号化機能をアプリケーションに組み込むには、AWS KMS API を直接使用するか、AWS SDK を使用する必要があります。

はい。AWS KMS SLA では、ある請求期間中において、月間稼働率がサービスコミットメントを下回った場合にサービスクレジットを提供するよう定められています。

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 を使用して様々なユースケースをサポートできます。これにはデジタル著作権管理 (DRM)、パブリックキーインフラストラクチャー (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 リクエストは無料利用枠に含まれません。

別途記載がない限り、表示される料金には付加価値税、売上税など、一切の税金等および関税は含まれません。日本の居住者であるお客様が 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) では使用できません。

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 の対象外としています。