1. Restricting access to your S3 resources
You can use S3 bucket and IAM policies to write custom, JSON-based permissions that determine which users can access which specific buckets and objects. For examples, see User Policy Examples and Bucket Policy Examples. You can also use the AWS Policy Generator and IAM Policy Simulator for help creating and testing your user and bucket policies.
You can use the S3 console to set ACLs on your buckets and objects. Consider the following best practices when using ACLs to secure your resources:
- Be stringent about who you allow read and write access to your buckets. You should carefully consider your use case before granting Read access to the Everyone group, because this allows anyone to access the bucket or object.
- You should never allow Write access to the Everyone group, because this allows anyone to add objects to your bucket (which you will be billed for), and it allows anyone to delete objects in the bucket that you might want to keep.
- The same is true for the Any authenticated AWS user group, which includes anyone with an active AWS account, not just IAM users in your account. To control access for IAM users on your account, use an IAM policy instead. For more information on how IAM policies are evaluated by Amazon S3, see How Amazon S3 Authorizes a Request.
- If your use case requires more granular control, you can create your own ACL with a custom set of permissions.
In addition to policies or ACLs, you can enable MFA Delete, which requires a user to authenticate using a multi-factor authentication device (MFA) before they're able to delete a bucket or object. For more information, see How do I configure an Amazon S3 bucket so I can undelete files that have been deleted?
2. Monitoring your S3 resources
It's a best practice to enable a logging solution for your S3 resources to help you track what actions were performed against your S3 buckets. Here are some options to consider:
- CloudTrail logs. For more information on how to configure CloudTrail, see Getting Started with CloudTrail.
Note: By default, CloudTrail only tracks bucket-level actions. To track object-level actions (such as GetObject), enable S3 Data Events for each logged bucket.
- S3 server access logging. For more information, see Server Access Logging and S3 Server Access Log Format.
In addition to providing raw logs, CloudTrail can be used in conjunction with services like CloudWatch and AWS Lambda to trigger specific processes when certain S3 actions are performed (for example, trigger an SNS notification to email your security administrator any time an object is deleted). For more information, see Log S3 Data Event.
Note: This Trusted Advisor check does not monitor for bucket policies that override bucket ACLs.
3. Using encryption to protect your data
If your use case requires encryption during transmission, S3 supports the HTTPS protocol, which encrypts data in transit to and from S3. All AWS tools and SDKs use HTTPS by default.
Note: If you use third-party tools to interact with S3, contact the developers to confirm if their tools also support the HTTPS protocol.
If your use case requires encryption for data at rest, S3 offers server-side encryption (SSE). You can specify the S3 SSE parameters when you write objects to the bucket; S3 offers SSE-S3, SSE-KMS, or SSE-C.
If your use case requires client-side encryption, see Protecting Data Using Client-Side Encryption.
If you continue to experience difficulties, please open a case with the DLT Opscenter using the following contact information: