「アプリの設定ファイルに RDS のパスワードを書いたまま、Git のリポジトリに入れてしまっていました。どこに置き直せばよいでしょうか。パスワードを定期的に変える仕組みもほしいです」
「ACM で無料の証明書を発行して ALB では使えたのに、CloudFront のディストリビューションの設定画面では、その証明書が一覧に出てきません」
第8回では、IAM のユーザー・ロールとポリシー、評価の順序、STS、Identity Center、Organizations と SCP・RCP を見ました。「誰が何をしてよいか」を決めても、それだけでは守りきれません。ディスクやバックアップのデータ、DB のパスワード、TLS の証明書をどう守るか、そして攻撃や設定の不備にどう気づき、入口でどう止めるかが残ります。オンプレでは HSM や社内 PKI、パスワードの金庫、IDS や WAF の装置が担っていた役目です。
後編の第9回では、KMS による暗号化、どこで何を暗号化するか、Secrets Manager と Parameter Store、ACM、検知のサービス、WAF・Shield・Network Firewall による境界防御を扱い、前編と後編の範囲をまとめた Azure との対応表で締めくくります。数値・料金は2026年9月時点のもので、料金は東京リージョンの例です。
データの暗号化：KMS
AWS KMS（Key Management Service）は、暗号鍵を生成・保管・利用するマネージドサービスです。鍵を守る専用装置である HSM（ハードウェアセキュリティモジュール）を、FIPS 140-3 レベル3で AWS が運用しています（HSM で CA の鍵を守る話は、このブログの連載「証明書入門」第5回の「ルートCA・中間CA・サーバー証明書」で詳しく扱っています）。鍵は「KMS キー」（旧 CMK）として ARN を持ち、EBS・S3・RDS・EFS・Secrets Manager・CloudTrail など、ほぼすべてのサービスが「このキーで暗号化する」と指定できます。
実際のデータは KMS キーで直接暗号化されるのではなく、エンベロープ暗号化（データキーでデータを暗号化し、そのデータキーを KMS キーで暗号化して一緒に保存）で処理されます。KMS の API 呼び出しは、鍵の暗号化・復号にだけ使われます。
鍵にはキーポリシー（リソースベース）が必須で、「誰が使えるか」「誰が管理できるか」を分けられます。AWS 管理キー（aws/ebs など、無料・自動）とカスタマー管理キー（月 1 USD、ローテーション・削除・キーポリシーを自分で制御。2026年9月時点、東京リージョンの例）があり、監査の要件があれば後者を使います。鍵の削除は7〜30日の待機期間を必ず挟み、削除するとそのキーで暗号化したデータは二度と復号できません。Organizations と RCP（第8回の「AWS Organizations と SCP」の節）を組み合わせ、「組織外の主体は KMS を使えない」とすれば、データの持ち出しを鍵の側で止められます。
- HSM ベースの鍵管理。ほぼ全サービスが KMS キーを指定できる
- エンベロープ暗号化：データキーで暗号化、データキーを KMS で保護
- AWS 管理キー（無料）とカスタマー管理キー（監査・制御が必要なとき）
暗号化の実践：どこで何を暗号化するか
対象ごとの暗号化の仕組みと既定の状態です。
| 対象 | 仕組み | 既定 | 備考 |
|---|---|---|---|
| EBS | SSE（KMS） | アカウント設定で「既定で暗号化」を有効化できる | 暗号化ボリュームのスナップショットも暗号化。性能影響はほぼなし |
| S3 | SSE-S3／SSE-KMS／SSE-C／クライアント側 | 2023-01 から SSE-S3 が既定 | SSE-KMS はキーポリシーでアクセス制御を二重化できる |
| RDS／Aurora | ストレージ暗号化（KMS） | 作成時に選択。後から有効化不可（スナップショット経由で作り直し） | |
| EFS／FSx | 保存時（KMS）＋転送時（TLS） | ||
| 通信 | TLS（ACM 証明書。この回の「証明書：ACM」）、VPN、DX の MACsec | AWS 内部の AZ 間・リージョン間はリンク層で暗号化済み | |
| Secrets／パラメータ | Secrets Manager／Parameter Store（SecureString） | ||
| ログ | CloudTrail・CloudWatch Logs の KMS 暗号化 |
Well-Architected のセキュリティの柱（第13回）は「保存時・転送時の暗号化」を原則としており、Config ルール（encrypted-volumes、s3-bucket-server-side-encryption-enabled）で暗号化されていないものを検出します。
シークレットの管理：Secrets Manager と Parameter Store
DB のパスワードや API キーは、コードや設定ファイルではなく専用のサービスに置きます。
- AWS Secrets Manager：DB のパスワード・API キーなどを暗号化して保管し、自動ローテーション（RDS・Redshift・DocumentDB は組み込み、ほかは Lambda で実装）ができる。シークレット1件あたり月 0.40 USD＋API 呼び出し（2026年9月時点、東京リージョンの例）。RDS の「マスターパスワードを Secrets Manager で管理」を選ぶと最初から連携される
- Systems Manager Parameter Store：設定値と
SecureString（KMS 暗号化）を階層的に保管。標準パラメータは無料。ローテーションは無い - 使い分け：ローテーションと監査が要るなら Secrets Manager、単なる設定値・小規模なら Parameter Store
- アプリからの取得：SDK か、ECS のタスク定義／Lambda の環境変数への注入。コードや AMI・ユーザーデータ・Git に書かない
- GitHub に AWS のアクセスキーを push する事故は今も多い。AWS はキーを検出すると自動で隔離ポリシーを付ける（
AWSCompromisedKeyQuarantineV3）が、そもそも恒久キーを作らない（前編の第8回の「STS（Security Token Service）と AssumeRole」「ID 連携：IAM Identity Center と SAML」の節）のが本質的な対策
冒頭の1つ目の相談がこれです。パスワードは Secrets Manager に移し、RDS の組み込みの自動ローテーションを有効にして、アプリは起動時に SDK で取得します。Git に一度入れたパスワードは履歴に残り続けるので、移すだけでなくパスワード自体も変えます。ローテーションを有効にすれば、その最初の切り替えも Secrets Manager に任せられます。
証明書：ACM（AWS Certificate Manager）
ACM は、TLS サーバー証明書の発行・更新・配備をマネージドで行うサービスです。パブリック証明書は無料で、Amazon Trust Services（ルート CA は Starfield 系）から発行され、主要なブラウザー・OS に信頼されています。
ドメインの所有確認は DNS 検証（Route 53 なら CNAME を自動で追加）かメール検証で、DNS 検証にしておけば有効期限の前に自動で更新され、期限切れの事故が構造的に起きません（期限切れの事故の実例は、このブログの連載「証明書入門」第8回の「期限切れ事故の実例」で詳しく扱っています）。2026年2月からは、CA/ブラウザフォーラムの決定に合わせて有効期間が最長198日になり、期限の45日前に自動で更新されます。
用途は ELB、CloudFront、API Gateway など AWS のサービスへの配備が基本で、EC2 の Nginx にそのまま入れることは長らくできませんでしたが、2025年6月からエクスポート可能なパブリック証明書（有料、秘密鍵を取り出せる）が追加されました。CloudFront 用の証明書は us-east-1 で発行する必要がある点は定番の注意点です。冒頭の2つ目の相談がこれで、CloudFront は us-east-1（バージニア北部）の ACM の証明書しか使えないため、東京リージョンで発行した証明書は一覧に出ません。同じドメイン名の証明書を us-east-1 でもう一度発行します（DNS 検証で、Route 53 なら CNAME の追加も自動です）。外部の CA（DigiCert など）で取得した証明書を ACM にインポートして ELB で使うこともできます（更新は手動です）。
社内の PKI が必要なら AWS Private CA（月額の CA 料金＋証明書ごとの課金）でプライベート CA を運用でき、IoT やサービス間の mTLS の証明書を発行できます。ACM と Private CA の詳しい使い方は、このブログの連載「証明書入門」第9回の「ACM（AWS Certificate Manager）」と「AWS Private CAとAzureの対応」で詳しく扱っています。
- パブリック証明書は無料、DNS 検証で自動更新
- 配備先は ELB／CloudFront／API Gateway。CloudFront は us-east-1
- エクスポート可能証明書（2025〜、有料）、外部証明書のインポート、Private CA
検知と防御のサービス群
AWS には、脅威や設定の不備を見つけるサービスがそろっています。
| サービス | 役割 | 入力・仕組み |
|---|---|---|
| Amazon GuardDuty | 脅威検知（不正なログイン、マイニング、C2 通信、S3 の異常アクセス） | CloudTrail・VPC Flow Logs・DNS ログ・EKS 監査ログを機械学習で分析。エージェント不要 |
| AWS Security Hub | 各サービスの検出結果を集約し、CIS／AWS 基礎セキュリティベストプラクティスに照らしてスコア化 | Config・GuardDuty・Inspector・Macie の集約 |
| Amazon Inspector | EC2・ECR・Lambda の脆弱性スキャン（CVE、ネットワーク到達性） | SSM エージェント経由（エージェントの無い EC2 は EBS スナップショットによるエージェントレスのスキャン）。継続的 |
| Amazon Macie | S3 内の個人情報・機密情報の検出 | 機械学習 |
| Amazon Detective | インシデントの調査（関係グラフの可視化） | GuardDuty の結果を深掘り |
| AWS Config | 設定の記録とルール違反の検出（第11回） | |
| IAM Access Analyzer | 外部に公開されているリソース、未使用の権限の検出 | |
| AWS CloudTrail | 操作の証跡（第11回） |
まず CloudTrail・GuardDuty・Security Hub・Config の4つを Organizations 全体で有効化するのが最初の一手です。GuardDuty には30日の無料試用があり、費用は分析するログの量に比例します。
なお、表の「CIS／AWS 基礎セキュリティベストプラクティスに照らしてスコア化」する機能は、2025年に名前が AWS Security Hub CSPM に変わりました（旧 Security Hub）。いまの「AWS Security Hub」は、GuardDuty や Inspector などの結果を関連付けて優先度を付ける新しいサービスを指します。コンソールや資料を見るときは、どちらの話かを確かめてください。
境界防御：WAF・Shield・Network Firewall
入口と VPC の境界で攻撃を止めるサービスです。
- AWS WAF：ALB・CloudFront・API Gateway・AppSync の前段で HTTP リクエストを検査する Web アプリケーションファイアウォール。マネージドルール（OWASP Top 10 相当、既知の悪性 IP、Bot 制御）と、自作のルール（レートベース：例として同一 IP から5分に 2,000 リクエストを超えたら遮断、国別、ヘッダーの条件）を使える。HTTP のメソッド・ヘッダー・URI の知識がルール作りに直結する（このブログの連載「HTTP入門」第2回の「メソッド」、第3回の「主なヘッダー（リクエスト）」、第10回の「WAFとAPIゲートウェイ」で詳しく扱います）
- AWS Shield Standard：L3/L4 の DDoS 緩和の機能。全利用者に無料・自動で適用され、CloudFront／Route 53 と組み合わせるとエッジで吸収できる
- Shield Advanced：月 3,000 USD（2026年9月時点）。L7 の DDoS 対応、DDoS 対応チーム（SRT）への24時間のアクセス、攻撃によるスケールアウトの費用の保護
- AWS Network Firewall：VPC 内に置くマネージドの L3〜L7 のファイアウォール（Suricata 互換のルール、ドメイン名のフィルター、IDS/IPS）。SG／NACL では書けない「特定のドメインへのアウトバウンドだけを許可」ができる
- Firewall Manager：Organizations 全体に WAF・SG・Network Firewall のポリシーを強制できる
- Route 53 Resolver DNS Firewall：VPC からの DNS クエリをドメインリストで遮断する（マルウェアの C2 通信の対策。オンプレの RPZ に当たる。このブログの連載「DNS入門」第9回の「保護的DNS・RPZ・DNSファイアウォール」と、第10回の「クエリーログ・DNS Firewall・Global Resolver」で詳しく扱っています）
Azure との対応表：ID・セキュリティ
Azure では、ID の基盤が独立したサービス（Entra ID）になっている点が大きな違いです。
| AWS | Azure | 補足 |
|---|---|---|
| IAM（ユーザー・グループ） | Microsoft Entra ID（テナント） | Azure は ID 基盤が独立したサービス。AWS の IAM は AWS 内部のもの |
| IAM ポリシー／ロール | Azure RBAC（ロール定義＋スコープ＋割り当て） | Azure は「ロール」を「スコープ（管理グループ／サブスクリプション／RG／リソース）」に割り当てる |
| IAM ロール（サービス用） | マネージド ID（システム割り当て／ユーザー割り当て） | |
| STS／AssumeRole | Entra ID トークン（OAuth 2.0）、Privileged Identity Management（PIM、時間限定の昇格） | |
| IAM Identity Center | Entra ID そのもの（＋条件付きアクセス） | Azure は最初から SSO 前提 |
| Managed Microsoft AD | Entra Domain Services | Entra ID 本体は LDAP/Kerberos 非対応（連載「LDAP入門」第10回の「クラウドの LDAP」） |
| Organizations／SCP | 管理グループ／Azure Policy（Deny 効果） | Azure Policy は Config ルール＋SCP の両方の役割 |
| KMS | Azure Key Vault（キー） | Key Vault は鍵・シークレット・証明書を 1 つで扱う |
| Secrets Manager／Parameter Store | Key Vault（シークレット）／App Configuration | |
| ACM | Key Vault（証明書）／App Service マネージド証明書 | |
| GuardDuty／Security Hub／Inspector | Microsoft Defender for Cloud（CSPM＋CWPP） | Defender for Cloud が複数の役割を兼ねる |
| Macie | Microsoft Purview | |
| WAF／Shield | Azure WAF（Application Gateway／Front Door）／Azure DDoS Protection | |
| Network Firewall | Azure Firewall（Premium で IDPS） |
Kerberos については補足があります。Entra ID は DC の代わりにはなりませんが、Azure Files などの特定のサービスのために Kerberos のチケットを出す「Entra Kerberos」があります（このブログの連載「Kerberos入門」第12回の「クラウドの Kerberos」で詳しく扱います）。
考えてみよう
- 暗号化を有効にせずに作った RDS のインスタンスがあります。後から暗号化するにはどうしますか。また、これから暗号化されていない EBS や S3 が作られたときに気づくには、何を使いますか
- EC2 のアプリが使う DB のパスワードは、今どこに置かれていますか。Secrets Manager と Parameter Store のどちらに移すか、ローテーションの要否から考えてください
- ALB で公開しているログイン画面に、同じ IP アドレスから短い間に大量のリクエストが来ています。どのサービスのどんなルールで止めますか。L3/L4 の大きな DDoS には、何が備えになりますか
ヒント：1は「暗号化の実践：どこで何を暗号化するか」、2は「シークレットの管理」、3は「境界防御：WAF・Shield・Network Firewall」の節を見直してください。
まとめ
- KMS は HSM で鍵を守り、データはエンベロープ暗号化で扱う。キーを削除すると、そのキーで暗号化したデータは二度と復号できない
- 暗号化は保存時と転送時が原則。S3 は既定で暗号化、EBS はアカウントの既定にでき、RDS は後から有効にできない
- パスワードや API キーは Secrets Manager（ローテーション）か Parameter Store（無料の設定値）に置き、コードや Git に書かない
- ACM のパブリック証明書は無料で、DNS 検証なら自動で更新される。CloudFront 用は us-east-1 で発行する
- まず CloudTrail・GuardDuty・Security Hub・Config を組織全体で有効にし、入口は WAF・Shield で守る
- Azure では Entra ID が ID 基盤として独立し、Key Vault が鍵・シークレット・証明書を、Defender for Cloud が検知を兼ねる
次回は、RDS・Aurora・DynamoDB を中心に、AWS のデータベースを扱います。
連載「クラウド入門」全14回
- クラウドとは（定義・歴史・責任分界）
- AWSの全体像
- コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
- コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
- ストレージ
- ネットワーキング 前編（VPC・サブネット・SG・NACL）
- ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
- IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
- IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）（この記事）
- データベース
- 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
- 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
- Well-Architectedフレームワーク
- これまでのテーマとAWSの対応・まとめ
コメント