Welcome to Module 4: AWS Cloud Security.

Security is the highest priority at Amazon Web Services (AWS). AWS delivers a scalable cloud
computing environment that is designed for high availability and dependability, while
providing the tools that enable you to run a wide range of applications. Helping to protect the
confidentiality, integrity, and availability of your systems and data is critical to AWS, and so is
maintaining customer trust and confidence. This module provides an introduction to the AWS
approach to security, which includes both the controls in the AWS environment and some of
the AWS products and features customers can use to meet their security objectives.
This module will address the following topics:

• AWS shared responsibility model

• AWS Identity and Access Management (IAM)
• Securing a new AWS account
• Securing accounts
• Securing data on AWS
• Working to ensure compliance
• Additional security services and resources

Section one includes an educator-led activity on the AWS shared responsibility model.

Section two includes a recorded IAM demo, and the end of this same section there includes a
hands-on lab that provides you with practice configuring IAM by using the AWS Management
Console.

Finally, you will be asked to complete a knowledge check to test your understanding of the
key concepts that are covered in this module.
After completing this module, you should be able to:

• Recognize the shared responsibility model

• Identify the responsibility of the customer and AWS
• Recognize IAM users, groups, and roles
• Describe different types of security credentials in IAM
• Identify the steps to securing a new AWS account
• Explore IAM users and groups
• Recognize how to secure AWS data
• Recognize AWS compliance programs
Introducing Section 1: AWS shared responsibility model.
Security and compliance are a shared responsibility between AWS and the customer. This
shared responsibility model is designed to help relieve the customer’s operational burden. At
the same time, to provide the flexibility and customer control that enables the deployment of
customer solutions on AWS, the customer remains responsible for some aspects of the
overall security. The differentiation of who is responsible for what is commonly referred to as
security “of” the cloud versus security “in” the cloud.

AWS operates, manages, and controls the components from the software virtualization layer
down to the physical security of the facilities where AWS services operate. AWS is
responsible for protecting the 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 the AWS Cloud services.

The customer is responsible for the encryption of data at rest and data in transit. The
customer should also ensure that the network is configured for security and that security
credentials and logins are managed safely. Additionally, the customer is responsible for the
configuration of security groups and the configuration of the operating system that run on
compute instances that they launch (including updates and security patches).
AWS is responsible for security of the cloud. But what does that mean?

Under the AWS shared responsibility model, AWS operates, manages, and controls the
components from the bare metal host operating system and hypervisor virtualization layer
down to the physical security of the facilities where the services operate. It means that AWS
is responsible for protecting the global infrastructure that runs all the services that are
offered in the AWS Cloud. The global infrastructure includes AWS Regions, Availability Zones,
and edge locations.

AWS is responsible for the physical infrastructure that hosts your resources, including:

• Physical security of data centers with controlled, need-based access; located in

nondescript facilities, with 24/7 security guards; two-factor authentication; access logging
and review; video surveillance; and disk degaussing and destruction.
• Hardware infrastructure, such as servers, storage devices, and other appliances that AWS
relies on.
• Software infrastructure, which hosts operating systems, service applications, and
virtualization software.
• Network infrastructure, such as routers, switches, load balancers, firewalls, and cabling.
AWS also continuously monitors the network at external boundaries, secures access
points, and provides redundant infrastructure with intrusion detection.
Protecting this infrastructure is the top priority for AWS. While you cannot visit AWS data
centers or offices to see this protection firsthand, Amazon provides several reports from
third-party auditors who have verified our compliance with a variety of computer security
standards and regulations.
While the cloud infrastructure is secured and maintained by AWS, customers are responsible
for security of everything they put in the cloud.
The customer is responsible for what is implemented by using AWS services and for the
applications that are connected to AWS. 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 any instance operating systems,
securing the applications that are launched on AWS resources, security group configurations,
firewall configurations, network configurations, and secure account management.
When customers use AWS services, they maintain complete control over their content.
Customers are responsible for managing critical content security requirements, including:
• What content they choose to store on AWS
• Which AWS services are used with the content
• In what country that content is stored
• The format and structure of that content and whether it is masked, anonymized, or
encrypted
• Who has access to that content and how those access rights are granted, managed, and
revoked

Customers retain control of what security they choose to implement to protect their own
data, environment, applications, IAM configurations, and operating systems.
Infrastructure as a service (IaaS) refers to services that provide basic building blocks for
cloud IT, typically including access to configure networking, computers (virtual or on
dedicated hardware), and data storage space. Cloud services that can be characterized as
IaaS provide the customer with the highest level of flexibility and management control
over IT resources. IaaS services are most similar to existing on-premises computing resources
that many IT departments are familiar with today.

AWS services—such as Amazon EC2—can be categorized as IaaS and thus require the
customer to perform all necessary security configuration and management tasks.
Customers who deploy EC2 instances are responsible for managing the guest operating
system (including updates and security patches), any application software that is installed on
the instances, and the configuration of the security groups that were provided by AWS.

Platform as a service (PaaS) refers to services that remove the need for the customer to
manage the underlying infrastructure (hardware, operating systems, etc.). PaaS services
enable the customer to focus entirely on deploying and managing applications. Customers
don’t need to worry about resource procurement, capacity planning, software maintenance,
or patching.
AWS services such as AWS Lambda and Amazon RDS can be categorized as PaaS because
AWS operates the infrastructure layer, the operating system, and platforms. Customers
only need to access the endpoints to store and retrieve data. With PaaS services, customers
are responsible for managing their data, classifying their assets, and applying the appropriate
permissions. However, these service act more like managed services, with AWS handling a
larger portion of the security requirements. For these services, AWS handles basic security
tasks—such as operating system and database patching, firewall configuration, and disaster
recovery.
Software as a service (SaaS) refers to services that provide centrally hosted software that is
typically accessible via a web browser, mobile app, or application programming interface
(API). The licensing model for SaaS offerings is typically subscription or pay as you go. With
SaaS offerings, customers do not need to manage the infrastructure that supports the
service. Some AWS services—such as AWS Trusted Advisor, AWS Shield, and Amazon
Chime—could be categorized as SaaS offerings, given their characteristics.

