「実践 Amazon KMS」 #cmdevio2015 #cmdevio2015H

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

こんにちは、虎塚です。

先日、Developers.IO 2015のテクニカルディープセッションで、Amazon KMS (Key Management Service) についてお話ししました。今日は、そのスライドと内容をご紹介します。

イベントにご参加いただいた皆様、ありがとうございました。

スライド

「実践 Amazon KMS」というタイトルで、KMSを実際に使う上で気をつけるポイントや落とし穴を中心にご紹介しました。

序盤は、以前発表した「10分でわかる!Key Management Serviceの仕組み」というLTと同じ内容です。

続いて、マスターキーを識別するエイリアス、鍵の権限管理、そしてAWSサービスと連携したKMSの利用について、新たにまとめてお話ししました。

セッションの内容

Amazon KMSの仕組み

KMSでいう「鍵」には2種類あります。データを暗号化する鍵がデータキー、データキーを暗号化する鍵がマスターキーです。

Amazon KMSは、「鍵の鍵」を管理するサービスです。

Amazon KMSの機能

マスターキーとデータキーのライフサイクルと、KMSが提供するAPIの機能を、図を使って説明しました。

データキーでデータを暗号化/復号する際に、セキュリティを維持するための大原則は、次の2つです。

  • データの暗号化/復号に使った平文のデータキーは即座に破棄する
  • データキー生成時に取得した暗号化されたデータキーは大事に保管する

また、KMS APIを使っていて、地味に分かりづらかった点を共有しました。

  • GenerateDataKeyは1つのAPIで2つのことをする(データキーの生成と暗号化)
  • API名から想像しづらいが、GenerateDataKeyとDecryptはデータキーの利用時に対になる
  • ReEncryptは「暗号化に使う鍵を変えたいとき」という特殊なユースケースで使う

マスターキーの識別子

マスターキーの識別子の1つにエイリアスがあります。エイリアスは、マスターキーの表示名です。1つのマスターキーには、複数のエイリアスをつけられます。

エイリアス付け替えの役割

エイリアスを使うと、マスターキーを明示的に切り替えることができます。ユースケースとして、マスターキーのローテーション後、古いキーで暗号化したデータを復号させたくない場合には、この機能が便利です。

Amazon KMSの権限管理

Key Policyとは、KMSのKeyに直接適用するアクセス可否の定義です。KMSを安全に運用するにはKey Policyの設定が重要です。

IAMのベストプラクティスどおり、まずは鍵の管理者と鍵の利用者を分けましょう。次に、DisableKey APIの操作権限を制限します。

Key Policyを明示的に指定せずにマスターキーを作成すると、デフォルトのKey Policyが適用されます。デフォルトのKey Policyには、鍵をDisableする権限があるので、場合によっては危険です。そこで、Key PolicyおよびIAM Policyで、DisableKeyを禁止しておきましょう。

AWSサービスとの連携

KMSは、S3、EBS、RDS、Redshiftlなどの様々なAWSサービスで暗号化鍵のオプションとして利用できます。今回は、RDSでKMSを使う検証をしていた時に得たundocumentedなネタを中心にお話ししました。

RDSをKMSで暗号化する設定で起動すると、AWS内部でGenerateDataKeyのリクエストが定期的に発生します。

RDSとKMSの連携時に何が発生しているか

その鍵をDisableすると、そのリクエストにエラーが返るようになり、一定期間でDBインスタンスが使用不能になります。こわいですね。前段のDisableKeyを禁止しようという話と繋がりました。

おわりに

KMSは素晴らしいサービスだと思いますので、どんどん便利になるといいなあと思います。今回の資料が何かのお役に立てば幸いです。

それでは、また。