TDCTF Academy Logo TDCTF ACADEMY
@farishhz

9.2.3 Least Privilege Principle

Least Privilege Principle (LPP) adalah prinsip keamanan yang menyatakan bahwa setiap entitas (user, aplikasi, service) hanya boleh diberikan akses minimum yang diperlukan untuk menjalankan fungsinya. Di cloud computing - di mana izin bisa diatur dengan granularitas tinggi - implementasi LPP adalah kunci untuk meminimalkan risiko data breach dan privilege escalation.

Konsep Dasar

Definisi

Least Privilege berarti:

  • Setiap request hanya mendapatkan izin yang spesifik untuk tugas yang dijalankan
  • Tidak ada akses permanen kecuali benar-benar diperlukan
  • Akses diberikan untuk waktu terbatas (just-in-time)
  • Privilege dikurangi secara otomatis setelah tugas selesai

Mengapa Least Privilege Penting di Cloud?

  1. Blast radius: cloud breach bisa menyebar cepat karena API-driven - satu role compromised bisa mengakses ribuan resource
  2. Privilege escalation pathways: izin berlebihan sering menjadi jalur escalation - misal iam:PassRole + ec2:RunInstances bisa memberi akses ke role dengan izin lebih tinggi
  3. Visibility terbatas: di lingkungan besar, sulit melacak siapa punya akses ke apa
  4. Automation risk: pipeline CI/CD yang compromised bisa mengeksekusi tindakan dengan izin akun service

Implementasi di Cloud

Policy Minimization

Policy minimization berarti menulis policy dengan izin spesifik - bukan wildcard "Action": "*".

❌ Jangan:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

✅ Lakukan:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "s3:DeleteObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::app-logs-bucket",
    "arn:aws:s3:::app-logs-bucket/*"
  ],
  "Condition": {
    "StringEquals": {
      "s3:prefix": ["production/", "staging/"]
    }
  }
}

AWS: Permission Boundaries

Permission boundaries membatasi izin maksimal yang bisa dimiliki sebuah IAM user atau role. Ini seperti "plafon" - bahkan jika identity policy mengizinkan sesuatu, permission boundary bisa memblokirnya.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "cloudtrail:*"
      ],
      "Resource": "*"
    }
  ]
}

Boundary ini memastikan developer tidak bisa membuat user/role baru dengan izin lebih tinggi, mengubah CloudTrail, atau mengakses Organizations.

Cara attach ke role:

aws iam create-role \
  --role-name developer-role \
  --assume-role-policy-document file://trust-policy.json \
  --permissions-boundary arn:aws:iam::123456789012:policy/developer-boundary

AWS: Service Control Policies (SCP)

SCP bekerja di level AWS Organizations untuk membatasi izin di semua akun anggota. SCP bukan identity policy - SCP tidak memberikan izin, hanya membatasi.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:PutRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/admin-role"
        }
      }
    }
  ]
}

SCP ini mencegah semua user/role (kecuali admin-role) membuat atau memodifikasi IAM entities.

Hierarki SCP:

Organization Root
  └── SCP applied here - berlaku untuk semua akun
      ├── OU: Production
      │   └── SCP: Block IAM changes
      │       ├── Account: prod-web
      │       └── Account: prod-db
      └── OU: Development
          └── SCP: Block production access
              └── Account: dev-sandbox

Azure: Management Groups & Azure Policy

# Management group hierarchy
az account management-group create --name "Enterprise-Root"
az account management-group create --name "Production-MG" --parent "Enterprise-Root"

# Azure Policy - deny VM with public IP
az policy definition create \
  --name "deny-public-ip" \
  --rules '{
    "if": {
      "allOf": [
        {"field": "type", "equals": "Microsoft.Network/publicIPAddresses"},
        {"field": "location", "equals": "southeastasia"}
      ]
    },
    "then": {"effect": "Deny"}
  }' \
  --params '{}'

GCP: Organization Policy & IAM Conditions

GCP menggunakan Organization Policy Constraints untuk membatasi akses di seluruh hierarki:

# Mencegah public IP di Compute Engine
gcloud resource-manager org-policies enable-enforce \
  --organization=ORG_ID \
  --constraint=compute.vmExternalIpAccess

IAM Conditions memungkinkan akses bersyarat:

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
      "members": ["user:[email protected]"],
      "condition": {
        "title": "production_only",
        "expression": "resource.name.startsWith('projects/_/buckets/prod-')"
      }
    }
  ]
}

Privilege Escalation Paths di Cloud

Memahami privilege escalation pathways adalah kunci untuk menulis policy yang aman. Beberapa jalur umum:

AWS Privilege Escalation

  1. iam:PassRole + ec2:RunInstances

    • Attacker bisa meluncurkan EC2 instance dengan role yang memiliki izin lebih tinggi
    • Mitigasi: batasi iam:PassRole ke role tertentu dengan iam:PassedToService 
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "arn:aws:iam::*:role/ec2-app-role",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "ec2.amazonaws.com"
        }
      }
    }

  2. iam:CreatePolicyVersion + iam:SetDefaultPolicyVersion

    • Attacker bisa mengubah policy menjadi versi yang permisif
    • Mitigasi: gunakan permission boundary yang melarang modifikasi IAM

  3. lambda:UpdateFunctionCode + lambda:InvokeFunction

    • Attacker bisa mengganti code Lambda dengan code berbahaya yang memiliki izin role Lambda
    • Mitigasi: kunci version Lambda dengan $LATEST - gunakan published versions

  4. s3:PutBucketPolicy

    • Attacker bisa membuat S3 bucket policy yang memberikan akses ke akun eksternal
    • Mitigasi: use SCP untuk memblokir s3:PutBucketPolicy di production OU

