In this section, you will investigate two different approaches organizations can take to control access, either based on a principal’s role or based on specific properties, also known as attributes, characterizing a principal.
This is the traditional access control approach where the permissions defining the actions that a principal (user or role) can perform are based on the function that the person has in their job. You typically define different policies for the roles you need in your organization and then assign these policies to IAM identities (users, user groups, or roles). Note that AWS already includes some managed policies for job functions.
Since granting the least privilege is a best practice, you should restrict the permissions that you grant to the various job functions to the strict minimum each of them needs to perform its job. Typically, you do that by explicitly listing the AWS resources each job function has access to, including the relevant actions that can be performed.
The main issue in doing that effectively is that the AWS resources a job function needs access to are likely to be quite variable over time. Every time a new AWS resource that one or more job functions need access to get added (for instance, a new S3 bucket, a new DynamoDB table, or a new Relational Database Service (RDS) database), you must update the policies for these job functions. Every time a specific job function changes team or project, you must update its permissions. The more granular control you want to have, the more policies you will have, and the more often you will need to update them.
So, the temptation rapidly grows for an AWS administrator to provide slightly too wide permissions by using wildcards (‘*’) in job functions’ policies instead of actual resources’ Amazon Resource Names (ARNs).
Therefore, a lack of flexibility and management overhead is often the main drawback of a traditional RBAC approach.
This is where an ABAC approach can help. With ABAC, you can create fewer and more compact policies.
You can, for instance, give an identity access to all resources of a certain type (for example, all S3 buckets) within the account but then specify a condition filtering on the value of a certain tag (or attribute), which would only allow access to the resource if the principal tag matched the resource tag. That tag could represent anything meaningful to your organization and context (for example, business unit (BU) or project), and you could filter on multiple tags (or attributes).
ABAC allows much more flexibility and is far less painful in terms of administration while still providing fine-grained access control to implement the least-privilege best practice.
ABAC really shines in helping you simplify permissions management at scale; therefore, it comes in handy for complex organizations. These organizations are likely to use identity federation for their workforce to access AWS resources leveraging their already existing identity provider (IdP), such as Microsoft Active Directory (AD). What you will see later when discussing user federation is that you can pass session tags when you create a temporary session for a role or a federated user, and when integrating your IdP with AWS, you can specify which user attributes you would like to pass as session tags. So, imagine that you set up attributes such as job function, department, and team as session tags. These session tags are then assigned to the principal and can be used in your identity-based or resource-based policies.
As an example, to illustrate the preceding information, the following identity-based policy would give, to the identity it is assigned to, full access to EC2 resources in the account, with the condition that the principal is in a systems administrator (SysAdmin) job function, provided that the job function is being passed as a session tag through identity federation:
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “ec2:*”,
“Resource”: “*”,
“Condition”: {“StringEquals”: {“aws:PrincipalTag/
jobfunction”: “SysAdmin”}}
}
]
}
So, now that you have covered IAM and how to leverage it to establish granular access control on AWS resources, which other security mechanisms do you need to investigate? Well, to start with, you need to consider cases where the permissions provided to a principal are simply not enough for what they need to achieve. What can you do in such cases while still adhering to your least-privilege best practice? This is where access delegation can help, and this is what you are going to cover next.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
