Cloud Security Basics: Identities, Permissions and Misconfigurations

The cloud did not make security disappear; it moved it. Servers that used to sit in a locked room now live in a provider's data centers, and the new front door is a web console protected by an account and a few permission settings. In this lesson you will learn who is responsible for what, how cloud identities work, and the configuration mistakes that cause most real-world cloud incidents.

The shared responsibility model

Imagine renting an apartment. The landlord is responsible for the building structure, the main door and the elevator. You are responsible for locking your own door, who you give keys to, and what you leave on the balcony. Cloud works the same way and is called the shared responsibility model:

• The provider secures the physical data centers, the hardware and the core services.
• The customer secures what they configure: accounts, permissions, data, network rules, operating systems they manage and applications they deploy.

The more the provider manages for you (for example a fully managed service rather than a virtual machine), the smaller your part, but it never drops to zero. You are always responsible for your data and your access settings. Most breaches in the cloud are customer-side configuration mistakes, not breaks of the provider's infrastructure.

Identity is the new perimeter

In a traditional network, the firewall was the wall. In the cloud, services are reachable over the internet by design, so who you are matters more than where you are. That makes Identity and Access Management (IAM) the heart of cloud security. The core concepts, which exist under different names at every provider, are:

• Identities: human users, groups, and also non-human identities such as applications and automated jobs (service identities, roles).
• Credentials: passwords, access keys, tokens and certificates that prove an identity.
• Permissions or policies: documents that say which actions on which resources are allowed or denied.
• Roles: sets of permissions that an identity can temporarily assume, which is safer than long-term keys.
• Resources: the things being protected, such as storage, databases and virtual machines.

Least privilege, again

You met this principle in chapter 1 and in the earlier courses. In the cloud it is both more important and easier to violate, because policies are text files and it is tempting to write "allow everything" to get something working. A generic example of a too-broad policy, written in a neutral pseudo-format:

{
  "effect": "allow",
  "actions": ["*"],
  "resources": ["*"]
}

This says "this identity can do anything to anything". If it is attached to an application and the application is compromised, the whole account is compromised. A better policy lists specific actions on specific resources:

{
  "effect": "allow",
  "actions": ["storage:read"],
  "resources": ["storage/reports-bucket/*"]
}

This says "this identity can only read files in one storage container". The difference between those two snippets is the difference between a bad day and a catastrophe.

The most common cloud misconfigurations

• Publicly exposed storage: a container of files set to be readable by anyone on the internet, often by mistake. This is behind many data exposures.
• Over-permissive identities: wildcard permissions, administrator rights given "temporarily" and never removed.
• Secrets in code: access keys or passwords committed to source repositories or left in configuration files and shared online.
• No multi-factor authentication on privileged accounts, especially the root or owner account.
• Long-lived access keys that are never rotated, instead of temporary credentials.
• Overly open network rules: management ports such as remote administration open to the whole internet.
• Logging disabled: no audit trail of administrative actions, so no way to investigate.
• Unpatched or unmanaged machine images and forgotten test resources that stay running.
• Default settings that were never reviewed.
• Missing separation between environments: development and production share an account or credentials.

Notice that none of these requires a clever exploit. They are visible to anyone who looks, which is why attackers scan for them automatically all the time, and why defenders must as well.

How defenders keep control

• Secure the owner account: unique strong password, hardware-based or app-based multi-factor authentication, almost never used in daily work.
• Use groups and roles rather than permissions assigned directly to individuals.
• Prefer temporary credentials over long-term keys.
• Review permissions regularly and remove what is unused. Many platforms show which permissions have never been used.
• Turn on audit logging for administrative actions and send it to a protected location. Feed it to the SIEM from chapter 4.
• Use policies as guard-rails: organization-level rules that forbid dangerous settings, such as public storage, no matter what an individual administrator tries.
• Scan configurations continuously: tools often called cloud security posture management compare your setup with best-practice baselines. The Center for Internet Security benchmarks and provider guidance are widely used references.
• Tag resources with owner and purpose so that forgotten ones are found and removed.

What a tester looks at, in an authorized engagement

In an authorized cloud review, a tester generally begins from the configuration and not from attacks: who can do what, which resources are exposed, which keys are old, what is logged. Many reviews are done with read-only access, which is safer and often more productive than an intrusive test. The findings read like those of the Active Directory audit in chapter 1: relationships and permissions that together create a path to a critical resource.

A small mental model for assessing a resource

1. Who can reach it? Network exposure, public or private.
2. Who may use it? Identities and permissions.
3. What does it hold or control? Sensitivity of data and power of actions.
4. Can we see what happens to it? Logging and alerting.
5. Can we recover? Backups and the ability to rebuild.

Your turn: review a policy

Below are three generic policies attached to three identities in a fictional company. Rank them from most to least risky and suggest one improvement for each.

Policy A (website application):
  allow actions ["*"] on resources ["*"]

Policy B (nightly backup job):
  allow actions ["storage:read", "storage:write"]
  on resources ["storage/backups-bucket/*"]

Policy C (new intern, for training):
  allow actions ["compute:*", "storage:*", "iam:*"]
  on resources ["*"]

See a solution

1. Policy A: highest risk. Full access to everything for a public-facing application. If the website is compromised, the entire account is compromised. Improve by listing the few actions and resources the application truly needs.
2. Policy C: very high risk, close to A. The identity can manage permissions (the iam actions), which means it can grant itself more rights. An intern account with this power is unnecessary. Improve by granting read-only or sandbox-limited access, with no permission to change IAM.
3. Policy B: lowest risk. Scoped to one container and two actions. It can still be improved: separate read and write identities if possible, and consider write-only if the job never needs to read.

Portfolio step

Create a folder 05-cloud-modern-apps in your portfolio. Add cloud-misconfigurations.md: a one-page checklist of the ten misconfigurations above with, for each one, a short explanation of why it is dangerous and the safer alternative. Keep it provider-neutral; that makes it reusable.

Now let us look at a layer where cloud and modern applications meet: APIs.