200 Acacad 30 en SG 03
200 Acacad 30 en SG 03
Contents
Module 3: Securing Access 4
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3
AWS Training and Certification Module 3: Securing Access
Securing Access
AWS Academy Cloud
Architecting
Welcome to the Securing Access module. This module reviews key security principles and concepts for securing
access to your cloud resources.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4
AWS Training and Certification Module 3: Securing Access
Introduction
Securing Access
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5
AWS Training and Certification Module 3: Securing Access
This module reviews key concepts that are related to security in the Amazon Web Services (AWS) Cloud. This
includes cloud security principles and the use of AWS Identity and Access Management (IAM) users, groups,
roles, and policies to secure access to cloud resources.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6
AWS Training and Certification Module 3: Securing Access
Module overview
Presentation sections Activity
• Security principles • Examining IAM Policies
• Authenticating and securing access Knowledge checks
• Authorizing users • Knowledge check
• Parts of an IAM policy • Sample exam question
You will also participate in an activity to examine IAM policies and answer questions about the access that the
policies provide.
The module wraps up with a sample exam question and an online knowledge check that covers the presented
material.
The lab in this module is described on the next slide.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7
AWS Training and Certification Module 3: Securing Access
This module includes the guided lab listed. Additional information about this lab is included in the student guide
where the lab takes place, and detailed instructions are provided in the lab environment.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8
AWS Training and Certification Module 3: Securing Access
This slide asks you to take the perspective of a cloud architect as you think about how to secure access to your
cloud resources. Keep these considerations in mind as you progress through this module. Remember that the
cloud architect should work backward from the business need to design the best architecture for a specific use
case. As you progress through the module, consider the café scenario in the course as an example business
need, and think about how you would address these needs.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9
AWS Training and Certification Module 3: Securing Access
Security principles
Securing Access
This section reviews the following principles, which are important for securing your AWS architectures:
• Consider the AWS shared responsibility model when you determine how you need to apply security to your
cloud architectures.
• Use the security pillar of the Well-Architected Framework to identify the design principles that apply to your
architectures.
• Always apply the principle of least privilege when you secure your AWS resources.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10
AWS Training and Certification Module 3: Securing Access
Customer data
Image description: Shared responsibility model of customer and AWS responsibilities. The customer is
responsible for security in the cloud. This includes customer data. Platform, applications, identity and access
management. Operating system, network and firewall configurations. Client-side data encryption and data
integrity, authentication. Server-side encryption of the file system and data. Networking traffic protection, to
include encryption, integrity, and identity. AWS is responsible for security of the cloud. This includes the AWS
foundation services for compute, storage, databases, and networking, and the AWS Global Infrastructure, which
includes Regions, Availability Zones, and Edge Locations. End description.
Security and compliance are shared responsibilities between AWS and our customers. AWS operates, manages,
and controls security of the cloud. This responsibility includes securing components, from the host operating
system and virtualization layer to the physical security of the facilities where services operate. AWS is
responsible for protecting the global infrastructure that runs all the services that are offered in the AWS Cloud.
This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud
services.
You assume responsibility and management in the cloud. The security steps that you must take depend on the
services that you use and the complexity of your system. Customer responsibilities include selecting and
securing operating systems that run on Amazon Elastic Compute Cloud (Amazon EC2) instances, and securing
the applications that are launched on AWS resources. Customers must also select and handle the configuration
of security groups, firewalls, and networks. Customers are also responsible for managing accounts and their
data, including encryption options.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11
AWS Training and Certification Module 3: Securing Access
The AWS Academy Cloud Foundations course introduced the Well-Architected Framework. You might find it
helpful to open the website now to look at how the pillars are organized.
Security is one of the six pillars of the framework. The other pillars are operational excellence, reliability,
performance efficiency, cost optimization, and sustainability. The framework provides best practices and design
guidance across each pillar to help you make choices and review existing architectures.
You can use the AWS Well-Architected Tool to help you implement best practices that are part of the Well-
Architected Framework. The AWS WA Tool is a self-service tool that provides you with on-demand access to
current AWS best practices. These best practices can help you build solutions that meet the well-architected
security design principles as well as design principles that are associated with the other pillars.
Links to the AWS Well-Architected Framework site, and to an appendix of questions and best practices that can
help you follow the framework, are provided on the content resources page of your online course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 12
AWS Training and Certification Module 3: Securing Access
10
Your architecture will present a much stronger security presence if you follow these design principles from the
security pillar of the Well-Architected Framework:
• Implement a strong identity foundation: Implement the principle of least privilege and enforce separation of
duties with appropriate authorization for each interaction with your AWS resources. Centralize identity
management, and aim to eliminate reliance on long-term, static credentials.
• Protect data in transit and at rest: Classify your data into sensitivity levels, and use mechanisms, such as
encryption, tokenization, and access control, where appropriate.
• Apply security at all layers: Apply a defense-in-depth approach with multiple security controls, and apply it
to all layers (for example, edge of network, virtual private cloud [VPC], load balancing, every instance and
compute service, operating system, application, and code).
• Keep people away from data: Use mechanisms and tools to reduce or eliminate the need for direct access or
manual processing of data. This reduces the risk of mishandling or modification and human error when
handling sensitive data.
• Maintain traceability: Monitor, alert, and audit actions and changes to your environment in real time.
Integrate log and metric collection with systems to automatically investigate and take action.
• Prepare for security events: Prepare for an incident by having incident management and investigation
policies and processes that align to your organizational requirements. Run incident response simulations, and
use tools with automation to increase your speed for detection, investigation, and recovery.
• Automate security best practices: Automated software-based security mechanisms improve your ability to
securely scale more rapidly and cost-effectively. Create secure architectures, which includes implementing
controls that are defined and managed as code in version-controlled templates.
The security pillar of the Well-Architected Framework describes how to take advantage of cloud technologies to
protect data, systems, and assets in a way that can improve your security posture. For more information, see
the Security Pillar of the AWS Well-Architected Framework link on the content resources page of your online
course.
The next few slides review key aspects of the first two design principles.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13
AWS Training and Certification Module 3: Securing Access
11
Part of implementing a strong identity foundation is using policies to grant or deny access to your AWS
resources, such as Amazon Simple Storage Service (Amazon S3) buckets. In this example, John can read, write,
and delete objects in S3 bucket 1. However, he can only read the objects in S3 bucket 2, and he is explicitly
denied access to a specific Amazon DynamoDB table.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 14
AWS Training and Certification Module 3: Securing Access
Best practices:
• Grant only the
permissions that are
required to perform a
task.
• Start with a minimum set
of permissions.
• Grant additional
permissions as necessary.
• Revoke unnecessary
permissions.
12
Image description: Diagram of John, an administrator user, receiving permissions from a policy. The policy
allows full access to S3 buckets 1 and 2. Mary, a marketing user, receives read-only access to S3 bucket 1 and is
explicitly denied access to S3 bucket 2 through policies. End description.
Another key aspect to implementing a strong identity foundation is to apply the principle of least privilege to
the permissions that you set. This means granting only the permissions that are needed to perform a task.
It’s more secure to start with a minimum set of permissions and grant additional permissions as needed. This
provides better security than starting with permissions that are too permissive and then trying to restrict them
later. To define the correct set of permissions, you must research what access is needed to accomplish a specific
task.
When you create access policies, determine what your users need to do, and then craft policies that allow them
to perform only those tasks. Similarly, create policies for individual resources that identify precisely who is
allowed to access the resource, and allow only the minimal permissions for those users. For example, perhaps
developers should be allowed to create EC2 instances in production environments but not to stop or terminate
the instances.
For more information, see the Apply Least-Privilege Permissions link on the content resources page of your
online course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 15
AWS Training and Certification Module 3: Securing Access
Use encryption
13
Image description: Diagram of protecting data in transit by using cryptographic protocol. TLS protects the data
as it moves to and from the client and cloud storage. End description.
In addition to limiting who has permissions to access data, you should prevent access to data through
encryption. This practice relates to the design principle of protecting data in transit and at rest.
Data in transit is data that is actively moving from one location to another, such as across the internet or
through a private network. To protect data in transit, you protect data while it's traveling from network to
network or being transferred from a local storage device to a cloud storage device. Wherever data is moving,
protection measures are critical because data is often considered less secure while in motion.
An example of protecting data in transit is encrypting pictures as they are uploaded to a cloud service. The
pictures don’t need to be encrypted; however, by using TLS, you can ensure the privacy of the transfer.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 16
AWS Training and Certification Module 3: Securing Access
14
Image description: Diagram of client-side encryption. The client encrypts data before sending it. The encrypted
data is sent through a secure pipe from the client to cloud storage. The client retrieves encrypted data from
cloud storage and decrypts the data for use. End description.
Protecting data at rest means using encryption to protect data that is stored anywhere in your cloud solution.
Client-side encryption provides end-to-end protection for your object, in transit and at rest, from its source to
storage.
An example is encrypting data on a mobile device. Because mobile devices can be easily lost or stolen,
encryption will ensure that data is scrambled and isn’t accessible to unintended users.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17
AWS Training and Certification Module 3: Securing Access
15
Image description: Diagram of server-side encryption. Unencrypted data is sent through a secure pipe. The
server encrypts data when storing it and decrypts data when you request it. Data is returned to the client
through the secure pipe. End description.
Amazon S3 provides server-side encryption. The service encrypts your data at the object level as it writes the
data to disks in AWS data centers and decrypts the data when you access it.
An example is encryption of personal user data, such as a Social Security Number, that is stored in a cloud
database.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18
AWS Training and Certification Module 3: Securing Access
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 19
AWS Training and Certification Module 3: Securing Access
17
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 20
AWS Training and Certification Module 3: Securing Access
18
With authentication, you can use the identity of requesters to control who can use your AWS resources. With
authorization, you can also use access management to control what resources requesters can use and in what
ways.
To understand the fundamental aspects of authentication and authorization, consider a banking analogy. Think
of a bank that allows their customers (users) to access their accounts online. Suppose that you are a bank
customer. You have money in a checking account at that bank, and you want to pay a bill online. Should any
random person be able to log in to your bank account and pay their bills with the money in your account? No, of
course not!
Before the bank allows you to access your checking account, the bank must ensure that the person accessing
the account is you. The bank wants to authenticate that you are who you claim to be. They typically accomplish
this authentication by requiring you to enter your username and a password that is supposed to be known only
to you. For extra security, they might have configured multi-factor authentication (MFA). Thus, in addition to
typing in a password, you also must receive a code on your phone and enter that code on the bank’s website.
Now, suppose that you are successfully logged in to the bank website (authenticated). Can you pay your bill by
using the money in another customer's account? No, of course not! You don’t have the authorization to access
accounts that don’t belong to you. However, you are authorized to access the money in your account, and you
are authorized to pay bills by using your money.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 21
AWS Training and Certification Module 3: Securing Access
19
AWS Identity and Access Management is also known as IAM. With this service, you can configure fine-grained
access control to AWS resources. You can use IAM to follow security best practices by granting unique security
credentials to users and groups. These credentials specify which AWS service APIs and resources the users and
groups can access. IAM is secure by default—users don’t have access to AWS resources until permissions are
explicitly granted.
IAM is integrated into most AWS services. You can define access controls from one place in the AWS
Management Console, and they will take effect throughout your AWS environment.
You can use IAM to grant your employees and applications access to the console and to AWS service APIs by
using your existing identity systems. AWS supports federation from corporate systems, such as Microsoft Active
Directory, and standards-based identity providers.
IAM also supports multi-factor authentication (MFA). If MFA is enabled and an IAM user attempts to log in, they
will be prompted for an authentication code. The authentication code is delivered to an MFA device, such as a
hardware or virtual device. For example, Google Authenticator is a virtual MFA device that runs as an
application on a user's smartphone.
You can create accounts that have permissions that are similar to the AWS account root user. However, a best
practice is to create administrative accounts that grant only the account permissions that are needed. Follow
the principle of least privilege. For example, ask yourself whether your database administrator (DBA) should be
able to provision EC2 instances. If the answer is no, then provision accounts accordingly.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 22
AWS Training and Certification Module 3: Securing Access
IAM terminology
Term Definition
IAM resource User, group, role, policy and identity-provider objects stored in
IAM
IAM entity IAM resource objects that are used by AWS for authentication
(users and roles)
Principal Person or application that can sign in and make requests to AWS
20
The following terms are specific to IAM, and you will use them throughout this course:
• An IAM resource is the user, group, role, policy, or identity provider object that is stored in IAM. As with other
AWS services, you can add, edit, and remove resources from IAM.
• An IAM entity is the IAM resource object that AWS uses for authentication. Entities include IAM users and
roles. Through an IAM entity, you can be provided the ability to sign in to the console and make
programmatic requests to AWS services by using the APIs or AWS Command Line Interface (AWS CLI).
• An IAM identity is the IAM resource object that is used to identify and group. You can attach a policy to an
IAM identity. Identities include users, groups, and roles.
• A principal is a person or application that uses the AWS account root user, an IAM user, or an IAM role to
authenticate and make requests to AWS. Principals include assumed roles and federated users—external
identities that don’t have an AWS account.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 23
AWS Training and Certification Module 3: Securing Access
21
You can use IAM to control access to your AWS resources. You achieve this access control by creating users,
groups, and roles. You can also enforce access control by attaching policies to IAM entities.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 24
AWS Training and Certification Module 3: Securing Access
*An AWS access key is a combination of an access key ID and a secret key.
22
When you interact with AWS you must provide AWS credentials. Two primary types of credentials are used for
authentication, and which credential type you use depends on how you access AWS:
• To authenticate from the console, you must sign in with your username and password.
• To authenticate through the AWS CLI, SDKs, or direct API calls, you must provide an AWS access key. The AWS
access key is the combination of an access key ID and a secret access key. You cannot use a username and
password to authenticate through these methods.
This is a very simplified introduction to using security credentials. For more information, see the AWS Security
Credentials link on the content resources page of your online course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 25
AWS Training and Certification Module 3: Securing Access
23
By following these best practices, you can enhance the security of your account setup. For more details and a
complete list of current best practices, see the link titled Security best practices in IAM on the content
resources page of your online course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 26
AWS Training and Certification Module 3: Securing Access
24
Protect your root user credentials like you would protect your credit card number, or any other sensitive or
secret data.
Rather than using the root user to do day-to-day administrative tasks, create an administrative user with
permissions to perform most administrative tasks. If you use the AWS IAM Identity Center (successor to AWS
Single Sign-On) to create the administrative user, temporary rather than long term credentials are used. For
instructions, see the AWS IAM Identity Center User Guide link on the content resources page of your online
course.
Only use the root user to perform those tasks that cannot be performed by any other user. For more
information, see the Tasks That Require Root User Credentials link on the content resources page of your online
course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 27
AWS Training and Certification Module 3: Securing Access
25
Instead of using the root user to perform administrative tasks, follow these steps to create an administrator
(admin) user:
1. Log in as the root user, and set up MFA on the root user.
2. Create a new admin user, add MFA, and download the programmatic keys. In the example on the slide, John
is the admin user.
3. Log out as the root user.
4. Log in as the admin user (in this example, John).
5. Create user accounts. Each user has a separate policy with permissions. In the example on the slide, user
accounts are created for John, Ji, and Nikki.
For more information, see the Security Best Practices in IAM link on the content resources page of your online
course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 28
AWS Training and Certification Module 3: Securing Access
26
Image description: Diagram of IAM policy 1 attached to an IAM group for sales users and IAM policy 2 attached
to a group of IT users. IAM users 1 and 2 are members of the IAM sales group and receive the permissions from
the policy that is attached to that group. IAM users 3, 4, and 5 are assigned to the IAM IT group and receive
different permissions through the policy that is attached to that group. End description.
You can attach an IAM policy to an IAM user, group, role, or any combination of these resources.
To configure long-term access, a best practice is to attach IAM policies to IAM groups, and then assign IAM
users to these IAM groups. An IAM user who is a member of an IAM group inherits the permissions that are
attached to that group. You can also attach IAM policies directly to an IAM user to further customize the access
that is granted through the group.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 29
AWS Training and Certification Module 3: Securing Access
IAM roles
Characteristics Common use cases
• Provides temporary security credentials • Application that runs on Amazon
Elastic Compute Cloud (Amazon EC2)
• Isn’t uniquely associated with one person
• Cross-account access for an IAM user
• Can be assumed by a person, application,
or service • Mobile applications
• Is often used to delegate access
27
By using an IAM role, you can define a set of permissions for the resources that a user or service needs to
access. However, the permissions aren’t attached to an IAM user or group. Instead, the permissions are
attached to a role, and the user or service assumes the role. When a user assumes a role, the user's prior
permissions are temporarily forgotten. AWS returns temporary security credentials that the user can then use
to make programmatic requests to AWS. When you use IAM roles, you don’t need to grant long-term security
credentials to each entity that requires access to a resource.
The following examples describe situations when you might need to use temporary security credentials:
• An IAM user in one AWS account needs temporary access to resources in another AWS account.
• User identities that were authenticated by a system outside of AWS (federated users) need to perform AWS
tasks and access your AWS resources. You don’t want to create and manage IAM users for people outside
your organization.
• A mobile app needs access to your AWS resources. You don’t want to store AWS credentials with the
application, where they can be difficult to rotate and users can potentially extract them.
• An application that runs on an EC2 instance needs access to AWS resources. You don’t want to store long-
term credentials locally.
When you need to provide an IAM user in another account or a federated user access to your AWS resources,
create an IAM role with temporary credentials instead of creating an IAM user in your account. Similarly, for an
application that runs on an EC2 instance and requires access to AWS resources, create an IAM role, add the role
to an instance profile, and attach the profile to the instance. The application can then programmatically assume
the role at runtime.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 30
AWS Training and Certification Module 3: Securing Access
28
The diagram on this slide illustrates three uses cases of an IAM role:
• In the first use case, an IAM user in AWS account 1 needs temporary access to an application that runs on an
EC2 instance. You first create an IAM policy with the necessary permissions. You then create an IAM role and
attach the policy to the role. The IAM user can now assume the role and access the EC2 instance.
• In the second use case, an application that runs on an EC2 instance needs access to an S3 bucket. After you
create an IAM role with the necessary permissions, you add the role to an instance profile and attach the
profile to the instance. The application can then access the S3 bucket.
• In the third use case, an IAM user in AWS account 2 needs to access an S3 bucket in AWS account 1. You
create a cross-account IAM role in account 1 that defines account 2 as a trusted entity. An IAM user in
account 2 can then switch roles to the cross-account role and access the S3 bucket in account 1.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 31
AWS Training and Certification Module 3: Securing Access
29
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 32
AWS Training and Certification Module 3: Securing Access
Authorizing users
Securing Access
30
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 33
AWS Training and Certification Module 3: Securing Access
31
A policy is an object that defines permissions for the identity or resource that it’s associated with. By using
policies, you can fine-tune permissions that are granted to principals. Examples of principals include IAM users,
IAM roles, and AWS services.
Two types of policies exist: identity-based policies and resource-based policies. The biggest difference is where
they are applied. Identity-based policies are attached to an IAM user, group, or role and indicate what the user
is permitted to do. Resource-based policies are attached to a resource and indicate what a specified user (or
group of users) is permitted to do with the resource.
Most policies are stored in AWS as JSON documents. AWS evaluates these policies when an IAM principal makes
a request. Permissions in the policies determine whether the request is allowed or denied.
A best practice is to follow the principle of least privilege, which was covered earlier in the module.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 34
AWS Training and Certification Module 3: Securing Access
32
When IAM determines whether an action is allowed, the service first checks for the existence of any applicable
explicit denial policy. If an explicit denial doesn’t exist, then IAM checks for any applicable explicit allow policy. If
an explicit deny or explicit allow policy doesn’t exist, IAM reverts to the default and denies access. This process
is referred to as an implicit deny. A user will be permitted to take the action only if the requested action is not
explicitly denied and is explicitly allowed.
The diagram on the slide shows the logic that AWS uses to evaluate IAM policies. AWS evaluates all applicable
policies and uses the following evaluation logic:
• By default, all requests are denied.
• An explicit allow overrides the default deny.
• An explicit deny overrides any explicit allow.
The order that the policies are evaluated in has no effect on the outcome of the evaluation. All policies are
evaluated, and the result is always that the request is either allowed or denied. Suppose that a conflict occurs
(one policy allows an action and another policy denies an action). Then, the most restrictive policy (that is, the
policy that denies the action) is applied.
When you develop IAM policies, it can be difficult to determine whether access to a resource will be granted to
an IAM entity. The IAM policy simulator is a helpful tool to test and troubleshoot IAM policies. For more
information, see the Testing IAM Policies with the IAM Policy Simulator link on the content resources page of
your online course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 35
AWS Training and Certification Module 3: Securing Access
What does a particular identity have access to? Who has access to a particular resource?
Carlos Resource Read Write List Resource X User Read Write List
Resource X Allow Allow Allow Ana Allow Allow Allow
Note: In the tables on the slide, N/A means not applicable because the policy doesn't specify permissions for
that particular action.
To reiterate, two types of IAM policies can grant permissions: identity-based policies and resource-based
policies. The difference between the two types is where they are applied, which depends on the type of access
that you're authorizing or restricting.
Identity-based policies are attached to an IAM user, group, or role. They indicate what that identity can do. For
example, you could grant a user the ability to access a DynamoDB table.
Resource-based policies are attached to a resource. They indicate what a specified user (or group of users) is
permitted to do with the resource. For example, you could use a resource-based policy to grant access to an S3
bucket or to grant cross-account access between two trusted AWS accounts.
For more information, see the Identity-Based Policies and Resource-Based Policies link on the content resources
page of your online course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 36
AWS Training and Certification Module 3: Securing Access
Policies: Example 1
Identity-based Resource-based
(Attached to an user, group, or role) (Attached to an AWS resource)
34
Note: In the tables on the slide, N/A means not applicable because the policy doesn't specify permissions for
that particular action.
Amazon S3 supports two types of access control mechanisms: identity-based (or user based) and resource-
based.
In the example on the slide, an IAM user named Bob has an identity-based policy attached. The policy allows
him to use the GET, PUT, and LIST APIs for S3 bucket X. However, the resource-based policy for bucket X allows
him to use GET and LIST, but denies the ability to use PUT. This means that Bob cannot PUT objects into bucket
X, even though his identity-based policy allows it.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 37
AWS Training and Certification Module 3: Securing Access
Policies: Example 2
Identity-based Resource-based
(Attached to an user, group, or role) (Attached to an AWS resource)
35
Note: In the tables on the slide, N/A means not applicable because the policy doesn't specify permissions for
that particular action.
The example on this slide focuses on Bob’s permissions for bucket Y. Bob's identity-based policy allows the LIST
action. The policy doesn’t explicitly allow or deny the GET and PUT actions on bucket Y. The resource-based
policy for bucket Y allows Bob to use GET and LIST, but doesn’t specify the PUT action. Therefore, Bob can read
objects from the bucket, even though his identity-based policy doesn't explicitly allow it.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 38
AWS Training and Certification Module 3: Securing Access
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 39
AWS Training and Certification Module 3: Securing Access
37
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 40
AWS Training and Certification Module 3: Securing Access
38
IAM policies are stored in AWS as JSON documents. Each statement includes information about a single
permission. If a policy includes multiple statements, AWS applies a logical OR across the statements when
evaluating them.
The following are common elements that are found in an IAM policy document:
• Version: Specify the version of the policy language that you want to use.
• Statement: Use this main policy element as a container for the following elements. You can include more
than one statement in a policy:
• Effect: Use Allow or Deny to indicate whether the policy allows or denies access.
• Principal: If you create a resource-based policy, you must indicate the account, user, role, or federated user
that you would like to allow or deny access to. If you are creating an IAM policy to attach to a user or role,
you cannot include this element. The principal is implied as the user or role that the policy is attached to.
• Action: Include a list of actions that the policy allows or denies.
• Resource: If you are creating an IAM policy to attach to a user or role, you must specify a list of resources to
which the actions apply. If you create a resource-based policy, this element is optional.
• Condition (optional): Specify the circumstances where the policy grants permissions.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 41
AWS Training and Certification Module 3: Securing Access
39
The policy uses a combination of an explicit allow and an explicit deny to limit access within an AWS account.
The example IAM policy on this slide allows access only to the following resources:
• The DynamoDB table course-notes.
• The S3 buckets course-notes-web and course-notes-mp3.
The explicit deny ("Effect":"Deny") element uses the NotResource element to ensure that users cannot use any
other DynamoDB or S3 actions or resources, except those that are specified in the policy. This is the case even if
permissions have been granted in another policy. An explicit deny statement takes precedence over an allow
statement.
In its totality, this IAM policy allows access to specific DynamoDB and Amazon S3 resources. It then explicitly
denies access to any other DynamoDB or Amazon S3 resources in the account.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 42
AWS Training and Certification Module 3: Securing Access
40
After you apply an identity-based policy to a user, group, or role, the policy allows or denies the ability for the
entity to perform specific actions.
The slide shows an example of an identity-based policy. If this policy was attached to an IAM user, the user
would be able to perform the following actions:
• Create, delete, get, or update their own password by using IAM LoginProfile actions.
• Create, delete, list, or update their own access key by using IAM AccessKey actions.
• Create, delete, get, list, or update their own Secure Shell (SSH) keys by using IAM SSHPublicKey actions.
The actions in the policy include wildcards, which are indicated with an asterisk (*). This format provides a
convenient way to include a set of related actions. Notice that the policy gets the AWS username dynamically,
as defined in the Resource key.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 43
AWS Training and Certification Module 3: Securing Access
41
The slide provides an example of a resource-based policy that allows cross-account access. In this scenario,
account A created the resource-based policy. The policy grants account B access to perform any Amazon S3 API
operation—which is indicated by the asterisk (*)—on the S3 bucket named DOC-EXAMPLE-BUCKET in account
A.
This S3 bucket policy doesn’t specify any IAM users, groups, or roles. Instead, it specifies account B (AWS
account number 111122223333). Account B should create an IAM user policy to allow a user in account B to
access account A's bucket.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 44
AWS Training and Certification Module 3: Securing Access
42
In this educator-led activity, you will review a few examples of IAM policies. For each policy, you will be asked
questions about what the policy allows you to do. Your educator will lead you in a discussion of each question
and reveal the correct answers one at a time.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 45
AWS Training and Certification Module 3: Securing Access
43
Look at the example IAM policy. Your educator will ask a series of questions to assess whether you understand
what actions this policy will allow and deny. Use the link provided in the content resources page of your online
course to answer the question.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 46
AWS Training and Certification Module 3: Securing Access
{ 1. Does the policy allow the user to terminate any EC2 instance at
"Version":"2012-10-17", any time without conditions?
"Statement":[{
"Effect":"Allow", Answer: No. The policy allows the action but applies a condition.
"Action":"ec2:TerminateInstances",
"Resource":"*" 2. Does the policy allow the user to terminate an EC2 instance from
}, anywhere?
{
"Effect":"Deny", Answer: No. The call must come from one of the two IP address
"Action":"ec2:TerminateInstances", ranges that are specified in aws:SourceIp.
"Condition":{
"NotIpAddress":{ 3. If the user’s IP address is 192.0.2.243, could they terminate an
"aws:SourceIp":[ EC2 instance according to this policy?
"192.0.2.0/24",
"203.0.113.0/24" Answer: Yes, because the 192.0.2.0/24 IP address range includes
] addresses 192.0.2.0 through 192.0.2.255.
}
},
"Resource":"*"
...
44
Analyze this second example of an IAM policy. Your educator will ask a series of questions to assess whether
you understand what actions this policy will allow and deny.
For question 3, to calculate the range of a CIDR block, you can use a CIDR to IPv4 Conversion tool resource
located in the content resources page of your online course.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 47
AWS Training and Certification Module 3: Securing Access
Observe this example of an IAM policy. Your educator will ask a series of questions to assess whether you
understand what actions this policy will allow and deny.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 48
AWS Training and Certification Module 3: Securing Access
46
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 49
AWS Training and Certification Module 3: Securing Access
47
You will now complete a lab. The next slides summarize what you will do in the lab, and you will find the
detailed instructions in the lab environment.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 50
AWS Training and Certification Module 3: Securing Access
48
Access the lab environment through your online course to get additional details and complete the lab.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 51
AWS Training and Certification Module 3: Securing Access
49
Your instructor might review these questions with you, or you might review them on your own. Use this
opportunity to extend your thinking about the tasks that you performed during the lab.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 52
AWS Training and Certification Module 3: Securing Access
Module wrap-up
Securing Access
50
This section summarizes what you have learned and brings the module to a close.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 53
AWS Training and Certification Module 3: Securing Access
Module summary
This module prepared you to do the following:
• Describe the security principles in the AWS Cloud.
• Explain the purpose of IAM users, groups, and roles.
• Explain how IAM policies determine permissions in an AWS account.
51
This module reviewed key security concepts that are applicable across all parts of your cloud solutions.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 54
AWS Training and Certification Module 3: Securing Access
52
Use the cafe business as an example to apply what you’ve learned in this module to building a cloud
architecture. What types of access considerations might be needed for the café staff?
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 55
AWS Training and Certification Module 3: Securing Access
53
Use your online course to access the knowledge check for this module.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 56
AWS Training and Certification Module 3: Securing Access
54
The question identifies the need for a team of developers to access resources for a specific duration. The fact
that they are a team of developers implies that the developers would need similar access to the resources. The
specified duration suggests that these users won’t require access after this period ends. The question also asks
that you think in terms of key security principles
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 57
AWS Training and Certification Module 3: Securing Access
Choice Response
A Create a single IAM user for the developer team, and attach the required IAM policies to the user.
B Create an IAM user for each developer, and attach the required IAM policies to each user.
C Create an IAM user for each developer, put them all in an IAM group, and attach the required IAM policies to the group.
Create a single IAM user for the developer team, place it in an IAM group, and attach the required IAM policies to the
D
group.
55
Use the key words that you identified on the previous slide, and review each of the possible responses to
determine which one best addresses the question.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 58
AWS Training and Certification Module 3: Securing Access
Choice Response
C Create an IAM user for each developer, put them all in an IAM group, and attach the required IAM policies to the group.
56
Choices A and D (creating a single shared IAM user for the team) shouldn’t be implemented. Having multiple
users share a single user account is generally a bad security practice. The password is shared by all users, and
you lose individual accountability for actions that are performed by the user account.
Choice B ( IAM users for each developer, and IAM policies attached to each user) will work but it is not the most
efficient option for managing a team, especially when it is likely that developers will be added or removed
during the project.
Choice C (putting users into a group, and attaching the policy to the group) is the best choice. Attaching a policy
to a group applies the same access rules to all members of the group. This method also automatically applies
the access rules to new users that are added to the group and removes those access rules from users that are
removed from the group.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 59
AWS Training and Certification Module 3: Securing Access
Thank you
57
That concludes this module. The Content Resources page of your course includes links to additional resources
that are related to this module.
© 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 60