AWS KMSで暗号キーを管理する

AWS Key Management Service（AWS KMS）は、暗号キーを作成・管理し、暗号処理を認可された主体だけに実行させるマネージドサービスです。AWSの各種サービスやアプリケーションからKMSキーを利用でき、キーの使用履歴を監査できます。KMSキーはリージョンに属するため、アプリケーションと暗号化対象の配置、障害時の復旧先、利用するKMSエンドポイントを一緒に設計します。

KMSのキーは、データのアクセス権限やアプリケーション認可の代わりにはなりません。たとえば、社内の倉庫から集めた需要予測ファイルを暗号化しても、ファイルを読める利用者や復号APIを呼べるロールを適切に絞らなければ、正規の権限を持つ主体からデータを守れません。暗号化、データへのアクセス制御、キーを使う権限、操作の監査を組み合わせます。

KMSキーとキーマテリアル

KMSキーは、暗号化や復号、電子署名などに使うキーを表す論理リソースです。キーには次のようなメタデータが関連付けられます。

• キーIDとキーARN
• 作成日時と説明
• キーの状態（有効、無効、削除保留など）
• キー仕様、用途、オリジン
• タグとエイリアス
• ローテーションの設定やポリシー

キーIDやARNはKMSキーを指定するための識別子で、秘密の暗号値ではありません。一方、キーマテリアルは暗号処理に使われる秘密の値そのものです。KMSキーというリソースの設定情報と、暗号演算に必要なキーマテリアルを区別してください。KMSで作成されたキーマテリアルはKMSの保護境界の外へ出ず、KMS APIを通じて許可された処理に使われます。

アプリケーションが大量のデータを扱う場合は、KMSキー自体でデータ全体を暗号化するのではなく、KMSとデータキーを組み合わせるエンベロープ暗号化が一般的です。データキーでデータを暗号化し、KMSキーでデータキーを保護します。ここでは、保護の根幹となるKMSキーの種類と、運用時の制御を扱います。

AWS管理キーとカスタマー管理キー

KMSキーは、誰が作成し、設定やライフサイクルを管理するかによって、主にAWS管理キーとカスタマー管理キーに分かれます。

観点	AWS管理キー	カスタマー管理キー
作成	AWSサービスが、サービス内で暗号化を有効にしたときなどに作成する	利用者がKMSコンソール、API、CLIなどで作成する
管理主体	AWSがキーの設定とライフサイクルを管理する	利用者がポリシー、タグ、状態、ローテーションなどを管理する
キーポリシー	利用者は内容を変更できない	利用者が設定・管理できる
有効化・無効化・削除	利用者は個別に操作できない。AWSサービス側の動作に従う	利用者が状態を変更し、削除をスケジュールできる
ローテーション	AWSが管理するスケジュールに従い、通常は毎年自動ローテーションされる	対象となるキーで自動ローテーションを設定でき、追加でオンデマンドローテーションも実行できる
料金	AWSサービスの利用料金に含まれ、キー自体に追加料金は発生しない	キーとAPIリクエストに対してKMSの料金が適用される

AWS管理キーは、AWSサービスを使い始める際に利用者が個別のキー管理をしなくても暗号化を利用できる選択肢です。ただし、キーのポリシーや無効化、削除を自ら細かく統制する用途には向きません。カスタマー管理キーなら、チームやアプリケーションごとのアクセスを設定し、無効化や削除を計画し、監査やローテーションをより直接的に管理できます。AWSサービスによって選択できるキーの種類や使い方は異なるため、対象サービスの仕様も確認します。

KMSキーへのアクセス制御とABAC

KMSは、キーの使用や管理をキーポリシー、IAMポリシー、グラントで制御します。キーポリシーはKMSキーに直接付くリソースベースポリシーで、そのキーに対する権限を決める中心的な設定です。IAMポリシーはユーザーやロールなどの主体に付けるアイデンティティベースポリシーです。

IAMポリシーだけでKMSキーへのアクセスを常に許可できるわけではありません。キーポリシーがアカウントにIAMポリシーで権限を委任することを認め、そのうえで主体に適切なIAM許可がある、といったポリシーの関係が必要です。明示的な拒否、権限境界、セッションポリシー、組織のサービスコントロールポリシーなどの制限も評価されます。また、KMSグラントはAWSサービスやアプリケーションに特定の操作を委任する仕組みです。暗号操作の認可と、キーの設定変更・削除などの管理操作は分け、必要な主体に最小限の権限を与えます。

