Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Evaluasi SCP

Karena Anda dapat melampirkan beberapa kebijakan kontrol layanan (SCP) di tingkat yang berbeda AWS Organizations, memahami bagaimana SCP dievaluasi dapat membantu Anda menulis SCP yang menghasilkan hasil yang tepat.

Cara kerja SCP dengan Izinkan

Agar izin diizinkan untuk akun tertentu, harus ada Allow pernyataan eksplisit di setiap level dari root melalui setiap OU di jalur langsung ke akun (termasuk akun target itu sendiri). Inilah sebabnya ketika Anda mengaktifkan SCP, AWS Organizations melampirkan kebijakan SCP ter AWS kelola bernama FullLawsAccess yang memungkinkan semua layanan dan tindakan. Jika kebijakan ini dihapus dan tidak diganti di tingkat organisasi mana pun, semua OU dan akun di bawah level tersebut akan diblokir untuk melakukan tindakan apa pun.

Sebagai contoh, mari kita berjalan melalui skenario yang ditunjukkan pada gambar 1 dan 2. Agar izin atau layanan diizinkan di Akun B, SCP yang mengizinkan izin atau layanan harus dilampirkan ke Root, OU Produksi, dan ke Akun B itu sendiri.

Evaluasi SCP mengikuti model penolakan secara default, yang berarti bahwa izin apa pun yang tidak diizinkan secara eksplisit di SCP ditolak. Jika pernyataan izin tidak ada di SCP di salah satu level seperti Root, Production OU atau Account B, akses ditolak.

Gambar 1: Contoh struktur organisasi dengan Allow pernyataan terlampir di Root, Production OU dan Account B

Gambar 2: Contoh struktur organisasi dengan Allow pernyataan yang hilang di OU Produksi dan dampaknya pada Akun B

Bagaimana SCP bekerja dengan Deny

Agar izin dit olak untuk akun tertentu, setiap SCP dari root melalui setiap OU di jalur langsung ke akun (termasuk akun target itu sendiri) dapat menolak izin itu.

Sebagai contoh, katakanlah ada SCP yang dilampirkan ke OU Produksi yang memiliki Deny pernyataan eksplisit yang ditentukan untuk layanan tertentu. Kebetulan ada SCP lain yang dilampirkan ke Root dan ke Akun B yang secara eksplisit memungkinkan akses ke layanan yang sama, seperti yang ditunjukkan pada Gambar 3. Akibatnya, Akun A dan Akun B akan ditolak akses ke layanan karena kebijakan penolakan yang melekat pada tingkat mana pun di organisasi dievaluasi untuk semua OU dan akun anggota di bawahnya.

Gambar 3: Contoh struktur organisasi dengan Deny pernyataan yang dilampirkan di OU Produksi dan dampaknya pada Akun B

Strategi untuk menggunakan SCP

Saat menulis SCP, Anda dapat menggunakan kombinasi Allow dan Deny pernyataan untuk memungkinkan tindakan dan layanan yang dimaksudkan di organisasi Anda. Denypernyataan adalah cara ampuh untuk menerapkan pembatasan yang harus benar untuk bagian yang lebih luas dari organisasi atau OU Anda karena ketika diterapkan di root atau OU-level mereka mempengaruhi semua akun di bawahnya.

AWS Organizations melampirkan SC AWS P terkelola bernama FullLawsAccess ke setiap root, OU, dan akun saat dibuat. Kebijakan ini mengizinkan semua layanan dan tindakan. Anda dapat mengganti FullLawsAccess dengan kebijakan yang hanya mengizinkan serangkaian layanan sehingga layanan baru tidak Layanan AWS diizinkan kecuali jika secara eksplisit diizinkan dengan memperbarui SCP. Misalnya, jika organisasi Anda hanya ingin mengizinkan penggunaan subset layanan di lingkungan Anda, Anda dapat menggunakan Allow pernyataan untuk hanya mengizinkan layanan tertentu. Anda dapat memilih untuk mengganti FullLawsAccess di tingkat root atau di setiap level. Jika Anda melampirkan SCP allowlist khusus layanan di root, itu secara otomatis berlaku untuk semua OU dan akun di bawahnya — yang berarti kebijakan tingkat root tunggal menentukan daftar izin layanan yang efektif di seluruh organisasi seperti yang ditunjukkan dalam skenario 7. Atau, Anda dapat menghapus dan mengganti FullLawsAccess di setiap OU dan akun, memungkinkan Anda menerapkan daftar izin layanan yang lebih terperinci yang berbeda antara unit organisasi atau akun individu.

Catatan: Mengandalkan hanya pada pernyataan allow dan model implisit deny-by-default dapat menyebabkan akses yang tidak diinginkan, karena pernyataan Allow yang lebih luas atau tumpang tindih dapat mengesampingkan pernyataan yang lebih ketat.

JSON

{
"Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        }
    ]
}

Kebijakan yang menggabungkan dua pernyataan mungkin terlihat seperti contoh berikut, yang mencegah akun anggota meninggalkan organisasi dan memungkinkan penggunaan AWS layanan yang diinginkan. Administrator organisasi dapat melepaskan kebijakan FullLawsAccess dan melampirkan kebijakan ini sebagai gantinya.

