Paulo Lapa

How this course is structured

Each heading of this post refers to a learning objective of the AWS Certified Cloud Practitioner exam guide. It might not be the easiest way to read, but I felt it was the most certain to cover everything that is needed.

2.1 Define the AWS shared responsibility model

Recognize the elements of the Shared Responsibility Model

When using AWS cloud offerings, there are two parties: the customer and AWS. Obviously, both parties have different responsibilities regarding operational management, security, and compliance. This agreement is called the shared responsibility model.

Describe the customer’s responsibility on AWS

Firstly, the customer is responsible for “Security in the cloud”. This means that customers have complete control over their content and are responsible for managing it.

Describe how the customer’s responsibilities may shift depending on the service used

The specific responsibilities depend on the service that the customer selects. For example, when using EC2, the customer is responsible for guest OS updates or controlling network access (documentation). However, when using a managed service like RDS, this could mean instead using SSL connections or enabling Amazon RDS encryption to secure data at rest (documentation).

Describe AWS responsibilities

Secondly, AWS is responsible for the “Security of the cloud”: meaning protecting the infrastructure that runs AWS offerings. This means the virtualization layer, the host operating system, and physical access to the data centre. Examples of AWS responsibilities:

1. Nondescript, undisclosed locations
2. 24/7 security staffing
3. Multi-factor authentication for facility entry
4. Continuous monitoring, logging, and auditing
5. Automated change control process
6. Network boundary devices for monitoring and audit access
7. Intrusion detection and analysis.

2.2 Define AWS Cloud security and compliance concepts

Identify where to find AWS compliance information

AWS compliance information can be found on AWS Artifact. It is the repository that contains AWS, independent compliance reports, and some online agreements (like NDAs).

• AWS Artifact Reports provides compliance reports from third-party auditors. It is up-to-date with the latest releases.
• AWS Artifacts Agreements enable signing and managing agreements with AWS. For example, if you need to sign a Business Associate Addendum (BAA) with AWS as part of the HIPAA accreditation, you can do it with AWS Artifacts Agreements.

Another resource is the Customer Compliance Center. It contains case studies and learning paths about compliance in the Cloud.

Recognize that compliance requirements vary among AWS services

Not all services are compliant with all the certifications. This information can be found on the AWS Services in Scope by Compliance Program page. For example, AWS Wickr is not PCI compliant, while AWS Redshift is.

At a high level, describe how customers achieve compliance on AWS

Identify different encryption options on AWS (for example, In transit, At rest)

Describe who enables encryption on AWS for a given service

Recognize there are services that will aid in auditing and reporting

AWS has many services that enable auditing:

• Amazon Config: Assess, audit, and evaluate configurations of your resources.
• AWS CloudTrail: Records uses activities and events in a single service. It can be used to audit account activity, identify security incidents and troubleshoot operational issues

as well as reporting, namely Amazon Cloudwatch:

• Amazon CloudWatch centrally collects logs from your services (lambda, EC2) that can be used to monitor application status, as well as audit user actions in your application.
• Cloudwatch dashboard brings visualization capabilities to your reporting, where you can monitor and analyze your application’s performance and status.

Explain the concept of least privileged access

The least privileged access concept will be very useful when talking about IAM. It means that a user or application should only have the minimum permissions to perform its role. For example, a Lambda that reads from an S3 bucket, should not be able to query a DynamoDb table. A user responsible for managing the account financials should not be able to spin up services.

This reduces the blast radius if that user or application is compromised.

2.3 Identify AWS access management capabilities

Understand the purpose of User and Identity Management (IAM)

When an AWS user or role makes a request, AWS IAM checks if that identity has the needed policy to access the resource and accepts or denies the request.

Major concepts:

• Principal – The entity making the request. It can be a user or a role.
• User – A user is an identity within an AWS account with specific permissions. This user can be a single person or an application.
• User group – is a collection of IAM users. Groups are used to manage permissions for multiple users at a time.
• Roles – a role is an identity NOT associated with a specific user that also has a set of permissions defined. A user can temporarily assume a role. This is weird but the idea is for the user to temporarily gain permissions that typically do not have. Examples
  • Cross-account access. A user from another account can temporarily assume a role in your account to access your account resources.
  • Your EC2 instance could have temporary credentials so the application running in it have access to your account resources.
  • Other examples (e.g. federated user access)

Policies

A policy defines the permissions that a user, user group or role has. When an AWS user or role makes a request, AWS IAM checks if that identity has the needed policy to access the resource and accepts or denies the request.

Types of policy

There are six types of policies, but I’ll just talk about the two most common, identity-based policies and resource-based policies.

Identity-based policies are attached to IAM identities (users, users groups, or roles). They grant permissions to that entity.

Identity-based policies can be further split:

• Managed policies – a policy created and managed by AWS. They include permissions for common use cases, and they cannot be changed by the user
• Custom policies – a policy created by the user that can be applied to roles, user groups and users.
• Inline policies – a policy created for a single identity (user, user group or roles). They are ad-hoc.

Resource-based policies attach policies to resources. For example, you can specify which users have access to an S3 bucket.

Access keys and password policies (rotation, complexity)

Password: Password are used by IAM users to access the AWS Management Console. To further protect them you can (and should) set custom password policies, like minimum length, expiration period, etc.

Access keys: access keys are long-term credentials for AWS users. They are composed of a key ID and a secret access key, and both must be used at the same time. Because they do not expire, it is good practice to rotate them frequently, and they should not be kept in source code.

Multi-Factor Authentication (MFA)

Lastly, users, and in particular root users, should have MFA enabled and required, to prevent unauthorized access in case the account passwords are stolen.

AWS Identity and Access Management (IAM)

• Groups/users
• Roles
• Policies managed policies compared to custom policies

Root account

Tasks that require the use of root accounts

The list of tasks that require a root account is explained in the AWS account management documentation, but as of May 2023 they include:

• Changing account settings – e-mail address, account name, etc. Some information like contact information and AWS regions can be done in a non-root account.
• Restore IAM administrator user permissions
• Close the AWS account
• Sign up for AWS GovCloud

Protection of root accounts

To protect your root account you should:

• Use a strong password
• Enable MFA
• Disable the access keys

2.4 Identify resources for security support

Recognize there are different network security capabilities

Native AWS services (for example, security groups, Network ACLs, AWS WAF) – These will be explained in more detail in the Domain Three post. The AWS Well-Architected Framework has is own post.

3rd party security products from the AWS Marketplace

The AWS Marketplace is a platform where vendors can offer their services and software. Naturally, it has security-focused solutions like Firewalls, VPNs, and auditing offerings.

Recognize there is documentation and where to find it (for example, best practices, whitepapers, official documents)

AWS Knowledge Center, Security Center, security forum, and Security blogs

• AWS Knowledge Center knowledge base with articles and content covering a wide array of topics, namely security.
• AWS Security Center with use cases, services, and resources about Security in AWS
• AWS Security Forum is an in-person event featuring coffee breaks and talks about security in the cloud.

Partner Systems Integrators

The AWS Security Center has a list of partners, from Vendors in the AWS Marketplace to Service providers offering security solutions.

Know that security checks are a component of AWS Trusted Advisor

The AWS Trusted Advisor is a tool that analyzes your AWS account and resources in several areas, namely Cost Optimization, Performance, Fault Tolerance, Service Quotes and Security. As an example of its security features, the AWS Trusted Advisor scans for exposed access keys, overly exposed S3 buckets or risks in security groups, etc

Series Navigation

<< AWS Certified Cloud Practitioner Crash CourseAWS Well-Architected Framework >>