IAM 访问分析器自定义策略检查的介绍

关键要点

在本文中，我们将讨论 AWS IAM 访问分析器自定义策略检查的最新功能。这一功能允许用户自动化检查 IAM 策略中的关键权限，为开发者提供快速反馈，以确保遵循安全标准。此外，我们将通过示例展示如何在开发工作流中集成这些检查，以高效地审查策略。

2024年7月12日： AWS 已扩展自定义策略检查，新增名为“检查无公共访问”的检查项。该检查可判断资源策略是否向特定资源类型提供公共访问。此外，现有的“检查未授予的访问”检查也进行更新，现在可以用于确定特定策略是否授予了对一个或多个客户定义的 AWS 资源的权限。本文中提到的 GitHub 示例代码 也已进行了更新，以反映这些更改。

AWS 身份和访问管理IAM访问分析器 于2019年底推出。它通过自动推理等分析技术，帮助客户在 Amazon Web Services (AWS) 中实现最小权限访问。今天，我们很高兴地宣布 IAM 访问分析器自定义策略检查的正式上线，这是一个新的功能，帮助客户精确、主动地检查 IAM 策略中的关键权限和政策的宽松程度。

在本文中，我们将展示如何将自定义策略检查集成到构建者工作流中，以自动识别过于宽松的 IAM 策略和包含您认为敏感或关键权限的 IAM 策略。

问题是什么？

虽然安全团队负责组织的整体安全态势，但开发者是创建应用程序的人员，这些应用程序需要权限。为使开发者能够快速推进，同时保持高水平的安全性，组织寻求安全地委托开发者编写 IAM 策略的能力。许多 AWS 客户在将开发者编写的策略部署到生产环境之前，会实施手动 IAM 策略审查。客户遵循这一做法以防止过多或不必要的权限进入生产环境。根据需要审查的策略的数量和复杂性，这些审查可能非常耗时且密集，导致开发速度放缓，并可能延迟应用程序和服务的部署。有些客户会编写自定义工具来减轻手动审查策略的负担，但这往往建造和维护的成本较高。

自定义策略检查如何解决这一问题？

自定义策略检查是 IAM 访问分析器的新功能，帮助安全团队准确和主动地识别策略中的关键权限。自定义策略检查还可以确定新版本的策略是否比之前的版本更加宽松。自定义策略检查利用自动推理静态分析的一种形式，为云中的安全性提供更高级别的保障。有关更多信息，请参阅 关于 AWS 安全的正式推理。

自定义策略检查可以嵌入持续集成和持续交付CI/CD管道中，以便可以在不部署策略的情况下，对策略进行检查。此外，开发者可从本地开发环境中运行自定义策略检查，快速获取所编写策略是否符合组织安全标准的反馈。

如何使用自定义策略检查分析 IAM 策略

在这一部分中，我们将提供使用自定义策略检查分析 IAM 策略的逐步说明。

前提条件

要完成以下示例中的演练，您需要满足以下条件：

拥有一个 AWS 账户，以及可以使用 AWS 服务并创建以下示例中使用的资源的身份。如果需要，请查看 GitHub 上的完整示例代码。安装并配置好的 AWS CLI。有关更多信息，请参见 配置 AWS CLI。AWS 云开发工具包AWS CDK。有关安装说明，请参阅 安装 AWS CDK。

示例 1：使用自定义策略检查比较两个 IAM 策略，检查一个是否未授予比另一个更多的访问权限

在此示例中，您将创建两个 IAM 身份策略文档，分别为 NewPolicyDocument 和 ExistingPolicyDocument。您将使用新的 CheckNoNewAccess API 来比较这两个策略，并检查 NewPolicyDocument 是否未授予比 ExistingPolicyDocument 更高的访问权限。

步骤 1：创建两个 IAM 身份策略文档

使用以下命令创建 ExistingPolicyDocument。

bashcat ltlt EOF gt existingpolicydocumentjson{ Version 20121017 Statement [ { Effect Allow Action [ ec2StartInstances ec2StopInstances ] Resource arnawsec2instance/ Condition { StringEquals { awsResourceTag/Owner {awsusername} } } } ]}EOF

使用以下命令创建 NewPolicyDocument。

bashcat ltlt EOF gt newpolicydocumentjson{ Version 20121017 Statement [ { Effect Allow Action [ ec2StartInstances ec2StopInstances ] Resource arnawsec2instance/ } ]}EOF

