6. S3 Security and Encryption

By default all the newly created buckets are PRIVATE. We can setup access control to our buckets using:
i) Bucket Policies — Work at bucket level
ii) Access Control Lists — Work at individual objects level
S3 buckets can be configured to create access logs which log all requests made to S3 bucket. This can be sent to another bucket or even another bucket in another account.

If we type https in browser then that traffic is going to be encrypted. So basically between your computer and server the traffic is encrypted and no one will be able to break it to understand what we are looking for.

We have two types of Encryptions
i) Encryption in Transit is achieved by SSL/TLS
ii) Encryption at rest (server side) is achieved by:
a) S3 Managed Keys – SSE-S3
b) AWS Key Management Service, Managed Keys – SSE-KMS
c) Server side encryption with customer provided keys – SSE – C

In console we have two types encryption:
i) AES-256
ii) AWS-KMS
a) aws/s3
b) Custom KMS ARN

The different components involved in S3 Security are:
i) User based: IAM policies – We are going to attach a policy to Users to allow them to get access to S3 buckets.
ii) Resource based:
Bucket Policies – bucket wide rules from the S3 console – allows cross account. A rule attached directly to S3 bucket to allow or deny request coming from other accounts or public requests.
Object Access Control List – finer grain. We can define at object level who can do what.
Bucket Access Control List – less common
Note: An IAM principal can access an S3 object if the user IAM permissions allow it OR the resource policy allows it and there is no explicit deny.
iii) Encryption: Encrypt objects in S3 using encryption keys. Encrypt the object and ensure no one but you can receive and decrypt these objects.