AWS 20：秘密の管理 ― Secrets Manager と KMS

コードに書いた秘密は、消しても消えない

「後で気づいたら、コードから消せばいい」と思うかもしれません。ところが、そうはいきません。

Git は、過去のすべての版を残す道具です（第18章）。図のように、2つ目の版で秘密を書き、4つ目の版で消したとしても、2つ目の版にさかのぼれば、秘密はそのまま読めます。

GitHub などには、秘密らしい文字列が入るのを見つけて止める機能（シークレットスキャン）もあります。便利な安全網ですが、根本の解決はそもそもコードに秘密を書かないことです。

秘密は金庫にしまい、コードには「金庫の名前」だけ書く

解決の考え方はシンプルです。パスワードそのものは AWS の金庫にしまい、コードには「金庫のどの引き出しか」という名前だけを書く。

図では、EC2 と RDS の間に Secrets Manager（シークレッツマネージャー）という金庫が置かれています。設定ファイルに書いてあるのは photolog/prod/db という名前だけです。

EC2 には、第9章から IAM ロールを付けてきました。このロールに「photolog/prod/db を読んでよい」という許可を1つ足します。すると、そのロールを持つ EC2 だけが金庫から秘密を取り出せます。人がパスワードを知る必要はありません。

さらに、金庫から秘密を取り出すたびに、誰がいつ読んだかが記録されます（第27章で扱う CloudTrail）。「漏れたかどうかわからない」がなくなります。

取り出しの流れ：ロールで金庫を開けて、DB に入る

アプリが DB に接続するまでの流れを、図の番号の順に追います。

この流れで大事なのは、パスワードがどこのファイルにも書かれていないことです。パスワードはアプリのメモリの中にだけ、少しのあいだ存在します。

第19章の OIDC と同じ考え方であることに気づいたでしょうか。「長く生きる秘密をあちこちに置く」のではなく、「身元（ロール）を確かめて、そのとき必要なものを渡す」。AWS で安全に作るときの、何度も出てくる型です。

金庫は2つ：Parameter Store と Secrets Manager

AWS には、値をしまっておく場所が主に2つあります。

使い分けの目安はこうです。

Parameter Store：名前を階層にして値を置く

Parameter Store では、値に /photolog/prod/db/host のような、フォルダのように区切った名前を付けられます。

