启用特定Amazon服务的日志记录 - Amazon CloudWatch Logs
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

启用特定Amazon服务的日志记录

虽然许多服务仅将日志发布到 CloudWatch Logs,但有些Amazon服务可以将日志直接发布到 Amazon Simple Storage Service 或 Amazon Kinesis Data Firehose。如果您对日志的主要需求是在其中一种服务中存储或处理日志,那么您可以轻松地让生成日志的服务将它们直接发送到 Amazon S3 或 Kinesis Data Firehose,而无需额外设置。

即使日志直接发布到 Amazon S3 或 Kinesis Data Firehose,仍会产生费用。有关更多信息,请参阅 Amazon CloudWatch Pricing(Amazon CloudWatch 定价)Logs(日志)选项卡上的 Vended Logs(已出售日志)

权限

部分Amazon服务使用通用基础设施将其日志发送到 CloudWatch Logs、Amazon S3 或 Kinesis Data Firehose。要启用下表中列出的Amazon服务,将其日志发送到前述目标,您必须以具有特定权限的用户身份登录。

此外,必须将权限授予Amazon以启用日志发送。Amazon可以在设置日志时自动创建这些权限,您也可以在设置日志记录之前自行创建这些权限。

如果您或您企业中的某个人在首次设置日志发送时选择让Amazon自动设置必要的权限和资源策略,那么设置日志发送的用户必须具有一定的权限,如本节后面所述。或者,您可以自行创建资源策略,这样设置日志发送的用户就不需要那么多权限。

下表汇总了适用本节中信息的日志类型及日志目标。

以下各部分提供了每个目标的更多详细信息。

发送到 CloudWatch Logs 的日志

重要

当您将以下列表中的日志类型设置为发送到 CloudWatch Logs 时,Amazon会创建或更改与接收日志的日志组关联的资源策略(如需要)。继续阅读本节,查看详细信息。

当前一部分的表中列出的日志类型发送到 CloudWatch Logs 时,本部分适用:

用户权限

若要能够设置首次将这些类型日志中的任一种日志发送到 CloudWatch Logs,您必须登录到具有以下权限的账户。

  • logs:CreateLogDelivery

  • logs:PutResourcePolicy

  • logs:DescribeResourcePolicies

  • logs:DescribeLogGroups

如果其中任何一种类型的日志已被发送到 CloudWatch Logs 中的日志组,要设置将其中另一种日志也发送到同一日志组,您只需要 logs:CreateLogDelivery 权限。

日志组和资源策略

接收日志的日志组必须具有包含特定权限的资源策略。如果日志组当前没有资源策略,而且设置日志记录的用户对日志组具有 logs:PutResourcePolicylogs:DescribeResourcePolicieslogs:DescribeLogGroups 权限,那么当您开始将日志发送到 CloudWatch Logs 日志时,Amazon会自动为其创建以下策略。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AWSLogDeliveryWrite20150319", "Effect": "Allow", "Principal": { "Service": [ "delivery.logs.amazonaws.com" ] }, "Action": [ "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:us-east-1:0123456789:log-group:my-log-group:log-stream:*" ], "Condition": { "StringEquals": { "aws:SourceAccount": ["0123456789"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-1:0123456789:*"] } } } ] }

如果日志组具有资源策略,但该策略不包含上一个策略中所示的语句,并且设置日志记录的用户对日志组具有 logs:PutResourcePolicylogs:DescribeResourcePolicieslogs:DescribeLogGroups 权限,则该语句将附加到日志组的资源策略中。

日志组资源策略大小限制注意事项

这些服务必须在资源策略中列出它们向其发送日志的每个日志组,并且 CloudWatch Logs 资源策略不得超过 5120 个字符。将日志发送到大量日志组的服务可能会遇到此限制。

