post-1130

6 Jenis AWS Policy: Bila Nak Guna Yang Mana?

by

6 Jenis AWS Policy

AWS ada banyak cara nak control permission. Ramai orang tahu pasal IAM policy je, tapi sebenarnya ada 6 jenis policy yang berbeza, masing-masing ada tujuan tersendiri.

Aku breakdown satu-satu kat sini.

1. Identity-Based Policy

Policy yang lekat terus pada IAM user, group, atau role. Ni yang paling common digunakan.

  • Attached kepada: IAM Users, Groups, Roles
  • Best for: Bagi permission spesifik kepada identiti tertentu
  • Control dia fine-grained, ko boleh tentukan exact action apa yang dibenarkan
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Policy kat atas ni boleh attach ke IAM user atau role. User/role tu je yang dapat akses baca object dalam bucket.

2. Resource-Based Policy

Policy yang lekat pada resource, bukan pada identiti. Contoh paling biasa: S3 bucket policy, SQS queue policy, Lambda resource policy.

  • Attached kepada: Resource (S3, SQS, Lambda, etc.)
  • Best for: Bagi akses cross-account, atau bagi service lain akses resource ko
  • Ada field Principal, berbeza dengan identity-based policy
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Kat sini account lain (123456789012) dapat akses bucket ko. Tanpa resource-based policy, cross-account access memang susah nak setup.

3. Permissions Boundary

Ini bukan policy yang bagi permission, tapi policy yang hadkan maximum permission yang boleh ada pada sesebuah identiti.

  • Attached kepada: IAM Users, Roles
  • Best for: Delegate permission management kepada team lain tapi dengan guardrail
  • Walaupun identity-based policy bagi lebih, permissions boundary yang tentukan ceiling dia

Contoh use case: Ko bagi developer boleh create IAM role sendiri, tapi dengan boundary supaya diorang tak boleh create role yang ada admin access.

4. Service Control Policy (SCP)

Policy peringkat AWS Organizations. Bukan bagi permission, tapi set maximum permission untuk seluruh OU atau account dalam organization.

  • Attached kepada: AWS Organization root, OU, atau individual account
  • Best for: Enforce guardrail peringkat organisasi (contoh: block semua region kecuali ap-southeast-1)
  • Management account tak kena effect SCP
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-southeast-1"
        }
      }
    }
  ]
}

SCP ni enforce dari atas ke bawah. Walaupun user ada Allow dalam IAM policy dia, kalau SCP deny, tetap kena block.

5. Access Control List (ACL)

Policy lama yang masih wujud untuk S3 dan VPC. Berbeza dengan policy lain sebab dia guna XML format dan tak support JSON policy language.

  • Attached kepada: S3 buckets/objects, VPC resources
  • Best for: Legacy use case je, atau cross-account S3 access yang simple
  • AWS dah recommend guna bucket policy sebagai ganti untuk S3

Kalau ko buat setup baru, elak guna ACL. Guna bucket policy atau resource-based policy yang lebih fleksibel.

6. Session Policy

Policy sementara yang pass masa ko assume role atau request temporary credential via STS. Ia hadkan permission dalam session tu je, tak affect role permission yang asal.

  • Attached kepada: Temporary session (AssumeRole, GetFederationToken)
  • Best for: Further restrict permission dalam specific session tanpa ubah role policy
  • Effective permission adalah intersection antara role policy dan session policy
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyRole \
  --role-session-name my-session \
  --policy file://session-policy.json

Berguna bila ko nak bagi temporary access yang lebih terhad dari role asal, contohnya untuk automated job yang perlu akses subset resource je.

Ringkasan: Bila Guna Apa

Policy Type Guna Bila
Identity-based Default choice untuk bagi permission kepada user/role
Resource-based Cross-account access, atau service-to-service
Permissions Boundary Delegate IAM management dengan guardrail
SCP Enforce org-wide restriction dalam AWS Organizations
ACL Legacy je, elak untuk setup baru
Session Policy Restrict further dalam temporary session

Kebanyakan setup akan guna identity-based dan resource-based policy. SCP masuk bila ko dah manage multiple AWS account dalam Organizations. Permissions boundary dan session policy lebih niche tapi penting bila situasi memerlukan.

Leave a Comment