Organizations SCPs
AWS Organizations is a service that allows us to centrally manage multiple AWS accounts belonging to the same organization. It provides the ability to structure them according to a hierarchy of organizational units (OUs). It also provides a feature called SCPs that allows us to limit permissions for all member accounts in either an entire organization or a single OU. It allows an AWS administrator to enforce those controls from a central place and easily adapt them to the evolution and needs of your organization over time.
You will cover SCPs in more detail while learning AWS Organizations in a later chapter.
Note
Remember that SCPs are one efficient mechanism to enforce security controls, following your organization’s security policies systematically and repeatedly without having to duplicate the same policies in each individual AWS account.
ACLs
ACLs are service policies that let you control which principals in another account are allowed to access a resource in the current account. They are somewhat like resource-based policies but present clear differences:
ACLs can help address some very specific use cases in which resource-based policies may not be your best option. Such use cases include, for instance, controlling access to S3 objects that do not belong to the S3 bucket owner, or setting different access permissions for individual objects inside the same folder within a given S3 bucket.
Amazon S3 but also services such as AWS Web Application Firewall (WAF), and Amazon Virtual Private Cloud (VPC) support ACLs.
Session Policies
Session policies are policies passed as a parameter when programmatically creating a temporary session for a role or a federated user. They are meant to limit the permissions from the role’s or user’s identity-based policy that are allowed during the session. Like permissions boundaries, they cannot be used to grant more permissions than those already allowed by the identity-based policy.
To create a temporary session for a role, you use either the AssumeRole, the AssumeRoleWithSAML, or the AssumeRoleWithWebIdentity application programming interface (API) operation from the AWS Security Token Service (STS). For federated users, temporary sessions are created using the GetFederationToken API operation from AWS STS.
You will review the importance of sessions when going through further details about access control later in this chapter.
Identity-Based Versus Resource-Based Policies
So, what most AWS administrators end up wondering is: Should I rather use identity-based policies or resource-based policies? Well, it depends—it really does.
It is not a binary decision. Very likely, you will end up using a combination of both plus several of the other types of policies we’ve previously discussed.
A first observation is that not all AWS resources support resource-based policies, so identity-based policies remain the only way of giving access to the resources that do not. A second key aspect is that identity-based policies provide a means to manage access to AWS resources independently of these AWS resources and their life cycle. So, it makes sense for an AWS administrator who wants to centralize access control as much as possible in a single place to rely on identity-based policies to control access to AWS resources.
Does this mean that resource-based policies would not be useful? No—they will prove very useful for providing additional control to the security-savvy resource owner who wants to further ensure that only specific entities within their organization are allowed to access their resources.
For instance, consider a situation where multiple teams have access to resources in your account. As the owner of sensitive data sitting in a specific S3 bucket, you want to restrict access to people who you know have been approved to access that data. You happen to know that these people are all part of a specific OU inside your organization. You could then make sure to restrict access, independently of the permissions that anyone is assigned in your organization, by enforcing specific conditions for accessing your sensitive data. For that, you would typically use resource-based policies. In this example, you could add a condition such as the following to the resource-based policy assigned to your resources sitting, for instance, in an S3 bucket:
“Condition” : { “ForAnyValue:StringLike” : {
“aws:PrincipalOrgPaths”:[” o-a1phab2avo/r-abcd/ou-wxyz- hal45678/*”]
}}
And does this mean that other policies, such as SCPs and session policies, are not so important? No—it most certainly does not. Complex organizations with multiple AWS accounts will also, at least, leverage SCPs on top of identity-based and resource-based policies. You will cover SCPs in more detail when you learn AWS Organizations.
Note
Identity-Based Policies and Resource-Based Policies Are Permissions Policies
Provided that there are no further constraints (SCPs, permissions boundaries, session policies, or ACLs), an entity will have access to a resource in the same account if access is not explicitly denied and if at least one policy statement grants access, whether it is within an identity-based policy or a resource-based policy.
Now examine how these different functionalities offered by IAM can be leveraged to control access to AWS resources.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