AWS Trusted Advisor is an online tool that analyzes your AWS environment and provides
real-time guidance and recommendations to help you provision your resources by following
AWS best practices. The Trusted Advisor service is offered as part of your AWS Support plan.
Some of the Trusted Advisor features are free to all accounts, but Business Support and
Enterprise Support customers have access to the full set of Trusted Advisor checks and
recommendations.

AWS Shield is a managed distributed denial of service (DDoS) protection service that
safeguards applications running on AWS. It provides always-on detection and automatic
inline mitigations that minimize application downtime and latency, so there is no need to
engage AWS Support to benefit from DDoS protection. AWS Shield Advanced is available to
all customers. However, to contact the DDoS Response Team, customers must have either
Enterprise Support or Business Support from AWS Support.
Amazon Chime is a communications service that enables you to meet, chat, and place
business calls inside and outside your organization, all using a single application. It is a pay-as-
you-go communications service with no upfront fees, commitments, or long-term contracts.
In this educator-led activity, you will be presented with two scenarios. For each scenario, you
will be asked several questions about whose responsibility it is (AWS or the customer) to
ensure security of the item in question. The educator will lead the class in a discussion of
each question and reveal the correct answers one at a time.
Consider the case where a customer uses the AWS services and resources that are shown
here. Who is responsible for maintaining security? AWS or the customer?

The customer uses Amazon Simple Storage Service (Amazon S3) to store data. The customer
configured a virtual private cloud (VPC) with Amazon Virtual Private Cloud (Amazon VPC). The
EC2 instance and the Oracle database instance that they created both run in the VPC.

In this example, the customer must manage the guest operating system (OS) that runs on the
EC2 instance. Over time, the guest OS will need to be upgraded and have security patches
applied. Additionally, any application software or utilities that the customer installed on the
Amazon EC2 instance must also be maintained. The customer is responsible for configuring
the AWS firewall (or security group) that is applied to the Amazon EC2 instance. The
customer is also responsible for the VPC configurations that specify the network conditions in
which the Amazon EC2 instance runs. These tasks are the same security tasks that IT staff
would perform, no matter where their servers are located.

The Oracle instance in this example provides an interesting case study in terms of AWS or
customer responsibility. If the database runs on an EC2 instance, then it is the customer's
responsibility to apply Oracle software upgrades and patches. However, if the database runs
as an Amazon RDS instance, then it is the responsibility of AWS to apply Oracle software
upgrades and patches. Because Amazon RDS is a managed database offering, time-
consuming database administration tasks—which include provisioning, backups, software
patching, monitoring, and hardware scaling—are handled by AWS. To learn more, see Best
Practices for Running Oracle Database on AWS for details.
Now, consider this additional case where a customer uses the AWS services and resources
that are shown here. Who is responsible for maintaining security? AWS or the customer?

A customer uses Amazon S3 to store data. The customer configured a virtual private cloud
(VPC) with Amazon VPC, and is running a web server on an EC2 instance in the VPC. The
customer configured an internet gateway as part of the VPC so that the web server can be
reached by using the AWS Management Console or the AWS Command Line Interface (AWS
CLI). When the customer uses the AWS CLI, the connection requires the use of Secure Shell
(SSH) keys.
Some key takeaways from this section of the module include:

• AWS and the customer share security responsibilities –

• AWS is responsible for security of the cloud
• Customer is responsible for security in the cloud

• AWS is responsible for protecting the infrastructure—including hardware, software,

networking, and facilities—that run AWS Cloud services

• For services that are categorized as infrastructure as a service (IaaS), the customer is
responsible for performing necessary security configuration and management tasks
• For example, guest OS updates and security patches, firewall, security group
configurations
Introducing Section 2: AWS Identity and Access Management (or IAM).
AWS Identity and Access Management (IAM) allows you to control access to compute,
storage, database, and application services in the AWS Cloud. IAM can be used to handle
authentication, and to specify and enforce authorization policies so that you can specify
which users can access which services.

IAM is a tool that centrally manages access to launching, configuring, managing, and
terminating resources in your AWS account. It provides granular control over access to
resources, including the ability to specify exactly which API calls the user is authorized to
make to each service. Whether you use the AWS Management Console, the AWS CLI, or the
AWS software development kits (SDKs), every call to an AWS service is an API call.

With IAM, you can manage which resources can be accessed by who, and how these
resources can be accessed. You can grant different permissions to different people for
different resources. For example, you might allow some users full access to Amazon EC2,
Amazon S3, Amazon DynamoDB, Amazon Redshift, and other AWS services. However, for
other users, you might allow read-only access to only a few S3 buckets. Similarly, you might
grant permission to other users to administer only specific EC2 instances. You could also
allow a few users to access only the account billing information, but nothing else.

IAM is a feature of your AWS account, and it is offered at no additional charge.

To understand how to use IAM to secure your AWS account, it is important to understand the
role and function of each of the four IAM components.

An IAM user is a person or application that is defined in an AWS account, and that must make
API calls to AWS products. Each user must have a unique name (with no spaces in the name)
within the AWS account, and a set of security credentials that is not shared with other users.
These credentials are different from the AWS account root user security credentials. Each
user is defined in one and only one AWS account.

An IAM group is a collection of IAM users. You can use IAM groups to simplify specifying and
managing permissions for multiple users.

An IAM policy is a document that defines permissions to determine what users can do in the
AWS account. A policy typically grants access to specific resources and specifies what the user
can do with those resources. Policies can also explicitly deny access.