KMSは**属性ベースのアクセス制御（ABAC）**にも対応しています。たとえば、環境やチームを示すタグをカスタマー管理キーに付け、ポリシー条件でタグを参照すると、属性に基づいて対象キーへの権限を整理できます。キーのタグを変更できる権限もアクセス判定に影響するため、タグ付与・変更権限は慎重に制限します。エイリアスを条件に使う場合も、エイリアスの割り当て先を変更できる主体を限定します。条件キーやAPIごとに利用可能な属性は異なるため、ポリシーを適用する操作の仕様に合わせて条件を組み立てます。

キーID、エイリアス、キーポリシー

キーIDとキーARNは特定のKMSキーを直接識別します。エイリアスは、alias/warehouse-forecast のような名前をKMSキーに関連付けるリージョン単位の参照先です。コードや設定がエイリアスを使っていれば、エイリアスを別のキーへ付け替えて新しいキーへ移行しやすくなります。ただし、エイリアスの付け替えは、そのエイリアスを使うすべての処理の参照先を変えます。既存データを復号できるキーを保持すること、エイリアスを変更したときの影響を検証することが必要です。

エイリアスはキーそのものではなく、キーマテリアルや権限を持つリソースでもありません。各リージョンで独立して存在し、同じ名前のエイリアスを別リージョンに作っても、それぞれ別個に管理されます。KMSキーをローテーションしてもキーIDやエイリアスは変わりません。自動ローテーションでは同じ論理キーの中で新しいキーマテリアルが使われるため、通常はアプリケーションのキー参照を更新する必要はありません。

キーポリシーでは、キー管理者とキー利用者を分けて定義します。管理者に暗号化データを復号する許可が不要な場合は、管理操作と暗号操作の権限を分離できます。クロスアカウントでキーを使う場合は、キーを所有する側のポリシーと、呼び出す側のIAMポリシーなど、両アカウントで必要な許可を整えます。どのアカウント・ロール・操作を許可するかを明示し、広い主体指定や不要な管理権限を避けます。

キーマテリアルのローテーション

ローテーションでは、一定期間ごとに使用するキーマテリアルを新しいものへ切り替えます。暗号化に使われる秘密の値を更新し、同一のキーマテリアルに依存し続ける期間を抑えることが目的です。キーID、ARN、ポリシー、タグ、エイリアスなどの論理キーに関する設定と、内部で使うキーマテリアルを区別することが大切です。

AWS管理キーのキーマテリアルはAWSが通常毎年自動でローテーションします。カスタマー管理キーでは、次の対象に自動ローテーションを設定できます。

• AWS KMSで生成したキーマテリアルを持つ、対称暗号化用のカスタマー管理キー
• 自動ローテーションの対象としてサポートされるマルチリージョンキー

自動ローテーションの既定の期間は365日です。利用者は90日から2,560日（約7年）の範囲で期間を設定できます。また、スケジュールを待たずにオンデマンドローテーションを実行できます。非対称キー、HMACキー、外部からインポートしたキーマテリアルを持つキー、カスタムキーストア内のキーなどは、自動ローテーションの対象外です。対象キーの種類と現在の機能条件を確認して設定します。

ローテーションに対応するマルチリージョンキーでは、プライマリキーでのローテーションが関連するレプリカにも反映されます。各レプリカを別々にローテーションするのではなく、共有するキーマテリアルとローテーション状態を一組として扱います。

自動ローテーション後も、KMSは過去のキーマテリアルを保持し、それぞれで暗号化されたデータを復号できるようにします。暗号化処理では新しいキーマテリアルが使われ、復号処理では暗号文に対応するキーマテリアルが選ばれます。このため、ローテーションによってKMSキーのIDやARNが変わることはなく、以前に暗号化したデータを一斉に再暗号化する必要もありません。古いキーマテリアルを保持することは、キー全体を削除しても過去のデータを復号できるという意味ではありません。キー自体を削除すれば、そのキーに依存したデータの復号手段を失います。

