MENU
AWSを中心としたクラウドインフラ技術サイト
  1. ホーム
  2. AWS
  3. AWS KMS（Key Management Service）

AWS KMS（Key Management Service）

AWS AWS認定試験 セキュリティ

目次

AWS Black Belt

AWS KMS

AWS Black Belt Online Seminar AWS Key Management Service (KMS) from Amazon Web Services Japan

■分かりやすい解説

10分でわかる！Key Management Serviceの仕組み #cmdevio

https://dev.classmethod.jp/articles/10minutes-kms

※図解且つシンプルな解説で分かりやすい。

AWS KMS の特徴

ユーザーは AWS サービスによって自動的に作成・管理される AWS マネージドキーを利用できます。AWS マネージドキーではなく、キーのライフサイクル、キーポリシー、IAM ポリシー、グラント、ローテーション、削除などを自分で管理したい場合は、AWS KMS にカスタマーマネージドキー（Customer managed key）を作成できます。

カスタマーマネージドキー（Customer managed key）は、ユーザーが AWS アカウント内で作成・所有・管理する KMS キーです。AWS サービスによるサーバーサイド暗号化に使用できるほか、ユーザー独自のアプリケーションから直接利用することもできます。

KMS キー（AWS マネージドキー及び カスタマーマネージドキー（Customer managed key））は、データキーを生成・暗号化・復号するために使用できます。データキーは、大量のデータやアプリケーションデータを実際に暗号化するための暗号化キーです。

AWS KMS で利用されるキーには、主に 3 つの種類があります。

① AWS 所有キー（AWS owned key）
② AWS マネージドキー（AWS managed key）
③ カスタマーマネージドキー（Customer managed key）

AWS 所有キーは AWS が所有・管理するキーで、ユーザーからは直接確認・管理できません。AWS マネージドキーは AWS サービスがユーザーのアカウント内に作成・管理するキーです。カスタマーマネージドキーは、ユーザー自身が作成し、キーポリシーやアクセス制御、ローテーションなどを管理できる KMS キーです。

AWS KMS を利用することで、RDS、EC2 インスタンスの EBS ボリューム、S3、Redshift などのデータを暗号化して保護できます。

KMS キーはどのように使われているか

実際に KMS キーがどのように使われているのかは、以下の 3層で考えると分かりやすいです。

  • KMS キー　…　データキーを暗号化・復号するために使う
  • データキー　…　実際のデータ本体を暗号化・復号するために使う
  • データ本体　…　S3オブジェクト、EBSボリューム、RDSデータ、Secrets Managerの値など

KMSキーはデータ本体を大量に暗号化する鍵ではない

KMS キーは、AWS KMS の中で管理される鍵です。KMS キーは、AWS KMS とやり取りして利用するもので、通常、鍵本体をアプリケーション側へ取り出して使うものではありません。KMS キーは HSM で保護され、暗号化されていない状態で AWS KMS の外に出ることはありません。

イメージとしては、KMS は「鍵を使って処理してくれる場所」です。

アプリ
  ↓
「この暗号化済みデータキーを復号してください」
  ↓
AWS KMS
  ↓
KMS 内部で KMS キーを使う
  ↓
結果だけ返す

つまり、KMSキーを持ち出して使うのではなく、KMS API に依頼して使うという形です。

一番よく使われる方式：エンベロープ暗号化

大量データを暗号化するときは、KMS キーでデータ本体を直接暗号化するのではなく、データキーを使います。

流れはこうです。

1. KMS キーを指定して GenerateDataKey を呼ぶ

2. KMS がデータキーを生成する

3. KMS は 2つのデータキーを返す
   - 平文のデータキー
   - KMS キーで暗号化されたデータキー

4. アプリや AWS サービスは、平文のデータキーでデータ本体を暗号化する

5. 平文のデータキーはメモリから破棄する

6. 暗号化されたデータ本体と、暗号化されたデータキーを一緒に保存する

