AWSにはSecurity Hubというコンプライアンスチェックをしてくれるサービスがあります。
「AWS基礎セキュリティのベストプラクティス」のチェック項目の1つに 「CloudTrailでは、保管時の暗号化を有効にします」というのがあります。
しかし、私のAWSアカウントでは失敗となっていました。
コンプライアンスチェックのスコアを上げたい、そんな気持ちから暗号化設定をしてみました。
また、その設定をする意味についても考えてみました、
1.CloudTrailのSSE-KMS暗号化設定をする
まずは現状把握
CloudTrailの証跡の設定を確認します。
確かに「ログファイルのSSE-KMS暗号化」が無効になってました。
あっさりとSSE-KMSに変更
後から暗号化設定の変更をできるんだろうか？と疑問に思いましたが、編集ボタンからあっさり変更できました。
今回はKMSキーを新規作成しました。
CloudTrailの設定をみると、ほんとにあっさり変更できてますね。
念のため、KMSの画面で確認すると、新しいCMK（カスタマー管理型のキー）ができていました。
ログも暗号化できたし、Security Hubのスコアも上がった
変更後に作成されたS3オブジェクトをみると、暗号化がAWS-KMSとなっています。 期待通りですね。
Security Hubのコンプライアンスチェックでも成功となりました。
2.CloudTrailはデフォルトで暗号化されている
CloudTrailの証跡を暗号化する設定をしてきましたが、実はデフォルトでも暗号化されてS3バケットに保存されます。
なんのこっちゃですね。
デフォルトではSSE-KMSではなく、SSE-S3という方式で暗号化されます。
SSE-KMSへの変更前に作成されたオブジェクトをみると、AES-256（SSE-S3のこと）という表記で暗号化されているのがわかります。
AWS CloudTrail を使用すると、AWS API 呼び出しや AWS アカウントの他のアクティビティを記録し、記録された情報を、選択した Amazon Simple Storage Service (Amazon S3) バケット内のログファイルに保存できます。デフォルトでは、CloudTrail によって S3 バケットに配信されるログファイルは、Amazon S3– で管理された暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用して暗号化されます。ただし、AWS KMS– 管理キーによるサーバー側の暗号化 (SSE-KMS) の使用を選択することもできます。
AWS CloudTrail で AWS KMS を使用する方法
デフォルトでは、SSE-S3で暗号化されると書いてます。
機密性の高い CloudTrail ログファイルのセキュリティを強化するには、保管時の暗号化用の CloudTrail ログファイルに AWS KMS マネージドキー (SSE-KMS) を使用してサーバー側の暗号化を使用する必要があります。デフォルトでは、CloudTrail によってバケットに配信されるログファイルは、Amazon で Amazon S3 管理された暗号化キーによるサーバー側の暗号化 (SSE-S3) によって暗号化されます。
AWS の基本的なセキュリティのベストプラクティスコントロール
Security Hubの説明では、「デフォルトでSSE-S3だけど、SSE-KMSにしてね」的なことが書いてあります。
3.CloudTrailのSSE-KMS暗号化のメリット
デフォルトでも暗号化されているのに、わざわざSSE-KMSに変更した時の利点はなんでしょうか？
このアプローチには以下の利点があります。 ・ CMK 暗号化キーを自分で作成して管理することができます。 ・ 単一の CMK を使用して、すべてのリージョンの複数のアカウントのログファイルを暗号化および復号できます。 ・ CloudTrail ログファイルを暗号化および復号するためにキーを使用できるユーザーを制御できます。要件に応じて、組織のユーザーにキーのアクセス権限を割り当てることができます。 ・ セキュリティが強化されました。この機能では、ログファイルを読み取るために、次のアクセス許可が必要です。 ・ ユーザーには、ログファイルを含むバケットに対する S3 の読み取り権限が必要です。 ・ ユーザーには、CMK ポリシーによるアクセス許可の復号化を許可するポリシーまたは役割も適用する必要があります。 ・ S3 では、CMK の使用を許可されたユーザーからの要求に対してログファイルが自動的に復号されるため、CloudTrail ログファイルの SSE-KMS 暗号化は、CloudTrail ログデータを読み取るアプリケーションとの下位互換性があります。
AWS KMS で管理されたキー (SSE-KMS) による CloudTrail ログファイルの暗号化
いくつかの利点が書いてありました。 これらに魅力を感じるのであれば、SSE-KMS暗号化するといいと思いますが、必ずしもすべてのAWSユーザーに必要ではない気もします。
CMK 暗号化キーを自分で作成して管理<
自分で作成した鍵をインポートしたいとか、定期的に鍵をローテーションしたいといったことを含むのだと思います。
企業によっては、セキュリティ監査要件に記載があるかもしれません。
CloudTrail ログファイルを暗号化および復号するためにキーを使用できるユーザーを制御
SSE-S3のキーは、AWSアカウント内のどのユーザーからでもアクセスできるという決め打ちの設定になっています。
SSE-KMSのキーなら、キーポリシーでいろいろと権限制御が可能です。
マネージメントコンソールでCloudTrailの暗号化設定の際に作成されたCMKのキーポリシーは以下のようになっていました。
{ "Version": "2012-10-17", "Id": "Key policy created by CloudTrail", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:sts::123456789012:assumed-role/Role1/User1", "arn:aws:iam::123456789012:root" ] }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow CloudTrail to encrypt logs", "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "kms:GenerateDataKey*", "Resource": "*", "Condition": { "StringLike": { "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:123456789012:trail/*" } } }, { "Sid": "Allow CloudTrail to describe key", "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "kms:DescribeKey", "Resource": "*" }, { "Sid": "Allow principals in the account to decrypt log files", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "kms:Decrypt", "kms:ReEncryptFrom" ], "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": "123456789012" }, "StringLike": { "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:123456789012:trail/*" } } }, { "Sid": "Allow alias creation during setup", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": "kms:CreateAlias", "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": "123456789012", "kms:ViaService": "ec2.ap-northeast-1.amazonaws.com" } } }, { "Sid": "Enable cross account log decryption", "Effect": "Allow", "Principal": { "AWS": "*" }, "Action": [ "kms:Decrypt", "kms:ReEncryptFrom" ], "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": "123456789012" }, "StringLike": { "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:123456789012:trail/*" } } } ] }
このポリシーだと、SSE-S3と同様にアカウント内の誰でもキーにアクセスし、復号に用いることができます。
ある意味では、そのまま使えるので親切なポリシーとは思います。
ただし、特定のIAMユーザーにのみ復号化を許可する設定にしたい場合は、"kms:Decrypt"を許可するPrincipalを限定する必要があります。
例えば、Principalを"AWS": "*"から、管理者のIAMユーザーに変更します。
そうすれば、その他のIAMユーザーでは復号化できなくなり（＝S3オブジェクトををダウンロードできなくなり）、CloudTrailのログにアクセスできる人を限定できます。
{ "Sid": "Allow principals in the account to decrypt log files", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/user1" }, "Action": [ "kms:Decrypt", "kms:ReEncryptFrom" ], "Resource": "*", "Condition": { "StringEquals": { "kms:CallerAccount": "123456789012" }, "StringLike": { "kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:123456789012:trail/*" } } }
4.CloudTrailのSSE-KMS暗号化のデメリット
明確なデメリットは1つで、コストが発生することです。
AWS KMS– 管理キー (SSE-KMS) によって CloudTrail ログファイルを暗号化すると、CloudTrail がログファイルを S3 バケットに置くたびに、AWS KMS API リクエストが生成されます。通常、CloudTrail は 5 分おきにログファイルを S3 バケットに置くため、リージョンおよび AWS アカウントあたり 1 日に約 288 の AWS KMS API リクエストが生成されます。
AWS CloudTrail で AWS KMS を使用する方法
まとめ
CloudTrailの証跡はデフォルトではSSE-S3で暗号化されますが、それをSSE-KMS暗号化に変更するのは簡単にできます。
しかし、必須というわけではありません。
メリット、デメリットを考えて決定していただければと思います。
渡辺 信秀(記事一覧)
2017年入社 / 地味な内容を丁寧に書きたい