An IAM role is a tool for granting temporary access to specific AWS resources in an AWS
account.
Authentication is a basic computer security concept: a user or system must first prove their
identity. Consider how you authenticate yourself when you go to the airport and you want to
get through airport security so that you can catch your flight. In this situation, you must
present some form of identification to the security official to prove who you are before you
can enter a restricted area. A similar concept applies for gaining access to AWS resources in
the cloud.

When you define an IAM user, you select what type of access the user is permitted to use to
access AWS resources. You can assign two different types of access to users: programmatic
access and AWS Management Console access. You can assign programmatic access only,
console access only, or you can assign both types of access.

If you grant programmatic access, the IAM user will be required to present an access key
ID and a secret access key when they make an AWS API call by using the AWS CLI, the AWS
SDK, or some other development tool.

If you grant AWS Management Console access, the IAM user will be required to fill in the
fields that appear in the browser login window. The user is prompted to provide either the
12-digit account ID or the corresponding account alias. The user must also enter their IAM
user name and password. If multi-factor authentication (MFA) is enabled for the user, they
will also be prompted for an authentication code.
AWS services and resources can be accessed by using the AWS Management Console, the
AWS CLI, or through SDKs and APIs. For increased security, we recommend enabling MFA.
With MFA, users and systems must provide an MFA token—in addition to the regular sign-in
credentials—before they can access AWS services and resources.
Options for generating the MFA authentication token include virtual MFA-compliant
applications (such as Google Authenticator or Authy 2-Factor Authentication), U2F security
key devices, and hardware MFA devices.
Authorization is the process of determining what permissions a user, service or application
should be granted. After a user has been authenticated, they must be authorized to access
AWS services.
By default, IAM users do not have permissions to access any resources or data in an AWS
account. Instead, you must explicitly grant permissions to a user, group, or role by creating
a policy, which is a document in JavaScript Object Notation (JSON) format. A policy lists
permissions that allow or deny access to resources in the AWS account.
To assign permission to a user, group or role, you must create an IAM policy (or find an
existing policy in the account). There are no default permissions. All actions in the account
are denied to the user by default (implicit deny) unless those actions are explicitly allowed.
Any actions that you do not explicitly allow are denied. Any actions that you explicitly deny
are always denied.

The principle of least privilege is an important concept in computer security. It promotes

that you grant only the minimal user privileges needed to the user, based on the needs of
your users. When you create IAM policies, it is a best practice to follow this security advice of
granting least privilege. Determine what users need to be able to do and then craft policies
for them that let the users perform only those tasks. Start with a minimum set of permissions
and grant additional permissions as necessary. Doing so is more secure than starting with
permissions that are too broad and then later trying to lock down the permissions granted.

Note that the scope of the IAM service configurations is global. The settings are not defined
at an AWS Region level. IAM settings apply across all AWS Regions.
An IAM policy is a formal statement of permissions that will be granted to an entity. Policies
can be attached to any IAM entity. Entities include users, groups, roles, or resources. For
example, you can attach a policy to AWS resources that will block all requests that do not
come from an approved Internet Protocol (IP) address range. Policies specify what actions are
allowed, which resources to allow the actions on, and what the effect will be when the user
requests access to the resources.

The order in which the policies are evaluated 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. When there is a conflict, the most restrictive policy applies.

There are two types of IAM policies. Identity-based policies are permissions policies that you
can attach to a principal (or identity) such as an IAM user, role, or group. These policies
control what actions that identity can perform, on which resources, and under what
conditions. Identity-based policies can be further categorized as:
• Managed policies – Standalone identity-based policies that you can attach to multiple
users, groups, and roles in your AWS account
• Inline policies – Policies that you create and manage, and that are embedded directly into
a single user group or role.

Resource-based policies are JSON policy documents that you attach to a resource, such as an
S3 bucket. These policies control what actions a specified principal can perform on that
resource, and under what conditions.
As mentioned previously, IAM policy documents are written in JSON.

The example IAM policy grants users access only to the following resources:
• The DynamoDB table whose name is represented by table-name.
• The AWS account's S3 bucket, whose name is represented by bucket-name and all the
objects that it contains.

The IAM policy also includes an explicit deny ("Effect":"Deny") element. The NotResource
element helps to ensure that users cannot use any other DynamoDB or S3 actions or
resources except the actions and resources that are specified in the policy—even if
permissions have been granted in another policy. An explicit deny statement takes
precedence over an allow statement.
While identity-based policies are attached to a user, group, or role, resource-based policies
are attached to a resource, such as an S3 bucket. These policies specify who can access the
resource and what actions they can perform on it.

Resource-based policies are defined inline only, which means that you define the policy on
the resource itself, instead of creating a separate IAM policy document that you attach. For
example, to create an S3 bucket policy (a type of resource-based policy) on an S3 bucket,
navigate to the bucket, click the Permissions tab, click the Bucket Policy button, and define
the JSON-formatted policy document there. An Amazon S3 access control list (ACL) is another
example of a resource-based policy.

The diagram shows two different ways that the user MaryMajor could be granted access to
objects in the S3 bucket that is named photos. On the left, you see an example of an identity-
based policy. An IAM policy that grants access to the S3 bucket is attached to the MaryMajor
user. On the right, you see an example of a resource-based policy. The S3 bucket policy for
the photos bucket specifies that the user MaryMajor is allowed to list and read the objects in
the bucket.

Note that you could define a deny statement in a bucket policy to restrict access to specific
IAM users, even if the users are granted access in a separate identity-based policy. An explicit
deny statement will always take precedence over any allow statement.
IAM policies enable you to fine-tune privileges that are granted to IAM users, groups, and
roles.

When IAM determines whether a permission is allowed, IAM first checks for the existence of
any applicable explicit denial policy. If no explicit denial exists, it then checks for any
applicable explicit allow policy. If neither an explicit deny nor an explicit allow policy exists,
IAM reverts to the default, which is to deny access. This process is referred to as an implicit
deny. The user will be permitted to take the action only if the requested action is not
explicitly denied and is explicitly allowed.

