第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 管理キー（無料）とカスタマー管理キー（監査・制御が必要なとき）

暗号化の実践：どこで何を暗号化するか

対象ごとの暗号化の仕組みと既定の状態です。

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 には、脅威や設定の不備を見つけるサービスがそろっています。

まず 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）になっている点が大きな違いです。

Kerberos については補足があります。Entra ID は DC の代わりにはなりませんが、Azure Files などの特定のサービスのために Kerberos のチケットを出す「Entra Kerberos」があります（このブログの連載「Kerberos入門」第12回の「クラウドの Kerberos」で詳しく扱います）。

考えてみよう

1. 暗号化を有効にせずに作った RDS のインスタンスがあります。後から暗号化するにはどうしますか。また、これから暗号化されていない EBS や S3 が作られたときに気づくには、何を使いますか
2. EC2 のアプリが使う DB のパスワードは、今どこに置かれていますか。Secrets Manager と Parameter Store のどちらに移すか、ローテーションの要否から考えてください
3. 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回

1. クラウドとは（定義・歴史・責任分界）
2. AWSの全体像
3. コンピューティング 前編（EC2・Nitro・インスタンスタイプ・AMI・IMDS）
4. コンピューティング 後編（課金と購入オプション・Auto Scaling・ELB・コンテナ・Lambda）
5. ストレージ
6. ネットワーキング 前編（VPC・サブネット・SG・NACL）
7. ネットワーキング 後編（DNS・接続・Route 53・CloudFront）
8. IAMとセキュリティ 前編（IAM・ポリシー・STS・ID連携・Organizations）
9. IAMとセキュリティ 後編（KMS・シークレット・ACM・検知と防御）（この記事）
10. データベース
11. 運用・監視・コスト 前編（CloudWatch・CloudTrail・Config・SSM）
12. 運用・監視・コスト 後編（タグ・転送料金・コスト管理・Control Tower・IaC）
13. Well-Architectedフレームワーク
14. これまでのテーマとAWSの対応・まとめ