AWSの暗号化はどう設計する？KMS・暗号鍵の選び方と実装の考え方

アマゾンウェブサービス（AWS）では、Amazon S3やAmazon EBS、Amazon RDSなど、多くのサービスでデータを暗号化できます。設計では、保護対象となるデータを洗い出し、保存中・転送中それぞれに適した方式と、暗号鍵の管理方法を選定します。

AWS KMSを利用する場合は、AWS マネージドキーとカスタマーマネージドキーの違いに加え、権限管理、ローテーション、監査などの要件も考慮します。

この記事では、AWSの暗号化設計で最初に決めることから、AWS KMSと暗号鍵の選び方、Amazon S3・Amazon EBS・Amazon RDSなど主要サービスでの設計、運用時の注意点まで解説します。

AWSの暗号化設計で最初に決めること

AWSの暗号化設計では、最初に保護するデータと求められるセキュリティ要件を明確にします。その後、保存中のデータと転送中のデータに分け、それぞれに適した暗号化方式を検討します。AWSでも、データ分類を行ったうえで、データの状態に応じた暗号化を検討することが推奨されています。

保護するデータとセキュリティ要件を整理する

まず、AWS上で扱うデータを洗い出し、重要度や機密性に応じて分類します。顧客情報や個人情報、認証情報、業務上の機密データなどは、漏えいした場合の影響を踏まえて保護レベルを設定します。

社内のセキュリティポリシーや法令・業界基準、監査要件も踏まえます。暗号鍵を自社で管理するか、利用者をどこまで限定するか、鍵の利用履歴を追跡するかといった条件は、AWS KMSのキー選択や権限設計に影響します。

保存中・転送中のデータで暗号化方式を分ける

暗号化するデータは、大きく「保存中」と「転送中」に分けて考えます。

保存中のデータには、Amazon S3のオブジェクト、Amazon EBSのボリューム、Amazon RDSのデータベースなどがあります。各AWSサービスが提供する暗号化機能やAWS KMSを利用して保護します。

転送中のデータは、ユーザーとAWSサービス間やシステム間を移動するデータです。HTTPSやTLSなどを利用し、通信経路での盗聴や改ざんを防ぎます。

適用する方式や鍵の管理方法は、データの重要度、利用方法、社内の管理要件によって変わります。

AWS KMSと暗号鍵の選び方

AWS KMS（AWS Key Management Service）では、データの暗号化に使用するKMSキーを管理できます。選定時の主な判断軸は、鍵の管理主体と、利用者側で求める制御範囲です。AWS KMSには、AWS 所有のキー、AWS マネージドキー、カスタマーマネージドキーがあります。

AWS 所有のキー・AWS マネージドキー・カスタマーマネージドキーの違い

3つのキーでは、利用者が管理できる範囲が異なります。

AWS 所有のキーはAWS側で管理されるキーで、ユーザー側から確認したり設定を変更したりすることはできません。

AWS マネージドキーは、AWSサービスがユーザーのアカウント内に作成・管理するKMSキーです。たとえばAmazon RDSでは aws/rds が利用されますが、ユーザー側でキーポリシーの変更や削除はできません。

カスタマーマネージドキーはユーザー自身が作成・管理します。キーポリシーやIAMポリシー、Grantによるアクセス制御、有効・無効化、ローテーション、削除などを扱えます。

カスタマーマネージドキーが必要になるケース

カスタマーマネージドキーは、鍵の利用条件を細かく制御したい場合に適しています。たとえば、特定のIAMロールだけに利用を許可する、複数のAWSアカウントで利用する、独自のローテーション方針を適用するといったケースです。

監査や社内規定で、鍵を利用・管理できるユーザーや役割を指定する必要がある場合にも適しています。

ただし、カスタマーマネージドキーではポリシーやライフサイクルも利用者側で管理します。AWSサービスの標準的な暗号化で要件を満たせる範囲と、独自の管理が求められる範囲を分けて選定します。

