Cloud identity and access management

Why cloud IAM is critical

In a data centre, an attacker needs to get onto your network first. In the cloud, the management console and APIs are on the internet. Anyone with a valid admin password or access key can create servers, read every database and delete backups from anywhere in the world. That is why identity and access management (IAM) is the most important cloud control.

Key words

Reading a policy

In AWS, permissions are JSON policy documents. Each statement has an Effect (Allow or Deny), Actions (what can be done) and Resources (on what). Here is a least-privilege policy that lets an app only read invoice files from one bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::invoices-bucket/*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "*", "Resource": "*" }
  ]
}

Azure uses role-based access control (Azure RBAC) with built-in roles like Owner, Contributor and Reader, assigned to Microsoft Entra ID users, groups or managed identities at a scope (subscription, resource group or resource). Google Cloud has IAM roles assigned to principals on projects and resources. The ideas are the same.

Good cloud IAM habits

1. Lock away the root/owner account: strong password, MFA (ideally a hardware key), no access keys, used only for the few tasks that need it.
2. MFA for every human user, especially admins.
3. Use single sign-on from the company identity provider so leavers lose access everywhere at once.
4. Least privilege: start with nothing and add only what is needed. Use built-in "Reader" style roles for people who only look.
5. Prefer roles with temporary credentials for programs (for example an IAM role on a server, or a managed identity) instead of long-lived access keys.
6. If access keys must exist: rotate them, never put them in code, and delete unused ones.
7. Review permissions regularly; cloud tools can show permissions that have not been used for 90 days.

$ aws iam list-access-keys --user-name build-bot
{
    "AccessKeyMetadata": [
        {
            "UserName": "build-bot",
            "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
            "Status": "Active",
            "CreateDate": "2023-01-09T06:31:10+00:00"
        }
    ]
}

Common mistakes

• Using the root account for daily work.
• Giving developers full admin "to move fast".
• Access keys in source code, mobile apps or shared spreadsheets.
• Forgetting service accounts in access reviews; they often have the most power.