AWSにあるデータを暗号化する必要があるか？

こんにちは！イーゴリです。

「そもそもクラウド上でデータの暗号化が必要か」と疑問に思っている方がいるかもしれませんので、これについて考えてみたいと思います。

結論

質問：AWSにあるデータを暗号化する必要がありますか。
回答：必要です！
終わりー

結論
責任共有モデル
どんな時に必ずKMS（暗号化）を使うべき？
AWS KMSについての解説
関連記事

責任共有モデル

まずは「何かあったら誰が責任を負うのか」を考えてみましょう。

AWSでは、責任共有モデルという概念があります。このモデルでは、特定の責任をAWSとお客様がどのように分担するかが示されています。

aws.amazon.com

お客様は、データの管理 (暗号化オプションを含む)、アセットの分類、IAM ツールでの適切な権限の適用について責任を負います。

AWSのデータセンターを守るのはAWS社の責任ですが、データの管理(暗号化オプションを含む)はお客様の責任です。したがって、データを暗号化するかどうかはお客様の判断次第ですが、多くの場合、暗号化することをお勧めします。

削除された EBS ボリュームで使用される物理ブロックストレージは、新しいボリュームに割り当てられる前に、ゼロまたは暗号的に擬似ランダムデータで上書きされます。機密データを扱っている場合は、手動によるデータの暗号化や、Amazon EBS 暗号化 で保護されているボリュームへのデータの格納を検討してください。詳細については、「Amazon EBS 暗号化」を参照してください。 docs.aws.amazon.com

個人的には、セキュリティ、コスト、パフォーマンスのバランスが重要だと考えています。例えば、EBSを例にしましょう。

EBSの場合、下記のページを見ると、「同じ IOPS パフォーマンスが期待できます」とのことですので、多層防御を実現するための一つの層として暗号化を有効にしたほうが良いと思います。

暗号化は、すべての EBS ボリュームタイプでサポートされます。暗号化されたボリュームでは、暗号化されていないボリュームと同じ IOPS パフォーマンスが期待できます。遅延に対する影響は最小限に抑えられます。 docs.aws.amazon.com

どんな時に必ずKMS（暗号化）を使うべき？

AWSではAWS Key Management Service (AWS KMS) というサービスがあり、アプリケーションと AWS のサービス全体で暗号キーを作成、管理、制御することができるサービスです。

下記の懸念点や要件がある場合、必ずKMS（暗号化）を使うべきです。

AWS Well-Architected Framework^※1に準拠したい場合、KMS（暗号化）が必要です。

^※1 AWS Well-Architected Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインです。

SEC08-BP02 保管中に暗号化を適用する

データを保存する唯一の方法は、暗号化を使用することだということを確実にする必要があります。AWS Key Management Service (AWS KMS) は、保管中のすべてのデータをより簡単に暗号化できるように、多数の AWS のサービスとシームレスに統合します。

省略

このベストプラクティスを活用しない場合のリスクレベル: 高

docs.aws.amazon.com

会社のコンプライアンスに保管中のデータを暗号化する要件がある場合、KMS（暗号化）が必要です。
AWSのデータセンターに対して物理的な侵害が発生しても攻撃者がアクセスできないようにするため、KMS（暗号化）が必要です。
機密データを扱っている場合、KMS（暗号化）が必要です。

AWS KMSについての解説

KMSを使わない場合（非暗号化）

EC2のEBSボリュームを例にします。

EBS←→EC2の通信とEC2のEBSボリュームのデータは、ともに非暗号の状態になります。

どんな時にEBSに不正アクセスできてしまう？

物理的なアクセス：AWSデータセンターに入ってサーバーに物理的に侵入する
設定ミス：誤ったアクセス権限設定により、攻撃者がデータにアクセスできる
AWSアカウントへの不正アクセス：組織内部の攻撃者がAWSアカウントにアクセスする

AWS マネージド型キーを使う場合

AWSが管理するキーで、AWSサービスによってデフォルトで使用されるキーです。これらのキーは自動管理および更新(1年に1度)され、ユーザーの負担が少なく、カスタマイズ性は低いです。単一のリージョンで作成されます。

