← AWSサービスの内部原理 コース
63. KMSの認可は二重扉である — キーポリシーが主、IAMは従
すべてのKMSキーがちょうど1つ必ず持つ「キーポリシー」を軸に、IAM・グラントという3つの扉がどう協調して初めてキーが使えるのかを、上から下へ図で追っていきます。
① キーポリシーは必ず1枚
KMSキー1個ごとに
「誰が・どう使えるか」を決める一次情報
キーポリシー= リソースポリシー
ちょうど1枚。0枚も2枚もない認可の主導権ここが空白だと、他の扉が何を言おうと通れない
- 公式の言い回し「Every KMS key must have exactly one key policy.」「Key policies are the primary way to control access to KMS keys.」
- 他にIAMポリシーとグラントも使えるが、キーポリシーは省略不可。
- 普通のAWSリソースは「アイデンティティ側(IAMポリシー)でAllowすれば使える」が、KMSはキー自身に貼られたキーポリシーが主導権を握る。
KMSキーには必ず1枚のキーポリシーがあり、それがアクセス制御の一次手段(primary way)。この一枚を無視して認可は成立しない。
② rootも最初は無権限
アカウントroot
キー作成者
管理者ロール
「明示的にAllow」かつ「Denyされていない」を満たす扉が必要
権限ゼロ暗黙の特権は一切なし
キーポリシー
IAMポリシー
グラント
- 公式の言い回し「No AWS principal, including the account root user or key creator, has any permissions to a KMS key unless they are explicitly allowed, and never denied, in a key policy, IAM policy, or grant.」
- 「explicitly allowed(明示的な許可)」かつ「never denied(一度もDenyされていない)」の両方が条件。
KMSは暗黙の特権を一切認めない。rootでさえ、3つの認可手段のどれかで明示的にAllowされ、どこからもDenyされていないときだけキーに触れる。
③ IAMは委任されて初めて効く
IAM: Allow例: kms:Decrypt を許可
それぞれの結果
Yes: 委任文ありデフォルトキーポリシーの「rootアカウントへの許可文」がIAM評価を有効化
No: 委任文なしキーポリシーが許していない
Allowが効くIAM側の許可が初めて有効に
no effectIAMのAllowは効果なし = 通れない
- 公式の言い回し「Unless the key policy explicitly allows it, you cannot use IAM policies to allow access to a KMS key. Without permission from the key policy, IAM policies that allow permissions have no effect.」
- Denyは別ルート: 「You can use an IAM policy to deny a permission to a KMS key without permission from a key policy.」— IAMのDenyは委任と無関係に常に有効。
- 「The default key policy enables IAM policies.」有効化に使う文は公式ページ「Allows access to the AWS account and enables IAM policies」で説明されるポリシーステートメント。
IAMのAllowは、キーポリシー(既定ではrootアカウントへの許可文)がIAM評価を有効化して初めて効く従属的な扉。一方でIAMのDenyはこの委任と無関係に常に効く。これは「通常はアイデンティティベースのAllowだけで通れる」というIAMの基本ルールの例外で、ロールの信頼ポリシーと並ぶ「リソースポリシー側の明示的Allowが必須」なケースだ(IAM評価の例外編で扱った通り)。
④ キーポリシーはリージョナル
IAMポリシーグローバル
キーポリシーリージョナル
全リージョン全リージョンのプリンシパルに一様に作用
同一リージョンのみ同じリージョンのキーにしか効かない
ap-northeast-1のKey-Aのポリシーは、us-east-1のKey-Bには一切効かない- 公式の言い回し「Unlike IAM policies, which are global, key policies are Regional. A key policy controls access only to a KMS key in the same Region. It has no effect on KMS keys in other Regions.」
IAMポリシーはグローバルに一様、キーポリシーはリージョン境界で閉じる。あるリージョンのキーポリシーは、別リージョンのキーには効果を持たない。
⑤ 第3の扉グラント
AWSサービス例: EBSが暗号化ボリュームを作る
② 鍵を使用(Decrypt / GenerateDataKey など)
グラントAllowのみ(Denyは書けない)・対象はちょうど1つのキー
grantee = サービス側(あなたに代わってキーを使う)③ タスク完了 → 即retire(または revoke で削除)
タスク実行暗号化タスクを完了
権限が消えるポリシーを書き換えずに後始末が済む
- 公式の言い回し「A grant can allow access to a KMS key, but not deny access.」「Each grant allows access to exactly one KMS key.」「The service creates a grant on behalf of a user in the account, uses its permissions, and retires the grant as soon as its task is complete.」
- 1グラント=1キーだが、別アカウントのキーに対して作ることはできる(You can create a grant for a KMS key in a different AWS account)。
- retire(グラントに指定された principal が終了)とrevoke(通常はキー管理者が権限を積極的に剥奪)はどちらもグラントを削除する。
- キーあたりのグラント上限は 50,000(Grants per KMS key: 50,000)。
グラントはAllow専用・1キー単位の一時的な扉。AWSサービスが「作る→使う→即retire」で使い捨てることで、キーポリシーやIAMを書き換えずに最小権限を実現する。
⑥ 結果整合性とgrant token
CreateGrantグラントを作成
並行してグラントがKMS全体に伝播(結果整合性)— 典型は数秒未満、遅い場合は数分
grant token非機密・可変長のbase64文字列
tokenを付けて GenerateDataKey 等を即実行 → 伝播を待たずに権限が効く伝播完了以後 token は不要
KMSは grant 本体で権限を判定(tokenはもう見ない)- 公式の言い回し「The AWS KMS API follows an eventual consistency model.」「It typically takes less than a few seconds for the change to propagate throughout the system, but in some cases it can take several minutes.」「In most cases, eventual consistency will be achieved within five minutes.」
- grant token は「unique, nonsecret, variable-length, base64-encoded string」。ハッシュダイジェストなのでグラントの中身は漏れない。
- 整合後は「AWS KMS uses the grant to determine permissions, not the grant token.」
グラントはDynamoDB編で見た結果整合性そのもので、書き込み直後は全ノードに伝わっていない。grant tokenは「伝播を待たずにこのグラントを今すぐ使う」ための引換券で、整合が取れれば不要になる。