AWS S3
Best practices and references below are based on published guidance from the cloud service provider and may reference native capabilities the cloud service provider offers. If you are not using the native security capabilities, the same security requirement can be met using other security capabilities your organization utilizes
AWS Security Best Practices
AWS Preventative Security Best Practices
There are a number of security considerations when attempting to secure your S3 buckets. See below for some key considerations. Refer to oak9's security blueprint for S3 for more details.
Identify and audit all your Amazon S3 buckets
Identification of your IT assets is a crucial aspect of governance and security. You need to have visibility of all your Amazon S3 resources to assess their security posture and take action on potential areas of weakness.
Use Tag Editor to identify security-sensitive or audit-sensitive resources, then use those tags when you need to search for these resources.
Use Amazon S3 Inventory to audit and report on the replication and encryption status of your objects for business, compliance, and regulatory needs.
Create resource groups for your Amazon S3 resources.
Implement monitoring using AWS monitoring tools
Monitoring is an important part of maintaining the reliability, security, availability, and performance of Amazon S3 and your AWS solutions. AWS provides several tools and services to help you monitor Amazon S3 and your other AWS services. For example, you can monitor CloudWatch metrics for Amazon S3, particularly
PutRequests, GetRequests, 4xxErrors, and DeleteRequests.Enable Amazon S3 server access logging
Server access logging provides detailed records of the requests that are made to a bucket. Server access logs can assist you in security and access audits, help you learn about your customer base, and understand your Amazon S3 bill.
Also consider implementing on-going detective controls using the s3-bucket-logging-enabled AWS Config managed rule.
Use AWS CloudTrail
AWS CloudTrail provides a record of actions taken by a user, a role, or an AWS service in Amazon S3. You can use information collected by CloudTrail to determine the request that was made to Amazon S3, the IP address from which the request was made, who made the request, when it was made, and additional details. For example, you can identify CloudTrail entries for Put actions that impact data access, in particular
PutBucketAcl, PutObjectAcl, PutBucketPolicy, and PutBucketWebsite. When you set up your AWS account, CloudTrail is enabled by default. You can view recent events in the CloudTrail console. To create an ongoing record of activity and events for your Amazon S3 buckets, you can create a trail in the CloudTrail console.
When you create a trail, you can configure CloudTrail to log data events. Data events are records of resource operations performed on or within a resource. In Amazon S3, data events record object-level API activity for individual buckets. CloudTrail supports a subset of Amazon S3 object-level API operations such as GetObject, DeleteObject, and PutObject.
AWS Config provides a managed rule (cloudtrail-s3-dataevents-enabled) that you can use to confirm that at least one CloudTrail trail is logging data events for your S3 buckets.Consider using Amazon Macie with Amazon S3
Amazon Macie is a data security and data privacy service that uses machine learning and pattern matching to help you discover, monitor, and protect sensitive data in your AWS environment. Macie automates the discovery of sensitive data, such as personally identifiable information (PII) and financial data, to provide you with a better understanding of the data that your organization stores in Amazon S3.
Macie also provides you with an inventory of your S3 buckets, and it automatically evaluates and monitors those buckets for security and access control. If Macie detects sensitive data or potential issues with the security or privacy of your data, it creates detailed findings for you to review and remediate as necessary.
Monitor AWS security advisories
You should regularly check security advisories posted in Trusted Advisor for your AWS account. In particular, note warnings about Amazon S3 buckets with “open access permissions.” You can do this programmatically using describe-trusted-advisor-checks.
Further, actively monitor the primary email address registered to each of your AWS accounts. AWS will contact you, using this email address, about emerging security issues that might affect you.
AWS operational issues with broad impact are posted on the AWS Service Health Dashboard. Operational issues are also posted to individual accounts via the Personal Health Dashboard.
The following best practices for Amazon S3 can help prevent security incidents.
Ensure that your Amazon S3 buckets use the correct policies and are not publicly accessible
Unless you explicitly require anyone on the internet to be able to read or write to your S3 bucket, you should ensure that your S3 bucket is not public. The following are some of the steps you can take:
- Use Amazon S3 block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources that are enforced regardless of how the resources are created.
- Identify Amazon S3 bucket policies that allow a wildcard identity such as Principal “*” (which effectively means “anyone”) or allows a wildcard action “*” (which effectively allows the user to perform any action in the Amazon S3 bucket).
- Similarly, note Amazon S3 bucket access control lists (ACLs) that provide read, write, or full-access to “Everyone” or “Any authenticated AWS user.”
- Use the
ListBucketsAPI to scan all of your Amazon S3 buckets. Then useGetBucketAcl,GetBucketWebsite, andGetBucketPolicyto determine whether the bucket has compliant access controls and configuration.
Use IAM roles for applications and AWS services that require Amazon S3 access
For applications on Amazon EC2 or other AWS services to access Amazon S3 resources, they must include valid AWS credentials in their AWS API requests. You should not store AWS credentials directly in the application or Amazon EC2 instance. These are long-term credentials that are not automatically rotated and could have a significant business impact if they are compromised.
Instead, you should use an IAM role to manage temporary credentials for applications or services that need to access Amazon S3. When you use a role, you don't have to distribute long-term credentials (such as a user name and password or access keys) to an Amazon EC2 instance or AWS service such as AWS Lambda. The role supplies temporary permissions that applications can use when they make calls to other AWS resources.
Consider encryption of data at rest
You have the following options for protecting data at rest in Amazon S3: * Server-side encryption with Amazon S3‐managed keys (SSE-S3). * Server-side encryption with KMS key stored in AWS Key Management Service (SSE-KMS). * Server-side encryption with customer-provided keys (SSE-C).
- Client-Side Encryption – Encrypt data client-side and upload the encrypted data to Amazon S3. In this case, you manage the encryption process, the encryption keys, and related tools. As with server-side encryption, client-side encryption can help reduce risk by encrypting the data with a key that is stored in a different mechanism than the mechanism that stores the data itself.
Enforce encryption of data in transit
You can use HTTPS (TLS) to help prevent potential attackers from eavesdropping on or manipulating network traffic using person-in-the-middle or similar attacks. You should allow only encrypted connections over HTTPS (TLS) using the aws:SecureTransport condition on Amazon S3 bucket policies.
VPC endpoints for Amazon S3 provide multiple ways to control access to your Amazon S3 data:
- You can control the requests, users, or groups that are allowed through a specific VPC endpoint.
- You can control which VPCs or VPC endpoints have access to your S3 buckets by using S3 bucket policies.
- You can help prevent data exfiltration by using a VPC that does not have an internet gateway.
Design Guidance:
Access Control | ||
Public Access Block Configuration | ||
Public Access Block Configuration-Block Public Acls | ||
Public Access Block Configuration-Block Public Policy | ||
Public Access Block Configuration-Ignore Public Acls | ||
Public Access Block Configuration-Restrict Public Buckets |
Public Access Block Configuration | ||
Public Access Block Configuration-Block Public Acls | ||
Public Access Block Configuration-Ignore Public Acls | ||
Public Access Block Configuration-Block Public Policy | ||
Public Access Block Configuration-Restrict Public Buckets |
Bucket |
Design Guidance:
Bucket Encryption-Server Side Encryption Configuration | ||
Server Side Encryption By Default-Ssealgorithm |
Design Guidance:
Server Side Encryption By Default-Kmsmaster Key Id |
Design Guidance:
Cors Configuration-Cors Rules | ||
Cors Rules-Allowed Headers | ||
Cors Rules-Allowed Origins | ||
Cors Rules-Exposed Headers |
Design Guidance:
Cors Rules-Allowed Methods |
Design Guidance:
Inventory Configurations | ||
Queue Configurations-Queue | ||
Topic Configurations-Topic | ||
Tags |
Design Guidance:
Lifecycle Configuration-Rules | ||
Rules-Expiration In Days | ||
Rules-Id | ||
Noncurrent Version Transitions-Storage Class | ||
Rules-Status | ||
Default Retention-Days | ||
Default Retention-Mode | ||
Default Retention-Years | ||
Object Lock Enabled | ||
Rules-Noncurrent Version Expiration In Days | ||
Noncurrent Version Transitions-Transition In Days |
Design Guidance:
Logging Configuration-Destination Bucket Name |
Versioning Configuration-Status |
Redirect All Requests To-Host Name |
Redirect All Requests To-Protocol | ||
Redirect Rule-Protocol |
Name | ||
Bucket | ||
VPC Configuration | ||
VPC Configuration-VPC Id |
Design Guidance:
Policy Document | ||
Policy Document-Statement | ||
Statement-Effect | ||
Statement-Action | ||
Statement-Principal | ||
Statement-Resource | ||
Statement-Condition |
Last modified 6mo ago