鍵の権限・ローテーション・ライフサイクルを設計する

カスタマーマネージドキーを利用する場合は、作成後の運用もあらかじめ定めます。

キーポリシーやIAMポリシーを使い、鍵の管理権限と、暗号化・復号に利用する権限を必要な主体に限定します。システムや担当者の役割に応じて、管理者と利用者の権限を分離する方法もあります。

ローテーションでは、組織のセキュリティポリシーや監査要件を踏まえて運用方針を定めます。AWS マネージドキーのキーマテリアルはAWS KMSによって自動的にローテーションされます。対応するカスタマーマネージドキーでは、自動ローテーションやオンデマンドローテーションを利用できます。

無効化や削除の扱いにも注意が必要です。KMSキーを削除すると、そのキーで暗号化したデータを復号できなくなる可能性があります。AWS KMSでは、カスタマーマネージドキーを削除する際に7～30日の待機期間を設定します。

AWSの主要サービスで考える保存データの暗号化

AWSでは、サービスごとに保存データを暗号化する仕組みが用意されています。標準で暗号化される範囲や利用できるKMSキーは異なるため、サービスごとの仕様と自社の管理・監査要件を照らして設定を選びます。

Amazon S3｜SSE-S3とSSE-KMSをどう使い分けるか

Amazon S3では、2023年1月以降、すべての新規オブジェクトが標準でSSE-S3（Amazon S3 マネージドキーによるサーバー側暗号化）によって暗号化されます。現在は、SSE-S3で要件を満たせるか、AWS KMSを利用するSSE-KMSが必要かが主な判断点です。

SSE-KMSでは、KMSキーへのアクセス制御や利用状況の監査が可能です。特定のカスタマーマネージドキーを使用したい場合に利用します。また、SSE-KMSで暗号化したS3オブジェクトを別のAWSアカウントと共有する場合は、カスタマーマネージドキーが必要です。 

SSE-KMSでは、AWS KMSへのAPIリクエストに伴う料金が発生する場合があります。カスタマーマネージドキーを使用する場合は、キー自体の料金も考慮します。大量のオブジェクトを扱う環境では、AWS KMSへのリクエスト数とコストを抑えるS3 Bucket Keysも選択肢になります。 

Amazon EBS｜ボリュームとスナップショットを暗号化する

Amazon EBSでは、AWS KMSを利用してEBSボリュームを暗号化できます。アカウント・リージョン単位でEBS暗号化をデフォルトで有効にすると、新しく作成するEBSボリュームに暗号化が適用されます。

暗号化されたEBSボリュームから作成したスナップショットも暗号化されます。既存の暗号化されていないボリュームは、そのまま暗号化できません。暗号化したスナップショットを経由して、新しい暗号化ボリュームを作成するなどの対応が必要です。

Amazon RDS・Amazon Aurora｜データベースを暗号化する

Amazon RDSでは、AWS KMSを利用してDBインスタンスを暗号化できます。暗号化されたDBインスタンスでは、ストレージに加えて、ログ、バックアップ、リードレプリカ、スナップショットも暗号化の対象になります。暗号化に使用するキーには、AWS マネージドキーまたはカスタマーマネージドキーを選択できます。

Amazon Auroraでは、2026年2月18日以降に新規作成されるDBクラスターが、デフォルトで保存時に暗号化されるようになりました。標準ではAWS 所有のキーが使用され、要件に応じてカスタマーマネージドキーなどを選択できます。それ以前に作成されたクラスターなどは設定が異なる場合があるため、既存環境については現在の暗号化状態を把握してから対応を検討します。

転送中データの暗号化を設計する

保存データに加えて、ユーザーとAWSサービス間、AWSサービス同士でやり取りされるデータも保護します。転送中の暗号化ではTLSを基本とし、インターネット経由の通信だけでなく、要件に応じてAWS環境内部の通信も対象にします。AWS Well-Architected Frameworkでも、安全なTLSプロトコルと暗号スイートの利用が推奨されています。

