[ad_1]
Generally you need to configure an AWS service to entry your useful resource in one other service. For instance, you possibly can configure AWS CloudTrail, a service that displays account exercise throughout your AWS infrastructure, to put in writing log information to your bucket in Amazon Easy Storage Service (Amazon S3). If you do that, you need assurance that the service will solely entry your useful resource in your behalf—you don’t need an untrusted entity to have the ability to use the service to entry your useful resource. Earlier than right this moment, you can obtain this by utilizing the 2 AWS Id and Entry Administration (IAM) situation keys, aws:SourceAccount and aws:SourceArn. You need to use these situation keys to assist ensure that a service accesses your useful resource solely on behalf of particular accounts or sources that you just belief. Nonetheless, as a result of these situation keys require you to specify particular person accounts and sources, they are often troublesome to handle at scale, particularly in bigger organizations.
Lately, IAM launched two new situation keys that may aid you obtain this in a extra scalable means that’s less complicated to handle inside your group:
aws:SourceOrgID — use this situation key to ensure that an AWS service can entry your sources solely when the request originates from a specific group ID in AWS Organizations.
aws:SourceOrgPaths — use this situation key to ensure that an AWS service can entry your sources solely when the request originates from a number of organizational items (OUs) in your group.
On this weblog publish, we describe how you should utilize the 4 out there situation keys, together with the 2 new ones, that can assist you management how AWS providers entry your sources.
Background
Think about a situation the place you configure an AWS service to entry your useful resource in one other service. Let’s say you’re utilizing Amazon CloudWatch to watch sources in your AWS atmosphere, and also you create an alarm that prompts when sure situations happen. When the alarm prompts, you need it to publish messages to a subject that you just create in Amazon Easy Notification Service (Amazon SNS) to generate notifications.
Determine 1 depicts this course of.
Determine 1: Amazon CloudWatch publishing messages to an SNS matter
On this situation, there’s a resource-based coverage controlling entry to your SNS matter. For CloudWatch to publish messages to it, you will need to configure the coverage to permit entry by CloudWatch. If you do that, you determine CloudWatch utilizing an AWS service principal, on this case cloudwatch.amazonaws.com.
Cross-service entry
That is an instance of a standard sample referred to as cross-service entry. With cross-service entry, a calling service accesses your useful resource in a referred to as service, and a resource-based coverage hooked up to your useful resource grants entry to the calling service. The calling service is recognized utilizing an AWS service principal within the kind <SERVICE-NAME>.amazonaws.com, and it accesses your useful resource on behalf of an originating useful resource, akin to a CloudWatch alarm.
Determine 2 reveals cross-service entry.
Determine 2: Cross-service entry
If you configure cross-service entry, you need to ensure that the calling service will entry your useful resource solely in your behalf. Which means you need the originating useful resource to be managed by somebody whom you belief. If an untrusted entity creates their very own CloudWatch alarm of their AWS atmosphere, for instance, then their alarm shouldn’t be in a position to publish messages to your SNS matter.
If an untrusted entity may use a calling service to entry your useful resource on their behalf, it might be an instance of what’s referred to as the confused deputy downside. The confused deputy downside is a safety situation through which an entity that doesn’t have permission to carry out an motion coerces a extra privileged entity (on this case, a calling service) to carry out the motion as an alternative.
Use situation keys to assist stop cross-service confused deputy points
AWS supplies world situation keys that can assist you stop cross-service confused deputy points. You need to use these situation keys to manage how AWS providers entry your sources.
Earlier than right this moment, you can use the aws:SourceAccount or aws:SourceArn situation keys to ensure that a calling service accesses your useful resource solely when the request originates from a particular account (with aws:SourceAccount) or a particular originating useful resource (with aws:SourceArn). Nonetheless, there are conditions the place you would possibly need to permit a number of sources or accounts to make use of a calling service to entry your useful resource. For instance, you would possibly need to create many VPC move logs in a company that publish to a central S3 bucket. To attain this utilizing the aws:SourceAccount or aws:SourceArn situation keys, you will need to enumerate all of the originating accounts or sources individually in your resource-based insurance policies. This could be troublesome to handle, particularly in massive organizations, and may doubtlessly trigger your resource-based coverage paperwork to achieve measurement limits.
Now, you should utilize the brand new aws:SourceOrgID or aws:SourceOrgPaths situation keys to ensure that a calling service accesses your useful resource solely when the request originates from a particular group (with aws:SourceOrgID) or a particular organizational unit (with aws:SourceOrgPaths). This helps keep away from the necessity to replace insurance policies when accounts are added or eliminated, reduces the scale of coverage paperwork, and makes it less complicated to create and overview coverage statements.
The next desk summarizes the 4 situation keys that you should utilize to assist stop cross-service confused deputy points. These keys work in an analogous means, however with completely different ranges of granularity.
Use case
Situation key
Worth
Allowed operators
Single/multi valued
Instance worth
Enable a calling service to entry your useful resource solely on behalf of a company that you just belief.
aws:SourceOrgID
AWS group ID of the useful resource making a cross-service entry request
String operators
Single-valued key
o-a1b2c3d4e5
Enable a calling service to entry your useful resource solely on behalf of an organizational unit (OU) that you just belief.
aws:SourceOrgPaths
Group entity paths of the useful resource making a cross-service entry request
Set operators and string operators
Multivalued key
o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/
Enable a calling service to entry your useful resource solely on behalf of an account that you just belief.
aws:SourceAccount
AWS account ID of the useful resource making a cross-service entry request
String operators
Single-valued key
111122223333
Enable a calling service to entry your useful resource solely on behalf of a useful resource that you just belief.
aws:SourceArn
Amazon Useful resource Title (ARN) of the useful resource making a cross- service entry request
ARN operators (really helpful) or string operators
Single-valued key
arn:aws:cloudwatch:eu-west-1:111122223333:alarm:myalarm
When to make use of the situation keys
AWS recommends that you just use these situation keys in any resource-based coverage statements that permit entry by an AWS service, besides the place the related situation key shouldn’t be but supported by the service. To search out out whether or not a situation key’s supported by a specific service, see AWS world situation context keys within the AWS Id and Entry Administration Consumer Information.
Be aware: Solely use these situation keys in resource-based insurance policies that permit entry by an AWS service. Don’t use them in different use circumstances, together with identity-based insurance policies and repair management insurance policies (SCPs), the place these situation keys received’t be populated.
Use situation keys for protection in depth
AWS providers use a wide range of mechanisms to assist stop cross-service confused deputy points, and the small print range by service. For instance, the place a calling service accesses an S3 bucket, some providers use S3 prefixes to assist stop confused deputy points. For extra data, see the related service documentation.
The place supported by the service, AWS recommends that you just use the situation keys we describe on this publish no matter whether or not the service has one other mechanism in place to assist stop cross-service confused deputy points. This helps to make your intentions specific, present protection in depth, and guard towards misconfigurations.
Instance use circumstances
Let’s stroll by way of some instance use circumstances to discover ways to use these situation keys in observe.
First, think about you’re utilizing Amazon Digital Personal Cloud (Amazon VPC) to handle logically remoted digital networks. In Amazon VPC, you possibly can configure move logs, which seize details about your community visitors. Let’s say you need a move log to put in writing information into an S3 bucket for later evaluation. This course of is depicted in Determine 3.
Determine 3: Amazon VPC writing move logs to an S3 bucket
This constitutes one other cross-service entry situation. On this case, Amazon VPC is the calling service, Amazon S3 is the referred to as service, the VPC move log is the originating useful resource, and the S3 bucket is your useful resource within the referred to as service.
To permit entry, the resource-based coverage to your S3 bucket (referred to as a bucket coverage) should permit Amazon VPC to place objects there. The Principal factor on this coverage specifies the AWS service principal of the service that may entry the useful resource, which for VPC move logs is supply.logs.amazonaws.com.
Preliminary coverage with out confused deputy prevention
The next is an preliminary model of the bucket coverage that enables Amazon VPC to place objects within the bucket however doesn’t but present confused deputy prevention. We’re displaying this coverage for illustration functions; don’t use it in its present kind.
Be aware: For simplicity, we solely present one of many coverage statements that it is advisable permit VPC move logs to put in writing to a bucket. In a real-life bucket coverage for move logs, you want two coverage statements: one permitting actions on the bucket, and one permitting actions on the bucket contents. These are described in Publish move logs to Amazon S3. Each coverage statements work in the identical means with respect to confused deputy prevention.
This coverage assertion permits Amazon VPC to place objects within the bucket. Nonetheless, it permits Amazon VPC to try this on behalf of any move log in any account. There’s nothing within the coverage to inform Amazon VPC that it ought to entry this bucket provided that the move log belongs to a particular group, OU, account, or useful resource that you just belief.
Let’s now replace the coverage to assist stop cross-service confused deputy points. For the remainder of this publish, the remaining coverage samples present confused deputy safety, however at completely different ranges of granularity.
Specify a trusted group
Persevering with with the earlier instance, think about that you just now have a company in AWS Organizations, and also you need to create VPC move logs in varied accounts inside your group that publish to a central S3 bucket. You need Amazon VPC to place objects within the bucket provided that the request originates from a move log that resides in your group.
You possibly can obtain this by utilizing the brand new aws:SourceOrgID situation key. In a cross-service entry situation, this situation key evaluates to the ID of the group that the request got here from. You need to use this situation key within the Situation factor of a resource-based coverage to permit actions provided that aws:SourceOrgID matches the ID of a particular group, as proven within the following instance. In your individual coverage, be certain to exchange <DOC-EXAMPLE-BUCKET> and <MY-ORGANIZATION-ID> with your individual data.
The revised coverage states that Amazon VPC can put objects within the bucket provided that the request originates from a move log in your group. Now, if somebody creates a move log outdoors your group and configures it to entry your bucket, they may get an entry denied error.
You need to use aws:SourceOrgID on this solution to permit a calling service to entry your useful resource provided that the request originates from a particular group, as proven in Determine 4.
Determine 4: Specify a trusted group utilizing aws:SourceOrgID
Specify a trusted OU
What when you don’t need to belief your complete group, however solely a part of it? Let’s take into account a special situation. Think about that you just need to ship messages from Amazon SNS right into a queue in Amazon Easy Queue Service (Amazon SQS) to allow them to be processed by shoppers. That is depicted in Determine 5.
Determine 5: Amazon SNS sending messages to an SQS queue
Now think about that you really want your SQS queue to obtain messages provided that they originate from an SNS matter that resides in a particular organizational unit (OU) in your group. For instance, you would possibly need to permit messages provided that they originate from a manufacturing OU that’s topic to alter management.
You possibly can obtain this by utilizing the brand new aws:SourceOrgPaths situation key. As earlier than, you utilize this situation key in a resource-based coverage hooked up to your useful resource. In a cross-service entry situation, this situation key evaluates to the AWS Organizations entity path that the request got here from. An entity path is a textual content illustration of an entity inside a company.
You construct an entity path for an OU by utilizing the IDs of the group, root, and all OUs within the path all the way down to and together with the OU. For instance, take into account the organizational construction proven in Determine 6.
Determine 6: Instance group construction
On this instance, you possibly can specify the Prod OU by utilizing the next entity path:
For extra details about tips on how to assemble an entity path, see Perceive the AWS Organizations entity path.
Let’s now match the aws:SourceOrgPaths situation key towards a particular entity path within the Situation factor of a resource-based coverage for an SQS queue. In your individual coverage, be certain to exchange <MY-QUEUE-ARN> and <MY-ENTITY-PATH> with your individual data.
Be aware: aws:SourceOrgPaths is a multivalued situation key, which suggests it’s able to having a number of values within the request context. On the time of writing, it accommodates a single entity path if the request originates from an account in a company, and a null worth if the request originates from an account that’s not in a company. As a result of this key’s multivalued, it is advisable use each a set operator and a string operator to match values.
On this coverage, there are two situations within the Situation block. The primary makes use of the Null situation operator and compares with a false worth to substantiate that the situation key’s worth shouldn’t be null. The second makes use of set operator ForAllValues, which returns true if each situation key worth within the request matches no less than one worth in your coverage situation, and string operator StringEquals, which requires an actual match with a price laid out in your coverage situation.
Be aware: The explanation for the null verify is that set operator ForAllValues returns true when a situation key resolves to null. With an Enable impact and the null verify in place, entry is denied if the request originates from an account that’s not in a company.
With this coverage utilized to your SQS queue, Amazon SNS can ship messages to your queue provided that the message got here from an SNS matter in a particular OU.
You need to use aws:SourceOrgPaths on this solution to permit a calling service to entry your useful resource provided that the request originates from a particular organizational unit, as proven in Determine 7.
Determine 7: Specify a trusted OU utilizing aws:SourceOrgPaths
Specify a trusted OU and its youngsters
Within the earlier instance, we specified a trusted OU, however that didn’t embody its little one OUs. What if you wish to embody its youngsters as effectively?
You possibly can obtain this by changing the string operator StringEquals with StringLike. This lets you use wildcards within the entity path. Utilizing the group construction from the earlier instance, the next Situation evaluates to true provided that the situation key worth shouldn’t be null and the request originates from the Prod OU or any of its little one OUs.
Specify a trusted account
If you’d like to be extra granular, you possibly can permit a service to entry your useful resource provided that the request originates from a particular account. You possibly can obtain this by utilizing the aws:SourceAccount situation key. In a cross-service entry situation, this situation key evaluates to the ID of the account that the request got here from.
The next Situation evaluates to true provided that the request originates from the account that you just specify within the coverage. In your individual coverage, be certain to exchange <MY-ACCOUNT-ID> with your individual data.
You need to use this situation factor inside a resource-based coverage to permit a calling service to entry your useful resource provided that the request originates from a particular account, as proven in Determine 8.
Determine 8: Specify a trusted account utilizing aws:SourceAccount
Specify a trusted useful resource
If you wish to be much more granular, you possibly can permit a service to entry your useful resource provided that the request originates from a particular useful resource. For instance, you possibly can permit Amazon SNS to ship messages to your SQS queue provided that the request originates from a particular matter inside Amazon SNS.
You possibly can obtain this by utilizing the aws:SourceArn situation key. In a cross-service entry situation, this situation key evaluates to the Amazon Useful resource Title (ARN) of the originating useful resource. This supplies essentially the most granular type of cross-service confused deputy prevention.
The next Situation evaluates to true provided that the request originates from the useful resource that you just specify within the coverage. In your individual coverage, be certain to exchange <MY-RESOURCE-ARN> with your individual data.
Be aware: AWS recommends that you just use an ARN operator somewhat than a string operator when evaluating ARNs. This instance makes use of ArnEquals to match the situation key worth towards the ARN specified within the coverage.
You need to use this situation factor inside a resource-based coverage to permit a calling service to entry your useful resource provided that the request comes from a particular originating useful resource, as proven in Determine 9.
Determine 9: Specify a trusted useful resource utilizing aws:SourceArn
Specify a number of trusted sources, accounts, OUs, or organizations
The 4 situation keys mean you can specify a number of trusted entities by matching towards an array of values. This lets you specify a number of trusted sources, accounts, OUs, or organizations in your insurance policies.
Conclusion
On this publish, you realized about cross-service entry, through which an AWS service communicates with one other AWS service to entry your useful resource. You noticed that it’s essential to ensure that such providers entry your sources solely in your behalf with a view to assist keep away from cross-service confused deputy points.
We confirmed you tips on how to assist stop cross-service confused deputy points by utilizing two new situation keys aws:SourceOrgID and aws:SourceOrgPaths, in addition to the opposite out there situation keys aws:SourceAccount and aws:SourceArn. You realized that it is best to use these situation keys in any resource-based coverage statements that permit entry by an AWS service, if the situation key’s supported by the service. This helps ensure that a calling service can entry your useful resource solely when the request originates from a particular group, OU, account, or useful resource that you just belief.
In case you have suggestions about this publish, submit feedback within the Feedback part beneath. In case you have questions on this publish, begin a brand new thread on AWS IAM re:Put up or contact AWS Assist.
Need extra AWS Safety information? Comply with us on Twitter.
James Greenwood
James is a Principal Safety Options Architect who helps AWS Monetary Providers prospects meet their safety and compliance goals within the AWS Cloud. James has a background in identification and entry administration, authentication, credential administration, and information safety with greater than 20 years of expertise within the monetary providers business.
Sophia Yang
Sophia is a Senior Product Supervisor on the AWS Id and Entry Administration (IAM) service. She is enthusiastic about enabling prospects to construct and innovate in AWS in a safe method.
[ad_2]
Source link
