AWSデータ暗号化設計入門｜保存時・転送時の暗号化方式とKMS統合ポイントをサービス別に整理する実践ガイド

2026年10月19日

「S3にKMSでサーバーサイド暗号化をかけているけど、RDSやEBSはデフォルト設定のままだ」「本番環境のTLS設定がまちまちで、どのサービスがどの暗号化を使っているか把握できていない」―― こうした状況は、クラウド移行を進めたチームに意外と多い。

オンプレ環境では、ネットワーク機器やストレージアレイの暗号化設定をインフラチームが一括管理していたはずだ。クラウドに移行すると、暗号化の責任が各サービスに分散し、設定箇所が格段に増える。把握しきれないまま本番稼働を迎えると、コンプライアンス監査や情報セキュリティ点検で思わぬ指摘を受けることになる。

この記事では、AWSのデータ暗号化設計を「保存時の暗号化（Encryption at Rest）」と「転送時の暗号化（Encryption in Transit）」の2軸で整理し、主要サービスごとの設定ポイントとKMS統合の考え方を解説する。PCI DSS・個人情報保護法（APPI）への対応を考えているエンジニアにも、設計判断の根拠として使える内容にした。

なぜクラウドでの暗号化設計が複雑になるのか

オンプレ環境では「ストレージはFull Disk Encryptionで一律保護」「外部通信はVPNで終端」のように、レイヤーを絞って暗号化を実装できた。AWSではサービスの数だけ暗号化の選択肢が増える。

たとえばS3だけでも、暗号化方式は次の4種類から選べる。

・SSE-S3（AES-256）: S3が自動管理するキーで暗号化。設定が最もシンプル
・SSE-KMS（AWS KMS）: KMSのカスタマーマネージドキー（CMK）で暗号化。キーポリシーで細かい制御が可能
・SSE-C（顧客指定キー）: 顧客がキーを提供してS3に渡す。キー管理の責任は完全に顧客側
・CSE（クライアントサイド暗号化）: データをAWSに送る前に顧客側で暗号化する方式

EBS、RDS、DynamoDB、EFS、SQS、SNS……それぞれに独自の暗号化オプションがある。「どこで何を使うか」の設計方針がなければ、担当者によって設定がまちまちになる。

保存時の暗号化（Encryption at Rest）の基本

1. AWS KMSの3種類のキータイプ

AWSの保存時暗号化の中心になるのがAWS Key Management Service（AWS KMS）だ。KMSのキーには大きく3種類ある（2026年10月時点）。

キータイプ	誰が管理するか	料金	カスタマイズ性
AWSマネージドキー（aws/s3 等）	AWS側が完全管理	無料（APIコールのみ課金）	ほぼなし
カスタマーマネージドキー（CMK）	顧客が管理	月額$1/キー + APIコール課金	高い（キーポリシー・自動ローテーション）
外部キーマテリアル（BYOK）	顧客がキーマテリアルをインポート	月額$1/キー + APIコール課金	高い（キーの完全所有権）

コンプライアンス要件が厳しい場合は基本的にCMKを選ぶ。AWSマネージドキーはキーポリシーを変更できず、監査証跡の粒度も落ちる。CMKなら「どのIAMロールがどのキーを使ったか」をCloudTrailで追跡でき、監査レポートに活用できる。

なお、AWSではKMSで生成したデータキー（Data Key）で実際のデータを暗号化し、そのデータキー自体をKMSのCMKで暗号化するという「エンベロープ暗号化」が基本パターンだ。KMSが直接大量のデータを暗号化するわけではない点は、オンプレのHSMと異なる動作だ。

KMSの詳細については、AWS KMS入門 S3データ暗号化とキー管理の実践ガイドで解説しているので参考にしてほしい。より厳格な鍵管理が必要な場合のCloudHSM（専用HSM）との違いも合わせて確認するとよい。

2. 主要サービスの保存時暗号化設定一覧