「AWS マネージド型キー」は単体のリージョンでしか使えないため、別のリージョンでEBSなどを使えないと思っている方がいるかもしれませんが、そんなことはありません。下記の記事に詳しく記載されていますが、スナップショットを別リージョンにコピーする時に、別のキー/キータイプでもリージョン間でコピーできますので、別のリージョンの鍵を使えばよいです。

blog.serverworks.co.jp

カスタマー管理型のキーを使う場合

カスタマー管理型のキーはユーザーが管理するキーで、ユーザーが作成し、管理し、必要に応じてカスタマイズ可能です。完全な制御、アクセスポリシーやキーのローテーションの期間（90日〜7年）を設定できますが、AWS マネージド型キーより管理に手間がかかります。

また、複数リージョンにカスタマー管理型のキーをコピーできます。但し、各リージョンに別々のキーのコピーを作成して管理する必要があります。

AWS マネージド型キー/カスタマー管理型のキーの比較表

テキストが多かったので、簡単にまとめられるようにAWS マネージド型キー/カスタマー管理型のキーの比較表を作成しましたので、ご参考ください（EBSだけではなく、全体的な比較表になります）。

特徴	AWS マネージド型キー (AWS Managed Keys)	カスタマー管理型キー (Customer Managed Keys)
管理者の負担	低	高
キーの作成と削除	AWS が自動管理	ユーザーが手動で作成・削除
キーのローテーション	自動 (毎年) ^※2	自動/手動、自動更新期間を90日〜7年に設定可能) ^※3
キーのアクセス制御	AWS が管理	ユーザーが詳細に制御可能
エイリアスの使用	サポートされていない	サポートされている
クロスアカウントの使用	制限あり	柔軟なアクセス制御が可能
キーポリシーのカスタマイズ	不可	可能
アプリ側への導入難度^※4	◎ 何も行う必要なし	▲ 場合によってAWS KMS CMKを使えるように必要なアプリを変更しないといけない / IAM権限の見直しが必要
キーの削除	不可	可能 (削除設定後の可能な削除期間：7~30日)

料金について詳しくは下記の記事をご参考ください。 aws.amazon.com

^※2 注記 2022 年 5 月、はのローテーションスケジュールを 3 年ごと (約 1,095 日) AWS マネージドキーから毎年 (約 365 日) AWS KMS に変更しました。

新しい AWS マネージドキーは、作成されてから 1 年後に自動的にローテーションされ、その後はほぼ毎年ローテーションされます。

既存の AWS マネージドキーは、最新のローテーションから 1 年後に自動的にローテーションされ、その後は毎年ローテーションされます。

docs.aws.amazon.com

^※3 2024/07時点の情報 aws.amazon.com

^※4 AWS マネージド型キー (AWS Managed Keys)はAWSによって管理され、アプリケーション側には追加の設定が不要です。そのため、これらのキーをアプリケーションに導入するための変更は必要ありません。

一方、カスタマー管理型キー (Customer Managed Keys)を使用するには、アプリケーションがAWS KMS CMKを使用するように設定する必要があります。これには、KMS APIと連携するためのアプリケーションコードの変更や、キーの管理が含まれる場合があります。

なお、AWS マネージド型キー (AWS Managed Keys)の場合は、IAMの変更が不要ですが、カスタマー管理型キー (Customer Managed Keys)の場合は、IAMの権限変更が必要です。

多くの AWS のサービスでは AWS KMS keys 、を使用して管理するリソースを保護します。あるサービスで AWS 所有のキー または AWS マネージドキー が使用される場合、そのサービスではこれらの KMS キーのキーポリシーが確立されて管理されます。

ただし、お客様が AWS のサービスでカスタマーマネージドキーを使用する場合は、ご自身でキーポリシーを設定して管理します。ユーザーに代わってリソースを保護するのに必要な最小限のアクセス許可が、そのキーポリシーによってサービスに付与される必要があります。最小特権の原則 (サービスで必要なアクセス許可のみを付与) に従うことをお勧めします。どのアクセス許可がそのサービスで必要かを把握し、AWS グローバル条件キーおよび AWS KMS 条件キーを使用してアクセス許可を絞り込むことで、これを効果的に行うことができます。 docs.aws.amazon.com

他の参考記事：

blog.serverworks.co.jp