JSON

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:*",
                "cloudwatch:*",
                "organizations:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny", 
            "Action":"organizations:LeaveOrganization",
            "Resource": "*" 
        }
    ]
}

Untuk menunjukkan bagaimana beberapa kebijakan kontrol layanan (SCP) dapat diterapkan dalam suatu AWS Organisasi, pertimbangkan struktur organisasi dan skenario berikut.

Skenario 1: Dampak kebijakan Deny

Skenario ini menunjukkan bagaimana kebijakan penolakan di tingkat yang lebih tinggi dalam organisasi berdampak pada semua akun di bawah ini. Ketika OU Sandbox memiliki kebijakan “Akses penuh AWS ” dan “Tolak akses S3”, dan Akun B memiliki kebijakan “Tolak akses EC2”, hasilnya adalah Akun B tidak dapat mengakses S3 (dari penolakan) dan EC2 (dari penolakan tingkat akunnya). OU-level Akun A tidak memiliki akses S3 (dari penol OU-level akan).

Skenario 2: Kebijakan Izinkan harus ada di setiap level

Skenario ini menunjukkan bagaimana kebijakan izinkan bekerja di SCP. Agar layanan dapat diakses, harus ada izin eksplisit di setiap level dari root hingga akun. Di sini, karena OU Sandbox memiliki kebijakan “Izinkan akses EC2", yang hanya secara eksplisit mengizinkan akses layanan EC2, Akun A dan B hanya akan memiliki akses EC2.

Skenario 3: Dampak hilangnya pernyataan Allow di tingkat root

Ketika root hanya memiliki pernyataan Tolak tanpa pernyataan Izinkan “ AWS Akses penuh”, semua akun anggota tidak mendapatkan akses layanan. SCP memerlukan Izin eksplisit di setiap level di jalur. Oleh karena itu, Deny-only SCP di root memblokir setiap layanan kecuali Izin eksplisit menutupinya.

Skenario 4: Pernyataan Penolakan Berlapis dan izin yang dihasilkan

Skenario ini menunjukkan struktur OU mendalam dua tingkat. Baik OU Root dan Beban Kerja memiliki “ AWS Akses penuh”, OU Uji memiliki “Akses penuh AWS ” dengan “Tolak akses EC2", dan OU Produksi memiliki “Akses penuh AWS ”. Akibatnya, Akun D memiliki semua akses layanan kecuali EC2 dan Akun E dan F memiliki semua akses layanan.

Skenario 5: Izinkan kebijakan OU-level untuk membatasi akses layanan

Skenario ini menunjukkan bagaimana kebijakan izinkan dapat digunakan untuk membatasi akses ke layanan tertentu. OU Tes memiliki kebijakan “Izinkan akses EC2”, yang berarti hanya layanan EC2 yang diizinkan untuk Akun D. OU Produksi mempertahankan “Akses penuh AWS ”, sehingga Akun E dan F memiliki akses ke semua layanan. Ini menunjukkan bagaimana kebijakan izin yang lebih ketat dapat diterapkan OU-level sambil mempertahankan izin yang lebih luas di tingkat root.

Skenario 6: Root-level menolak memengaruhi semua akun terlepas dari izin tingkat yang lebih rendah

Skenario ini menunjukkan bahwa kebijakan penolakan di tingkat root memengaruhi semua akun di organisasi, terlepas dari kebijakan izinkan di tingkat yang lebih rendah. Root memiliki kebijakan “ AWS Akses penuh” dan “Tolak akses S3”. Meskipun OU Uji memiliki kebijakan “Izinkan akses S3”, penolakan S3 tingkat root diutamakan. Akun D tidak memiliki akses layanan karena Test OU hanya mengizinkan akses S3, tetapi S3 ditolak di tingkat root. Akun E dan F dapat mengakses layanan lain kecuali S3 karena penolakan eksplisit di tingkat root.

Skenario 7: Kustom tingkat root mengizinkan kebijakan untuk membatasi OU-level akses

Skenario ini menunjukkan bagaimana SCP dengan layanan eksplisit memungkinkan fungsi daftar ketika diterapkan pada tingkat root dalam. AWS Organizations Pada tingkat root organisasi, dua SCP khusus “Izinkan Layanan” dilampirkan yang secara eksplisit mengizinkan akses ke serangkaian AWS layanan terbatas — SCP_1 memungkinkan IAM dan Amazon EC2, SCP_2 memungkinkan Amazon S3 dan Amazon. CloudWatch Pada tingkat unit organisasi (OU), kebijakan FullLawsAccess default tetap dilampirkan. Namun, karena perilaku persimpangan, akun A dan B di bawah OU ini hanya dapat mengakses layanan yang secara eksplisit diizinkan oleh SCP tingkat root. Kebijakan root yang lebih ketat diutamakan, secara efektif membatasi akses hanya ke IAM, EC2, S3, dan CloudWatch layanan, terlepas dari izin yang lebih luas yang diberikan di tingkat organisasi yang lebih rendah.