実践 Amazon KMS #cmdevio2015

自己紹介

2Ⓒ Classmethod, Inc.

こんにちは，虎塚です

Twitter & Hatena-id: torazuka

最近の趣味は昔の翻訳SFを読むことです

AWSコンサルティング部で構築の仕事をしています

鳥形由希と申します

おすすめがあれば教えてください．

本日の内容• Amazon KMSの仕組み • Amazon KMSの機能 • マスターキーの識別子 • Amazon KMSの権限管理 • AWSサービスとの連携 • まとめ


このスライドの内容は2015年3月時点の情報に基づいていますスライドは後日Web上で公開します

Amazon KMSの仕組み

Key Management Service (KMS)• re:Invent 2014で発表されました • 全リージョンで利用できます • データ暗号化と復号用の鍵をAWS上で管理します


正確には，データの暗号化に使う鍵（データキー）を暗号化するための鍵（マスターキー）を管理できます

KMSが扱う2種類の鍵の特徴


マスターキーデータキー

AWS内部で永続化される AWS内部で永続化されない

ユーザがローカルにエクスポートできない

ユーザがローカルにエクスポートできる

データキーを暗号化するデータを暗号化する

一般的なデータと暗号化のおさらい

8

データの暗号化


データ暗号化

鍵

暗号化されたデータ

秘

鍵の保管場所が問題になる



暗号化されたデータと鍵を一緒に保管するのは危険

鍵

秘

単独で盗まれても大丈夫だが

鍵と一緒に盗まれるとアウト

鍵の暗号化


データ暗号化

鍵


暗号化

鍵の鍵

暗号化対象と同じ鍵は使えないので，別の鍵を用意する暗号化された

鍵

秘

秘

鍵の鍵の保管場所が問題になる



問題が解決していない！

暗号化された鍵

秘

暗号化された鍵と暗号化されたデータを盗まれても大丈夫だが

鍵の鍵と一緒に盗まれるとアウト

鍵の鍵

秘

解決法: 鍵の鍵を安全な場所で保管する



暗号化された鍵

秘鍵の鍵

秘安全な場所

OK

安全な場所 = Amazon KMS



暗号化されたデータキー

秘マスターキー

秘 Amazon KMS

OK

AWS/オンプレミス（場所を問わない）

自分で用意した“安全な場所”より安全

マスターキーとデータキーの特徴(再掲)







Amazon KMSの機能

マスターキーのライフサイクル


利用不能な状態

create

disableenable

updaterotate 利用可能な状態

マスターキーの管理


マスターキー管理者

利用不能利用可能利用可能

作成無効化有効化削除

※削除はサポートされていません

情報更新

マスターキーに対して可能な操作は，概ね次のとおりです

マスターキーの状態

情報取得

マスターキーの管理操作に対応するKMS API



CreateKey DisableKey EnableKey

ListKeyPolicies

ListKeysListAliases

GetKeyPolicyGetKeyRotationStatus

DescribeKeyCreateAliasDeleteAlias

DisableKeyRotationEnableKeyRotation

UpdateKeyDescription

PutKeyPolicy

情報取得情報更新

作成状態変更


マスターキーに対して直接可能な操作は，次の4つのカテゴリに分けられます

データキーのライフサイクル


generate

平文の状態

暗号化状態

encryptdecrypt

データキーの利用


利用可能

データキーの利用者

データキーの生成

対応するマスターキーの状態

データキーの復号データキーの暗号化

データキーに対して可能な操作は，次のとおりです

データキーの利用操作に対応するKMS API


利用可能

Encrypt DecryptReEncrypt

GenerateDataKey

GenerateDataKeyWithoutPlaintext

データキーの生成データキーの復号データキーの暗号化

マスターキーの作成


• Policy（権限）やDescription（説明）を指定して，マスターキーを生成します • 作成されたマスターキーはAWSに永続化されます

AWS KMSCreateKey(Description, Policy)

KeyID, ARN, 作成日, など

マスターキーを生成して保管する

マスターキーの管理者

マスターキーそのものは返却されない

データキーの生成


