Security
- User Based
IAM policydetermine, whichAPIcalls are allowed from console- Resource Based
- Allow Cross Account
- Object Access Control List (Object ACL) is finer grain
- Bucket Access Control List (Bucket ACL) is less common
- A
IAMprincipal allow accessS3if - Any
IAMpermission allow - Any
Resource Policyallow - No explicit deny in anywhere
- Supports
VPC Endpoint, do it is possible to interact withS3without public internet API Callscan be logged byCloud TrailS3 Access Logscan be stored in anotherS3 Bucket- User can use
MFAto prevent unintended deletion Presigned URLcan be used for premium contentPresigned URLis generated by user credential token- It is valid for limited time
Bucket Policy
- JSON Based Policy
- Keys in the
Policy Effectmeans is the actionAllowedorDeniedPrincipalmeans who is trying to access/taking-actions- It can be
- User
- Resource
Actionmeans what type of action will be happen- Can be
- READ Object
- GET Object (single/multiple)
- UPDATE Object
- DELETE Object
Resourcemeans on whichBucketorObjectis targeted- Hands On
Object can not be uploaded if it is not SSE-S3 Effectshould beDeny- The
Principalbe*, since it is applicable for anyone ServiceisAWS S3ActionbeS3 Put ObjectARNshould bes3://bucket_name/*- We have to deny if it does not match two condition
- The header
x-aws-server-side-encryptioncan not be null - The header
x-aws-server-side-encryptionis not equalAES-256
- The header
Bucket Settings for Block Public Access
- Use to prevent company data leaks
- We can block public access to a bucket through (No need to remember the names)
- new ACL
- any ACL
- new Public Bucket
- Access Point Policies
Allow cross account permission
To allow a bucket in production account from the development account,
- On production account, create IAM role nd specify the development account as trusted entity
- Create a policy that will allow the created role to access S3 bucket
- In development account, using STS assume role create and attach the policy to the IAM user