Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Comprendere l'ereditarietà delle policy di gestione
**Importante**
Le informazioni contenute in questa sezione ***non*** si applicano alle politiche di autorizzazione: politiche di controllo del servizio (SCPs) e politiche di controllo delle risorse (RCPs). Per ulteriori informazioni su come SCPs e come RCPs lavorare in una AWS Organizations gerarchia, vedere [Valutazione SCP](orgs_manage_policies_scps_evaluation.md) e[Valutazione RCP](orgs_manage_policies_rcps_evaluation.md).
Puoi collegare le policy di gestione alle entità dell'organizzazione, ovvero root dell'organizzazione, unità organizzativa (UO) o account, all'interno dell'organizzazione:
+ Quando si associa una politica di gestione alla radice dell'organizzazione, tutti OUs e gli account dell'organizzazione ereditano tale politica.
+ Quando colleghi una policy di gestione a un'unità organizzativa specifica, gli account che si trovano direttamente sotto tale unità organizzativa o qualsiasi unità organizzativa figlio ereditano la policy.
+ Quando colleghi una policy di gestione a un account specifico, essa influisce solo su tale account.
Poiché è possibile associare policy di gestione a più livelli nell'organizzazione, gli account possono ereditare più policy.
I seguenti argomenti spiegano come le politiche relative ai genitori e alle politiche relative ai figli vengono trasformate in politiche efficaci per un account.
**Topics**
+ [Terminologia](inheritance-terminology.md)
+ [Tipi di policy di gestione](syntax-inheritance.md)
+ [Operatori di ereditarietà](policy-operators.md)
+ [Esempi di ereditarietà](inheritance-examples.md)
# Terminologia dell'ereditarietà
Quando si discute dell'ereditarietà delle policy di gestione, in questo argomento vengono utilizzati i termini seguenti.
**Ereditarietà delle policy**
Interazione dei criteri a diversi livelli di un'organizzazione, passando dalla root di livello superiore dell'organizzazione e procedendo verso il basso attraverso la gerarchia delle unità organizzative (OU) fino ai singoli account.
È possibile allegare le politiche alla radice dell'organizzazione OUs, ai singoli account e a qualsiasi combinazione di queste entità organizzative. L'ereditarietà delle policy si riferisce alle policy di gestione collegate alla root dell'organizzazione o a un'unità organizzativa. Tutti gli account che appartengono alla root dell'organizzazione o all'unità organizzativa a cui è collegata una policy di gestione *ereditano* tale policy.
Ad esempio, quando le policy di gestione sono collegate alla root dell'organizzazione, tale policy viene ereditata da tutti gli account dell'organizzazione. Questo perché tutti gli account di un'organizzazione si trovano sempre sotto la root dell'organizzazione. Quando associ una policy a un'unità organizzativa specifica, gli account direttamente sotto l'unità organizzativa o qualsiasi unità organizzativa figlio ereditano tale policy. Poiché è possibile collegare le policy a più livelli nell'organizzazione, gli account potrebbero ereditare più documenti di policy per un singolo tipo di policy.
**Policy padre**
Nell'albero dell'organizzazione sono le policy collegate a un livello più alto rispetto alle policy collegate alle entità inferiori dell'albero.
Ad esempio, se colleghi la policy di gestione A alla root dell'organizzazione, parliamo semplicemente di una policy. Se a un'unità organizzativa sotto tale root associ anche la policy B, la policy A è la policy padre della policy B. La policy B è la policy figlio della policy A. La policy A e la policy B si uniscono per creare la policy di tag operativa per gli account nell'unità organizzativa.
**Policy figlio**
Nell'albero dell'organizzazione sono le policy collegate a un livello inferiore rispetto alla policy padre.
**Policy operative**
Il singolo documento di policy finale che specifica le regole applicabili a un account. La policy operativa è l'aggregazione di tutte le policy ereditate dall'account, oltre a qualsiasi policy collegata direttamente all'account. Per ulteriori informazioni, consulta [Visualizzazione di politiche di gestione efficaci](orgs_manage_policies_effective.md).
**Operatori di ereditarietà**
Operatori che controllano il modo in cui le policy ereditate si uniscono in un'unica policy operativa. Questi operatori costituiscono una funzionalità avanzata. Gli autori di policy esperti possono utilizzarli per limitare le modifiche apportate da una policy figlio e la modalità di unione delle impostazioni nelle policy. Per ulteriori informazioni, consulta [Operatori di ereditarietà](policy-operators.md).
# Sintassi della policy ed ereditarietà per i tipi di policy di gestione
L' OUs esatto modo in cui le politiche influiscono sugli account che le ereditano dipende dal tipo di politica di gestione scelto. I tipi di policy di gestione includono:
+ [Policy dichiarative](orgs_manage_policies_declarative.md)
+ [Policy di backup](orgs_manage_policies_backup.md)
+ [Policy di tag](orgs_manage_policies_tag-policies.md)
+ [Politiche relative alle applicazioni di chat](orgs_manage_policies_chatbot.md)
+ [Politiche di disattivazione dei servizi di intelligenza artificiale](orgs_manage_policies_ai-opt-out.md)
+ [Politiche del Security Hub](orgs_manage_policies_security_hub.md)
+ [Politiche di base](orgs_manage_policies_bedrock.md)
+ [Politiche di Inspector](orgs_manage_policies_inspector.md)
+ [Aggiorna le politiche di implementazione](orgs_manage_policies_upgrade_rollout.md)
+ [Politiche S3](orgs_manage_policies_s3.md)
+ [AWS Shield Politiche di Network Security Director](orgs_manage_policies_network_security_director.md)
La sintassi per i tipi di policy di gestione include *[Operatori di ereditarietà](policy-operators.md)*, che consente di specificare con grande granularità quali elementi delle policy principali vengono applicati e quali elementi possono essere sovrascritti o modificati se ereditati dal figlio e dagli account. OUs
La *politica efficace* è l'insieme di regole ereditate dalla radice dell'organizzazione e OUs insieme a quelle direttamente collegate all'account. La policy effettiva specifica l'insieme finale di regole applicabili all'account. Puoi visualizzare la policy operativa per un account, che include l'effetto di tutti gli operatori di ereditarietà nelle policy applicate. Per ulteriori informazioni, consulta [Visualizzazione di politiche di gestione efficaci](orgs_manage_policies_effective.md).
# Operatori di ereditarietà
Gli operatori di ereditarietà controllano il modo in cui le policy ereditate e le policy dell'account si uniscono nella policy operativa dell'account. Tali operatori comprendono gli operatori di impostazione del valore e gli operatori del controllo degli elementi figlio.
Quando si utilizza l'editor visivo nella AWS Organizations console, è possibile utilizzare solo l'`@@assign`operatore. Altri operatori costituiscono una funzionalità avanzata. Per utilizzare gli altri operatori, è necessario creare manualmente la policy JSON. Gli autori esperti di policy possono utilizzare gli operatori di ereditarietà per controllare quali valori vengono applicati alla policy operativa e limitare le modifiche che le policy figlio possono apportare.
Per informazioni su come funziona l'ereditarietà delle politiche in un'organizzazione, vedere. [Esempi di ereditarietà](inheritance-examples.md)
## Operatori di impostazione del valore
È possibile utilizzare gli operatori di impostazione del valore per controllare il modo in cui la policy interagisce con le policy padre:
+ `@@assign` - **Sovrascrive** le impostazioni delle policy ereditate con le impostazioni specificate. Se l'impostazione specificata non è ereditata, questo operatore la aggiunge alla policy operativa. Questo operatore può essere applicato a un'impostazione di policy di qualsiasi tipo.
+ Per le impostazioni a valore singolo, questo operatore sostituisce il valore ereditato con il valore specificato.
+ Per le impostazioni con più valori (array JSON), questo operatore rimuove eventuali valori ereditati e li sostituisce con i valori specificati da questa policy.
+ `@@append` - **Aggiunge** le impostazioni specificate (senza rimuoverne nessuna) a quelle ereditate. Se l'impostazione specificata non è ereditata, questo operatore la aggiunge alla policy operativa. Puoi utilizzare questo operatore solo con impostazioni con più valori.
+ Questo operatore aggiunge i valori specificati a qualsiasi valore nell'array ereditato.
+ `@@remove` - **Rimuove** le impostazioni ereditate specificate dalla policy effettiva, se esistono. Puoi utilizzare questo operatore solo con impostazioni con più valori.
+ Questo operatore rimuove solo i valori specificati dall'array di valori ereditati dalle policy padre. Altri valori possono continuare a esistere nell'array e possono essere ereditati dalle policy figlio.
## Operatori di controllo figlio
L'utilizzo degli operatori di controllo figlio è facoltativo. È possibile utilizzare l'operatore `@@operators_allowed_for_child_policies` per controllare quali operatori di impostazione del valore possono utilizzare le policy di tag figlio. Puoi consentire tutti gli operatori, alcuni operatori specifici o nessun operatore. Per impostazione predefinita, tutti gli operatori (`@@all`) sono consentiti.
+ `"@@operators_allowed_for_child_policies"`: `["@@all"]` — I bambini OUs e gli account possono utilizzare qualsiasi operatore nelle politiche. Per impostazione predefinita, tutti gli operatori sono consentiti nelle policy figlio.
+ `"@@operators_allowed_for_child_policies"`: `["@@assign", "@@append", "@@remove"]` — I bambini OUs e gli account possono utilizzare solo gli operatori specificati nelle politiche per bambini. Puoi specificare uno o più operatori di impostazione del valore in questo operatore di controllo figlio.
+ `"@@operators_allowed_for_child_policies"`: `["@@none"]` — I bambini OUs e gli account non possono utilizzare gli operatori nelle politiche. Puoi utilizzare questo operatore per bloccare efficacemente i valori definiti in una policy padre in modo che le policy figlio non possano aggiungere, integrare o rimuovere tali valori.
**Nota**
Se un operatore di controllo figlio ereditato limita l'utilizzo di un operatore, non è possibile invertire tale regola in una policy figlio. Se includi operatori di controllo figlio in una policy padre, essi limitano gli operatori di impostazione del valore in tutti le policy figlio.
# Esempi di ereditarietà
Questi esempi mostrano come funziona l'ereditarietà della policy mostrando come le policy di tag padre e figlio vengono unite in una policy di tag operativa di un account.
Gli esempi presuppongono che la struttura dell'organizzazione sia quella mostrata nel diagramma seguente.
![\[Un'organizzazione con un account principale OUs, due e diversi account.\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/org-structure-inheritance.png)
**Topics**
+ [Esempio 1: consente alle policy figlio di sovrascrivere *solo* i valori dei tag](#example-assign-operator)
+ [Esempio 2: aggiungere nuovi valori ai tag ereditati](#example-append-operator)
+ [Esempio 3: rimuovere i valori dai tag ereditati](#example-remove-operator)
+ [Esempio 4: limitare le modifiche alle policy figlio](#example-restrict-child)
+ [Esempio 5: conflitti con gli operatori di controllo figlio](#multiple-same-node-operators)
+ [Esempio 6: conflitti con l'aggiunta di valori allo stesso livello di gerarchia](#multiple-same-node-values)
## Esempio 1: consente alle policy figlio di sovrascrivere *solo* i valori dei tag
La seguente policy di tag definisce la chiave di tag `CostCenter` e due valori ammissibili, `Development` e `Support`. Se la si collega alla radice dell'organizzazione, la policy di tag è attiva per tutti gli account dell'organizzazione.
**Policy A – Policy di tag del root dell'organizzazione**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Si supponga che si desideri che gli utenti utilizzino un valore di tag diverso per una chiave e che si desideri applicare la politica dei tag per tipi di risorse specifici. OU1 Poiché la policy A non specifica quali operatori di controllo figlio sono consentiti, tutti gli operatori sono consentiti. È possibile utilizzare l'`@@assign`operatore e creare una politica di tag come la seguente a cui allegare OU1.
**Politica B: politica dei OU1 tag**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Sandbox"
]
},
"enforced_for": {
"@@assign": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
Specificando l'operatore `@@assign` per il tag, quando la policy A e la policy B si uniscono per formare la *policy di tag operativa* per un account:
+ La policy B sovrascrive i due valori di tag specificati nella policy padre, la policy A. Il risultato è che `Sandbox` è l'unico valore ammissibile per la chiave di tag `CostCenter`.
+ L'aggiunta di `enforced_for` specifica che il tag `CostCenter` *deve* essere il valore di tag specificato su tutte le risorse Amazon Redshift e le tabelle Amazon DynamoDB.
Come mostrato nel diagramma, OU1 include due account: 1111 e 222222222222.
**Policy di tag operativa risultante per gli account 111111111111 e 222222222222.**
**Nota**
Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Sandbox"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Esempio 2: aggiungere nuovi valori ai tag ereditati
In alcuni casi si desidera che tutti gli account dell'organizzazione specifichino una chiave di tag con un breve elenco di valori accettabili. Per gli account di un'unità organizzativa, puoi consentire un valore aggiuntivo che solo tali account possono specificare durante la creazione di risorse. Questo esempio specifica come eseguire questa operazione utilizzando l'operatore `@@append`. L'operatore `@@append` è una caratteristica avanzata.
Come l'esempio 1, questo esempio inizia con la policy A per la policy del tag root dell'organizzazione.
**Policy A – Policy di tag del root dell'organizzazione**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
Per questo esempio, allega il criterio C a. OU2 La differenza in questo esempio consiste nel fatto che l'utilizzo dell'operatore `@@append` nella policy C *aggiunge*, anziché sovrascrivere, l'elenco dei valori accettabili e la regola `enforced_for`.
**Policy C: politica di OU2 tag per l'aggiunta di valori**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@append": [
"Marketing"
]
},
"enforced_for": {
"@@append": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
```
L'associazione della politica C a OU2 ha i seguenti effetti quando la politica A e la politica C si uniscono per formare la politica di tag efficace per un account:
+ Poiché la policy C include l'operatore `@@append`, consente di *aggiungere*, non sovrascrivere, l'elenco dei valori di tag accettabili specificati nella policy A.
+ Come nella policy B, l'aggiunta di `enforced_for` specifica che il tag `CostCenter` deve essere utilizzato come valore di tag specificato su tutte le risorse Amazon Redshift e le tabelle Amazon DynamoDB. La sovrascrittura (`@@assign`) e l'aggiunta (`@@append`) hanno lo stesso effetto se la policy padre non include un operatore di controllo figlio che limita ciò che una policy figlio può specificare.
Come mostrato nel diagramma, OU2 include un account: 9999. Le policy A e C si uniscono per creare la policy di tag operativa per l'account 999999999999.
**Policy di tag operativa per l'account 999999999999**
**Nota**
Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Development",
"Support",
"Marketing"
],
"enforced_for": [
"redshift:*",
"dynamodb:table"
]
}
}
}
```
## Esempio 3: rimuovere i valori dai tag ereditati
In alcuni casi, la policy di tag collegata all'organizzazione definisce più valori di tag di quelli che si desidera vengano utilizzati da un account. In questo esempio viene illustrato come modificare una policy di tag utilizzando l'operatore `@@remove`. `@@remove` è una caratteristica avanzata.
Come gli altri esempi, anche questo esempio inizia con la policy A per la policy di tag root dell'organizzazione.
**Policy A – Policy di tag del root dell'organizzazione**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"Development",
"Support"
]
}
}
}
}
```
In questo esempio, collega la policy D all'account 999999999999.
**Policy D – Policy di tag dell'account 999999999999 per la rimozione divalori**
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@remove": [
"Development",
"Marketing"
],
"enforced_for": {
"@@remove": [
"redshift:*",
"dynamodb:table"
]
}
}
}
}
}
```
L'associazione della policy D all'account 999999999999 ha i seguenti effetti quando le policy A, C e D si uniscono per formare la policy di tag operativa:
+ Supponendo che siano stati eseguiti tutti gli esempi precedenti, i criteri B, C e C sono criteri secondari di A. I criteri B sono associati solo a OU1, quindi non ha alcun effetto sull'account 99999.
+ Per l'account 9999999999999, l'unico valore accettabile per la chiave di tag `CostCenter` è `Support`.
+ La conformità non viene applicata per la chiave di tag `CostCenter`.
**Nuova policy di tag operativa per l'account 999999999999**
**Nota**
Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione.
```
{
"tags": {
"costcenter": {
"tag_key": "CostCenter",
"tag_value": [
"Support"
]
}
}
}
```
Se in seguito aggiungessi altri account OU2, le loro politiche di tag efficaci sarebbero diverse da quelle per l'account 9999. Questo perché la policy D più restrittiva è collegata solo a livello di account e non all'unità organizzativa.
## Esempio 4: limitare le modifiche alle policy figlio
Ci possono essere casi in cui vuoi limitare le modifiche nelle policy figlio. Questo esempio spiega come eseguire questa operazione utilizzando gli operatori di controllo figlio.
Questo esempio inizia con una nuova policy di tag root dell'organizzazione e presuppone che le policy di tag non siano ancora collegate alle entità dell'organizzazione.
**Policy E - Policy di tag root dell'organizzazione per limitare le modifiche nelle policy figlio**
```
{
"tags": {
"project": {
"tag_key": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "Project"
},
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance",
"Escalations"
]
}
}
}
}
```
Quando associ la policy E alla root dell'organizzazione, questa impedisce alle policy figlio di modificare la chiave del tag `Project`. Tuttavia, le policy figlio possono sovrascrivere o aggiungere valori di tag.
Supponi quindi di associare la seguente policy F a un'unità organizzativa.
**Policy F – Policy di tag dell'unità organizzativa**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": [
"Escalations - research"
]
}
}
}
}
```
L'unione della policy E e della policy F ha i seguenti effetti sugli account dell'unità organizzativa:
+ La policy F è una policy figlio per la policy E.
+ La policy F tenta di cambiare il trattamento lettere maiuscole o minuscole, ma non può. Questo perché la policy E include l'operatore `"@@operators_allowed_for_child_policies": ["@@none"]` per la chiave di tag.
+ Tuttavia, la policy F può aggiungere valori di tag per la chiave. Questo perché la policy E include `"@@operators_allowed_for_child_policies": ["@@append"]` per il valore del tag.
**Policy operativa per gli account nell'unità organizzativa**
**Nota**
Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione.
```
{
"tags": {
"project": {
"tag_key": "Project",
"tag_value": [
"Maintenance",
"Escalations",
"Escalations - research"
]
}
}
}
```
## Esempio 5: conflitti con gli operatori di controllo figlio
Gli operatori di controllo figlio possono esistere nelle policy di tag collegate allo stesso livello nella gerarchia organizzativa. In questo caso, l'intersezione degli operatori consentiti viene utilizzata quando le policy si uniscono per formare la policy operativa per gli account.
Supponi che le policy G e H siano collegate alla root dell'organizzazione.
**Policy G – Policy di tag del root dell'organizzazione 1**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append"],
"@@assign": [
"Maintenance"
]
}
}
}
}
```
**Policy H – Policy di tag del root dell'organizzazione 2**
```
{
"tags": {
"project": {
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
}
}
}
}
```
In questo esempio, una policy nella root dell'organizzazione definisce che i valori per la chiave di tag possono solo essere aggiunti. L'altra policy collegata alla root dell'organizzazione consente alle policy figlio di aggiungere e rimuovere valori. L'intersezione di queste due autorizzazioni viene utilizzata per le policy figlio. Il risultato è che le policy figlio possono aggiungere valori, ma non rimuovere valori. Pertanto, la policy figlio può aggiungere un valore all'elenco dei valori di tag, ma non può rimuovere il valore `Maintenance`.
## Esempio 6: conflitti con l'aggiunta di valori allo stesso livello di gerarchia
Puoi collegare più policy di tag a ciascuna entità dell'organizzazione. Quando si esegue questa operazione, le policy di tag collegate alla stessa entità dell'organizzazione possono includere informazioni in conflitto. Le policy vengono valutate in base all'ordine in cui sono state associate all'entità dell'organizzazione. Per modificare l'ordine di valutazione delle policy, puoi scollegare e ricollegare una policy.
Supponi che la policy J sia collegata alla root dell'organizzazione e che poi la policy K venga collegata alla root dell'organizzazione.
**Policy J – Prima policy di tag collegata al root dell'organizzazione**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "PROJECT"
},
"tag_value": {
"@@append": ["Maintenance"]
}
}
}
}
```
**Policy K – Seconda policy di tag collegata al root dell'organizzazione**
```
{
"tags": {
"project": {
"tag_key": {
"@@assign": "project"
}
}
}
}
```
In questo esempio, la chiave di tag `PROJECT` viene utilizzata nella policy di tag operativa perché la policy che l'ha definita è stata collegata per prima alla root dell'organizzazione.
**Policy JK – Policy di tag effettiva per l'account**
La policy operativa per l'account è la seguente.
**Nota**
Non è possibile utilizzare direttamente il contenuto di una policy effettiva visualizzata come contenuto di una nuova policy. La sintassi non include gli operatori necessari per controllare l'unione con altre policy figlie e padri. La presentazione della policy efficace serve unicamente per comprendere i risultati della fusione.
```
{
"tags": {
"project": {
"tag_key": "PROJECT",
"tag_value": [
"Maintenance"
]
}
}
}
```