• マスターキーのIDを指定して，データキーを生成します • 作成されたデータキーはAWS側に永続化されません

AWS KMSGenerateDataKey(KeyID)


データキー

秘データキーの利用者

指定されたマスターキーでデータキーを生成

データキー自体は保管しない

データキー自体が返却される

データキーでデータを暗号化


@ローカル

データ

暗号化

データキー


秘暗号化されたデータキー

秘


使い終わったら即座に捨てる

重要

大事に保管する

暗号化されたデータキーを紛失すると，データを復号できなくなります！

超重要

データキーの復号


• 暗号化されたデータキーを渡して，データキーを復号します

AWS KMSDecrypt(CiphertextBlob)


データキー

秘データキーの利用者

暗号化に使われたマスターキーでデータキーを復号

データキー自体は保管しない

秘

データキーでデータを復号


@ローカル


復号

データキー

データ


秘使い終わったら即座に捨てる

重要

• GenerateDataKeyとEncryptの違い • GenerateDataKey: データキーの生成とデータキーの暗号化 • Encrypt: 渡されたデータの暗号化 (データキーに限らない)

• 名前から想像しづらい対称性 • GenerateDataKeyとDecryptが対 • EncryptとDecryptが対

• ReEncryptの意義 • 古い鍵で暗号化されたデータを復号し，別の鍵で暗号化する

落とし穴: データキーのAPIが分かりづらい


マスターキーの有効化/無効化


• マスターキーを無効化すると，そのマスターキーを利用するデータキーの操作が，すべて失敗するようになります • データキーが復号できない＝暗号化したデータの復号もできない

無効化有効化



データキーの生成データキーの復号データキーの暗号化


マスターキーのローテーション


• マスターキーには1年ごとのローテーションを設定できます • ローテーションされたキーは，それ以降，復号だけに利用されます

有効な鍵

active

deactivated

ローテーション

ローテーション以降のすべてのリクエスト

ローテーション以前のマスターキーで作成されたデータキーの復号リクエスト

マスターキーとデータキーの特徴(再掲)







マスターキーの識別子

マスターキー• Amazon managedなデフォルトマスターキー

• ユーザが作成したカスタマーマスターキー


マスターキーの4種類の識別子 (Identifier)


KeyID

KeyIDのARN

エイリアス名

エイリアスのARN

ARN(Amazon Resource Name) =AWSの様々なリソースを一意に識別する名前

1

1 1

0～n

0～n

エイリアス名とは• マスターキーの表示名 • 「alias/」から始まる文字列 • 「alias/aws」から始まるエイリアスはAWSが予約済み • (例) 「alias/aws/s3」はS3のデフォルトマスターキー

• アカウント内のリージョンで一意になる • 1つのアカウントの1つのリージョンに同じエイリアス名は2つ存在できない

• 一度削除してから同じ名前で作り直すことはできる • 同一のエイリアス名を別リージョンに作ることもできる • 操作ミスの原因になるので特に理由がなければ避けた方がよい


マスターキーの識別子 (1/2)

• Key ID (Globally Unique Key ID) • 例: 1234abcd-12ab-34cd-12ab-123abc456dab • 一覧方法:

• エイリアス名 • 例: alias/aws/s3 • 一覧方法:


aws kms list-aliases | jq '.Aliases[].AliasName'

aws kms list-keys | jq '.Keys[].KeyId

KMSのAPIで，マスターキーを指定する際には，次の4種類の識別子のどれを使います

マスターキーの識別子 (2/2)• Key IDのARN • 例: arn:aws:kms:リージョン名:AWSアカウントID:key/1234abcd-12ab-34cd-12ab-123abc456dab

• 一覧方法:

• エイリアスのARN • 例: arn:aws:kms:リージョン名:AWSアカウントID:alias/aws/s3

• 一覧方法:


aws kms list-aliases | jq '.Aliases[].AliasArn'

aws kms list-keys | jq '.Keys[].KeyArn'

KeyIDとエイリアスの関係性


KeyID

KeyIDのARN

エイリアス名


参照 (target key id)

エイリアスはただ1つのKey IDと関連づけられる (これをエイリアスから見てtarget key idという)

