How IAM is used to securely manage access
Managing user identities with long term credentials in IAM
Managing access using IAM user groups & roles
Using IAM policies to define and manage permissions
Key Management Service (KMS)
AWS Web Application Firewall
AWS Firewall Manager
Using AWS Network Firewalls to Secure Your VPCs
AWS Security Hub Overview
Other AWS Security Services
AWS Secrets Manager
The course is part of this learning path
This section of the AWS Certified Solutions Architect - Professional learning path introduces the key identity management, security, and encryption services within AWS relevant to the AWS Certified Solutions Architect - Professional exam. Core to security is AWS Identity & Access Management commonly referred to as IAM. This service manages identities and their permissions that can access your AWS resources, so understanding how this service works and what you can do with it will help you to maintain a secure AWS environment. IAM is an important service in ensuring your resources are secure.
Want more? Try a Lab Playground or do a Lab Challenge!
- Learn about identity and access management on AWS, including users, groups & roles, IAM policies, MFA, identity federation, and cross-account access
- Learn the fundamentals of AWS Web Application Firewall (WAF), including what it is, when to use it, how it works, and why use it
- Understand how to configure and monitor AWS WAF
- Learn about AWS Firewall Manager and its components
- Learn how to configure AWS Shield
- Learn the fundamentals of AWS Cognito
Every time someone tries to access a resource within AWS, the request is processed through a series of steps. One of which involves evaluating the level of permissions based upon the policies that are used. So let's take a look at the whole process to understand how access is either granted or denied. And we can start with a simple four step process. So firstly authentication. We must first ensure that the principle sending the request is authenticated as a valid user.
Next, the context. Once authentication of the principle has been established, AWS then needs to determine the context of the request that is being asked, for example, what service or action is being requested. And this ensures that the relevant policies can be highlighted based on the request. We then have policy evaluation, and this is the part that we are interested in. Based on the request, there may be multiple policy types that need to be reviewed to determine the level of access, and I shall cover this in greater detail as we go through this lecture. And then finally, the result. AWS will determine if access is allowed or denied based upon the evaluation of all policies used.
So for this lecture, I want to focus purely on the third point, the policy evaluation and how that process is carried out. The rules for reviewing permissions across multiple policies in a single account is actually quite simple and can be summarized like this: by default, all access to a resource is denied. Access will only be allowed if an Allow has been specified within a policy associated with the principle. If a single Deny exists within any policy associated with the same principle against the same resource then that Deny will overrule any previous Allow that might exist for the same resource and action. So to reiterate, an explicit Deny will always take precedence over an Allow.
Now, there is an order in which policies are evaluated, and the following list of policies are shown in the order of evaluation. So firstly, we have any Organizational Service Control Policies. Then any Resource-based policies, then IAM permission boundaries, and then finally Identity-based policies. So let's look at an example scenario. Let's assume that the user, Stuart, is requesting to upload an object to the s3 bucket of ca-bucket-uk using the s3:PutObject API.
With this in mind, let's assume we have the following policies in place to see what happens at each step of the evaluation. So firstly, the evaluation will review any organization SCPs in place, and here is our example SCP. So this SCP will simply deny all access to RDS. So there is no Deny in place that affects the s3:PutObject requested by Stuart so the evaluation continues. Next, the evaluation will identify any resource-based policies, and here we have a Bucket Policy associated with the ca-bucket-uk as shown.
Again, there is no Deny here for the request in question, so the evaluation continues. Next, we have IAM Permission Boundaries. And this IAM Permission Boundary Policy is set on the user, Stuart. So this policy sets out a maximum permission boundary of full access to s3. Remember, permission boundaries do not actually grant permissions, they set the maximum privilege level, as full access to s3 allowed, the evaluation continues.
Finally, we have the evaluation of any Identity-based Policies, and this policy is associated to the group that the user, Stuart, belongs to. So as we can see, this policy allows any s3 action to the ca-bucket-uk. As a result, this permits Stuart to upload an object using s3:PutObject to the s3 bucket of ca-bucket-uk. So the final decision upon the policy evaluation is to allow the request.
Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.