aws-samples/iam-access-analyzer-custom-policy-check-samples

## AWS IAM Access Analyzer CheckNoNewAccess 示例参考策略 本仓库包含一组示例参考策略，可与 Access Analyzer 的 CheckNoNewAccess API 结合使用。CheckNoNewAccess API 会将现有策略与新策略进行比对，如果在新策略中未检测到新的访问权限，则返回 PASS；如果在新策略中检测到新的访问权限，则返回 FAIL。 本仓库中的参考策略旨在传递给 CheckNoNewAccess API 的 ExistingPolicyDocument 参数。然后，在 NewPolicyDocument 参数中传递您要检查是否存在新访问权限的 IAM 策略（在本仓库中称为 candidate-policy）。示例： ``` aws accessanalyzer check-no-new-access --existing-policy-document file://reference-policy.json --new-policy-document file://candidate-policy.json --policy-type IDENTITY_POLICY ``` CheckNoNewAccess API 支持身份策略和资源策略，并基于 Zelkova 构建。Zelkova 将 IAM 策略转换为等价的逻辑陈述，并针对该问题运行一套通用和专用的逻辑求解器（可满足性模理论）。要了解有关可满足性模理论的更多信息，请参阅 [可满足性模理论](https://people.eecs.berkeley.edu/~sseshia/pubdir/SMT-BookChapter.pdf)。 ### 什么是参考策略？ 您使用参考策略来检查候选策略是否允许比参考策略更多的访问权限。换句话说，如果候选策略是参考策略的子集，则检查通过。 使用精心设计的参考策略，您可以做出如下断言： - 此策略不授予对我的敏感资源的访问权限。 - 仅允许这些主体访问我的敏感资源。 - 只有伴随标签条件键时，才能授予此 IAM 操作。 让我们通过一个示例来说明。参考策略通常从允许所有访问开始。如果您以前接触过[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)，这可能看起来很熟悉。然后，您添加一个或多个语句来拒绝您希望参考策略检查的访问权限。 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": [ "s3:PutBucketPolicy" ], "Resource": "arn:aws:s3:::my-sensitive-bucket" } ] } ``` 在上面的示例 1 中，我们首先允许所有访问。然后，我们拒绝对特定敏感存储桶 ```my-sensitive-bucket``` 执行 ```s3:PutBucketPolicy``` 操作。您可以选择在此处添加多个存储桶。 对于未授予对 ```my-sensitive-bucket``` 的 ```s3:PutBucketPolicy``` 访问权限的候选策略，CheckNoNewAccess API 将返回 PASS（意味着没有新访问权限）。对于确实授予对敏感存储桶访问权限的候选策略，API 将返回 FAIL。您可以使用该结果来决定，作为 CI/CD 流程的一部分，授予对敏感存储桶 ```s3:PutBucketPolicy``` 访问权限的策略需要额外的审查。 您可以将这种相同的模式用于任何 AWS 服务，并且本仓库中有许多可供您自定义的参考策略。 ### 如果我只想检查 IAM 操作而不想处理参考策略怎么办？ 您应该改用 CheckAccessNotGranted API。CheckAccessNotGranted API 检查候选策略是否未授予对 IAM 操作的访问权限。 ### 当检查失败并且在根据参考策略检查 IAM 策略时出现“新访问权限”意味着什么？ 新访问权限意味着您正在检查的候选策略授予了参考策略未授予的额外访问权限。 这就是为什么我们建议您在参考策略的开头使用一个授予对所有操作和资源访问权限的语句。然后，您编写拒绝特定访问权限的语句。这意味着，您的候选策略授予参考策略中未授予的访问权限的唯一途径是它授予了参考策略拒绝的访问权限。 在上面的示例 1 中，候选策略可以授予比参考策略更多访问权限的唯一途径是它允许对 ```s3:PutBucketPolicy``` 操作和 ```my-sensitive-bucket``` 资源的访问。 ### 我应该如何使用本仓库中的示例参考策略？ 本仓库中的示例参考策略分为两个顶层文件夹——资源策略和身份策略。 ***身份策略*** - **check-access-to-sensitive-resource** - 检查对敏感资源的访问。您应该将拒绝语句中的占位符 ARN 替换为您敏感资源的 ARN。如果要检查多个敏感资源，可以添加多个资源。您还可以根据要检查访问权限的操作来添加或删除操作。您还可以通过将多个拒绝语句附加到单个允许语句来组合参考策略。检查对敏感资源的访问是上面示例 1 中显示的示例类型。 - **check-for-privilege-escalation** - 检查可能用于提升权限的操作。这并不是所有可能用于权限提升的操作的完整列表。您还应该在 IAM 策略 guardrails 中对这些操作中的许多操作实施预防性控制。 - **check-for-tag-based-access** - 检查使用特定操作的访问是否受到标签条件键的约束。例如，参考策略 [```run-ec2-instance-with-tag.md```](identity-policies/check-for-tag-based-access/run-ec2-instance-with-tag.md) 检查策略是否仅允许在指定特定标签条件键的情况下运行 EC2 实例。参考策略 [```act-on-ec2-instance-with-tag.md```](identity-policies/check-for-tag-based-access/act-on-ec2-instance-with-tag.md) 检查策略是否只能授予对特定资源标签值终止 EC2 实例的访问权限。您可以使用此类参考策略来帮助在开发过程中实施某些基于标签的访问控制策略。 ***资源策略*** - **check-who-is-granted-access** - 检查资源策略是否仅允许特定主体或一组主体访问。后缀为 ```-specific-actions``` 的示例仅检查特定的、可能敏感的操作是否限于一个或多个主体。这些示例中的其他操作不被检查。后缀为 ```-all-actions``` 的示例检查所有操作是否仅授予特定主体或一组主体。 引入 ```Principal``` 元素使得编写这些参考策略略有不同。参考策略使用 ```Principal``` 元素和 ```aws:PrincipalArn``` 条件键允许可以授予访问权限的主体。对于仅检查特定操作的示例，添加一个额外的语句以使用 ```NotAction``` 元素允许所有剩余操作。有关示例，请参阅 [```s3-specific-actions.md```](resource-policies/check-who-is-granted-access/s3-specific-actions.md)。 ### 如何编写自己的参考策略？ 我们建议坚持使用本仓库中提供的示例，并根据需要进行自定义。如果您确实想编写自己的参考策略，应遵循以下一般模式。 对于身份策略，从允许所有操作和资源的语句开始。为在候选策略中被授予时应导致检查失败的操作、资源和条件添加拒绝语句。 对于资源策略，像通常编写资源策略时一样，添加语句以允许主体、操作、资源和条件的访问。如果您只想检查特定的操作或资源，请在末尾添加一个包含您正在检查的特定操作和资源的 ```NotAction``` 或 ```NotResource``` 元素语句，并有效地允许所有其他操作和资源。 ### 编写自己的参考策略时要记住哪些事项？ 如果您选择编写自己的参考策略，我们建议自定义本仓库中的参考策略或遵循上述一般模式。在自定义现有参考策略或编写自己的参考策略时，有一些事项需要注意。 - 策略检查不了解操作与条件之间的所有关系。例如，它们不知道某个操作是否仅支持 ```*``` 资源。这意味着您不能编写如下面示例 2 所示的参考策略。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::my-sensitive-bucket" } ] } 由于 S3 具有不支持指定资源的操作，例如 ```s3:ListAllMyBuckets```，此参考策略将假定任何候选策略在允许对 S3 操作的访问时必须指定资源。由于这是不可能的，因此使用示例 2 作为参考策略将导致检查出现误报。 - 条件不具备组织感知能力。这意味着策略检查不知道账户或 OU 路径是否属于您的组织。如果您尝试使用 ```aws:PrincipalOrgId``` 或类似的条件键，请记住这一点。如果您想检查外部或跨账户访问，应该使用 [Access Analyzer 访问预览](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-preview-access-apis.html)。

标签：Access Analyzer, AWS, CheckNoNewAccess, DevSecOps, DPI, Homebrew安装, IAM, LNA, S3策略, SMT求解器, Zelkova, 上游代理, 最小权限原则, 权限管理, 模型越狱, 策略即代码, 策略检查, 聊天机器人安全, 资源策略, 身份与访问管理, 身份策略