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ポリシーしか設定されていない状況では、利用不可。まず、キーポリシーによる許可が必要。

https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/control-access-overview.html#managing-access


以下で、

  1. root userからのアクセス
  2. IAMで許可されているユーザーからのアクセス

を許可できる。この書き方でなぜ2が実現できるのか疑問だったが、キーポリシーは特別、ということなら納得。

{
  "Sid": "Enable IAM policies",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:root"
   },
  "Action": "kms:*",
  "Resource": "*"
}