介绍 (Intro)

The Salesforce Security Assurance team would like to share a tool that we recently published called Policy Sentry, which helps to automate the creation of least privilege IAM policies in Amazon Web Services (AWS) environments.

Salesforce安全保证团队希望共享我们最近发布的称为Policy Sentry的工具，该工具可帮助在Amazon Web Services(AWS)环境中自动创建最低特权IAM策略。

Policy Sentry allows users to create least-privilege IAM policies in a matter of seconds, rather than tediously writing IAM policies by hand. These policies are scoped down according to access levels and resources. In the case of a breach, this helps to limit the blast radius of compromised credentials by only giving IAM principals access to what they need by writing policies according to access levels and resource constraints. Before this tool, it could take hours to craft a secure IAM policy — but now it can take a matter of seconds. This way, developers only have to determine the resources that they need to access, and Policy Sentry abstracts the complexity of IAM policies away from their development processes. In this post, we’ll walk through the principles of least privilege IAM policies, the general steps that one would use to write them by hand, and show how Policy Sentry automates this process.

使用Policy Sentry ，用户可以在几秒钟内创建特权最小的IAM策略，而不必手工编写IAM策略。 这些策略的范围根据访问级别和资源而定。 在发生违规的情况下，这仅通过根据访问级别和资源限制编写策略，仅允许IAM负责人访问他们所需的内容，从而有助于限制受到破坏的凭据的爆炸半径。 在使用此工具之前，可能需要花费数小时来制定安全的IAM策略，但现在可能需要几秒钟的时间。 这样，开发人员只需确定他们需要访问的资源， Policy Sentry即可从开发过程中抽象出IAM策略的复杂性 。 在本文中，我们将遍历最低特权IAM策略的原理，以及人们手工编写它们的一般步骤，并展示Policy Sentry如何使这一过程自动化。

为什么这有用？ (Why is this useful?)

In a recent breach on an AWS environment, an attacker compromised an internet-exposed WAF appliance server that was vulnerable to Server-Side Request Forgery, obtained AWS credentials via EC2 metadata, and discovered that the server had excessive privileges to access S3 buckets, some of which contained customer data. So the breach likely could have been prevented through one of the two general technical controls:

在最近的AWS环境漏洞中，攻击者破坏了暴露于Internet的WAF设备服务器，该服务器容易受到服务器端请求伪造的侵害，通过EC2元数据获取AWS凭证，并发现该服务器具有访问S3存储桶的过多特权，其中一些其中包含客户数据。 因此，很可能可以通过两种常规技术控制措施之一来防止违规：

• Server-Side Request Forgery¹, which is a difficult problem of its own.服务器端请求伪造¹，这本身就是一个难题。

• Limiting Blast Radius through Least Privilege IAM policies.

  通过最低权限IAM策略限制爆炸半径。

Ideally, we want to give users and systems access to only the resources that they need to for their use case, at access levels appropriate to their use case. For instance, accessing a specific S3 bucket (the resource), with “Read” actions only (the access level). This concept is an example of least privilege. However, until now, it has been challenging to achieve least privilege at scale. One problem is the rapid pace of new features and services by AWS. At the time of writing this blog post, there are now 214 AWS services and over 7,000 different AWS API calls. When we started writing this tool in mid-2019, there were about 180 different AWS services and about 6,000 different API calls. The rapid pace of new feature releases by AWS makes it nearly impossible for a security organization to review and approve new organization-wide IAM policies without disrupting business. The time it takes to write new AWS policies by hand exacerbates this problem. Even for cloud security professionals who are familiar with IAM, writing security-conscious IAM policies by hand can be tedious, inefficient, and time-consuming; and, quite often, security professionals aren’t the ones authoring those IAM policies — developers are! Many Infrastructure as Code developers have experienced something like this:

理想情况下，我们希望以适合其用例的访问级别 ，使用户和系统仅访问其用例所需的资源 。 例如，仅通过“读取”操作(访问级别)访问特定的S3存储桶(资源)。 此概念是最低特权的示例。 但是，直到现在，要实现最低限度的特权一直是一个挑战。 一个问题是AWS的新功能和服务的快速发展。 在撰写此博客文章时，现在有214个AWS服务和7,000多个不同的AWS API调用。 当我们在2019年中期开始编写此工具时，大约有180种不同的AWS服务和大约6,000种不同的API调用。 AWS快速发布新功能使安全组织几乎不可能在不中断业务的情况下审查和批准整个组织范围内的新IAM策略。 手工编写新的AWS策略所花费的时间加剧了该问题。 即使对于熟悉IAM的云安全专家而言，手动编写具有安全意识的IAM策略也可能是乏味，低效且耗时的； 而且，安全专家通常不是那些编写IAM策略的人，开发人员是！ 许多作为代码的基础架构开发人员都经历过以下事情：

• Determined to make your best effort to give users and roles the least amount of privilege you need to perform your duties, you spend way too much time combing through the AWS IAM Documentation on Actions, Resources, and Condition Keys for AWS Services.

  决心尽最大的努力为用户和角色提供执行职责所需的最少特权，您花了太多时间梳理有关AWS服务的操作，资源和条件键的AWS IAM文档。

• Your team lead encourages you to build security into your IAM Policies for product quality, but eventually, you get frustrated due to project deadlines.您的团队负责人鼓励您将安全性纳入产品质量的IAM策略中，但最终，由于项目截止日期，您会感到沮丧。
• You don’t have a security person assigned to your team day-to-day who can write those IAM policies for you, and there’s no automated tool that will automagically sense the AWS API calls that you perform and then write them for you in a least-privilege manner.您没有每天分配给您的团队的安全人员来为您编写这些IAM策略，并且没有自动工具可以自动感应您执行的AWS API调用，然后在您的应用程序中编写它们。最小特权方式。
• After dreaming about that level of automation, you realize that writing least privilege IAM Policies may jeopardize your ability to finish your code in time to meet project deadlines.在梦到了那种自动化水平之后，您意识到编写最低特权的IAM策略可能会损害您及时完成代码以符合项目期限的能力。

• You use Managed Policies, or you eyeball the names of the API calls and use wildcards instead so you can move on with your life.

  您可以使用托管策略 ，也可以使用API​​调用的名称，而可以使用通配符，这样您就可以继续生活。

Recent breaches have drawn attention to the risks of Server Side Request Forgery (SSRF), but overprivileged IAM policies have continued to be an overlooked issue — partially because of the difficulty in achieving least privilege with IAM at scale. Policy Sentry seeks to lower that difficulty level.

最近的违规行为已引起人们对服务器端请求伪造(SSRF)风险的关注，但是特权过多的IAM策略仍然是一个被忽略的问题-部分原因是难以大规模获得IAM的最低特权。 政策哨兵试图降低这一难度。

While Policy Sentry can’t determine the context of your IAM role — whether it truly needs access to certain resources based on business or functional requirements — it can restrict access to precisely the resources that you say it needs access to, and do it in a predictable, auditable, and readable manner.

虽然Policy Sentry不能确定您的IAM角色的上下文(它是否确实需要根据业务或功能要求来访问某些资源)，但它可以限制对您说需要访问的资源的精确访问，并且可以在可预测，可审核和可读的方式。

它是如何工作的？ (How does it work?)

IAM政策背景 (IAM Policy Background)

At the most basic level, a policy statement has one or more statements. Each statement always has the following components:

在最基本的级别上，一个策略声明包含一个或多个声明。 每个语句始终具有以下组成部分：

• Effect: This can be Allow or Deny.

  Effect ：这可以是Allow或Deny 。

• Action: A list of AWS IAM Actions.

  Action ：AWS IAM操作的列表。

• Resource: A list of Amazon Resource Names (ARNs) of various AWS resources.

  Resource ：各种AWS资源的Amazon资源名称(ARN)列表。