エイリアスは複数付けたり，付け替えたりできる


KeyID

KeyIDのARN

エイリアス名

エイリアスのARNエイリアス名


NEW

NEW

AMCでのカスタマーマスターキー作成: エイリアスも作成


AMC(Amazon Management Console) から作成する場合，同時にエイリアス名の作成が必須

CLIでのカスタマーマスターキー作成: エイリアス作成は任意


% aws kms create-key

{ "KeyMetadata": { "KeyId": "1234abcd-12ab-34cd-12ab-123abc456dab", "Description": "", "Enabled": true, "KeyUsage": "ENCRYPT_DECRYPT", "CreationDate": 1427453438.697, "Arn": "arn:aws:kms:ap-northeast-1:123456789012:key/1234abcd-12ab-34cd-12ab-123abc456dab", "AWSAccountId": "123456789012" }

AWS-CLIを使うと，エイリアス名を作成せずにマスターキーを作成できる実行結果

(補足) エイリアス名のない鍵


AWS-CLIでエイリアス名を指定せずに作成した鍵をAMCで確認すると，エイリアス名の欄が空白になっている

鍵の作成時以外にエイリアス名を編集するには，AWS CLIを利用する

KeyIDとKeyIDのARNが作成された


KeyID

KeyIDのARN

1234abcd-12ab-34cd-12ab-123abc456dab

arn:aws:kms:ap-northeast-1:012345678901:key/1234abcd-12ab-34cd-12ab-123abc456dab

エイリアスの作成方法


% aws kms create-alias --alias-name alias/alias-test \ 　--target-key-id 1234abcd-12ab-34cd-12ab-123abc456dab

% aws kms list-aliases | jq '.Aliases[]' \ | jq 'select(.AliasName == "alias/alias-test")'

{ "AliasArn": "arn:aws:kms:ap-northeast-1:012345678901:alias/alias-test", "AliasName": "alias/alias-test", "TargetKeyId": "1234abcd-12ab-34cd-12ab-123abc456dab" }

作成

確認※KeyIDは，キー作成時の戻り値に表示されています

エイリアス名とエイリアスのARNが作成された


KeyID

KeyIDのARN



エイリアス名


参照 (target-key-id)

alias/alias-test

arn:aws:kms:ap-northeast-1:012345678901:alias/alias-test

エイリアスの変更方法


% aws kms delete-alias --alias-name alias/alias-test

% aws kms list-aliases | jq '.Aliases[]' \ | jq 'select(.AliasName == "alias/alias-changed")'

{ "AliasArn": "arn:aws:kms:ap-northeast-1:012345678901:alias/alias-changed", "AliasName": "alias/alias-changed", "TargetKeyId": "1234abcd-12ab-34cd-12ab-123abc456dab" }

削除

確認

% aws kms create-alias --alias-name alias/alias-changed \ 　--target-key-id 1234abcd-12ab-34cd-12ab-123abc456dab

再作成

エイリアスが付け替えられた


KeyID

KeyIDのARN



エイリアス名


参照

alias/alias-test

arn:aws:kms:ap-northeast-1:012345678901:alias/alias-test

エイリアス名


NEW

NEWalias/alias-changed

arn:aws:kms:ap-northeast-1:012345678901:alias/alias-changed

エイリアス付け替えの役割カスタマーマスターキーを明示的に入れ替える


KeyID

利用者

KeyID

エイリアス名

NEW

以前と同一のエイリアス名で新しいカスタマーマスターキーを使うことができる

付け替え

利用

エイリアスを付け替えるユースケース例• 古いキーで暗号化したデータを復号させたくない場合 • ローテーションをしても古いキーでの復号がサポートされ続けるが，実体となるキーを切り替えることで，現在よりも古いキーを切り捨てられる

• アプリケーションにエイリアス名を埋め込んで別リージョンでも動かしたい場合 • アプリケーション移行先のリージョンに同じエイリアス名のカスタマーマスターキーを用意する

• ソースコードを変更しなくてよい


※既存の暗号化済みデータは，元のリージョンの鍵で暗号化しているので，データ移行はできません

マスターキーの識別子: まとめ• マスターキーを特定する4種類の識別子 • Key ID，KeyIDのARN，エイリアス名，エイリアス名のARN

• エイリアス名とは • 「alias/」から始まる表示名 • アカウント内のリージョンで一意 • AMCから鍵を作成するときはエイリアス名も同時作成 • AWS CLIで鍵を作成するときは同時作成でも後からでもOK

• 付け外しできるエイリアス名の意義 • カスタマーマスターキーを明示的に切り替えることができる


Amazon KMSの権限管理

Amazon KMSの権限管理• Key Policyとは • デフォルトKey Policy • よくある落とし穴

• KMSを安全に運用するために


※Grantの話は今回省略しました

Key Policy


• キーに直接適用するアクセス可否の定義 • 「誰が」「どのキーを」使用可能かを指定する • AWSアカウントやユーザ，IAMユーザなどをPrincipalの値として指定する

• IAM Policyと同じくAWS API単位で操作種別を限定できる • ベストプラクティス:カスタマーマスターキーの作成時にPolicyを与える • 明示的に与えない場合，デフォルトのKeyPolicyが適用される • 意図せずデフォルトPolicyのままにしてしまうのを避ける


{ "Version" : "2012-10-17", "Id" : "key-default", "Statement" : [ { "Sid" : "Enable IAM User Permissions", "Effect" : "Allow", "Principal" : { "AWS" : "arn:aws:iam::012345678901:root" }, "Action" : "kms:*", "Resource" : "*" } ] }

Allow / Deny

ここではAWSアカウントの全ユーザ

デフォルトのKey Policy

キーを使うAPI操作APIで操作対象とするキー

キーへのアクセスが許可または拒否されるユーザ

落とし穴: IAMユーザがキーを使えない場合


A client error (AccessDeniedException) occurred when calling the GenerateDataKey operation: User: arn:aws:iam::012345678901:user/username is not authorized to perform: kms:GenerateDataKey on resource: arn:aws:kms:ap-northeast-1:012345678901:key/1234abcd-12ab-34cd-12ab-123abc456dab

権限不足のときのエラー例（AWS CLI）

IAMユーザでカスタマーマスターキーを作成した場合， Policyの設定が原因でキーの利用時にエラーになることがある

IAMユーザがキーを使えない場合の確認事項


• KMS APIを利用したAWSアカウントは正しいか • KMS APIを利用したユーザは正しいか • 選択したリージョンは正しいか • 利用しようとしたカスタマーマスターキーは正しいか • 異なるリージョンで同一のエイリアス名を利用できることに注意

• どのAction (API操作) に失敗したか

• 利用しようとしたユーザのIAM Policyで，上記のActionを明示的に許可しているか

• 利用しようとしたカスタマーマスターキーで，上記のユーザが Principalに含まれているか

落とし穴解説

Key Policyの確認方法


% aws --output text kms get-key-policy \ --key-id 1234abcd-12ab-34cd-12ab-123abc456dab \ --policy-name default

出力結果はフォーマットされたJSON形式で，改行文字が含まれるため，text形式で出力すると見やすい

キーの指定方法は，Key ID，またはKey IDのARNのみ (エイリアス名を使えない)

Key Policyを明示的に与えていない場合，defaultという名前でPolicyが適用されている

解決法(1) IAM Policyの修正IAMユーザ (あるいはユーザが所属するグループ) のPolicyを変更する


AWS Managed Policyの「AWSKeyManagementServicePowerUser」を採用している場合は特に注意 "Effect": "Allow", "Action": [ "kms:CreateAlias", "kms:CreateKey", "kms:DeleteAlias", "kms:Describe*", "kms:GenerateRandom", "kms:Get*", "kms:List*", "iam:ListGroups", "iam:ListRoles", "iam:ListUsers" ], "Resource": "*"

KMSの一部の操作しか許可されない

AWSKeyManagementServicePowerUserから抜粋

このPolicyはread onlyなので，必要なPolicyを新規に作成してIAMユーザに関連づける

落とし穴解説

利用するアカウントまたはIAMユーザをPrincipalに追加する

解決法(2) Key Policyの修正

利用するユーザがキーと別のAWSアカウントの時に忘れがち


[...] "Effect" : "Allow", "Principal" : { "AWS" : "arn:aws:iam::012345678901:root", "AWS" : "arn:aws:iam::555666777888:user/username" }, "Action" : "kms:*", "Resource" : "*" [...] 前掲のデフォルトKey Policyから抜粋

落とし穴解説

上のアカウントのユーザはすべて許可される下のアカウントのユーザはusernameだけ許可される

KMSを安全に運用するために• 鍵の管理者と利用者を分けましょう • 権限ごとにユーザを分けるのがIAMのベストプラクティス • 利用者には最小の権限を付与する

• AWSサービスと連携して使うときはDisableKeyを制限しましょう • RDSの暗号化に使用している鍵をDisableしてしまうと，DBからデータを取り出せなくなる．そういった事態を未然に防ぐ


Key Policyで鍵の管理と利用を分離


{ "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::012345678901:user/Administrator"}, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*" ], "Resource": "*" } {

"Sid": "Allow use of the key", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::012345678901:user/User"}, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*" }

