Patching and the Shared Responsibility Model

Every cloud provider publishes a version of the shared responsibility model,
and the summary is always the same: they are responsible for the security
of the cloud, and you are responsible for security in it. The
phrase is memorable and slightly too neat, because the dividing line is not in
one place. It moves depending on what you bought.

What the provider always handles

• Physical security of the data centres.
• The hardware, and the hypervisor that isolates tenants from one another.
• The provider’s own network infrastructure.
• The availability and security of the management console and APIs.

You cannot influence any of this, and you do not need to. It is also,
genuinely, better than what most organisations would achieve themselves.

What you always handle

• Your data: what you collect, where you put it, how long you keep it.
• Who has access to your account and what they can do.
• Your application code and its dependencies.
• How your network is configured: firewall rules, what is exposed.
• Encryption choices and key management.

Account access belongs firmly on this side, and it is where most real
incidents begin.

Where the line moves

This is the part the summary glosses over.

Virtual machines. You own everything from the operating
system upwards. Kernel updates, package updates, the configuration of every
service running on it. The provider supplies an image and does not maintain it
after boot. Provider images are built periodically and are routinely out of date
at the moment you launch them, which is why updating is the first thing to do on
a new server.

Managed databases. The provider patches the database engine
and the operating system beneath it. You own the schema, the queries, the data
and who can reach it. You usually choose the maintenance window but not whether
maintenance happens.

Managed Kubernetes. The provider handles the control plane.
You handle the worker nodes, the container images, and everything running in
them. This split surprises people: a managed cluster does not mean managed
nodes, and an unpatched container image is yours regardless of how managed the
cluster is.

Serverless. The provider handles essentially all of the
infrastructure. You own your code, its dependencies and its permissions. The
dependencies are the live issue here, because a vulnerable library in a function
is entirely your responsibility.

Object storage. The provider secures the service. You
configure whether a bucket is public, which is the single most reliably
misconfigured setting in cloud computing.

What this means for patching

Patching is the clearest illustration, because responsibility for it is
entirely determined by what you chose.

If you run virtual machines, you need a patching process. Not an intention, a
process: enable unattended security updates where the distribution supports it,
decide how kernel updates and the reboots they require are handled, and have
something that tells you when a machine has fallen behind.

If you use managed services, patching largely happens without you, which is
one of the strongest arguments for them and is frequently undervalued when
comparing costs. See
the hidden cost of managed
services for the other side of that trade.

Either way, your application dependencies are yours. No provider patches the
libraries in your code, and that is where a substantial share of exploitable
vulnerabilities actually lives.

The misreadings that cause incidents

“It is in the cloud, so it is backed up.” Durability is not
backup, as covered in
backups: what your provider
does not do for you.

“The provider secures it.” They secure their layer. The
public bucket, the open database port and the leaked API key are all on your
side of the line.

“Managed means I can ignore it.” Managed narrows your
responsibility. It does not remove access control, data handling or your own
code from it.

“Compliance certifications cover us.” A provider’s
certification covers the provider’s scope. Your workload is separately in scope
for your own obligations.

Working out your own line

For each component you run, ask three questions: who patches the operating
system, who patches the service itself, and who controls access to it. Write the
answers down. Anything where the answer is “you” and nothing is currently
happening is your list of work, and it is usually short and specific rather than
overwhelming.