Domain 2: Security and Compliance

Define the AWS shared responsibility model

AWS Shared Responsibility Model Explained

This model denotes how security and compliance responsibilities are shared between AWS and the customer.

Think of the Shared Responsibility Model as a partnership. AWS secures the foundation, and you secure what you put on it.

Customer's Responsibility on AWS

Depending on the AWS service used, the responsibility might vary:

RDS: AWS manages underlying infrastructure, database patching.
Lambda: AWS manages the infrastructure, OS, and application stack.
EC2: You manage guest OS, updates, and the application.

AWS Responsibilities

AWS is responsible for the security of the cloud, including infrastructure, hardware, software, and facilities.

Who is responsible for patching the database in Amazon RDS?

a) Customer b) AWS

b) AWS

Define AWS Cloud security and compliance concepts

AWS Compliance Information

AWS offers compliance controls like HIPPA and SOCs. Not all AWS services might comply with every standard.

Compliance requirements might vary per AWS service and region.

Achieving Compliance on AWS

AWS offers different encryption options:

In Transit: Data encrypted while moving.

At Rest: Data encrypted while stored.

Auditing and Reporting Services:

AWS provides tools like Amazon CloudWatch, AWS Config, and AWS CloudTrail for monitoring, auditing, and reporting.

Least Privileged Access Concept:

Always grant only the permissions required to perform a task.

AWS Identity and Access Management (IAM)

AWS Identity and Access Management (IAM) allows you to securely control access to AWS resources.

It allows you to create and manage AWS users and groups and assign permissions to allow or deny their access to AWS resources.

Key IAM Entities:

User: Individual people, system users, or services that will be interacting with AWS.
Group: A collection of IAM users. You can specify permissions for multiple users, which can make it easier to manage the permissions for those users.
Role: Not tied to a specific user or group. Instead, roles are assumed by trusted entities, such as IAM users, applications, or AWS services like EC2.
Policies: Documents defining permissions and can be attached to users, groups, or roles.

Best Practices

Root vs. IAM User:

Root User: When you open an AWS account, you begin with a single sign-in identity that has complete access to all AWS services and resources. This is termed as the "root" user.

Don't use your AWS root user credentials to access AWS, and no one else should either. Instead, create individual IAM users.

Access Keys:

Access keys consist of an access key ID and secret access key, used to sign programmatic requests to AWS.

Password Policies:

Set requirements for IAM user passwords.

Multi-Factor Authentication (MFA):

Uses multiple factors to authenticate a user, adding an extra layer of security.

Deep Dive into IAM Roles, Users, and Groups

Roles:

Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.

Example: An EC2 instance might need access to an S3 bucket. Instead of hardcoding AWS credentials, you'd assign the EC2 instance an IAM role with the necessary permissions.

Users:

Intended for humans or services. They have permanent long-term credentials.

Example: A developer named John in your team might have a user account with permissions to access only specific S3 buckets and EC2 instances.

Groups:

A way to assign policies to multiple users simultaneously.

Example: If you have a group of developers, rather than assign each of them permissions, you'd place them in an Developers group and assign the necessary permissions to that group.