TLSで通信経路を暗号化する

TLSを利用すると、通信中のデータを暗号化し、盗聴や改ざんのリスクを抑えられます。WebアプリケーションではHTTPSを利用し、Application Load BalancerやAmazon CloudFront、Amazon API GatewayなどでもTLSを前提に通信経路を構成します。

TLSバージョンや暗号スイートも選定します。組織の暗号化ポリシーに合わせて各サービスのセキュリティポリシーを選び、古いSSL/TLSや安全性の低い暗号方式は利用しない構成にします。

アプリケーションとデータベース間など、AWS環境内部で機密性の高いデータを送受信する通信についても、要件に応じてTLSを適用します。

証明書の発行・更新まで運用に含める

TLSで利用する証明書は、発行だけでなく更新まで管理します。AWS Certificate Manager（ACM）を利用すると、SSL/TLS証明書の発行や管理、Elastic Load BalancingやAmazon CloudFrontなど対応するAWSサービスへの配置ができます。

ACMで発行した証明書は、一定の条件を満たせばマネージド更新の対象となります。証明書が対応するAWSサービスで使用されていることや、DNS検証に必要な設定など、マネージド更新の条件を維持します。

有効期限や更新状況を監視し、証明書の失効や更新失敗に対応できる運用フローを用意します。

AWSの暗号化設計で注意したいポイント

暗号化方式を決めた後は、暗号鍵の管理主体や利用権限、監査方法を具体化します。カスタマーマネージドキーを利用する場合は、AWS側に任せる範囲と自社で管理する範囲を明確にします。

カスタマーマネージドキーは管理要件に応じて使い分ける

カスタマーマネージドキーでは、キーポリシーの設定や有効・無効化、ローテーション、削除などをユーザー側で管理できます。独自のアクセス制御が必要な場合や、監査要件に応じて鍵の利用主体を明確にしたい場合に適しています。

AWSサービスの標準的な暗号化で要件を満たせる場合は、AWS マネージドキーなども選択肢です。カスタマーマネージドキーを使う範囲は、必要な制御レベル、監査要件、管理にかかる負荷を踏まえて判断します。

暗号化とアクセス制御を組み合わせる

暗号化だけでは、不適切な権限設定によるデータアクセスは防げません。IAMポリシーやKMSのキーポリシーを組み合わせ、データにアクセスできる主体と、暗号鍵を利用できる主体を制御します。

権限は最小権限の原則に沿って付与します。データへのアクセス権限と復号権限はあわせて管理し、異動やシステム変更に応じて不要な権限を削除します。

詳しくは下記記事をご覧ください。

 >> 最小権限の原則とは？過剰権限のリスクとIAM設計の具体手順

ログ・監査まで含めて運用を設計する

AWS マネージドキーやカスタマーマネージドキーの利用はAWS CloudTrailに記録され、誰がいつ、どのキーを利用したかを監査できます。AWS 所有のキーは、ユーザー側から利用状況を監査できません。 

運用では、ログの確認頻度、異常を検知した場合の対応、不要になったキーの無効化・削除、権限の見直しについてルールを定めます。

AWS CloudTrailを使ったログ設計については、下記記事をご覧ください。

>> AWSセキュリティログ設計ガイド｜AWS CloudTrailを中心に「証跡」と「検知」を分けて考える

まとめ

AWSの暗号化設計では、データの重要度や利用方法、セキュリティ要件を基準に、保存中・転送中それぞれの暗号化方式を選定します。AWS KMSを使う場合も、必要な制御範囲や監査要件に合わせて、AWS マネージドキーとカスタマーマネージドキーを使い分けます。

Amazon S3、Amazon EBS、Amazon RDSなどのサービス仕様に加え、鍵の権限管理、ローテーション、ログ・監査まで含めて、自社で継続できる暗号化運用を設計します。