AWS KMS の GenerateDataKey は、平文のデータキーと、指定した対称 KMSキーで暗号化されたデータキーの両方を返します。

図にするとこうです。

暗号化時

AWS KMS
  KMS キー
    ↓
  データキーを生成
    ↓
  ┌─────────────────────┐
  │ 平文データキー       │ → データ本体を暗号化するために一時的に使う
  │ 暗号化済みデータキー  │ → データと一緒に保存する
  └─────────────────────┘

アプリ / AWS サービス
  平文データキーでデータ本体を暗号化
  ↓
  暗号化済みデータ本体
  +
  暗号化済みデータキー

ここで重要なのは、保存するのは暗号化済みデータキーだという点です。
平文のデータキーは、使い終わったら破棄します。

復号時はどうなるか

復号時は、保存してある 暗号化済みデータキーを KMS に渡します。

1. 暗号化済みデータキーを KMS の Decrypt に渡す

2. KMS が KMS キーで暗号化済みデータキーを復号する

3. KMS から平文のデータキーが返る

4. アプリや AWS サービスが、平文のデータキーでデータ本体を復号する

5. 平文のデータキーをメモリから破棄する

図にするとこうです。

復号時

保存済みデータ
  ┌────────────────────┐
  │ 暗号化済みデータ本体 │
  │ 暗号化済みデータキー │
  └────────────────────┘
              ↓
        暗号化済みデータキーを KMS に渡す

AWS KMS
  KMSキーで暗号化済みデータキーを復号
              ↓
        平文データキーを返す

アプリ / AWSサービス
  平文データキーでデータ本体を復号

AWS KMS の Decrypt は、KMS キーで暗号化された暗号文を復号するために使われます。

S3 の SSE-KMS ではどう使われるか

たとえば S3 で SSE-KMS を使う場合、ユーザーは S3 にオブジェクトをアップロードします。

ユーザー
  ↓ PutObject
S3
  ↓ KMS キーを指定してデータキーを取得
AWS KMS
  ↓
S3
  ↓ データキーでオブジェクトを暗号化
S3 に保存

S3 はざっくり言うと、以下を保存します。

・暗号化されたオブジェクト本体
・暗号化されたデータキー
・メタデータ

オブジェクトを取得するときは、S3 が暗号化済みデータキーを KMS に渡して復号してもらい、得られたデータキーでオブジェクトを復号します。AWS の S3 ドキュメントでも、S3 は暗号化済みデータキーを KMS の Decrypt リクエストに送り、KMS が同じ KMSキーで復号すると説明されています。

つまり、ユーザーが直接 KMS を呼んでいなくても、裏側では S3 が KMS を呼んでいます。

Secrets Manager ではどう使われるか

Secrets Manager の場合も同じ考え方です。

たとえば DB パスワードを保存するとします。

Secrets Manager
  ↓ KMS キーを使ってデータキーを取得
AWS KMS
  ↓
Secrets Manager
  ↓ 平文データキーでシークレット値を暗号化
保存

Secrets Manager は、シークレット値そのものを KMSキーで直接暗号化するのではなく、データキーで暗号化します。データキーは KMSキーで暗号化され、シークレットのメタデータに保存されます。復号時には、Secrets Manager が暗号化済みデータキーを KMS で復号してから、シークレット値を復号します。

このため、以下のエラーが出ることがあります。

This version of secret is not encrypted with the current KMS key

これは、シークレットの現在バージョンや過去バージョンが、想定している KMSキーとは別のキーで暗号化されている可能性がある、という話です。

EBS / RDS ではどう使われるか

EBS や RDS の場合、ユーザーが毎回 GenerateDataKey を呼ぶわけではありません。AWS サービス側が KMS と連携して、ストレージ暗号化を行います。

たとえば EBS なら、

EC2
  ↓
EBSボリューム
  ↓
KMSキーを使って暗号化

と見えますが、実際には EBS 側が KMSキーを使ってデータキーを扱い、ボリュームのデータを暗号化します。