自動ローテーションに対応しないキーを運用上ローテーションする必要がある場合は、新しいKMSキーを用意し、エイリアスやアプリケーション設定を切り替える方式を計画します。過去の暗号文を復号できるように、移行が完了するまで旧キーと必要なキーマテリアルへのアクセスを維持します。キーの交換だけを行い、旧データがどのキーに結び付いているか追跡できなくなる状態を避けます。

有効化・無効化・削除のライフサイクル

カスタマー管理キーは有効化・無効化でき、不要になったキーには削除をスケジュールできます。無効化したキーはKMSの暗号操作に使えなくなりますが、再び有効化すれば利用を戻せます。無効化を、キーを削除する前の影響確認や一時的な使用停止に使うことができます。AWS管理キーは利用者が個別に無効化または削除できません。

KMSキーの削除はすぐには行われず、7日から30日までの待機期間を指定してスケジュールします。待機期間中、キーは削除保留状態となり、暗号操作に使用できません。削除を取り消せるのはこの待機期間中です。スケジュールを取り消したキーは必要に応じて再度有効化します。待機期間が終わるとKMSはキーを削除し、元に戻せません。バックアップ、ログ、別リージョンのレプリカなどを含め、キーが必要なデータが残っていないか事前に調べてください。

KMSのAPI操作とキー使用はAWS CloudTrailに記録されます。CloudTrailのイベントを確認することで、キーを使った主体、操作、時刻などを調査できます。CloudTrailのログをCloudWatch Logsへ配信してメトリクスフィルターやアラームを設定したり、EventBridgeルールで通知したりすれば、想定外の利用や削除関連の操作を監視できます。KMSのメトリクスや監査ログの設定を確認し、記録先の保護と保持期間も決めます。

削除保留期間はデータ復旧期間ではありません。削除保留に入ったキーは利用できず、既存データの復号にも使えません。保持期間中にキー使用の記録を監視できても、その使用を許可したり復号を可能にしたりするわけではありません。キーが不要か判断できない場合は、すぐ削除せず、まず無効化し、影響と依存データを確認する運用が安全です。

外部キーマテリアルのインポート（BYOK）

AWS KMSでは、利用者がKMSの外部で生成したキーマテリアルをカスタマー管理キーにインポートできます。この方式はBYOK（Bring Your Own Key）とも呼ばれます。キーマテリアルを自組織の手順で作り、KMSへ持ち込める一方、生成品質、保護、バックアップ、交換時期を管理する責任は利用者にあります。KMSはインポートされたマテリアルのバックアップを利用者に代わって作成したり、自動でローテーションしたりしません。

インポートの大まかな流れは次のとおりです。

1. EXTERNAL をオリジンとしてKMSキーを作成し、用途とキー仕様に合うキーマテリアルを安全な環境で生成する。
2. KMSからインポート用の公開鍵とインポートトークンを取得する。
3. 公開鍵を使ってキーマテリアルを指定された方式で暗号化する。
4. 暗号化したキーマテリアル、インポートトークン、有効期限の指定をKMSに送信して取り込む。
5. KMSでキーが利用可能になったことを確認し、元のキーマテリアルを安全な保管手順に従って保護する。

KMSへ送るキーマテリアルは、対象キーの仕様に適合する必要があります。KMSは、インポート後のキー使用を管理しますが、外部で保管する原本のバックアップや復旧可能性までは担いません。バックアップが失われれば再インポートできず、対象キーで暗号化したデータを復号できなくなるおそれがあります。

インポート時に有効期限を設定すると、期限到来時にKMSはインポートされたキーマテリアルを削除し、KMSキーをマテリアルの再インポート待ち状態にします。キーリソースそのものを削除する処理とは異なり、インポート済みキーマテリアルの有効期限切れには7〜30日の削除待機期間はありません。キーマテリアルがなくなれば、その間は暗号操作を行えません。有効期限を設ける場合は、期限前の更新・再インポートを監視し、復旧用のマテリアルを安全に保管します。また、利用者はキーマテリアルをKMSから手動で削除することもできます。これはキーリソース自体の削除とは別の操作で、マテリアルを削除すると直ちにそのキーを使った暗号操作ができなくなります。

