Balancing Shared Responsibilities in the Public Cloud

By Paul Woodward, Blog Contributor
Share Post

Deploying workloads in the cloud is not the same as the on-premises data center. When you request a virtual machine, you can generally rely on your IT department having all of the underlying infrastructure in place. The hosts are updated and patched, the network is locked down from external threats, and your data is backed up. But what happens when you launch an instance in AWS or an Azure VM? Failure to understand the shared responsibility model of public clouds can lead to a disastrous deployment.

Let's start at the top. What exactly is the shared responsibility model?

It varies by cloud providers and by services utilized, but the base definition is as follows: The cloud service provider is responsible for the maintenance and security of the hardware as well as the software that acts as the operating system of the cloud. The customer is liable for the security of workloads and data in the cloud, as well as patching, upgrades and data protection.

Often when discussing public cloud you will hear people say, "AWS guarantees 99.99+ of S3 uptime" or "Office 365 has built-in backups." Sure, that is true. Amazon guarantees Simple Storage Service (S3) uptime, but what happens when a user gets infected with ransomware? Your data is encrypted. AWS has no recourse to recover the data. The onus is on the administrators to create copies of their data following the 3-2-1 rule.  Office 365 only retains deleted email for 30 days. Go ask the PCI compliance officer if 30 days' worth of email retention is sufficient. I bet you already know the answer.

One of the biggest causes of failure in cloud deployments is proper planning. Fully understanding the differences in each cloud provider's shared responsibility model is going to be a key step to your success. Once you have researched the preferred cloud's policies you can now begin to lay out the cloud infrastructure needs for the environment you wish to deploy.

Let's do a quick walkthrough of some baseline thoughts on securing the cloud.

Is the solution just going to utilize cloud-based object storage? Be sure to include a backup product that can retain copies and replicate site-to-site, or in the cloud case, region-to-region. Will the solution be more complex involving multiple applications running on several servers? This scenario will be a bit more complex than securing the standard on-premises data center.

Looking at the shared responsibility model, the customer is in charge of securing cloud-based applications and workloads from the ground up. With AWS, the Virtual Private Cloud (VPC) must be secured with identity and access management, routing, subnets, VPN connections to the physical site and network firewalls.

Site-to-cloud connectivity should be protected with a product like Aruba SD-Branch. Once Elastic Compute 2 (EC2) instances are deployed, the operating systems need to be updated and maintained. Virus protection should be utilized. The instances should have their operating systems and data protected with a product that can offer data replication and backups just the same as you would on premises.

Understanding the shared responsibility model is just a step in the right direction to the security and maintenance of your public cloud-based workloads. In future posts, we will dive deeper into the realm of cloud security.

Related Content

Amazon: Shared Responsibility Model

Microsoft: Shared Responsibility in the Cloud

Data Protection in Amazon S3

Backing Up Email in Exchange Online

Infosec: Top 5 Email Retention Policy Best Practices