RDS も同様です。

RDS DBインスタンス / Auroraクラスター
  ↓
ストレージ層のデータ
  ↓
KMSキーを使って暗号化

ここでも、KMS キー自体で DB の全データを直接暗号化しているというより、KMSキーがデータキーを保護し、そのデータキー系統でストレージの暗号化が行われる、と考えるとよいです。

アプリケーションから直接使う場合

自作アプリから KMS を直接使うこともできます。

小さいデータなら、Encrypt / Decrypt を直接使えます。
ただし、KMS の Encrypt API は最大 4,096 バイトまでの平文を暗号化する用途です。

そのため、DBの大量データ、ファイル、大きなJSONなどを直接 KMS に送って暗号化するのは通常やりません。

小さいデータの場合

アプリ
  ↓ Encrypt API
AWS KMS
  ↓ KMSキーで暗号化
暗号文を保存

例：

・APIキー
・トークン
・小さな設定値
・短い文字列

大きいデータの場合

アプリ
  ↓ GenerateDataKey
AWS KMS
  ↓ 平文データキー + 暗号化済みデータキー
アプリ
  ↓ 平文データキーでファイルやDBカラムを暗号化
保存

この方式がエンベロープ暗号化です。

Encryption Context は何をしているか

KMS では Encryption Context という追加情報を付けられます。これは秘密情報ではありません。「この復号処理は、どの用途・どのリソースに対するものか」を紐づけるための追加認証データです。

例：

SecretARN = arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:xxx
TableName = customer
Environment = prod

Encryption Context を付けて暗号化した場合、復号時にも同じ Encryption Context が必要です。AWS KMS のドキュメントでも、暗号化時に Encryption Context を指定した場合、復号時には大文字小文字まで完全一致する同じ Encryption Context が必要と説明されています。

これにより、たとえば KMS キーポリシーで「この Secrets Manager のシークレットに対する復号だけ許可する」のような制御ができます。

キーポリシーや IAM はどこで効くのか

KMSキーを使うには、権限が必要です。たとえば復号なら、kms:Decrypt が必要です。

データキー生成なら、kms:GenerateDataKey が必要です。

暗号化なら、kms:Encrypt が必要です。

さらに、カスタマーマネージドキーでは、キーポリシー、IAM ポリシー、グラントなどで利用権限を制御できます。カスタマーマネージドキーはユーザーが作成・所有・管理する KMS キーで、キーポリシー、IAM ポリシー、グラント、ローテーション、削除などを制御できます。

つまり、復号時には次のようなチェックが行われます。

1. 呼び出し元は誰か？
   例: IAM ロール、AWS サービス、別アカウントのロール

2. その呼び出し元に kms:Decrypt が許可されているか？

3. キーポリシー上も許可されているか？

4. 条件に合っているか？
   例:
   - kms:ViaService
   - kms:EncryptionContext
   - kms:CallerAccount

kms:ViaService の意味

AWS サービス経由でだけ KMS キーを使わせたい場合があります。

たとえば、以下の場合です。

このキーは Secrets Manager 経由でだけ使わせたい。
EC2 や CLI から直接 Decrypt されたくない。

そのときに使う条件が kms:ViaService です。

イメージ：

"Condition": {
  "StringEquals": {
    "kms:ViaService": "secretsmanager.ap-northeast-1.amazonaws.com"
  }
}

これにより、

Secrets Manager → KMS

の呼び出しは許可するが、

ユーザー / アプリ → KMS

の直接呼び出しは制限する、といった設計ができます。

まとめると、KMSキーの役割は何か

KMS キーの役割は、主にこれです。

データ本体を守る鍵を、さらに守る

もう少し正確に言うと、

KMSキー
  = データキーを生成・暗号化・復号するための上位キー

データキー
  = 実際のデータ本体を暗号化・復号する鍵

暗号化済みデータキー
  = 後で復号するためにデータ本体と一緒に保存する鍵の包み

