Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Contoh warisan
Contoh ini menunjukkan cara kerja pewarisan kebijakan dengan menunjukkan bagaimana kebijakan tag induk dan anak digabungkan ke kebijakan tag efektif untuk sebuah akun.
Contoh berikut mengasumsikan bahwa Anda memiliki struktur organisasi yang ditunjukkan pada diagram berikut.
![Organisasi dengan satu root, duaOUs, dan beberapa akun.](images/org-structure-inheritance.png)
Contoh
- Contoh 1: Izinkan kebijakan anak untuk menimpa hanya nilai tag
- Contoh 2: Menambahkan nilai-nilai baru untuk tag yang diwariskan
- Contoh 3: Hapus nilai dari tag yang diwariskan
- Contoh 4: Membatasi perubahan kebijakan anak
- Contoh 5: Konflik dengan operator kontrol anak
- Contoh 6: Konflik dengan penambahan nilai pada tingkat hirarki yang sama
Contoh 1: Izinkan kebijakan anak untuk menimpa hanya nilai tag
Kebijakan tag berikut mendefinisikan kunci tag CostCenter
dan dua nilai yang dapat diterima, Development
dan Support
. Jika Anda melampirkannya ke akar organisasi, kebijakan tag berlaku untuk semua akun di organisasi tersebut.
Kebijakan A — Kebijakan tag akar organisasi
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }
Misalnya Anda ingin pengguna menggunakan nilai tag yang berbeda untuk kunci, dan Anda ingin menerapkan kebijakan tag untuk jenis sumber daya tertentu. OU1 Karena kebijakan A tidak menentukan operator kontrol anak mana yang diizinkan, semua operator diperbolehkan. Anda dapat menggunakan @@assign
operator dan membuat kebijakan tag seperti berikut ini untuk dilampirkanOU1.
Kebijakan B — kebijakan OU1 tag
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Sandbox" ] }, "enforced_for": { "@@assign": [ "redshift:*", "dynamodb:table" ] } } } }
Menentukan operator @@assign
untuk tag menyebabkan hal berikut ketika kebijakan A dan kebijakan B bergabung untuk membentuk kebijakan tag efektif untuk sebuah akun:
-
Kebijakan B menimpa dua nilai tag yang ditentukan dalam kebijakan induk, yakni kebijakan A. Hasilnya adalah bahwa
Sandbox
menjadi nilai satu-satunya yang patuh untuk kunci tagCostCenter
. -
Penambahan
enforced_for
menentukan bahwa tagCostCenter
harus menjadi nilai tag yang ditentukan pada semua sumber daya Amazon Redshift dan tabel Amazon DynamoDB.
Seperti yang ditunjukkan pada diagram, OU1 termasuk dua akun: 111111111111 dan 222222222222.
Kebijakan tag efektif yang dihasilkan untuk akun 111111111111 dan 222222222222
catatan
Anda tidak dapat langsung menggunakan konten kebijakan efektif yang ditampilkan sebagai isi dari kebijakan baru. Sintaksis tidak menyertakan operator yang diperlukan untuk mengontrol penggabungan dengan kebijakan anak dan kebijakan induk lainnya. Tampilan dari sebuah kebijakan efektif dimaksudkan hanya untuk memahami hasil penggabungan.
{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Sandbox" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } }
Contoh 2: Menambahkan nilai-nilai baru untuk tag yang diwariskan
Mungkin ada kasus di mana Anda ingin semua akun di organisasi Anda menentukan kunci tag dengan daftar pendek nilai yang dapat diterima. Untuk akun di satu OU, Anda mungkin ingin mengizinkan nilai tambahan yang hanya akun tersebut dapat menentukan kapan membuat sumber daya. Contoh ini menentukan bagaimana melakukannya dengan menggunakan operator @@append
. Operator @@append
adalah fitur lanjutan.
Seperti contoh 1, contoh ini dimulai dengan kebijakan A untuk kebijakan tag akar organisasi.
Kebijakan A — Kebijakan tag akar organisasi
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }
Untuk contoh ini, lampirkan kebijakan C keOU2. Perbedaan dalam contoh ini adalah bahwa menggunakan operator @@append
dalam kebijakan C menambahkan ke, bukan menimpa, daftar nilai yang dapat diterima dan aturan enforced_for
.
Kebijakan C - kebijakan OU2 tag untuk menambahkan nilai
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@append": [ "Marketing" ] }, "enforced_for": { "@@append": [ "redshift:*", "dynamodb:table" ] } } } }
Melampirkan kebijakan C untuk OU2 memiliki efek berikut ketika kebijakan A dan kebijakan C bergabung untuk membentuk kebijakan tag efektif untuk akun:
-
Karena kebijakan C menyertakan operator
@@append
, ia memungkinkan untuk menambahkan ke, bukan menimpa, daftar nilai tag yang dapat diterima yang ditentukan dalam Kebijakan A. -
Seperti dalam kebijakan B, penambahan
enforced_for
menentukan bahwa tagCostCenter
harus digunakan sebagai nilai tag yang ditentukan pada semua sumber daya Amazon Redshift dan tabel Amazon DynamoDB. Menimpa (@@assign
) dan menambahkan (@@append
) memiliki efek yang sama jika kebijakan induk tidak menyertakan operator kontrol anak yang membatasi apa yang dapat ditentukan kebijakan anak.
Seperti yang ditunjukkan pada diagram, OU2 termasuk satu akun: 999999999999. Kebijakan A dan kebijakan C bergabung untuk membuat kebijakan tag efektif untuk akun 999999999999.
Kebijakan tag yang efektif untuk akun 999999999999
catatan
Anda tidak dapat langsung menggunakan konten kebijakan efektif yang ditampilkan sebagai isi dari kebijakan baru. Sintaksis tidak menyertakan operator yang diperlukan untuk mengontrol penggabungan dengan kebijakan anak dan kebijakan induk lainnya. Tampilan dari sebuah kebijakan efektif dimaksudkan hanya untuk memahami hasil penggabungan.
{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Development", "Support", "Marketing" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } }
Contoh 3: Hapus nilai dari tag yang diwariskan
Mungkin ada kasus di mana kebijakan tag yang dilampirkan ke organisasi mendefinisikan nilai tag lebih dari yang Anda inginkan untuk digunakan sebuah akun. Contoh ini menjelaskan cara merevisi kebijakan tag menggunakan operator @@remove
. @@remove
adalah fitur lanjutan.
Seperti contoh lainnya, contoh ini dimulai dengan kebijakan A untuk kebijakan tag akar organisasi.
Kebijakan A — Kebijakan tag akar organisasi
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }
Untuk contoh ini, lampirkan kebijakan D ke akun 999999999999.
Kebijakan D - Kebijakan tag Akun 999999999999 untuk menghapus nilai
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@remove": [ "Development", "Marketing" ], "enforced_for": { "@@remove": [ "redshift:*", "dynamodb:table" ] } } } } }
Melampirkan kebijakan D ke akun 999999999999 memiliki efek berikut ketika kebijakan A, kebijakan C, dan kebijakan D bergabung untuk membentuk kebijakan tag efektif:
-
Dengan asumsi Anda melakukan semua contoh sebelumnya, kebijakan B, C, dan C adalah kebijakan anak dari A. Kebijakan B hanya dilampirkanOU1, sehingga tidak berpengaruh pada akun 9999999999999.
-
Untuk akun 9999999999999, satu-satunya nilai yang dapat diterima untuk kunci tag
CostCenter
adalahSupport
. -
Kepatuhan tidak ditegakkan untuk kunci tag
CostCenter
.
Kebijakan tag efektif baru untuk akun 99999999999999
catatan
Anda tidak dapat langsung menggunakan konten kebijakan efektif yang ditampilkan sebagai isi dari kebijakan baru. Sintaksis tidak menyertakan operator yang diperlukan untuk mengontrol penggabungan dengan kebijakan anak dan kebijakan induk lainnya. Tampilan dari sebuah kebijakan efektif dimaksudkan hanya untuk memahami hasil penggabungan.
{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Support" ] } } }
Jika nanti Anda menambahkan lebih banyak akunOU2, kebijakan tag efektifnya akan berbeda dengan akun 999999999999. Hal itu karena kebijakan D yang lebih ketat hanya dilampirkan pada tingkat akun, dan bukan ke OU.
Contoh 4: Membatasi perubahan kebijakan anak
Mungkin ada kasus di mana Anda ingin membatasi perubahan dalam kebijakan anak. Contoh ini menjelaskan bagaimana melakukan hal itu dengan menggunakan operator kontrol anak.
Contoh ini dimulai dengan sebuah kebijakan tag akar organisasi baru dan mengasumsikan bahwa kebijakan tag belum dilampirkan ke entitas organisasi.
Kebijakan E — Kebijakan tag akar organisasi untuk membatasi perubahan kebijakan anak
{ "tags": { "project": { "tag_key": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "Project" }, "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance", "Escalations" ] } } } }
Ketika Anda melampirkan kebijakan E ke akar organisasi, kebijakan tersebut akan mencegah kebijakan anak mengubah kunci tag Project
. Namun, kebijakan anak dapat menimpa atau menambahkan nilai tag.
Misalnya Anda kemudian melampirkan kebijakan F berikut ke sebuah OU.
Kebijakan F - Kebijakan tag OU
{ "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": [ "Escalations - research" ] } } } }
Menggabungkan kebijakan E dan kebijakan F memiliki efek berikut pada akun OU:
-
Kebijakan F adalah kebijakan anak untuk Kebijakan E.
-
Kebijakan F mencoba untuk mengubah perlakuan kasus, tetapi tidak bisa. Itu karena kebijakan E menyertakan operator
"@@operators_allowed_for_child_policies": ["@@none"]
untuk kunci tag. -
Namun, kebijakan F dapat menambahkan nilai tag untuk kunci tersebut. Itu karena kebijakan E menyertakan
"@@operators_allowed_for_child_policies": ["@@append"]
untuk nilai tag.
Kebijakan efektif untuk akun di OU
catatan
Anda tidak dapat langsung menggunakan konten kebijakan efektif yang ditampilkan sebagai isi dari kebijakan baru. Sintaksis tidak menyertakan operator yang diperlukan untuk mengontrol penggabungan dengan kebijakan anak dan kebijakan induk lainnya. Tampilan dari sebuah kebijakan efektif dimaksudkan hanya untuk memahami hasil penggabungan.
{ "tags": { "project": { "tag_key": "Project", "tag_value": [ "Maintenance", "Escalations", "Escalations - research" ] } } }
Contoh 5: Konflik dengan operator kontrol anak
Operator kontrol anak dapat ada dalam kebijakan tag yang dilampirkan pada tingkat yang sama dalam hirarki organisasi. Ketika itu terjadi, persimpangan operator diizinkan digunakan ketika kebijakan bergabung untuk membentuk kebijakan efektif untuk akun.
Asumsikan kebijakan G dan kebijakan H sudah dilampirkan ke akar organisasi.
Kebijakan G - Kebijakan tag akar organisasi 1
{ "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance" ] } } } }
Kebijakan H — Kebijakan tag akar organisasi 2
{ "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append", "@@remove"] } } } }
Dalam contoh ini, satu kebijakan di akar organisasi mendefinisikan bahwa nilai untuk kunci tag saja yang dapat ditambahkan. Kebijakan lain yang dilampirkan pada akar organisasi memungkinkan kebijakan anak untuk menambahkan dan menghapus nilai. Persimpangan dua izin ini digunakan untuk kebijakan anak. Hasilnya adalah kebijakan anak dapat menambahkan nilai, tetapi tidak menghapus nilai. Oleh karena itu, kebijakan anak dapat menambahkan nilai ke daftar nilai tag tetapi tidak dapat menghapus nilai Maintenance
.
Contoh 6: Konflik dengan penambahan nilai pada tingkat hirarki yang sama
Anda dapat melampirkan beberapa kebijakan tag ke setiap entitas organisasi. Ketika Anda melakukannya, kebijakan tag yang dilampirkan ke entitas organisasi yang sama mungkin menyertakan informasi yang bertentangan. Kebijakan dievaluasi berdasarkan urutan saat mereka dilampirkan pada entitas organisasi. Untuk mengubah kebijakan mana yang dievaluasi terlebih dahulu, Anda dapat melepaskan kebijakan dan kemudian melampirkannya kembaliitu.
Asumsikan kebijakan J dilampirkan ke akar organisasi terlebih dahulu, dan kemudian kebijakan K dilampirkan ke akar organisasi.
Kebijakan J — Kebijakan tag pertama yang dilampirkan ke root organisasi
{ "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": ["Maintenance"] } } } }
Kebijakan K — Kebijakan tag kedua yang dilampirkan ke root organisasi
{ "tags": { "project": { "tag_key": { "@@assign": "project" } } } }
Dalam contoh ini, kunci tag PROJECT
digunakan dalam kebijakan tag efektif karena kebijakan itulah yang ditetapkan dilampirkan pada akar organisasi terlebih dahulu.
Kebijakan JK — Kebijakan tag efektif untuk akun
Kebijakan efektif untuk akun adalah sebagai berikut.
catatan
Anda tidak dapat langsung menggunakan konten kebijakan efektif yang ditampilkan sebagai isi dari kebijakan baru. Sintaksis tidak menyertakan operator yang diperlukan untuk mengontrol penggabungan dengan kebijakan anak dan kebijakan induk lainnya. Tampilan dari sebuah kebijakan efektif dimaksudkan hanya untuk memahami hasil penggabungan.
{ "tags": { "project": { "tag_key": "PROJECT", "tag_value": [ "Maintenance" ] } } }