以下は主要AWSサービスの保存時暗号化対応状況だ（2026年10月時点）。

サービス	デフォルト暗号化	KMS CMK対応	注意点
Amazon S3	SSE-S3（2023年から自動有効）	○（SSE-KMS）	バケットデフォルト暗号化で全オブジェクトに適用可
Amazon EBS	アカウントレベルでデフォルト有効化可（新規ボリュームのみ）	○	既存ボリュームは後から暗号化不可。スナップショット→新ボリューム作成で対応
Amazon RDS	作成時に選択（後から変更不可）	○	暗号化インスタンスのスナップショットは自動暗号化される
Amazon Aurora	RDSと同様	○	クラスター全体（ストレージ・バックアップ・レプリカ）に一括適用
Amazon DynamoDB	常時有効（AWS所有キー）	○（CMKへ変更可）	デフォルトのAWS所有キーは無料。CMKに変更するとKMS費用が発生
Amazon EFS	作成時に選択（後から変更不可）	○	転送時のTLS設定とは独立している
Amazon SQS	未暗号化（設定で有効化）	○（SSE-KMS）	キュー作成後でも変更可能
Amazon SNS	未暗号化（設定で有効化）	○（SSE-KMS）	トピック作成後でも変更可能
AWS Lambda（環境変数）	AWSマネージドキーで暗号化	○（CMKへ変更可）	関数コード自体はS3管理のためS3暗号化が適用される

3. EBSのよくあるつまずき：既存ボリュームは後から暗号化できない

オンプレのSAN環境では後から暗号化を有効にできるストレージ製品もあるが、EBSは一般的に後付け暗号化ができない。既存のEBSボリュームを暗号化するには次の手順が必要だ。

# 想定例: 既存EBSボリュームを暗号化する一般的な手順（AWS CLI） # 1. 既存ボリュームのスナップショット作成 aws ec2 create-snapshot \ --volume-id vol-xxxxxxxxxxxxxxxxx \ --description "pre-encrypt-backup" # 2. スナップショットをKMS CMKで暗号化コピー aws ec2 copy-snapshot \ --source-region ap-northeast-1 \ --source-snapshot-id snap-xxxxxxxxxxxxxxxxx \ --description "encrypted-copy" \ --encrypted \ --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \ --region ap-northeast-1 # 3. 暗号化スナップショットから新ボリューム作成 aws ec2 create-volume \ --snapshot-id snap-yyyyyyyyyyyyyyyyy \ --availability-zone ap-northeast-1a \ --encrypted \ --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

この作業はEC2インスタンスの停止を伴うため、メンテナンスウィンドウの確保が必要だ。クラウド移行時に暗号化を有効にしておくか、アカウントレベルで「EBSデフォルト暗号化」を有効化しておくのが最善策だ。

4. RDSの落とし穴：暗号化は作成後変更不可

RDSも同様に、インスタンス作成後に暗号化の有効・無効を変更することはできない。既存の非暗号化RDSインスタンスを暗号化するには、スナップショットを取得して暗号化コピーを作成し、そこからインスタンスをリストアする手順が必要だ。本番DBのカットオーバーが発生するため、計画的に進める必要がある。

新規環境を構築する際はTerraformやCloudFormationのIaCテンプレートにデフォルトで storage_encrypted = true を入れておくことを強く推奨する。

転送時の暗号化（Encryption in Transit）の設計

1. AWS外部との通信：TLSバージョンの強制

クラウドサービスとクライアント間の通信は基本的にHTTPS/TLSを使う。AWSのマネージドエンドポイントはデフォルトでTLS対応しているが、「TLS 1.0/1.1でも接続できてしまう」という設定が残っているケースがある。

PCI DSS v4.0ではTLS 1.2以上が要件だ。Application Load Balancer（ALB）ではセキュリティポリシーで最低バージョンを指定できる。

