Who Secures What, Once You Are in the Cloud

The provider is responsible for the parts you cannot touch. The buildings, the power, the hardware, the network between their sites, the software that separates one customer's virtual machine from another, and the internals of the managed services they run for you. They do that work well, and it is not where your risk lives.

You are responsible for everything you put on top. Who can sign in and what they can do. How your storage is configured. Your own code and the libraries in it. Your data, its encryption and its retention. The operating systems on machines you created. The rules deciding what can reach what.

Almost every cloud incident we have looked at, or read a credible account of, landed on the customer side of that line. That side is where the configuration lives, and configuration is where mistakes happen.

The line moves depending on what you buy, which is the part people find genuinely confusing. Rent a plain machine and you own the operating system and everything above it. Use a managed database and the provider patches the database engine while you still own the network rules, the accounts and the backups. Use a finished application on subscription and you own little more than identity, data and settings. Same principle, different boundary, and the boundary is worth writing down for each service you use.

This is the most common serious mistake in the whole field, and the mechanism is always mundane. Somebody needed to share a file with a supplier and opening the bucket was quicker than working out permissions. A static website was hosted from storage and the permissive setting spread to a bucket beside it. A developer opened access to diagnose a problem at four in the afternoon and the fix was still in place four months later.

The internet finds these quickly. Address ranges are scanned continuously, common names are guessed, and there are people whose entire activity is looking for storage that answers without credentials. Something opened by mistake on a Monday can be found long before anyone notices on Thursday.

The fix is structural rather than vigilant. Turn on the account level setting that blocks public access, so that making something public requires a deliberate exception at a level an individual engineer cannot reach on their own. Then enumerate the exceptions you actually need, put an owner and a reason on each, and review that short list rather than the whole estate.

Then check the contents of what you do publish. Buckets built for static websites accumulate other things over the years, and the file with the database dump in it does not announce itself.

Long lived access keys are the second recurring cause. They end up committed to a repository, baked into a container image, pasted into a chat message so a colleague could get something working, or written into a configuration file that later gets shared. Once outside, a key works from anywhere in the world until somebody revokes it, and it carries whatever permissions it was given.

The private repository is a false comfort. Repositories become public by accident, get copied to laptops, get cloned by contractors, and get exported when somebody leaves. A secret committed once stays in the history even after the file is deleted, which is why the only real remedy after exposure is rotation rather than removal.

The structural answer is to stop having long lived keys wherever the platform offers an alternative. Machines and services can be given an identity by the platform itself, receiving short lived credentials automatically, with nothing for anybody to copy. That covers most of what applications need, and it removes the class of problem rather than managing it.

For the cases that genuinely need a key, keep it in a secret store rather than a file, scope it to the one thing it must do, rotate it on a schedule you have actually rehearsed, and run automated scanning across your repositories and your build output. Also practise the revocation, because the first time anybody discovers which systems break when a key is withdrawn should not be during an incident.

Permissions in a cloud account start tight and loosen over time. A deployment fails, somebody widens the policy to unblock it, the deployment works, and the wide policy stays. Repeat that across a few teams and a couple of years, and you have an environment where a surprising number of identities can do a surprising number of things.

The accounts to look at first are the ones nobody uses daily. The top level account with no two step sign in, registered to an email alias nobody reads. The contractor's login from a project that finished. The service account created for an integration that was decommissioned. The shared login that three people know the password to. None of these appear in anybody's mental picture of who has access.

Run a review on a schedule, and make it a review of what is granted rather than a list of who exists. Who can create and delete resources. Who can read the customer data. Who can change the security rules. Who can reach the backups. That last one deserves particular attention, because backup access flowing out of a compromised administrator account is how a recoverable incident becomes an unrecoverable one.

Two step sign in everywhere, without exceptions for senior people or for automation accounts that could use a platform identity instead. It remains the single control with the best return, and the objections to it have not improved in years.

A managed database is a good example of how the split works in practice. The provider patches the engine, replaces failed hardware, and keeps the service running. You still choose whether it is reachable from the internet, who holds the administrator password, how long backups are kept, whether the data is encrypted with a key you control, and whether the audit log is switched on.

Every one of those is a decision that can go wrong, and the defaults are chosen to make the service easy to start rather than to make it safe in your particular environment. Read the security section of the documentation for each managed service you adopt, once, and write down the settings you decided on.

The same applies to subscription software. The platform being secure says nothing about whether your staff have shared a folder with everybody in the company, whether external sharing is allowed, whether old accounts still have access, or whether anybody is looking at the sign in logs.

A useful habit when adopting anything new: ask what this service does for us, what it explicitly does not do, and which of the settings would matter if somebody got hold of a valid password. Ten minutes at the start, and it is the sort of question that stops a problem existing rather than catching it later.

After an incident, the first question is what happened and when. If the audit trail was switched on last week, there is no answer for anything before that, and the investigation becomes guesswork dressed up as analysis.

Turn on the platform audit log across every account on the first day, keep it long enough to investigate something you find out about late, and send a copy somewhere that a compromised administrator in the main account cannot delete. A separate account with restricted access is the usual arrangement and it is not expensive.

Then alert on the small number of events that always deserve a look. Changes to security rules. New administrator grants. The top level account being used at all. Logging being switched off, which is the first thing anybody does when they want to work unobserved. Alerting on everything produces noise nobody reads, and that is the same as not alerting at all.

Retention is a decision worth making deliberately rather than accepting the default. Many intrusions are discovered long after they began, often by somebody outside telling you, and by then the useful record is either there or it is not.

It is worth being fair about the other side of the line, because dismissing it leads to spending money on the wrong things. Physical security, hardware failure, the isolation between customers, patching the platform itself, and the network underneath are all genuinely handled, at a standard almost no individual business could match in its own building.

That is a real transfer of risk. The disk failing, the air conditioning dying, the break in, the unpatched hypervisor: those stop being your problem in any practical sense.

What does not transfer is the consequence. A provider outage is still your outage as far as your customers are concerned, and the compensation in the agreement will be a fraction of what the day cost you. That is an argument for designing your important systems to survive a failure on their side, not an argument against using them.

Read the specific commitments rather than the general reassurance. What is promised, measured how, with what exclusions, and what actually happens when they miss. It is the same reading you would give any supplier contract, and the fact that the supplier is very large does not change the exercise.

Keep it short enough that it happens. Any storage open to the internet, and whether each one is on the approved exception list. Long lived keys, how old they are, and what each one is for. Accounts with administrator rights, and whether every one of them still needs it. Two step sign in on the top level account and on every human login. Network rules that allow access from anywhere, especially on management ports. Accounts and identities that have not been used in months.

Run it per account or subscription and give each one a name to answer for it. An estate wide review with no owner produces a document. A per account review produces changes, because somebody has to say either that it is fixed or that it is accepted.

Where you accept a risk, write down what it is, who accepted it and when it will be looked at again. Exceptions with expiry dates get revisited. Exceptions without them become the architecture.

None of this needs a product. The platforms include the tooling to answer every one of those questions. Estates drift because nobody was asked to look.