为了缓解这种情况,CloudWatch Logs 监视该服务使用的资源策略的大小,并在检测到某个策略接近 5120 个字符的大小限制时,CloudWatch Logs 将在该服务的资源策略中自动启用 /aws/vendedlogs/*。之后,您可以开始将名称以 /aws/vendedlogs/ 开头的日志组作为这些服务所发送的日志的目标。

发送到 Amazon S3 的日志

重要

当您将以下列表中的日志类型设置为发送到 Amazon S3 时,Amazon会创建或更改与接收日志的 S3 存储桶关联的资源策略(如需要)。继续阅读本节,查看详细信息。

当以下类型的日志发送到 Amazon S3 时,本节适用:

  • CloudFront 访问日志和流式访问日志。CloudFront 使用的权限模型与此列表中其他服务的权限模式不同。有关更多信息,请参阅配置标准日志记录和访问日志文件所需的权限

  • Amazon EC2 Spot 实例数据源

  • Amazon Global Accelerator 流日志

  • Amazon Managed Streaming for Apache Kafka 代理日志

  • Network Load Balancer 访问日志

  • Amazon Network Firewall 日志

  • Amazon Virtual Private Cloud 流日志

直接发布到 Amazon S3 的日志将发布到您指定的现有存储桶。每 5 分钟将在指定的存储桶中创建一个或多个日志文件。

当您首次将日志发送到 Amazon S3 存储桶时,发送日志的服务会记录存储桶的拥有者,以确保日志仅发送到属于该账户的存储桶。因此,要更改 Amazon S3 存储桶拥有者,您必须在原始服务中重新创建或更新日志订阅。

用户权限

若要能够设置首次将这些类型日志中的任一种日志发送到 Amazon S3,您必须登录具有以下权限的账户。

  • logs:CreateLogDelivery

  • S3:GetBucketPolicy

  • S3:PutBucketPolicy

如果其中任何一种类型的日志已被发送到 Amazon S3 存储桶,要设置将其中另一种日志也发送到同一存储桶,您只需要 logs:CreateLogDelivery 权限。

S3 存储桶资源策略

接收日志的 S3 存储桶必须具有包含特定权限的资源策略。如果存储桶当前没有资源策略,而且设置日志记录的用户对存储桶具有 S3:GetBucketPolicyS3:PutBucketPolicy 权限,那么当您开始将日志发送到 Amazon S3 时,Amazon会自动为其创建以下策略。

{ "Version": "2012-10-17", "Id": "AWSLogDeliveryWrite20150319", "Statement": [ { "Sid": "AWSLogDeliveryAclCheck", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::my-bucket", "Condition": { "StringEquals": { "aws:SourceAccount": ["0123456789"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-1:0123456789:*"] } } }, { "Sid": "AWSLogDeliveryWrite", "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::my-bucket/AWSLogs/account-ID/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control", "aws:SourceAccount": ["0123456789"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-1:0123456789:*"] } } } ] }

在之前的策略中,对于 aws:SourceAccount,请指定将日志传送到此存储桶的账户 ID 列表。对于 aws:SourceArn,请按 arn:aws:logs:source-region:source-account-id:* 格式指定生成日志的资源 ARN 列表。

如果存储桶具有资源策略,但该策略不包含上一个策略中所示的语句,并且设置日志记录的用户对存储桶具有 S3:GetBucketPolicyS3:PutBucketPolicy 权限,则该语句将附加到存储桶的资源策略中。

注意

某些情况下,如果未向 delivery.logs.amazonaws.com 授予 s3:ListBucket 权限,可能会在 Amazon CloudTrail 中看到 AccessDenied 错误。为了避免 CloudTrail 日志中出现此类错误,必须向 delivery.logs.amazonaws.com 授予 s3:ListBucket 权限且必须包含与在上述存储桶策略中设置的 s3:GetBucketAcl 权限一起显示的 Condition 参数。为方便起见,可以直接将 AWSLogDeliveryAclCheck 更新为 “Action”: [“s3:GetBucketAcl”, “s3:ListBucket”],而不是创建一个新的 Statement

Amazon S3 存储桶服务器端加密

您可以通过启用 Amazon S3 托管式密钥 (SSE-S3) 的服务器端加密或 Amazon Key Management Service 中存储 Amazon KMS 密钥 (SSE-KMS) 的服务器端加密来保护 Amazon S3 存储桶中的数据。有关更多信息,请参阅使用服务器端加密保护数据

如果选择 SSE-S3,则不需要额外的配置。Amazon S3 处理加密密钥。

警告

如果选择 SSE-KMS,则必须使用客户托管式密钥,因为此场景不支持使用 Amazon 托管式密钥。如果您使用 Amazon 托管密钥设置加密,则会以不可读取的格式提供日志。

当您使用客户托管式 Amazon KMS 密钥时,您可以在启用存储桶加密时指定客户托管式密钥的Amazon Resource Name (ARN)。您必须将以下内容添加到客户托管式密钥的密钥策略(不是 S3 存储桶的存储桶策略)中,以便日志传输账户可以写入 S3 存储桶。

如果选择 SSE-KMS,则必须使用客户托管式密钥,因为此场景不支持使用 Amazon 托管式密钥。当您使用客户托管式 Amazon KMS 密钥时,您可以在启用存储桶加密时指定客户托管式密钥的Amazon Resource Name (ARN)。您必须将以下内容添加到客户托管式密钥的密钥策略(不是 S3 存储桶的存储桶策略)中,以便日志传输账户可以写入 S3 存储桶。

{ "Sid": "Allow Logs Delivery to use the key", "Effect": "Allow", "Principal": { "Service": [ "delivery.logs.amazonaws.com" ] }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": ["0123456789"] }, "ArnLike": { "aws:SourceArn": ["arn:aws:logs:us-east-1:0123456789:*"] } } }

对于 aws:SourceAccount,请指定将日志传送到此存储桶的账户 ID 列表。对于 aws:SourceArn,请按 arn:aws:logs:source-region:source-account-id:* 格式指定生成日志的资源 ARN 列表。

发送到 Kinesis Data Firehose 的日志

当前一部分的表中列出的日志类型发送到 Kinesis Data Firehose 时,本部分适用:

用户权限

若要能够设置首次将这些类型日志中的任一种日志发送到 Kinesis Data Firehose,您必须登录具有以下权限的账户。

  • logs:CreateLogDelivery

  • firehose:TagDeliveryStream

  • iam:CreateServiceLinkedRole

如果其中任何一种日志已被发送到 Kinesis Data Firehose,要设置将其中另一种日志也发送到 Kinesis Data Firehose,您只需要 logs:CreateLogDeliveryfirehose:TagDeliveryStream 权限。

用于权限的 IAM 角色

由于 Kinesis Data Firehose 不使用资源策略,Amazon将这些日志设置为发送到 Kinesis Data Firehose 时会使用 IAM 角色。Amazon创建名为 AWSServiceRoleForLogDelivery 的服务相关角色。此服务相关角色包括以下权限。

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "firehose:PutRecord", "firehose:PutRecordBatch", "firehose:ListTagsForDeliveryStream" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/LogDeliveryEnabled": "true" } }, "Effect": "Allow" } ] }

此服务相关角色会为将 LogDeliveryEnabled 标签设置为 true 的所有 Kinesis Data Firehose 传输流授予权限。当您设置日志记录时,Amazon会将此标签提供给目标传输流。

此服务相关角色还具有允许 delivery.logs.amazonaws.com 服务委托人来代入所需服务相关角色的信任策略。该信任策略如下所示:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "delivery.logs.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

跨服务混淆代理问题防范

混淆代理问题是一个安全性问题,即不具有操作执行权限的实体可能会迫使具有更高权限的实体执行该操作。在 Amazon 中,跨服务模拟可能会导致混淆代理问题。一个服务(呼叫服务) 调用另一项服务(所谓的服务)时,可能会发生跨服务模拟。可以操纵调用服务,使用其权限以在其他情况下该服务不应有访问权限的方式对另一个客户的资源进行操作。为了防止这种情况,Amazon 提供可帮助您保护所有服务的服务委托人数据的工具,这些服务委托人有权限访问账户中的资源。

我们建议在资源策略中使用 aws:SourceArnaws:SourceAccount 全局条件上下文密钥,以限制 CloudWatch Logs 和 Amazon S3 向生成日志的服务授予的权限。如果使用两个全局条件上下文键,在同一策略语句中使用时,aws:SourceAccount 值和 aws:SourceArn 值中的账户必须使用相同的账户 ID。

aws:SourceArn 的值必须是生成日志的 Amazon 资源的 ARN。

防范混淆代理问题最有效的方法是使用 aws:SourceArn 全局条件上下文键和资源的完整 ARN。如果不知道资源的完整 ARN,或者正在指定多个资源,请针对 ARN 未知部分使用带有通配符 (*) 的 aws:SourceArn 全局上下文条件键。

本页前几节中的策略显示了如何使用 aws:SourceArnaws:SourceAccount 全局条件上下文密钥,以避免混淆代理人问题出现。

CloudWatch Logs 对Amazon托管策略的更新

查看有关 CloudWatch Logs 的Amazon托管策略更新的详细信息(从该服务开始跟踪这些更改开始)。有关此页面更改的自动提示,请订阅 CloudWatch Logs 文档历史记录页面上的 RSS 源。

更改 说明 日期

AWSServiceRoleForLogDelivery 服务相关角色策略 – 对现有策略的更新

CloudWatch Logs 更改了与 AWSServiceRoleForLogDelivery 服务相关角色关联的 IAM 策略权限。更改内容如下:

  • firehose:ResourceTag/LogDeliveryEnabled": "true" 条件键已更改为 aws:ResourceTag/LogDeliveryEnabled": "true"

2021 年 7 月 15 日

CloudWatch Logs 开始跟踪更改

CloudWatch Logs 开始跟踪其Amazon托管策略的更改。

2021 年 6 月 10 日