How to Take ‘Shared Responsibility’ of Cloud Security

Table of Contents

When you first embark on cloud, it often begins with a credit card transaction, a shadow IT department or as a proof-of-value with a given project before a more strategic commercial agreement. 

Getting clarity on the details of what the cloud provider is responsible for and what you, as a customer, are responsible for can be easily overlooked but is integral to seeing success.

Breaking down responsibility

Shared responsibility in cloud is a security framework that states who has responsibility for which elements of security: The customer or the cloud provider. 

Cloud providers will often depict the relationship as a high-level diagram (shown below with the AWS shared responsibility model), however, there is a lot more complexity and granularity of understanding needed to really manage the risk and overall cost appropriately

shared responsibility model aws
Reference: AWS Shared Responsibility Model

Because each cloud service is often a piece of open-source software that the cloud vendor has wrapped, the level of complexity that’s contained within that software, to run and manage it, isn’t equal. The amount of customer-owned complexity will therefore depend on the service itself and how much the cloud vendor decided to take responsibility for. 

To put this in perspective, one of the first AWS services, S3 (shared object storage), is much more SaaS (software as a service) in nature than something like Kubernetes, which is operating as a PaaS, (platform as a service) layer and IaaS (infrastructure as a service) layer. This fundamentally means that there is much less responsibility on the customer for S3 than Kubernetes.

Putting shared responsibility into good practice 

So, the cloud vendor doesn’t take responsibility for everything they offer … but what does that mean for YOU?

There are a few important things to understand here:

1. Get the right in-house skills

Because there’s still ownership on you on a ‘per-service’ level, having skills inside of your business that understand how to configure and manage specific services is crucial.  

Although the running aspect is removed, the creation and options you provide when you create them, become incredibly important to know. The majority of the breaches that are in the media are often with misconfigurations with the cloud service, which means that what the customer provided as configuration was at fault and not the cloud vendored service itself. 

How many skills you will need in-house will depend on what services you consume and how SaaS / PaaS those service offerings are. That unfortunately is not only at a per-cloud-service level but also at a per-cloud level, so it needs to be assessed as you go along.

Some skills are more in demand than others, and the economic principle of supply-and-demand also applies here. The more in-demand the skills, the higher the cost will be on that skill. The more experience an individual has the more inflated the price will be, as experience counts for everything when it comes to critical services that your applications sit inside of.

2. Limit the services in an agile yet controlled way

Knowing which services you plan to adopt will be difficult because you don’t always know at the very beginning what you will or won’t end up using at an application level. You also don’t want to stop or slow-down innovation but you also don’t want to be left with hundreds of services being consumed in different ways across your organisation. 

Having a lean process internally on proving out value per cloud service will help keep a tab on what is being used where, and the demand internally across the business. Policies can be enforced in all major cloud vendors across all of your team cloud accounts, projects or subscriptions, to limit what services can be used. 

This is quite an upfront process, so it’ll require some thought on what the best lean process will be for your organisation. Collaboration will be key however, within those teams, to understand what the use cases are and how deep the teams plan to go on that service and hence how much configuration overhead there is going to be internally.

If there’s an opportunity to promote self-service across your teams, then this route is preferred. But it will depend on the internal capability and cloud maturity. 

3. Keep an eye on cost and make it a team problem

Cloud vendors are incentivised to make consumption incredibly easy, you can use as much as you want and need. This can be a double-edged sword as the value of cloud is the principle of it being easy to get, but it is often the part that causes the biggest cost pain. 

Understanding how to monitor ‘how much you have’ v.s. ‘how much you need’ also requires a level of maturity within the team. Providing the right visibility on cost and consumption to a team and making it their responsibility, will help instill good behaviours early on. 

Leaving this to when it matters is a difficult journey,  as habits and behaviours are instilled inside of teams and responsibilities aren’t understood. Trying to change responsibility and habits down the road will undoubtedly not be an easy feat!

4. Secure everything

This essentially boils down to the skills you have in-house. 

As a lot of companies use tools over products, meaning the configuration ownership is higher and therefore making sure teams responsible for those configurations have a high understanding of security will be critical. 

Software engineering best practices will be essential when going down the conventional tool and configuration approach:

  1. Making sure everything is code controlled
  2. Peer reviewing all changes
  3. Having the right amount of tests to make sure things work as expected (especially when planning an upgrade)
  4. Testing and validating policies

Are all key aspects of managing clouds safely and appropriately. 

Reducing your Total Cost of Ownership

One of the reasons organisations get started with cloud is the promising ability to reduce their total cost of ownership. 

As the infrastructure management layer is now the responsibility of the cloud vendor, the amount of in-house skills, custom engineering and skills diversity is significantly reduced. However, as cloud-native is an ever-expanding landscape and there are significant tools and products out there, there is a risk that the TCO can increase beyond what it needs to.

How much TCO you need, will depend on the business type and the complexity of the business services you plan to provide. Complex distributed systems with high amounts of scale, will increase the amount of internal engineering needed to meet the demand and hence the amount of customisation in and around the cloud services. 

If you’re not one of these businesses, then leaning on in the industry as a whole to offset operational costs will help increase the security footprint but also enable you to keep your teams lean and invest more financially in development over operational overheads.

About Appvia

Appvia enables businesses to solve complex cloud challenges with products and services that make Kubernetes secure, cost-effective and scalable.

Our founders have worked with Kubernetes in highly regulated, highly secure environments since 2016, contributing heavily to innovative projects such as Kops and fully utilizing Kubernetes ahead of the curve. We’ve mastered Kubernetes, and experienced its complexities, so our customers don’t have to. 

Share this article
Twitter
LinkedIn
Facebook
profile-160x160-crop-1 1
Jon Shanks
CHIEF EXECUTIVE OFFICER
Jon steers the ship, driving Appvia’s overall vision, direction and mission-critical strategy.

The podcast that takes a lighthearted look at the who, what, when, where, why, how and OMGs of cloud computing

Related insights

Managing Kubernetes Secrets with HashiCorp Vault vs. Azure Key Vault Keeping secrets secure...
Namespaces are a vital feature of Kubernetes. They allow you to separate uniquely named...
DevOps teams have rapidly adopted Kubernetes as the standard way to deploy and...
Once you start working with Kubernetes, it’s natural to think about how you...
Self-service of cloud resources Kubernetes has been brilliant at delivering an ecosystem for...
Pods, deployments, and services are just some of the concepts that you need to understand in...
Last week I published a blog, “How to spot gaps in your Public Cloud...
Breaking down the core areas that you should be aware of when considering...
5 tips to help you manage more with less Not every manager of...
Public cloud has provided huge benefits in getting infrastructure and services to people...
This is the story of how three Appvia Engineers contributed so much to...
Overview The UK Home Office is a large government organisation, whose projects and...