The case
The cloud was secure. The customer spreadsheet was public.
Isaac stored the store's customer spreadsheet in cloud storage and, so that a partner could download the file faster, opened access to anyone with the link. Weeks later, the customers' data showed up on a forum.
The provider's data center was never broken into. The door that was left open was Isaac's.
This post builds on Cloud Fundamentals and Cloud Service Models.
The problem
A secure cloud doesn't mean secure data
Providers spend far more on security than a small store could: guards, cameras, redundant power, dedicated teams, hardware replaced before it fails. That doesn't stop Isaac from exposing his own data with a wrong configuration.
Most cloud leaks come from configuration and access, not from attacks on the provider's infrastructure.
The solution
Shared responsibility
Every provider works with the same principle, the shared responsibility model. It splits security into two parts:
- Security of the cloud (security of the cloud): the provider's. It includes the building, the hardware, the global network and the virtualization.
- Security in the cloud (security in the cloud): yours. It includes the data you put there, who can access it and how you configure the services.
The line between the two parts is the same as in the stack of Cloud Service Models: the more managed the service, the more layers the provider takes on. Only two layers never leave your hands: the data and the access accounts.
Each provider draws its own picture, with more or fewer lines. The logic is the same: what stays under your control stays under your responsibility.
Access
Who can do what
Since access is yours, the cloud offers a service just for it: IAM (Identity and Access Management). It answers two questions: who you are and what you can do.
- Identity (identity): a user, a group or an application that needs to access something.
- Policy (policy): the rule that says which actions that identity can take, and on which resources.
- Role (role): a set of permissions assigned to an identity, instead of granting permissions one by one.
| AWS | Azure | Google Cloud | Oracle Cloud | |
|---|---|---|---|---|
| Access service | IAM | Microsoft Entra ID and Azure RBAC | IAM | OCI IAM |
Least privilege (least privilege)
Give each person and each application only the permissions they need, and only for as long as necessary.
At the store: the partner who downloads the spreadsheet can only read that file.
Multi-factor authentication (multi-factor authentication, MFA)
On top of the password, a second factor: a code on the phone, a physical key. A leaked password is no longer enough.
At the store: the cloud panel asks for a password and a code.
Root account, kept safe (root account)
The account that created everything has full power. Protect it with MFA and use ordinary accounts day to day.
At the store: only Isaac knows the root account password, and he almost never uses it.
Temporary credentials (temporary credentials)
Access keys that never expire leak and get forgotten. Prefer credentials that are valid for a short time.
At the store: the order system receives a role, instead of a key pasted into the code.
Don't mix them up
Authentication × authorization
Two terms that exams love to swap. Both happen in sequence, and each one answers a different question.
Authentication (authentication)
“Are you who you say you are?”
- Example
- Logging into the panel with a password and a code from the phone.
- Focus
- Proving identity.
Authorization (authorization)
“What are you allowed to do?”
- Example
- Being able to read the files, but not delete them.
- Focus
- Setting the permissions once you're identified.
In practice
What to do in each situation
| Situation | What to do |
|---|---|
| A partner needs to download a file | Grant read permission only on that file, and for a limited time |
| A service needs to call another service | Assign a role to the service, with no fixed key in the code |
| The root account was used day to day | Create ordinary accounts, enable MFA on the root and keep it locked away |
| A person changed roles | Review their permissions, instead of adding the new ones to the old ones |
Key terms
Six terms to remember
Tap a card to see the definition.
Quick test
Three questions, exam style
01
A company uses SaaS software. Who is responsible for the data it stores in it?
02
A developer only needs to read files from a storage. Which permission applies least privilege?
03
Which of these responsibilities belongs to the provider in any service model?
The exam question about security is usually the same: whose responsibility is it? The answer follows the stack. The provider takes on the lower layers, and you never get rid of the data or the access. With IAM, least privilege and MFA properly configured, most leaks like Isaac's stop happening. The next step on the track is Cloud Storage.