背景・目的
以前、Amazon Aurora のリソース暗号化について整理しました。
今回は、AWS Key Management Service（KMS）を使用した暗号化について整理し、実際に試してみます。
まとめ
下記に特徴をまとめます
| 特徴 | 説明 |
|---|---|
| 概要 | ・Aurora は、キー管理のために AWS Key Management Service（AWS KMS） と自動的に統合されている ・暗号化方式として エンベロープ暗号化 が使用される |
| 使用できるKMSキー | AWS マネージドキー カスタマーマネージドキー |
概要
下記を基に整理します。
- Aurora は、キー管理のために AWS Key Management Service（AWS KMS） と自動的に統合されている
- Aurora の暗号化方式として エンベロープ暗号化 が使用される
- DB クラスターの暗号化には 下記の2 種類の KMS キー を利用できる
- AWS マネージドキー
- AWS サービスが 自動的に作成・管理・使用
- Aurora では RDS 用 AWS マネージドキー（aws/rds） がデフォルトで使用される
- ユーザーは 管理・ローテーション・削除ができない
- カスタマーマネージドキー
- KMS キーに対して フルコントロール（ポリシー・ローテーション等） が必要な場合に使用
- AWS マネージドキー
- KMS キーに対する すべての操作の監査ログ は AWS CloudTrail で確認可能
- キーのローテーションについては AWS KMS のキー管理機能を利用して行われる
カスタマーマネージドキーの使用の承認
- Amazon Aurora は、暗号化オペレーション時にリソースを作成・変更するユーザーに代わって動作する
- Aurora リソースを カスタマーマネージドキー で作成・変更するには、ユーザーに以下の KMS 権限 が必要
- kms:CreateGrant
- kms:DescribeKey
- これらの権限は、以下のいずれかで指定できる
- KMS キーポリシー
- IAM ポリシー（キーポリシーで許可されている場合）
- RDS（Aurora 含む）などのマネージドサービスで使用するKMS キーポリシーに 明示的な拒否（Deny） を設定する場合
- リソース所有アカウントを許可する条件を必ず指定する必要がある
- これを指定しないと、IAM ユーザーを例外に含めていても操作が失敗する場合がある
Amazon RDS 暗号化コンテキスト
- Aurora（および代行する Amazon EBS）KMSを使用する際、暗号化コンテキスト（Encryption Context） を指定する
- 暗号化コンテキストは、追加の認証データ（AAD: Additional Authenticated Data） として使われ、データの整合性を保証する役割を持つ
- 暗号化時に指定した暗号化コンテキストは、復号時にも完全に同一である必要がある。一致しない場合、復号は 必ず失敗する
実践
シナリオ1: 基本的なCMK暗号化
CMK
- CMKを作成します
- 作成されました
Auroraクラスタの作成
- CMKでAuroraクラスタ作成します
- KMSキーが利用されていました
シナリオ2: KMS無効化の影響確認
KMSを無効化した際の挙動と、再有効化した際の挙動を確認します
EC2のデプロイ
- EC2をデプロイします
テストデータの作成
-
EC2にセッションマネージャーで接続します
-
psqlで接続します
-
テスト用のテーブルを作成します
XXXXXX=> -- テーブル作成 CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(100), email VARCHAR(100), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE XXXXXX=> -
データを投入します
XXXXXX=> INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com'), ('Bob', 'bob@example.com'), ('Charlie', 'charlie@example.com'); -
確認できました
SELECT * FROM users; INSERT 0 3 id | name | email | created_at ----+---------+---------------------+---------------------------- 1 | Alice | alice@example.com | 2025-12-31 03:20:57.636584 2 | Bob | bob@example.com | 2025-12-31 03:20:57.636584 3 | Charlie | charlie@example.com | 2025-12-31 03:20:57.636584 (3 rows) XXXXXX=>
KMSキー無効化した際の挙動の確認
-
KMSに移動します
-
ナビゲーションペインで「カスタマー管理型のキー」をクリックします
-
該当するキーをクリックします
-
キーのアクションをクリックし、「無効」を選択します
-
ステータスが「無効」になりました
-
しばらくするとクラスターのステータスが「inaccessible-encryption-credentials-recoverable」に変わります（おそらく5分〜10分程度）
-
以前のSELECTを実行しますが、結果が返ってきません
XXXXXX=> SELECT * FROM users; -
新しく接続しようとしても、結果が返ってきません
$ psql -h aurora-XXXXXX.ap-northeast-1.rds.amazonaws.com -U XXXXX -d XXXXX -p XXXX
KMSキーを最有効化した際の挙動の確認
-
KMSに移動します
-
ナビゲーションペインで「カスタマー管理型のキー」をクリックします
-
該当するキーをクリックします
-
キーのアクションをクリックし、「有効」を選択します
-
KMSのステータスが「有効」になりました
-
30分経っても「inaccessible-encryption-credentials-recoverable」のままでしたが、しばらくすると、「起動中」→「利用可能」に変わりました
-
改めて接続します。できました
$ psql -h aurora-XXXXXX.ap-northeast-1.rds.amazonaws.com -U XXXXXX -d XXXXXX -p XXXX Password for user XXXXXX: psql (15.15) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off) Type "help" for help. XXXXXX=> -
クエリも成功しました
XXXXX=> SELECT * FROM users; id | name | email | created_at ----+---------+---------------------+---------------------------- 1 | Alice | alice@example.com | 2025-12-31 03:20:57.636584 2 | Bob | bob@example.com | 2025-12-31 03:20:57.636584 3 | Charlie | charlie@example.com | 2025-12-31 03:20:57.636584 4 | David | david@example.com | 2025-12-31 03:34:11.803545 (4 rows) XXXXX=>
シナリオ3: スナップショット暗号化
スナップショットを作成した際のCMKと、 砂プッショットをコピーした際のCMKがことな場合の挙動を確認します。
スナップショットを作成
最初のCMKで暗号化されたAuroraからスナップショット作成します
-
Auroraクラスタを選択し、「スナップショットの取得」をクリックします
-
スナップショット名を指定し、「スナップショットの取得」をクリックします
-
しばらくすると作成されました
別のCMKを作成
- あたらしくCMK（cmk-b）を作成します
CMK-Bでスナップショットを暗号化コピー
- RDSに移動します
- ナビゲーションペインで「スナップショット」をクリックします
- 上記で作成した、snapshotを選択します
- アクション＞「スナップショットをコピー」をクリックします
- KMSキーには、新しく作ったキーを指定し「スナップショットをコピー」をクリックします
- できました
CMK-Bのスナップショットから新クラスタ復元
-
作成したスナップショットを選択します
-
アクション＞「スナップショットを復元」をクリックします
-
DBインスタンス識別子を指定して、「DBクラスターを復元」をクリックします
-
EC2からリストアされたクラスタにアクセスします
sh-5.2$ psql -h aurora-XXXXX.ap-northeast-1.rds.amazonaws.com -U XXXXX -d XXXXX -p 5432 Password for user XXXXX: psql (15.15) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off) Type "help" for help. XXXXX=> SELECT * FROM users; id | name | email | created_at ----+---------+---------------------+---------------------------- 1 | Alice | alice@example.com | 2025-12-31 03:20:57.636584 2 | Bob | bob@example.com | 2025-12-31 03:20:57.636584 3 | Charlie | charlie@example.com | 2025-12-31 03:20:57.636584 4 | David | david@example.com | 2025-12-31 03:34:11.803545 (4 rows) XXXXX=>
CMK-Aを無効化
-
最初のクラスターで使用していたKMSを無効化します
-
Auroraのクラスタでステータスが「Inaccessible-encryption-credentials-recoverable」になるまでまちます
-
EC2から元のクラスタに接続します。アクセスできませんでした
$ psql -h aurora-XXXXX.ap-northeast-1.rds.amazonaws.com -U XXXXX -d XXXXX -p XXXX -
新規に作成した（リストアした）クラスタに接続します。アクセスできました
sh-5.2$ psql -h aurora-XXXXX.ap-northeast-1.rds.amazonaws.com -U XXXXX -d XXXXX -p XXXXX Password for user XXXXX: psql (15.15) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off) Type "help" for help. XXXXX=> SELECT * FROM users; id | name | email | created_at ----+---------+---------------------+---------------------------- 1 | Alice | alice@example.com | 2025-12-31 03:20:57.636584 2 | Bob | bob@example.com | 2025-12-31 03:20:57.636584 3 | Charlie | charlie@example.com | 2025-12-31 03:20:57.636584 4 | David | david@example.com | 2025-12-31 03:34:11.803545 (4 rows) XXXXX=>
考察
今回、AuroraでKMSの利用を試してみました。
下記のようなことがわかりました。
- KMS無効化は即座には影響しないが、確実にサービス停止する
- recoverable 状態なので、KMS有効化で自動復旧可能
- 手動起動は不要（自動で復旧プロセスが開始される）
- スナップショットは別のKMSキーで再暗号化できる
- 異なるKMSキーを使う複数のクラスタを独立管理できる
参考