Shared Responsibility in Cloud Security
Key Points
- Cloud security follows a shared‑responsibility model, where the provider secures the underlying platform (network, hypervisor, containers, SaaS applications) and the customer secures the workloads, applications, and data they run on it.
- The specific responsibilities shift depending on the service model—PaaS (customer secures app and data, provider secures platform), IaaS (customer controls OS, VMs, and data, provider secures hypervisor and hardware), and SaaS (provider secures everything except the customer’s data).
- Understanding which cloud service model you are adopting is essential for correctly assigning risk and compliance duties and for planning appropriate security controls.
- Data classification (confidential, public, sensitive) should drive the design of a secure data architecture, including mandatory encryption of data at rest across databases, object stores, and block storage.
- Robust key management—ideally using “bring your own keys” and hardware security modules—gives you professional‑level control over encryption keys and ensures you retain ownership and protection of sensitive data in the shared‑responsibility environment.
Sections
- Understanding Cloud Shared Responsibility - The speaker outlines how security responsibilities shift between the customer and IBM Cloud across PaaS, IaaS, and SaaS models.
- Least‑Privilege App & Container Security - Emphasizes restricting data access to only required applications, continuously scanning applications and container images for vulnerabilities, and enforcing identity‑based access controls throughout cloud‑native deployments.
- SecDevOps: Integrating Security Early - The speaker stresses that security must be a forethought, not an after‑thought, by adopting a SecDevOps model that shifts left to embed secure design, encryption, data classification, and controls throughout the entire application lifecycle.
Full Transcript
# Shared Responsibility in Cloud Security **Source:** [https://www.youtube.com/watch?v=jI8IKpjiCSM](https://www.youtube.com/watch?v=jI8IKpjiCSM) **Duration:** 00:10:16 ## Summary - Cloud security follows a shared‑responsibility model, where the provider secures the underlying platform (network, hypervisor, containers, SaaS applications) and the customer secures the workloads, applications, and data they run on it. - The specific responsibilities shift depending on the service model—PaaS (customer secures app and data, provider secures platform), IaaS (customer controls OS, VMs, and data, provider secures hypervisor and hardware), and SaaS (provider secures everything except the customer’s data). - Understanding which cloud service model you are adopting is essential for correctly assigning risk and compliance duties and for planning appropriate security controls. - Data classification (confidential, public, sensitive) should drive the design of a secure data architecture, including mandatory encryption of data at rest across databases, object stores, and block storage. - Robust key management—ideally using “bring your own keys” and hardware security modules—gives you professional‑level control over encryption keys and ensures you retain ownership and protection of sensitive data in the shared‑responsibility environment. ## Sections - [00:00:00](https://www.youtube.com/watch?v=jI8IKpjiCSM&t=0s) **Understanding Cloud Shared Responsibility** - The speaker outlines how security responsibilities shift between the customer and IBM Cloud across PaaS, IaaS, and SaaS models. - [00:04:27](https://www.youtube.com/watch?v=jI8IKpjiCSM&t=267s) **Least‑Privilege App & Container Security** - Emphasizes restricting data access to only required applications, continuously scanning applications and container images for vulnerabilities, and enforcing identity‑based access controls throughout cloud‑native deployments. - [00:08:15](https://www.youtube.com/watch?v=jI8IKpjiCSM&t=495s) **SecDevOps: Integrating Security Early** - The speaker stresses that security must be a forethought, not an after‑thought, by adopting a SecDevOps model that shifts left to embed secure design, encryption, data classification, and controls throughout the entire application lifecycle. ## Full Transcript
Hi, I'm Nataraj Nagaratnam
and I'm from IBM Cloud.
Traditionally when you deploy an application
you have the entire data center, the servers that you run - you're responsible for all of it.
In the cloud model that's a shared responsibility
between you and the cloud provider.
In a shared responsibility model you need to rethink security
on what your responsibility is and what the cloud provider's responsibility is.
Let's take platform-as-a-service (PaaS) as an example.
When you look at PaaS, you're building applications,
migrating data to the cloud
and building applications running them on the cloud.
So, you're responsible for securing the applications, the workload and the data
while the cloud provider is responsible for managing the security of the platform.
So that it's compliant, it's secured from the perspective of network,
the platform on down in terms of managing the containers and the runtime and isolation,
so that you have your own space within the platform.
Whereas if you are adopting and migrating workloads to the cloud
and you're using infrastructure-as-a-service (IaaS),
then the cloud provider manages hypervisor on down if you are using virtual servers
or, if you are using bare metal, then you can completely control everything on up
from the operating system, the virtual servers that you run,
and the data you bring it on.
So it's very important to understand the adoption model whether you're
consuming IaaS or PaaS, or if you're consuming SaaS where the cloud provider
manages all the applications and the security offered and you worry about the
data that you bring in and plan accordingly.
So that's a very important thing because it's part of understanding your
responsibility in ultimately managing the risk and compliance of the workloads
of the data that you bring to cloud.
Now let's talk about architecture.
When you build applications and migrate applications and modernize your apps
- let's start with data.
With all the risk that you deal with, and the kind of data matters. Is it confidential data, is it public data, or
sensitive data that may deal with private information.
Consider all those factors and make a secure design around what your data security architecture should be.
Make sure you have data at rest encryption so that the data is
always encrypted whether you use a database as a service, object store as a
service, or other ways to store data like block storage. Encryption is for
amateurs, and we think about key management for professionals. So having more
control of your keys provide you the ability in the context of shared
responsibility model that you own your data you have complete control of your
data. So as you think about key management make sure you have an
approach to think about if you are bringing confidential data you want to
bring your own keys may be sensitive data you want to keep your own keys. So
that how much control of the keys you have and the hardware security module in
which the key processing the encryption decryption operations happen more
control you have more responsibility that you can take on. So encryption at
data at rest, data in motion, as it comes from services to data stores or
applications so that as you think about data coming out of the way your requests
and API requests coming all the way data in motion. And in the new world we need
to start thinking about when the application is actually processing the
data that is going to be data in its memory. So you can actually start to
protect data using hardware based technologies where you can protect
in-memory data as well. So that when it is in use and in memory by the
applications you can protect it. So take a holistic approach to data protection
at rest, in motion, in use with full control of your keys. It can be bring
your own keys, or even better push the boundary with keep your own keys.
The application that serves the data it's not only about which application
needs to have access make sure the data access is on an only by need basis. Do
not open up your data services to the whole world, be it network access or
everybody to access the data, make sure you exactly know which applications need
to access or which users need to access the data to run your cloud applications.
From an application viewpoint make sure there are no vulnerabilities in your
application so scan your applications, so I have an App SEC application security
approach so that you can do dynamic scanning or static scanning of your
application before you deploy it into the production, and in the cloud-native
environment you're deploying container images so you can scan your images, you
can scan it for vulnerabilities before you deploy and set your policies so that
you only have secured images in production any time and if there is any
vulnerability in the new world you don't need to patch these systems you just
spin up a new container and off you go. So that's the beauty of a cloud-native
approach that you have security built in in every step. So at a container level
and the applications that serves the business logic you can start to protect
it. Then when you look at the users coming in you want to manage access in
terms of who the user is and what from there they are coming from. So identity
you need to make sure who the user is or which service it is based on the
identity of those services or users so that you can manage access control to your
application or data and also from the perspective of network access you want
to make sure only authorized users can get in and if there are intruders out
there you can make sure you can set it up so that they are prevented from
accessing your application and your data in the cloud, be it through Web
Application Firewall-ing, network access control or
denial-of-service distributed, denial-of-service protection and have
intelligence built into these network protection as well. So both identity and
network. In essence, you are protecting your data, you need to manage access to
your apps and the workload on the data that you have deployed on the cloud. You
need to have a continuous security monitoring so that you know at any point
whether you're compliant to your policies, you can watch out for threats
that you need to manage, having an approach and set of tools to manage
security and complaints posture is very important. So gaining insights about your
posture, compliance, and threats. So from your deployment environment you can
garner information, it can be security events, audit logs, flow logs from network
or system that can be fed in so that you can figure out what your posture and
complaints and threats are, and that is not only important for you to gain insight
you need to have actionable intelligence so that you can start to remediate. You
may figure out there's a vulnerability, a container image that you have deployed
is vulnerable so you can re-spin the container so you can remediate and spin
up a new container. There may be a particular access from a network that
seems to be coming in from a suspicious network IP address so we can block that.
So the ability to gain visibility and insights and having that insights and
turn it into actionable intelligence and remediate is very important. So let's
talk about DevOps. DevOps is about development and operations. Traditionally
we think about okay, there's an application team that is doing the
design and architecture, who are building code, and then you throw it over the wall
for the enterprise security team to secure it and manage it. That should be
rethought, fundamentally it's not just about Dev and Ops, but security need
to be a forethought not an afterthought. So it should become
SecDevOps approach to the way you build, manage, and run your applications.
So you need to embed security into the entire lifecycle, what we call shift left,
not only you manage security but shift left through the entire process you need
to have a secure design, so as you plan as you design and say what kind of data
am I going to put what level of classification what kind of applications
am I building, is it container based, is it a workload that I'm migrating, take
that into account and what integrations you need to do so that you can plan it
and architect it. Then as you build it embed security as part of that process.
So you have security aware applications, for example you may want to
encrypt data of your sensitive data, you may want to encrypt the data from your
applications before you even you store into a data store. So secure build and
you manage security as part of SecDevops as you have secure design and
architecture you pass on that and build secure applications and deploy and
manage security in a continuous fashion and then you have a closed loop
so that whatever you find you may need to remediate or rearchitect your
application or implement certain things as threats landscape evolve.
Thanks for watching this video.
If you want to see more videos like it
please leave a comment below, "like", and subscribe.
Thank you.