Amazon EFSでのCMKによる暗号化について

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか?」 というリスクの解説から、「どうやって直すのか?」 という具体的な修復手順(コンソール、AWS CLI、Terraformなど)まで、分かりやすく解説します。
今回は、Amazon EFS (Elastic File System) のデータがAWS所有キーで暗号化されており、カスタマー管理キー (CMK) 以上のレベルで暗号化されていない状態について、そのリスクと対策を解説します。

リスク
Amazon EFSは、AWSクラウドサービスおよびオンプレミスリソースで使用できる、シンプルでスケーラブルなファイルストレージを提供します。EFSはデフォルトで保管時の暗号化をサポートしていますが、その際にAWSが所有するキー(AWS owned key)が使用されます。このデフォルト設定のまま運用している場合、以下のようなセキュリティおよびコンプライアンス上のリスクが発生します。
- 鍵管理の制御不足: AWS所有キーはAWSによって管理され、ユーザーがそのライフサイクル(作成、ローテーション、無効化、削除)やアクセス制御を詳細に制御することはできません。高度なセキュリティ要件を持つ組織では、鍵の生成、保管、利用、ローテーションなどを自身で完全に管理できるカスタマー管理キー (CMK) またはそれ以上のセキュリティレベルのキーの利用が不可欠となります。
- 内部脅威への脆弱性: AWS所有キーを使用している場合、万が一AWS内部の不正行為が発生した場合に、データが不正にアクセスされるリスクが皆無とは言えません(非常に低いリスクですが)。CMKやCloudHSMキーを使用することで、鍵へのアクセス権限を完全に分離し、内部脅威に対する防御を強化できます。
- 鍵の使用状況の可視性不足: AWS所有キーの使用状況はKMSのログには記録されないため、誰がいつデータにアクセスし、暗号化/復号化が行われたかといった詳細な監査証跡を追跡することが困難です。CMKを使用すると、KMSのAPI呼び出しがCloudTrailに記録され、鍵の使用状況を完全に可視化できます。
対策
EFSのデータをKMSのカスタマー管理キー (CMK) またはCloudHSMキーで暗号化することは、上記のすべてのリスクを軽減し、セキュリティ体制を大幅に強化するための重要なベストプラクティスです。
- KMS カスタマー管理キー (CMK) の使用: EFSファイルシステムを作成する際に、KMSで作成したカスタマー管理キーを指定します。CMKを使用することで、鍵の生成、ローテーション、無効化、削除、およびアクセス権限(キーポリシー)をユーザー自身が完全に制御できるようになります。これは、最も一般的なセキュリティ強化策です。
- CloudHSMキーの使用 (最高レベルのセキュリティ): FIPS 140-2 Level 3認証のハードウェアセキュリティモジュール (HSM) に保管されたキーを使用したい場合は、AWS CloudHSMと統合できます。これは、最も厳格なセキュリティおよびコンプライアンス要件を持つ組織に適しており、鍵がAWSのデータセンター内でFIPS検証済みのハードウェアに安全に保管されることを保証します。
- 最小特権の原則に基づくキーポリシー: CMKのキーポリシーを設定する際には、EFSサービスがファイルシステムの暗号化および復号化に必要な最小限の権限のみを付与するようにします。具体的には、EFSサービスプリンシパル(
elasticfilesystem.amazonaws.com
)にkms:Encrypt
,kms:Decrypt
,kms:ReEncrypt*
,kms:GenerateDataKey*
,kms:DescribeKey
などの権限を許可します。 - 新規ファイルシステムでの有効化: EFSの暗号化設定は、ファイルシステム作成時のみに指定できます。既存の暗号化されていない、またはAWS所有キーで暗号化されたファイルシステムをCMKで暗号化するには、新しいファイルシステムを作成し、データを移行する必要があります。
- AWS CloudTrailとの統合: CMKまたはCloudHSMキーの使用状況はAWS CloudTrailに記録されます。これにより、誰がいつ暗号化/復号化操作を行ったかを監査し、セキュリティイベントを監視できます。
修復方法
EFSファイルシステムの暗号化をKMSカスタマー管理キー(CMK)で有効にする方法は、AWSコンソールまたはTerraformで行えます。CloudHSMキーを使用する場合は、先にAWS CloudHSMクラスターとそれに統合されたKMSキーを作成する必要があります。
AWSコンソールでの修復手順
AWSコンソールを使用して、EFSファイルシステムの作成時にKMS CMKで暗号化を有効にします。
前提:
- EFSファイルシステムを暗号化するためのAWS KMS カスタマー管理キー (CMK) が既に存在すること。
- CMKのキーポリシーには、EFSサービス (
elasticfilesystem.amazonaws.com
) がキーを使用するための適切な権限(kms:Encrypt
,kms:Decrypt
など)が付与されている必要があります。
- CMKのキーポリシーには、EFSサービス (
- EFSサービスへ移動: AWSコンソールにログインし、Amazon Elastic File System (EFS) サービスを開きます。
- ファイルシステムの作成: 「ファイルシステムの作成」をクリックします。
- ステップ1: ファイルシステムの作成設定:
- 「カスタマイズ」を選択します。(「簡単作成」ではCMKを選択できません)暗号化セクションで、「暗号化を有効にする」にチェックが入っていることを確認します。「カスタマー管理のキー (CMK) を選択する」を選択します。ドロップダウンメニューから、使用したい既存のKMS CMKを選択します。
- もし適切なCMKがリストに表示されない場合は、正しいIAM権限があるか、またはCMKが作成されているか確認してください。
- 「カスタマイズ」を選択します。(「簡単作成」ではCMKを選択できません)暗号化セクションで、「暗号化を有効にする」にチェックが入っていることを確認します。「カスタマー管理のキー (CMK) を選択する」を選択します。ドロップダウンメニューから、使用したい既存のKMS CMKを選択します。

- ステップ2: ネットワークアクセスを設定:
- EFSをアタッチするVPCとサブネットを選択し、セキュリティグループを設定します。
- ステップ3: ファイルシステムポリシーを設定:
- 必要に応じてファイルシステムポリシーを設定します。
- ステップ4: 確認と作成:
- 設定内容を確認し、「作成」をクリックしてファイルシステムをプロビジョニングします。
これで、EFSファイルシステムに保存されるデータは、指定したKMS CMKを使用して保管時に暗号化されるようになります。既存のファイルシステムを変更することはできないため、既存のファイルシステムをCMKで暗号化したい場合は、新しいファイルシステムにデータを移行する必要があります。
Terraformでの修復手順
TerraformでEFSファイルシステムの暗号化をKMSカスタマー管理キー(CMK)で有効にするには、aws_efs_file_system
リソースの kms_key_id
パラメータを設定します。
# (例) EFSファイルシステム暗号化用のKMSカスタマー管理キー (CMK)
resource "aws_kms_key" "efs_cmk" {
description = "KMS key for EFS encryption"
deletion_window_in_days = 10 # キーの削除をスケジュールするまでの日数
enable_key_rotation = true # キーの自動ローテーションを有効にする
policy = jsonencode({
Version = "2012-10-17",
Statement = [
{
Sid = "Enable IAM User Permissions",
Effect = "Allow",
Principal = {
AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root" # アカウントルートユーザーにアクセス許可
},
Action = "kms:*",
Resource = "*"
},
{
Sid = "Allow EFS Service to use the key"
Effect = "Allow",
Principal = {
Service = "elasticfilesystem.amazonaws.com"
},
Action = [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
Resource = "*"
}
]
})
tags = {
Name = "EFS_CMK"
}
}
# EFSファイルシステム
resource "aws_efs_file_system" "my_encrypted_efs" {
creation_token = "my-secure-efs-filesystem" # 一意のトークン
performance_mode = "generalPurpose"
throughput_mode = "bursting"
# 暗号化を有効にし、KMS CMKを指定
encrypted = true
kms_key_id = aws_kms_key.efs_cmk.arn
tags = {
Name = "MySecureEFS"
}
}
# (例) EFSマウントターゲット (各アベイラビリティゾーンに設定)
resource "aws_efs_mount_target" "mount_target_az1" {
file_system_id = aws_efs_file_system.my_encrypted_efs.id
subnet_id = "subnet-0abcdef1234567890" # あなたのサブネットIDに置き換え (AZ1)
security_groups = ["sg-0fedcba9876543210"] # あなたのセキュリティグループIDに置き換え
}
resource "aws_efs_mount_target" "mount_target_az2" {
file_system_id = aws_efs_file_system.my_encrypted_efs.id
subnet_id = "subnet-0abcdefedcba98765" # あなたのサブネットIDに置き換え (AZ2)
security_groups = ["sg-0fedcba9876543210"] # あなたのセキュリティグループIDに置き換え
}
# 現在のAWSアカウント情報を取得
data "aws_caller_identity" "current" {}
上記のTerraformコードでは、aws_efs_file_system
リソースを使用してEFSファイルシステムを定義し、暗号化を設定しています。
encrypted = true
: 暗号化を有効にします。kms_key_id = aws_kms_key.efs_cmk.arn
: 暗号化に使用するKMSカスタマー管理キーのARNを指定します。このキーは事前にaws_kms_key
リソースで定義しておく必要があります。- KMSキーポリシーでは、EFSサービスプリンシパル (
elasticfilesystem.amazonaws.com
) に、EFSファイルシステムがキーを使用してデータを暗号化・復号化するために必要な権限(kms:Encrypt
,kms:Decrypt
,kms:ReEncrypt*
,kms:GenerateDataKey*
,kms:DescribeKey
など)を付与することが重要です。
my-secure-efs-filesystem
や subnet-0abcdef1234567890
、sg-0fedcba9876543210
などのプレースホルダーは、実際の環境に合わせて修正してください。
最後に
この記事では、EFSのデータをKMSカスタマー管理キー(CMK)以上のレベルで暗号化することの重要性について解説しました。デフォルトのAWS所有キーによる暗号化も有効ですが、CMKやCloudHSMキーを使用することで、鍵管理の制御を強化し、より厳格なコンプライアンス要件を満たし、内部脅威に対する防御を強化できます。 貴社のEFSファイルシステムは、カスタマー管理キー以上のレベルで暗号化されていますか?この機会にぜひ設定を確認・強化してみてください。 こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。
最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。