暗号化済みデータ本体
  = S3オブジェクト、EBS、RDS、Secrets Managerの値など

一言でいうと、以下になります。

KMSキーは、データを直接大量に暗号化する鍵というより、データ暗号化に使うデータキーを安全に管理・保護するための鍵です。

この理解を持っておくと、S3、EBS、RDS、Secrets Manager、アプリケーション暗号化、クロスアカウントの KMS 権限設計がかなり分かりやすくなります。

KMS は昔と今で用語が変わっているので注意

古い資料と新しい資料を読むと、用語で混乱します。私も混乱した時がありました。その原因は KMS の用語が変わったからです。

以下に新旧の用語を整理します。

旧用語現在の用語意味
Customer Master Key / CMKKMS keyAWS KMS のキー全般
Customer managed CMKCustomer managed keyユーザーが作成・管理するKMSキー
AWS managed CMKAWS managed keyAWSサービスが自動作成・管理するKMSキー
AWS owned CMKAWS owned keyAWSが所有・管理し、ユーザーからは見えないキー

昔は CMK というと KMS キー全般を意味していました。今は CMK というとカスタマーマネージドキーで、ユーザーが作成・管理している KMS キーを指します。

CMK という呼び方は避ける

CMK という用語をカスタマーマネージドキーの意味で利用するケースは多いと思いますが、CMK より『カスタマーマネージドキー』もしくは『Customer managed key』を使用する方が認識の齟齬がなくせます。

KMS キーとデータキーの違い

様々な用語で混乱することがありますが、KMS キーとデータキーは異なります。

  • KMS キー　…　データキーを保護する親キー
  • データキー　…　実際にデータを暗号化するための一時的なキー

AWS 所有キー（AWS owned key）、AWS 管理キー（AWS managed key）、カスタマーマネージドキーの違いについて

様々な用語が異なるコンテキストで出てくるので混乱することがあります。まずは、以下の3種類をまとめて KMS Key（KMS キー）と言います。KMS Key（KMS キー）は、キー階層の最上位を表します。KMS Key には以下の 3種類のキーが含まれます。

  • AWS 所有キー（AWS owned key）　…　AWS が所有・管理するキーでユーザー側は管理できません。
  • AWS 管理キー（AWS managed key）　…　AWS がユーザーのアカウント内に作るキーです。
  • カスタマーマネージドキー（Customer managed key）　…　ユーザーが作成するキーです。

AWS 所有キー（AWS owned key）

AWS が所有しているキー です。特徴は、ユーザーがアカウントのキーとして見えない、キーポリシーも見えない、基本的に管理もできないことです。

AWS 管理キー（AWS managed key）

AWS サービスがユーザーのアカウント内に自動作成する KMS キー です。たとえば aws/rds、aws/ebs、aws/s3 のような AWS 管理エイリアスで見えるものがこれです。

ユーザーのアカウント内に存在するので、メタデータ や CloudTrail の記録は見えますが、自由にキーポリシーを編集したり削除したりはできません。ローテーションはAWS側が毎年実施します。イメージとしては、自分のアカウントにはあるけれど、管理権はほぼ AWS 側にある鍵です。

使い道として向いているのは、まずは簡単に AWS サービスの暗号化を有効にしたい 場合です。ただし、アクセス制御や運用を細かく詰めたいときは不向きです。

カスタマーマネージドキー（Customer Managed Key、旧CMK）

ユーザーが作る KMS キー です。キーポリシー、IAM ポリシー、Grant、エイリアス、タグ、有効/無効、削除予約、ローテーション まで自分で管理できます。フルコントロールしたい場合は、カスタマーマネージドキーを選択します。月額料金と使用料金がかかります。

イメージとしては、自分で所有・運用する鍵です。向いているのは以下のようなケースです。

  • 特定ロールだけに復号を許したい
  • キーポリシーを細かく書きたい
  • クロスアカウントで利用したい
  • 削除や無効化の運用を自分で管理したい
  • 監査要件で自分が管理する鍵が必要