It can be difficult to figure out whether access to a resource will be granted to an IAM entity
when you develop IAM policies. The IAM Policy Simulator is a useful tool for testing and
troubleshooting IAM policies.
An IAM group is a collection of IAM users. IAM groups offer a convenient way to specify
permissions for a collection of users, which can make it easier to manage the permissions for
those users.

For example, you could create an IAM group that is called Developers and attach an IAM
policy or multiple IAM policies to the Developers group that grant the AWS resource access
permissions that developers typically need. Any user that you then add to the Developer
group will automatically have the permissions that are assigned to the group. In such a case,
you do not need to attach the IAM policy or IAM policies directly to the user. If a new user
joins your organization and should be granted developer privileges, you can simply add that
user to the Developers group. Similarly, if a person changes jobs in your organization, instead
of editing that user's permissions, simply remove the user from the group.

Important characteristics of IAM groups:

• A group can contain many users, and a user can belong to multiple groups.
• Groups cannot be nested. A group can contain only users, and a group cannot contain
other groups.
• There is no default group that automatically includes all users in the AWS account. If you
want to have a group with all account users in it, you need to create the group and add
each new user to it.
An IAM role is an IAM identity you can create in your account that has specific permissions.
An IAM role is similar to an IAM user because it is also an AWS identity that you can attach
permissions policies to, and those permissions determine what the identity can and cannot
do in AWS. However, instead of being uniquely associated with one person, a role is intended
to be assumable by anyone who needs it. Also, a role does not have standard long-term
credentials such as a password or access keys associated with it. Instead, when you assume a
role, the role provides you with temporary security credentials for your role session.

You can use roles to delegate access to users, applications, or services that do not normally
have access to your AWS resources. For example, you might want to grant users in your AWS
account access to resources they don't usually have, or grant users in one AWS account
access to resources in another account. Or you might want to allow a mobile app to use AWS
resources, but you do not want to embed AWS keys within the app (where the keys can be
difficult to rotate and where users can potentially extract them and misuse them). Also,
sometimes you may want to grant AWS access to users who already have identities that are
defined outside of AWS, such as in your corporate directory. Or, you might want to grant
access to your account to third parties so that they can perform an audit on your resources.

For all of these example use cases, IAM roles are an essential component to implementing
the cloud deployment.
In the diagram, a developer runs an application on an EC2 instance that requires access to the
S3 bucket that is named photos. An administrator creates the IAM role and attaches the role
to the EC2 instance. The role includes a permissions policy that grants read-only access to the
specified S3 bucket. It also includes a trust policy that allows the EC2 instance to assume the
role and retrieve the temporary credentials. When the application runs on the instance, it can
use the role's temporary credentials to access the photos bucket. The administrator does not
need to grant the application developer permission to access the photos bucket, and the
developer never needs to share or manage credentials.

To learn more details about this example, see Using an IAM Role to Grant Permissions to
Applications Running on Amazon EC2 Instances.
Some key takeaways from this section of the module include:

• IAM policies are constructed with JavaScript Object Notation (JSON) and define
permissions.
• IAM policies can be attached to any IAM entity.
• Entities are IAM users, IAM groups, and IAM roles.
• An IAM user provides a way for a person, application, or service to authenticate to AWS.
• An IAM group is a simple way to attach the same policies to multiple users.
• An IAM role can have permissions policies attached to it, and can be used to delegate
temporary access to users or applications.
Now, take a moment to watch the IAM Demo. The recording runs a little over 4 minutes, and
it reinforces many of the concepts that were discussed in this section of the module.

The demonstration shows how to configure the following resources by using the AWS
Management Console:

• An IAM role that will be used by an EC2 instance

• An IAM group
• An IAM user
Introducing Section 3: Securing a new AWS account.
When you first create an AWS account, you begin with a single sign-in identity that has
complete access to all AWS services and resources in the account. This identity is called the
AWS account root user and it is accessed by signing into the AWS Management Console with
the email address and password that you used to create the account. AWS account root users
have (and retain) full access to all resources in the account. Therefore, AWS strongly
recommends that you do not use account root user credentials for day-to-day interactions
with the account.

Instead, AWS recommends that you use IAM to create additional users and assign
permissions to these users, following the principle of least privilege. For example, if you
require administrator-level permissions, you can create an IAM user, grant that user full
access, and then use those credentials to interact with the account. Later, if you need to
revoke or modify your permissions, you can delete or modify any policies that are associated
with that IAM user.

Additionally, if you have multiple users that require access to the account, you can create
unique credentials for each user and define which user will have access to which resources.
For example, you can create IAM users with read-only access to resources in your AWS
account and distribute those credentials to users that require read access. You should avoid
sharing the same credentials with multiple users.
While the account root user should not be used for routine tasks, there are a few tasks that
can only be accomplished by logging in as the account root user. A full list of these tasks is
detailed on the Tasks that require root user credentials AWS documentation page.
To stop using the account root user, take the following steps:

1. While you are logged into the account root user, create an IAM user for yourself with
AWS Management Console access enabled (but do not attach any permissions to the user
yet). Save the IAM user access keys if needed.
2. Next, create an IAM group, give it a name (such as FullAccess), and attach IAM policies to
the group that grant full access to at least a few of the services you will use. Next, add the
IAM user to the group.
3. Disable and remove your account root user access keys, if they exist.
4. Enable a password policy for all users. Copy the IAM users sign-in link from the IAM
Dashboard page. Then, sign out as the account root user.
5. Browse to the IAM users sign-in link that you copied, and sign in to the account by using
your new IAM user credentials.
6. Store your account root user credentials in a secure place.

To view detailed instructions for how to set up your first IAM user and IAM group, see
Creating Your First IAM Admin User and Group.
Another recommended step for securing a new AWS account is to require multi-factor
authentication (MFA) for the account root user login and for all other IAM user logins. You
can also use MFA to control programmatic access. For details, see Configuring MFA-Protected
API Access.

