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

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 tag CostCenter.
Penambahan enforced_for menentukan bahwa tag CostCenter 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 tag CostCenter 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


{
    "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 adalah Support.
Kepatuhan tidak ditegakkan untuk kunci tag CostCenter.

Kebijakan tag efektif baru untuk akun 99999999999999

catatan


{
    "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


{
    "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


{
    "tags": {
        "project": {
            "tag_key": "PROJECT",
            "tag_value": [
                "Maintenance"
            ]
        }
    }
}

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Operator pewarisan

Kebijakan berhenti berlangganan layanan AI