Cara SCP Bergabung dengan Izin IAM

Akses dalam organisasi diatur oleh dua lapisan: batas maksimum SCP yang ditetapkan oleh AWS Organisasi dan izin IAM yang diberikan di dalam akun. Memahami cara keduanya bergabung adalah salah satu gagasan yang paling sering diuji dalam domain tata kelola, karena hasilnya bergantung pada persetujuan dari keduanya.

Aturannya sederhana tetapi ketat: suatu tindakan hanya diizinkan jika diperbolehkan oleh keduanya, yaitu SCP yang berlaku dan kebijakan IAM akun tersebut. Izin efektif adalah irisan dari keduanya. SCP tanpa izin IAM yang sesuai tidak memberikan apa pun; izin IAM yang diblokir oleh SCP juga tidak memberikan apa pun.

Jika SCP mengizinkan suatu tindakan tetapi tidak ada kebijakan IAM yang memberikannya, hasilnya adalah ditolak oleh penolakan implisit IAM. SCP hanya membuat tindakan tersebut mungkin; IAM tetap harus benar-benar memberikannya. Banyak pelajar lupa bahwa SCP adalah batas maksimum, bukan pemberian izin.

Sebaliknya, jika kebijakan IAM mengizinkan suatu tindakan tetapi SCP menolaknya, hasilnya adalah ditolak. Penolakan dari SCP membatasi akun, terlepas dari seberapa longgar IAM. Dengan cara inilah organisasi menerapkan batas keras yang tidak dapat diubah oleh administrator lokal.

Permintaan hanya diizinkan jika keduanya, yaitu SCP dan kebijakan IAM, mengizinkan tindakan tersebut dan tidak ada penolakan eksplisit di mana pun. Logika irisan ini serupa dengan cara kerja batas izin, dan keduanya dapat berlaku secara bersamaan sehingga izin menjadi semakin sempit.

Dalam lingkungan yang sepenuhnya diatur, beberapa batas dapat ditumpuk: SCP (tingkat akun), batas izin (tingkat identitas), kebijakan sesi apa pun (tingkat sesi), dan kebijakan identitas (pemberian izin). Izin efektif adalah irisan semua batas ditambah pemberian izin, dikurangi penolakan eksplisit apa pun.

Bayangkan sebuah kebijakan IAM yang memberikan s3:* dan ec2:*, batas izin yang hanya mengizinkan s3:*, serta SCP yang hanya mengizinkan s3:GetObject. Izin efektifnya hanyalah s3:GetObject, yaitu irisan dari ketiga lapisan tersebut. Setiap batas mempersempit izin lebih jauh.

Di setiap lapisan, Penolakan eksplisit dalam kebijakan, SCP, batas, sesi, identitas, atau sumber daya apa pun akan langsung memblokir tindakan tersebut. Tidak ada gabungan izin yang dapat mengatasinya. Saat menganalisis skenario, cari penolakan eksplisit terlebih dahulu; jika ditemukan, jawabannya adalah ditolak.

Kebijakan berbasis sumber daya dapat memberikan akses dalam akun yang sama secara terpisah dari kebijakan identitas, tetapi SCP tetap membatasi akun principal. Untuk akses lintas akun, kendali di kedua akun dan kebijakan di kedua sisi berlaku. Aturan irisan menjadi lebih luas, tetapi gagasan utamanya tetap sama: setiap batas yang berlaku harus mengizinkan.

Jika akses gagal secara tidak terduga dalam organisasi, periksa dari bagian dalam ke luar: pastikan kebijakan identitas memberikan izin untuk tindakan tersebut, lalu periksa batas izin, kemudian SCP pada akun dan setiap OU induk, setelah itu kebijakan sesi, dan terakhir cari penolakan eksplisit di semua lapisan. Batas pertama yang tidak mencantumkan tindakan tersebut, atau penolakan apa pun, adalah penyebabnya.

SCP dan IAM bergabung melalui irisan: suatu tindakan memerlukan izin dari keduanya, ditambah batas izin dan sesi apa pun, serta tanpa penolakan eksplisit di mana pun. SCP dan batas hanya membatasi; kebijakan IAM memberikan izin. Agar suatu tindakan diizinkan, setiap batas harus mengizinkannya dan setidaknya harus ada satu pemberian izin.

Uji logika penggabungannya.

SCP dan IAM bergabung melalui irisan: suatu tindakan hanya diizinkan jika keduanya mengizinkannya, ditambah batas izin dan kebijakan sesi apa pun, serta tanpa penolakan eksplisit di mana pun. SCP dan batas hanya membatasi; kebijakan IAM memberikan izin. Penolakan eksplisit di lapisan mana pun selalu mengalahkan semua izin.