Cloud providers secure the building and the wiring. You secure who gets in, what they can touch, and whether your data is locked. Most cloud breaches are not clever hacks. They are a setting someone left open. Learn the shared responsibility split, turn on MFA, give people the least access they need, and encrypt your data. That handles the large majority of real risk.
Freshers and brand-new IT employees who keep hearing that the cloud is either perfectly safe or terrifyingly dangerous. Both stories are wrong, and this part shows you the part of security that is actually yours to own.
A junior engineer spins up a storage bucket to share a few report files with a teammate. To make it easy, they flip a setting that says "allow public access" and move on. Three weeks later a security researcher emails the company: those reports, plus a folder of customer data nobody meant to upload there, have been sitting open to the whole internet. Nobody broke in. The door was left unlocked. This is what cloud security actually looks like on the ground, and it is the part that belongs to you, not to the provider.
Here is the blunt claim this part is built on: the cloud is not automatically safer than a server in your own office, and it is not automatically more dangerous. It is exactly as safe as the settings you choose. The skill worth having is knowing which settings are yours.
The one idea that explains everything: shared responsibility
Think of renting an apartment. The landlord owns the building. They handle the foundation, the locks on the front entrance, the fire alarms in the hallway, the electrical wiring inside the walls. What happens inside your unit is yours. If you leave your own door unlocked, hand your key to a stranger, or leave the stove on, that is on you, not the landlord. Cloud security works the same way. The provider secures the building. You secure your unit.
Every major provider draws this as two halves. The phrase to memorise is security of the cloud versus security in the cloud. The provider owns security of the cloud: the physical data centres, the hardware, the network cables, the virtualization layer that keeps one customer separate from another. You own security in the cloud: your data, who can sign in, what permissions they hold, your firewall rules, and whether your data is encrypted. AWS, Microsoft Azure, and Google Cloud all describe it this way, and they all expect you to hold up your half.
The line moves depending on the service
The split is not fixed. It slides based on how much of the stack you rent. This is the single most useful thing to understand deeply, so let us slow down here. When you rent a raw virtual machine (the IaaS model from Part 4), you get an empty operating system and almost everything above the hardware is yours: OS patches, the software you install, the firewall, user accounts, all of it. When you use a managed database or an object storage service (closer to PaaS), the provider patches the engine and the host for you, and your job shrinks to access control and data. When you use finished software in a browser (SaaS), most of the stack is the provider, and you are mostly responsible for your accounts and your data.
Explain the shared responsibility model and give one example of something on each side.
How to answer well: name the split first (the provider secures the cloud itself, the customer secures what they put in it), then prove you understand the moving line. Say something like: on a raw virtual machine, patching the operating system is mine, but the physical server it runs on is the provider's. Always finish with the part interviewers are really checking for: data and access control stay on the customer side no matter which service you pick. That last sentence is what separates someone who memorised a diagram from someone who gets it.
Identity is the new perimeter
In an old office network, security was a wall. You were either inside the building or outside it. In the cloud there is no building. Your resources are reachable from anywhere, so the thing that actually protects them is identity: who is signing in and what they are allowed to do. This is handled by IAM, Identity and Access Management, which we covered in Part 10. Here we care about the security habits that sit on top of it.
Least privilege, even when it is annoying
Least privilege means giving each person or service the smallest set of permissions that lets them do their job, and nothing more. A reporting tool that only reads data should not be able to delete it. A new joiner who manages one storage bucket should not hold the keys to the entire account. The reason is simple: if those credentials leak, the damage is capped at what they could do, which you kept small on purpose.
Here is where I disagree with how a lot of teams actually behave. Under deadline pressure, the quick fix is to attach an administrator-level policy or a wildcard permission (the infamous action of allowing everything on everything) just to make the error go away. It works, the ticket closes, and the over-broad permission stays there for years because nobody circles back. My honest advice: treat a wildcard permission as a thing you have to justify out loud to another person, not a default you reach for. The five extra minutes to scope it properly is the cheapest security work you will ever do.
In your first months you will mostly be handed access, not designing it. But you will be asked to request permissions, and how you ask tells a senior engineer a lot. Asking for "read access to this one bucket" instead of "admin, to be safe" marks you as someone who already thinks the right way. It is a small signal that gets noticed early.
Turn on MFA and stop using the root account
Multi-factor authentication (MFA) means a password alone is not enough to sign in. You also need a second factor, usually a six-digit code from an app on your phone or a hardware key. A stolen password becomes far less useful because the attacker still lacks the second factor. If you do one security thing on any cloud account, make it this.
The account you create when you first sign up is the root or owner account, and it can do anything, including closing the account and changing billing. Every provider tells you the same thing, and they are right: protect it with MFA, then lock it away and stop using it for daily work. Create a normal user with only the permissions you need and use that instead. The root account is a fire-break-glass key, not your everyday login.
The misconfiguration that keeps making headlines
If you read about a cloud data leak, it is almost never a broken provider. It is a storage bucket that was made public by mistake. This has happened so many times that AWS changed the defaults: since 2023, new S3 buckets have Block Public Access turned on and access control lists disabled by default, so a fresh bucket is private out of the box. Azure and Google Cloud have similar guardrails for their storage. The platforms learned from years of leaks and made the safe choice the default.
So why does it still happen? Because people turn the guardrails off. Someone needs to share a file, hits an access denied wall, and the fastest path is to disable Block Public Access or attach a policy that opens the bucket to everyone. The leak is not the platform failing. It is a person trading a safe default for a quick result and forgetting to undo it.
You upload a file, try to open its link, and get a blunt
AccessDenied with a 403 error. The wrong instinct is to make the whole bucket public to make the error vanish. The right move is to ask why you are trying to reach private data over a public link at all. If a teammate needs the file, share it through a time-limited signed URL or give their account read permission. The error is the system protecting you. Do not silence it by opening the door for the entire internet.Encryption, in two plain flavours
Encryption scrambles data so that without the key it is meaningless. There are two moments that matter, and the names tell you exactly when each applies. Encryption at rest protects data while it is sitting on a disk, so a stolen drive is just noise. Encryption in transit protects data while it moves across the network, so someone listening on the wire sees gibberish. The good news for a fresher: on the big providers, encryption at rest is now on by default for most storage and database services, and in-transit encryption is what the little padlock in your browser already gives you through HTTPS.
Here is a quick reference for the everyday controls and which side of the responsibility line they fall on.
| Control | What it does | Whose job |
|---|---|---|
| MFA on accounts | Blocks logins with a stolen password alone | You |
| Least-privilege permissions | Caps the blast radius if a key leaks | You |
| Block Public Access | Keeps storage private by default | You (default helps) |
| Encryption at rest | Useless data if a disk is stolen | Mostly provider, you confirm |
| Physical data centre security | Guards, cameras, hardware | Provider |
| Patching the hypervisor | Fixes the virtualization layer | Provider |
A worked example: what a small mistake actually costs
Imagine a developer accidentally commits an access key to a public code repository. Bots scan public repos constantly and find exposed keys within minutes. If that key had administrator permissions, the attacker can spin up dozens of expensive machines to mine cryptocurrency and run up a bill in the thousands before anyone notices. Now run the same scenario with least privilege: the key could only read one storage bucket. The attacker gets some files, which is bad, but they cannot launch a single server. Same mistake, wildly different outcome. The difference was a permissions choice made weeks earlier. That is why the boring habit of scoping access matters more than any fancy tool.
On a free-tier account with any major provider, do these three things, which cost nothing:
1. Turn on MFA for your own login using a phone authenticator app.
2. Create a second user that has read-only access to just one storage bucket, and sign in as that user.
3. Try to delete a file as that read-only user.
How to check it worked: the delete should fail with an access denied message. That failure is the whole point. You just watched least privilege stop an action it was not allowed to take, which is exactly what it would do if those credentials were ever stolen.
Logging: you cannot protect what you cannot see
One more habit worth building early. Every provider keeps an audit log of who did what: AWS calls it CloudTrail, Azure has Activity Log and Microsoft Entra logs, Google Cloud has Cloud Audit Logs. When something goes wrong, this log is how you answer the only questions that matter: who touched it, when, and from where. You do not need to be an expert. You just need to know the log exists and turn it on, because a log you started collecting last week is worth far more than one you wish you had started after an incident.
FAQ
Is the cloud more secure than keeping servers in my own office?
It can be, because providers run security at a scale most companies cannot match. But that only covers their half. If you misconfigure access or leave data public, the cloud is no safer than a server under your desk. Security comes from the settings, not the location.
Do I need to encrypt my data myself, or is it automatic?
On the major providers, encryption at rest is on by default for most storage and database services, and traffic over HTTPS is encrypted in transit. You should still confirm it is enabled rather than assume, and for very sensitive data you may manage your own keys.
What is the single most important thing a beginner should do?
Turn on MFA and stop using the root or owner account for daily work. Those two habits block the most common ways accounts get taken over.
What does least privilege actually mean in practice?
Give each user or service only the permissions it needs to do its job. If a tool only reads data, do not let it delete. If a key leaks, least privilege is what keeps a small mistake from becoming a disaster.
Whose fault is it when a cloud bucket leaks data?
Almost always the customer's, not the provider's. New buckets are private by default now. A leak usually means someone deliberately turned off a safety setting to share something quickly and never turned it back on.
The takeaway
Cloud security is not a dark art. It is a short list of habits done consistently: know which half of the responsibility split is yours, turn on MFA, give the least access that works, keep data encrypted, and turn on the audit log. Do those five things and you are already ahead of most of the leaks you will read about. The providers built the safe defaults. Your job is to not switch them off.
References
- AWS Shared Responsibility Model
- AWS S3 Block Public Access (default settings)
- Microsoft Azure: Shared responsibility in the cloud
About The Author
DrJha