Best Practices for Keeping Amazon S3 Buckets Secure
Explore best practices for the five key areas of cloud storage security and gain insight into locking down your data to prevent breaches, identifying and reacting quickly to any breaches that do occur, and preventing similar breaches in the future.
Companies have, and continue to migrate to cloud-hosted infrastructure, applications, microservices, and backend services worldwide.
Cloud storage is big part of the migration equation and offers many advantages such as scalability, high availability, geographic distribution, and potential cost savings. For high volume data applications, like machine learning and data mining, the ability to dial performance and capacity up and down as needed is a crucial advantage.
In this article, we will walk you through the best practices for the five key areas of cloud storage security. In the end, we hope you will have more insight into locking down your data to prevent breaches, identifying and reacting quickly to any breaches that do occur, and preventing similar breaches in the future.
Five Cloud Storage Security Risk Factors
With the increased use of cloud storage, the potential for security incidents also increases. A security breach could be anything from a social engineering attack to a simple mistake that leaves data open and discoverable to anyone who notices. Automated processes that create and manage cloud storage could inadvertently leave security holes as well. So, let’s run through the main areas of concern for cloud storage security:
- Configuration—basic security configurations based on your business needs
- Encryption—encrypt data at rest
- Role-based access—restrict access through least privilege role-based access
- Multiple Layers—utilise multiple layers of security and multi-factor authentication
- Logging and Auditing—be able to detect and follow up when attacked
Ensure your systems are configured at the most basic level to operate at a level of security that meets your business and legal needs.
Amazon S3 buckets have fine-grain permissions, and most users and applications accessing them need only a small subset to accomplish their tasks. For example, AWS-authenticated users could have read access that may allow them to list bucket contents or bucket access control lists (ACLs).
Locking down these permissions can be complicated. So, when securing cloud resources, it’s important to focus on configuration and monitoring that configuration. AWS Config is an excellent place to start, as it compares your configurations to your desired state and sends out notifications if something drifts out of compliance. Amazon Macie is also a great tool offered by AWS, as it extends configuration monitoring by using machine learning to continuously monitor your Amazon S3 storage accounts' patterns of access.
Despite your best efforts, it’s always good practice to assume your data can be exposed. With this in mind, you’ll want to utilise encryption to prevent someone from using your data in the event it is inappropriately access. Ensure that your Amazon S3 buckets are encrypted both on the server and during transport. If you only have one bucket, this might not be complicated, but if buckets are being created dynamically, monitoring and controlling encryption might not be taking place the way you think it is.
On the server side, Amazon S3 buckets support encryption, but it must be turned on. Once enabled, the data is encrypted at rest. Encrypting the bucket will ensure that anyone getting their hands on the data will need a key (password) to decrypt it.
For transport security, HTTPS is the protocol that ensures data is encrypted end to end. The current version of TLS in use is 1.2, with recommendations to disable TLS 1.0 and 1.1 on both servers and clients. Each new version of TLS makes the protocols a bit more secure and removes older, now insecure, encryption schemes. TLS is a moving standard. TLS 1.3 is available, but not widely used as of this writing. AWS requires TLS 1.2 as a minimum.
Define roles that cover your access needs and ensure those roles only have the minimum access possible to ensure the job can get done. This way, in the event that a user’s account is breached, the potential damage is minimised.
AWS security is based on AWS Identity and Access Management (IAM) policies. A principal is an identity that can be authenticated (you are who you say you are, possibly with a password). Users, roles, federated users (from other systems), and applications can all be principals. Once the principal is authenticated and requests a service, resource, entity, or other asset, authorisation kicks in.
Authorization policies check what access the identified principal has to the requested resource. Approval is driven by identity or resource-based policies. Matching each authorisation policy against the authenticated principal determines if the request will be allowed or not. See this comprehensive introduction to AWS IAM for more information.
Least privileged access means developing authorisation policies that give authenticated principals the access they need to do the job at hand but no more. For example, people in a sales role may have access to sales reports, but not accounting statements.
Remember that least privileged access also applies to applications and services that may be fully automated to be created and destroyed on the fly. Security settings must be part of your DevOps process. In all cases, less access is better!
One other data security approach is sharding or splitting, data into separate buckets. For example, a multi-tenant application may want different Amazon S3 buckets for each tenant. Another AWS tool is Amazon Virtual Private Cloud (Amazon VPC), which provides your endpoints secure access to parts of your Amazon S3 buckets.
Multiple layers of security
Suppose one layer of your security fails through misconfiguration, human error, or a sophisticated attack. Subsequent protection layers may be the difference between safety and a breach.
One potent tool is multi-factor authentication (MFA). A password or key is one security layer; it is something you know—the first factor. With MFA, an additional requirement is to have something unique as the second factor. This could be an actual device, such as a Yubico security key, or a dynamically generated code from an authentication application configured for your AWS IAM that implements the Time-based One-time Password (TOTP) standard. These one-time passwords expire quickly, typically between 30 and 60 seconds.
Using both factors to authenticate a user or device dramatically increases security. Even if both security factors are exposed, they will only be valid for a number of seconds.
AWS also supports MFA Delete for Amazon S3 buckets. MFA Delete requires two-factor authentication to change the versioning state of your bucket or permanently delete the bucket. Only the bucket owner can enable MFA Delete.
Logging and Auditing
Security breaches don't always happen all at once. Logging and auditing can prevent a breach before it occurs or to identify holes to prevent future issues.
AWS has built-in tools that can help. Amazon CloudWatch is a monitoring service for DevOps and IT managers. The goal of this service is to give you a unified view of operations covering AWS and on-premises servers. You can detect problems, visualise logs, and automate actions to remediate issues or notify people.
AWS CloudTrail is a way to continuously audit your AWS usage, enabling stronger governance, compliance, and risk assessment. The AWS CloudTrail service provides the event history of any actions taken in the AWS Management Console, SDKs, command line, and other services.
Many third-party tools can extend what is already built into AWS if you need multi-cloud support, further visibility and additional features.
Bonus: Check the Contents
The AWS Well Architected framework helps ensure the applications you build in the cloud perform as expected. Trend Micro Cloud One™– Conformity delivers central visibility and real-time monitoring of your multi-cloud infrastructure - including your AWS S3 infrastructure for cloud security posture management. Align to best practices of the Well Architected frameworks and compliance frameworks and quickly remediate your riskiest misconfigurations. This helps free your teams from being security and compliance experts, while providing the resources to build in the cloud with confidence.
Yet security is a shared responsibility. So, while your application and storage access controls may be rock solid, malicious files landing in your AWS S3 buckets could impact downstream workflows and execute unforeseen risks across your organisation or customer systems. How do you know what you are storing in your bucket is safe to consume?
Trend Micro Cloud One™ – File Storage Security helps ensure your AWS S3 buckets are free from malware by deploying cloud native security with integration for your custom AWS S3 workflows. File Storage Security provides automated protection to reduce overhead and maintains data sovereignty by keeping your files and data within your AWS account with scalable and concurrent scanning to mitigate risks.
There are five fundamental security steps: Configuration, encryption, least privilege access, multi-factor authentication, and logging and auditing.
Augmenting AWS tools with third-party security can provide the best possible protection for your data. You never want to be the next headline, so utilising tools outside of what's provided by AWS provides a sensible extension to your security best practices.
Remember, it's not if a breach occurs, it's when.
Trend Micro Cloud One™ is a security services platform for cloud builders worth considering, as it delivers the broadest and deepest cloud security offering in one solution, enabling you to secure your cloud infrastructure with clarity and simplicity. If interested, you can try it by signing up for a 30-day free trial and requesting a free Automated Public Cloud Risk Assessment.
Learn more on how to secure and encrypt objects in S3 buckets: https://www.trendmicro.com/en_us/devops/21/d/how-to-scan-and-encrypt-objects-in-s3-buckets.html