Consider a statement that has an Allow effect, with the action s3:GetObject and Resources set to *.

考虑一个具有Allow效果的语句，其动作s3:GetObject和Resources设置为* 。

This means that the IAM policy will allow the IAM principal (a role or user) to run GetObject from any S3 bucket in the AWS account. Overly permissive access to S3 buckets - i.e., a wide blast radius - is a cause of many breaches.

这意味着IAM策略将允许IAM主体(角色或用户)从AWS账户中的任何S3存储桶运行GetObject 。 过度允许进入S3铲斗-即爆炸半径较大-是造成许多漏洞的原因。

手动编写安全策略 (Writing Secure Policies by Hand)

Now, how could this be prevented with more secure IAM policies? For starters, you could restrict the IAM action to the specific ARN that your role needs access to. With the simple combination of s3:GetObject and a specific S3 bucket — let’s say, arn:aws:s3:::my-bucket/ , the policy is simple enough.

现在，如何通过更安全的IAM策略来防止这种情况发生？ 对于初学者，您可以将IAM操作限制为您的角色需要访问的特定ARN。 通过s3：GetObject和特定的S3存储桶的简单组合-假设arn:aws:s3:::my-bucket/ ，策略就足够简单了。

However, real IAM policies quickly become trickier when you combine one IAM action with one IAM resource, as with the above example. Let’s say that your internal customer needs access to the following actions:

但是，如上例所示，将一个IAM操作与一个IAM资源结合使用时，实际的IAM策略很快变得棘手。 假设您的内部客户需要访问以下操作：

• kms:CreateGrant

  kms:CreateGrant

• kms:CreateCustomKeyStore

  kms:CreateCustomKeyStore

• ec2:AuthorizeSecurityGroupEgress

  ec2:AuthorizeSecurityGroupEgress

• ec2:AuthorizeSecurityGroupIngress

  ec2:AuthorizeSecurityGroupIngress

To build this policy, we need to navigate to the AWS IAM Documentation — specifically the Actions, Resources, and Condition Keys page for each service.

要构建此策略，我们需要导航到AWS IAM文档-特别是每个服务的“ 操作，资源和条件键”页面 。

Let’s take a look at the consolidated EC2 Actions Table below:

让我们看一下下面的综合EC2操作表：

As shown in the table above, both of those actions can be restricted to specific security groups — so in the Resources stanza of the IAM policy, we would specify whatever the ARN format of the security-group is.

如上表所示，这两种操作都可以限制在特定的安全组中-因此，在IAM策略的“资源”节中，我们将指定安全组的ARN格式是什么。

We can determine that format by navigating to the ARN table on that page. A snippet is below:

我们可以通过导航到该页面上的ARN表来确定该格式。 以下是一个摘要：

As you can see above, we’d have to specify the security group ID in the IAM policy. Let’s see what it would look like in an IAM policy:

正如您在上面看到的，我们必须在IAM策略中指定安全组ID。 让我们看看IAM策略中的情况：

根据资源约束和访问级别编写安全策略 (Writing Secure Policies based on Resource Constraints and Access Levels)

Now, to do this for every single action by hand is very tedious, error-prone, and difficult to audit. Imagine if we had to do this by hand for dozens of IAM actions across multiple services!

现在，手动执行每个操作都是非常繁琐，容易出错且难以审核的。 想象一下，如果我们必须为多个服务中的数十个IAM操作手动执行此操作！

Quite often, this leads to one of the following results for Infrastructure as Code developers:

通常，对于代码开发人员来说，这会导致以下结果之一：

1. Use Managed IAM Policies, and write the IAM policy later. Sometimes this never gets fixed.使用托管IAM策略，并在以后编写IAM策略。 有时这永远不会解决。
2. Write the policy correctly, potentially leading to missed project deadlines.正确编写策略，可能导致错过项目截止日期。
3. “Eyeball” the IAM policy and use wildcard statements instead of specifying resource ARNs correctly.“眼球” IAM策略，并使用通配符语句，而不是正确指定资源ARN。

