# 中的安全性AWS Lambda
AWS的云安全性的优先级最高。作为 AWS 客户，您将从专为满足大多数安全敏感型企业的要求而打造的数据中心和网络架构中受益。
安全性是 AWS 和您的共同责任。[责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)将其描述为云*的*安全性和云*中*的安全性：
+ **云的安全性** – AWS 负责保护在 AWS 云中运行 AWS 服务 的基础设施。AWS 还向您提供可安全使用的服务。作为 [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)的一部分，第三方审核人员将定期测试和验证安全性的有效性。要了解适用于 AWS Lambda 的合规性计划，请参阅[按合规性计划提供的范围内 AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)。
+ **云中的安全性**：您的责任由您使用的 AWS 服务决定。您还需要对其他因素负责，包括您的数据的敏感性、您公司的要求以及适用的法律法规。
此文档将帮助您了解如何在使用 Lambda 时应用责任共担模型。以下主题说明如何配置 Lambda 以实现您的安全性和合规性目标。您还将了解如何使用其他 AWS 服务以帮助您监控和保护 Lambda 资源。
有关向 Lambda 应用程序应用安全原则的更多信息，请参阅 Serverless Land 中的 [Security](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops)。
**Topics**
+ [AWS Lambda 中的数据保护](security-dataprotection.md)
+ [使用 Lambda 的服务相关角色](using-service-linked-roles.md)
+ [适用于 AWS Lambda 的 Identity and Access Management](security-iam.md)
+ [为 Lambda 函数和层创建治理策略](governance-concepts.md)
+ [AWS Lambda 的合规性验证](security-compliance.md)
+ [AWS Lambda 中的故障恢复能力](security-resilience.md)
+ [中的基础设施安全性AWS Lambda](security-infrastructure.md)
+ [使用公共端点保护工作负载](security-public-endpoints.md)
+ [使用代码签名通过 Lambda 验证代码完整性](configuration-codesigning.md)
# AWS Lambda 中的数据保护
AWS [责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)适用于 AWS Lambda 中的数据保护。如该模式中所述，AWS 负责保护运行所有 AWS 云 的全球基础架构。您负责维护对托管在此基础架构上的内容的控制。您还负责您所使用的 AWS 服务 的安全配置和管理任务。有关数据隐私的更多信息，请参阅[数据隐私常见问题](https://aws.amazon.com/compliance/data-privacy-faq/)。有关欧洲数据保护的信息，请参阅 *AWS Security Blog* 上的 [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 博客文章。
出于数据保护目的，我们建议您保护 AWS 账户 凭证并使用 AWS IAM Identity Center 或 AWS Identity and Access Management（IAM）设置单个用户。这样，每个用户只获得履行其工作职责所需的权限。我们还建议您通过以下方式保护数据：
+ 对每个账户使用多重身份验证（MFA）。
+ 使用 SSL/TLS 与 AWS 资源进行通信。我们要求使用 TLS 1.2，建议使用 TLS 1.3。
+ 使用 AWS CloudTrail 设置 API 和用户活动日记账记录。有关使用 CloudTrail 跟踪来捕获 AWS 活动的信息，请参阅《AWS CloudTrail 用户指南》**中的 [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)。
+ 使用 AWS 加密解决方案以及 AWS 服务 中的所有默认安全控制。
+ 使用高级托管安全服务（例如 Amazon Macie），它有助于发现和保护存储在 Amazon S3 中的敏感数据。
+ 如果在通过命令行界面或 API 访问 AWS 时需要经过 FIPS 140-3 验证的加密模块，请使用 FIPS 端点。有关可用的 FIPS 端点的更多信息，请参阅[美国联邦信息处理标准（FIPS）140-3](https://aws.amazon.com/compliance/fips/)。
我们强烈建议您切勿将机密信息或敏感信息（如您客户的电子邮件地址）放入标签或自由格式文本字段（如**名称**字段）。这包括通过控制台、API、AWS CLI 或 AWS 开发工具包使用 Lambda 或其他 AWS 服务 服务时。在用于名称的标签或自由格式文本字段中输入的任何数据都可能会用于计费或诊断日志。如果您向外部服务器提供网址，强烈建议您不要在网址中包含凭证信息来验证对该服务器的请求。
**Topics**
+ [传输中加密](#security-privacy-intransit)
+ [AWS Lambda 中的静态数据加密](security-encryption-at-rest.md)
## 传输中加密
Lambda API 端点仅支持基于 HTTPS 的安全连接。使用 AWS 管理控制台、AWS开发工具包或 Lambda API 管理 Lambda 资源时，所有通信都使用传输层安全性 (TLS) 进行加密。有关 API 终端节点的完整列表，请参阅 AWS 一般参考 中的 [AWS区域和终端节点](https://docs.aws.amazon.com/general/latest/gr/rande.html)。
当您[将函数连接到文件系统](configuration-filesystem.md)时，Lambda 会对所有连接使用传输中加密。有关更多信息，请参阅《Amazon Elastic File System 用户指南》**中的 [Amazon EFS 中的数据加密](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)。
当您使用[环境变量](configuration-envvars.md)时，您可以启用控制台加密帮助程序，以使用客户端加密来保护传输中的环境变量。有关更多信息，请参阅 [保护 Lambda 环境变量](configuration-envvars-encryption.md)。
# AWS Lambda 中的静态数据加密
Lambda 始终使用 [AWS 拥有的密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)或 [AWS 托管式密钥](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)为以下资源提供静态加密：
+ 环境变量
+ 您上载到 Lambda 的文件，包括部署包和层归档
+ 事件源映射筛选条件对象
您可以选择将 Lambda 配置为使用客户自主管理型密钥来加密您的[环境变量](configuration-envvars-encryption.md)、[.zip 部署包](encrypt-zip-package.md)和[筛选条件对象](invocation-eventfiltering.md#filter-criteria-encryption)。
默认情况下，Amazon CloudWatch Logs 和 AWS X-Ray 也会对数据进行加密，并可配置为使用客户托管密钥。有关详细信息，请参阅 [Encrypt log data in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) 和 [Data protection in AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html)。
## 为 Lambda 监控您的加密密钥
将 AWS KMS 客户自主管理型密钥与 Lambda 一起使用时，您可以使用 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)。以下示例是 Lambda 进行的 `Decrypt`、`DescribeKey` 和 `GenerateDataKey` 调用的 CloudTrail 事件，用于访问由您的客户自主管理型密钥加密的数据。
------
#### [ Decrypt ]
如果您使用 AWS KMS 客户自主管理型密钥对[筛选条件](invocation-eventfiltering.md#filter-criteria-encryption)对象进行加密，那么当您尝试以纯文本形式访问该对象时（例如，通过 `ListEventSourceMappings` 调用），Lambda 会代表您发送 `Decrypt` 请求。以下示例事件记录了 `Decrypt` 操作：
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:05:46Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
```
------
#### [ DescribeKey ]
如果您使用 AWS KMS 客户自主管理型密钥对[筛选条件](invocation-eventfiltering.md#filter-criteria-encryption)对象进行加密，那么当您尝试访问该对象时（例如，通过 `GetEventSourceMapping` 调用），Lambda 会代表您发送 `DescribeKey` 请求。以下示例事件记录了 `DescribeKey` 操作：
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-05-30T01:09:40Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "54.240.197.238",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",
"requestParameters": {
"keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
------
#### [ GenerateDataKey ]
使用 AWS KMS 客户自主管理型密钥在 `CreateEventSourceMapping` 或 `UpdateEventSourceMapping` 调用中加密[筛选条件](invocation-eventfiltering.md#filter-criteria-encryption)对象时，Lambda 会代表您发送 `GenerateDataKey` 请求，要求生成用于加密筛选条件的数据密钥（[信封加密](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)）。以下示例事件记录 `GenerateDataKey` 操作：
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:06:07Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:04:18Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"numberOfBytes": 32,
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
------
# 使用 Lambda 的服务相关角色
Lambda 使用 AWS Identity and Access Management（IAM）[服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)。服务相关角色是一种独特类型的 IAM 角色，它与 Lambda 直接相关。服务相关角色由 Lambda 预定义，并包含该服务代表您调用其他 AWS 服务所需的权限。
Lambda 定义其服务相关角色的权限，并且仅 Lambda 可以担任其角色。定义的权限包括信任策略和权限策略，以及不能附加到任何其他 IAM 实体的权限策略。
只有在首先删除相关资源后，您才能删除服务关联角色。这可以保护您的 Lambda 资源，因为您不会无意中删除对资源的访问权限。
有关支持服务相关角色的其他服务的信息，请参阅[使用 IAM 的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，并查找**服务相关角色**列中显示为**是**的服务。选择**是**和链接，查看该服务的服务关联角色文档。
## Lambda 的服务相关角色权限
Lambda 使用名为 **AWSServiceRoleForLambda** 的服务相关角色。 服务相关角色信任以下服务代入该角色：
+ `lambda.amazonaws.com`
名为 AWSLambdaServiceRolePolicy 的角色权限策略允许 Lambda 对指定资源完成以下操作：
+ 操作：`arn:aws:ec2:*:*:instance/*` 上的 `ec2:TerminateInstances`，具有条件 `ec2:ManagedResourceOperator` = `scaler.lambda.amazonaws.com`
+ 操作：`*` 上的 `ec2:DescribeInstanceStatus` 和 `ec2:DescribeInstances`。
您必须配置使用户、组或角色能够创建、编辑或删除服务相关角色的权限。有关更多信息，请参阅*《IAM 用户指南》*中的[服务相关角色权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。
有关托管策略更新，请参阅 [Lambda 托管策略](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates)。
## 为 Lambda 创建服务相关角色
您无需手动创建服务关联角色。当您在 AWS 管理控制台、AWS CLI 或 AWS API 中创建 Lambda 容量提供程序时，Lambda 将为您创建服务相关角色。
如果您删除该服务关联角色，然后需要再次创建，您可以使用相同流程在账户中重新创建此角色。当您创建 Lambda 容量提供程序时，Lambda 将为您再次创建服务相关角色。
您还可以使用 IAM 控制台创建具有 **AWSServiceRoleForLambda** 使用案例的服务相关角色。在 AWS CLI 或 AWS API 中，使用 `lambda.amazonaws.com` 服务名称创建服务相关角色。有关更多信息，请参阅《IAM 用户指南》中的[创建服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)**。如果您删除了此服务相关角色，可以使用同样的过程再次创建角色。
## 编辑 Lambda 的服务相关角色
Lambda 不允许编辑 AWSServiceRoleForLambda 服务相关角色。创建服务关联角色后，您将无法更改角色的名称，因为可能有多种实体引用该角色。但是可以使用 IAM 编辑角色描述。有关更多信息，请参阅《IAM 用户指南》**中的[编辑服务关联角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。
## 删除 Lambda 的服务相关角色
如果不再需要使用某个需要服务关联角色的功能或服务，我们建议您删除该角色。这样就没有未被主动监控或维护的未使用实体。但是，必须先清除服务相关角色的资源，然后才能手动删除它。
**注意**
如果在您试图删除资源时 Lambda 服务正在使用该角色，则删除操作可能会失败。如果发生这种情况，请等待几分钟后重试。
**删除 AWSServiceRoleForLambda 使用的 Lambda 资源**
1. 从您的账户中移除所有 Lambda 容量提供程序。您可以使用 Lambda 控制台、CLI 或 API 执行此操作。
1. 尝试删除服务相关角色之前，请确认您的账户中没有剩下 Lambda 容量提供程序。
**使用 IAM 手动删除服务关联角色**
使用 IAM 控制台、AWS CLI 或 AWS API 删除 AWSServiceRoleForLambda 服务相关角色。有关更多信息，请参阅《IAM 用户指南》**中的[删除服务相关角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。
## Lambda 服务相关角色的受支持区域
Lambda 并非在提供该服务的每个区域中都支持使用服务相关角色。在以下区域中支持 AWSServiceRoleForLambda。
| 区域名称 | 区域标识 | Lambda 中的支持 |
| --- | --- | --- |
| 美国东部（弗吉尼亚州北部） | us-east-1 | 是 |
| 美国东部（俄亥俄州） | us-east-2 | 是 |
| 美国西部（北加利福尼亚） | us-west-1 | 是 |
| 美国西部（俄勒冈州） | us-west-2 | 是 |
| 非洲（开普敦） | af-south-1 | 否 |
| 亚太地区（香港） | ap-east-1 | 是 |
| 亚太地区（雅加达） | ap-southeast-3 | 是 |
| 亚太地区（曼谷） | ap-southeast-7 | 是 |
| 亚太地区（孟买） | ap-south-1 | 是 |
| 亚太地区（大阪） | ap-northeast-3 | 否 |
| 亚太地区（首尔） | ap-northeast-2 | 否 |
| 亚太地区（新加坡） | ap-southeast-1 | 是 |
| 亚太地区（悉尼） | ap-southeast-2 | 是 |
| 亚太地区（东京） | ap-northeast-1 | 是 |
| 加拿大（中部） | ca-central-1 | 否 |
| 欧洲地区（法兰克福） | eu-central-1 | 是 |
| 欧洲地区（爱尔兰） | eu-west-1 | 是 |
| 欧洲地区（伦敦） | eu-west-2 | 是 |
| 欧洲地区（米兰） | eu-south-1 | 否 |
| 欧洲地区（巴黎） | eu-west-3 | 否 |
| 欧洲地区（斯德哥尔摩） | eu-north-1 | 否 |
| 中东（巴林） | me-south-1 | 否 |
| 中东（阿联酋） | me-central-1 | 否 |
| 南美洲（圣保罗） | sa-east-1 | 否 |
| AWS GovCloud（美国东部） | us-gov-east-1 | 否 |
| AWS GovCloud（美国西部） | us-gov-west-1 | 否 |
# 适用于 AWS Lambda 的 Identity and Access Management
AWS Identity and Access Management（IAM）是一项，AWS 服务可以帮助管理员安全地控制对 AWS 资源的访问。IAM 管理员控制可以通过*身份验证*（登录）和*授权*（具有权限）使用 Lambda 资源的人员。IAM 是一项无需额外费用即可使用的。AWS 服务
**Topics**
+ [受众](#security_iam_audience)
+ [使用身份进行身份验证](#security_iam_authentication)
+ [使用策略管理访问](#security_iam_access-manage)
+ [AWS Lambda 如何与 IAM 协同工作](security_iam_service-with-iam.md)
+ [AWS Lambda 基于身份的策略示例](security_iam_id-based-policy-examples.md)
+ [适用于 AWS Lambda 的 AWS 托管式策略](security-iam-awsmanpol.md)
+ [排查 AWS Lambda 身份和访问问题](security_iam_troubleshoot.md)
## 受众
您使用 AWS Identity and Access Management（IAM）的方式因您的角色而异：
+ **服务用户**：如果您无法访问功能，请从管理员处请求权限（请参阅[排查 AWS Lambda 身份和访问问题](security_iam_troubleshoot.md)）
+ **服务管理员**：确定用户访问权限并提交权限请求（请参阅[AWS Lambda 如何与 IAM 协同工作](security_iam_service-with-iam.md)）
+ **IAM 管理员**：编写用于管理访问权限的策略（请参阅[AWS Lambda 基于身份的策略示例](security_iam_id-based-policy-examples.md)）
## 使用身份进行身份验证
身份验证是您使用身份凭证登录 AWS 的方法。您必须作为 AWS 账户根用户、IAM 用户或通过担任 IAM 角色进行身份验证。
您可以使用来自 AWS IAM Identity Center（IAM Identity Center）等身份源的凭证、单点登录身份验证或 Google/Facebook 凭证，以联合身份进行登录。有关登录的更多信息，请参阅《AWS 登录 用户指南》**中的[如何登录您的 AWS 账户](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。
对于编程访问，AWS 提供了 SDK 和 CLI 来对请求进行加密签名。有关更多信息，请参阅*《IAM 用户指南》*中的[适用于 API 请求的 AWS 签名版本 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。
### AWS 账户 根用户
当您创建 AWS 账户 时，最初使用的是一个对所有 AWS 服务和资源拥有完全访问权限的登录身份（称为 AWS 账户*根用户*）。我们强烈建议不要使用根用户进行日常任务。有关需要根用户凭证的任务，请参阅《IAM 用户指南》**中的[需要根用户凭证的任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。
### 联合身份
作为最佳实践，请要求人类用户必须使用带有身份提供者的联合身份验证才能使用临时凭证访问 AWS 服务。
*联合身份*是来自企业目录、Web 身份提供者的用户，或 Directory Service 中的用户（这些用户使用来自身份源的凭证访问 AWS 服务）。联合身份代入可提供临时凭证的角色。
要集中管理访问权限，建议使用。AWS IAM Identity Center有关更多信息，请参阅《AWS IAM Identity Center 用户指南》**中的[什么是 IAM Identity Center？](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。
### IAM 用户和群组
*[IAM 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*是对某个人员或应用程序具有特定权限的一个身份。建议使用临时凭证，而非具有长期凭证的 IAM 用户。有关更多信息，请参阅*《IAM 用户指南》*中的[要求人类用户使用带有身份提供商的联合身份验证才能使用临时凭证访问 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)指定一组 IAM 用户，便于更轻松地对大量用户进行权限管理。有关更多信息，请参阅*《IAM 用户指南》*中的 [IAM 用户使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)。
### IAM 角色
*[IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*是具有特定权限的身份，可提供临时凭证。您可以通过[从用户切换到 IAM 角色（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或调用 AWS CLI 或 AWS API 操作来担任角色。有关更多信息，请参阅《IAM 用户指南》**中的[担任角色的方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)。
IAM 角色对于联合用户访问、临时 IAM 用户权限、跨账户访问、跨服务访问以及在 Amazon EC2 上运行的应用程序非常有用。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。
## 使用策略管理访问
您将创建策略并将其附加到 AWS 身份或资源，以控制 AWS 中的访问。策略在与身份或资源关联时定义权限。当主体发出请求时，AWS 会评估这些策略。大多数策略在 AWS 中存储为 JSON 文档。有关 JSON 策略文档的更多信息，请参阅*《IAM 用户指南》*中的 [JSON 策略概述](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。
管理员使用策略，通过定义哪个**主体**可以在什么**条件**下对哪些**资源**执行哪些**操作**来指定谁有权访问什么。
默认情况下，用户和角色没有权限。IAM 管理员创建 IAM 策略并将其添加到角色中，然后用户可以担任这些角色。IAM 策略定义权限，与执行操作所用的方法无关。
### 基于身份的策略
基于身份的策略是您附加到身份（用户、组或角色）的 JSON 权限策略文档。这些策略控制身份可以执行什么操作、对哪些资源执行以及在什么条件下执行。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。
基于身份的策略可以是*内联策略*（直接嵌入到单个身份中）或*托管策略*（附加到多个身份的独立策略）。要了解如何在托管策略和内联策略之间进行选择，请参阅*《IAM 用户指南》*中的[在托管策略与内联策略之间进行选择](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)。
### 基于资源的策略
基于资源的策略是附加到资源的 JSON 策略文档。示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。
基于资源的策略是位于该服务中的内联策略。您不能在基于资源的策略中使用来自 IAM 的 AWS 托管策略。
### 其他策略类型
AWS 支持额外的策略类型，这些策略类型可以设置由更常用的策略类型授予的最大权限：
+ **权限边界** – 设置基于身份的策略可以授予 IAM 实体的最大权限。有关更多信息，请参阅《 IAM 用户指南》**中的 [IAM 实体的权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。
+ **服务控制策略（SCP）**– 指定 AWS Organizations 中组织或组织单元的最大权限。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。
+ **资源控制策略（RCP）**– 设置对账户中资源的最大可用权限。有关更多信息，请参阅《AWS Organizations 用户指南》**中的[资源控制策略（RCP）](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。
+ **会话策略** – 在为角色或联合用户创建临时会话时，作为参数传递的高级策略。有关更多信息，请参阅《IAM 用户指南》**中的[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。
### 多个策略类型
当多个类型的策略应用于一个请求时，生成的权限更加复杂和难以理解。要了解 AWS 如何确定在涉及多种策略类型时是否允许请求，请参阅*IAM 用户指南*中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。
# AWS Lambda 如何与 IAM 协同工作
在使用 IAM 管理对 Lambda 的访问之前，您应该了解哪些 IAM 功能可用于 Lambda。
| IAM 功能 | Lambda 支持 |
| --- | --- |
| [基于身份的策略](#security_iam_service-with-iam-id-based-policies) | 是 |
| [基于资源的策略](#security_iam_service-with-iam-resource-based-policies) | 是 |
| [策略操作](#security_iam_service-with-iam-id-based-policies-actions) | 是 |
| [策略资源](#security_iam_service-with-iam-id-based-policies-resources) | 是 |
| [策略条件键（特定于服务）](#security_iam_service-with-iam-id-based-policies-conditionkeys) | 是 |
| [ACL](#security_iam_service-with-iam-acls) | 否 |
| [ABAC（策略中的标签）](#security_iam_service-with-iam-tags) | 部分 |
| [临时凭证](#security_iam_service-with-iam-roles-tempcreds) | 是 |
| [转发访问会话 (FAS)](#security_iam_service-with-iam-principal-permissions) | 否 |
| [服务角色](#security_iam_service-with-iam-roles-service) | 是 |
| [服务关联角色](#security_iam_service-with-iam-roles-service-linked) | 部分 |
要深入了解 Lambda 和其他 AWS 服务如何与大多数 IAM 功能配合使用，请参阅《IAM 用户指南》**中的[使用 IAM 的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。
## Lambda 的基于身份的策略
**支持基于身份的策略：**是
基于身份的策略是可附加到身份（如 IAM 用户、用户组或角色）的 JSON 权限策略文档。这些策略控制用户和角色可在何种条件下对哪些资源执行哪些操作。要了解如何创建基于身份的策略，请参阅《IAM 用户指南》**中的[使用客户管理型策略定义自定义 IAM 权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。
通过使用 IAM 基于身份的策略，您可以指定允许或拒绝的操作和资源以及允许或拒绝操作的条件。要了解可在 JSON 策略中使用的所有元素，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素引用](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)。
### Lambda 基于身份的策略示例
要查看 Lambda 基于身份的策略示例，请参阅[AWS Lambda 基于身份的策略示例](security_iam_id-based-policy-examples.md)。
## Lambda 内基于资源的策略
**支持基于资源的策略：**是
基于资源的策略是附加到资源的 JSON 策略文档。基于资源的策略的示例包括 IAM *角色信任策略*和 Amazon S3 *存储桶策略*。在支持基于资源的策略的服务中，服务管理员可以使用它们来控制对特定资源的访问。对于在其中附加策略的资源，策略定义指定主体可以对该资源执行哪些操作以及在什么条件下执行。您必须在基于资源的策略中[指定主体](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。主体可以包括账户、用户、角色、联合用户或。AWS 服务
要启用跨账户访问，您可以将整个账户或其他账户中的 IAM 实体指定为基于资源的策略中的主体。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。
您可以将基于资源的策略附加到 Lambda 函数或层。此策略定义了哪些主体可以对函数或层执行操作。
要了解如何将基于资源的策略附加到函数或层，请参阅[在 Lambda 中查看基于资源的 IAM 策略](access-control-resource-based.md)。
## Lambda 的策略操作
**支持策略操作：**是
管理员可以使用 AWS JSON 策略来指定谁有权访问什么内容。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
JSON 策略的 `Action` 元素描述可用于在策略中允许或拒绝访问的操作。在策略中包含操作以授予执行关联操作的权限。
要查看 Lambda 操作的列表，请参阅《Service Authorization Reference》**中的 [Actions defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)。
Lambda 中的策略操作在操作前使用以下前缀：
```
lambda
```
要在单个语句中指定多项操作，请使用逗号将它们隔开。
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
要查看 Lambda 基于身份的策略示例，请参阅[AWS Lambda 基于身份的策略示例](security_iam_id-based-policy-examples.md)。
## Lambda 的策略资源
**支持策略资源：**是
管理员可以使用 AWS JSON 策略来指定谁有权访问什么内容。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
`Resource` JSON 策略元素指定要向其应用操作的一个或多个对象。作为最佳实践，请使用其 [Amazon 资源名称（ARN）](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)指定资源。对于不支持资源级权限的操作，请使用通配符 (\$1) 指示语句应用于所有资源。
```
"Resource": "*"
```
要查看 Lambda 资源类型及其 ARN 的列表，请参阅《Service Authorization Reference》**中 [Resource types defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies)。要了解可以在哪些操作中指定每个资源的 ARN，请参阅 [AWS Lambda 定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)。
要查看 Lambda 基于身份的策略示例，请参阅[AWS Lambda 基于身份的策略示例](security_iam_id-based-policy-examples.md)。
## Lambda 的策略条件键
**支持特定于服务的策略条件键：**是
管理员可以使用 AWS JSON 策略来指定谁有权访问什么内容。也就是说，哪个**主体**可以对什么**资源**执行**操作**，以及在什么**条件**下执行。
`Condition` 元素根据定义的条件指定语句何时执行。您可以创建使用[条件运算符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)（例如，等于或小于）的条件表达式，以使策略中的条件与请求中的值相匹配。要查看所有 AWS 全局条件键，请参阅《IAM 用户指南》**中的 [AWS 全局条件上下文键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。
有关 Lambda 条件键的列表，请参阅《Service Authorization Reference》**中的 [Condition keys for AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys)。要了解您可以对哪些操作和资源使用条件键，请参阅 [AWS Lambda 定义的操作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)。
要查看 Lambda 基于身份的策略示例，请参阅[AWS Lambda 基于身份的策略示例](security_iam_id-based-policy-examples.md)。
## Lambda 中的 ACL
**支持 ACL：**否
访问控制列表（ACL）控制哪些主体（账户成员、用户或角色）有权访问资源。ACL 与基于资源的策略类似，但它们不使用 JSON 策略文档格式。
## ABAC 与 Lambda 配合使用
**支持 ABAC（策略中的标签）：**部分支持
基于属性的访问权限控制（ABAC）是一种授权策略，该策略基于称为标签的属性来定义权限。您可以将标签附加到 IAM 实体和 AWS 资源，然后设计 ABAC 策略，以支持在主体的标签与资源上的标签匹配时执行操作。
要基于标签控制访问，您需要使用 `aws:ResourceTag/key-name``aws:RequestTag/key-name` 或 `aws:TagKeys` 条件键在策略的[条件元素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中提供标签信息。
如果某个服务对于每种资源类型都支持所有这三个条件键，则对于该服务，该值为**是**。如果某个服务仅对于部分资源类型支持所有这三个条件键，则该值为**部分**。
有关 ABAC 的更多信息，请参阅《IAM 用户指南》**中的[使用 ABAC 授权定义权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)。要查看设置 ABAC 步骤的教程，请参阅《IAM 用户指南》**中的[使用基于属性的访问权限控制（ABAC）](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)。
有关标记 Lambda 资源的更多信息，请参阅[在 Lambda 中使用基于属性的访问控制](attribute-based-access-control.md)。
## 将临时凭证与 Lambda 配合使用
**支持临时凭证：**是
临时凭证提供对 AWS 资源的短期访问权限，并且是在您使用联合身份验证或切换角色时自动创建的。AWS 建议您动态生成临时凭证，而不是使用长期访问密钥。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的临时安全凭证](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)和[使用 IAM 的。AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)
## 转发 Lambda 访问会话
**支持转发访问会话（FAS）：**否
转发访问会话（FAS）使用调用 AWS 服务的主体的权限，与发出请求的 AWS 服务结合，来向下游服务发出请求。有关发出 FAS 请求时的策略详情，请参阅[转发访问会话](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)。
## Lambda 的服务角色
**支持服务角色：**是
服务角色是由一项服务担任、代表您执行操作的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。IAM 管理员可以在 IAM 中创建、修改和删除服务角色。有关更多信息，请参阅《IAM 用户指南》**中的[创建向 AWS 服务 委派权限的角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)。
在 Lambda 中，服务角色称为[执行角色](lambda-intro-execution-role.md)。
**警告**
更改执行角色的权限可能会破坏 Lambda 功能。
## Lambda 的服务相关角色
**支持服务相关角色：**部分支持
服务关联角色是一种与 AWS 服务 关联的服务角色。服务可以代入代表您执行操作的角色。服务关联角色显示在您的 AWS 账户 中，并由该服务拥有。IAM 管理员可以查看但不能编辑服务关联角色的权限。
Lambda 不具有服务相关角色，但 Lambda@Edge 具有。有关更多信息，请参阅《Amazon CloudFront 开发人员指南》**中的 [Lambda@Edge 的服务相关角色](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles)。
有关创建或管理服务相关角色的详细信息，请参阅[能够与 IAM 搭配使用的 AWS 服务](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。在表中查找**服务相关角色**列中包含 `Yes` 的表。选择**是**链接以查看该服务的服务相关角色文档。
# AWS Lambda 基于身份的策略示例
默认情况下，用户和角色没有创建或修改 Lambda 资源的权限。要授予用户对所需资源执行操作的权限，IAM 管理员可以创建 IAM 策略。
要了解如何使用这些示例 JSON 策略文档创建基于 IAM 身份的策略，请参阅《IAM 用户指南》**中的[创建 IAM 策略（控制台）](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。
有关 Lambda 定义的操作和资源类型的详细信息，包括每种资源类型的 ARN 格式，请参阅《Service Authorization Reference》**中的 [Actions, resources, and condition keys for AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html)。
**Topics**
+ [策略最佳实践](#security_iam_service-with-iam-policy-best-practices)
+ [使用 Lambda 控制台](#security_iam_id-based-policy-examples-console)
+ [允许用户查看他们自己的权限](#security_iam_id-based-policy-examples-view-own-permissions)
## 策略最佳实践
基于身份的策略确定某个人是否可以创建、访问或删除您账户中的 Lambda 资源。这些操作可能会使 AWS 账户产生成本。创建或编辑基于身份的策略时，请遵循以下指南和建议：
+ **AWS 托管式策略及转向最低权限许可入门**：要开始向用户和工作负载授予权限，请使用 *AWS 托管式策略*来为许多常见使用场景授予权限。您可以在 AWS 账户 中找到这些策略。建议通过定义特定于您的使用场景的 AWS 客户托管式策略来进一步减少权限。有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[工作职能的 AWS 托管策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。
+ **应用最低权限**：在使用 IAM 策略设置权限时，请仅授予执行任务所需的权限。为此，您可以定义在特定条件下可以对特定资源执行的操作，也称为*最低权限许可*。有关使用 IAM 应用权限的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的策略和权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。
+ **使用 IAM 策略中的条件进一步限制访问权限**：您可以向策略添加条件来限制对操作和资源的访问。例如，您可以编写策略条件来指定必须使用 SSL 发送所有请求。如果通过特定 AWS 服务（例如 CloudFormation）使用服务操作，您还可以使用条件来授予对服务操作的访问权限。有关更多信息，请参阅《IAM 用户指南》**中的 [IAM JSON 策略元素：条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。
+ **使用 IAM Access Analyzer 验证您的 IAM 策略，以确保权限的安全性和功能性**：IAM Access Analyzer 会验证新策略和现有策略，以确保策略符合 IAM 策略语言（JSON）和 IAM 最佳实践。IAM Access Analyzer 提供 100 多项策略检查和可操作的建议，以帮助您制定安全且功能性强的策略。有关更多信息，请参阅《IAM 用户指南》**中的[使用 IAM Access Analyzer 验证策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。
+ **需要多重身份验证（MFA）**：如果您所处的场景要求您的 AWS 账户 中有 IAM 用户或根用户，请启用 MFA 来提高安全性。若要在调用 API 操作时需要 MFA，请将 MFA 条件添加到您的策略中。有关更多信息，请参阅《IAM 用户指南》**中的[使用 MFA 保护 API 访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。
有关 IAM 中的最佳实操的更多信息，请参阅《IAM 用户指南》**中的 [IAM 中的安全最佳实践](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。
## 使用 Lambda 控制台
要访问 AWS Lambda 控制台，您必须拥有一组最低权限。这些权限必须允许您列出和查看有关 AWS 账户 中 Lambda 资源的详细信息。如果创建比必需的最低权限更为严格的基于身份的策略，对于附加了该策略的实体（用户或角色），控制台将无法按预期正常运行。
对于只需要调用 AWS CLI 或 AWS API 的用户，无需为其提供最低控制台权限。相反，只允许访问与其尝试执行的 API 操作相匹配的操作。
有关授予函数开发的最小访问权限的示例策略，请参阅[授予用户对 Lambda 函数的访问权限](permissions-user-function.md)。除了 Lambda API 以外，Lambda 控制台还使用其他服务来显示触发器配置，并允许您添加新触发器。如果您的用户将 Lambda 与其他服务结合使用，则他们还需要这些服务的访问权限。有关配置其他服务及 Lambda 的详细信息，请参阅[使用来自其 AWS 他服务的事件调用 Lambda](lambda-services.md)。
## 允许用户查看他们自己的权限
该示例说明了您如何创建策略，以允许 IAM 用户查看附加到其用户身份的内联和托管式策略。此策略包括在控制台上完成此操作或者以编程方式使用 AWS CLI 或 AWS API 所需的权限。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# 适用于 AWS Lambda 的 AWS 托管式策略
AWS 托管式策略是由 AWS 创建和管理的独立策略。AWS 托管式策略旨在为许多常见使用案例提供权限，以便您可以开始为用户、组和角色分配权限。
请记住，AWS 托管式策略可能不会为您的特定使用案例授予最低权限，因为它们可供所有 AWS 客户使用。我们建议通过定义特定于使用案例的[客户管理型策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)来进一步减少权限。
您无法更改 AWS 托管式策略中定义的权限。如果 AWS 更新在 AWS 托管式策略中定义的权限，则更新会影响该策略所附加到的所有主体身份（用户、组和角色）。当新的 AWS 服务 启动或新的 API 操作可用于现有服务时，AWS 最有可能更新 AWS 托管式策略。
有关更多信息，请参阅《IAM 用户指南》**中的 [AWS 托管式策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。
**Topics**
+ [AWS 托管式策略：AWSLambda\$1FullAccess](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [AWS 托管式策略：AWSLambda\$1ReadOnlyAccess](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [AWS 托管式策略：AWSLambdaBasicExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [AWS 托管策略：AWSLambdaBasicDurableExecutionRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [AWS 托管式策略：AWSLambdaDynamoDBExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [AWS 托管式策略：AWSLambdaENIManagementAccess](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [AWS 托管式策略：AWSLambdaInvocation-DynamoDB](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [AWS 托管式策略：AWSLambdaKinesisExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [AWS 托管式策略：AWSLambdaMSKExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [AWS 托管式策略：AWSLambdaRole](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [AWS 托管式策略：AWSLambdaSQSQueueExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [AWS 托管式策略：AWSLambdaVPCAccessExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [AWS 托管策略：AWSLambdaManagedEC2ResourceOperator](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [AWS 托管策略：AWSLambdaServiceRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [Lambda 对 AWS 托管式策略的更新](#lambda-security-iam-awsmanpol-updates)
## AWS 托管式策略：AWSLambda\$1FullAccess
该策略向所有 Lambda 操作授予完全访问权限。它还向用于开发和维护 Lambda 资源的其他 AWS 服务授予权限。
您可以将 `AWSLambda_FullAccess` 策略附加到用户、组和角色。
**权限详细信息**
该策略包含以下权限：
+ `lambda`：允许主体完全访问 Lambda。
+ `cloudformation`：允许主体描述 AWS CloudFormation 堆栈并列出这些堆栈中的资源。
+ `cloudwatch`：允许主体列出 Amazon CloudWatch 指标并获取指标数据。
+ `ec2`：允许主体描述安全组、子网和 VPC。
+ `iam`：允许主体获取策略、策略版本、角色、角色策略、附加角色策略和角色列表。此策略还允许主体将角色传递给 Lambda。将执行角色分配给函数时，需要使用 `PassRole` 权限。创建服务相关角色时将使用 `CreateServiceLinkedRole` 权限。
+ `kms`：允许主体列出别名和描述卷加密的密钥。
+ `logs` – 允许主体描述日志流、获取日志事件、筛选日志事件以及启动和停止 Live Tail 会话。
+ `states`：允许主体描述和列出 AWS Step Functions 状态机。
+ `tag`：允许主体根据其标签获取资源。
+ `xray`：允许主体获取 AWS X-Ray 跟踪摘要并检索按 ID 指定的跟踪列表。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)。
## AWS 托管式策略：AWSLambda\$1ReadOnlyAccess
此策略授予对 Lambda 资源以及用于开发和维护 Lambda 资源的其他 AWS 服务的只读访问权限。
您可以将 `AWSLambda_ReadOnlyAccess` 策略附加到用户、组和角色。
**权限详细信息**
该策略包含以下权限：
+ `lambda`：允许主体获取并列出所有资源。
+ `cloudformation`：允许主体描述并列出 AWS CloudFormation 堆栈以及其中的资源。
+ `cloudwatch`：允许主体列出 Amazon CloudWatch 指标并获取指标数据。
+ `ec2`：允许主体描述安全组、子网和 VPC。
+ `iam`：允许主体获取策略、策略版本、角色、角色策略、附加角色策略和角色列表。
+ `kms`：允许主体列出别名。
+ `logs` – 允许主体描述日志流、获取日志事件、筛选日志事件以及启动和停止 Live Tail 会话。
+ `states`：允许主体描述和列出 AWS Step Functions 状态机。
+ `tag`：允许主体根据其标签获取资源。
+ `xray`：允许主体获取 AWS X-Ray 跟踪摘要并检索按 ID 指定的跟踪列表。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)。
## AWS 托管式策略：AWSLambdaBasicExecutionRole
此策略授予将日志上传到 CloudWatch Logs 的权限。
您可以将 `AWSLambdaBasicExecutionRole` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)。
## AWS 托管策略：AWSLambdaBasicDurableExecutionRolePolicy
该策略提供对 CloudWatch Logs 的写入权限，为 Lambda 持久性函数使用的持久执行 API 提供读/写权限。该策略提供 Lambda 持久性函数所需的基本权限，这些函数使用持久执行 API 来保持函数调用的进度并在调用之间保持状态。
您可以将 `AWSLambdaBasicDurableExecutionRolePolicy` 策略附加到用户、组和角色。
**权限详细信息**
该策略包含以下权限：
+ `logs`：允许主体创建日志组和日志流，并将日志事件写入 CloudWatch Logs。
+ `lambda`：允许主体检查持久执行状态并检索 Lambda 持久性函数的持久执行状态。
要查看有关策略的更多详细信息（包括 JSON 策略文档的最新版本），请参阅《AWS Managed Policy Reference Guide》**中的 [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)。
## AWS 托管式策略：AWSLambdaDynamoDBExecutionRole
此策略授予读取 Amazon DynamoDB Streams 中的记录并写入 CloudWatch Logs 的权限。
您可以将 `AWSLambdaDynamoDBExecutionRole` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaDynamoDBExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html)。
## AWS 托管式策略：AWSLambdaENIManagementAccess
此策略授予创建、描述和删除启用 VPC 的 Lambda 函数所使用的弹性网络接口的权限。
您可以将 `AWSLambdaENIManagementAccess` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html)。
## AWS 托管式策略：AWSLambdaInvocation-DynamoDB
此策略授予对 Amazon DynamoDB Streams 的读取权限。
您可以将 `AWSLambdaInvocation-DynamoDB` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)。
## AWS 托管式策略：AWSLambdaKinesisExecutionRole
此策略授予读取 Amazon Kinesis Data Streams 中的事件和写入 CloudWatch Logs 的权限。
您可以将 `AWSLambdaKinesisExecutionRole` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)。
## AWS 托管式策略：AWSLambdaMSKExecutionRole
此策略授予读取和访问 Amazon Managed Streaming for Apache Kafka 集群中的记录、管理弹性网络接口及写入 CloudWatch Logs 的权限。
您可以将 `AWSLambdaMSKExecutionRole` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaMSKExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)。
## AWS 托管式策略：AWSLambdaRole
此策略授予调用 Lambda 函数的权限。
您可以将 `AWSLambdaRole` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html)。
## AWS 托管式策略：AWSLambdaSQSQueueExecutionRole
此策略授予读取和删除 Amazon Simple Queue Service 队列中的消息的权限，以及写入 CloudWatch Logs 的权限。
您可以将 `AWSLambdaSQSQueueExecutionRole` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)。
## AWS 托管式策略：AWSLambdaVPCAccessExecutionRole
此策略授予管理 Amazon Virtual Private Cloud 中的弹性网络接口和写入 CloudWatch 日志的权限。
您可以将 `AWSLambdaVPCAccessExecutionRole` 策略附加到用户、组和角色。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)。
## AWS 托管策略：AWSLambdaManagedEC2ResourceOperator
该策略支持对 Lambda 容量提供程序进行自动化的 Amazon Elastic Compute Cloud 实例管理。它向 Lambda 扩展器服务授予相应的权限，使其能够代表您执行实例生命周期操作。
您可以将 `AWSLambdaManagedEC2ResourceOperator` 策略附加到用户、组和角色。
**权限详细信息**
该策略包含以下权限：
+ `ec2:RunInstances`：允许 Lambda 启动新的 Amazon EC2 实例，条件是 ec2:ManagedResourceOperator 等于 scaler.lambda.amazonaws.com，并且会将 AMI 的使用仅限于 Amazon 拥有的映像。
+ `ec2:DescribeInstances` 和 `ec2:DescribeInstanceStatus`：允许 Lambda 监控实例状态并检索实例信息。
+ `ec2:CreateTags`：允许 Lambda 标记 Amazon EC2 资源以进行管理和识别。
+ `ec2:DescribeAvailabilityZones`：允许 Lambda 查看可进行实例置放决策的可用区。
+ `ec2:DescribeCapacityReservations`：允许 Lambda 检查容量预留以实现最佳实例置放。
+ `ec2:DescribeInstanceTypes` 和 `ec2:DescribeInstanceTypeOfferings`：允许 Lambda 查看可用的实例类型及其产品。
+ `ec2:DescribeSubnets`：允许 Lambda 检查子网配置以进行网络规划。
+ `ec2:DescribeSecurityGroups`：允许 Lambda 检索网络接口配置所对应的安全组信息。
+ `ec2:CreateNetworkInterface`：允许 Lambda 创建网络接口并管理子网和安全组关联。
+ `ec2:AttachNetworkInterface`：允许 Lambda 将网络接口附加到 Amazon EC2 实例，条件是 `ec2:ManagedResourceOperator` 等于 [scaler.lambda.amazonaws.com](http://scaler.lambda.amazonaws.com/)。
有关此策略的更多信息，包括 JSON 策略文档和策略版本，请参阅《AWS Managed Policy Reference Guide**》中的 [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html)。
## AWS 托管策略：AWSLambdaServiceRolePolicy
此策略将附加到名为 AWSServiceRoleForLambda 的服务相关角色，以允许 Lambda 终止作为 Lambda 容量提供程序一部分管理的实例。
**权限详细信息**
该策略包含以下权限：
+ `ec2:TerminateInstances`：允许 Lambda 终止 EC2 实例，条件是 ec2:ManagedResourceOperator 等于 scaler.lambda.amazonaws.com。
+ `ec2:DescribeInstanceStatus` 和 `ec2:DescribeInstances`：允许 Lambda 描述 EC2 实例。
有关此策略的更多信息，请参阅[将服务相关角色用于 Lambda](using-service-linked-roles.md)。
## Lambda 对 AWS 托管式策略的更新
| 更改 | 描述 | 日期 |
| --- | --- | --- |
| [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html)：新策略 | Lambda 添加了一个新的托管策略，以便为 Lambda 容量提供程序启用自动化 Amazon EC2 实例管理，从而使扩缩器服务能够执行实例生命周期操作。 | 2025 年 11 月 30 日 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html)：新策略 | Lambda 为服务相关角色添加了新的托管策略，以允许 Lambda 终止作为 Lambda 容量提供程序一部分管理的实例。 | 2025 年 11 月 30 日 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) ：更改 | Lambda 更新了 `AWSLambda_FullAccess` 策略以允许 `kms:DescribeKey` 和 `iam:CreateServiceLinkedRole` 操作。 | 2025 年 11 月 30 日 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)：新托管策略 | Lambda 发布了一项新的托管策略 `AWSLambdaBasicDurableExecutionRolePolicy`，该策略提供对 CloudWatch Logs 的写入权限，为 Lambda 持久性函数使用的持久性执行 API 提供读/写权限。 | 2025 年 12 月 1 日 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) 和 [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – 更改 | Lambda 更新了 `AWSLambda_ReadOnlyAccess` 和 `AWSLambda_FullAccess` 策略以允许 `logs:StartLiveTail` 和 `logs:StopLiveTail` 操作。 | 2025 年 3 月 17 日 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) – 变更 | Lambda 更新了 `AWSLambdaVPCAccessExecutionRole` 策略以允许操作 `ec2:DescribeSubnets`。 | 2024 年 1 月 5 日 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)：变更 | Lambda 更新了 `AWSLambda_ReadOnlyAccess` 策略，以允许主体列出 CloudFormation 堆栈。 | 2023 年 7 月 27 日 |
| AWS Lambda 开启了跟踪更改 | AWS Lambda 为其 AWS 托管式策略开启了跟踪更改。 | 2023 年 7 月 27 日 |
# 排查 AWS Lambda 身份和访问问题
可以使用以下信息，以帮助您诊断和修复在使用 Lambda 和 IAM 时可能遇到的常见问题。
**Topics**
+ [我无权在 Lambda 中执行操作](#security_iam_troubleshoot-no-permissions)
+ [我无权执行 iam:PassRole](#security_iam_troubleshoot-passrole)
+ [我希望允许我 AWS 账户 以外的人访问 Lambda 资源](#security_iam_troubleshoot-cross-account-access)
## 我无权在 Lambda 中执行操作
如果您收到错误提示，指明您无权执行某个操作，则必须更新策略以允许执行该操作。
当 `mateojackson` IAM 用户尝试使用控制台查看有关虚构 `my-example-widget` 资源的详细信息，但不拥有虚构 `lambda:GetWidget` 权限时，会发生以下示例错误。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
在此情况下，必须更新 `mateojackson` 用户的策略，以允许使用 `lambda:GetWidget` 操作访问 `my-example-widget` 资源。
如果您需要帮助，请联系 AWS 管理员。您的管理员是提供登录凭证的人。
## 我无权执行 iam:PassRole
如果收到错误，则表明您无权执行 `iam:PassRole` 操作，则必须更新策略以允许您将角色传递给 Lambda。
有些 AWS 服务 允许将现有角色传递到该服务，而不是创建新服务角色或服务关联角色。为此，您必须具有将角色传递到服务的权限。
当名为 `marymajor` 的 IAM 用户尝试使用控制台在 Lambda 中执行操作时，会发生以下示例错误。但是，服务必须具有服务角色所授予的权限才可执行此操作。Mary 不具有将角色传递到服务的权限。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
在这种情况下，必须更新 Mary 的策略以允许她执行 `iam:PassRole` 操作。
如果您需要帮助，请联系 AWS 管理员。您的管理员是提供登录凭证的人。
## 我希望允许我 AWS 账户 以外的人访问 Lambda 资源
您可以创建一个角色，以便其他账户中的用户或您组织外的人员可以使用该角色来访问您的资源。您可以指定谁值得信赖，可以代入角色。对于支持基于资源的策略或访问控制列表（ACL）的服务，您可以使用这些策略向人员授予对您的资源的访问权。
要了解更多信息，请参阅以下内容：
+ 要了解 Lambda 是否支持这些功能，请参阅 [AWS Lambda 如何与 IAM 协同工作](security_iam_service-with-iam.md)。
+ 要了解如何为您拥有的 AWS 账户中的资源提供访问权限，请参阅《IAM 用户指南》**中的[为您拥有的另一个 AWS 账户中的 IAM 用户提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。
+ 要了解如何为第三方 AWS 账户 提供您的资源的访问权限，请参阅《IAM 用户指南》**中的[为第三方拥有的 AWS 账户 提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)。
+ 要了解如何通过身份联合验证提供访问权限，请参阅《IAM 用户指南》**中的[为经过外部身份验证的用户（身份联合验证）提供访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)。
+ 要了解使用角色和基于资源的策略进行跨账户访问之间的差别，请参阅《IAM 用户指南》**中的 [IAM 中的跨账户资源访问](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。
# 为 Lambda 函数和层创建治理策略
要构建和部署无服务器、云原生应用程序，您必须通过适当的治理和防护机制来实现敏捷性和上市速度。设定业务层面的优先事项，可以强调敏捷性是重中之重，也可以通过治理、防护机制和控制来强调风险规避。实际上，您不会有“非此即彼”的策略，而是使用“和”策略，用于在软件开发生命周期中平衡敏捷性和防护机制。无论这些要求属于贵公司生命周期的哪个阶段，治理能力都可能成为流程和工具链中的一项实施要求。
以下是组织可能为 Lambda 实施的治理控制的几个示例：
+ Lambda 函数不可公开访问。
+ Lambda 函数必须连接到 VPC。
+ Lambda 函数不应使用已弃用的运行时系统。
+ Lambda 函数必须使用一组必需的标签进行标记。
+ 组织外部不得访问 Lambda 层。
+ 带有附加安全组的 Lambda 函数在函数和安全组之间必须具有匹配的标签。
+ 带有附加层的 Lambda 函数必须使用经批准的版本
+ Lambda 环境变量必须使用客户托管式密钥进行静态加密。
下图是在整个软件开发和部署过程中实施控制和策略的深入治理策略的示例：
![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-concepts.png)
以下主题介绍了如何在您的组织中实施开发和部署 Lambda 功能的控制措施，包括针对初创企业和企业的控制措施。您的组织可能已具备相关工具。以下主题采用模块化的方式介绍这些控件，以便您挑选实际需要的组件。
**Topics**
+ [使用 AWS CloudFormation Guard 主动控制 Lambda](governance-cloudformation-guard.md)
+ [使用 AWS Config 对 Lambda 实施预防性控制](governance-config.md)
+ [使用 AWS Config 检测不合规的 Lambda 部署和配置](governance-config-detection.md)
+ [使用 AWS Signer 的 Lambda 代码签名](governance-code-signing.md)
+ [使用 Amazon Inspector 自动执行 Lambda 的安全评测](governance-code-scanning.md)
+ [实施可观测性以实现 Lambda 安全性和合规性](governance-observability.md)
# 使用 AWS CloudFormation Guard 主动控制 Lambda
[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) 是一款开源、通用、策略即代码评估工具。通过根据策略规则验证基础设施即代码（IaC）模板和服务组合，可用于预防性治理和合规性。这些规则可以根据您的团队或组织的要求进行自定义。对于 Lambda 函数，Guard 规则可用于通过定义创建或更新 Lambda 函数时所需的属性设置来控制资源创建和配置更新。
合规性管理员定义部署和更新 Lambda 函数所需的控制和治理策略列表。平台管理员在 CI/CD 管道中实施控制，将其作为带有代码存储库的预提交验证 Webhook，并为开发人员提供命令行工具，以便在本地工作站上验证模板和代码。开发人员编写代码，使用命令行工具验证模板，然后将代码提交到存储库，在部署到 AWS 环境中之前，会自动通过 CI/CD 管道验证存储库。
Guard 允许您使用特定域的语言[编写规则](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html)和实施控制，如下所示。
![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-cloudformation-guard.png)
例如，假设要确保开发人员只选择最新的运行时系统。可以指定两种不同的策略，一种用于识别已弃用的[运行时系统](lambda-runtimes.md)，另一种用于识别即将弃用的运行时系统。为此，可以编写以下 `etc/rules.guard` 文件：
```
let lambda_functions = Resources.*[
Type == "AWS::Lambda::Function"
]
rule lambda_already_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <>
}
}
}
}
rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <>
}
}
}
}
```
现在，假设您编写了以下定义 Lambda 函数的 `iac/lambda.yaml` CloudFormation 模板：
```
Fn:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.7
CodeUri: src
Handler: fn.handler
Role: !GetAtt FnRole.Arn
Layers:
- arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35
```
[安装](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) Guard 实用程序后，请验证您的模板：
```
cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml
```
该输出类似于以下示例：
```
lambda.yaml Status = FAIL
FAILED rules
rules.guard/lambda_soon_to_be_deprecated_runtime
---
Evaluating data lambda.yaml against rules rules.guard
Number of non-compliant resources 1
Resource = Fn {
Type = AWS::Lambda::Function
Rule = lambda_soon_to_be_deprecated_runtime {
ALL {
Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] {
ComparisonError {
Message = Lambda function is using a runtime that is targeted for deprecation.
Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])]
}
PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15]
Operator = NOT IN
Value = "python3.7"
ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]]
Code:
86. Fn:
87. Type: AWS::Lambda::Function
88. Properties:
89. Runtime: python3.7
90. CodeUri: src
91. Handler: fn.handler
}
}
}
}
```
Guard 使开发人员从本地开发人员工作站看到他们需要更新模板才能使用组织允许的运行时系统。这种情况发生在提交到代码存储库以及随后在 CI/CD 管道中检查失败之前。这样一来，开发人员会收到有关如何开发合规模板，以及如何将时间转向编写可带来商业价值的代码的反馈。此控件可以应用于本地开发人员工作站、预提交验证 Webhook 和/或部署前的 CI/CD 管道中。
## 警告
如果您使用 AWS Serverless Application Model（AWS SAM）模板来定义 Lambda 函数，请注意，您需要更新 Guard 规则以搜索如下所示的 `AWS::Serverless::Function` 资源类型。
```
let lambda_functions = Resources.*[
Type == "AWS::Serverless::Function"
]
```
Guard 还希望这些属性包含在资源定义中。同时，AWS SAM 模板使单独的 [Globals](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) 部分中可以指定属性。Globals 部分中定义的属性不会通过您的 Guard 规则进行验证。
正如 Guard 故障排除[文档](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html)中所述，请注意，Guard 不支持 `!GetAtt` 或 `!Sub` 之类的短格式内置函数，而是要求使用扩展形式 `Fn::GetAtt` 和 `Fn::Sub`。（[前面的示例](#guard-iac-yaml)没有评估 Role 属性，因此为了简单起见，使用了短格式内置函数。）
# 使用 AWS Config 对 Lambda 实施预防性控制
在开发过程中尽早确保无服务器应用程序的合规性至关重要。在本主题中，我们将介绍如何使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 实现预防性控制。这样，您就能够在开发过程的早期阶段实施合规性检查，并在 CI/CD 管道中实施相同的控制。这还可以在集中管理的规则存储库中实现标准控制化，以便在 AWS 账户中一致地应用控制。
例如，假设您的合规性管理员定义了一项要求，用于确保所有 Lambda 函数都包含 AWS X-Ray 跟踪。借助 AWS Config 的主动模式，您可以在部署前对 Lambda 函数资源进行合规性检查，从而降低部署配置不当的 Lambda 函数的风险，并通过向开发人员就基础设施即代码模板提供更快的反馈来节省其时间。以下是使用 AWS Config 进行预防性控制的可视化流程：
![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-config-1.png)
考虑要求所有 Lambda 函数都必须启用跟踪。对此，平台团队确定需要在所有账户中主动运行的特定 AWS Config 规则。此规则将缺乏已配置的 X-Ray 跟踪配置的任何 Lambda 函数标记为不合规资源。该团队制定规则，将其打包到[一致性包](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)中，然后在所有 AWS 账户中部署一致性包，以确保组织中的所有账户统一应用这些控制措施。您可以用 AWS CloudFormation Guard 2.x.x 语法编写规则，其形式如下：
```
rule name when condition { assertion }
```
以下是一个 Guard 规则示例，用于检查以确保 Lambda 函数已启用跟踪：
```
rule lambda_tracing_check {
when configuration.tracingConfig exists {
configuration.tracingConfig.mode == "Active"
}
}
```
平台团队采取进一步行动，要求每个 AWS CloudFormation 部署必须调用预创建/更新[钩子](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html)。他们承担开发此钩子和配置管道的全部责任，加强对合规性规则的集中控制，并在所有部署中保持应用程序的一致性。要开发、打包和注册钩子，请参阅 CloudFormation Command Line Interface（CFN-CLI）文档中的 [Developing AWS CloudFormation Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html)。您可以使用 [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) 来创建钩子项目：
```
cfn init
```
此命令要求您提供有关钩子项目的一些基本信息，并创建一个包含以下文件的项目：
```
README.md
.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml
```
作为钩子开发者，您需要在 `.json` 配置文件中添加所需的目标资源类型。在下面的配置中，将钩子配置为在使用 CloudFormation 创建任何 Lambda 函数之前执行。您也可以为 `preUpdate` 和 `preDelete` 操作添加类似的处理程序。
```
"handlers": {
"preCreate": {
"targetNames": [
"AWS::Lambda::Function"
],
"permissions": []
}
}
```
您还需要确保 CloudFormation 钩子具有调用 AWS Config API 的相应权限。为此，您可以更新名为 `hook-role.yaml` 的角色定义文件。默认情况下，角色定义文件具有以下信任策略，该策略允许 CloudFormation 代入该角色。
```
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- hooks.cloudformation.amazonaws.com
- resources.cloudformation.amazonaws.com
```
要允许此钩子调用配置 API，您必须在策略语句中添加以下权限。然后，使用 `cfn submit` 命令提交钩子项目，CloudFormation 会在其中为您创建一个具有所需权限的角色。
```
Policies:
- PolicyName: HookTypePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- "config:Describe*"
- "config:Get*"
- "config:List*"
- "config:SelectResourceConfig"
Resource: "*
```
接下来，您需要在 `src/handler.py` 文件中编写一个 Lambda 函数。在此文件中，您可以找到在启动项目时就已创建的名为 `preCreate`、`preUpdate`、和 `preDelete` 的方法。您的目标是编写一个通用、可重复使用的函数，该函数可以主动模式使用 适用于 Python (Boto3) 的 AWS SDK 调用 AWS Config `StartResourceEvaluation` API。此 API 调用将资源属性作为输入，并根据规则定义评估资源。
```
def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent:
LOG.info("Fetching proactive data")
config_client = boto3.client('config')
resource_specs = {
'ResourceId': 'MyFunction',
'ResourceType': resource_type,
'ResourceConfiguration': json.dumps(function_properties),
'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA'
}
LOG.info("Resource Specifications:", resource_specs)
eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60)
ResourceEvaluationId = eval_response.ResourceEvaluationId
compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId)
LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType)
if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType:
return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant)
else:
return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.")
```
现在，您可以从预创建钩子的处理程序中调用通用函数。下面是处理程序的示例：
```
@hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION)
def pre_create_handler(
session: Optional[SessionProxy],
request: HookHandlerRequest,
callback_context: MutableMapping[str, Any],
type_configuration: TypeConfigurationModel
) -> ProgressEvent:
LOG.info("Starting execution of the hook")
target_name = request.hookContext.targetName
LOG.info("Target Name:", target_name)
if "AWS::Lambda::Function" == target_name:
return validate_lambda_tracing_config(target_name,
request.hookContext.targetModel.get("resourceProperties")
)
else:
raise exceptions.InvalidRequest(f"Unknown target type: {target_name}")
```
完成此步骤后，您可以注册钩子并将其配置为侦听所有 AWS Lambda 函数创建事件。
开发人员使用 Lambda 为无服务器微服务准备基础设施即代码（IaC）模板。准备工作包括遵守内部标准，然后进行本地测试并将模板提交到存储库。IaC 模板示例如下：
```
MyLambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
Handler: index.handler
Role: !GetAtt LambdaExecutionRole.Arn
FunctionName: MyLambdaFunction
Code:
ZipFile: |
import json
def handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello World!')
}
Runtime: python3.14
TracingConfig:
Mode: PassThrough
MemorySize: 256
Timeout: 10
```
作为 CI/CD 流程的一部分，在部署 CloudFormation 模板时，CloudFormation 服务会在预置 `AWS::Lambda::Function` 资源类型之前调用预创建/更新钩子。该钩子利用在主动模式下运行的 AWS Config 规则来验证 Lambda 函数配置是否包含规定的跟踪配置。来自钩子的响应决定了下一步行动。如果合规，则钩子会发出成功响应，CloudFormation 将继续预置资源。否则，CloudFormation 堆栈部署将失败，管道会立即停止，系统会记录详细信息以供后续审查。合规性通知将被发送到相关利益方。
您可以在 CloudFormation 控制台中找到钩子成功/失败信息：
![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-config-2.png)
如果您为 CloudFormation 钩子启用了日志，则可以捕获钩子评估结果。以下是状态为失败的钩子的示例日志，表明 Lambda 函数未启用 X-Ray：
![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-config-3.png)
如果开发者选择更改 IaC，将 `TracingConfig Mode` 值更新为 `Active` 并重新部署，则钩子将成功执行，堆栈会继续创建 Lambda 资源。
![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-config-4.png)
这样，在开发和部署 AWS 账户中的无服务器资源时，您就可以通过 AWS Config 以主动模式实施预防性控制。通过将 AWS Config 规则集成到 CI/CD 管道中，您可以识别并选择阻止不合规的资源部署，例如缺乏活动跟踪配置的 Lambda 函数。这样可以确保只有符合最新治理策略的资源才会部署到您的 AWS 环境中。
# 使用 AWS Config 检测不合规的 Lambda 部署和配置
除了[主动性评估](governance-config.md)外，AWS Config 还可以被动检测不符合您的治理策略的资源部署和配置。被动侦测非常重要，因为治理策略会随着组织学习和实施新的最佳实践而不断演变。
假设您在部署或更新 Lambda 函数时设置了全新的策略：所有 Lambda 函数都必须始终使用特定的、经批准的 Lambda 层版本。您可以配置 AWS Config 来监控新函数或更新函数的层配置。如果 AWS Config 检测到某函数未使用已批准的层版本，则会将该函数标记为不合规资源。您可以选择配置 AWS Config，通过使用 AWS Systems Manager 自动化文档指定补救操作来自动修复资源。例如，您可以通过 适用于 Python (Boto3) 的 AWS SDK 使用 Python 编写自动化文档，将不合规函数更新为指向已批准的层版本。因此，AWS Config 既可以作为检测性控制，也可以作为纠正性控制，实现了合规性管理的自动化。
让我们将这个过程分解为三个重要的实施阶段：
![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-config-detective-1.png)
## 第 1 阶段：确定访问资源
首先在账户中激活 AWS Config，然后将其配置为记录 AWS Lambda 函数。这样，AWS Config 就可以观测到 Lambda 函数的创建或更新时间。然后，您可以配置使用 AWS CloudFormation Guard 语法的[自定义策略规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html)来检查是否存在特定的策略违规行为。Guard 规则的一般形式如下：
```
rule name when condition { assertion }
```
以下示例规则用于确保层未设置为旧版本：
```
rule desiredlayer when configuration.layers !empty {
some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}
```
让我们来了解一下规则的语法和结构：
+ **规则名称：**所提供的示例中的规则名称为 `desiredlayer`。
+ **条件：**此子句指定了检查规则的条件。在所提供的示例中，条件为 `configuration.layers !empty`。这意味着只有在配置中的 `layers` 属性不为空时，才会对资源进行评估。
+ **断言：**在 `when` 子句之后，断言决定了规则检查的内容。该断言 `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` 会检查是否有任何 Lambda 层 ARN 与 `OldLayerArn` 值不匹配。如果不匹配，则断言为真，规则通过；否则，规则失败。
`CONFIG_RULE_PARAMETERS` 是使用 AWS Config 规则配置的一组特殊参数。在本例中，`OldLayerArn` 是 `CONFIG_RULE_PARAMETERS` 中的一个参数。这样，用户可以提供其认为已过时或已弃用的特定 ARN 值，然后该规则就会检查是否有任何 Lambda 函数正在使用此旧 ARN。
## 第 2 阶段：可视化和设计
AWS Config 收集配置数据并将这些数据存储在 Amazon Simple Storage Service（Amazon S3）存储桶中。您可以使用 [Amazon Athena](https://aws.amazon.com/athena/) 直接从 S3 存储桶中查询这些数据。通过 Athena，您可以在组织层面聚合这些数据，从而生成所有账户中资源配置的整体视图。要设置资源配置数据的聚合，请参阅 AWS Cloud Operations and Management Blog 上的 [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)。
以下是一个 Athena 查询示例，用于确定使用特定层 ARN 的所有 Lambda 函数：
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.version') AS version
FROM
unnested
WHERE
lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%'
```
以下是查询的结果：
![\[Query results in Athena console.\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-config-detective-2.png)
聚合整个组织的 AWS Config 数据后，就可以使用 [Amazon Quick](https://aws.amazon.com/quicksight/) 创建控制面板。通过将 Athena 结果导入 Quick，您可以直观地了解 Lambda 函数在多大程度上遵守了层版本规则。此控制面板可以突出显示合规资源和不合规资源，从而有助于您确定执行策略，如[下一节](#governance-config-detective-implement)所述。下图是一个示例控制面板，用于报告应用于组织内函数的层版本的分布情况。
![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-config-detective-3.png)
## 第 3 阶段：实施和强制执行
现在，您可以选择通过 Systems Manager 自动化文档将您在[第 1 阶段](#governance-config-detective-identify)创建的层版本规则与补救操作配对，该文档是您使用 适用于 Python (Boto3) 的 AWS SDK 编写的 Python 脚本。该脚本将调用每个 Lambda 函数的 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API 操作，从而使用新的层 ARN 更新函数配置。您也可以使用脚本向代码存储库提交拉取请求以更新层 ARN。这样，未来的代码部署也将使用正确的层 ARN 进行更新。
# 使用 AWS Signer 的 Lambda 代码签名
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) 是一项完全托管的代码签名服务，让您可以根据数字签名验证代码，从而确认代码未被更改且来自可信的发布者。AWS Signer 可以与 AWS Lambda 结合使用，用于验证函数和层在部署到您的 AWS 环境之前未被更改。这可以保护您的组织免受恶意行为者的侵害，这些恶意行为者可能已获得创建新函数或更新现有函数的凭证。
要为 Lambda 函数设置代码签名，请先创建一个启用了版本控制的 S3 存储桶。之后，使用 AWS Signer 创建签名配置文件，将 Lambda 指定为平台，然后指定签名配置文件的有效期限。例如：
```
Signer:
Type: AWS::Signer::SigningProfile
Properties:
PlatformId: AWSLambda-SHA384-ECDSA
SignatureValidityPeriod:
Type: DAYS
Value: !Ref pValidDays
```
然后使用签名配置文件，并通过 Lambda 创建签名配置。当签名配置看到与预期数字签名不匹配的构件时，必须指定要采取的措施：警告（但允许部署）或强制执行（并阻止部署）。以下示例配置为强制执行并阻止部署。
```
SigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
AllowedPublishers:
SigningProfileVersionArns:
- !GetAtt Signer.ProfileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: Enforce
```
现在，您已将 AWS Signer 与 Lambda 一同配置，以阻止不受信任的部署。假设您已完成功能请求的编码，现在准备好部署该函数。第一步是使用相应的依赖项压缩代码，然后使用您创建的签名配置文件对构件进行签名。为此，您可以将 zip 构件上传到 S3 存储桶，然后启动签名作业。
```
aws signer start-signing-job \
--source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \
--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \
--profile-name your-signer-id
```
您将获得如下输出，其中 `jobId` 是在目标存储桶和前缀中创建的对象，`jobOwner` 是运行作业的 12 位 AWS 账户 ID。
```
{
"jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",
"jobOwner": "111122223333"
}
```
现在，您可以使用已签名的 S3 对象和创建的代码签名配置来部署您的函数。
```
Fn:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip
Handler: fn.handler
Role: !GetAtt FnRole.Arn
CodeSigningConfigArn: !Ref pSigningConfigArn
```
或者，您也可以使用原始的未签名源 zip 构件来测试函数部署。部署失败时会显示如下消息：。
```
Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.
```
如果您使用 AWS Serverless Application Model（AWS SAM）构建和部署函数，程序包命令会处理将 zip 构件上传到 S3 的作业，还会启动签名作业并获取已签名的构件。您可以使用参数和命令执行该操作：
```
sam package -t your-template.yaml \
--output-template-file your-output.yaml \
--s3-bucket your-versioned-bucket \
--s3-prefix your-prefix \
--signing-profiles your-signer-id
```
AWS Signer 可帮助您验证部署到账户中的 zip 构件是否值得信任，可用于部署。您可以将上述过程包含在 CI/CD 管道中，并要求所有函数都附加使用前面主题中概述的技术的代码签名配置。通过在 Lambda 函数部署中使用代码签名，可以防止恶意行为者在获得创建或更新函数的凭证后在函数中注入恶意代码。
# 使用 Amazon Inspector 自动执行 Lambda 的安全评测
[Amazon Inspector](https://aws.amazon.com/inspector/) 是一项漏洞管理服务，可持续扫描您的工作负载，查找已知的软件漏洞和意外的网络暴露。Amazon Inspector 会创建调查发现，该调查发现将描述漏洞，确定受影响的资源，对漏洞的严重性进行评级，并提供补救指导。
Amazon Inspector 支持可为 Lambda 函数和层提供持续、自动的安全漏洞评测。Amazon Inspector 提供两种 Lambda 扫描类型：
+ **Lambda 标准扫描（默认）：**扫描 Lambda 函数及其层中的应用程序依赖项，以便查找[程序包漏洞](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package)。
+ **Lambda 代码扫描：**扫描函数中及其层中的自定义应用程序代码，以便查找[代码漏洞](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code)。您可以单独激活 Lambda 标准扫描，也可以同时激活 Lambda 标准扫描和 Lambda 代码扫描。
要启用 Amazon Inspector，请导航到 [Amazon Inspector 控制台](https://console.aws.amazon.com/inspector/)，展开**设置**部分，然后选择**账户管理**。在**账户**选项卡上，选择**激活**，然后选择其中一个扫描选项。
在设置 Amazon Inspector 时，您可以为多个账户启用 Amazon Inspector，并将该组织的 Amazon Inspector 管理权限委托给特定账户。启用时，您需要通过创建角色 `AWSServiceRoleForAmazonInspector2` 来授予 Amazon Inspector 权限。您可以通过 Amazon Inspector 控制台使用一键式选项创建此角色。
对于 Lambda 标准扫描，Amazon Inspector 会在以下情况下对 Lambda 函数启动漏洞扫描：
+ Amazon Inspector 发现现有 Lambda 函数时。
+ 部署新的 Lambda 函数时。
+ 部署现有 Lambda 函数或其层的应用程序代码或依赖项更新时。
+ Amazon Inspector 在其数据库中添加新的常见脆弱性和风险 (CVE) 项目，且该 CVE 与您的函数相关时。
对于 Lambda 代码扫描，Amazon Inspector 会使用自动推理和机器学习来评估 Lambda 函数应用程序代码，分析应用程序代码的总体安全合规性。如果 Amazon Inspector 在 Lambda 函数应用程序代码中检测到漏洞，Amazon Inspector 会生成详细的**代码漏洞**的调查发现。有关可能的检测的列表，请参阅 [Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/)。
要查看调查发现，请前往 [Amazon Inspector 控制台](https://console.aws.amazon.com/inspector/)。在**调查发现**菜单上，选择**按 Lambda 函数**，以显示对 Lambda 函数执行的安全扫描结果。
要从标准扫描中排除 Lambda 函数，请使用以下键值对标记函数：
+ `Key:InspectorExclusion`
+ `Value:LambdaStandardScanning`
要从代码扫描中排除 Lambda 函数，请使用以下键值对标记函数：
+ `Key:InspectorCodeExclusion`
+ `Value:``LambdaCodeScanning`
例如，如下图所示，Amazon Inspector 会自动检测漏洞并将发现的漏洞归类为**代码漏洞**类型，这表明漏洞存在于函数的代码中，而不是存在于某个依赖于代码的库中。您可以同时查看特定函数或多个函数的这些详细信息。
![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-code-scanning-1.png)
您可以进一步深入了解这些调查发现，并学习如何补救问题。
![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-code-scanning-2.png)
在使用 Lambda 函数时，请确保遵守 Lambda 函数的命名约定。有关更多信息，请参阅 [使用 Lambda 环境变量](configuration-envvars.md)。
您应对自己接受的补救建议负责。在接受补救建议之前，请务必仔细审视这些建议。您可能需要对补救建议进行编辑，以确保代码符合您的预期。
# 实施可观测性以实现 Lambda 安全性和合规性
AWS Config 是查找和修复不合规的 AWS 无服务器资源的有用工具。您对无服务器资源所做的每一次更改都会记录在 AWS Config 中。此外，AWS Config 还允许您将配置快照数据存储在 S3 上。您可以使用 Amazon Athena 和 Amazon Quick 制作控制面板并查看 AWS Config 数据。在 [使用 AWS Config 检测不合规的 Lambda 部署和配置](governance-config-detection.md) 中，我们讨论了如何可视化特定配置（如 Lambda 层）。本主题将扩展这些概念。
## Lambda 配置的可见性
您可以使用查询来拉取重要的配置，例如 AWS 账户 ID、区域、AWS X-Ray 跟踪配置、VPC 配置、内存大小、运行时系统和标签。您可以通过下面的查询示例来从 Athena 中拉取这些信息：
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
account_id,
tags,
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.runtime') AS version
json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig
json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig
FROM
unnested
```
您可以使用查询来构建 Quick 控制面板并可视化数据。要聚合 AWS 资源配置数据，在 Athena 中创建表，以及根据来自 Athena 的数据构建 Quick 控制面板，请参阅 AWS Cloud Operations and Management Blog 上的 [Visualizing AWS Config data using Athena and Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)。值得注意的是，此查询还会检索函数的标签信息。这样就可以更深入地了解您的工作负载和环境，尤其是在您使用自定义标签的情况下。
![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-observability-1.png)
有关您可以执行的操作的更多信息，请参阅本主题后面的 [处理可观测性调查发现](#governance-observability-addressing) 部分。
## Lambda 合规性的可见性
通过 AWS Config 生成的数据，您可以创建组织级别的控制面板来监控合规性。这样就可以对以下内容实现一致的跟踪和监控：
+ 按合规性分数列出的合规包
+ 按不合规资源列出的规则
+ 合规性状态
![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-observability-2.png)
检查每条规则，找出该规则的不合规资源。例如，如果您的组织要求所有 Lambda 函数都必须与 VPC 关联，并且您已经部署了用于识别合规性的 AWS Config 规则，则可以在上面的列表中选择 `lambda-inside-vpc` 规则。
![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-observability-3.png)
有关您可以执行的操作的更多信息，请下面的 [处理可观测性调查发现](#governance-observability-addressing) 部分。
## 使用 Security Hub CSPM 查看 Lambda 函数边界的可见性
![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-observability-4.png)
为确保包括 Lambda 在内的 AWS 服务的安全使用，AWS 引入了基础安全最佳实践 v1.0.0。这套最佳实践为保护 AWS 环境中的资源和数据提供了明确的指导原则，强调了保持强大安全态势的重要性。AWS Security Hub CSPM 提供了一个统一的安全性和合规性中心，从而对此进行了补充。它汇总、组织并优先处理来自多个 AWS 服务的安全调查发现，如 Amazon Inspector、AWS Identity and Access Management Access Analyzer 和 Amazon GuardDuty。
如果您在 AWS 组织中启用了 Security Hub CSPM、Amazon Inspector、IAM Access Analyzer 和 GuardDuty，则 Security Hub CSPM 会自动汇总来自这些服务的调查发现。例如，让我们来看一下 Amazon Inspector。通过 Security Hub CSPM，您可以有效地识别 Lambda 函数中的代码和程序包漏洞。在 Security Hub CSPM 控制台中，导航到底部标有**来自 AWS 集成的最新调查发现**的部分。在这里，您可以查看和分析来自各种集成的 AWS 服务的调查发现。
![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-observability-5.png)
要查看详细信息，请选择第二列中的**查看调查发现**链接。这将显示按产品（例如 Amazon Inspector）筛选的调查发现列表。要将搜索范围限制为 Lambda 函数，请将 `ResourceType` 设置为 `AwsLambdaFunction`。这将显示 Amazon Inspector 与 Lambda 函数相关的调查发现。
![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/governance-observability-6.png)
对于 GuardDuty，您可以识别可疑的网络流量模式。此类异常情况可能表明您的 Lambda 函数中存在潜在的恶意代码。
通过 IAM Access Analyzer，您可以检查策略，尤其是那些带有向外部实体授予函数访问权限的条件语句的策略。此外，IAM Access Analyzer 还会评估在使用 Lambda API 中 [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) 操作时与 `EventSourceToken` 一起设置的权限。
## 处理可观测性调查发现
鉴于 Lambda 函数的可配置范围很广，而且要求各不相同，因此标准化的自动化补救解决方案可能无法适用于所有情况。此外，在不同的环境中，变更的实施方式也有所不同。如果您遇到任何看似不合规的配置，请考虑以下指导原则：
1. **标记策略**
我们建议实施全面的标记策略。每个 Lambda 函数都应使用关键信息进行标记，例如以下信息：
+ **所有者：**负责该函数的人员或团队。
+ **环境：**生产、暂存、开发或沙盒。
+ **应用程序：**此函数所属的更广泛上下文（如果适用）。
1. **所有者外联活动**
与其自动进行重大更改（例如 VPC 配置调整），不如主动联系不合规函数（通过所有者标签标识）的所有者，方便其拥有足够时间执行以下任一操作：
+ 调整 Lambda 函数上的不合规配置。
+ 提供解释并申请例外情况，或完善合规标准。
1. **维护配置管理数据库（CMDB）**
虽然标签可以提供即时上下文，但通过维护集中式 CMDB，可以提供更深入的见解。CMDB 可以保存有关每个 Lambda 函数、其依赖关系和其他关键元数据的更精细的信息。CMDB 是审计、合规性检查和识别函数所有者的宝贵资源。
随着无服务器基础设施状况的不断演变，采取积极主动的监控态度至关重要。通过 AWS Config、Security Hub CSPM 和 Amazon Inspector 等工具，可以快速识别出潜在的异常或不合规配置。但是，仅靠工具并不能确保完全合规或使用最佳配置。将这些工具与有据可查的流程和最佳实践相结合至关重要。
+ **反馈环路：**确保采取补救措施后会有反馈环路。这意味着要定期重访不合规资源，以确认其是否已更新，或是否在存在相同问题的情况下继续运行。
+ **文档：**务必记录观察结果、采取的行动以及批准的任何例外情况。适当的文档不仅有助于审计，而且还有助于改进流程，从而在将来提高合规性和安全性。
+ **培训和意识：**确保所有利益相关者（特别是 Lambda 函数所有者），定期接受培训，并了解最佳实践、组织策略和合规要求。定期举办研讨会、网络研讨会或培训课程，对确保每个人就安全性和合规性保持一致意见大有裨益。
总而言之，尽管工具和技术为检测和标记潜在问题提供了强大功能，但人的因素（理解、沟通、培训和文档）仍然至关重要。它们共同构成了强大的组合，可确保您的 Lambda 函数和更广泛的基础设施保持合规性、安全性并根据您的业务需求进行优化。
# AWS Lambda 的合规性验证
作为多个 AWS Lambda 合规性计划的一部分，第三方审计员将评估 AWS 的安全性和合规性。其中包括 SOC、PCI、FedRAMP、HIPAA 及其他。
有关特定合规性计划范围内的 AWS 服务的列表，请参阅[合规性计划范围内的 AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)。有关一般信息，请参阅 [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)。
您可以使用 AWS Artifact 下载第三方审计报告。有关更多信息，请参阅[下载AWS构件中的报告](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。
您在使用 Lambda 时的合规性责任由您的数据的敏感性、您公司的合规性目标以及适用的法律法规决定。您可以实施治理控制，以确保贵公司的 Lambda 函数符合合规要求。有关更多信息，请参阅 [为 Lambda 函数和层创建治理策略](governance-concepts.md)。
# AWS Lambda 中的故障恢复能力
AWS全球基础架构围绕AWS区域和可用区构建。AWS区域提供多个在物理上独立且隔离的可用区，这些可用区通过延迟低、吞吐量高且冗余性高的网络连接在一起。利用可用区，您可以设计和操作在可用区之间无中断地自动实现故障转移的应用程序和数据库。与传统的单个或多个数据中心基础架构相比，可用区具有更高的可用性、容错性和可扩展性。
有关 AWS 区域和可用区的更多信息，请参阅 [AWS 全球基础设施](https://aws.amazon.com/about-aws/global-infrastructure/)。
除了AWS全球基础设施之外，Lambda 还提供了多种功能，以帮助支持您的数据故障恢复能力和备份需求。
+ **版本控制** – 您可以在 Lambda 中使用版本控制，在开发时保存函数的代码和配置。与别名相配合，您可以使用版本控制来执行蓝/绿和滚动部署。有关详细信息，请参阅[管理 Lambda 函数版本](configuration-versions.md)。
+ **扩展** – 当您的函数在处理之前的请求时收到新的请求，Lambda 会启动另一个函数实例来处理增加的负载。Lambda 会弹性伸缩以处理每个区域 1000 个并发执行，[配额](gettingstarted-limits.md)可以根据需要增加。有关详细信息，请参阅[了解 Lambda 函数扩展](lambda-concurrency.md)。
+ **高可用性** – Lambda 会在多个可用区中运行您的函数，确保在单一区域中服务中断时能够处理事件。如果将函数配置为连接到账户中的 Virtual Private Cloud (VPC)，请在多个可用区中指定子网以确保高可用性。有关详细信息，请参阅[授予 Lambda 函数访问 Amazon VPC 中资源的权限](configuration-vpc.md)。
+ **预留并发** – 要确保您的函数能够始终扩展以处理更多请求，您可以为其预留并发。为函数设置预留并发可确保其能够扩展（但不超出）指定数量的并发调用。这可确保您不会因为其他函数使用了所有可用的并发而丢失请求。有关详细信息，请参阅[为函数配置预留并发](configuration-concurrency.md)。
+ **重试** – 对于异步调用和由其他服务触发的调用子集，Lambda 会在遇到错误时自动重试（每次重试有延迟）。同步调用函数的其他客户端和 AWS 服务 负责执行重试。有关详细信息，请参阅[了解 Lambda 中的重试行为](invocation-retries.md)。
+ **死信队列** – 对于异步调用，如果所有重试都失败，您可以配置 Lambda 向死信队列发送请求。死信队列是 Amazon SNS 主题或 Amazon SQS 队列，它会接收事件进行故障排除或重新处理。有关详细信息，请参阅[添加死信队列](invocation-async-retain-records.md#invocation-dlq)。
# 中的基础设施安全性AWS Lambda
作为一项托管服务，AWS Lambda 受 AWS 全球网络安全保护。有关 AWS 安全服务以及 AWS 如何保护基础结构的信息，请参阅 [AWS 云安全](https://aws.amazon.com/security/)。要按照基础设施安全最佳实践设计您的 AWS 环境，请参阅*《安全性支柱 AWS Well‐Architected Framework》*中的 [基础设施保护](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)。
您可以使用AWS发布的 API 调用，通过网络访问 Lambda。客户端必须支持以下内容：
+ 传输层安全性协议（TLS）。我们要求使用 TLS 1.2，建议使用 TLS 1.3。
+ 具有完全向前保密（PFS）的密码套件，例如 DHE（临时 Diffie-Hellman）或 ECDHE（临时椭圆曲线 Diffie-Hellman）。大多数现代系统（如 Java 7 及更高版本）都支持这些模式。
# 使用公共端点保护工作负载
对于可公开访问的工作负载，AWS 提供了许多有助于降低某些风险的功能和服务。本节介绍应用程序用户的身份验证和授权以及保护 API 端点。
## 身份验证和授权
身份验证与身份相关，授权涉及操作。使用身份验证来控制谁可以调用 Lambda 函数，然后使用授权来控制调用者可以执行的操作。对于许多应用程序来说，IAM 足以管理这两种控制机制。
对于具有外部用户的应用程序，例如 Web 或移动应用程序，通常使用 [JSON Web 令牌](https://jwt.io/introduction/)（JWT）来管理身份验证和授权。与传统的基于服务器的密码管理不同，JWT 在每次请求时都会从客户端传递。它们是一种加密的安全方式，可使用从客户端传递的数据来验证身份和声明。对于基于 Lambda 的应用程序，这使您可以保护对每个 API 端点的每次调用，而无需依赖中央服务器进行身份验证。
您可以[使用 Amazon Cognito 实施 JWT](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)，这是一种可以处理注册、身份验证、账户恢复和其他常见账户管理操作的用户目录服务。[Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) 提供了一些库，可简化将此服务集成到前端应用程序中的过程。您还可以考虑第三方合作伙伴服务，例如 [Auth0](https://auth0.com/)。
鉴于身份提供者服务的关键安全角色，使用专业工具来保护您的应用程序非常重要。不建议您自己编写服务来处理身份验证或授权。自定义库中的任何漏洞都可能对您的工作负载及其数据的安全性产生重大影响。
## 保护 API 端点
对于无服务器应用程序，公开为后端应用程序提供服务的首选方式是使用 Amazon API Gateway。这可以帮助您保护 API 免受恶意用户或流量激增的侵害。
API Gateway 为无服务器开发人员提供了两种端点类型：[REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) 和 [HTTP API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html)。两者都支持[使用 AWS Lambda 授权](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)、IAM 授权或 Amazon Cognito 授权。使用 IAM 或 Amazon Cognito 时，会评估传入的请求，如果这些请求缺少所需的令牌或包含无效的身份验证，则会拒绝该请求。您无需为这些请求付费，并且这些请求不计入任何限制配额。
公共互联网上的任何人皆可访问未经身份验证的 API 路由，因此建议您限制使用未经身份验证的 API。如果您必须使用未经身份验证的 API，务必保护它们免受常见风险，例如[拒绝服务（DoS）](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻击。[将 AWS WAF 应用](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)到这些 API 可以帮助保护您的应用程序免受 SQL 注入和跨站脚本攻击（XSS）。使用 API 密钥时，API Gateway 还会在 AWS 账户级别和每个客户端级别实施[节流](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)。
在许多情况下，未经身份验证的 API 所提供的功能可以通过其他方法来实现。例如，Web 应用程序可以向未登录的用户提供来自 DynamoDB 表的客户零售商店列表。此请求可能来自前端 Web 应用程序或任何其他调用 URL 端点的源。此图比较了三种解决方案：
![\[安全运营图 5\]](http://docs.aws.amazon.com/zh_cn/lambda/latest/dg/images/security-ops-figure-5.png)
1. 互联网上的任何人都可以调用此未经身份验证的 API。在拒绝服务攻击中，可能会耗尽底层表上的 API 节流限制、Lambda 并发或 DynamoDB 预调配的读取容量。
1. 在 API 端点前面使用适当的[生存时间](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html)（TTL）配置的 CloudFront 分配将承受 DoS 攻击中的大部分流量，而无需更改用于获取数据的底层解决方案。
1. 另外，对于很少更改的静态数据，CloudFront 分配可以提供来自 Amazon S3 存储桶的数据。
# 使用代码签名通过 Lambda 验证代码完整性
代码签名有助于确保只有可信代码部署到您的 Lambda 函数。使用 AWS Signer，您可以为您的函数创建数字签名的代码包。当您[向函数添加代码签名配置](configuration-codesigning-create.md)时，Lambda 会验证所有新代码部署是否由可信来源签名。由于代码签名验证检查在部署时运行，因此对函数执行没有影响。
**重要**
代码签名配置仅阻止未签名代码的新部署。如果将代码签名配置添加到具有未签名代码的现有函数，则该代码将一直运行，直到您部署新的代码包。
当您为某个函数启用代码签名时，您添加到该函数的任何[层](chapter-layers.md)也必须由允许的签名配置文件进行签名。
使用 AWS Signer 或 AWS Lambda 代码签名不收取任何额外费用。
## 签名验证
将签名代码包部署到函数时，Lambda 会执行以下验证检查：
1. **完整性**：验证代码包自签名以来是否尚未修改。Lambda 将包的哈希值与签名的哈希值进行比较。
1. **过期**：验证代码包的签名是否尚未过期。
1. **不匹配**：验证代码包是否使用允许的签名配置文件进行签名
1. **撤销**：验证代码包的签名是否尚未撤销。
创建代码签名配置时，您可以使用 [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment) 参数来指定在过期、不匹配或撤销检查失败时 Lambda 应如何响应。您可以选择以下操作之一：
+ `Warn`：这是默认设置。Lambda 允许部署代码包，但会发出警告。Lambda 发布新的 Amazon CloudWatch 指标 (`SignatureValidationErrors`)，并将警告存储在 CloudTrail 日志中。
+ `Enforce` Lambda 发出警告（与 `Warn` 操作相同）并阻止代码包的部署。
**Topics**
+ [签名验证](#config-codesigning-valid)
+ [为 Lambda 创建代码签名配置](configuration-codesigning-create.md)
+ [为 Lambda 代码签名配置 IAM 策略](config-codesigning-policies.md)
+ [在代码签名配置上使用标签](tags-csc.md)
# 为 Lambda 创建代码签名配置
要为函数启用代码签名，您需要创建*代码签名配置*并将其附加到函数。代码签名配置定义了允许的签名配置文件列表以及在任意一项验证检查失败时要采取的策略操作。
**注意**
定义为容器映像的函数不支持代码签名。
**Topics**
+ [配置先决条件](#config-codesigning-prereqs)
+ [创建代码签名配置](#config-codesigning-config-console)
+ [为函数启用代码签名](#config-codesigning-function-console)
## 配置先决条件
为 Lambda 函数配置代码签名之前，请使用 AWS Signer 执行以下操作：
+ 创建一个或多个[签名配置文件](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html)。
+ 使用签名配置文件[为函数创建签名代码包](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html)。
## 创建代码签名配置
代码签名配置定义允许的签名配置文件列表和签名验证策略。
**创建代码签名配置（控制台）**
1. 打开 Lambda 控制台的 [Code signing configurations（代码签名配置）页面](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)。
1. 选择 **Create configuration**（创建配置）。
1. 对于 **Description（描述）**，输入一个描述性的配置名称。
1. 在 **Signing profiles**（签名配置文件）下，最多可以在配置中添加 20 个签名配置文件。
1. 对于 **Signing profile version ARN（签名配置文件版本 ARN）**，选择配置文件版本的 Amazon 资源名称 (ARN) 或输入 ARN。
1. 要添加其他签名配置文件，请选择 **Add signing profiles（添加签名配置文件）**。
1. 在 **Signature validation policy**（签名验证策略）下，选择 **Warn**（警告）或 **Enforce**（强制执行）。
1. 选择 **Create configuration**（创建配置）。
## 为函数启用代码签名
要为函数启用代码签名，请向该函数添加代码签名配置。
**重要**
代码签名配置仅阻止未签名代码的新部署。如果将代码签名配置添加到具有未签名代码的现有函数，则该代码将一直运行，直到您部署新的代码包。
**将代码签名配置与函数关联（控制台）**
1. 打开 Lamba 控制台的[函数页面](https://console.aws.amazon.com/lambda/home#/functions)。
1. 选择要启用代码签名的函数。
1. 打开 **Configuration**（配置）选项卡。
1. 向下滚动并选择**代码签名**。
1. 选择**编辑**。
1. 在 **Edit code signing（编辑代码签名）**中，为此函数选择代码签名配置。
1. 选择**保存**。
# 为 Lambda 代码签名配置 IAM 策略
要授予用户访问 Lambda 代码签名 API 操作的权限，请将一个或多个策略声明附加到用户策略。有关用户策略的详细信息，请参阅[Lambda 的基于身份的 IAM policy](access-control-identity-based.md)。
以下示例策略声明将授予创建、更新和检索代码签名配置的权限。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
管理员可以使用 `CodeSigningConfigArn` 条件键指定开发人员创建或更新函数时必须使用的代码签名配置。
以下示例策略声明将授予创建函数的权限。策略声明包括指定允许的代码签名配置的 `lambda:CodeSigningConfigArn` 条件。如果 [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn) 参数缺失或与条件中的值不匹配，则 Lambda 会阻止 `CreateFunction` API 请求。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReferencingCodeSigningConfig",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6"
}
}
}
]
}
```
------
# 在代码签名配置上使用标签
对代码签名配置进行标签可以组织和管理资源。标签是与资源关联的自由格式键值对，在 AWS 服务 中受支持。有关标签用例的更多信息，请参阅《Tagging AWS Resources and Tag Editor Guide》**中的 [Common tagging strategies](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies)。
可以使用 AWS Lambda API 来查看和更新标签。在 Lambda 控制台中管理特定的代码签名配置时，还可以查看和更新标签。
**Topics**
+ [使用标签所需的权限](#csc-tags-required-permissions)
+ [通过 Lambda 控制台使用标签](#tags-csc-console)
+ [通过 AWS CLI 使用标签](#tags-csc-cli)
## 使用标签所需的权限
要允许 AWS Identity and Access Management（IAM）身份（用户、组或角色）读取资源或为其设置标签，请授予该身份相应的权限：
+ **lambda:ListTags** – 当资源有标签时，将此权限授予需要在其上调用 `ListTags` 的任何人。对于带标签的函数，`GetFunction` 也需要此权限。
+ **lambda:TagResource** – 将此权限授予需要调用 `TagResource` 或执行在创建时授予标记的操作的任何人。
或者，也可以考虑授予 **lambda:UntagResource** 权限以允许 `UntagResource` 调用该资源。
有关更多信息，请参阅 [Lambda 的基于身份的 IAM policy](access-control-identity-based.md)。
## 通过 Lambda 控制台使用标签
可以使用 Lambda 控制台创建带标签的代码签名配置、向现有代码签名配置添加标签、按标签筛选代码签名配置。
**在创建代码签名配置时添加标签**
1. 在 Lambda 控制台中打开[代码签名配置](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)。
1. 从内容窗格的标题中选择**创建配置**。
1. 在内容窗格的顶部区域中设置代码签名配置。有关设定代码签名配置的更多信息，请参阅[使用代码签名通过 Lambda 验证代码完整性](configuration-codesigning.md)。
1. 在**标签**部分，选择**添加新标签**。
1. 在**键**字段中输入标签键。有关标记限制的信息，请参阅《Tagging AWS Resources and Tag Editor Guide》中的 [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)。**
1. 选择**创建配置**。
**向现有代码签名配置添加标签**
1. 在 Lambda 控制台中打开[代码签名配置](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)。
1. 选择代码签名配置的名称。
1. 在**详细信息**窗格下方的选项卡中选择**标签**。
1. 选择**管理标签**。
1. 选择 **Add new tag（添加新标签）**。
1. 在**键**字段中输入标签键。有关标记限制的信息，请参阅《Tagging AWS Resources and Tag Editor Guide》中的 [Tag naming limits and requirements](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)。**
1. 选择**保存**。
**按标签筛选代码签名配置**
1. 在 Lambda 控制台中打开[代码签名配置](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)。
1. 选择搜索框。
1. 在下拉列表中，从**标签**副标题下方选择标签。
1. 选择**使用：“tag-name”**查看所有使用此键标记的代码签名配置，或者选择一个**运算符**进一步按值筛选。
1. 选择标签值以按标签键和值的组合进行筛选。
搜索框还支持搜索标签键。输入键名称，即可在列表中查找该键。
## 通过 AWS CLI 使用标签
可以使用 Lambda API 在现有 Lambda 资源（包括代码签名配置）上添加和删除标签。还可以在创建代码签名配置时添加标签，这样就可以在资源的整个生命周期中对其进行标记。
### 使用 Lambda 标签 API 更新标签
可以通过 [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) 和 [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) API 操作，添加和删除受支持 Lambda 资源的标签。
可以使用 AWS CLI 调用这些操作。要向现有资源添加标签，请使用 `tag-resource` 命令。此示例添加了两个标签，一个带有键 *Department*，另一个带有键 *CostCenter*。
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
要删除标签，请使用 `untag-resource` 命令。此示例删除了键为 *Department* 的标签。
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### 在创建代码签名配置时添加标签
若要使用标签创建新的 Lambda 代码签名配置，请使用 [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html) API 操作。指定 `Tags` 参数。可以使用 `create-code-signing-config` AWS CLI 命令和 `--tags` 选项调用此操作。有关 CLI 命令的更多信息，请参阅《AWS CLI Command Reference》中的 [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)。**
在将 `Tags` 参数与 `CreateCodeSigningConfig` 一起使用之前，请确保角色拥有标记资源的权限以及此操作所需的常规权限。有关标记权限的更多信息，请参阅 [使用标签所需的权限](#csc-tags-required-permissions)。
### 使用 Lambda 标签 API 查看标签
要查看应用于特定 Lambda 资源的标签，请使用 `ListTags` API 操作。有关更多信息，请参阅 [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)。
可以提供 ARN（Amazon 资源名称），以使用 `list-tags` AWS CLI 命令调用此操作。
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### 按标签筛选资源
您可以使用 AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) API 操作按标签筛选资源。`GetResources` 操作最多可接收 10 个筛选条件，每个筛选条件包含一个标签键和最多 10 个标签值。提供具有 `ResourceType` 的 `GetResources`，可按特定资源类型进行筛选。
可以使用 `get-resources` AWS CLI 命令调用此操作。有关使用 `get-resources` 的示例，请参阅《AWS CLI Command Reference》**中的 [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples)。