AWS CLF(Cloud Practitioner)対策
暗号化とKMS
このレッスンを終えると、保管時の暗号化と転送時の暗号化を区別して説明でき、AWS Key Management Service（通称 KMS）と AWS Certificate Manager（通称 ACM）のどちらを選ぶべきかを判断できるようになります。
自分でサーバーを1台建てるなら
自前のサーバーで暗号化に取り組んだとき、話は2か所に分かれたはずです。ひとつはディスクの中身で、LUKS でボリュームを暗号化したり、バックアップファイルを暗号化して外部に置いたりしました。もうひとつは通信で、Let's Encrypt などで証明書を取り、HTTP を HTTPS にしました。そしてどちらの場合も、いちばん面倒だったのは暗号そのものではなく鍵と証明書の管理です。鍵をどこに置くか、誰が触れるか、いつ入れ替えるか、失効したらどうするか。AWS はこの面倒な部分を引き取るサービスを用意しています。
保管時と転送時
暗号化は状態で2つに分けて考えます。
| 種類 | 対象 | AWS での例 |
|---|---|---|
| 保管時の暗号化 | ディスクやオブジェクトに置かれた静止したデータ | S3 のサーバー側暗号化、Amazon Elastic Block Store（EBS）ボリュームの暗号化、RDS の暗号化 |
| 転送時の暗号化 | ネットワークを流れているデータ | HTTPS（TLS）、VPN、AWS Direct Connect と組み合わせた暗号化 |
覚え方は「止まっているデータ」と「動いているデータ」です。試験の英語表現をそのまま日本語にした「保存されているデータ」「転送中のデータ」という言い回しでも出ます。
KMS の役割
KMS は暗号鍵を作り、保管し、使用を許可し、監査するためのサービスです。実際にデータを暗号化するのは各サービス（S3 や EBS や RDS）で、KMS はその鍵を預かる金庫の役割を担います。
押さえどころは次のとおりです。
- 鍵は KMS の外に出ない。利用者は「この鍵で暗号化して」と頼むだけで、鍵の中身を取り出す運用にはならない
- 誰がどの鍵を使えるかは IAM のポリシーと鍵ポリシーで制御する
- 鍵の自動ローテーションを設定できる
- 鍵の使用は CloudTrail に記録されるので、いつ誰が使ったかを追える
- 多くのサービスで「暗号化を有効にする」チェックひとつで S3 や EBS と連携する
より厳しい規制で、専用のハードウェアで鍵を単独管理したい場合には AWS CloudHSM という選択肢もあります。CLF では「専用ハードウェアが要件に明記されていれば CloudHSM、通常は KMS」という粒度で十分です。
証明書は ACM
転送時の暗号化に使う TLS 証明書は、KMS ではなく AWS Certificate Manager が扱います。パブリック証明書の発行と更新を自動化でき、Elastic Load Balancing や Amazon CloudFront に紐づけて使います。「証明書の更新を忘れてサイトが落ちた」という古典的な事故を、自動更新で防ぐのが主な価値です。
試験ではこう出る
- 「暗号鍵を作成・管理し、その利用を監査したい」→ KMS
- 「Web サイトを HTTPS にしたい。証明書の更新を自動化したい」→ ACM。KMS を選ばせる引っ掛けが定番です
- 「保管時の暗号化」「保存データの暗号化」という語が出たら S3・EBS・RDS の暗号化と KMS の話
- 「転送中のデータの保護」という語が出たら TLS や VPN の話
- 「規制で専用ハードウェアの鍵管理が必要」→ CloudHSM
- 「暗号化の有無を決めるのは誰か」→ 責任共有モデルどおり利用者。仕組みを提供するのが AWS
- 「シークレットやデータベースのパスワードを安全に保管して自動更新したい」→ 鍵ではなく AWS Secrets Manager
まとめ
- 暗号化は保管時（止まっているデータ）と転送時（動いているデータ）に分けて考える
- KMS は鍵の作成・保管・利用制御・監査を担い、暗号化そのものは各サービスが行う
- TLS 証明書は ACM が扱い、更新を自動化できる
- 専用ハードウェアが要件なら CloudHSM、資格情報の保管なら Secrets Manager
- 暗号化するかどうかを決める責任は利用者側にある
復習ミニクイズ
自社の Web サイトを HTTPS で公開し、TLS 証明書の更新作業を自動化したいと考えています。最も適切な AWS サービスはどれですか。