Access management

01

Who are you, and what can you do? Authentication and authorization

Think about walking into an office building. At the entrance, your ID badge proves it's really you. Then on each floor, the same badge is checked again to see whether you're allowed in there. The first check is authentication (confirming who you are), and the second is authorization (deciding whether you're allowed to do this). The cloud works the same way, in the same two steps.

Whoever sends a request is called a security principal, or just a principal. Principals aren't only people. A program that runs backups every night and a server that processes orders also call the cloud's storage and databases, so they're principals too. People prove who they are with a password and a second factor; programs prove it with keys or temporary credentials (chapter 4). Try switching the situation in the scene below.

In the HTTP standard, 401 means an authentication failure (tell me who you are again) and 403 means an authorization failure (I know who you are, but you're not allowed). Cloud APIs don't always follow that split, though. Some return 403 for both, and some return 401 for both. So instead of the status number, look at the error code and message to tell which door stopped you.

The most powerful account is the one you don't use

The top-level account you get when you first sign up for a cloud (the root or main account, or the top admin) can do anything — even change billing details or close the account. So you put MFA on it, lock it away, and do your everyday work with separate accounts that have only the permissions they need. If this account is compromised, no permission setting in the world can save you.

You've seen the door that checks who you are. But if your employees use dozens of apps, do you need to build that door separately for each one?

02

One identity for everything: SSO, federation, MFA and conditional access

Give every app its own accounts and passwords, and people end up with more passwords than they can remember — so they reuse the same one. When someone leaves, you have to go through every app to delete their account, and if you miss even one, that door stays open. That's why identities are kept in one place: an identity provider (IdP). You sign in once at the IdP, and the apps let you in because they trust the proof (a token) the IdP issues. That's SSO (single sign-on).

If your company already has a corporate directory, you don't have to create people all over again in the cloud. You can make the cloud trust that directory instead. Trusting another organization's identity checks like this is called federation, and the standards for passing that proof back and forth are SAML 2.0 and OIDC (OpenID Connect).

One password isn't enough: MFA

Passwords leak easily — through phishing, or because the same password leaked from some other site. MFA (multi-factor authentication) adds a second check on top of the password: something you have (a phone app, a security key) or something you are (a fingerprint). Not all MFA is equally strong. A text message (SMS) code or the six-digit number from an authenticator app can be typed straight into a fake site and passed along, but security keys and passkeys (FIDO2) only work on the real site, so they resist phishing.

Deciding by the situation: conditional access

You don't need the same level of checking every time someone signs in. Someone on a work laptop in the office can go straight through, while a sign-in from a country and device you've never seen can be asked for MFA or blocked. Looking at signals like the user, location, device and risk and deciding "allow / allow after an extra check / block" is called conditional access. You can only set conditions like this in one place if identities are kept in one place (the IdP).

Now we know for sure who you are. Next comes the second door — "are you allowed to do this?" Let's read the policies that decide it.

03

How to read a policy: who, what, where and under which conditions

Permissions are granted with policies. Policies look different at each provider, but they hold almost the same fields: who (the principal), what (the action), where (the resource), under which conditions (the condition), and whether it's an allow or a deny.

Allow | Who: developers group
      | What: read objects, write objects
      | Where: every object in the dev bucket
      | Condition: only when signed in with MFA

When a request comes in, the system gathers every policy that applies to it and checks them all. The rules for the verdict fit in three lines.

In the scene below, try attaching and removing the allow policy and the deny policy.

Two places to attach a policy: the identity side and the resource side

You can attach a policy to an identity like a person, group or role ("this person can do these things"), or to a resource like a storage bucket ("these principals can get into this bucket"). A resource-side policy always has a "who" field. Resource-side policies matter most when you let in principals from other accounts or organizations, so chapter 5 covers them on their own.

Don't grant person by person — bundle it: groups and roles

If you attach policies to each person one by one, it becomes unmanageable as people join. Instead, you put people who do the same job in a group and attach the policy to the group, and you build bundles of permissions like "read-only" or "database operator" as roles. This is called role-based access control (RBAC). Using attributes like tags as conditions on top of that — "only resources with the same project tag" — is called attribute-based access control (ABAC).

Policies aren't just for people. So how do you give permissions to a program that runs all night with nobody around?