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) pada tingkat yang berbeda AWS Organizations, memahami bagaimana SCP dievaluasi dapat membantu Anda menulis SCP yang menghasilkan hasil yang tepat.

Bagaimana SCP bekerja dengan Izinkan

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

Sebagai contoh, mari kita telusuri 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 Akun B itu sendiri.

Evaluasi SCP mengikuti model deny-by-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 tingkat seperti Root, Produksi OU atau Akun 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 Produksi OU dan dampaknya pada Akun B

Bagaimana SCP bekerja dengan Deny

Agar izin ditolak untuk akun tertentu, SCP apa pun 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 melekat pada OU Produksi yang memiliki Deny pernyataan eksplisit yang ditentukan untuk layanan tertentu. Ada juga SCP lain yang dilampirkan ke Root dan Akun B yang secara eksplisit memungkinkan akses ke layanan yang sama, seperti yang ditunjukkan pada Gambar 3. Akibatnya, baik Akun A dan Akun B akan ditolak aksesnya ke layanan karena kebijakan penolakan yang dilampirkan pada tingkat mana pun dalam organisasi dievaluasi untuk semua OU dan akun anggota di bawahnya.

Gambar 3: Contoh struktur organisasi dengan Deny pernyataan terlampir di Produksi OU 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 yang ampuh untuk menerapkan pembatasan yang seharusnya benar untuk bagian yang lebih luas dari organisasi Anda atau OU karena ketika mereka diterapkan di root atau OU-level mereka mempengaruhi semua akun di bawahnya.

AWS Organizations melampirkan SCP AWS terkelola bernama FulLawsAccess ke setiap root, OU, dan akun saat dibuat. Kebijakan ini mengizinkan semua layanan dan tindakan. Anda dapat mengganti FulLawsAccess dengan kebijakan yang hanya mengizinkan satu set layanan sehingga Layanan AWS new tidak diizinkan kecuali diizinkan secara eksplisit 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 FulLawsAccess di tingkat root atau di setiap level. Jika Anda melampirkan SCP daftar izin khusus layanan di root, SCP otomatis berlaku untuk semua OU dan akun di bawahnya—artinya kebijakan tingkat root tunggal menentukan daftar izin layanan efektif di seluruh organisasi seperti yang ditunjukkan dalam skenario 7. Atau, Anda dapat menghapus dan mengganti FulLawsAccess di setiap OU dan akun, memungkinkan Anda menerapkan daftar izin layanan yang lebih terperinci yang berbeda antara unit organisasi atau akun individual.

Catatan: Hanya mengandalkan pernyataan allow dan model deny-by-default implisit dapat menyebabkan akses yang tidak diinginkan, karena pernyataan Izinkan yang lebih luas atau tumpang tindih dapat menggantikan 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 FulLawsAccess 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 AWS Organisasi, pertimbangkan struktur dan skenario organisasi berikut.

Skenario 1: Dampak kebijakan Deny

Skenario ini menunjukkan bagaimana kebijakan penolakan di tingkat yang lebih tinggi dalam organisasi memengaruhi semua akun di bawah ini. Ketika Sandbox OU memiliki kebijakan “ AWS Akses penuh” 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 penolakan OU-level).

Skenario 2: Izinkan kebijakan harus ada di setiap level

Skenario ini menunjukkan cara kerja kebijakan izinkan di SCP. Agar layanan dapat diakses, harus ada izin eksplisit di setiap tingkat dari root hingga akun. Di sini, karena Sandbox OU 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 Izinkan di tingkat root

Kehilangan pernyataan “Izinkan” di tingkat root di SCP adalah kesalahan konfigurasi kritis yang secara efektif akan memblokir semua akses ke AWS layanan dan tindakan untuk semua akun anggota di organisasi Anda.

Skenario 4: Pernyataan Layered Deny dan izin yang dihasilkan

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

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

Skenario ini menunjukkan bagaimana kebijakan izin dapat digunakan untuk membatasi akses ke layanan tertentu. Uji OU memiliki kebijakan “Izinkan akses EC2”, yang berarti hanya layanan EC2 yang diizinkan untuk Akun D. Produksi OU mempertahankan “ AWS Akses penuh”, 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 penolakan memengaruhi semua akun terlepas dari izin tingkat yang lebih rendah

Skenario ini menunjukkan bahwa kebijakan penolakan di tingkat akar mempengaruhi semua akun dalam organisasi, terlepas dari kebijakan izinkan di tingkat yang lebih rendah. Root memiliki kebijakan “ AWS Akses penuh” dan “Tolak akses S3”. Meskipun Test OU memiliki kebijakan “Izinkan akses S3”, penolakan S3 tingkat root lebih 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 untuk S3 karena penolakan eksplisit di tingkat root.

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

Skenario ini menunjukkan bagaimana SCP dengan layanan eksplisit mengizinkan fungsi daftar ketika diterapkan pada tingkat root dalam file. AWS Organizations Pada tingkat root organisasi, dua SCP “Izinkan Layanan” khusus 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 FulLawsAccess default tetap dilampirkan. Namun, karena perilaku persimpangan, akun A dan B di bawah OU ini hanya dapat mengakses layanan yang diizinkan secara eksplisit 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 pada tingkat organisasi yang lebih rendah.