導入
「データを暗号化しましょう」とはよく言われますが、暗号化には”保存されているとき”と”通信しているとき”の2つの場面があり、それぞれ守り方のサービスが違います。
説明
データの暗号化には、次の2つの観点があります。
- 保管時の暗号化（Encryption at Rest） … ディスクやデータベースに保存されているデータを暗号化する。ディスクを物理的に抜き取られても中身が読めないようにする。
- 転送時の暗号化（Encryption in Transit） … ネットワークを通信中のデータを暗号化する。代表的な方式はTLS/SSL。通信を盗聴されても内容が読めないようにする。
暗号化・鍵管理まわりの主要サービスは次の通りです。
| サービス | 役割 |
|---|---|
| AWS KMS（Key Management Service） | データを暗号化・復号するための鍵を作成・管理するサービス。S3やEBS、RDSなど多くのサービスと統合されている |
| AWS CloudHSM | 専用の物理的なハードウェア（HSM）で鍵を管理するサービス。より厳格な規制要件（鍵を専有ハードウェアで管理したい場合など）に対応 |
| AWS Secrets Manager | データベースのパスワードやAPIキーなどの機密情報を安全に保管し、自動でローテーション（定期的な更新）もできるサービス |
| AWS Certificate Manager（ACM） | Webサイトの通信を暗号化するSSL/TLS証明書を作成・管理し、自動更新するサービス |
flowchart LR
D["平文データ"] -->|KMSの鍵で暗号化| S["S3 / EBS / RDSに保存"]
C["クライアント"] -->|TLSで暗号化された通信| A["AWSのサービス"]
App["アプリのコード"] -.パスワードを直書きしない.-> SM["Secrets Manager"]
SM -->|安全に取得・自動ローテーション| App
KMSとCloudHSMの違いは頻出です。KMSはAWSが鍵をマネージド（共有基盤）で管理するのに対し、CloudHSMは利用者専用の物理ハードウェアで鍵を管理します。ほとんどの用途はKMSで十分ですが、規制上「専有ハードウェアが必須」という場合にCloudHSMを選びます。
具体例
医療系スタートアップが、患者データを扱うWebサービスを作るとします。1つのサービスの中で、暗号化の各サービスがきれいに役割分担します。
- 保管時の暗号化 → KMS … 患者データを入れるS3バケットとRDSを、KMSの鍵で暗号化。万一ディスクを物理的に抜き取られても、鍵がなければ中身は読めない。
- 転送時の暗号化 → ACM … ブラウザとサーバー間の通信をHTTPS化するため、ACMで無料のSSL/TLS証明書を発行し、自動更新も任せる。通信を盗聴されても内容は読めない。
- DBパスワードの管理 → Secrets Manager … データベースの接続パスワードをコードに直書きせず、Secrets Managerに保管。しかも30日ごとに自動でローテーションされ、漏洩リスクを下げる。
- もし規制が厳しければ → CloudHSM … 「鍵は他社と共有基盤でなく専有ハードウェアで管理すること」という規制があるなら、KMSの代わりにCloudHSMを選ぶ。
「保存＝KMS、通信＝ACM、パスワード＝Secrets Manager、専有ハードが必須＝CloudHSM」——場面ごとの担当が、この1サービスの中で全部見えます。
読んでみよう
「鍵の管理＝KMS（専有HWならCloudHSM）」「パスワード等の機密情報＝Secrets Manager」「証明書＝ACM」という役割分担を混同しないようにしましょう。