「実践 Amazon KMS」補遺

2015.07.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

今日は、以前イベントでお話しした「実践 Amazon KMS」の内容について、当日や後日いただいたご質問への回答をまとめたいと思います。

Q1. データキーを暗号化したマスターキーを覚えておく必要がある?

「データキーを暗号化するのに使ったマスターキーを覚えておかないと、データキーを復号できませんか?」というご質問がありました。

回答は「いいえ、覚えておく必要はありません」です。

詳細

KMSを使った暗号化では、概念的には次の2段階で鍵を使用します。

  1. 保護したい情報を、データキーで暗号化する
  2. 暗号化に使用したデータキーを、マスターキーで暗号化する

APIを利用した実際の操作としては、次のようになります。

  1. 暗号化されたデータキーと暗号化されていないデータキーを受け取る
  2. 暗号化されていないデータキーで、保護したい情報を暗号化する
  3. 暗号化されていないデータキーを削除する
  4. 暗号化されたデータキーだけを(復号にそなえて)保管する

1つ目のステップで、暗号化されたデータキーを取得するために用意されているAPIは、次の3種類です。

  • データキーを生成して暗号化するAPI
    • generate-data-key
    • generate-data-key-withoud-plaintext
  • データキー(のように小さなデータ)を暗号化するAPI
    • encrypt

上記3種類のAPIは、引数に「データキーを暗号化するマスターキーのID」を指定して利用します。次の図は、generate-data-key APIの例です。

データキーの生成

一方、データキーを復号するために、decryptというAPIが用意されています。このAPIの引数は、「暗号化されたデータキーそのもの」だけです。

データキーの復号

上の図でいうと、CiphertextBlobが、暗号化されたデータキーを意味します。データキーを暗号化するのに使ったマスターキーは、指定する必要がありません。非対称のように感じるかもしれませんが、KMSの仕組み上、そうなっています。

(なお、発表時に、decrypt APIの説明で誤って「KeyId」を引数に渡している図を使ったために、こちらの質問をいただいたのではないかと思います。資料を訂正いたします。申し訳ありません)

補足

ちなみに、データキーを生成する際に、encryption-contextという任意のkey-value形式の文字列を引数に指定できます。この値はオプションです。

データキー生成時にこの値を使用した場合は、データキー復号時にも同じ文字列を指定しなければなりません。保管しておかなければならないのは、暗号化に使ったマスターキーでなく、こちらの値です。

Q2. RDSの暗号化に使った鍵をDisableしてもう一度Enableしたらどうなる?

「RDSの暗号化に使ったカスタマーマスターキーを無効化した場合、そのキーをもう一度有効化しても、暗号化対象のデータベースは正常に戻らないのか?」という質問を同僚から受けました。

回答は、「はい、戻りません! そのDBインスタンスはもうダメです……」です。カスタマーマスターキーの無効化には、細心の注意を払ってください。

KMSによるRDS暗号化の注意点

詳細

公式ドキュメントのとおり、DBインスタンスの暗号化に使用したキーを無効化するなどして、AWSからキーにアクセスできなくなった場合、たとえキーを後から再有効化しても、DBインスタンスは終了状態になります。DBインスタンスのバックアップからリストアするしかありません。

このような事態にそなえて、RDS暗号化にKMSを使うことにした場合は、DBの自動バックアップをかならず有効にしておきましょう

Q3. カスタマーマスターキーを使う積極的な理由は?

上記のように、カスタマーマスターキーを誤って無効化することの危険性は、デフォルトマスターキーを使えば解決します。デフォルトマスターキーは、AWSによってあらかじめ用意されたマスターキーです。デフォルトマスターキーは、ユーザ操作によって無効化できません

という話をしたところ、「それならデフォルトマスターキーではなく、カスタマーマスターキーを使う積極的な理由はあるの?(どんな時でもデフォルトマスターキーを使えばよいのでは?)」という質問を同僚から受けました。

回答は、「複数のキーポリシーを使い分けたい場合は、カスタマーマスターキーが便利です!」です。

詳細

キーポリシーとは、キーに対する操作の権限を定義したものです。

Key Policyとは

デフォルトマスターキーの場合、ポリシーもAWSから提供され、ユーザは内容を変更できません。また、デフォルトマスターキーは、リージョンごと、サービスごと(RDS、S3、ELB、Redshiftなど)に1本だけ提供されます。たとえば、東京リージョンのS3バケットを暗号化するために利用できるデフォルトマスターキーは、1種類しかありません。当然、利用できるポリシーも1種類です。

一方、カスタマーマスターキーでは、ユーザが自由にポリシーを作成して適用できます。また、リージョンに複数作成できます。複数のポリシーを用途に応じて使い分けるには、カスタマーマスターキーが便利でしょう。

Q4. データキーは無効化できる?

「カスタマーマスターキーが有効化/無効化できるのは分かったけど、データキーは削除や無効化ができるのか?」という質問を同僚から受けました。

回答は「データキーを明示的に無効化するAPIは存在しません」です。

データキーの利用

とはいえ、ユースケースとして、「作成済みの暗号化されたデータキーを、ある時点以降は復号に利用されたくない」という場合があるかもしれません。それには、次の対処法があります。

  • ユーザが特定できる場合、そのユーザによるDecrypt操作をキーポリシーで禁止する
  • ユーザが特定できない場合、マスターキーを無効化する

しかし、複数のサービスでマスターキーを共用していると、Q2で挙げたような制約が発生し、安易にキーを無効化できない状況に陥ることが考えられます。データキーの暗号化に使うマスターキーは、用途によって使い分けたほうがよいと思います。

おわりに

質問してくださった皆さん、ありがとうございました。不明点は解決しましたでしょうか?

他にもこういった話題が出てきましたら、また補遺をホイホイと書いていきたいと思います。ご質問、ツッコミ等、ぜひよろしくお願いいたします。

それでは、また。