# AWS CLIでALBのリスナーにTLS 1.2以上を強制するセキュリティポリシーを設定（例） aws elbv2 modify-listener \ --listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/xxxx/xxxx \ --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06

SSL/TLS証明書の管理はAWS Certificate Manager（ACM）で無料で自動更新できる。詳細はAWS Certificate Manager（ACM）入門を参照してほしい。

2. VPC内部の通信：「暗号化していない」という盲点

外部通信にTLSをかけていても、VPC内部（サービス間通信）を平文で通信しているケースがある。オンプレ環境ではデータセンター内を「信頼できるネットワーク」として扱う設計が多かったが、クラウドではゼロトラストの観点から内部通信も暗号化することが推奨される。

詳しくはゼロトラストセキュリティ入門も参考にしてほしい。主なVPC内通信の暗号化オプションを整理する。

・RDS/Aurora: 接続時に ssl-mode=require または ssl-mode=verify-full を指定するとTLS接続が強制される
・ElastiCache for Redis（TLSモード）: クラスター作成時に転送中暗号化を有効化できる（後から変更不可）
・Amazon MSK（Apache Kafka）: ブローカー間通信・クライアント間通信それぞれでTLSを設定可能
・Amazon EFS: マウント時に -o tls オプションを指定するとAmazon EFS mount helperがTLSでマウントする
・EC2インスタンス間: 同一リージョン内でも特定インスタンスタイプ（C5n、P3dn等）間はAWSネットワーク層で自動暗号化される（2019年～）

3. 内部APIエンドポイントのmTLS設計

マイクロサービス構成では、サービス間のAPIコールにmTLS（相互TLS認証）を適用することがある。AWSではACM Private CA（プライベート認証局）を使ってサービス間の証明書を発行・管理するのが定石だ。詳細はAWS ACM Private CA設計入門で解説している。

コンプライアンス要件別の設計パターン

1. PCI DSS v4.0 対応の最低ライン

クレジットカード情報（CHD）を扱うシステムがPCI DSS v4.0に準拠するためには、暗号化に関して主に以下が求められる。

・保存データ: CHDはAES-256以上で暗号化（KMS CMKで要件を満たせる）
・転送データ: TLS 1.2以上を使用（TLS 1.0/1.1は廃止必須）
・鍵管理: 暗号鍵のアクセス記録をCloudTrailで保持、年1回の鍵ローテーション
・鍵の分離: 本番環境のCMKは開発・ステージング環境と分離（アカウント分離＋CMKのキーポリシーで制御）

想定例として、AWS Audit ManagerのPCI DSS準拠フレームワークを活用すると、暗号化設定に関するコントロールの証拠収集を自動化できる。

2. 個人情報保護法（APPI・日本）対応

日本の個人情報保護法では「漏えい等のリスクに応じた安全管理措置」が求められる。法令上「AES-256必須」のような具体的な暗号アルゴリズムは規定されていないが、経済産業省・個人情報保護委員会のガイドラインでは「適切な暗号化」を施すことが求められている。実務上は少なくとも以下をカバーすることで、審査や監査に対して説明責任を果たしやすい。

・個人情報を含むS3バケットにSSE-KMS（CMK）を適用し、バケットポリシーで暗号化なしのPUTリクエストを拒否する
・個人情報DBのRDS/Aurora暗号化を有効化する
・外部への転送はHTTPS（TLS 1.2以上）を強制する
・KMS CMKのCloudTrailログを保持して鍵の使用履歴を追跡できるようにする

組織全体の暗号化設定を「検知・強制」する仕組み

1. AWS Configルールで非暗号化リソースを自動検知する

個別サービスの暗号化設定は人間が見落としやすい。AWS Configのマネージドルールを使えば、暗号化が未設定のリソースを自動検知できる。よく使うルールを挙げる。

