Amazon S3 is one of its oldest services, immensely popular as a cost-effective storage option. Launched in 2006, it is an object storage and sharing service with a web interface, deeply embedded with applications across the Internet via API integrations.
However, despite being one of the most secure services AWS S3 has frequently been hitting headlines with a large number of data breaches— from Facebook leak of millions of customer records by third-party apps, exposing classified data of the Pentagon to data breaches at Verizon, FedEx and Go Daddy, S3 data leaks continue to come to light.
Yet it is not that the S3 service has been breached as it comes equipped with robust security features and mechanisms. Every breach can be traced back to exposures pertaining to specific buckets due to misconfigurations or mistakes by users.
That brings into focus the underlying principle of AWS S3 security—it is a shared responsibility between AWS and customers, wherein AWS is responsible for the ‘security of the Cloud’ while customers are responsible for ‘security in the Cloud’. AWS protects the infrastructure on which S3 runs and customers manage access to data by applying appropriate permissions and access levels aligned with the organization’s security and compliance requirements.
So, what are the security capabilities of S3 and how can organizations participate in the shared responsibility model to prevent inadvertent data breaches and achieve continuous data security and compliance goals?
AWS denies access to any resources unless customer/user allows access to a specific resource in S3. That is why it is important to understand where customer responsibility comes into play. Let’s take a closer look at some key security capabilities to understand how best to employ those techniques and strengthen AWS S3 security.
Only the resource owner can allow access and permissions via two types of policies—resource-based and user policy. Built on a foundation of least privilege access, the best practice is to start with no privilege and incrementally add users that may need access.
IAM Policies: IAM enables fine-grained S3 access controls by resource, user or other conditions. This minimizes chances of human errors to misconfigure S3 buckets and thereby trigger inadvertent data leakage.
Bucket Policies: Tied to a bucket, it defines who can access the S3 resource. Bucket policies allow cross-account access to S3 buckets without using IAM roles. Use case for bucket policies include access from different AWS account, internal AWS service, specific IP addresses or ranges; requests when certain conditions are met, such as HTTPS, MFA, etc.
Amazon S3 Access Points: Simplifies managing access at scale for shared datasets
with distinct permissions and network controls as each access point enforces customized policy that works in conjunction with bucket policy. Access points support independent block public access settings. For an application or user to access objects through an access point, both the access point and the underlying bucket must permit request. Use an IAM role to manage temporary credentials for applications or services that need to access Amazon S3.
S3 Block Public Access: S3 Block Public Access setting allows to override any bucket policies and object permissions in a centralized way. But before applying these settings, ensure applications will work correctly without public access. This setting is by default for all new buckets and can be used for buckets, AWS accounts and access points.
Amazon provides encryption capabilities to protect data at rest and in transition. You can set default encryption in S3 buckets to encrypt new objects and employ server-side encryption with either Amazon S3-managed keys (SSE-S3) or customer master keys (CMKs) stored in AWS Key Management Service (AWS KMS). You can also use client-side encryption wherein customer encrypts data before sending it to AWS and decrypts while retrieving the data from AWS. One can enforce client-side encryption by configuring it in bucket policy.
You can protect data in-transit using Secure Socket Layer/Transport Layer Security (SSL/TLS) or client-side encryption.
S3 Object lock prevents deletion of an object or from being overwritten enabling you to enforce object retention by specifying a retention period or by placing a legal hold until you release it. This feature helps comply with regulatory requirements that require setting up an additional layer of protection.
Apart from the above capabilities you can strengthen S3 security using monitoring services such as AWS Config, Trusted Advisor, Cloud Trail and AWS Macie.
Trusted Advisor runs security checks based on specified metrics and raises alerts.
AWS Macie uses machine learning to automatically discover sensitive data and presents the risk value based on the content of the data. AWS Config provides configuration history and changes in logs while Cloud Trail logs all API calls both of which facilitate security and governance.
Securing S3 data is an ongoing process wherein administrators must review settings and revisit permissions as requirements change over time and to ensure adherence in user behaviour. Sometimes sensitive information may be stored in public facing buckets causing inadvertent leakage which a periodic review helps bring to light.
AWS provides new features and services to strengthen S3 security. As a premier AWS partner Umbrella keeps abreast of new developments and upgrades knowledge about AWS services. Reach out to us to know more about a security assessment or if you need help with any AWS security services. You can write to us at email@example.com