ACMは「そのサーバ、本物です」を証明してくれる公証人 📜
そもそも「サーバ認証」がなぜ必要なのか
ユーザーからリソースへのアクセスは、基本的にネットワーク経由で行われる。
ネットワークを経由するということは、
常に傍受や改ざんのリスクと隣り合わせということでもある。
このリスクを防ぐために、
リソースにSSL/TLS認証（サーバ認証）を適用する。
ユーザーとの通信をHTTPSで暗号化するだけでなく、
ドメインの使用権を確認し、「アクセス先のサーバが本物である」ことまで証明してくれる。
暗号化していても、
繋いだ相手が偽物だったら意味がない、という当たり前だけど重要な話。
ACMは「証明書の発行・管理」を丸ごと引き受けるサービス
ACM（Certificate Manager）は、
SSL/TLS証明書を作成・管理するマネージドサービス。
CloudFront、ELB、API Gatewayに適用することで、
- 通信の暗号化
- アクセス先サーバの正当性の証明
の両方を同時に実現できる。
主な機能
証明書の発行とインポート
- Amazonによるパブリック証明書の発行
-
ワイルドカード証明書（ドメイン名にアスタリスクを含む）にも対応
→ 1つの証明書で複数のサブドメインをまとめてカバーできる - サードパーティ認証局（CA）が発行した証明書のインポートも可能
一枚一枚サブドメインごとに証明書を用意しなくても、
ワイルドカード証明書があれば「まとめて一括カバー」できるのが地味に便利。
自動更新
- ACMが発行した証明書 → 自動更新
- インポートした証明書 → 手動更新が必要
証明書は放置すると期限切れになるものなので、
「ACM発行なら勝手に更新される」というのはかなり大きな安心材料になる。
逆に、インポートした証明書は自動更新の対象外なので、
うっかり期限切れを起こさないよう自分で管理する必要がある。
監視と記録
- EventBridge
- CloudWatch
- CloudTrail
これらと連携することで、
証明書まわりのイベントのモニタリングやロギングが可能になる。
証明書を発行して終わりではなく、
その後の状態までちゃんと追跡できる仕組みが用意されている。
まとめメモ ✍️
- ACMはSSL/TLS証明書の作成・管理を行うマネージドサービス
- CloudFront、ELB、API Gatewayに適用し通信の暗号化とサーバの正当性を担保
- ワイルドカード証明書で複数サブドメインをまとめてカバー可能
- ACM発行の証明書は自動更新、インポート証明書は手動更新
- EventBridge・CloudWatch・CloudTrailと連携し監視・記録が可能
「暗号化する」ことと「相手が本物だと証明する」ことは別物だと、
今回改めて整理できた回だった。