You have a few options for retrieving the MFA token that is needed to log in when MFA is
enabled. Options include virtual MFA-compliant applications (such as Google Authenticator
and Authy Authenticator), U2F security key devices, and hardware MFA options that provide
a key fob or display card.
AWS CloudTrail is a service that logs all API requests to resources in your account. In this way,
it enables operational auditing on your account.

AWS CloudTrail is enabled on account creation by default on all AWS accounts, and it keeps a
record of the last 90 days of account management event activity. You can view and download
the last 90 days of your account activity for create, modify, and delete operations of services
that are supported by CloudTrail without needing to manually create another trail.

To enable CloudTrail log retention beyond the last 90 days and to enable alerting whenever
specified events occur, create a new trail (which is described at a high level on the slide). For
detailed step-by-step instructions about how to create a trail in AWS CloudTrail, see creating
a trail in the AWS documentation.
An additional recommended step for securing a new AWS account is to enable billing reports,
such as the AWS Cost and Usage Report. Billing reports provide information about your use
of AWS resources and estimated costs for that use. AWS delivers the reports to an Amazon
S3 bucket that you specify and AWS updates the reports at least once per day.

The AWS Cost and Usage Report tracks usage in the AWS account and provides estimated
charges, either by the hour or by the day.

For details about how to create an AWS Cost and Usage Report, see the AWS
Documentation.
The educator might optionally choose to show a full walkthrough of the first two major steps
that you must complete to secure a new AWS account. (These steps were described in the
previous slides.) The slides in this section provide screen captures of what it looks like to go
through the process in detail.
The screen capture shows an example of what the IAM Console Dashboard looks like when
you are logged in as the AWS account root user. To access this screen in an account:
1. Log in to the AWS Management Console as the AWS account root user.
2. Go to the IAM service page and click the Dashboard link.
3. Review the information in the Security Status panel.

In the screen capture, only one of the five security status checks has been completed (Delete
your root access keys). The goal of a person who completes the steps to secure the account is
to receive green checks next to each security status item.

A review of the current Security Status list indicates that:

• MFA has not been activated on the AWS account root user.
• No individual IAM users have been created.
• No permissions have been assigned to groups.
• No IAM password policy has been applied.
There is a custom IAM user sign-in link for the account. Note that the account number was
hidden in this screen capture. Optionally, you can use the Customize link to the right of the
IAM user sign-in link to change the name of the account so that it does not display the
account number. This link is used to sign in to the account, and it can be sent to users after
their accounts are created.
Before you create IAM users in the account, activate MFA on the account root user. To log in
as the account root user, use the email address that you used to create the account. The
account root user has access to everything, which is why it is important to secure this account
with restrictions.
To configure MFA:
1. Click the Activate MFA on your root account link.
2. Click Manage MFA.
3. Click Assign MFA device. You have three options: Virtual MFA device, U2F security key,
and Other hardware MFA device. A hardware device is an actual hardware device.
4. For purposes of this demonstration, select Virtual MFA device and then click Continue.
5. A new dialog box appears and asks you to configure a virtual MFA device. An app (such as
Google Authenticator) must be downloaded for this task. After the download is
complete, click Show QR code.
6. In the authenticator application, choose the plus sign (+).
7. Scan the barcode, and enter the first authentication code.
8. Wait a moment for the second code to display, and enter the second code.
9. Click the Assign MFA button.
10. Click Finish and refresh your browser.

In the Security Status panel, it should now show a green checkmark icon, which indicates
that MFA is now activated on the account root user.
Most AWS accounts are shared by multiple users in an organization. To support this practice,
you can set up each user with individually assigned permissions, or you can add users to the
appropriate IAM group that grants them specific permissions.
An AWS best practice is to provide each user with their own IAM user login so that they do
not log in as the account root user with global privileges, or use the same credentials as
someone else to log in to the account.
To configure this setup:
1. Click Create individual IAM users and then select Manage Users.
2. Select Add user and specify a new user name. Note that user names cannot have spaces.
3. Select the Access type. There are two access types (you can grant either type or both
types to the user, but for the purposes of this demonstration, grant both types):
• Programmatic access enables the user to have AWS CLI access to provision
resources. This option will generate an access key one time. This access key must
be saved because it will be used for all future access.
• AWS Management Console access enables the user to log in to the console.
4. If you chose to grant console access, either choose Autogenerate password, or select
Custom password and enter one.
5. Click Next: Permissions.
Next, you will assign permissions. You have three options for assigning permissions:
• Add user to group
• Copy permissions from an existing user
• Attach existing policies directly

6. You want to add the user to a group, so select Add user to group and then choose Create
group.

Note: A group is where you put users to inherit the policies that are assigned to the group.
7. Give the group a name. In this example, give the lead developer administrative access
and then choose Create group.
8. Select Next Review to review what will be created, and then choose Create user.
When a user is created—and assuming you enabled both programmatic and console access
when you defined the Access type setting and created the user—several artifacts will be
generated:
1. An access key ID that can be used to sign AWS API calls when the user uses the AWS CLI
or AWS SDKs.
2. A secret access key that is also used to sign AWS API calls when the user uses the AWS
CLI or AWS SDKs.
3. A password that can be used to log in to the AWS Management Console.
Choose Show to display the values in each field. The credentials can also be downloaded by
choosing Download .csv. This time is the only time when you have the option to download
these credentials. You will not have an opportunity to retrieve the secret access key after this
screen. Thus, you should either download the credentials, or—at the minimum—copy the
secret access key, and paste it in a safe location.
Important: Never store these credentials in a public place (for example, never embed these
credentials in code that you upload to GitHub or elsewhere). This information can be used to
access your account. If you ever have a concern that your credentials have been
compromised, log in as a user with IAM administrator access permissions and delete the
existing access key. You can then optionally create a new access key.
When you return to the IAM Dashboard, the Create individual IAM users and Use groups to
assign permissions security status items should show that they were addressed.
The remaining security item to address is to apply an IAM password policy.
The IAM password policy is a set of rules that defines the type of password that an IAM user
can set.
Select the rules that the passwords should comply with and then choose Apply password
policy.
All the security status checkmarks should now be green. Your account is now in compliance
with the listed IAM security status checks. Congratulations!
The key takeaways from this section of the module are all related to best practices for
securing an AWS account. Those best practice recommendations include:

