There’s a lot of discussion lately about Infrastructure-as-a-Service (IaaS) and the implications of shared resources. But what does this mean in regards to data security? I hate to break it to you, but it’s time to talk about the birds and the bees – well, at least the bees. Let’s dive right in.
What Does This All Mean?
Think of AWS infrastructure as the soil in the garden. The applications hosted in your EC2 instances become your flowers, and end users are the bees that pollinate those flowers- or access the applications.
In the same way bees don’t go directly to the soil, but rather pull nutrients through the flowers, end users are interacting with data from within the AWS infrastructure through the applications they consume. And, just like the soil is a shared resource between all the flowers, the data stored in S3 buckets are shared between the applications.
Are My S3 Buckets Secure?
It depends who you’re asking, and in what context. Applications are free-form expressions of their developers and can pull data from – or drop data into – any number of S3 buckets. Yes, the AWS infrastructure is secure. But the interactions with the data stored in S3 buckets are complex, leaving room for error. Even if your EC2 instance is only accessible to admins, the applications built on top of it may provide end users and entities with data access and modification capabilities.
Let’s get specific.
The way in:
If an application has forms, text fields, or file drag-and-drops, end users can enter sensitive data into your S3 buckets. Your organization is then responsible for the storage, management, protection, and compliance of that data with any appropriate regulations.
For example, imagine your organization has stray Social Security numbers floating around in S3 buckets unprotected. The financial and reputational repercussions should the data be breached are drastic.
The way out:
It may be obvious that the data intended to be pulled into applications will be visible and accessible to end users. But what about data that’s not intended to be pulled into that application? Developers may spin up applications using existing AWS resources rather than creating new S3 buckets for each application, which can open your organization to possible threats.
Consider this scenario:
Your organization is hosting an EC2 instance to house an application the HR department uses to manage people’s personal information. A developer is also building your organization’s public-facing website on AWS, and needs to create an “About Us” section. Instead of using a new S3 bucket to store employee info for the site, they save time by pulling data from the S3 bucket already in use by the HR application.
Now, a search engine crawling the web to index resources has an entryway into the S3 bucket. Opening a programmatic access point to a bucket containing sensitive HR files raises the potential for cyberattacks.
What Does DLP for S3 Buckets Look Like?
CloudLock for AWS gives organizations visibility and control beyond what developers can see in the AWS console. To protect sensitive data accessible to public cloud applications hosted in AWS, it’s crucial to shine a light on the data your end users are accessing from – or putting into – your S3 buckets.
Email us at firstname.lastname@example.org if you’re interested in auditing your S3 buckets through your AWS applications for fast detection and response to risks such as oversharing, inadvertent exposure, malicious data extraction, and cyberthreats.