KMS — 「鍵の鍵」を理解する
エンベロープ暗号化からキーポリシーまで、暗号化の仕組みを講義形式で腹落ちさせる
前回の復習と今回の位置付け
前回はIAMのポリシー評価を学びました。今日はKMS、つまりKey Management Service について、一緒に学んでいきます。
実は、このサービスについて一番よくある誤解があります。「KMSって暗号化の鍵を保管するサービスなんだ」と思ってる人が多いんですけど、実は、もっと深い話なんです。SCS-C03で出てくるKMS関連の問題は、落とし穴だらけなんです。
なぜか。それはKMSって「鍵を安全に保管する仕組み」だけじゃなくて、「誰が鍵を使えるか」「いつまで使えるか」「本当に安全か」という権限管理と運用まで含まれてるからです。多くの人はそこを見落とす。で、本番環境で「あ、これ動かない」という事態になります。
今日は、その全体像を一気に整理します。
エンベロープ暗号化 — 「鍵をさらに鍵で包む」という発想
まず基本から。皆さんは「暗号化」って聞いて、何を想像しますか。データを鍵で暗号化する、復号化する。はい、そう。
でも、ここで一つ問題が生まれます。データを暗号化したら、その鍵はどこに保管しますか。
例えば、EC2のインスタンスに秘密鍵を置いたとする。でも、そのEC2がハックされたら、鍵も一緒に盗まれるじゃないですか。鍵があれば、暗号化も意味ないですよね。
そこで登場するのがエンベロープ暗号化という発想です。考え方はシンプルです。「データを暗号化する鍵そのものを、さらに鍵で暗号化してしまおう」ということなんですよ。
具体的に言うと、こうなります。データを保護したい。例えば、データベースのレコード。そのデータを保護するために、データ暗号化キー、つまりDEKという鍵を作ります。このDEKはアプリケーションが持ってても大丈夫です。
そのDEKをさらに保護するために、マスターキー、つまりKMKという上位の鍵でDEKを暗号化します。マスターキーはAWSの鍵管理サービス、つまりKMSに安全に保管される。アプリケーションは絶対に持ちません。
この階層構造ですね。これがエンベロープ暗号化です。
データを直接マスターキーで暗号化するのではなく、中間の鍵を経由することで、マスターキーの使用頻度を減らし、セキュリティを強化する。ここが大事なんですよ。
なぜこれが嬉しいか。マスターキーはKMSが厳重に保管してくれる。アプリケーション側は暗号化されたDEKを持ってればいい。データが盗まれても、DEKが盗まれても、マスターキーがなければ復号できないんですよ。これ、強い。
そしてここ、重要な気づきなんですが、エンベロープ暗号化を使うと、大量のデータを高速に処理できるんですよ。なぜなら、マスターキーでの暗号化・復号化は少ない操作数で済むから。その分をDEKでやるから、全体として効率的になるんです。
試験で「大量のS3オブジェクトを暗号化したい。どうする」って聞かれたら、エンベロープ暗号化だ、と答えてください。
キーポリシー — なぜIAMポリシーだけじゃダメなのか
ここからが、多くの人が引っかかるポイントです。これ、本当に重要です。
IAMって皆さんご存知ですよね。Identity and Access Management。ユーザーやロール、リソースへのアクセス権限を管理するサービス。
「あ、じゃあKMSの鍵へのアクセスもIAMで管理すればいいんじゃないの」って思いますよね。だから多くの人は、KMSの鍵に対してIAMポリシーだけを設定して「これで安全だ」と思ってる。
でも、待ってください。それ、不完全です。なぜなら、KMSの鍵には、IAMポリシーに加えてキーポリシーという独立した権限層が存在するからなんですよ。
考えてみてください。KMSの鍵は、AWSアカウント内で非常に重要なリソースです。たとえば、データベース暗号化に使われてる。その鍵を誰でも削除できたら、大変なことになる。
IAMだけで管理すると、ルートユーザーやアカウント管理者はデフォルトで全リソースへのアクセス権を持ってしまう。つまり、意図しないアクセスが起きやすくなるんですよ。
そこで、KMSはキーポリシーという、鍵そのものに付与する権限設定を用意した。これはリソースベースのポリシーです。S3のバケットポリシーみたいな感じです。
キーポリシーでは、「このプリンシパル、つまりユーザーやロールは、この鍵を使ってDecrypt、つまり復号化はできるが、削除はできない」みたいな、細かい制御ができるんですよ。
そして、ここが大事。IAMとキーポリシーの両方が許可してない限り、その操作はできないんですよ。つまり、AND条件。両方のチェックを通る必要があるわけです。
だからですね、KMSの鍵を操作しようとして「あれ、なんでこれ動かないの」って状況になったら、まずチェックするべきは1番目、このプリンシパルのIAMポリシーにkms:Decryptが入ってるか。2番目、KMSの鍵のキーポリシーに、このプリンシパルへの許可が入ってるか。この二つです。両方揃ってないと動かない。試験でもよく出る落とし穴ですね。
グラント — 一時的な権限委譲の仕組み
次のトピック。これもね、実務的で、試験にも出るし、本番運用でも必須な考え方です。
グラント、つまりGrantというものを聞いたことありますか。グラントってのは、簡単に言うと、「期間限定で、特定のプリンシパルに対して、鍵の特定の操作だけを許可する」という仕組みです。
キーポリシーとどう違うんだ、って思いますよね。いいところに気づいた。キーポリシーは、鍵の構成として、ずっと存在する設定です。一度決めたら、変更・削除するまで有効。申し込み形式で言うと「社員証」みたいなものですね。一度発行されたら、返すまでずっと有効。
対して、グラントは、一時的な権限譲渡なんですよ。「このアプリケーションに、今から1時間だけ、Decryptの権限をあげる」みたいな感じ。申し込み形式で言うと「来客証」。来館期間中だけ有効。終わったら自動的に無効になる。
なぜ、こんな仕組みが必要かって言うと、こんなシナリオを考えてみてください。Lambda関数があるとする。その関数が、何かの条件下で、暗号化されたデータを復号化する必要がある。でも、その関数のロールに、通常は「暗号化されたデータなんか見ちゃダメ」という制限がかかってるとしましょう。
通常時はいいんですよ。でも、例えば「監査のために、この1日だけデータを見る必要がある」という状況が来たとします。キーポリシーを変更して、そのLambdaロールに権限をあげる、というのは、設定変更で大事な操作。かつ、その後に「取り消す」という操作も必要で、手作業が増える。ここで、グラントを使うんですよ。「このロールに、監査期間中だけ、Decrypt権限をあげる」と。期間が終わったら、自動的に無効になる。または、プログラムで明示的に「RetireGrant」を呼んで終了させる。
実務的には、こういう場面で使うんですよ。通常の運用はキーポリシーで、一時的な拡張権限はグラントで。これで、セキュリティレビューにも通りやすくなる。「あ、これ一時的なんだな」と。試験では、「一時的な権限が必要な場面で、何を使うか」みたいな問題が来ますね。答え、グラントです。
キーローテーション — 古いデータはどうなるのか
続いて、キーローテーション。これ、頻出トピックです。
皆さんは、暗号化の鍵って、どのくらいの期間使い続けるのが安全だと思いますか。もちろん、「できるだけ長く」と思うかもしれません。でも、セキュリティ的には、定期的に鍵を交換するんですよ。なぜか。
長く使い続けた鍵ほど、攻撃者に盗まれるリスクが高まるからです。また、もし鍵が漏洩したとしても、過去に暗号化されたデータが全部やられるわけです。だから、セキュリティのベストプラクティスとしては、定期的に新しい鍵を作って、それを使い始める。古い鍵は、新規での暗号化に使わず、復号化だけに使う。そういう運用をする。
AWSのKMSには、自動キーローテーション と手動キーローテーション の二つのモードがあります。
自動キーローテーションを有効にすると、AWSが勝手に1年ごと、つまり12ヶ月ごとに新しい鍵を作ってくれる。その鍵の材質、内部のマテリアルが新しくなる。ただし、鍵の識別子は変わりません。KMS側で管理してくれるんですよ。
対して、手動キーローテーションは、自分で新しいKMSキーを作成して、使い始める操作。これは、古い鍵をスケジュールして削除する際の「待機期間」をコントロールしたい時に使う。
ここで、重要な質問が出ます。「鍵をローテーションしたら、昔のデータはどうなるの？」
答えは、何ももならない。昔のデータはそのまま復号化できる。なぜなら、KMSはですね、「この鍵は、どのバージョンの鍵材で暗号化されたか」という情報を持ってるんですよ。新しいバージョンが出ても、古いバージョンの鍵材も保持している。だから、復号化する時に「あ、このデータは鍵バージョン2で暗号化されてるな」と認識して、正しく復号化できるわけです。
このことを理解してると、キーローテーションは怖くなくなるんですよ。古いデータが急に読めなくなるわけじゃない。ただ、セキュリティ的には、新しい鍵で新規データを暗号化してく。それだけ。
試験では「キーローテーション後、古いデータにアクセスできなくなるか」みたいな問題が出ます。答え、できる。マスターキーは複数のバージョンを持ってるから。ここ、試験でよく出ます。
マルチリージョンキー — プライマリとレプリカの独立性
さて、ここからは、グローバルなアーキテクチャを考える話です。
皆さんは、AWSのデータセンターが世界中にあることはご存知ですね。例えば、東京リージョン、シンガポールリージョン、N.バージニアリージョンとか。
通常のKMSキーは、その作成したリージョンにだけ存在します。つまり、東京リージョンで作ったKMSキーは、東京リージョンでしか使えない。
でも、グローバルなアプリケーションの場合、複数リージョンにデータが分散してることがあります。例えば、ユーザーのプライベートデータが、複数の地域に複製されてるみたいな場合。
「あ、じゃあ各リージョンで別々のKMSキーを作ればいいじゃん」って思いますよね。確かに、それでも動きます。でも、鍵の管理が複雑になる。各リージョンの鍵を個別に回転させたり、アクセス権限を設定したり。それが手間なんですよ。
そこで登場するのが、マルチリージョンキー という概念です。マルチリージョンキーってのはですね、一つの「親キー」を作って、それを複数のリージョンに複製する、という仕組みなんですよ。
具体的には、プライマリリージョン、例えば東京で、マルチリージョンキーを作成します。そのキーをシンガポール、N.バージニアなどにもレプリケートします。各リージョンに、そのキーのレプリカキー が作られます。
ここで大事な特性があります。レプリカキーはですね、それぞれ独立して機能するんですよ。つまり、シンガポールのレプリカキーでEncryptされたデータは、東京のプライマリキーで、そのまま復号化できる。逆も同じ。鍵の識別子は同じだから、KMS側で「あ、このデータはマルチリージョンキーで暗号化されてるな」と認識して、自動的に正しい方の鍵で復号化する。
で、さらに、各リージョンのレプリカキーは、そのリージョンでスタンドアロンに使用できるんですよ。プライマリが壊れても、レプリカは動く。これ、災害対策的に強い。
もちろん、キーローテーションをやる場合は、プライマリで実行すると、全レプリカに反映される。鍵ポリシーの更新も同じ。一度の操作で全リージョンに反映される。効率的ですね。
試験では「マルチリージョンキーのレプリカは、プライマリなしで使えるか」みたいな問題が来ます。答え、使える。レプリカは独立して機能する。
SSE-S3 vs SSE-KMS vs SSE-C — 「誰が鍵を持つか」で整理する
さあ、ここからはですね、S3の暗号化の話です。S3のオブジェクトって、保存される時に暗号化できるんですよ。その暗号化には、三つの方式があるんです。これ、よく混同される。
一つ一つ、整理していきましょう。
一つ目がSSE-S3、つまりServer-Side Encryption with S3-Managed Keys。これはですね、最もシンプルな方式。S3がね、暗号化用の鍵を全て管理してくれるんですよ。ユーザーは何もしない。オブジェクトをアップロードするだけで、S3が自動的に暗号化してくれます。
メリットは設定が簡単で、コストがかかりません。デメリットは鍵の管理を自分でコントロールできない。キーローテーションのタイミングも、ポリシーもAWSに任せっきり。
どういう場面で使うか。「ちょっと暗号化しときたいけど、細かい管理は不要」みたいな場合。例えば、ログデータとか。機密度が低い場合ですね。
二つ目がSSE-KMS、つまりServer-Side Encryption with KMS-Managed Keys。これはですね、さっき学んだKMSを使う方式。S3が、KMSの鍵を使ってオブジェクトを暗号化する。
鍵の管理は、KMSが担当。つまり、キーローテーション、アクセス権限の設定、全部をKMSで制御できる。
メリットは鍵管理が細かくできて、監査ログ、つまりCloudTrailに詳細が記録される。複数のバケット間で同じマスターキーを使い回せる。デメリットはSSE-S3より少し複雑で、KMS APIの呼び出し数によって、料金が増える可能性がある。
どういう場面で使うか。本番のデータ。顧客情報、財務データとか。機密度が高い、かつ監査対応が必要な場合。
ここで一つ、重要なポイント。SSE-KMSを使う場合、S3がオブジェクトを暗号化・復号化するときに、KMS APIを呼びます。だから、S3のサービスロールには、kms:Decrypt、kms:GenerateDataKeyの権限が必要なんですよ。これ、よく見落とされます。試験で引っかかる人が多い。
三つ目がSSE-C、つまりServer-Side Encryption with Customer-Provided Keys。これはですね、ユーザー自身が鍵を用意して、それをHTTPリクエストで毎回渡す方式。
S3は、その鍵を一時的に使って暗号化して、リクエストが終わったら鍵を破棄します。S3側には鍵が保存されない。
メリットは鍵の完全なコントロール。AWSに鍵を知られたくない場合に使える。デメリットは自分で鍵を管理しなきゃいけない。つまり、バックアップ、ローテーション、セキュリティ、全部自分の責任。S3の管理画面からは見られないから、監査も手作業。
どういう場面で使うか。「鍵を絶対にAWSに知られたくない」という、非常にハイセキュリティな環境。例えば、政府機関とか、規制が厳しい業界とか。そういった限られた場面ですね。
さあ、このときに、最初の質問に戻ります。「誰が鍵を持つか」。これで、三つの方式が完全に整理されるんですよ。
SSE-S3はAWSが全部持ってる。SSE-KMSはAWSが持ってるけど、ユーザーが権限制御できる。SSE-Cはユーザーが自分で持ってる。
この整理で、試験問題も怖くなくなるんですよ。「この場合、どの暗号化方式を使うべきか」という問題が来たら、「鍵の管理をどこまでコントロールする必要があるか」で答えが決まるんです。
CloudHSM との違い — 「マンション vs 一戸建て」の比喩
さあ、KMSを理解したところで、似ているけど全然違うサービスが出てきます。CloudHSM です。
HSMって聞いたことあります。Hardware Security Module。つまり、ハードウェアレベルのセキュリティモジュール。KMSとCloudHSMって、どちらも鍵を管理するサービスなんですよ。だから、「あ、同じようなもんでしょ」と思う人が多い。でも、実は、全然違う。
比喩で説明すると、こんな感じですね。KMSはマンションの中の鍵付きロッカー。AWSが建物も管理してくれて、ロッカーも管理してくれる。セキュリティもAWSに任せっきり。かわりに、多機能。キーローテーション自動で、監査ログ完備で、複数ユーザーのアクセス制御も楽。
CloudHSMは自分で建てた一戸建ての金庫。HSMハードウェアはあなた専用。他の人と共有しない。セキュリティ設定も、全部自分で決める。かわりに、責任も全部自分。故障したら自分で対応。鍵管理も自分でプログラム。
つまりですね、KMSは「AWSが提供するマネージドサービス」。CloudHSMは「AWSが提供するハードウェアだけど、運用は自分でやるサービス」という位置付けなんですよ。
KMSが向いてる場面は「暗号化のベストプラクティスに従いたいけど、運用負荷は減らしたい」という普通の企業。CloudHSMが向いてる場面は「鍵の管理を絶対に自分でしたい」「AWSの多人数共有環境は嫌」という、超高度なセキュリティ要件がある場合。例えば、金融機関とか、機密防衛産業とか。
試験では「KMSで十分か、CloudHSMが必要か」という判断問題が出ます。大抵の場合、答えはKMSです。なぜなら、CloudHSMを使う場面は本当に限られてるから。
よくある間違い — 実務で陥りやすいワナ
最後に、これは本当に大事なので、ちゃんと聞いてください。試験に出るパターンだけじゃなくて、実務で実際に起こる間違いです。
間違い一つ目が「IAMポリシーだけでKMS操作ができる」と思い込む。これ、さっき説明しましたね。IAMポリシーにkms:Decryptを入れても、キーポリシーに権限がなかったら、動かないんですよ。多くのチームは、IAMの部分だけを確認して、「あれ、動かない」ってなる。デバッグに1時間費やす。
対策はKMSの鍵を操作するときは、必ず「IAMとキーポリシーの両方を確認する」という習慣をつける。これ、本当に大事。
間違い二つ目が削除したKMSキーは二度と取り戻せない、という認識不足。KMSキーには、削除を申し込むと、「待機期間」、デフォルトは30日が入ります。その期間は、キーは削除されず、ただ無効になるだけ。でも、多くの人は「あ、削除申し込んだ。でも、やっぱり必要だ」って気づいて、対応するんですよ。待機期間中なら、キャンセルできる。
問題は、待機期間が終わったら、もう取り戻せないということ。KMSキーで暗号化されたデータがあったら、そのキーなしでは永遠に復号化できない。つまり、データは失われたと同じなんですよ。
対策は本番環境のKMSキーは、削除申し込みする前に、最低でも三重で確認する。担当者の確認、マネージャーの確認、データセキュリティチームの確認とか。それくらいの慎重さが必要。
間違い三つ目がキーポリシーをIAMポリシーと混同して、複雑にしてしまう。キーポリシーとIAMポリシーは、別もの。でも、似てるから、初心者は「あ、IAMポリシーの書き方でいいんでしょ」と思い込んで、キーポリシーに複雑なConditionsを書いたりする。でも、キーポリシーは、「このプリンシパルは、このアクションをできるか、できないか」という、わりとシンプルな制御に向いてるんですよ。複雑な条件付け、時間帯とか、IP範囲とかは、IAMポリシー側でやった方がいい。
対策はキーポリシーはシンプルに。複雑な条件制御はIAMポリシー側で。役割分担を明確にする。
まとめ — KMSの本質
KMSについて、一通り学びました。結局のところ、KMSは何なのか。それは、「データを守る鍵そのものを、さらに堅牢に守るための仕組み」なんですよ。
エンベロープ暗号化で、鍵を階層化する。キーポリシーで、権限を二重に制御する。グラントで、一時的な権限を委譲する。キーローテーションで、セキュリティを常に更新する。マルチリージョンキーで、グローバルにスケールさせる。
そして、S3との組み合わせの使い分け方、CloudHSMとの違いまで理解すれば、完璧です。
試験では、これらの知識が、個別の問題として出てきます。「この場面で、何をすべきか」という判断を求められる。でも、今日学んだ全体像があれば、その判断は自然と出てくるんですよ。
最後に、一つだけ。セキュリティは「完璧」を求めるものではなく、「誠実に、段階的に」整備していくものです。KMSも、完璧な設定を最初から求めず、まずはSSE-KMSで基本をおさえて、必要に応じてキーポリシーを厳密にしていく。そういう進め方が、実務的で、かつ持続可能です。
皆さんが本番環境でKMSを触る時は、今日のこのイメージを思い出してくださいね。では、次の講義へ進みましょう。次はCloudTrailです。「誰が何をしたか」を絶対に逃さないための仕組みを、一緒に学びます。