・s3-bucket-server-side-encryption-enabled: SSEが有効でないS3バケットを検知
・encrypted-volumes: 暗号化されていないEBSボリュームを検知
・rds-storage-encrypted: 暗号化が無効なRDSインスタンスを検知
・dynamodb-table-encrypted-at-rest: DynamoDBテーブルのCMK暗号化を確認

2. SCPで暗号化なしリソース作成を組織全体で禁止する

AWS Organizationsを使ったマルチアカウント環境では、SCPを使って暗号化なしのリソース作成を組織レベルで強制的にブロックできる。


# 想定例: S3への非暗号化PUTを拒否するSCPのポリシー例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": ["AES256", "aws:kms"]
        }
      }
    }
  ]
}

SCPの詳細な設計パターンについては、AWS SCP（サービスコントロールポリシー）実践設計入門を参照してほしい。

よくあるつまずきと設計のポイント

1. CMKを使うとコストが増える

KMSのCMKは月額$1/キーに加え、APIコール（GenerateDataKey、Decryptなど）ごとに$0.03/10,000コールの料金がかかる（2026年10月時点）。S3の大量オブジェクト、Lambda関数の高頻度実行、SQSのメッセージ処理など、APIコール数が増えやすいサービスでは事前にコスト試算しておくとよい。一般的な使い方ではKMSのコストはサービス全体の数%程度に収まることが多いが、処理量によっては想定外の金額になることもある。

2. クロスアカウントでKMS CMKを使う場合はキーポリシーが必要

アカウントAのCMKでアカウントBのリソース（S3等）を暗号化する場合、CMKのキーポリシーにアカウントBのプリンシパルを許可する記述が必要だ。IAMポリシーだけでは不十分で、忘れがちなポイントだ。エラーメッセージが「Access Denied for KMS」と出た場合はまずキーポリシーを確認するとよい。

3. EFS・ElastiCache・MSKも作成後に暗号化変更不可

EBSやRDSと同様に、EFS・ElastiCache・MSKも作成後に暗号化の有効・無効を変更できないサービスが多い。IaCテンプレートのデフォルトとして暗号化有効化を組み込んでおくことで、設定漏れのリスクを下げられる。

4. 「デフォルト暗号化」の落とし穴：どのキーで暗号化されているか把握できない

DynamoDBのように「常時暗号化」されているサービスは便利だが、デフォルトではAWSが管理する所有キー（AWS Owned Key）が使われ、CloudTrailでのキー使用ログが記録されない。コンプライアンス要件でキー使用ログが必要な場合は明示的にCMKへ変更する必要がある。「暗号化されている」だけでは要件を満たせないケースがある点に注意しよう。

5. Secrets ManagerのシークレットもKMSが必要

APIキーやデータベースパスワードを管理するAWS Secrets Managerも、デフォルトではAWSマネージドキーで暗号化される。より厳格なキー管理が必要な場合はCMKに変更できる。詳細はAWS Secrets Manager入門を参照してほしい。

本記事のまとめ

AWSの暗号化設計は「保存時」と「転送時」の2軸を押さえ、サービスごとの設定タイミング（作成時のみ変更可能かどうか）を理解しておくことが重要だ。

確認ポイント	推奨設定
S3バケット	SSE-KMS（CMK）＋バケットポリシーで非暗号化PUT拒否
EBSボリューム	アカウントデフォルト暗号化を有効化（CMK推奨）
RDS/Aurora	作成時にCMK暗号化を有効化（後から変更不可）
DynamoDB	デフォルトはAWS所有キー。監査ログが必要ならCMKへ変更
SQS/SNS	SSE-KMSを有効化（作成後に変更可能）
外部通信	TLS 1.2以上を強制（ALBセキュリティポリシー設定）
内部API通信	重要サービス間はmTLS（ACM Private CA）
設定の検知・強制	AWS Configルール＋SCPの組み合わせ
鍵管理の監査証跡	CloudTrailでKMS APIコールを記録（CMK必須）