Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Descripción de la herencia de políticas de administración
**importante**
La información de esta sección ***no*** se aplica a las políticas de autorización: políticas de control de servicios (SCPs) y políticas de control de recursos (RCPs). Para obtener más información sobre cómo SCPs y cómo RCPs trabajar en una AWS Organizations jerarquía, consulte [Evaluación de SCP](orgs_manage_policies_scps_evaluation.md) y[Evaluación de RCP](orgs_manage_policies_rcps_evaluation.md).
Puede asociar políticas de administración a entidades de organización (raíz de organización, unidad organizativa [OU] o cuenta) en su organización:
+ Al adjuntar una política de administración a la raíz de la organización, todas las cuentas OUs y cuentas de la organización heredan esa política.
+ Cuando asocia una política de administración a una unidad organizativa específica, las cuentas que están directamente en esa unidad organizativa o cualquier unidad organizativa secundaria heredan la política.
+ Cuando se asocia una política de administración a una cuenta específica, solo afecta a esa cuenta.
Dado que puede asociar políticas de administración a varios niveles de la organización, las cuentas pueden heredar varias políticas.
En estos temas se explica cómo se procesan las políticas principales y secundarias en la política en vigor de una cuenta.
**Topics**
+ [Terminología](inheritance-terminology.md)
+ [Tipos de políticas de administración](syntax-inheritance.md)
+ [Operadores de herencia](policy-operators.md)
+ [Ejemplos de herencia](inheritance-examples.md)
# Terminología de herencia
En este tema se utilizan los siguientes términos al analizar la herencia de políticas de administración.
**Herencia de políticas**
La interacción de políticas en distintos niveles de una organización, desplazándose desde la raíz de nivel superior de la organización, bajando por la jerarquía de unidades organizativas (OU) a cuentas individuales.
Puede adjuntar políticas a la raíz de la organización OUs, a las cuentas individuales y a cualquier combinación de estas entidades de la organización. La herencia de políticas de administración hace referencia a las políticas que se asocian a la raíz de la organización o a una unidad organizativa. Todas las cuentas que son miembros de la raíz de la organización o unidad organizativa donde se asocia una política de administración *heredan* esa política.
Por ejemplo, cuando se asocian las políticas de administración a la raíz de la organización, todas las cuentas de la organización heredan esa política. Esto se debe a que todas las cuentas de una organización siempre están bajo la raíz de la organización. Cuando asocia una política a una unidad organizativa específica, las cuentas que están directamente en esa unidad organizativa o cualquier unidad organizativa secundaria heredan esa política. Dado que puede asociar políticas a varios niveles de la organización, las cuentas pueden heredar varios documentos de políticas para un solo tipo de política.
**Políticas principales**
Políticas asociadas más alto en el árbol organizativo que las políticas asociadas a entidades más abajo en el árbol.
Por ejemplo, si asocia la política de administración A a la raíz de la organización, es solo una política. Si también asocia la política B a una unidad organizativa debajo de esa raíz, la política A es la política principal de la política B. La política B es la política secundaria de la política A. La política A y la política B se fusionan para crear la política de etiquetas en vigor para las cuentas de la unidad organizativa.
**Políticas secundarias**
Políticas asociadas a un nivel inferior en el árbol de la organización con respecto a la política principal.
**Políticas en vigor**
El documento de políticas único final que especifica las reglas que se aplican a una cuenta. La política en vigor es la agregación de cualquier política de etiquetas que herede la cuenta, además de cualquier política de etiquetas que se asocie directamente a la cuenta. Para obtener más información, consulte [Visualización de políticas de administración en vigor](orgs_manage_policies_effective.md).
**Operadores de herencia**
Operadores que controlan cómo se fusionan las políticas heredadas en una sola política efectiva. Se considera que estos operadores son una característica avanzada. Los autores de políticas experimentados pueden utilizarlas para limitar los cambios que puede realizar una política secundaria y cómo se combinan las configuraciones de las políticas. Para obtener más información, consulte [Operadores de herencia](policy-operators.md).
# Sintaxis de política y herencia para tipos de políticas de administración
La forma exacta en que las políticas afectan a las cuentas que las heredan OUs y a las que las heredan depende del tipo de política de administración que elija. Los tipos de políticas de administración incluyen:
+ [Políticas declarativas](orgs_manage_policies_declarative.md)
+ [Políticas de copia de seguridad](orgs_manage_policies_backup.md)
+ [Políticas de etiquetas](orgs_manage_policies_tag-policies.md)
+ [Políticas de aplicaciones de chat](orgs_manage_policies_chatbot.md)
+ [Políticas de exclusión de servicios de IA](orgs_manage_policies_ai-opt-out.md)
+ [Políticas de Security Hub](orgs_manage_policies_security_hub.md)
+ [Políticas fundamentales](orgs_manage_policies_bedrock.md)
+ [Políticas del Inspector](orgs_manage_policies_inspector.md)
+ [Actualice las políticas de implementación](orgs_manage_policies_upgrade_rollout.md)
+ [Políticas de S3](orgs_manage_policies_s3.md)
+ [AWS Shield Políticas del director de seguridad de red](orgs_manage_policies_network_security_director.md)
La sintaxis de los tipos de políticas de administración incluye *[Operadores de herencia](policy-operators.md)*, que permiten especificar con precisión qué elementos de las políticas principales se aplican y qué elementos se pueden anular o modificar al heredarlos los hijos OUs y las cuentas.
La *política efectiva* es el conjunto de reglas que se heredan de la raíz de la organización y OUs junto con las que se asocian directamente a la cuenta. La política en vigor especifica el conjunto de reglas final que se aplican a la cuenta. Puede ver la política en vigor de una cuenta que incluya el efecto de todos los operadores heredados en las políticas aplicadas. Para obtener más información, consulte [Visualización de políticas de administración en vigor](orgs_manage_policies_effective.md).
# Operadores de herencia
Los operadores de herencia controlan cómo se fusionan las políticas heredadas y las políticas de la cuenta con la política de etiquetas en vigor de la cuenta. Estos operadores incluyen operadores de configuración de valores y operadores de control secundarios.
Cuando utilice el editor visual de la AWS Organizations consola, solo podrá utilizar el `@@assign` operador. Se considera que los otros operadores son una característica avanzada. Para utilizar el resto operadores, debe crear manualmente la política JSON. Los autores de políticas con experiencia pueden utilizar los operadores de herencia para controlar qué valores de etiqueta se aplican a la política en vigor y limitar los cambios que pueden realizar las políticas secundarias.
Para obtener información sobre cómo funciona la herencia de políticas en una organización, consulte [Ejemplos de herencia](inheritance-examples.md).
## Operadores de configuración de valores
Puede utilizar los operadores de configuración de valores para controlar cómo interactúa la política con sus políticas principales:
+ `@@assign` – **Sobreescribe** cualquier configuración de política heredada con la configuración especificada. Si la configuración especificada no se hereda, este operador la agrega a la política en vigor. Este operador se puede aplicar a cualquier configuración de política de cualquier tipo.
+ Para la configuración de un solo valor, este operador reemplaza el valor heredado por el valor especificado.
+ Para configuraciones de valores múltiples (matrices JSON), este operador elimina los valores heredados y los reemplaza con los valores especificados por esta política.
+ `@@append` – **Agrega** la configuración especificada (sin quitar ninguna) a los heredados. Si la configuración especificada no se hereda, este operador la agrega a la política en vigor. Puede utilizar este operador solo con configuraciones de varios valores.
+ Este operador agrega los valores especificados a cualquier valor de la matriz heredada.
+ `@@remove` – **Elimina** las configuraciones heredadas especificadas de la política efectiva, si existen. Puede utilizar este operador solo con configuraciones de varios valores.
+ Este operador quita solo los valores especificados de la matriz de valores heredados de las políticas principales. Otros valores pueden continuar existiendo en la matriz y pueden ser heredados por las políticas secundarias.
## Operadores de control secundarios
El uso de operadores de control secundarios es opcional. Puede utilizar el operador `@@operators_allowed_for_child_policies` para controlar qué operadores de configuración de valores pueden utilizar las políticas secundarias. Puede permitir todos los operadores, algunos operadores específicos o ningún operador. De forma predeterminada, todos los operadores (`@@all`) están permitidos.
+ `"@@operators_allowed_for_child_policies"`: `["@@all"]` — Los niños OUs y las cuentas pueden utilizar cualquier operador en las pólizas. De forma predeterminada, todos los operadores están permitidos en las políticas secundarias.
+ `"@@operators_allowed_for_child_policies"`: `["@@assign", "@@append", "@@remove"]` — Las cuentas para niños OUs y las cuentas solo pueden usar los operadores especificados en las políticas para niños. Puede especificar uno o más operadores de configuración de valores en este operador de control secundario.
+ `"@@operators_allowed_for_child_policies"`: `["@@none"]` — Los niños OUs y las cuentas no pueden usar operadores en las políticas. Puede usar este operador para bloquear eficazmente los valores definidos en una política principal de modo que las políticas secundarias no puedan agregar, anexar o quitar esos valores.
**nota**
Si un operador de control secundario heredado limita el uso de un operador, no puede revertir esa regla en una política secundaria. Si incluye operadores de control secundarios en una política principal, limitan los operadores de configuración de valores en todas las políticas secundarias.
# Ejemplos de herencia
Estos ejemplos muestran cómo la herencia de políticas funciona al mostrar que las políticas de etiquetas principales y secundarias se fusionan en una política de etiquetas en vigor para una cuenta.
En los ejemplos se supone que tiene la estructura de organización que se muestra en el siguiente diagrama.
![\[Una organización con una cuenta raíz OUs, dos y varias cuentas.\]](http://docs.aws.amazon.com/es_es/organizations/latest/userguide/images/org-structure-inheritance.png)
**Topics**
+ [Ejemplo 1: Permitir que las políticas secundarias sobrescriban *solo* valores de etiquetas](#example-assign-operator)
+ [Ejemplo 2: Agregar nuevos valores a las etiquetas heredadas](#example-append-operator)
+ [Ejemplo 3: Eliminar los valores de etiquetas heredadas](#example-remove-operator)
+ [Ejemplo 4: Restringir los cambios en las políticas secundarias](#example-restrict-child)
+ [Ejemplo 5: Conflictos con los operadores de control secundarios](#multiple-same-node-operators)
+ [Ejemplo 6: Conflictos al anexar valores en el mismo nivel de jerarquía](#multiple-same-node-values)
## Ejemplo 1: Permitir que las políticas secundarias sobrescriban *solo* valores de etiquetas
La siguiente política de etiquetas define la clave de etiquetas `CostCenter` y dos valores aceptables, `Development` y `Support`. Si asocia una política de etiquetas a la raíz de la organización, la política de etiquetas se encuentra en vigor para todas las cuentas en la organización.
**Política A: política de etiqueta raíz de la organización**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Suponga que desea que los OU1 usuarios usen un valor de etiqueta diferente para una clave y que desea aplicar la política de etiquetas a tipos de recursos específicos. Dado que la política A no especifica qué operadores de control secundarios están permitidos, todos los operadores están permitidos. Puedes usar el `@@assign` operador y crear una política de etiquetas como la siguiente para adjuntarla OU1.
**Política B: política OU1 de etiquetas**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Sandbox"
]
},
"enforced_for": {
"@@assign": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
Al especificar el operador `@@assign` para la etiqueta, se hace lo siguiente cuando la política A y la B se fusionan para formar la *política de etiquetas en vigor* para una cuenta:
+ La política B sobrescribe los dos valores de etiquetas que se especificaron en la política principal, la política A. El resultado es que `Sandbox` es el único valor compatible para la clave de etiquetas `CostCenter`.
+ La adición de `enforced_for` especifica que la etiqueta `CostCenter` *debe* utilizar el valor de etiquetas especificado en todos los recursos de Amazon Redshift y las tablas de Amazon DynamoDB.
Como se muestra en el diagrama, OU1 incluye dos cuentas: 1111 y 222222222222.
**Política de etiquetas en vigor resultante para las cuentas 111111111111 y 222222222222**
**nota**
No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Sandbox"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Ejemplo 2: Agregar nuevos valores a las etiquetas heredadas
Puede haber casos en los que desee que todas las cuentas de su organización especifiquen una clave de etiquetas con una breve lista de valores aceptables. Para las cuentas de una unidad organizativa, es posible que desee permitir un valor adicional que solo puedan especificar esas cuentas al crear recursos. En este ejemplo se especifica cómo hacerlo mediante el operador `@@append`. El operador `@@append` es una característica avanzada.
Al igual que el ejemplo 1, este ejemplo comienza con la política A para la política de etiquetas de la raíz de la organización.
**Política A: política de etiqueta raíz de la organización**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Para este ejemplo, adjunte la política C a. OU2 La diferencia en este ejemplo es que el uso del operador `@@append` en la política C *agrega*, en lugar de sobrescribir, la lista de valores aceptables y la regla `enforced_for`.
**Política C: política de OU2 etiquetas para anexar valores**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@append": [
"Marketing"
]
},
"enforced_for": {
"@@append": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
Adjuntar la política C a OU2 tiene los siguientes efectos cuando la política A y la política C se fusionan para formar la política de etiquetas efectiva para una cuenta:
+ Dado que la política C incluye al operador `@@append`, permite *agregar*, no sobrescribir, la lista de valores de etiquetas aceptables especificados en la política A.
+ Al igual que en la política B, la adición de `enforced_for` especifica que la etiqueta `CostCenter` se debe utilizar como valor de etiquetas especificado en todos los recursos de Amazon Redshift y tablas de Amazon DynamoDB. La sobrescritura (`@@assign`) y la adición (`@@append`) tienen el mismo efecto si la política principal no incluye un operador de control secundario que restringe lo que puede especificar una política secundaria.
Como se muestra en el diagrama, OU2 incluye una cuenta: 7139999. Las políticas A y C se fusionan para crear la política de etiquetas en vigor para la cuenta 999999999999.
**Política de etiquetas en vigor para la cuenta 999999999999**
**nota**
No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Development",
"Support",
"Marketing"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Ejemplo 3: Eliminar los valores de etiquetas heredadas
Puede haber casos en los que la política de etiquetas asociada a la organización defina más valores de etiquetas de los que desea utilizar una cuenta. En este ejemplo se explica cómo revisar una política de etiquetas mediante el operador `@@remove`. `@@remove` es una característica avanzada.
Al igual que otros ejemplos, este ejemplo comienza con la política A para la política de etiquetas de la raíz de la organización.
**Política A: política de etiqueta raíz de la organización**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Para este ejemplo, asocie la política D a la cuenta 999999999999.
**Política D: política de etiqueta de la cuenta 999999999999 para eliminar valores**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@remove": [
"Development",
"Marketing"
],
"enforced_for": {
"@@remove": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
}
```
La asociación de la política D a la cuenta 999999999999 tiene los siguientes efectos cuando las políticas A, C y D se fusionan para formar la política de etiquetas en vigor:
+ Suponiendo que ha realizado todos los ejemplos anteriores, las pólizas B, C y C son políticas secundarias de A. La política B solo está vinculada a ella OU1, por lo que no afecta a la cuenta.
+ Para la cuenta 9999999999999, el único valor aceptable para la clave de etiquetas `CostCenter` es `Support`.
+ La conformidad no se aplica para la clave de etiquetas `CostCenter`.
**Nueva política de etiquetas en vigor para la cuenta 999999999999**
**nota**
No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Support"
]
}
}
}
```
Si posteriormente añades más cuentas a OU2, sus políticas de etiquetado efectivas serán diferentes a las de la cuenta 99999999. Esto se debe a que la política D más restrictiva solo se asocia a la cuenta y no a la unidad organizativa.
## Ejemplo 4: Restringir los cambios en las políticas secundarias
Puede haber casos en los que desee restringir los cambios en las políticas secundarias. En este ejemplo se explica cómo hacerlo mediante los operadores de control secundarios.
Este ejemplo comienza con una nueva política de etiquetas de la raíz de la organización y se supone que las políticas de etiquetas aún no se asocian a las entidades de la organización.
**Política E: política de etiqueta raíz de la organización para restringir los cambios en las políticas secundarias **
```
{
"tags": {
"project": {
"tag_key": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "Project"
},
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance",
"Escalations"
]
}
}
}
}
```
Cuando se asocia la política E a la raíz de la organización, la política impide que las políticas secundarias cambien la clave de la etiqueta `Project`. Sin embargo, las políticas secundarias pueden sobrescribir o anexar valores de etiquetas.
Supongamos que, a continuación, asocia la siguiente política F a una unidad organizativa.
**Política F: política de etiqueta de unidad organizativa**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": [
"Escalations - research"
]
}
}
}
}
```
La fusión de las políticas E y F tiene los siguientes efectos en las cuentas de la unidad organizativa:
+ La política F es una política secundaria de la política E.
+ La política F intenta cambiar el tratamiento del caso, pero no puede. Esto se debe a que la política E incluye el operador `"@@operators_allowed_for_child_policies": ["@@none"]` para la clave de etiqueta.
+ Sin embargo, la política F puede añadir los valores de etiquetas para la clave. Esto se debe a que la política E incluye `"@@operators_allowed_for_child_policies": ["@@append"]` para el valor de etiqueta.
**Política en vigor para las cuentas en la unidad organizativa**
**nota**
No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.
```
{
"tags": {
"project": {
"tag_key": "Project",
"tag_value": [
"Maintenance",
"Escalations",
"Escalations - research"
]
}
}
}
```
## Ejemplo 5: Conflictos con los operadores de control secundarios
Los operadores de control secundarios pueden existir en políticas de etiquetas asociadas al mismo nivel en la jerarquía de la organización. Cuando eso sucede, se utiliza la intersección de los operadores permitidos cuando las políticas se fusionan para formar la política efectiva para las cuentas.
Supongamos que las políticas G y H se asocian a la raíz de la organización.
**Política G: política de etiqueta raíz de la organización 1**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance"
]
}
}
}
}
```
**Política H: política de etiqueta raíz de la organización 2**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
}
}
}
}
```
En este ejemplo, una política en la raíz de la organización define que los valores de la clave de etiquetas solo se pueden anexar. La otra política asociada a la raíz de la organización permite que las políticas secundarias anexen y eliminen valores. La intersección de estos dos permisos se utiliza para las políticas secundarias. El resultado es que las políticas secundarias pueden anexar valores, pero no eliminar valores. Por lo tanto, la política secundaria puede anexar un valor a la lista de valores de etiquetas, pero no puede eliminar el valor `Maintenance`.
## Ejemplo 6: Conflictos al anexar valores en el mismo nivel de jerarquía
Puede asociar varias políticas de etiquetas a cada entidad de la organización. Al hacerlo, las políticas de etiqueta asociadas a la misma entidad de la organización podrían incluir información conflictiva. Las políticas se evalúan en función del orden en que se asociaron a la entidad de la organización. Para cambiar la política que se evalúa primero, puede asociar una política y, a continuación, volver a asociarla.
Supongamos que la política J se asocia primero a la raíz de la organización y, a continuación, la política K se asocia a la raíz de la organización.
**Política J: primera política de etiquetas adjunta al nodo raíz de la organización**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": ["Maintenance"]
}
}
}
}
```
**Política K: segunda política de etiquetas adjunta al nodo raíz de la organización**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "project"
}
}
}
}
```
En este ejemplo, la clave de etiquetas `PROJECT` se utiliza en la política de etiquetas en vigor porque la política que la definió se asoció primero a la raíz de la organización.
**Política JK: política de etiquetas en vigor para la cuenta**
La política en vigor para la cuenta es la siguiente.
**nota**
No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.
```
{
"tags": {
"project": {
"tag_key": "PROJECT",
"tag_value": [
"Maintenance"
]
}
}
}
```