こういうときは、基本的にカスタマーマネージドキーを使います。

キーの有効期限を設定する場合はカスタマーマネージドキー（Customer managed key）を使用する

AWS 管理キー（AWS Managed Key）には有効期限を設定して無効にする制御はできません。有効期限を設定したい場合はカスタマーマネージドキー（Customer Managed Key）を使用する必要があります。更にカスタマーマネージドキーは持ち込みのキーでインポートをする際に有効期限を設定します。

AWS KMS が利用できる対象サービス

AWS KMS は、ほとんどの AWS のサービスとシームレスに統合されています。KMS は主に「保存データの暗号化キー管理」に使うサービスなので下図のようにデータを保存するサービスで利用できます。

AWS KMS が利用できる対象サービスに入っていないサービス

逆に以下のサービスは KMS が利用できません。

  • EC2 インスタンス
  • Route 53

EC2 インスタンス

EC2 インスタンスは「直接 KMS を使うサービス」ではありませんが、EBS 経由では KMS を利用できます。EC2 インスタンスそのものは、仮想サーバーです。EC2 インスタンス自体を KMS キーで暗号化する、という考え方は基本的にありません。

ただし、EC2 にアタッチする EBS ボリューム は KMS で暗号化できます。ボリュームやスナップショットを KMS キーで暗号化できます。

Amazon EBS 暗号化は、Amazon EC2 インスタンスに関連付けられた EBS リソースの簡単な暗号化ソリューションとして使用できます。Amazon EBS 暗号化では、独自のキー管理インフラストラクチャを構築、保守、保護する必要はありません。Amazon EBS 暗号化は、暗号化されたボリュームとスナップショットを作成するときに、 AWS KMS keys を使用します。

Route 53

Route 53 のホストゾーンや DNS レコードに対して KMS キーで暗号化することはありませんが、Route 53 の DNSSEC 署名では、キー署名キー、KSK を作成するために カスタマーマネージドキーを使用します。Route 53 で DNSSEC 署名を有効にすると、KSK 作成のために DNSSEC をサポートする AWS KMS のカスタマーマネージドキーを使う必要があります。

カスタムキーストア

AWS マネジメントコンソールの KMS のメニューにカスタムキーストアがあります。

カスタムキーストアは KMS キーのキーマテリアルを通常の AWS KMS 標準保管ではなく、別の保管先で扱うための仕組みです。カスタムキーストアとして主に AWS CloudHSM キーストア と 外部キーストア（XKS） を案内しています。

AWS CloudHSM キーストア

AWS CloudHSM キーストアは、ユーザー自身が所有・管理する CloudHSM クラスター内でキーマテリアルを生成・保存・利用する方式です。KMS への暗号操作リクエストは、裏で CloudHSM クラスターに転送されて処理されます。CloudHSM は AWS 上でホストされますが、シングルテナントで、可用性や運用の責任をユーザー自身で持つ点が標準 KMS と大きく違います。

AWS KMS External Key Store（外部キーストア、XKS）

AWS KMS External Key Store（外部キーストア）とは、AWS の外部にある鍵管理システムや HSM でキーマテリアル（鍵素材）を保持し、AWS KMS からはプロキシ経由で利用する方式です。規制要件の強いワークロード向けの上級機能です。鍵を AWS の外に置きたいという要件で使われます。AWS KMS のキーを使う形は保ちつつ、実際の鍵素材と暗号処理を AWS の外に置く仕組みです。

通常の KMS ではキーマテリアル（鍵素材）は AWS KMS 内にありますが、XKS ではキーマテリアル（鍵素材）は外部キーマネージャーから出ません。

カスタムキーストアの重要な特徴

カスタムキーストアのキーは、標準の KMS キーよりも可用性・性能・レイテンシの面で不利になる可能性があります。外部依存が増えるからです。また、外部キーストアでは、作成できるキーは外部キーストア起源の対称暗号化 KMS キーに限られ、非対称キー、HMAC キー、インポートキーマテリアル付きキーは作れません。CloudFormation の AWS::KMS::Key でも、カスタムキーストア上の KMS キーは作成対象にできないとされています。

