Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Who's Responsible for Security in AWS?

DZone's Guide to

Who's Responsible for Security in AWS?

Lines were already drawn in the sand years ago, and then updated and re-drawn. There's no point in debating something that is ultimately the provider's decision.

· Cloud Zone ·
Free Resource

See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.

If you haven't read over the AWS shared responsibility model for security yet, I strongly suggest you do so now. While some people still like to debate about whether or not the responsibility of security should fall with the tenant or the infrastructure (because outsourcing infrastructure means outsourcing security responsibility as well), lines were already drawn in the sand years ago, and then updated and re-drawn. The point is, there's no point in debating something that is ultimately the provider's decision.

Here's the ultimate do and don't: DON'T expect your cloud provider to keep you secure, but DO periodically check in to see whether or not your cloud provider has made updates to their regulations.

Amazon Web Services, easily the largest cloud provider, has made their shared responsibility model crystal clear: As a SaaS provider they place control (and thus security) squarely within the customer's realm. It's part of the reason why CloudPassage Halo has recently been added to the AWS Marketplace, and why it is a recommended addition to your Amazon workloads.

The image below demonstrates exactly what AWS provides themselves, and what rests on an organization's (your) shoulders:

As you can see, Amazon protects their own cloud, not your network security, data encryption, access control, or inventory.

At the end of the day "responsibility" is typically defined within the provider's Service Level Agreement (SLA). With any provider, (not just Amazon), look for clauses such as "this SLA does not apply to actions or inactions of third parties," which is effectively a get out of jail free card for the provider if your data is compromised by a non-employee. So while responsibility for applying security may rest under the provider's control, your recourse for security failures may be severely limited.

So what's the take away? While you should always leverage security controls as much as possible, it's up to you to find a security solution that can be tailored to the needs of your workloads.

If we could offer any advice it would be to find something automated, that scales at the speed of your DevOps team, and that's provider-agnostic. Therefore if your organization ever decides to test out various public cloud models, or expand into containerization practices, you aren't exposing any workloads to needless threats.

Interested in CloudPassage Halo? Check out our listing on AWS Marketplace!

Cloud Foundry saves app developers $100K and 10 weeks on average per development cycle. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity. Find out what people love about the industry standard cloud application platform.

Topics:
cloud ,security ,aws ,amazon ,sla ,cloudpassage halo

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}