![[アップデート] AWS KMSキーの最終使用を簡単に確認できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d5543bc9fd4ae763dcf74e04d096b8bc/d3fffe307001ee43ef2e3f0a1eca7bea/aws-key-management-service?w=3840&fm=webp)
[アップデート] AWS KMSキーの最終使用を簡単に確認できるようになりました
AWS KMSキーの棚卸しをしたいけど、ログを確認するの大変だな
こんにちは、のんピ(@non____97)です。
皆さんはAWS KMSキーの棚卸しをしたいけど、ログを確認するの大変だなと思ったことはありますか? 私はあります。
KMSキーそれ自体が残っていても大した課金額にはなりませんが、ちりつもです。不要なものについては削除をする形が望ましいです。
従来、KMSキーを削除する際には以下のようなプロセスをとっていました。
- Cloud Trailで対象のKMSキーを用いた処理があるか確認
- ある場合は、今後もその処理が発生するのかの確認、判断
- KMSキーの無効化
- 一定期間様子見をし、KMSキーを無効化したことによるトラブルがないか観察
- KMSキーの削除のスケジューリング
複数のKMSキーがある場合、都度AthenaなどでCloudTrailログを検索するのも手間です。
今回、アップデートによりAWS KMSキーの最終使用を簡単に確認できるようになりました。
マネジメントコンソールやAWS CLIからKMSキーが最後に使用された日時や操作、CloudTrailイベントIDを取得できます。
ドキュメントとしては以下にまとまっています。
実施に確認してみます。
確認できる対象や内容
確認できる対象は以下のとおりです。
- 成功した以下暗号化操作
- Decrypt
- DeriveSharedSecret
- Encrypt
- GenerateDataKey
- GenerateDataKeyPair
- GenerateDataKeyPairWithoutPlaintext
- GenerateDataKeyWithoutPlaintext
- GenerateMac
- ReEncrypt
- Sign
- Verify
- VerifyMac
- 注意点
- 記録は最大1時間の遅延発生の可能性あり
- マルチリージョンKMSキーの場合、プライマリキーとレプリカキーはそれぞれ独立して最終使用情報を追跡する
- 再暗号化処理をした場合は暗号化と復号の両方のKMSキーそれぞれで記録される
確認できる内容は以下のとおりです。
- タイムスタンプ
- 操作 (AWS API名)
- KMSキーのリクエストID
- CloudTrailのイベントID
何かしら記録がある = 使用されているとの判断はできますが、その逆の判断は危険です。先述のドキュメント上でも過信するなと紹介されています。
Do not solely rely on last usage information when deleting unused keys. Instead, disable the key first and monitor AWS CloudTrail for DisabledException entries, which indicate attempts to use the key while disabled. This helps identify potential dependencies and workload failures.
やってみた
既存のKMSキーの確認
試してみます。
まずは既存のKMSキーの確認をします。
マネジメントコンソールからカスタマーマネージドキーを確認すると、最終使用という項目があり、3 days agoと表示されていることが分かります。
3 days agoをクリックすると、最終使用時のタイムスタンプや操作、CloudTrailのイベントIDを確認することができました。
CloudTrailイベントIDはリンクになっており、クリックするとCloudTrailのコンソールで対象のイベントの詳細を確認することができます。
他のカスタマーマネージドキーを確認すると、使用状況追跡の開始以降のレコードがありません (2026年4月23日)となっていました。
作成日は2025/4/30と一年以上前ですが、最終使用が2026/4/23というところを見ると、この機能がリリースされてから2026/4/23以降のKMSの暗号化/復号のAPI操作を記録してくれそうですね。
AWSマネージドキーも確認してみます。
すると、こちらも最終使用という項目があり、8 hours agoと表示されていることから、AWSマネージドキーだろうとカスタマーマネージドキーだろうと使用できる機能であることが分かりました。
AWS CLIからもKMSキーの最終使用情報を確認します。get-key-last-usageを実行します。
> aws kms get-key-last-usage --key-id <KMSキーID>
{
"KeyId": "<KMSキーID>",
"KeyLastUsage": {
"Operation": "Decrypt",
"Timestamp": "2026-04-25T22:30:57.004000+09:00",
"CloudTrailEventId": "34f87fe2-b5f0-4ad3-b5e1-f0f0c013d8a2",
"KmsRequestId": "3ecb6705-cd11-4705-b64f-ba39d12bf49e"
},
"TrackingStartDate": "2026-04-23T09:00:00+09:00",
"KeyCreationDate": "2024-03-29T19:01:58.438000+09:00"
}
はい、取得できしました。"TrackingStartDate": "2026-04-23T09:00:00+09:00"であることから、やはり2026/4/23以降の操作を追跡しているようですね。
KMSキーの削除や無効化防止
こちらの機能と併せて、KMS キーに対する暗号化操作が行われなかった日数を表すkms:TrailingDaysWithoutKeyUsageという条件キーが追加されています。
| AWS KMS 条件キー | 条件タイプ | 値のタイプ | API操作 |
|---|---|---|---|
kms:TrailingDaysWithoutKeyUsage |
数値 | 単一の値 | - DisableKey- ScheduleKeyDeletion |
詳細は以下AWS公式ドキュメントをご覧ください。
こちらを用いることによって最終利用日からの指定した経過日数以上経過しなければKMSキーを無効 / 削除スケジュールできないように制御が可能です。
試してみましょう。
現在、マネジメントコンソールからKMSキーの削除のスケジューリングや無効化をしようとすると、以下のように最終使用情報が表示されていますが、無視しようと思えば無視して処理を継続することができます。
今回は最終使用から90日以上経過しなければ、無効 / 削除スケジュールできないようにKMSキーポリシーを設定してみます。具体的には以下のステートメントを追加しました。
{
"Effect": "Deny",
"Principal": "*",
"Action": [
"kms:ScheduleKeyDeletion",
"kms:DisableKey"
],
"Resource": "*",
"Condition": {
"NumericLessThanEquals": {
"kms:TrailingDaysWithoutKeyUsage": "90"
}
}
}
この状態でKMSキーを無効化しようとすると、AccessDeniedExceptionと確かにKMSキーの無効化を拒否してくれました。
KMSキーを作成する際に、こちらのステートメントを追加することで、二重のガードレール的な形でKMSキーの誤削除を防ぐことができそうですね。これは積極的に使っていきたいです。指定した経過日数に満たない状態で削除しようとするとKMSキーポリシーの変更が必要になるので、対象のKMSキーを誤って選択してしまっていた場合についても気づきやすくなるように思います。
KMSキーの棚卸しのお供に
AWS KMSキーの最終使用を簡単に確認できるようになったアップデートを紹介しました。
KMSキーの棚卸しのお供に使っていきたいですね。EventBridge SchedulerとStep Functionsとを用いて定期的にカスタマーマネージドキーの最終使用情報を取得して、指定した日数以上使われていないものがあれば管理者に通知するといった対応などをすれば、かなり楽ができそうです。
ただし、繰り返しになりますが、最終使用日時が古い = 現在も使用されていないではありません。最終的には最終使用時のシチュエーションなどから現在も継続して利用される可能性があるのかを確認していく必要があります。
AWS公式ドキュメントでも以下のように暗号化操作を頻繁に実行しない場合もあると紹介されています。
Certain AWS services create resources that depend on a KMS key for data protection but do not invoke cryptographic operations on that key frequently. For example, the Amazon EC2 service calls AWS KMS to decrypt the data key for an encrypted Amazon EBS volume only when the volume is attached to an instance. In these cases, you must not rely on the last usage information alone to determine if a KMS key can be deleted. If the KMS key protecting an Amazon EBS volume is deleted, there will be no disruption to the Amazon EBS volume that's already attached, but subsequent attempts to attach that encrypted Amazon EBS volume to another Amazon EC2 instance would fail.
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