注意，ExistingPolicyDocument 在满足条件键 awsResourceTag/Owner 的情况下授予对 ec2StartInstances 和 ec2StopInstances 操作的访问。换句话说，标签的值与策略变量 awsusername 匹配。而 NewPolicyDocument 则授予相同操作的访问，但没有包含条件键。

步骤 2：使用 AWS CLI 检查策略

使用以下命令调用 CheckNoNewAccess API，检查 NewPolicyDocument 是否授予了比 ExistingPolicyDocument 更多的访问权限。

bashaws accessanalyzer checknonewaccess newpolicydocument file//newpolicydocumentjson existingpolicydocument file//existingpolicydocumentjson policytype IDENTITYPOLICY

稍等片刻，您将看到来自 Access Analyzer 的响应。响应将类似于以下内容。

json{ result FAIL message The modified permissions grant new access compared to your existing policy reasons [ { description New access in the statement with index 1 statementIndex 1 } ]}

在这个示例中，验证返回了 FAIL 结果。这是因为 NewPolicyDocument 缺少条件键，潜在地赋予任何附加了此身份策略的主体比预期或所需的更多访问权限。

示例 2：使用自定义策略检查确保 IAM 策略不包含敏感权限

在此示例中，您将创建一个包含一系列权限的 IAM 身份策略。您将使用 CheckAccessNotGranted API，检查新策略是否赋予了禁用 AWS CloudTrail 或删除任何相关轨迹的权限。

步骤 1：创建新的 IAM 身份策略文档

使用以下命令创建 IamPolicyDocument。

bashcat ltlt EOF gt iampolicydocumentjson{ Version 20121017 Statement [ { Effect Allow Action [ cloudtrailStopLogging cloudtrailDelete ] Resource [] } ]}EOF

步骤 2：使用 AWS CLI 检查策略

使用以下命令调用 CheckAccessNotGranted API，检查新策略是否授予了敏感操作的权限。在此示例中，您要求 Access Analyzer 检查 IamPolicyDocument 是否包含 cloudtrailStopLogging 或 cloudtrailDeleteTrail 操作作为列表传递给访问参数。

bashaws accessanalyzer checkaccessnotgranted policydocument file//iampolicydocumentjson access actions=cloudtrailStopLoggingcloudtrailDeleteTrail policytype IDENTITYPOLICY

由于您创建的策略同时包含了 cloudtrailStopLogging 和 cloudtrailDeleteTrail 操作，Access Analyzer 返回的结果为 FAIL。

json{ result FAIL message The policy document grants access to perform one or more of the listed actions reasons [ { description One or more of the listed actions in the statement with index 0 statementIndex 0 } ]}

示例 3：将自定义策略检查集成到开发工作流中

基于之前的两个示例，在这个示例中，您将自动分析在 AWS CloudFormation 模板中定义的 IAM 策略。图 1 显示了将要使用的工作流。该工作流将在针对名为 myiampolicy 的 AWS CodeCommit 存储库的主分支创建每个拉取请求时发起图 1 中的提交阶段。第一个检查使用 CheckNoNewAccess API 来确定更新后的策略是否比参考 IAM 策略更宽松。第二个检查使用 CheckAccessNotGranted API 自动检查策略中的关键权限图 1 中的验证阶段。在这两种情况下，如果更新的策略更宽松或包含关键权限，则会在拉取请求中发布包含验证结果的评论。然后，这些信息可用于决定是否将拉取请求合并到主分支进行部署图 1 中显示了部署阶段。

步骤 1：部署基础设施并设置管道

使用以下命令下载并解压与本文相关的 Cloud Development Kit (CDK) 项目。

bashgit clone https//githubcom/awssamples/accessanalyzerautomatedpolicyanalysisbloggitcd /accessanalyzerautomatedpolicyanalysisblog

使用以下命令创建一个虚拟 Python 环境以包含项目依赖关系。

bashpython3 m venv venv

使用以下命令激活虚拟环境。

bashsource venv/bin/activate

使用以下命令安装项目需求。

bashpip install r requirementstxt

使用以下命令将 CDK CLI 更新到最新的主要版本。

bashnpm install g awscdk@2 force

在您能够部署 CDK 项目之前，请使用以下命令引导您的 AWS 环境。引导是在部署 CDK 项目时创建所需资源的过程。这些资源包括一个 Amazon 简单存储服务 (Amazon S3) 桶，用于存储文件和授予执行部署所需权限的 IAM 角色。

bashcdk bootstrap

