- [Tatyana] Hello, I'm Tatyana Yatskevich,
senior solutions architect in AWS.
Today, I will show you how to use aws:ResourceOrgID
global condition key
to help ensure that your identities and your networks
can only be used to access trusted resources.
When you store your sensitive data
in your corporate environment,
which may include on-premises networks and AWS clouds,
you would want to prevent this data from making its way
out of that network to untrusted locations.
Untrusted or external locations,
usually refer to resources which do not belong
to your AWS organization.
Those are S3 buckets, SNS topics
and other resources that do not belong
to your organization boundary.
To achieve that objective
you can use AWS and access management capabilities
to restrict your IAM principals,
such as IAM roles
from making API calls to resources outside
of your AWS account or AWS organization.
Historically, you could do that by listing out
individual resources in IAM policies with arns
Amazon resource names containing the account
IDs you want limit access to.
You could also use service specific condition keys
such as S3 resource account to limit access
to resources inside your trusted AWS accounts.
Notice that in both cases you have to individually
list account IDs in resource or condition element
of the policy in order to identify resources that belong
to your trust boundary.
Even though that allows you to meet the requirement
of restricting access to trusted resources.
This approach presents scaling challenges
for organizations
with many accounts created dynamically
on a regular basis.
Alternatively, you can use IAM global condition keys
such as aws:ResourceAccount, aws:ResourceOrgPaths
and aws:ResourceOrgID,
which consistently apply
to all AWS services that support them
and can be implemented
at an organizational level.
aws:ResourceOrgID condition key specifically
is beneficial for multi account environments.
As it allows you to build a boundary
at the level of an entire organization.
Consider a scenario where you want
to prevent your principals
from writing
to an S3 bucket that is outside of your organization.
To accomplish this,
you can write a policy
which includes the aws:ResourceOrgID condition key
with the value set
to your AWS organization ID.
With this policy in place.
When a principal in your organization tries
to write to an S3 bucket
AWS verifies if the value
of the condition key matches the organization ID
of the S3 bucket, getting accessed.
And if those values do not match
the access will be explicitly denied with this policy.
You can apply this policy
to any principal in your organization
or to your entire organization
using service control policies SCPs.
By attaching this policy
as an SCP permissions automatically apply
as your organization scales
and you add more principals
to your AWS environment.
This establishes a data perimeter
around all principals in your organization
and allows to maintain central access control
while giving developers
the ability to innovate and move fast.
To illustrate how to use aws:ResourceOrgID
in practice,
let's go over a couple of use cases.
In the first example,
I will use an SCP to show you
how to implement a data perimeter that helps ensure
that your principals cannot upload data to AWS secrets
manager secrets created outside of your organization.
In my second example, I will use a VPC endpoint
policy to show you how to create a data perimeter
that helps ensure that your networks cannot be used
to upload data to Amazon SNS topics created outside
of your organization.
To demonstrate how you can use SCP
to restrict access to AWS secrets manager secrets.
I will first show you a secret
which I have pre-created outside of my AWS organization.
You will see that this secret explicitly allows
my application role to put secret values.
When we navigate to an account
the application role belongs to,
you will see that this role has secrets manager
and SNS permissions granted using
an identity based policy.
Now, I would like to use application role
to update a value
of previously shown secret.
You can see that this cross account call has succeeded.
In order to apply organization level control
to prevent this type of access.
I will navigate to the AWS organizations console
and create a deny list SCP.
This SCP will result
in an explicit deny for PutSecretValue operation.
If secrets that are being accessed
don't belong to my organization.
Like all SCPs, this SCP doesn't grant any access
but it establishes a perimeter
which is the maximum access allowed
to all principals within your organization.
Additionally, for a permission to be enabled
for a principal in an organization,
every SCP from the root through each OU
in the direct path
to the account must allow that permission.
Therefore, besides this deny statement
in your SCP you also need to have an allow list
which would define permissions
that can be delegated
to principals within individual accounts.
By default, AWS organizations attaches
an AWS managed SCP named FullAWSAccess
to every root, organization unit, and an account .
When I attach this newly created deny list SCP
to my OU
these two policies in combination will ensure
that my principals are permitted
to perform all actions allowed
by the identity or resource based policies.
But are explicitly denied PutSecretValue,
when it is targeting resource outside of my organization.
You can also modify this SCP
to use a policy variable
instead of a hard coded value
for the AWS organization ID.
Policy variables is a feature
that allows you to specify placeholders in a policy.
When a policy is evaluated
policy variables are replaced with values
that come from the context
of the request itself.
In this example
we can use aws:PrincipalOrgID to derive value
for the aws:ResourceOrgID condition key.
aws:PrincipalOrgID value in a request will include
the identifier of the organization
to which the requesting
principal belongs.
As a result this policy denies access
to PutSecretValue
unless the secret being accessed
is in the same organization
as the IAM principal that is accessing it.
The use of this policy variable
in this case may simplify your SCPs management
when you operate multiple AWS organizations
to show this SCP in action
I will try to access that same secret
that belongs to an external account.
You can see that I'm getting an access denied this time
with a detailed message saying
that there is an explicit deny
in an SCP preventing this operation.
Now, if I try to access a secret
which belongs to my organization,
I'm able to do so successfully.
To summarize using aws:ResourceOrgID condition key
within a service control policy
you can create a resource data perimeter
around your corporate data
helping to ensure that your principals can only
access resources in your organization.
As my second example, I would like to demonstrate how
you can use VPC endpoint policy
to prevent principals
in your network
from accessing SNS topics
outside of your organization.
I will first show you an SNS topic
that I have pre-created
in an external account.
You see that this topic explicitly allows my
application role to publish messages to this topic.
You already know
that the application role has SNS permissions.
Now I will try to publish
to that SNS topic from an EC2 instance
running in a VPC of my AWS organization's account.
To do so I will go to the EC2 console
and use AWS SSM session manager
to access that instance.
From there, I will issue AWS SNS publish call.
You can see that this cross account call has succeeded.
In order to apply guardrail,
to prevent this type of access,
I will navigate to the VPC console.
As you may know
you can use VPC endpoints
to enable connections
between your virtual private cloud
and supported services,
without requiring that you use
an internet gateway
or a NAT device.
By default VPC endpoints allow full access
to the services they're created for.
When you create or modify an endpoint
you can attach your custom policy
to restrict access
through that endpoint
based on your security requirements.
I will now attach my data perimeter policy
to the VPC endpoint for SNS service.
This policy will ensure
that SNS actions are only allowed
if topics specified
in the request belongs to my organization.
Like SCPs VPC endpoint policies
do not grant any access
but rather establish a boundary
which is the maximum access allowed
through that endpoint.
Please note that when you use aws:ResourceOrgiD
condition key in a VPC endpoint policy
we do not recommend using a policy variable instead
of a hard coded value for the AWS organization ID.
This is to prevent malicious users
from bringing their own credentials
into your network
and trying to exfiltrate data
by uploading it to their resources.
In this scenario, aws:PrincipalOrgID value,
in the request context
will be the malicious user's, organization ID,
and therefore
if you use PrincipalOrgID variable
in this policy
you will permit that user
to access resources,
outside of your organization.
You can however mitigate this risk
by applying another IAM global condition key
to this policy.
aws:PrincipalOrgID,
which will restrict all SNS actions
to principals in your AWS organization only.
This creates a defense
in depth protection against data exfiltration.
To show this VPC endpoint policy in action.
I will try to access the SNS topic
that belongs
to an external organization
from that same EC2 instance,
running in my VPC.
You see that now I'm getting an access denied
for this request, with a detailed error message saying
that VPC endpoint policy,
not allowing this access.
And if I try to publish to an SNS topic,
which belongs
to my organization,
I'm able to do so successfully.
To summarize using aws:ResourceOrgID condition key
within a VPC endpoint policy
you can create a resource data perimeter
around your corporate data, helping to ensure
that your networks can only be used
to access resources
in your organization.
Please note that there are scenarios
when AWS services act on your behalf,
accessing resources that do not belong
to your AWS organization.
Such data access patterns should be accounted
for when implementing ResourceOrgiD condition key
in policies in your production environment.
This should be dictated by your use
of AWS services and expected data access patterns.
Please reference individual services documentation
for more details.
You have just seen how
you can use aws:ResourceOrgID global condition key
to simplify policies while limiting access
to trusted resources.
Thank you for watching.