サーバ側暗号化とクライアント側暗号化がある

  • サーバ側暗号化（SSE-S3、SSE-KMS、SSE-C）
  • クライアント側暗号化（CSE-KMS、CSE-C）

クライアント側暗号化の何が嬉しいかというと「Amazon S3 に送信する前にデータを暗号化できる」ことです。

クライアント側の暗号化を使用したデータの保護

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/UsingClientSideEncryption.html

その一方、サーバ側暗号化は「送信先でデータを暗号化する」ことを言います。

Amazon S3 は、データセンターのディスクに書き込まれるときにデータをオブジェクトレベルで暗号化し、クライアントがデータにアクセスするときに復号します。その為、例えば会社のPCからS3バケットへファイルをアップロードするとか保存する場合は、サーバ側の暗号化だけでなく、クライアント側の暗号化もするとよりセキュリティが高まります。

x-amz-server-side-encryption

x-amz-server-side-encryption は、S3 にオブジェクトを書き込むリクエストに付ける指定ヘッダーです。このヘッダーを付けるのはアップロードする側のクライアントで、判断するのは S3、対象は S3 に保存されるそのオブジェクトです。S3 の REST API では、PutObject やマルチパートアップロード開始時にこのヘッダーを指定できます。

どこで有効になる（判断される）？

S3 に保存されるオブジェクトの保存時の暗号化の際に判断されます。通信経路ではなくバケット内に保存された後のデータに対して判断されます。S3 のサーバー側暗号化は at rest の保護であり、S3 がオブジェクトを保存するときに暗号化を行います。

暗号化キーとは何か？

そもそも暗号化キーとは何でしょうか。公開鍵認証基盤の秘密鍵と公開鍵をイメージすればいいのでしょうか？それとも共通鍵をイメージすればいいのでしょうか？KMS は、「対称キー」と「非対称キー」のどちらも提供しています。なのでどちらをイメージしても間違いではありません。

対称キーと非対称キーの使用

https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/symmetric-asymmetric.html

AWS KMS は、対称暗号化 KMS キーと非対称 KMS キーをサポートしています。

対称暗号化 KMS キー

AWS KMS が生成する単一の対称鍵を表します。標準の対称暗号化 KMS キーは、通常 256-bit AES-GCM のキーマテリアルを使用します。このキーマテリアルが AWS KMS を平文のまま外部に出ることはありません。このキーを使った暗号化・復号を行うには、AWS KMS を呼び出す必要があります。

非対称 KMS キー

数学的に関連した公開鍵と秘密鍵のペアを表します。秘密鍵が AWS KMS を平文のまま外部に出ることはありませんが、公開鍵は取得して AWS KMS の外部で利用できます。非対称 KMS キーは、キー仕様に応じて、暗号化と復号、署名と検証、または鍵共有（key agreement）のいずれか1つの用途に使用します。

Encryption Context（暗号化コンテキスト）

KMSキーの Encryption Context（暗号化コンテキスト） は、暗号化するデータにひも付ける「追加の説明情報」 です。形式としては キーと値のペア で渡し、これを AAD（Additional Authenticated Data: 追加認証データ） として使い、暗号文に“結び付けて”保護します。暗号化時に付けた暗号化コンテキストと、復号時に指定する暗号化コンテキストが 完全一致 しないと復号できません。

Encryption Context（暗号化コンテキスト） は、復号時の取り違え防止のために使用します。対称暗号化 KMS キーを使う暗号化操作で利用します。非対称鍵の暗号化 や HMAC では暗号化コンテキストは利用できません。

KMS の自動キーローテーション機能