最后，使用以下命令部署管道基础设施。

bashcdk deploy requireapproval never

部署将花费几分钟的时间完成。可以随便喝杯咖啡，稍后再检查。

当部署完成后，将列出两个堆栈输出：一个包含 CodeCommitRepo 名称，另一个包含 ConfigBucket 名称。请记下这些输出的值，因为稍后会用到。

白鲸加速器安装教程

已部署的管道在 AWS CodePipeline 控制台 中显示，其外观与图 2 类似。

除了在创建拉取请求时发起外，新部署的管道还可以在检测到 AWS CodeCommit 存储库主分支的更改时发起。管道有三个阶段，即 CheckoutSources、IAMPolicyAnalysis 和 deploy。当由于主分支发生更改而触发管道时，CheckoutSource 阶段将检查 myiampolicy 存储库的内容。

IAMPolicyAnalysis 阶段在 CheckoutSource 阶段之后运行，或者当针对主分支创建拉取请求时，包含两个动作。第一个动作，检查无人新访问，验证 CloudFormation 模板中 IAM 策略的更改是否未授予比预定义的参考策略更多的访问权限。第二个动作，检查未授予的访问，验证这些更新是否未授予被认为敏感或关键的 API 操作访问权限。最后，如果 IAMPolicyAnalysis 阶段的操作成功，Deploy 阶段将部署在 CloudFormation 模板中定义的资源。

要分析 IAM 策略，检查无人新访问 和 检查未授予的访问 操作依赖于一个 参考 策略和一个预定义的 API 操作列表。

使用以下命令创建 参考 策略。

bashcd / cat ltlt EOF gt cnnareferencepolicyjson{ Version 20121017 Statement [ { Effect Allow Action Resource } { Effect Deny Action iamPassRole Resource arnawsiamrole/mysensitiveroles/ } ]} EOF

此参考策略设定了计划通过自定义策略检查进行验证的策略的最大权限。iamPassRole 权限允许 IAM 主体将 IAM 角色传递给 AWS 服务，例如 Amazon Elastic Compute Cloud (Amazon EC2) 或 AWS Lambda。参考策略指明，策略扩展的唯一方式是允许该组敏感资源 arnawsiamrole/mysensitiveroles/ 上的 iamPassRole。

为何参考策略可能有用？参考策略有助于确保环境中不允许某一特定的操作、资源和条件的组合。参考策略通常在一条语句中允许某些操作和资源，然后通过第二个语句拒绝有问题的权限。这意味着比参考策略更宽松的策略允许访问该参考策略拒绝的权限。

在此示例中，获得 IAM 角色的权限的开发者可能会有意或无意地创建一个 AWS 服务如 EC2 对 AWS Lambda可以将特权角色传递给另一个服务或主体的 IAM 角色，从而导致权限升级。

使用以下命令创建一个敏感操作列表。该列表将在构建管道中解析并传递给 CheckAccessNotGranted API。如果策略授予访问此列表中一个或多个敏感操作的权限，将返回 FAIL 结果。为了让这个示例更简单，仅添加一个 API 操作，如下所示。

bashcat ltlt EOF gt sensitiveactionsfiledynamodbDeleteTableEOF

为了使 CodeBuild 项目能够访问依赖关系，使用以下命令将 cnnareferencepolicyfile 和 sensitiveactionsfile 复制到 S3 桶。请参阅您记下的堆栊输出，并用 替换您环境中创建的 S3 桶的名称。

bashaws s3 cp /cnnareferencepolicyjson s3//ltConfigBucketgt/cnnareferencepolicyjsonaws s3 cp /sensitiveactionsfile s3//ltConfigBucketgt/sensitiveactionsfile

步骤 2：创建一个新的 CloudFormation 模板以定义 IAM 策略

管道部署完成后，下一步是克隆创建的存储库，并将其填充为定义 IAM 策略的 CloudFormation 模板。

使用以下命令安装 gitremotecodecommit。

bashpip install gitremotecodecommit

有关安装和配置 gitremotecodecommit 的更多信息，请参见 AWS CodeCommit 用户指南。

安装 gitremotecodecommit 后，使用以下命令从 AWS CodeCommit 克隆 myiampolicy 存储库。

bashgit clone codecommit//myiampolicy ampamp cd /myiampolicy

如果您已为 AWS CLI 配置了命名配置文件，请使用以下命令替换 为您的命名配置文件的名称。

bashgit clone codecommit//ltprofile