こうしておくと、IAM の許可を「/photolog/prod/* だけ読んでよい」と書けます。本番の EC2 は本番の値だけ、試験環境の EC2 は試験の値だけを読めるようになり、取り違えや読みすぎを防げます。

値の種類は3つです。

図の下のコマンドは、SecureString の値を取り出す例です。--with-decryption を付けると、暗号化を解いた値が返ります（解く権限が必要です）。

アプリから読む場合も、コマンドと同じ操作を SDK（プログラムから AWS を使うための部品）で行います。

Secrets Manager：秘密を JSON で置き、RDS と組む

Secrets Manager では、1つの秘密の中に、ユーザー名・パスワード・接続先などを JSON（第3章）でまとめて置くのが一般的です。図の左が、フォトログの DB の秘密の例です。

Secrets Manager のいちばんの強みは、RDS との連携です。RDS を作るときに「管理者のパスワードを Secrets Manager で管理する」を選ぶと、次のことを RDS がやってくれます。

つまり、誰もパスワードを知らない状態を作れます。知らないものは、漏らしようがありません。

アプリ用のユーザー（図の photolog_app）のように、管理者以外の DB ユーザーの秘密も、Secrets Manager に置いてローテーションを設定できます。アプリは管理者ではなく、必要な権限だけを持つアプリ用のユーザーで接続するのが基本です（最小権限、第3章）。

ローテーション：パスワードを定期的に入れ替える

ローテーションは、パスワードを定期的に新しいものへ入れ替えることです。

なぜ入れ替えるのでしょうか。どれだけ気をつけても、秘密が漏れる可能性はゼロになりません。しかし定期的に入れ替えていれば、漏れた値は、次の入れ替えで使えなくなります。漏れたことに気づかなくても、被害の期間を区切れます。

Secrets Manager のローテーションは、図の4段で進みます。

この4段を実際に行うのは Lambda（第22章で詳しく扱う、小さなプログラムを動かすサービス）の関数です。RDS などの代表的な DB 向けには、AWS が用意した関数を使えます。RDS が管理するパスワードなら、この仕組みごと AWS が面倒を見ます。

入れ替えの瞬間に接続が切れないように、古い値も「前の値（AWSPREVIOUS）」として少しのあいだ残ります。また、DB のユーザーを2人用意して交互に入れ替える方式もあります。

アプリ側で気をつけるのは、起動時に1回だけ読んで、ずっと持ち続けないことです。次のページで読み方を見ます。

アプリから読む：毎回ではなく、少しのあいだ覚えておく

図は、フォトログのアプリ（Node.js）が Secrets Manager から DB の秘密を読むコードです。

なぜ「5分覚えておく」のでしょうか。

さらに、「DB への接続がパスワードの誤りで失敗したら、覚えている値を捨てて読み直す」ようにしておくと、ローテーションの直後でも自然に新しい値へ移れます。

AWS は、このキャッシュを自分で書かずに済むように、キャッシュ付きの読み取りライブラリや、サーバーの中で動かす Secrets Manager Agent も用意しています。

もう1つの守り：暗号化（保存時と通信時）

ここからは、秘密の置き場所から少し視野を広げて、データそのものを守る暗号化の話をします。

暗号化は、データを、鍵が無いと読めない形に変えることです。鍵を持つ人だけが元の形に戻せます（復号）。暗号化には、守る場面によって2種類あります。

通信時の暗号化が無いと、途中の回線でデータを覗かれるおそれがあります。保存時の暗号化が無いと、ディスクやバックアップのファイルが何らかの形で持ち出されたときに、中身をそのまま読まれます。

どちらも「設定したつもり」になりやすいので、次の2ページで、どの区間・どの部品で何をするかを1つずつ確かめます。

通信時の暗号化：どの区間も TLS で包む

通信時の暗号化には TLS を使います。TLS は、第14章の HTTPS の「S」の部分、つまり通信を暗号化する仕組みです。フォトログの通信を区間ごとに見ます。

図の下は、RDS for PostgreSQL で TLS 以外の接続を断る設定です。パラメータグループ（DB の設定をまとめたもの、第13章）で rds.force_ssl を 1 にします。MySQL など他の DB エンジンにも、同じ目的の設定があります。

「VPC の中だから安全」と考えて、中の区間を暗号化しないこともよくあります。それが許されるかは、扱うデータと、守るべき決まり（個人情報の扱い、業界の基準など）で決まります。迷ったら暗号化しておくのが安全です。

保存時の暗号化：S3・EBS・RDS それぞれの決まり

保存時の暗号化は、部品ごとに「既定でどうなっているか」「いつ設定できるか」が違います。ここを知らないと事故になります。

図の下の3つの印のとおり、暗号化は利用者から見るとほぼ透明です。

特に RDS は、最初に暗号化を選び忘れると、後で直すのに作り直しが必要です。第18章の IaC のコードで、暗号化を最初から書いておくのが確実です。

KMS：鍵の金庫。鍵は金庫の外に出ない

暗号化には鍵が必要です。では、その鍵はどこに置けばよいのでしょうか。鍵をパスワードのようにファイルに書いたら、元の問題に戻ってしまいます。

そこで使うのが AWS KMS（Key Management Service）です。KMS は、暗号化の鍵を作り、専用の頑丈な機械の中で守るサービスです。

KMS のいちばんの特徴は、鍵（KMS キー）そのものは KMS の外に取り出せないことです。鍵を使いたいときは、「このデータを暗号化して」「これを元に戻して」と KMS に頼む形になります。図では、EBS・S3・Parameter Store が、それぞれ KMS に頼んでいます。

つまり、「データを読めるかどうか」を、鍵を使う権限で管理できるようになります。S3 のバケットを誤って読める設定にしてしまっても、鍵を使う権限が無ければ中身は読めません。守りが二重になります。

鍵の種類：AWS に任せるか、自分で管理するか

KMS の鍵には、管理のしかたで3つの種類があります。

何も指定しなければ、AWS 所有のキーか AWS マネージドキーが使われます。それでもデータは暗号化されています。

では、いつ自分の鍵（カスタマーマネージドキー）を作るのでしょうか。

フォトログでは、本番の RDS と S3 を自分の鍵で暗号化することにします。

エンベロープ暗号化：データの鍵を、KMS の鍵で包む

KMS には、1回に送って暗号化できるデータの大きさに上限があります（小さなものに限られます）。10MB の写真や、何百 GB のディスクを、まるごと KMS に送って暗号化するわけにはいきません。

そこで使われるのが エンベロープ暗号化（封筒の暗号化）です。図の番号の順に見ます。

読むときは逆です。包んだデータキーだけを KMS に送って開けてもらい（小さいので送れる）、手元でそのデータキーを使って写真を戻します。

S3・EBS・RDS の暗号化は、裏でこの仕組みを使っています。自分で意識することは少ないですが、「KMS の鍵を使えない人は、データを読めない」理由がここにあります。

フォトログの秘密と暗号化

この章の内容を、フォトログに当てはめて決めます。

CDK（第18章）を使っていれば、これらはほとんどコードに書けます。たとえば RDS を作るときに「パスワードは Secrets Manager で管理」「暗号化はこの鍵で」と書き、アプリのロールに secret.grantRead(role) のように読み取りだけを許す、といった形です。

お金：秘密の数・呼び出しの回数・鍵の数

この章の道具の料金は、次の単位で決まります。

単価と無料枠は、それぞれの料金ページで確認してください。

いちばん効く節約は、呼び出しを減らすことです。この章で見たキャッシュ（数分覚えておく）はその代表です。S3 でも、バケット単位のデータキーを使う設定（S3 バケットキー）で、KMS への呼び出しを大きく減らせます。

暗号化は保存料を増やさないので、「お金がかかるから暗号化しない」という理由はほとんどありません。

よくある落とし穴

秘密と暗号化でよくある事故を並べます。

特に怖いのが、KMS の鍵の削除です。鍵を消すと、その鍵で包んだデータキーが開けられなくなり、データは AWS にも戻せません。そのため KMS は、削除の操作の後に待ち期間を設けています（次のページ）。

片付け：秘密と鍵は、すぐには消えない

この章で作ったものを消すときは、順番と待ち期間に気をつけます。

待ち期間は、間違って消したときに取り消すための猶予です。待ち期間中の鍵は使えませんが、取り消せば元に戻ります。

順番は、データ → 秘密 → 鍵です。鍵を先に消してしまうと、残ったスナップショットやバックアップが、二度と読めなくなります。「もう要らないはず」のデータでも、読めなくなってから必要になることがあるので、この順番を守ってください。