# 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.
{% hint style="info" %}
Think of the Shared Responsibility Model as a partnership. AWS secures the foundation, and you secure what you put on it.
{% endhint %}
### **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
{% hint style="success" %}
b) AWS
{% endhint %}
***
## **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.
{% hint style="info" %}
Compliance requirements might vary per AWS service and region.
{% endhint %}
### **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.
{% hint style="danger" %}
Don't use your AWS root user credentials to access AWS, and no one else should either. Instead, create individual IAM users.
{% endhint %}
#### **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.
### **IAM Permission Policies**
#### **Managed Policies:**
AWS managed policies are designed to provide permissions for many common use cases. AWS controls these.
* **Example:** `AmazonS3ReadOnlyAccess` – Provides read-only access to all buckets via the AWS Management Console.
#### **Custom Policies:**
You define custom permissions according to your needs.
* **Example:** A policy that allows a user to only read a specific S3 bucket and not any other bucket.
{% hint style="info" %}
Never use the root account for daily tasks.
{% endhint %}
***
## **Identify resources for security support**
### **Network Security Capabilities**
AWS offers tools like security groups, Network ACLs, and AWS WAF. Also, 3rd party security products are available on the AWS Marketplace.
### **Finding Documentation**
#### Access resources such as:
* AWS Knowledge Center
* Security Center
* Security forum
* Security blogs
#### Where can you find official AWS security best practices?
> a) Google\
> b) AWS Knowledge Center\
> c) Random blogs\
> d) Reddit
{% hint style="success" %}
b) AWS Knowledge Center
{% endhint %}
### **AWS Trusted Advisor**
This tool offers insights to follow best practices, including security checks.
