AWS is responsible for portions of the cloud, and you as the customer have portions of the cloud that you are responsible for - thus creating shared security responsibility.
Reduces the operational burden (on you) as AWS operates, manages, and controls the components from the host operating system and virtualization layer, down to the physical security of the facilities in which the service operate.
As the customer (you), using AWS means you assume the responsibility and management of the guest operating system (including updates and security patches), other associated applications software, as well as the configuration of the AWS-provided security group firewall.
You are also responsible for your own coded applications and custom applications built on top of the cloud.

When mitigating against DOS/DDOS attacks, use the same practice you would use on your on-premise components:
- Firewalls:
  - Security groups
  - Network access control lists
  - Host-based firewalls
- Web application Firewalls (WAFS)
- Host-based or inline IDS/IPS (Trend Micro)
- Traffic shaping/rate limiting
Along with your traditional approaches for DOS/DDOS attach mitigation, AWS provides capabilities based on its elasticity:
- You can potentially use CloudFront to absorb DOS/DDOS flooding attacks.
- A potential attackers trying to attack content behind a CloudFront distribution is likely to send most requests to CloudFront edge locations, where the AWS infrastructure will absorb the extra requests with minimal to no impact on the back-end customer web servers.
We MUST have permission to do Port Scanning on any of your EC2 instances.
INGRESS Filtering on all incoming traffic onto their network.

S3 has built-in features that allow you to encrypt your data:
- AES-256 bit encryption that encrypt data-at-REST in an S3 bucket.
- AWS will decrypt the data and sent to you when you download it.
EBS encrypted volumes:
- You can select to have all data encrypted that is stored on an EBS for volume.
- If a snapshot is taken, that snapshot is automatically encrypted.
RDS encryption:
- Aurora, MySQL, Oracle, PostgreSQL and MS SQL all support this feature.
- Encrypts the underlying storage space for the instance.
- Automated backups are encrypted (as well as snapshot).
- Read replicas are encrypted.
- RDS provides SSL endpoints to encrypt a connection to a DB instance.

Through IAM policies, AWS gives us the ability to create extremely complex and granular permission policies for our users (all the way down to the resource level).
IAM policies with resource level permission:
- EC2: Create permissions for instances such as reboot, start, stop or terminate based on all the way down to the instance ID.
- EBS volumes: Attach, Delete, Detach.
- EC2 actions that are not one of these above are not governed by resource-level at this time.
This is not EC2 limited can also include services such as RDS, S3, etc.
Additional security measures, such as MFA authentication are also available when acting on certain resource:
- For example, you can require MFA before an API request to delete an object within an S3 bucket.

CloudWatch Security

Request are signed with an HMAC-SHA1 signature, calculated from the request and the user's private key.
CloudWatch control API is only accessible via SSL encrypted endpoints.
CloudWatch access is given via IAM permission policies, essentially giving users permissions that are only needed (only give access to CloudWatch if they need access to CloudWatch).
Use CloudWatch and CloudTrail to monitor changes inside of the AWS environment.
- We can ask CloudWatch to notify us (via SNS) if there has been changes, for example:
  - Changes to IAM security credentials.
  - Assigning access policies to users.
  - Adding/deleting users.
It is important to know how we can use CloudWatch for security in our AWS environment.

HSM (Hardware Security Module) is a dedicated physical machine/appliance isolated in order to store security keys and other types of encryption keys used within an application.
The key is used within the domain of the HSM appliance instead of being exposed outside the appliance.
HSM appliance have special security mechanisms to make them more secure:
- The security key is only used within the HSM.
- An HSM client is used to expose the APIs of the HSM.
- So an application can communicate with HSM to do the encryption (or decryption) of the data that we are requesting.
- The appliance is physically isolated from other resources.
- Tamper resistant (build to notify via advanced logging).
- On AWS, even though they are hosting the appliance, AWS engineers have NO access to the keys (only to manage and update the appliance).
- If the keys are lost or reset (to access the appliance), you will never be able to access the data stored on the appliance.
Some types of keys that might be stored on HSMs:
- Keys used to encrypt file systems.
- Keys used to encrypt databases.
- Keys used to provide DRM.
- Used with S3 encryption.
When to use CloudHSM instead of something like Key Management Service?
- Generally, compliance requirements require it or internal security policy require it.
- Not even AWS engineers have access to the keys on the CloudHSM appliance, only access to "manage" the appliance.

21.2 Security Architecture with AWS

results matching ""