• Secure logins with multi-factor authentication (MFA).

• Delete account root user access keys.
• Create individual IAM users and grant permissions according to the principle of least
privilege.
• Use groups to assign permissions to IAM users.
• Configure a strong password policy.
• Delegate using roles instead of sharing credentials.
• Monitor account activity using AWS CloudTrail.
Introducing Lab 1: Introduction to AWS IAM.
In this hands-on lab, you will:

• Explore pre-created IAM users and groups.

• Inspect IAM policies as they are applied to the pre-created groups.
• Follow a real-world scenario and add users to groups that have specific capabilities
enabled.
• Locate and use the IAM sign-in URL.
• Experiment with the effects of IAM policies on access to AWS resources.
The diagram shows the resources that your AWS account will have after you complete the lab
steps. It also describes how the resources will be configured.
It is now time to start the lab.
The instructor will now lead a conversation about the key takeaways from the lab after you
complete it.
Introducing Section 4: Securing accounts
AWS Organizations is an account management service that enables you to consolidate
multiple AWS accounts into an organization that you create and centrally manage. Here, the
focus is on the security features that AWS Organizations provides.

One helpful security feature is that you can group accounts into organizational units (OUs)
and attach different access policies to each OU. For example, if you have accounts that
should only be allowed to access AWS services that meet certain regulatory requirements,
you can put those accounts into one OU. You then can define a policy that blocks OU access
to services that do not meet those regulatory requirements, and then attach the policy to the
OU.

Another security feature is that AWS Organizations integrates with and supports IAM. AWS
Organizations expands that control to the account level by giving you control over what users
and roles in an account or a group of accounts can do. The resulting permissions are the
logical intersection of what is allowed by the AWS Organizations policy settings and what
permissions are explicitly granted by IAM in the account for that user or role. The user can
access only what is allowed by both the AWS Organizations policies and IAM policies.

Finally, AWS Organizations provides service control policies (SCPs) that enable you to specify
the maximum permissions that member accounts in the organization can have. In SCPs, you
can restrict which AWS services, resources, and individual actions the users and roles in each
member account can access. These restrictions even override the administrators of member
accounts. When AWS Organizations blocks access to a service, resource, or API action, a user
or role in that account can't access it, even if an administrator of a member account explicitly
grants such permissions.
Here is a closer look at the Service control policies (SCPs) feature of AWS Organizations.

SCPs offer central control over the maximum available permissions for all accounts in your
organization, enabling you to ensure that your accounts stay in your organization’s access
control guidelines. SCPs are available only in an organization that has all features enabled,
including consolidated billing. SCPs aren't available if your organization has enabled only the
consolidated billing features. For instructions about enabling SCPs, see Enabling and Disabling
a Policy Type on a Root.

SCPs are similar to IAM permissions policies and they use almost the same syntax. However,
an SCP never grants permissions. Instead, SCPs are JSON policies that specify the maximum
permissions for an organization or OU. Attaching an SCP to the organization root or an
organizational unit (OU) defines a safeguard for the actions that accounts in the organization
root or OU can do. However, it is not a substitute for well-managed IAM configurations
within each account. You must still attach IAM policies to users and roles in your
organization's accounts to actually grant permissions to them.
AWS Key Management Service (AWS KMS) is a service that enables you to create and
manage encryption keys, and to control the use of encryption across a wide range of AWS
services and your applications. AWS KMS is a secure and resilient service that uses hardware
security modules (HSMs) that were validated under Federal Information Processing
Standards (FIPS) 140-2 (or are in the process of being validated) to protect your keys. AWS
KMS also integrates with AWS CloudTrail to provide you with logs of all key usage to help
meet your regulatory and compliance needs.

Customer master keys (CMKs) are used to control access to data encryption keys that
encrypt and decrypt your data. You can create new keys when you want, and you can
manage who has access to these keys and who can use them. You can also import keys from
your own key management infrastructure into AWS KMS.

AWS KMS integrates with most AWS services, which means that you can use AWS KMS CMKs
to control the encryption of the data that you store in these services. To learn more, see AWS
Key Management Service features.
Amazon Cognito provides solutions to control access to AWS resources from your application.
You can define roles and map users to different roles so your application can access only the
resources that are authorized for each user.

Amazon Cognito uses common identity management standards, such as Security Assertion
Markup Language (SAML) 2.0. SAML is an open standard for exchanging identity and security
information with applications and service providers. Applications and service providers that
support SAML enable you to sign in by using your corporate directory credentials, such as
your user name and password from Microsoft Active Directory. With SAML, you can use
single sign-on (SSO) to sign in to all of your SAML-enabled applications by using a single set of
credentials.

Amazon Cognito helps you meet multiple security and compliance requirements, including
requirements for highly regulated organizations such as healthcare companies and
merchants. Amazon Cognito is eligible for use with the US Health Insurance Portability and
Accountability Act (HIPAA). It can also be used for workloads that are compliant with the
Payment Card Industry Data Security Standard (PCI DSS); the American Institute of CPAs
(AICPA) Service Organization Control (SOC); the International Organization for
Standardization (ISO) and International Electrotechnical Commission (IEC) standards ISO/IEC
27001, ISO/IEC 27017, and ISO/IEC 27018; and ISO 9001.
AWS Shield is a managed distributed denial of service (DDoS) protection service that
safeguards applications that run on AWS. It provides always-on detection and automatic
inline mitigations that minimize application downtime and latency, so there is no need to
engage AWS Support to benefit from DDoS protection.