Azure Privilege Escalation

  1. Microsoft.Authorization/roleAssignments/write

    • Attacker bisa memberikan role Contributor ke dirinya sendiri
    • Mitigasi: gunakan PIM dengan approval workflow

  2. Microsoft.ManagedIdentity/userAssignedIdentities/assign/action

    • Attacker bisa assign managed identity ke resource yang dikontrolnya
    • Mitigasi: Azure Policy untuk membatasi assignment managed identity

GCP Privilege Escalation

  1. iam.serviceAccounts.actAs

    • Attacker bisa menggunakan service account untuk mendapatkan akses
    • Mitigasi: batasi iam.serviceAccounts.actAs ke service account spesifik

  2. iam.roles.update

    • Attacker bisa memodifikasi IAM role menjadi lebih permisif
    • Mitigasi: gunakan Organization Policy untuk mencegah perubahan role

Tools Implementasi Least Privilege

AWS IAM Access Analyzer

Mendeteksi resource yang dibagikan secara publik atau cross-account: 

# Buat analyzer untuk seluruh akun
aws accessanalyzer create-analyzer \
  --analyzer-name "org-analyzer" \
  --type ACCOUNT

# Generate findings
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/org-analyzer

IAM Access Analyzer Policy Validation - analisis policy untuk izin berlebihan:

aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://policy.json

GCP Policy Analyzer

gcloud beta policy-intelligence query-activity \
  --project=my-project \
  --activity-type=policy-analysis \
  --query="member:user:[email protected]"

Azure AD Privileged Identity Management (PIM)

PIM memberikan Just-In-Time (JIT) access ke Azure AD roles dan Azure resources:

# Aktivasi role via PIM - temporary & perlu approval
az role assignment create \
  --assignee "[email protected]" \
  --role "Contributor" \
  --scope "/subscriptions/SUBSCRIPTION_ID" \
  --start-time "2026-07-22T10:00:00Z" \
  --end-time "2026-07-22T12:00:00Z"

Fitur PIM:

  • Time-bound activation: role aktif hanya untuk durasi tertentu
  • Approval workflow: aktivasi role butuh approval atasan
  • Justification: user harus memberikan alasan saat aktivasi
  • Audit log: semua aktivasi tercatat
  • Notifications: alert saat role diaktifkan

Just-In-Time Access

JIT access adalah implementasi praktis dari least privilege: akses diberikan saat diperlukan, bukan permanen.

AWS: JIT via IAM + Lambda + CloudWatch

Arsitektur JIT di AWS:

User → AWS Console / Slack bot
  → Lambda (validasi + approval)
    → AWS STS GetFederationToken
      → Temporary credentials (15 menit - 1 jam)
        → Auto-expire

Implementasi sederhana dengan AWS CLI:

# User minta akses - dapatkan temporary token dengan MFA
SESSION=$(aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/user \
  --token-code 123456 \
  --duration-seconds 3600)

export AWS_ACCESS_KEY_ID=$(echo $SESSION | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $SESSION | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $SESSION | jq -r '.Credentials.SessionToken')

Azure: JIT via PIM

# Aktivasi JIT di Azure Portal atau CLI
az role assignment create \
  --assignee "[email protected]" \
  --role "Virtual Machine Contributor" \
  --scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/prod-rg" \
  --start-time "2026-07-22T14:00:00Z" \
  --end-time "2026-07-22T16:00:00Z" \
  --justification "Emergency patch DB server"

GCP: JIT via Access Approval

gcloud access-approval requests approve \
  --project=my-project \
  --request-id="REQUEST_ID" \
  --reason-code="userInitiated" \
  --expire-time="2026-07-22T18:00:00Z"

Best Practices

Siklus Implementasi Least Privilege

  1. Start dengan deny all - beri izin minimal, lalu tambah sesuai kebutuhan
  2. Gunakan AWS IAM Access Analyzer - deteksi policy yang terlalu broad
  3. Terapkan di semua layer - SCP (organization), permission boundary (account), identity policy (user/role)
  4. Review dan rotasi policy - audit setiap 90 hari, cabut izin yang tidak terpakai
  5. Gunakan temporary credentials - hindari long-term access keys
  6. Monitor privilege usage - CloudTrail, CloudWatch Logs, alert untuk unusual activity

Checklist

  • Semua IAM user menggunakan group, bukan inline policy
  • Tidak ada policy dengan "Effect": "Allow", "Action": "*", "Resource": "*"
  • SCP aktif di AWS Organizations untuk blokir IAM changes
  • Permission boundary terpasang di semua role yang bisa diasumsikan user
  • MFA enforcement policy aktif di semua akun
  • Akses root / super admin menggunakan JIT dengan approval
  • Automated tool (Access Analyzer, Policy Analyzer) berjalan rutin
  • Tidak ada unused IAM roles atau users lebih dari 90 hari

Kesimpulan

Least Privilege Principle adalah salah satu kontrol keamanan paling efektif di cloud. Dengan membatasi akses secara granular, menggunakan permission boundaries, SCP, JIT access, dan tools automated analysis, Anda bisa meminimalkan blast radius dari potensi breach. Implementasi LPP bukan proyek satu kali - ini adalah proses berkelanjutan yang membutuhkan audit rutin, adaptasi terhadap perubahan arsitektur, dan budaya keamanan di seluruh organisasi.

← Sebelumnya 9.2.2 MFA (Multi-Factor Authentication) Selanjutnya → 9.3 Cloud Infrastructure
PADA HALAMAN INI