Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beispiele für Vererbungen

In diesen Beispielen wird gezeigt, wie die Richtlinienvererbung funktioniert, indem übergeordnete und untergeordnete Tag-Richtlinien zu einer effektiven Tag-Richtlinie für ein Konto zusammengeführt werden.

Die Beispiele gehen davon aus, dass Sie die im folgenden Diagramm dargestellte Organisationsstruktur besitzen.

Beispiel 1: Zulassen, dass untergeordnete Richtlinien nur Tag-Werte überschreiben

Die folgende Tag-Richtlinie definiert den Tag-Schlüssel CostCenter und die zulässigen Werte Development und Support. Wenn Sie diese dem Organisationsstamm anhängen, gilt die Tag-Richtlinie für alle Konten in der Organisation.

Richtlinie A – Tag-Richtlinie des Organisationsstamms

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

Angenommen, Sie möchten, dass Benutzer einen anderen Tagwert für einen Schlüssel verwenden, und Sie möchten die Tag-Richtlinie für bestimmte Ressourcentypen durchsetzen. OU1 Da Richtlinie A nicht angibt, welche untergeordneten Steuerungsoperatoren zulässig sind, sind alle Operatoren zulässig. Sie können den @@assign Operator verwenden und eine Tag-Richtlinie wie die folgende erstellen, an die Sie sie anhängen möchten OU1.

Richtlinie B — OU1 Tag-Richtlinie

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Sandbox"
                ]
            },
            "enforced_for": {
                "@@assign": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

Wenn Sie den @@assign-Operator für das Tag angeben, wird bei Zusammenführung von Richtlinie A und Richtlinie B Folgendes ausgeführt, um die effektive Tag-Richtlinie für ein Konto zu bilden:

OU1 Enthält, wie im Diagramm dargestellt, zwei Konten: 111111111111 und 222222222222.

Resultierende effektive Tag-Richtlinie für die Konten 111111111111 und 222222222222

{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Sandbox"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

Beispiel 2: Geerbten Tags neue Werte hinzufügen

Es kann vorkommen, dass alle Konten in Ihrer Organisation einen Tag-Schlüssel mit einer kurzen Liste zulässiger Werte angeben sollen. Für Konten in einer OU möchten Sie möglicherweise einen zusätzlichen Wert zulassen, den nur diese Konten beim Erstellen von Ressourcen angeben können. In diesem Beispiel wird dargestellt, wie dies mithilfe des @@append-Operators durchgeführt wird. Der @@append-Operator ist ein erweitertes Feature.

Wie Beispiel 1 beginnt dieses Beispiel mit der Richtlinie A der Tag-Richtlinie des Organisationsstamms.

Richtlinie A – Tag-Richtlinie des Organisationsstamms

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

Fügen Sie für OU2 dieses Beispiel die Richtlinie C an an. Der Unterschied in diesem Beispiel besteht darin, dass die Verwendung des @@append-Operators in Richtlinie C die Liste der zulässigen Werte und die enforced_for-Regel erweitert und nicht überschreibt.

Richtlinie C — OU2 Tag-Richtlinie zum Anhängen von Werten

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@append": [
                    "Marketing"
                ]
            },
            "enforced_for": {
                "@@append": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

Das Anhängen von Richtlinie C an OU2 hat folgende Auswirkungen, wenn Richtlinie A und Richtlinie C zusammengeführt werden, um die effektive Tag-Richtlinie für ein Konto zu bilden:

OU2 Umfasst, wie im Diagramm dargestellt, ein Konto: 999999999999. Richtlinie A und Richtlinie C werden zusammengeführt, um die effektive Tag-Richtlinie für das Konto 999999999999 zu bilden.

Effektive Tag-Richtlinie für Konto 999999999999

{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Development",
                "Support",
                "Marketing"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

Beispiel 3: Entfernen von Werten aus geerbten Tags

Es kann Fälle geben, in denen die Tag-Richtlinie, die der Organisation hinzugefügt ist, mehr Tag-Werte definiert, als ein Konto verwenden soll. In diesem Beispiel wird erläutert, wie eine Tag-Richtlinie mit dem Operator @@remove überarbeitet wird. @@remove ist ein erweitertes Feature.

Wie in den anderen Beispielen beginnt dieses Beispiel mit Richtlinie A der Tag-Richtlinie des Organisationsstamms.

Richtlinie A – Tag-Richtlinie des Organisationsstamms

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

In diesem Beispiel fügen Sie dem Konto 999999999999 Richtlinie D hinzu.

Richtlinie D – Tag-Richtlinie für Konto 999999999999 zum Entfernen von Werten

{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@remove": [
                    "Development",
                    "Marketing"
                ],
                "enforced_for": {
                    "@@remove": [
                        "redshift:*",
                        "dynamodb:table"
                    ]
                }
            }
        }
    }
}

Das Anfügen von Richtlinie D an Konto 999999999999 hat folgende Auswirkungen, wenn Richtlinie A, Richtlinie C und Richtlinie D zusammengeführt werden, um die effektive Tag-Richtlinie zu bilden:

Neue effektive Tag-Richtlinie für Konto 999999999999

{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Support"
            ]
        }
    }
}

Wenn Sie später weitere Konten hinzufügen würden OU2, würden sich deren effektive Tag-Richtlinien von denen für das Konto 999999999999 unterscheiden. Das liegt daran, weil die restriktivere Richtlinie D nur auf Kontoebene und nicht der OU hinzugefügt ist.

Beispiel 4: Änderungen an untergeordneten Richtlinien einschränken

Es kann vorkommen, dass Sie Änderungen in untergeordneten Richtlinien einschränken möchten. In diesem Beispiel wird erläutert, wie dies mit untergeordneten Steuerungsoperatoren durchgeführt wird.

Dieses Beispiel beginnt mit einer neuen Tag-Richtlinie des Organisationsstamms und setzt voraus, dass Organisations-Entitäten noch keine Tag-Richtlinien hinzugefügt wurden.

Richtlinie E – Tag-Richtlinie des Organisationsstamms zum Einschränken von Änderungen in untergeordneten Richtlinien

{
    "tags": {
        "project": {
            "tag_key": {
                "@@operators_allowed_for_child_policies": ["@@none"],
                "@@assign": "Project"
            },
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance",
                    "Escalations"
                ]
            }
        }
    }
}

Wenn Sie Richtlinie E an den Organisationsstamm anfügen, verhindert die Richtlinie, dass untergeordnete Richtlinien den Project-Tag-Schlüssel ändern. Untergeordnete Richtlinien können jedoch Tag-Werte überschreiben oder hinzufügen.

Angenommen, Sie fügen eine OU der folgende Richtlinie F hinzu.

Richtlinie F – OU-Tag-Richtlinie

{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "PROJECT"
            },
            "tag_value": {
                "@@append": [
                    "Escalations - research"
                ]
            }
        }
    }
}

Die Zusammenführung der Richtlinien E und F hat folgende Auswirkungen auf die Konten der OU:

Effektive Richtlinie für Konten in der OU

{
    "tags": {
        "project": {
            "tag_key": "Project",
            "tag_value": [
                "Maintenance",
                "Escalations",
                "Escalations - research"
            ]
        }
    }
}

Beispiel 5: Konflikte mit untergeordneten Steuerungsoperatoren

Untergeordnete Steuerungsoperatoren können in Tag-Richtlinien vorhanden sein, die auf derselben Ebene in der Organisationshierarchie hinzugefügt sind. In diesem Fall wird bei Zusammenführung der Richtlinien der Schnittmenge der zulässigen Operatoren verwendet, um die effektive Richtlinie für Konten zu bilden.

Angenommen, Richtlinien G und H sind dem Organisationsstamm hinzugefügt.

Richtlinie G – Tag-Richtlinie 1 des Organisationsstamms

{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance"
                ]
            }
        }
    }
}

Richtlinie H – Tag-Richtlinie 2 des Organisationsstamms

{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
            }
        }
    }
}

In diesem Beispiel definiert eine Richtlinie am Organisationsstamm, dass die Werte für den Tag-Schlüssel nur angehängt werden können. Mithilfe der anderen, dem Organisationsstamm angehängten Richtlinie können untergeordnete Richtlinien Werte anhängen und entfernen. Die Schnittmenge dieser beiden Berechtigungen wird für untergeordnete Richtlinien verwendet. Im Ergebnis können untergeordnete Richtlinien Werte hinzufügen, jedoch keine Werte entfernen. Daher kann die untergeordnete Richtlinie der Liste der Tag-Werte einen Wert hinzufügen, den Maintenance-Wert jedoch nicht entfernen.

Beispiel 6: Konflikte mit dem Anhängen von Werten auf derselben Hierarchieebene

Sie können jeder Organisations-Entität mehrere Tag-Richtlinien hinzufügen. Wenn Sie dies tun, können die Tag-Richtlinien, die derselben Organisations-Entität angefügt wurden, widersprüchliche Informationen enthalten. Richtlinien werden basierend auf der Reihenfolge, in der sie der Organisations-Entität hinzugefügt wurden, ausgewertet. Um zu ändern, welche Richtlinie zuerst ausgewertet wird, können Sie eine Richtlinie trennen und dann erneut hinzufügen.

Angenommen, Richtlinie J wurde als erste dem Organisationsstamm hinzugefügt, und anschließend Richtlinie K.

Richtlinie J – Erste dem Organisationsstamm hinzugefügte Tag-Richtlinie

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

Richtlinie K – Zweite dem Organisationsstamm hinzugefügte Tag-Richtlinie

{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "project"
            }
        }
    }
}

In diesem Beispiel wird der Tag-Schlüssel PROJECT in der effektiven Tag-Richtlinie verwendet, da die sie definierende Richtlinie zuerst dem Organisationsstamm hinzugefügt wurde.

Richtlinie JK – Effektive Tag-Richtlinie des Kontos

Die effektive Richtlinie des Kontos lautet wie folgt.

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