AWS Shield helps protects your website from all types of DDoS attacks, including
Infrastructure layer attacks (like User Datagram Protocol—or UDP—floods), state exhaustion
attacks (like TCP SYN floods), and application-layer attacks (like HTTP GET or POST floods). For
examples, see the AWS WAF Developer Guide.

AWS Shield Standard is automatically enabled to all AWS customers at no additional cost.

AWS Shield Advanced is an optional paid service. AWS Shield Advanced provides additional
protections against more sophisticated and larger attacks for your applications that run on
Amazon EC2, Elastic Load Balancing, Amazon CloudFront, AWS Global Accelerator, and
Amazon Route 53. AWS Shield Advanced is available to all customers. However, to contact
the DDoS Response Team, customers need to have either Enterprise Support or Business
Support from AWS Support.
Introducing Section 5: Securing data on AWS
Data encryption is an essential tool to use when your objective is to protect digital data. Data
encryption takes data that is legible and encodes it so that it is unreadable to anyone who
does not have access to the secret key that can be used to decode it. Thus, even if an
attacker gains access to your data, they cannot make sense of it.

Data at rest refers to data that is physically stored on disk or on tape.

You can create encrypted file systems on AWS so that all your data and metadata is
encrypted at rest by using the open standard Advanced Encryption Standard (AES)-256
encryption algorithm. When you use AWS KMS, encryption and decryption are handled
automatically and transparently, so that you do not need to modify your applications. If your
organization is subject to corporate or regulatory policies that require encryption of data and
metadata at rest, AWS recommends enabling encryption on all services that store your data.
You can encrypt data stored in any service that is supported by AWS KMS. See How AWS
Services use AWS KMS for a list of supported services.
Data in transit refers to data that is moving across the network. Encryption of data in transit
is accomplished by using Transport Layer Security (TLS) 1.2 with an open standard AES-256
cipher. TLS was formerly called Secure Sockets Layer (SSL).

AWS Certificate Manager is a service that enables you to provision, manage, and deploy SSL
or TLS certificates for use with AWS services and your internal connected resources. SSL or
TLS certificates are used to secure network communications and establish the identity of
websites over the internet, and also resources on private networks. With AWS Certificate
Manager, you can request a certificate and then deploy it on AWS resources (such as load
balancers or CloudFront distributions). AWS Certificate Manager also handles certificate
renewals.

Web traffic that runs over HTTP is not secure. However, traffic that runs over Secure HTTP
(HTTPS) is encrypted by using TLS or SSL. HTTPS traffic is protected against eavesdropping
and man-in-the-middle attacks because of the bidirectional encryption of the
communication.

AWS services support encryption for data in transit. Two examples of encryption for data in
transit are shown. The first example shows an EC2 instance that has mounted an Amazon EFS
shared file system. All data traffic between the instance and Amazon EFS is encrypted by
using TLS or SSL. For further details about this configuration, see Encryption of EFS Data in
Transit.
The second example shows the use of AWS Storage Gateway, a hybrid cloud storage service
that provides on-premises access to AWS Cloud storage. In this example, the storage gateway
is connected across the internet to Amazon S3, and the connection encrypts the data in
transit.
By default, all Amazon S3 buckets are private and can be accessed only by users who are
explicitly granted access. It is essential to manage and control access to Amazon S3 data.
AWS provides many tools and options for controlling access to your S3 buckets or objects,
including:

• Using Amazon S3 Block Public Access. These settings override any other policies or object
permissions. Enable Block Public Access for all buckets that you don't want to be publicly
accessible. This feature provides a straightforward method for avoiding unintended
exposure of Amazon S3 data.

• Writing IAM policies that specify the users or roles that can access specific buckets and
objects. This method was discussed in detail earlier in this module.

• Writing bucket policies that define access to specific buckets or objects. This option is
typically used when the user or system cannot authenticate by using IAM. Bucket policies
can be configured to grant access across AWS accounts or to grant public or anonymous
access to Amazon S3 data. If bucket policies are used, they should be written carefully and
tested fully. You can specify a deny statement in a bucket policy to restrict access. Access
will be restricted even if the users have permissions that are granted in an identity-based
policy that is attached to the users.
• Setting access control lists (ACLs) on your buckets and objects. ACLs are less commonly
used (ACLs predate IAM). If you do use ACLs, do not set access that is too open or
permissive.

• AWS Trusted Advisor provides a bucket permission check feature that is a useful tool for
discovering if any of the buckets in your account have permissions that grant global
access.
Introducing Section 6: Working to ensure compliance.
AWS engages with external certifying bodies and independent auditors to provide customers
with information about the policies, processes, and controls that are established and
operated by AWS.

A full Listing of AWS Compliance Programs is available. Also, for details about which AWS
services are in scope of AWS assurance programs, see AWS Services in Scope by Compliance
Program.

As an example of a certification for which you can use AWS services to meet your compliance
goals, consider the ISO/IEC 27001:2013 certification. It specifies the requirements for
establishing, implementing, maintaining, and continually improving an Information Security
Management System. The basis of this certification is the development and implementation
of a rigorous security program, which includes the development and implementation of an
Information Security Management System. The Information Security Management System
defines how AWS perpetually manages security in a holistic, comprehensive manner.

AWS also provides security features and legal agreements that are designed to help support
customers with common regulations and laws. One example is the Health Insurance
Portability and Accountability Act (HIPAA) regulation. Another example, the European Union
(EU) General Data Protection Regulation (GDPR) protects European Union data subjects'
fundamental right to privacy and the protection of personal data. It introduces robust
requirements that will raise and harmonize standards for data protection, security, and
compliance. The GDPR Center contains many resources to help customers meet their
compliance requirements with this regulation.
AWS Config is a service that enables you to assess, audit, and evaluate the configurations of
your AWS resources. AWS Config continuously monitors and records your AWS resource
configurations, and it enables you to automate the evaluation of recorded configurations
against desired configurations. With AWS Config, you can review changes in configurations
and relationships between AWS resources, review detailed resource configuration histories,
and determine your overall compliance against the configurations that are specified in your
internal guidelines. This enables you to simplify compliance auditing, security analysis,
change management, and operational troubleshooting.

