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 berbeda AWS 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.

Misalnya, Anda dapat menerapkan kebijakan menggunakan Deny pernyataan ke Mencegah akun anggota keluar dari organisasi tingkat root, yang akan efektif untuk semua akun di organisasi. Pernyataan tolak juga mendukung elemen kondisi yang dapat membantu untuk membuat pengecualian.

AWS Organizations melampirkan 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.

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 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 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 “ AWS Akses penuh”, Uji OU memiliki “ AWS Akses penuh” dengan “Tolak EC2 akses”, 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 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 “ AWS Akses 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 “ 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.