KMS の自動キーローテーション機能は、KMS キーそのものを作り直すのではなく、同じ KMS キーの中の鍵素材（キーマテリアル、key material）を定期的に入れ替える機能です。AWS KMS では、対称暗号のカスタマーマネージドキーに対して自動ローテーションを有効化でき、AWS マネージドキーは毎年自動でローテーションされます。

鍵素材（キーマテリアル、key material）とは

KMS キーの中の鍵素材（キーマテリアル、key material） とは、実際に暗号計算に使われる生の暗号鍵データそのものです。KMS キーは、見た目上は 1 つのキー ID や ARN を持つ論理的なキーですが、KMS キーはトップレベルキーマテリアルのコンテナとして説明されています。キー ID や ARN は入れ物で、その中身が鍵素材です。

以下の構成です。

  • KMS キー = 管理用の箱、識別子、ポリシー、設定を持つ論理オブジェクト
  • 鍵素材 = その箱の中で実際に暗号化・復号・署名・MAC 生成に使われる秘密データ

KMS コンソールで見ているキー ARN やエイリアスそのものが暗号処理しているわけではなく、その背後にある鍵素材が処理しています。

AWS KMS の制限

AWS KMS には API リクエストの制限（レートリミット）があります。一定期間に大量のリクエストを送信するとスロットリング（リクエスト拒否）が発生します。

KMS グラント（Grant）

KMS グラントとは、AWS プリンシパルが KMS キーに対して、暗号化操作（暗号化・復号・データキー生成）できる権限を与える仕組みです。特定の KMS キーに対して、特定のプリンシパルへ一時的な権限を与えます。既存のポリシーを書き換えずに使用し、不要になったら削除できるので一時的な権限付与で利用します。

STS は期限が切れれば無効になりますが KMS グラントは期限を設定できなく利用が終わったら自身で削除する必要があります。

KMS グラント（KMS Grant）を利用する例

例えば、自社の S3 バケットのデータに数社の外部ベンダーがアクセスをする場合、ポリシーで管理しようとすると以下のようになります。

{
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "arn:aws:iam::111111111111:role/vendor-role-a",
      "arn:aws:iam::222222222222:role/vendor-role-b",
      "arn:aws:iam::333333333333:role/vendor-role-c"
    ]
  },
  "Action": [
    "kms:Decrypt"
  ],
  "Resource": "*"
}

この場合、ベンダーが増減するとその度にポリシーの修正が必要になります。しかしクリティカルなデータを守るポリシーを頻繁に修正するのはかなりのリスクがあります。そこで KMS グラントを利用します。

KMS グラントは以下のように AWS CLI ベースでkms create-grantコマンドを実施します。

aws kms create-grant \
  --key-id arn:aws:kms:ap-northeast-1:111111111111:key/abcd-1234 \
  --grantee-principal arn:aws:iam::222222222222:role/vendor-read-role \
  --operations Decrypt DescribeKey \
  --region ap-northeast-1

不要になったら以下のようにグラントを取り消します。

aws kms revoke-grant \
  --key-id arn:aws:kms:ap-northeast-1:111111111111:key/abcd-1234 \
  --grant-id a1b2c3d4example \
  --region ap-northeast-1

このように運用することでポリシーを都度修正せずにベンダーに対して権限を追加したり削除したりできます。

Grant 作成直後に失敗することがある

AWS KMS API は結果整合性モデルに従います。グラントの作成時、グラントがすぐに有効にならないことがあります。変更が AWS KMS全体に適用されるまでに数秒もかかりませんが、場合によっては数分かかることがあります。その場合、リクエストはAccessDeniedExceptionエラーで失敗する可能性があります。

新しいグラントでアクセス許可をすぐに使用するには、グラントのグラントトークンを使用します。CreateGrant オペレーションによって返されるグラントトークンを保存して利用します。

AWS AWS認定試験 セキュリティ
AWS AWS認定試験 CMK KMS
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

サイト管理人

関連記事

コメント

コメントする

AlphaOmega Captcha Classica  –  Enter Security Code
  ⟲    ➴
 

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。