As you can see in the AWS Config Dashboard screen capture shown here, AWS Config keeps
an inventory listing of all resources that exist in the account, and it then checks for
configuration rule compliance and resource compliance. Resources that are found to be
noncompliant are flagged, which alerts you to the configuration issues that should be
addressed within the account.

AWS Config is a Regional service. To track resources across Regions, enable it in every Region
that you use. AWS Config offers an aggregator feature that can show an aggregated view of
resources across multiple Regions and even multiple accounts.
AWS Artifact provides on-demand downloads of AWS security and compliance documents,
such as AWS ISO certifications, Payment Card Industry (PCI), and Service Organization Control
(SOC) reports. You can submit the security and compliance documents (also known as audit
artifacts) to your auditors or regulators to demonstrate the security and compliance of the
AWS infrastructure and services that you use. You can also use these documents as
guidelines to evaluate your own cloud architecture and assess the effectiveness of your
company's internal controls. AWS Artifact provides documents about AWS only. AWS
customers are responsible for developing or obtaining documents that demonstrate the
security and compliance of their companies.

You can also use AWS Artifact to review, accept, and track the status of AWS agreements
such as the Business Associate Agreement (BAA). A BAA typically is required for companies
that are subject to HIPAA to ensure that protected health information (PHI) is appropriately
safeguarded. With AWS Artifact, you can accept agreements with AWS and designate AWS
accounts that can legally process restricted information. You can accept an agreement on
behalf of multiple accounts. To accept agreements for multiple accounts, use AWS
Organizations to create an organization. To learn more, see Managing agreements in AWS
Artifact.
Some key takeaways from this section of the module include:

• AWS security compliance programs provide information about the policies, processes, and
controls that are established and operated by AWS.

• AWS Config is used to assess, audit, and evaluate the configurations of AWS resources.

• AWS Artifact provides access to security and compliance reports.

Introducing Section 7: Additional security services and resources
AWS Service Catalog enables organizations to create and manage catalogs of IT services that
are approved for use (for example, for your employees to use) on AWS. These IT services can
include everything from virtual machine images, servers, software, and databases to
complete multi-tier application architectures.

From the perspective of AWS Service Catalog, an IT service can be thought of as a product. A
product could be a single compute instance that runs Amazon Linux, it could be a fully
configured multi-tier web application that runs in its own environment, or it could be any
other useful IT service that you build on AWS. This enables your users to quickly deploy the IT
services that they need, and it is designed so that users deploy only approved configurations.
AWS Service Catalog can support your efforts to centrally manage deployed IT services, and it
can help you achieve consistent governance and meet compliance requirements.

For more information, see AWS Service Catalog in the AWS documentation.
Amazon Macie is a security service that uses machine learning to automatically discover,
classify, and protect sensitive data in AWS. Amazon Macie recognizes sensitive data such as
personally identifiable information (PII) or intellectual property. It provides you with
dashboards and alerts that give visibility into how this data is being accessed or moved.
Amazon Macie is a fully managed service that continuously monitors data access activity for
anomalies, and it generates detailed alerts when it detects risk of unauthorized access or
inadvertent data leaks. Amazon Macie is currently available to protect data that is stored in
Amazon S3.

Amazon Inspector is an automated security assessment service that helps improve the
security and compliance of applications that are deployed on AWS. Amazon Inspector
automatically assesses applications for exposure, vulnerabilities, and deviations from best
practices. After performing an assessment, Amazon Inspector produces a detailed list of
security findings that are listed by level of severity. These findings can be reviewed directly or
as part of detailed assessment reports that are available via the Amazon Inspector console or
the API.

Amazon GuardDuty is a threat-detection service that continuously monitors for malicious

activity and unauthorized behavior to protect your AWS accounts and workloads. With the
cloud, the collection and aggregation of account and network activities is simplified, but it can
be time-consuming for security teams to continuously analyze event log data for potential
threats. GuardDuty uses machine learning, anomaly detection, and integrated threat
intelligence to identify and rank potential threats. GuardDuty analyzes tens of billions of
events across multiple AWS data sources, such as AWS CloudTrail, Amazon VPC Flow Logs,
and Domain Name System (DNS) logs.
It’s now time to review the module and wrap up with a knowledge check and discussion of a
practice certification exam question.
In summary, in this module you learned how to:

• Recognize the shared responsibility model

• Identify the responsibility of the customer and AWS
• Recognize IAM users, groups, and roles
• Describe different types of security credentials in IAM
• Identify the steps to securing a new AWS account
• Explore IAM users and groups
• Recognize how to secure AWS data
• Recognize AWS compliance programs
It is now time to complete the knowledge check for this module.
Look at the answer choices and rule them out based on the keywords that were previously
highlighted.

This sample exam question comes from the AWS Certified Cloud Practitioner sample exam
questions document that is linked to from the main AWS Certified Cloud Practitioner exam
information page.
Security is a large topic and this module has only provided an introduction to the subject. The
following resources provide more detail:

• The AWS Cloud Security home page – Provides links to many security resources.
• AWS Security Resources.
• AWS Security Blog.
• Security Bulletins notify the customer about the latest security and privacy events with
AWS services.
• The Vulnerability and Penetration testing page – Describes which types of testing are
permitted without prior approval, which types of testing require approval, and which
types of testing are prohibited.
• AWS Well-Architected Framework – Security pillar.
• AWS documentation – IAM Best Practices.
Thank you for completing this module.