첫 번째 원칙에서 클라우드 ID 및 액세스 (IAM)

⚡ TL;DR: IAM collapses to four words: who can do what to which thing. Master how a request is evaluated and why roles beat long-lived users, and you close the gap where most cloud breaches actually start.

Contents

• Why IAM is the foundation of cloud security
• The four words: who, what, which, allow/deny
• How a request is actually evaluated
• What a policy actually looks like
• Users vs roles: prefer roles, always
• Common mistakes that cost people (a lot)
• Where to go next

Why IAM is the foundation of cloud security

Almost every cloud breach you read about starts the same way: a credential or permission that was broader than it needed to be. Not a clever zero-day, just an access key with too much power, or an S3 bucket open to everyone. IAM (Identity and Access Management) is the system that decides who can do what. Get it right and most attack paths simply close.

It feels intimidating because of the jargon, principals, policies, roles, ARNs. But underneath, IAM answers exactly one question for every single request:

Is THIS identity allowed to perform THIS action on THIS resource, yes or no?

📌 Who this is for: Beginners. If you’ve ever gotten an “Access Denied” and not known why, this article is for you.

The four words: who, what, which, allow/deny

In the real world In tech 👤 Who is asking Principal (user / role) 🎬 What they want to do Action (e.g. s3:GetObject) 📦 Which thing Resource (an ARN) ✅ Yes or no Effect (Allow / Deny)

Every IAM concept is one of these four everyday ideas.

• Principal, the identity making the request. A human user, or (better) a role assumed by a service or app.
• Action, the specific operation, namespaced by service: s3:GetObject, ec2:StartInstances.
• Resource, the exact thing, named by an ARN (Amazon Resource Name): arn:aws:s3:::my-bucket/*.
• Effect, Allow or Deny. Everything is denied by default; you grant access explicitly.

How a request is actually evaluated

Every API call runs this gauntlet. Default is deny; an explicit Deny always wins over any Allow.

1. Start from DENY: Nothing is allowed until something explicitly allows it. This is the single most important IAM rule.
2. Look for a matching Allow: AWS gathers every policy attached to the principal and the resource, and checks for an Allow matching this action + resource.
3. Check for any explicit Deny: If any policy says Deny for this request, it’s denied, full stop. An explicit Deny beats any Allow.
4. Decide: Allowed only if there is a matching Allow and no matching Deny. Otherwise: Access Denied.

What a policy actually looks like

A policy is just JSON listing statements of effect + action + resource. This one lets a principal read objects from one bucket, and nothing else:

read-one-bucket.json

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

Enter fullscreen mode Exit fullscreen mode

Read it as a sentence: Allow the action s3:GetObject on every object in reports-bucket. No write, no delete, no other bucket. That’s least privilege, grant exactly what’s needed, nothing more.

Users vs roles: prefer roles, always

The biggest practical upgrade you can make: stop handing out long-lived access keys, and use roles instead.

IAM User (keys) IAM Role Credentials Long-lived access key Short-lived, auto-rotated If leaked Valid until you notice + revoke Expires in minutes/hours Best for Rare human/CLI cases Apps, services, EC2, Lambda, CI Rotation Manual (often forgotten) Automatic

Roles give out short-lived, auto-rotating credentials, far safer than static keys.

⚠️ The #1 cloud security mistake: Hardcoding long-lived access keys in code, config, or a Git repo. Leaked keys are the most common breach vector. Use roles so credentials are temporary and rotate themselves.

Common mistakes that cost people (a lot)

1. Using the root account for daily work. Lock it away, enable MFA, and never use it for routine tasks.
2. Granting * permissions “to make it work.” Action: "*" on Resource: "*" is admin-over-everything. Scope it down.
3. Long-lived access keys in code or Git. Use roles and short-lived credentials. Scan repos for leaked keys.
4. No MFA on human users. A password alone is one phishing email away from compromise.
5. Never auditing. Permissions accumulate. Review and remove what’s unused, least privilege is a habit, not a one-time setup.

Where to go next

The whole article in 6 lines

• IAM answers one question: can THIS identity do THIS action on THIS resource?
• Four parts: principal, action, resource, effect (Allow/Deny).
• Everything is denied by default; you grant access explicitly.
• An explicit Deny always beats an Allow.
• Practice least privilege, grant exactly what’s needed, nothing more.

• Prefer roles (short-lived credentials) over users with long-lived keys.

• Go deeper: Service Auth & IAM.

• Related read: Zero Trust Networking, where IAM meets the network.

• See it in context in the Cloud Engineer path.

Originally published on TheSimplifiedTech, where this guide is interactive, with in-browser terminal labs and diagrams. Learn cloud and DevOps by doing, no videos.