第 3 章 セキュアなアーキテクチャの設計（30%）
データをどう守るか
この章で学ぶこと
- データへのアクセスとガバナンス
- データの復旧
- データの保持と分類
- 暗号化と適切なキー管理
この章に出てくる用語
- AWS KMS（Key Management Service）
- 暗号化の鍵を作って保管し、「この鍵で暗号化／復号してよいか」を判定するサービス。 鍵そのものは KMS の外に出ない。利用者は「このデータを暗号化して」と頼み、KMS は許可を確かめてから処理する。ほとんどの AWS サービス（S3・EBS・RDS・Lambda など）が KMS と繋がっていて、チェックを入れるだけで暗号化できる。
- AWS Certificate Manager（ACM）
- TLS 証明書を無料で発行し、期限が来たら自動で更新してくれるサービス。 発行した証明書は ALB・CloudFront・API Gateway などに付けて使う。パブリック証明書は書き出せない（EC2 に自分で入れることはできない）。EC2 に入れたいときは、プライベート CA を使うか、外部で買った証明書を取り込む。
- AWS Backup
- 複数のサービスのバックアップを 1 か所で計画・実行・保持するサービス。 EBS・RDS・DynamoDB・EFS・FSx・Storage Gateway などをまとめて扱える。バックアッププランに「毎日 2 時に取り、30 日保持、そのあと低温の保管へ」と書けば、サービスごとにスクリプトを書かなくてよくなる。ボールトロックを掛けると、保持期間中は誰も削除できなくなる。
データが危ないのは 2 つの状態のときだ。ディスクに置いてあるとき（保管時）と、線の上を流れているとき（転送時）。対策も分かれている。
| 保管時（at rest） | 転送時（in transit） | |
|---|---|---|
| 何から守るか | ディスクやスナップショットが流出したとき | 通信を盗み見られたとき |
| 使うもの | AWS KMS（鍵の管理） | TLS。証明書は ACM で用意する |
| 代表的な設定 | S3 の暗号化、EBS の暗号化、RDS の暗号化 | HTTPS、クライアントとの通信、AWS サービス間 |
| あとから有効にできるか | サービスによる（EBS や RDS は作り直しが要る） | できる |
試験では
EBS ボリュームと RDS インスタンスは、作ったあとから暗号化を有効にできない。スナップショットを取り、暗号化を有効にして復元する（= 作り直す）。「既存の暗号化されていない DB を暗号化したい」という設問の答えはこれ。S3 は後からでも設定できる（既存オブジェクトはバッチ操作で変換する）。
鍵には 3 種類ある。誰が管理し、誰がポリシーを書けるかで分かれる。
| 鍵の種類 | 管理するのは | できること | 料金 |
|---|---|---|---|
| AWS 所有キー | AWS | 見えない・選べない | 無料 |
| AWS マネージドキー | AWS（aws/s3 のような名前） | 使えるが、ポリシーは変えられない | 無料 |
| カスタマーマネージドキー | 利用者 | キーポリシー・ローテーション・無効化・削除 | 月額＋リクエスト課金 |
試験では
「鍵へのアクセスを自分で制御したい」「監査のために鍵の使用を追跡したい」「ローテーションの周期を決めたい」ならカスタマーマネージドキー。AWS マネージドキーはポリシーを書けないので、この要件では落ちる。
KMS で押さえるべき仕組みが エンベロープ暗号化 だ。大きなデータを KMS に送って暗号化するのではなく、データは手元のデータキーで暗号化し、そのデータキーだけを KMS の鍵で暗号化する。
- KMS にデータキーを作ってもらう。平文のデータキーと、暗号化されたデータキーが返る。
- 平文のデータキーでデータを暗号化し、平文のデータキーはメモリから消す。
- 暗号化されたデータキーを、暗号化済みデータと一緒に保管する。
- 復号するときは、暗号化されたデータキーを KMS に送って平文に戻してもらう。
補足
なぜこの形にするのか。KMS が 1 回で扱えるデータは最大 4KB しかないし、大きなファイルを毎回ネットワーク越しに送るのは遅い。鍵だけを往復させれば、データ本体は手元で速く処理できる。S3 も EBS も内部ではこの形で動いている。
鍵のポリシーについて、1 つだけ特別なことがある。KMS の鍵には必ずキーポリシーが付いていて、IAM ポリシーだけでは鍵を使えない。他のサービスなら IAM ポリシーで許可すれば足りるが、KMS は鍵側の許可も要る。
試験では
「IAM で kms:Decrypt を許可したのに復号できない」はキーポリシー側の問題。鍵のキーポリシーにそのプリンシパルが書かれていない。この型は第 1 章の「信頼ポリシーを疑う」と同じ構造だ。
鍵を預ける先がもう 1 つある。AWS CloudHSM だ。違いは「AWS が鍵に触れるかどうか」に尽きる。
| AWS KMS | AWS CloudHSM | |
|---|---|---|
| 形 | マネージドな共有サービス | 専有のハードウェア（HSM） |
| 鍵に触れるのは | AWS も仕組み上は関与する | 利用者だけ。AWS は鍵を見られない |
| 他の AWS サービスとの連携 | ほぼ全部とつながる | 限定的（カスタムキーストア経由） |
| 運用 | AWS がやる | 自分でクラスタを運用する |
| 選ぶ理由 | ふつうはこちら | FIPS 140-2 レベル 3 など、規制で求められるとき |
試験では
「鍵は絶対に AWS にも見せられない」「FIPS 140-2 レベル 3 が要る」なら CloudHSM。それ以外は KMS が正解になる。運用の手間を減らしたい設問で CloudHSM を選ぶと誤り。
| やりたいこと | 答え |
|---|---|
| ALB や CloudFront を HTTPS にしたい | ACM で発行して付ける（無料・自動更新） |
| 証明書の期限切れで止まるのを防ぎたい | ACM の自動更新に任せる |
| EC2 に証明書を置きたい | ACM のパブリック証明書は書き出せない。取り込むか、プライベート CA を使う |
| 社内向けの証明書を自分で発行したい | ACM Private CA |
試験で最も細かく問われるのが S3 の守り方だ。暗号化の方式が 4 つあり、さらに消させない／戻せるようにする仕組みが別にある。
| 方式 | 鍵を持つのは | 特徴 |
|---|---|---|
| SSE-S3 | AWS（S3 が管理） | 既定で有効。何も設定しなくても暗号化される |
| SSE-KMS | 利用者（KMS の鍵） | 鍵の使用が CloudTrail に残る。アクセス制御も書ける |
| DSSE-KMS | 利用者（KMS の鍵） | 二重に暗号化する。規制で求められる場合 |
| SSE-C | 利用者（自分で持ち込む） | リクエストのたびに鍵を送る。S3 は鍵を保管しない |
補足
2023 年 1 月から、S3 に置かれる新しいオブジェクトは既定で SSE-S3 により暗号化される。「暗号化されていないオブジェクトがある」という前提の古い設問は、現行では成り立たない。ただしどの鍵で暗号化するかを選びたいなら、明示的に SSE-KMS を指定する。
| 仕組み | 何をするか | 注意点 |
|---|---|---|
| ブロックパブリックアクセス | バケットを公開させない | 新しいバケットでは既定で有効 |
| バージョニング | 上書き・削除しても前の版が残る | 一度有効にすると無効化できない（停止のみ） |
| MFA Delete | 版の削除に MFA を要求する | バージョニングが前提。ルートユーザーだけが設定できる |
| オブジェクトロック | 決めた期間、誰も消せなくする（WORM） | バージョニングが前提。コンプライアンスモードは管理者でも解除できない |
| レプリケーション | 別バケット／別リージョンへ複製 | 両方でバージョニングが要る |
試験では
オブジェクトロックのコンプライアンスモードは、root でも期間中は削除できない。「規制で N 年間の保持が求められる」「改ざんされないようにしたい」はこれが答え。ガバナンスモードは特別な権限を持つ利用者なら解除できる、という違いも問われる。
暗号化は「盗まれても読めない」ための仕組みで、「消えた／壊れた」ときには役に立たない。そちらはバックアップの話だ。
| やりたいこと | 使うもの |
|---|---|
| サービスごとにばらばらのバックアップをまとめたい | AWS Backup（プランで一元管理） |
| バックアップを消させないようにしたい | AWS Backup のボールトロック |
| 古いデータを自動で安い置き場へ移したい | S3 のライフサイクル（第 11 章） |
| 誤って消したときに戻したい | バージョニング／スナップショット／ごみ箱（Recycle Bin） |
| 別リージョンにも控えを置きたい | クロスリージョンのコピー／レプリケーション |
最後に、監査や規制に答えるための道具を分ける。ここも名前が似ているので、誰に向けて何を出すかで覚える。
| 道具 | 何をするか |
|---|---|
| AWS Artifact | AWS 側の監査報告書（SOC・ISO など）をダウンロードする場所 |
| AWS Audit Manager | 自分の環境の証跡を基準ごとに自動で集める |
| AWS Config | リソースの設定が決めた形から外れていないかを継続して見る |
| Amazon Macie | S3 の中に個人情報などが無いかを探す |
| AWS CloudTrail | 誰が何をしたかの記録。ログの改ざん検出も設定できる |
試験では
Artifact は「AWS が監査を受けた証明書をもらう場所」、Audit Manager は「自分が監査を受けるための証拠を集める道具」。向きが逆なので、入れ替えた選択肢が出る。
シナリオ演習
既存の RDS インスタンスが暗号化されていないことが監査で指摘された。暗号化を有効にしたい。手順は。
補足
答え：スナップショットを取り、暗号化を有効にしたコピーから復元して切り替える。
稼働中の RDS に後から暗号化を有効にすることはできない。「設定画面で暗号化を有効にする」という選択肢は存在しない操作。
シナリオ演習
法令で、取引記録を 7 年間、誰にも削除・変更させずに保管する必要がある。
補足
答え：S3 のバージョニングを有効にし、オブジェクトロックをコンプライアンスモードで7 年の保持期間を設定する。
ガバナンスモードは特別な権限を持つ利用者が解除できるので、「誰にも」という要件を満たさない。IAM ポリシーで削除を禁じる案も、ポリシーを変えられる人が消せるので落ちる。
この章のまとめ
- データを守る 2 つの状態
- 既存の暗号化されていない RDS を暗号化する手順
- KMS の鍵 3 種類
- キーポリシーを書けるのはどれか
- エンベロープ暗号化で KMS が暗号化するもの
- KMS が 1 回で扱えるデータの上限
この章の根拠
最終確認 2026-10-04 ／ 対応バージョン DEA 2026-05-04 改訂版