はじめる前に
- 必須AWS アカウントを持っていること
- 必須マネジメントコンソールにサインインできること
- あると良い「パスワードをコードに書くと危ない」という感覚
- あると良いIAM ロールという言葉を聞いたことがある
※ コマンドラインや SSH などの操作は一切ありません。すべてブラウザのコンソール上で完結します。
参照する公式ドキュメント
手順に迷ったときや、用語の意味を確かめたいときに開きましょう。
※ リンク切れの場合は、ページタイトルで検索してください。
背景・シナリオ
データベースのパスワードなどをプログラムのコードや設定ファイルに直接書いてしまうと、そのコードを誰かに見られたときに、パスワードがそのまま漏えいしてしまいます。バージョン管理に誤ってコミットしてしまい、後から削除しても履歴に残ってしまう、といった事故も起こりがちです。
Secrets Manager は、こうした機密情報を暗号化して保管し、必要なときだけ取得できるようにするサービスです。今回はデータベース認証情報を模したシークレットを1つ保存し、取得する一連の流れを体感します。
Parameter Store の SecureString と何が違うの？
どちらも暗号化して保存できる点は似ていますが、Secrets Manager は自動ローテーション（定期的なパスワードの自動更新）など、シークレット運用に特化した機能を持ちます。一方で料金は Secrets Manager の方が高めです。今回はローテーションまでは設定せず、保存と取得の基本だけを扱います。
保存したシークレットの値は誰でも見られるの？
いいえ。IAM の権限で「誰がこのシークレットを取得できるか」を制限できます。自分のアカウントで操作していると意識しにくいですが、実務では必要な人・サービスだけに権限を絞ることが重要です。
データベース認証情報を模したシークレットを1つ作成し、コンソールから「シークレット値を取得」して、キーと値のペアが正しく保存・取得できることを確認する。
つくる構成
Secrets Manager でシークレットを保存する際は、いくつかの「シークレットのタイプ」から選びます。今回扱う2つを比較してみましょう。
シークレットのタイプ
その他のシークレットのタイプ
任意のキー/値のペアを保存できる。
Amazon RDS のデータベースの認証情報
RDS インスタンスと連携する場合に使う。
要件
以下の要件を満たし、シークレットの保存と取得ができることを確認してください。
| No | 要件 |
|---|---|
| 1 | リージョンは「東京（ap-northeast-1）」を使用する。 |
| 2 | シークレットのタイプは「その他のシークレットのタイプ」を選び、キー/値のペア（例：username = appuser、password = 自由な文字列）を入力して、シークレットを1つ作成する（名前は自由、例：demo-db-credentials）。 |
| 3 | ローテーションは設定しない。「自動ローテーションを無効にする」のまま進める。 |
| 4 | 作成したシークレットの詳細から「シークレット値を取得」し、保存したキー/値が正しく表示されることを確認する。 |
構築の進め方
「シークレットを作る → キー/値を入れる → ローテーションは設定しない → 取得して確かめる」という、シンプルな順番で進みます。
-
マネジメントコンソールにサインインし、リージョンを合わせる
ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。
-
Secrets Manager コンソールでシークレットのタイプを選ぶ
画面上部の検索バーに
Secrets Managerと入力してコンソールを開き、「新しいシークレットを保存する」をクリックします。シークレットのタイプは「その他のシークレットのタイプ」を選びます。シークレットのタイプ
その他のシークレットのタイプ
任意のキー/値のペアを保存できる。
Amazon RDS のデータベースの認証情報
RDS インスタンスと連携する場合に使う。
今回は RDS を使わないRDS インスタンスと連携するタイプもありますが、今回はデータベースそのものは作成しません。任意のキー/値を保存できる「その他のシークレットのタイプ」を選びましょう。
-
キー/値のペアを入力し、シークレット名を付ける
キー/値のペアを入力します（例：
username=appuser、password= 自由な文字列）。続けてシークレット名を付けます（名前は自由、例：demo-db-credentials）。 -
ローテーションの設定画面はそのまま進める
ローテーションの設定画面が表示されますが、「自動ローテーションを無効にする」のまま、設定を変えずに進めてシークレットを作成します。
ローテーションは今回のスコープ外自動ローテーションには Lambda 関数などの追加設定が必要です。今回は保存と取得の基本を体感することが目的のため、ここでは有効化しません。
-
シークレット値を取得して確認する
作成したシークレットの詳細画面を開き、「シークレット値を取得」をクリックします。手順3で入力したキー/値のペアが、そのまま表示されることを確認しましょう。
つまずきポイント
初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。
「取得ボタンが見当たらない、または値が表示されない」
シークレットの詳細画面の中に「シークレット値を取得」というセクションがあります。一覧画面ではなく、シークレットの名前をクリックして詳細画面に入った先を確認してみましょう。
「複数のキー/値のペアを入れたら、どれがどれか分かりにくい」
複数のキー/値のペアを入れた場合、画面上ではキーと値が並んで表示されます。入力したときの画面と、取得したときの画面を見比べて、それぞれのキーにどの値が対応しているかを確認してみましょう。
完了チェック
要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。Secrets Manager コンソールを開いて、次を順に確かめましょう。
- シークレットの一覧に、自分が作成したシークレット（例：
demo-db-credentials）が表示されている。 - そのシークレットの詳細画面で「シークレット値を取得」を開くと、
usernameやpasswordの値が確認できる。 - ローテーションの設定が「無効」になっていることが、詳細画面で確認できる。
- シークレットの作成日時が、詳細画面で確認できる。
考えてみよう
手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。
- パスワードをコードに直接書く方法と比べて、Secrets Manager を使う方法はどんな場面で特に効果を発揮するでしょうか。
ヒント
コードを複数人で共有する場面や、コードをバージョン管理に保存する場面を考えてみましょう。コードと機密情報を分離しておくことで、コードを見られても困らない、という状態をつくれます。 - 今回はローテーションを設定しませんでしたが、自動ローテーションを有効にするとパスワードの運用はどう変わりそうでしょうか。
ヒント
人が定期的にパスワードを変更してまわる作業がなくなり、決まった周期で自動的に新しいパスワードに切り替わるようになります。その分、ローテーションの仕組み（Lambda 関数など）自体の正しさを保証する必要が出てくる、という点も考えてみましょう。 - IAM ロールを使って EC2 や Lambda にこのシークレットを取得する権限だけを渡す場合、何を許可し、何を許可しないようにすべきでしょうか。
ヒント
「シークレットの値を取得する」操作だけを許可し、「シークレットを削除する」「他のシークレットも取得できる」といった、必要以上に広い権限を与えないことが大切です。対象のシークレットを名前やリソースで絞り込めるかどうかも考えてみましょう。
後片づけ
確認用に作成したシークレットを削除します。
- 作成したシークレットを削除する：Secrets Manager コンソールのシークレット一覧から、作成したシークレット（手順3で付けた名前、例：
demo-db-credentials）を選び、削除する。 - 復元可能な猶予期間があることを確認する：シークレットは即時削除ではなく、デフォルトで一定期間（猶予期間）はまだ完全には消えず、その間は復元も可能な状態になります。すぐに見えなくなるわけではない点を覚えておきましょう。
削除するのは、このハンズオンで自分が作ったものだけ
シークレットの一覧には、すでに他の用途で使っているシークレットも並んでいるかもしれません。間違えて削除しないよう、このハンズオンのために付けた名前のものだけを選んで削除してください。
コストに関する注意: Secrets Manager は、保存しているシークレットの数とAPI 呼び出し回数に応じて料金が発生します（無料利用枠はありません）。今回のように学習目的で短時間使う程度であれば少額ですが、シークレットを保存したまま放置すると、その分の料金が継続して発生する点に注意してください。後片づけの手順で必ず削除しましょう。