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

Bagaimana SCPs 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 SCPs, AWS Organizations melampirkan kebijakan SCP AWS terkelola bernama Full AWSAccess yang memungkinkan semua layanan dan tindakan. Jika kebijakan ini dihapus dan tidak diganti pada tingkat organisasi mana pun, semua OUs 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 deny-by-default model, yang berarti bahwa izin apa pun yang tidak diizinkan secara eksplisit di dalamnya ditolak. SCPs Jika pernyataan izin tidak ada SCPs 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 SCPs 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 akses ke layanan karena kebijakan penolakan yang dilampirkan ke tingkat mana pun dalam organisasi dievaluasi untuk semua akun anggota OUs dan di bawahnya.

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

Strategi untuk menggunakan SCPs

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

AWS Organizationsmelampirkan SCP AWS terkelola bernama Full AWSAccess ke setiap root, OU, dan akun saat dibuat. Kebijakan ini mengizinkan semua layanan dan tindakan. Anda dapat mengganti Full AWSAccess dengan kebijakan yang hanya mengizinkan satu set layanan sehingga yang baru tidak Layanan AWS diizinkan kecuali secara eksplisit diizinkan dengan memperbarui. SCPs 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 Full AWSAccess di tingkat root atau di setiap level. Jika Anda melampirkan SCP daftar izin khusus layanan di root, SCP otomatis berlaku untuk semua OUs 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 Penuh AWSAccess di setiap OU dan akun, memungkinkan Anda untuk menerapkan daftar izin layanan yang lebih terperinci yang berbeda antara unit organisasi atau akun individu.

Catatan: Hanya mengandalkan pernyataan allow dan deny-by-default model implisit dapat menyebabkan akses yang tidak diinginkan, karena pernyataan Izinkan 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 Lengkap dan melampirkan AWSAccess 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 (SCPs) dapat diterapkan dalam AWS Organisasi, pertimbangkan struktur dan skenario organisasi berikut.

Skenario 1: Dampak kebijakan Penyangkalan

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

Skenario 2: Izinkan kebijakan harus ada di setiap level

Skenario ini menunjukkan cara kerja kebijakan izinkan SCPs. Agar layanan dapat diakses, harus ada izin eksplisit di setiap tingkat dari root hingga akun. Di sini, karena Sandbox OU memiliki kebijakan “Izinkan EC2 akses”, yang hanya secara eksplisit mengizinkan akses EC2 layanan, 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 “AWSAkses penuh”, Uji OU memiliki “AWSAkses penuh” dengan “Tolak EC2 akses”, dan OU Produksi memiliki “AWSAkses penuh”. Akibatnya, Akun D memiliki semua akses layanan kecuali EC2 dan Akun E dan F memiliki semua akses layanan.

Skenario 5: Izinkan kebijakan di tingkat OU untuk membatasi akses layanan

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

Skenario 6: Penolakan tingkat root 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 “AWSAkses 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 untuk membatasi akses tingkat OU

Skenario ini menunjukkan bagaimana SCPs dengan layanan eksplisit mengizinkan fungsi daftar ketika diterapkan pada tingkat root dalam file. AWS Organizations Pada tingkat akar organisasi, dua “Izinkan Layanan” khusus SCPs 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), AWSAccess kebijakan Lengkap default tetap dilampirkan. Namun, karena perilaku persimpangan, akun A dan B di bawah ini hanya OUs dapat mengakses layanan yang diizinkan secara eksplisit oleh SCP tingkat root. Kebijakan root yang lebih ketat diutamakan, secara efektif membatasi akses hanya ke IAM,, S3, dan CloudWatch layanan EC2, terlepas dari izin yang lebih luas yang diberikan pada tingkat organisasi yang lebih rendah.