AWS SAA(Solutions Architect - Associate)対策
KMSとSecrets Manager
このレッスンを終えると、暗号化まわりの要件文を読んで、KMS の話なのか Secrets Manager の話なのか、それとも Parameter Store で足りるのかを切り分けられるようになります。
まず要件から
ある企業が、EC2 上のアプリから RDS に接続しています。監査で次の3点を指摘されました。ひとつめは DB のパスワードがアプリの設定ファイルに書かれていること。ふたつめはそのパスワードが3年間変わっていないこと。みっつめは S3 に置いた個人情報が、鍵の管理主体を説明できない形で暗号化されていることです。
3つとも「暗号化」の話に見えますが、対応するサービスは別です。鍵そのものを預かるのが KMS、秘密の値を預かって自動で入れ替えるのが Secrets Manager、そして値を預かるだけで入れ替えは自前なら Parameter Store です。
3つの線引き
| AWS KMS | Secrets Manager | Systems Manager Parameter Store | |
|---|---|---|---|
| 預けるもの | 暗号鍵 | パスワード、API キーなどの秘密の値 | 設定値。SecureString なら秘密の値も |
| 値の自動ローテーション | 対象外(鍵の自動ローテーションはある) | あり。Lambda が入れ替える | 無い。自前で更新する |
| RDS などとの連携 | 保存時の暗号化に使う | 対応 DB のパスワードを丸ごと管理できる | 参照はできるが入れ替えは自分で組む |
| 追加料金 | 鍵と API 呼び出しに課金 | 秘密ごとに課金され、3者では最も高い | 標準パラメータは追加料金が発生しない |
| 向いている要件 | 鍵の管理主体と監査を説明したい | パスワードを定期的に自動で変えたい | 環境変数や設定値を一元管理したい |
先ほどの要件に当てはめます。設定ファイルのパスワードは Secrets Manager に移し、3年変わっていない点は自動ローテーションで解きます。S3 の個人情報は、暗号化の方式を KMS を使う形にして、鍵の作成者と利用履歴を説明できるようにします。
KMS のどこが問われるか
試験で問われるのは鍵の主体です。AWS マネージドキーはローテーションも管理も AWS 側で完結し、ポリシーを細かく書けません。カスタマーマネージドキーは自分で作り、キーポリシーで利用者を絞り、削除や無効化も自分で決められます。「特定のチームだけが復号できるようにしたい」「鍵を無効化して即座にデータを読めなくしたい」「別アカウントと鍵を共有したい」といった要件が出たらカスタマーマネージドキーです。
さらに厳しい要件として「鍵を専有のハードウェアで保持したい」「規制でシングルテナントの HSM が必要」と書かれていれば CloudHSM を指します。ここまで書かれていない限り CloudHSM は選びません。運用負荷が重く、要件語が無いのに選ぶと過剰設計になるからです。
Secrets Manager のどこが問われるか
決め手は自動ローテーションの一語です。要件文に「定期的にパスワードを変更する」「変更をアプリ改修なしで行う」とあれば Secrets Manager です。対応するデータベースならローテーション用の仕組みが用意されており、アプリ側は毎回 Secrets Manager から取得する形に変えるだけで済みます。
逆に、値を安全に置きたいだけで入れ替えの要件が無く、しかも「コストを抑えたい」と添えられていれば Parameter Store の SecureString です。SecureString も KMS で暗号化されるので、暗号化の要件は満たせます。
要件語から構成へ
| 要件文の言い回し | 選ぶもの |
|---|---|
| DB のパスワードを定期的に自動で入れ替えたい | Secrets Manager |
| 秘密の値を安全に保管したい。コストは最小に | Parameter Store の SecureString |
| 鍵の作成と利用を自分で統制し監査したい | KMS のカスタマーマネージドキー |
| 特定の鍵を無効化して即座に読めなくしたい | KMS のカスタマーマネージドキー |
| 専有 HSM が規制で要求されている | CloudHSM |
| S3 の暗号化を追加設定なしで有効にしたい | S3 のマネージドキーによる暗号化 |
よくある引っ掛け
ひとつめは、パスワードの自動ローテーション要件に対して Parameter Store を選ぶ誤答です。SecureString で暗号化はできますが、値を入れ替える仕組みは付いてきません。
ふたつめは、単に「安全に保管したい」だけの要件に Secrets Manager を選ぶ誤答です。動きますが、コスト最小の要件語が添えられていれば Parameter Store に負けます。
まとめ
- 鍵は KMS、秘密の値とその自動入れ替えは Secrets Manager、値の保管だけなら Parameter Store
- 「自動ローテーション」の一語が出たら Secrets Manager
- 鍵の統制や無効化の要件はカスタマーマネージドキー。要件語が無ければ CloudHSM を選ばない
- コスト最小の要件語が付くと、Secrets Manager より Parameter Store が優先されることがある
復習ミニクイズ
ある企業が、EC2 上のアプリケーションから Amazon RDS for MySQL に接続しています。監査要件により、データベースの認証情報を 30 日ごとに変更し、その作業を運用担当者の手作業なしで行う必要があります。アプリケーションのコードは変更できますが、接続断は最小にしたいと考えています。最も運用の手間が少ない構成はどれですか。