Open4
KMS完全に理解する
CMKの種類
1️⃣ AWSマネージド型CMK
- AWSサービスが自動で作って自動で使う鍵
- 削除不可
- ローテーションは、3年単位で自動更新
2️⃣ カスタマーマネージド型CMK(AWS上で生成)
- AWS上で生成した鍵を、AWS上でそのまま管理する
- 自動ローテーション対応。期間は1年固定。手動でオンデマンドでローテーションもできる(ただし、新規のCMKを作ってaliasを張り替える方法のみ)。
3️⃣ カスタマーマネージド型CMK(BYOK: Bring Your Own Keys)
- ユーザー所有のKMIで生成した鍵を、インポートする
- 自動ローテーション非対応。随時手動で更新が必要
- 有効期限設定可能だが、削除時の待機時間ゼロで即消えてしまうため、オペミスに超注意
CMK以外の鍵
AWS所有鍵
- AWSが利用する複数アカウントで共用の鍵
- ローテーション頻度諸々はAWSが決める
- 自分たちで管理するものではないので、あまり意識しなくて良い
KMSによる暗号化/復号化
暗号化をしたいデータそのものの暗号化/復号化は、クライアントサイドで実行する
KMSがやってくれるのは、「↑の暗号化/復号化に使うCDK (Customer Data Key)」の暗号化/復号化。
4KBまでの制限は、この部分にかかるので注意。
データ自体は、クライアントサイドで暗号化/復号化するので大きなサイズでも問題ない。
リージョンまたぎの注意点
KMSそのものがリージョンサービスである点に注意。
リージョンが変わると、当然鍵が使えなくなる。
クロスリージョンでデータをやり取りするためには、
- Aリージョンで、AのKMSで復号
- Bリージョンで、BのKMSで最暗号化
必要
KMSのキーポリシー
ほとんどのAWSサービスで、IAM ポリシーがサービスのリソースへのアクセスを制御する唯一の方法です。一部のサービスでは、IAM ポリシーを補完するリソースベースのポリシーまたはその他のアクセスコントロールメカニズムが提供されますが、これらは一般的にオプションであり、IAM ポリシーだけでこれらのサービスのリソースへのアクセスを制御できます。ただし、AWS KMS については該当しません。
KMSのキーポリシーは、他のリソースポリシーとは仕組みが違う。
IAMポリシーしか設定されていない状況では、利用不可。まず、キーポリシーによる許可が必要。
以下で、
- root userからのアクセス
- IAMで許可されているユーザーからのアクセス
を許可できる。この書き方でなぜ2が実現できるのか疑問だったが、キーポリシーは特別、ということなら納得。
{
"Sid": "Enable IAM policies",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "kms:*",
"Resource": "*"
}