BYOKではKMSによる自動ローテーションを利用できません。キーマテリアルの交換は利用者が計画し、旧データを復号する方法を残しながら新しいキーへ移行します。多くの構成では新しいKMSキーを作成し、利用先を切り替えたうえで、旧キーを過去データの復号に必要な期間維持します。キーマテリアルを削除・交換する前に、バックアップ、再インポート手順、暗号文の移行状況を確認してください。

マルチリージョンキー

通常のKMSキーは作成したリージョンでのみ使用できます。マルチリージョンキーは、プライマリキーと別リージョンに作成したレプリカキーを、同じキーマテリアルと共有プロパティを持つ関連キーの集合として扱います。あるリージョンでデータを暗号化し、暗号文を別リージョンへ移動したとき、移動先に対応するレプリカキーがあれば、そのリージョンのKMSエンドポイントを通じて復号できます。暗号文自体を複製するわけではないため、データの移動や複製は別途行います。

プライマリキーはマルチリージョンキーを最初に作成したリージョンのキーです。利用者はそれを別リージョンに複製してレプリカキーを作成します。各キーはリージョン内で個別に存在し、暗号化・復号要求はそのリージョンのKMSが処理します。マルチリージョンキーはグローバルな単一エンドポイントや、アカウント全体で自動的に複製されるキー設定を提供するものではありません。

関連するプライマリキーとレプリカキーは、同じキーID、キーマテリアル、キー仕様、用途、オリジンを共有します。カスタマー管理のキーポリシー、グラント、タグ、説明、有効・無効の状態、削除スケジュール、エイリアスなどはリージョンごとに個別管理します。一つのリージョンのポリシーやタグを変えても、他リージョンの設定が自動的に同じになるわけではありません。レプリカを使うワークロードでは、各リージョンで必要な主体、ポリシー、監視、エイリアスを用意します。

マルチリージョンキーは、複数リージョンで暗号文を扱うアプリケーションや、リージョン間のデータ移動を容易にする選択肢です。利用することでリージョン障害時の可用性が自動的に完成するわけではありません。データの複製、アプリケーションの切り替え、レプリカの有効状態とポリシー、リージョンごとの依存関係をあわせて設計します。通常のリージョンキーと同様、キーを無効化したり削除保留にしたりすれば利用に影響し、各リージョンのKMS APIに到達できなければそのリージョンでの操作はできません。

運用時に確認すること

• どのAWSアカウントとリージョンにキーがあり、どのサービスやアプリケーションが利用しているかを台帳化する。
• キー管理者、暗号操作の利用者、タグやエイリアスを変更できる主体を分け、必要最小限の権限を付与する。
• キーの無効化、ローテーション、削除予約が暗号化済みデータ、バックアップ、レプリカ、障害復旧に及ぼす影響を確認する。
• 外部キーマテリアルでは、生成、バックアップ、期限、再インポート、交換の担当者と手順を定め、原本をKMSの外で安全に保護する。
• CloudTrailのKMSイベントを監査し、CloudWatch LogsやEventBridgeなどを使って異常な使用とライフサイクル操作を通知する。
• マルチリージョンキーでは、共有されるプロパティと各リージョンで別々に設定するプロパティを区別し、全レプリカの状態とアクセス制御を点検する。

DVA試験での判断ポイント

• AWSサービスに簡単に暗号化を組み込み、個別のキー制御を細かく必要としないならAWS管理キーが候補になる。利用者がポリシー、状態、監査、ローテーションなどを制御したい場合はカスタマー管理キーを選ぶ。
• IAM許可だけを追加してもKMSキーを使えないことがある。キーポリシーがIAMへの委任を認めているか、必要な主体と操作が許可されているかを確認する。
• 自動ローテーションはキーマテリアルを更新する。論理キーのIDは維持され、KMSが過去のキーマテリアルを復号に使うため、既存暗号文を一斉に作り直すこととは異なる。
• カスタマー管理キーの削除は待機期間後に確定し、削除保留中のキーは暗号操作に利用できない。削除の影響が不明なら、即時削除ではなく無効化と依存関係の確認を行う。
• BYOKでは、マテリアルの原本、バックアップ、期限、交換を利用者が管理する。期限切れや手動削除でマテリアルがなくなると、キーリソースが残っていてもそのキーで暗号操作できない。
• マルチリージョンキーは同じキーIDとキーマテリアルを持つ関連キーを各リージョンで使う機能であり、データ複製や全てのキー設定の同期まで自動化するものではない。