Policy Sentry automates this process to avoid that outcome and abstract the complexity of writing IAM policies. As a result, writing secure policies takes seconds instead of hours.

Policy Sentry可自动执行此过程，以避免产生这种结果，并抽象出编写IAM策略的复杂性。 结果，编写安全策略只需几秒钟而不是几小时。

The CRUD mode functionality takes the opinionated approach that IAC developers shouldn’t have to understand the complexities of AWS IAM — we should abstract the complexity for them. In fact, developers should just be able to say…

CRUD模式功能采用了自以为是的方法，即IAC开发人员不必了解AWS IAM的复杂性-我们应该为他们抽象复杂性。 实际上，开发人员应该能够说……

• “We need Read, Write, and List access to arn:aws:ssm:us-east-1:123456789012:parameter/myparameter"

  “我们需要对arn:aws:ssm:us-east-1:123456789012:parameter/myparameter读取，写入和列表访问权限”

• “We need Permissions Management and Tagging access to arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret“

  “我们需要对arn:aws:secretsmanager:us-east-1:123456789012:secret:mysecret权限管理和标记访问权限”

…and our automation should create policies that correspond to those access levels. How do we accomplish this? Well, Policy Sentry leverages another column available in the Actions Table from the Actions, Resources, and Condition Keys documentation — the “Access Level” column. See the snippet below.

…并且我们的自动化应该创建与这些访问级别相对应的策略。 我们如何做到这一点？ 好吧，Policy Sentry利用了“操作”，“资源和条件键”文档中“操作表”中的另一列-“访问级别”列。 请参见下面的代码段。

Policy Sentry aggregates all of that documentation into a single database and uses that database to generate policies according to actions, resources, and access levels.

Policy Sentry将所有文档汇总到一个数据库中，并使用该数据库根据操作，资源和访问级别生成策略。

To generate a policy according to resources and access levels, start by creating a template with the create-template command so you can just fill out the fields, rather than memorizing the format. The --name flag specifies the name of the role, the --output-file flag specifies the name of the file, and the --template-type specifies the “mode” that Policy Sentry will use to create policies (crud or actions).

要根据资源和访问级别生成策略，请首先使用create-template命令创建一个模板，这样您就可以填写字段，而不用记住格式。 --name标志指定角色的名称，-- --template-type --output-file标志指定--output-file的名称，-- --template-type指定Policy Sentry将用于创建策略的“模式”( crud或actions )。

policy_sentry create-template --name myRole --output-file crud.yml --template-type crud

It will generate a file like this:

它将生成如下文件：

The template has a few fields:

该模板有几个字段：

• mode - the Policy Sentry “mode”. Acceptable values are crud or actions. CRUD mode creates policies based on access levels constrained to the resource ARNs provided. Read more about Actions mode here.

  mode -Policy Sentry的“模式”。 可接受的价值是crud actions 。 CRUD模式基于受限于提供的资源ARN的访问级别创建策略。 在此处阅读有关动作模式的更多信息。

• name - the name of your role. This is for readability purposes and for anyone who might review your template later if it is checked into Git.(Optional)

  name -您的角色名称。 这是出于提高可读性的目的，也适用于以后将模板检入Git的任何人。

• description - this is where you would include your description or justification for that role. (Optional)

  description -在这里您将包括对该角色的描述或理由。 (可选的)

• role_arn: You can insert the ARN of the IAM role that this applies to for informational purposes. (Optional)

  role_arn ：您可以插入IAM角色的ARN，以供参考。 (可选的)

