Review Least Privilege IAM Cloud: Izin Efektif
Least privilege bukan policy pendek. Kontrol ini adalah jawaban yang dapat dibuktikan atas pertanyaan: principal terautentikasi mana dapat melakukan aksi apa pada resource mana, dengan kondisi apa, lewat seluruh jalur yang tersedia. Pisahkan review administrator, pengguna, dan workload. Ketiganya dapat menjadi jalur menuju data produksi.
Petakan izin efektif
Kumpulkan grant langsung, grant turunan, resource policy, keanggotaan grup, federation, dan jalur delegasi untuk setiap grup manusia, service account, managed identity, role workload, serta role break-glass. Jangan menyimpulkan dari nama role. Uji aksi yang diizinkan pada resource tujuan dan aksi sama pada resource tetangga yang harus ditolak.
Google Cloud menyebut gabungan allow policy dari resource dan induknya sebagai effective allow policy. Azure RBAC bersifat aditif untuk role assignment, lalu deny assignment serta condition ikut dievaluasi. Di AWS, identity policy, resource policy, permissions boundary, SCP, dan session policy dapat memengaruhi hasil. Explicit deny mengalahkan allow.
| Principal | Kapabilitas yang dimaksud | Scope efektif | Owner | Bukti | Hasil |
|---|---|---|---|---|---|
| role CI | deploy layanan staging | resource staging bernama | owner platform | simulator policy dan trust policy | pass/fail |
| workload aplikasi | baca objek tenant-a/ | satu prefix bucket | owner layanan | identitas runtime dan uji akses | pass/fail |
| admin darurat | pemulihan berbatas waktu | akun terdokumentasi | owner keamanan | approval dan audit session | pass/fail |
Catat scope organisasi, account/subscription, project, folder, resource group, resource, dan data plane. Role read-only Azure untuk management plane tidak otomatis membuktikan akses blob data plane. Pada S3, aksi dan resource bucket/objek juga perlu dievaluasi terpisah.
Telusuri assume role dan delegasi
Policy sempit tetap gagal bila principal dapat sts:AssumeRole ke role luas, menjalankan iam:PassRole, membuat kredensial, atau mengubah otorisasinya sendiri. Periksa trust policy AWS, sts:AssumeRole, iam:PassRole, mapping federasi, dan session policy sebagai satu jalur. Akses lintas account adalah jalur terpisah, bukan catatan kecil.
Di Google Cloud, periksa source identity, service-account impersonation atau workload identity federation, role target, hierarchy, deny policy, principal access boundary, dan IAM Conditions. Di Azure, periksa security principal, role definition, scope assignment, deny assignment, condition, dan keanggotaan grup transitif.
Permissions boundary AWS membatasi izin maksimum dari identity policy, tetapi tidak memberi izin sendiri. Principal access boundary Google Cloud membatasi resource yang boleh diakses principal meski allow policy memberi role. Keduanya guardrail delegasi; keduanya bukan pengganti grant dasar yang presisi.
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::example-private/tenant-a/*"
}Contoh ini tidak memberi list, write, delete, KMS decrypt, assume role, atau wildcard bucket. Tambahkan aksi hanya setelah perilaku aplikasi membuktikan kebutuhan, lalu uji kembali jalur yang harus ditolak.
Bukti, pengecualian, dan perbaikan
Artefak selesai memuat tanggal, environment, principal ID, kapabilitas tujuan, scope efektif, versi atau tautan immutable policy/trust policy, hasil perintah atau simulator, reviewer, dan status. Temuan gagal wajib memiliki owner perbaikan, tenggat, dan bukti retest.
Pengecualian harus menyebut kebutuhan bisnis, principal/resource/aksi tepat, kontrol kompensasi, approver, masa berlaku, dan uji pencabutan. “Admin sementara” tanpa tanggal berakhir adalah gagal. Hapus kredensial jangka panjang yang tidak dipakai, role broad, grup usang, service account dorman, dan trust lintas account yang tidak diperlukan. Jadwalkan recertification dengan owner bisnis: setiap capability sensitif harus dikonfirmasi masih diperlukan, bukan diwariskan karena role pernah ada. Bandingkan inventaris policy dengan penggunaan nyata dan bedakan akses yang jarang tetapi sah dari akses tanpa owner. Jika kebutuhan belum dapat dibuktikan, nonaktifkan akses terlebih dahulu melalui prosedur perubahan yang dapat dipulihkan. Dokumentasikan dampak, komunikasi, dan hasil rollback bila diperlukan.
Ulangi review setelah perubahan IdP, deployment, resource policy, atau containment insiden. Gunakan inventaris ini saat offboarding: cabut group membership, federated mapping, role assignment, dan trust policy yang memberi akses melalui jalur tidak langsung. Bukti pencabutan harus mencakup pengujian aksi yang sebelumnya diizinkan dan kini ditolak, bukan hanya screenshot perubahan konfigurasi. Pengujian infrastruktur dapat memvalidasi jalur otorisasi cloud yang disetujui.
Kasus kerja: role deployment sempit
Mulai dari role deployment yang boleh memperbarui satu layanan bernama. Kumpulkan API call yang dimaksud dari dry run terkendali, lalu tulis batas resource dan condition berdasarkan call itu, bukan menyalin kebijakan administrator. Output yang diharapkan mengizinkan deployment ke environment bernama serta menolak update ke environment saudara, layanan tak terkait, dan tindakan manajemen credential langsung. Catat ID event penolakan lalu bandingkan dengan daftar penolakan yang diharapkan; izin tak terduga adalah cacat review, sedangkan penolakan tak terduga perlu bukti alur kerja sebelum policy diperlebar.
Uji tepi sebelum penutupan
Uji role asumsi dari principal tak berwenang, sesi kedaluwarsa, tag hilang, dan ID resource salah bentuk. Periksa permission boundary serta policy tingkat organisasi secara terpisah karena akses efektif adalah irisan. Paket penutupan berisi revisi policy, output evaluator, trace dry run sukses, trace penolakan, approver, dan pengecualian bertanggal bila ada. Periksa ulang saat alur deployment menambah API call; wildcard permanen tidak dibuat hanya untuk membungkam penolakan baru.