Cloud IAM and Posture Management

Identity is the new perimeter

In the cloud, most damage flows through identity and access management (IAM): who or what can call which API on which resource. Common failures are wildcard policies ("Action": "*"), long-lived access keys for humans and machines, unused permissions that pile up, and overly broad cross-account trust. Good practice is to grant specific actions on specific resources, use roles and federation instead of user keys, enforce MFA for humans, and review permissions using access analysers that show what was actually used. At organisation level, guardrail policies (such as AWS Service Control Policies or Azure Policy) can forbid dangerous actions in every account, for example disabling audit logging. Cloud security posture management (CSPM) tools continuously check live accounts against benchmarks and flag public storage, unencrypted databases or disabled logging, catching drift that IaC scanning cannot see because it happened outside code.

A least-privilege IAM policy

The service can read and write objects under one prefix of one bucket, and nothing else.

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

Read the wildcard twice

"Resource": "*" combined with iam:PassRole or iam:* often lets an identity grant itself more power. Review IAM changes in pull requests as carefully as code.

त्वरित जाँच: Which IAM practice best limits damage if a service's credentials are stolen?

• Using one shared admin role for all services
• Rotating the admin password every year
• Disabling CloudTrail to reduce noise
• Granting only the specific actions and resources the service needs