• The access levels, read, write, list, tag, and permissions-management. Here, you specify a list of ARNs that your service needs access to, under the proper access level. Policy Sentry will match the ARNs with the ARN formats listed in its database, and will generate a policy that restricts actions at that access level that can be matched to those ARNs only. If any of these fields are not used, you can just delete them from the template.

  访问级别， read ， write ， list ， tag和permissions-management 。 在这里，您可以在适当的访问级别下指定服务需要访问的ARN列表。 Policy Sentry会将ARN与数据库中列出的ARN格式进行匹配，并将生成一个策略，该策略限制只能在那些访问级别上与那些ARN匹配的操作。 如果未使用这些字段中的任何一个，则可以将它们从模板中删除。

• wildcard, a special field where you can specify IAM actions that cannot be restricted to ARNs, like ssm:DescribeParameters, if necessary. Delete this field from the template if it is not used.

  wildcard ，这是一个特殊字段，您可以在其中指定不能限于ARN的IAM操作，例如ssm:DescribeParameters (如果需要)。 如果不使用该字段，请从模板中删除它。

Then just paste all of the ARNs under the access levels in the template:

然后只需将所有ARN粘贴在模板的访问级别下：

Then run the write-policy command. Here, you’ll specify the the Policy Sentry template you just created with--input-file:

然后运行write-policy命令。 在这里，您将指定刚刚使用--input-file创建的Policy Sentry模板：

policy_sentry write-policy --input-file crud.yml

It will generate these results:

它将产生以下结果：

Notice how the policy above recognizes the ARNs that the user supplies, along with the requested access level. For instance, the SID SecretsmanagerTaggingSecret contains Tagging actions that are assigned to the secret resource type only.

请注意，上述策略如何识别用户提供的ARN以及请求的访问级别。 例如，SID SecretsmanagerTaggingSecret包含仅分配给secret资源类型的Tagging操作。

Policy Sentry与其他工具相比如何？ (How does Policy Sentry compare to other tools?)

Policy Sentry is somewhat similar to Trailscraper. Trailscraper queries CloudTrail logs and attempts to “guess” the matching between CloudTrail actions and IAM actions, then generates a policy. Given that there is not a 1-to-1 mapping between the names of Actions listed in CloudTrail log entries and the names AWS IAM Actions, the results are not always accurate. It is a good place to start, but the generated policies all contain Resources: "*", so it is up to the user to restrict those IAM actions to only the necessary resources. CloudTracker performs similar log-based policy suggestions, and is faster due to the use of Amazon Athena, but it does not generate suggested policies.

政策哨兵有点类似于Trailscraper 。 Trailscraper查询CloudTrail日志，并尝试“猜测” CloudTrail操作和IAM操作之间的匹配，然后生成策略。 假设CloudTrail日志条目中列出的操作名称与AWS IAM操作名称之间没有一对一的映射关系，所以结果并不总是准确的。 这是一个很好的起点，但是生成的策略都包含Resources: "*" ，因此用户可以将这些IAM操作限制为仅必要的资源。 CloudTracker执行类似的基于日志的策略建议，并且由于使用了Amazon Athena而速度更快，但是它不会生成建议的策略。

RepoKid is a popular tool that was developed by Netflix, and is one of the more mature and battle-tested AWS IAM open source projects. It leverages AWS Access Advisor, which informs you how many AWS services your IAM Principal has access to, and how many of those services it has used in the last X amount of days or months. If you haven’t used a service within the last 30 days, it “repos” your policy, and strips it of the privileges it doesn’t use. It has some advanced features to allow for whitelisting roles and overall is a great tool.

RepoKid是由Netflix开发的一种流行工具，是比较成熟且经过考验的AWS IAM开源项目之一。 它利用了AWS Access Advisor，它可以通知您IAM委托人可以访问多少AWS服务，以及最近X天或数月内使用了哪些服务。 如果您在过去30天内没有使用过服务，它将“重新分配”您的策略，并剥夺它不使用的特权。 它具有一些高级功能，可以将角色列入白名单，并且总体而言是个不错的工具。

