使用 Amazon Config 检测不合规的 Lambda 部署和配置 - Amazon Lambda
第 1 阶段：确定访问资源第 2 阶段：可视化和设计第 3 阶段：实施和强制执行
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

使用 Amazon Config 检测不合规的 Lambda 部署和配置

除了主动性评估外，Amazon Config 还可以被动检测不符合您的治理策略的资源部署和配置。被动侦测非常重要，因为治理策略会随着组织学习和实施新的最佳实践而不断演变。

假设您在部署或更新 Lambda 函数时设置了全新的策略：所有 Lambda 函数都必须始终使用特定的、经批准的 Lambda 层版本。您可以配置 Amazon Config 来监控新函数或更新函数的层配置。如果 Amazon Config 检测到某函数未使用已批准的层版本，则会将该函数标记为不合规资源。您可以选择配置 Amazon Config，通过使用 Amazon Systems Manager 自动化文档指定补救操作来自动修复资源。例如，您可以通过 Amazon SDK for Python (Boto3) 使用 Python 编写自动化文档，将不合规函数更新为指向已批准的层版本。因此，Amazon Config 既可以作为检测性控制，也可以作为纠正性控制，实现了合规性管理的自动化。

让我们将这个过程分解为三个重要的实施阶段：

The three implementation phases are identify, notify, and deploy remediation.

第 1 阶段：确定访问资源

首先在账户中激活 Amazon Config，然后将其配置为记录 Amazon Lambda 函数。这样，Amazon Config 就可以观测到 Lambda 函数的创建或更新时间。然后，您可以配置使用 Amazon CloudFormation Guard 语法的自定义策略规则来检查是否存在特定的策略违规行为。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 是使用 Amazon Config 规则配置的一组特殊参数。在本例中，OldLayerArn 是 CONFIG_RULE_PARAMETERS 中的一个参数。这样，用户可以提供其认为已过时或已弃用的特定 ARN 值，然后该规则就会检查是否有任何 Lambda 函数正在使用此旧 ARN。

第 2 阶段：可视化和设计

Amazon Config 收集配置数据并将这些数据存储在 Amazon Simple Storage Service（Amazon S3）存储桶中。您可以使用 Amazon Athena 直接从 S3 存储桶中查询这些数据。通过 Athena，您可以在组织层面聚合这些数据，从而生成所有账户中资源配置的整体视图。要设置资源配置数据的聚合，请参阅 Amazon Cloud Operations and Management Blog 上的 Visualizing Amazon Config data using 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.

聚合整个组织的 Amazon Config 数据后，就可以使用 Amazon QuickSight 创建控制面板。通过将 Athena 结果导入 Amazon QuickSight，您可以直观地了解 Lambda 函数在多大程度上遵守了层版本规则。此控制面板可以突出显示合规资源和不合规资源，从而有助于您确定执行策略，如下一节所述。下图是一个示例控制面板，用于报告应用于组织内函数的层版本的分布情况。

Example Amazon QuickSight dashboard shows distribution of layer versions in Lambda functions.

第 3 阶段：实施和强制执行

现在，您可以选择通过 Systems Manager 自动化文档将您在第 1 阶段创建的层版本规则与补救操作配对，该文档是您使用 Amazon SDK for Python (Boto3) 编写的 Python 脚本。该脚本将调用每个 Lambda 函数的 UpdateFunctionConfiguration API 操作，从而使用新的层 ARN 更新函数配置。您也可以使用脚本向代码存储库提交拉取请求以更新层 ARN。这样，未来的代码部署也将使用正确的层 ARN 进行更新。