管理系API

利用系API

DisableKey操作を制限する(1)AWSサービスと連携してKMSを利用するときは，誤って鍵を Disableする事故を防ぐため，Policyの変更を検討する

たとえば，IAM PolicyにDisableKeyの明示Denyを追加する


{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "NotAction": "iam:*", "Resource": "*" } ] }

{ "Effect": "Deny", "Action": “kms:DisableKey", "Resource": "*" }

追加

(例) PowerUser権限

Disableすると取り返しがつかないので，鍵の管理者にも実施した方が安全

DisableKey操作を制限する(2)もしくは，AWSサービスと連携したカスタマーマスターキーの Key Policyに，DisableKeyの明示Denyを追加する


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

{ "Sid" : "Disable - DisableKey Action", "Effect" : "Deny", "Principal" : { "AWS" : "arn:aws:iam::012345678901:root" }, "Action" : "kms:DisableKey", "Resource" : "*" }

追加

デフォルトKey Policyから抜粋

• 鍵自体に制約を与える(2)のKeyPolicy編集がベター • 将来IAMユーザが増えた時，個別に対処せずに済ますため

• できれば，(1)のIAM Policy編集も併用する • ユーザにデフォルトのPolicyとしてDisableKeyを強制するため

• Key PolicyまたはIAM Policyの変更権限がない場合，最低限どちらか可能な方を実施する

DisableKey操作の制限方法の選択紹介した2つの方法は片方を実施すれば用が足りる．どちらを使えばよいか


KMSの権限管理: まとめ


• Key Policyとは • Keyに直接適用するアクセス可否定義 • カスタマーマスターキーの作成時に付与するのがベター

• デフォルトKey Policy • カスタマーマスターキーの使用時にエラーが出るときは， IAM PolicyとKey Policyを見直す

• KMSを安全に運用するために • 鍵の管理者と利用者を分けましょう • DisableKeyをIAM PolicyでもKey Policyでも制限しましょう

AWSサービスとの連携

KMSと連携可能なサービス• EBS • RDS • S3 • Redshift • Transcoder • WorkMail


これらのサービスでKMSをデータ暗号化に利用できます

利用方法は公式ドキュメントを参照ください利用にあたって注意すべきことは，スライド最後の参考資料に掲載したAWS公式のWebinar資料をご一読ください

複数の暗号化オプションの選択肢の1つとして，KMSを選べるサービスもあります

どんなときにKMSによる暗号化を選ぶか• 鍵を厳重に管理することが負担なとき • 鍵をCDに焼いて金庫にしまうのは面倒 • KMSならエクスポートの心配がない

• マルチクラウドでのデザスタリカバリをしたいとき • 鍵の鍵をエクスポートできないことが弱点に

• 物理管理のセキュリティポリシーを変えられないとき • アメリカのパトリオット法による強制捜査のリスクを重視するとき


次の場合はKMSの利用に向かないと思われます

RDSのKMSによる暗号化 (検証)


RDSインスタンスの起動暗号化用キー(KMS)の指定

カスタマーマスターキーの無効化

CloudTrailログの確認

CloudTrailログの確認

実際の運用時には絶対にやってはいけません

起動時にだけ指定できます

落とし穴: DBインスタンスが起動しない暗号化用の鍵として指定したKMSの鍵が存在しない，またはRDSでKMSを使うための権限がKey Policyに足りない場合，DBインスタンスが起動しない

解決策: Key Policyに必要な定義を追加する


どんな権限が必要かAWS managedなRDS用のデフォルトキーを参考に


落とし穴解説

"Statement" : [ { "Sid" : "Allow access through RDS for all principals in the account that are authorized to use RDS", "Effect" : "Allow", "Principal" : { "AWS" : "*" }, "Action" : [ "kms:ListGrants", "kms:Decrypt", "kms:CreateGrant", "kms:GenerateDataKey*", "kms:ReEncrypt*", "kms:DescribeKey", "kms:Encrypt" ], "Resource" : "*", "Condition" : { "StringEquals" : { "kms:ViaService" : "rds.ap-northeast-1.amazonaws.com", "kms:CallerAccount" : "012345678901" } } }] RDSが透過的に暗号化/復号するためのPolicyが必要

落とし穴: 暗号化に使った鍵をDisableした


DBインスタンスにクライアントからアクセスできなくなり，AMCからもDeleteかRestoreしかできなくなることがある

Statusが「inaccessible-encryption-credentials」になる

何が発生しているかRDSを暗号化すると，クライアントから書き込みがなくてもAWS内部でGenerateDataKeyのイベントが定期的に発生する

（おそらく鍵の有効性を確認している）


落とし穴解説

{ [...] "eventName":"GenerateDataKey", [...] "userAgent":"v1.0, aws-internal/3", [...] "eventType":"AwsServiceEvent", [...]}

CloudTrailログから抜粋

APIコール以外で発生したイベントであることを示す

何が発生しているかKeyをDisableにすると，このリクエストがエラーになる一定期間エラーが続いた後，DBインスタンスが無効になる


落とし穴解説

{ [...] "eventSource":"kms.amazonaws.com", "eventName":"GenerateDataKey", [...] "userAgent":"v1.0, aws-internal/3", "errorCode":"DisabledException", "errorMessage":"arn:aws:kms:ap-northeast-1:012345678901:key/1234abcd-12ab-34cd-12ab-123abc456dab is disabled.", [...] "eventType":"AwsServiceEvent", [...]}

CloudTrailログから抜粋

誤ってDisableKeyしたときの対処RDSの暗号化に使った鍵をDisableしてしまった場合，内部のデータにアクセスできなくなる

次を実行する

1. マスターキーをEnableに戻す

2. DBインスタンスをDeleteする

3. スナップショットからDBをリストアする


落とし穴解説

AWSサービスとの連携: まとめ


• KMSとAWSサービスの連携を利用したときは，鍵のDisableに注意しましょう • RDSの場合は，KMSの利用とスナップショットの定期取得はセットであると考える

• AWSサービスと連携してもKMSはKMS • 挙動の基本は同じ

まとめ

まとめ• KMSの仕組みを理解して，データキーを正しく取り扱いましょう • 暗号化されたデータキーは大切に保管しましょう • 平文のデータキーは使ったらすぐ捨てましょう

• エイリアスを活用すると古いキーを捨てられます • Key Policyの活用でKMSを安全に運用しましょう

• AWSサービスと連携したKMSの活用も，上記の延長線上です


参考資料• AWS Key Management Service • http://aws.amazon.com/jp/kms

• AWS Key Management Service whitepaper • https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf

• AWS Black Belt Techシリーズ AWS Key Management Service • http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-aws-key-management-service

• AWS Black Belt Tech Webinar - AWS Key Management Service を開催しました • http://aws.typepad.com/sajp/2015/02/black-belt-kms.html


Developer Day

ご清聴ありがとうございました。スライドは後日ブログで公開します。

81

H-1

Ⓒ Classmethod, Inc.

#cmdevio2015

Documents

実践 Amazon KMS #cmdevio2015