One shortcoming is that AWS IAM Access Advisor only provides details at the service level (ex: S3-wide, or EC2-wide) and not down to the IAM Action level, so the revised policy is not very granular. However, RepoKid plays a unique role in the IAM ecosystem right now in that there are not any open source tools that provide similar functionality. For that reason, it is best to view RepoKid and Policy Sentry as complementary.

一个缺点是，AWS IAM Access Advisor仅在服务级别(例如：S3范围或EC2范围)提供详细信息，而没有提供IAM Action级别的详细信息，因此修订后的策略不是很精细。 但是，RepoKid现在在IAM生态系统中扮演着独特的角色，因为没有任何开源工具可以提供类似的功能。 因此，最好将RepoKid和Policy Sentry视为互补。

We recommend using Policy Sentry to create Identity based policies, using Repokid to revoke out of date policies as your application/roles mature, and never to provision Infrastructure manually — always provision your policies using Infrastructure as Code tools (like Terraform) in a CI/CD pipeline.

我们建议您使用Policy Sentry创建基于身份的策略，并在应用程序/角色成熟时使用Repokid撤销过期的策略，并且永远不要手动配置基础结构-始终在CI /中使用“基础结构即代码”工具(例如Terraform)来配置策略CD管道。

摘要 (Summary)

Policy Sentry rapidly speeds up the time to develop IAM policies and ensures that all IAM policies limit access according to the proper CRUD levels, and only to the exact resources that your role needs access to. Before this tool, it could take hours to craft the perfect IAM Policy — but now it can take a matter of seconds. This way, developers only have to determine the resources that they need to access, and Policy Sentry abstracts the complexity of IAM policies away from their development processes. Be sure to let us know if you have questions about Policy Sentry, if you leverage it in your own environment, or if you have other methods for addressing this problem!

Policy Sentry快速加快了开发IAM策略的时间，并确保所有IAM策略均根据适当的CRUD级别(仅针对您角色需要访问的确切资源)限制访问。 在使用此工具之前，可能需要花费数小时来制定完善的IAM策略，但现在可能需要几秒钟的时间。 这样，开发人员只需确定他们需要访问的资源， Policy Sentry即可从开发过程中抽象出IAM策略的复杂性 。 如果您对Policy Sentry有疑问，是否在自己的环境中利用它或有其他解决此问题的方法，请务必让我们知道！

PS：我们正在招聘！ (P.S.: We’re hiring!)

One of the things that we love about working at Salesforce is that management is committed to automation, including automation of security activities. Certain challenges can only be addressed through careful security engineering and we understand that. If you’re interested in working in Salesforce security, we are hiring in InfraSec and are looking for those with heavy threat modeling skills, secure architecture, and design. If this sounds interesting to you, feel free to follow and message me on Twitter: https://twitter.com/kmcquade3.

我们喜欢在Salesforce工作的一件事是管理致力于自动化，包括安全活动的自动化。 某些挑战只能通过仔细的安全工程来解决，我们知道。 如果您对使用Salesforce安全性感兴趣，我们正在InfraSec招聘人员，并且正在寻找具有大量威胁建模技能，安全架构和设计的人员。 如果您觉得这很有趣，请随时关注并在Twitter上给我发消息： https : //twitter.com/kmcquade3 。

¹ There were some updates in late 2019 to the EC2 metadata service to prevent against SSRF attacks, which are covered here — although that requires some re-engineering on the part of AWS customers to support the updates to the EC2 metadata service.

¹有到EC2元数据服务，以防止对SSRF攻击，其中涵盖了一些更新，在2019年后期 这里 -尽管这需要在AWS客户的某些部分重新设计，以支持更新到EC2元数据服务。

² GitHub: https://github.com/salesforce/policy_sentry/

²GitHub： https ： //github.com/salesforce/policy_sentry/

³ Documentation: https://policy-sentry.readthedocs.io/

³说明文件： https : //policy-sentry.readthedocs.io/

⁴ Author: https://twitter.com/kmcquade3

⁴作者： https : //twitter.com/kmcquade3