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à.
# Politiche di gestione in AWS Organizations
Le politiche di gestione consentono di configurare e gestire centralmente Servizi AWS e le relative funzionalità. Il OUs modo in cui tali politiche influiscono sugli account che le ereditano dipende dal tipo di politica di gestione a AWS Organizations cui si applica. Consulta gli argomenti di questa sezione per saperne di più sui termini e sui concetti pertinenti relativi alle policy di gestione.
**Topics**
+ [Prerequisiti e autorizzazioni](orgs_manage_policies_prereqs.md)
+ [Informazioni sull'ereditarietà delle policy](orgs_manage_policies_inheritance_mgmt.md)
+ [Visualizzazione delle politiche efficaci](orgs_manage_policies_effective.md)
+ [Avvisi relativi alle politiche non validi](invalid-policy-alerts.md)
+ [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)
+ [Policy di rifiuto dei servizi di IA](orgs_manage_policies_ai-opt-out.md)
+ [Politiche del Security Hub](orgs_manage_policies_security_hub.md)
+ [Politiche di Amazon Bedrock](orgs_manage_policies_bedrock.md)
+ [Politiche di Amazon Inspector](orgs_manage_policies_inspector.md)
+ [Aggiorna le politiche di implementazione](orgs_manage_policies_upgrade_rollout.md)
+ [Politiche di Amazon S3](orgs_manage_policies_s3.md)
+ [AWS Shield Politiche di Network Security Director](orgs_manage_policies_network_security_director.md)
# Prerequisiti e autorizzazioni per le politiche di gestione per AWS Organizations
Questa pagina descrive i prerequisiti e le autorizzazioni richieste per le politiche di gestione per. AWS Organizations
**Topics**
+ [Prerequisiti per le politiche di gestione](#manage-policies-prereqs-overview)
+ [Autorizzazioni per le politiche di gestione](#manage-policies-permissions)
## Prerequisiti per le politiche di gestione
L'utilizzo delle politiche di gestione per un'organizzazione richiede quanto segue:
+ L'organizzazione deve avere [tutte le caratteristiche abilitate](orgs_manage_org_support-all-features.md).
+ È necessario accedere all'account di gestione dell'organizzazione o essere un amministratore delegato.
+ Il tuo utente o ruolo AWS Identity and Access Management (IAM) deve disporre delle autorizzazioni elencate nella sezione seguente.
## Autorizzazioni per le politiche di gestione
Il seguente esempio di politica IAM fornisce le autorizzazioni per utilizzare tutti gli aspetti delle politiche di gestione in un'organizzazione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "OrganizationPolicies",
"Effect": "Allow",
"Action": [
"organizations:AttachPolicy",
"organizations:CreatePolicy",
"organizations:DeletePolicy",
"organizations:DescribeAccount",
"organizations:DescribeCreateAccountStatus",
"organizations:DescribeEffectivePolicy",
"organizations:DescribeOrganization",
"organizations:DescribeOrganizationalUnit",
"organizations:DescribePolicy",
"organizations:DetachPolicy",
"organizations:DisableAWSServiceAccess",
"organizations:DisablePolicyType",
"organizations:EnableAWSServiceAccess",
"organizations:EnablePolicyType",
"organizations:ListAccounts",
"organizations:ListAccountsForParent",
"organizations:ListAWSServiceAccessForOrganization",
"organizations:ListCreateAccountStatus",
"organizations:ListOrganizationalUnitsForParent",
"organizations:ListParents",
"organizations:ListPolicies",
"organizations:ListPoliciesForTarget",
"organizations:ListRoots",
"organizations:ListTargetsForPolicy",
"organizations:UpdatePolicy"
],
"Resource": "*"
}
]
}
```
------
Per ulteriori informazioni su policy e autorizzazioni IAM, consulta la [Guida per l'utente di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/).
# 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"
]
}
}
}
```
# Visualizzazione di politiche di gestione efficaci
Determina la politica di gestione efficace per un account nella tua organizzazione.
## Cos'è una politica di gestione efficace?
La *politica efficace* specifica le regole finali che si applicano a un tipo Account AWS di politica di gestione. È l'aggregazione di una politica di gestione che l'account eredita, più tutte le politiche per quel tipo di politica di gestione che sono direttamente collegate all'account. Quando si allega una politica di gestione alla radice dell'organizzazione, questa si applica a tutti gli account dell'organizzazione. Quando si allega una politica di gestione a un'unità organizzativa (OU), questa si applica a tutti gli account OUs che appartengono all'unità organizzativa. Quando si allega una politica di gestione direttamente a un account, questa si applica solo a quell'account. Account AWS
Per informazioni su come le policy vengono combinate nella policy effettiva finale, consulta [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md).
**Esempio di policy di Backup**
La policy di backup allegata alla cartella principale dell'organizzazione potrebbe specificare che tutti gli account dell'organizzazione eseguano il backup di tutte le tabelle Amazon DynamoDB con una frequenza di backup predefinita di una volta alla settimana. Una policy di backup separata collegata direttamente a un account membro con informazioni critiche in una tabella può sovrascrivere la frequenza con un valore di una volta al giorno. La combinazione di queste policy di backup comprende la policy di backup effettiva. Questa policy di backup effettiva è determinata individualmente per ogni account nell'organizzazione. In questo esempio, il risultato è che tutti gli account dell'organizzazione eseguono il backup delle tabelle DynamoDB una volta alla settimana, ad eccezione di un account che esegue il backup delle tabelle ogni giorno.
**Esempio di politica dei tag**
La politica dei tag allegata alla radice dell'organizzazione potrebbe definire un `CostCenter` tag con quattro valori conformi. Una policy di tag separata collegata all'account può limitare la chiave `CostCenter` a soli due dei quattro valori conformi. La combinazione di queste policy di tag costituisce la policy di tag operativa. Il risultato è che solo due dei quattro valori di tag conformi definiti nella policy del tag root dell'organizzazione sono conformi per l'account.
**Esempio di policy sulle applicazioni di chat**
Amazon Q Developer nelle applicazioni di chat rivaluterà le configurazioni di applicazioni di chat Amazon Q Developer in chat create in precedenza rispetto alle politiche effettive delle applicazioni di chat e negherà qualsiasi azione precedentemente consentita se è coerente con le impostazioni e i limiti consentiti nella politica effettiva. La politica efficace per un account membro definisce le impostazioni e i guardrail consentiti. Ad esempio, se a un account membro viene applicata una policy per le applicazioni di chat con negazione dell'accesso ai canali Slack pubblici, lo sviluppatore Amazon Q esistente nelle configurazioni delle applicazioni di chat per i canali Slack pubblici nell'account membro verrà disabilitato. Le applicazioni di chat di Amazon Q Developer non invieranno notifiche e i membri del canale non saranno in grado di eseguire alcuna attività nel canale bloccato. La console delle applicazioni di chat di Amazon Q Developer contrassegnerà i canali interessati come disabilitati con accanto un messaggio di errore appropriato.
**Esempio di disattivazione dei servizi AI**
La politica di disattivazione dei servizi di intelligenza artificiale allegata alla cartella principale dell'organizzazione potrebbe specificare che tutti gli account dell'organizzazione disattivino l'uso dei contenuti da parte di tutti i servizi di apprendimento AWS automatico. Una policy separata di rifiuto dei servizi di IA collegata direttamente a un account membro specifica che consente di utilizzare il contenuto solo per Amazon Rekognition. La combinazione di queste policy di rifiuto dei servizi di IA costituisce la policy di rifiuto dei servizi di IA effettiva. Il risultato è che tutti gli account dell'organizzazione vengono esclusi da tutti Servizi AWS, ad eccezione di un account che attiva Amazon Rekognition.
## Come visualizzare la politica di gestione efficace
È possibile visualizzare la politica efficace di un tipo di politica di gestione per un account dall' Console di gestione AWS AWS API o AWS Command Line Interface.
**Autorizzazioni minime**
Per visualizzare la politica efficace di un tipo di politica di gestione per un account, devi disporre dell'autorizzazione a eseguire le seguenti azioni:
`organizations:DescribeEffectivePolicy`
`organizations:DescribeOrganization` - Obbligatorio solo quando si utilizza la console Organizations
------
#### [ Console di gestione AWS ]
**Per visualizzare la politica efficace di un tipo di politica di gestione per un account**
1. Accedi alla [console AWS Organizations](https://console.aws.amazon.com/organizations/v2). È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
1. Nella **[Account AWS](https://console.aws.amazon.com/organizations/v2/home/accounts)**pagina, scegli il nome dell'account per il quale desideri visualizzare la politica efficace. Potrebbe essere necessario espandere OUs (scegliere il![\[Gray cloud icon representing cloud computing or storage services.\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/console-expand.png)) per trovare l'account desiderato.
1. Nella scheda **Politiche**, scegli il tipo di politica di gestione per cui desideri visualizzare la politica efficace.
1. Scegli **Visualizza la politica efficace per questo Account AWS**.
Nella console viene visualizzata la policy effettiva applicata all'account specificato.
**Nota**
Non puoi copiare e incollare una politica efficace e utilizzarla come JSON per un'altra politica senza modifiche significative. I documenti relativi alle policy devono includere gli [operatori di ereditarietà](policy-operators.md) che specificano in che modo ogni impostazione viene unita alla policy definitiva effettiva.
------
#### [ AWS CLI & AWS SDKs ]
**Per visualizzare la politica efficace di un tipo di politica di gestione per un account**
È possibile utilizzare uno dei seguenti strumenti per visualizzare la politica efficace:
+ AWS CLI: [describe-effective-policy](https://docs.aws.amazon.com/cli/latest/reference/organizations/describe-effective-policy.html)
Nell'esempio seguente viene illustrata la policy di rifiuto dei servizi di IA effettiva per un account.
```
$ aws organizations describe-effective-policy \
--policy-type AISERVICES_OPT_OUT_POLICY \
--target-id 123456789012
{
"EffectivePolicy": {
"PolicyContent": "{\"services\":{\"comprehend\":{\"opt_out_policy\":\"optOut\"}, ....TRUNCATED FOR BREVITY.... "opt_out_policy\":\"optIn\"}}}",
"LastUpdatedTimestamp": "2020-12-09T12:58:53.548000-08:00",
"TargetId": "123456789012",
"PolicyType": "AISERVICES_OPT_OUT_POLICY"
}
}
```
+ AWS SDKs: [DescribeEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html)
------
Per informazioni sulle situazioni in cui una politica efficace potrebbe diventare non valida, vedere [Visualizzazione degli avvisi di policy non validi](https://docs.aws.amazon.com//organizations/latest/userguide/invalid-policy-alerts.html).
# Informazioni sugli avvisi di policy non validi ed efficaci
*Gli avvisi relativi a policy non valide* segnalano policy efficaci non valide e forniscono meccanismi (APIs) per identificare gli account con policy non valide. AWS Organizations ti avvisa in modo asincrono quando uno dei tuoi account ha una politica efficace non valida. La notifica viene visualizzata come banner nella pagina della AWS Organizations console e viene registrata come evento. AWS CloudTrail
## Rileva politiche di gestione efficaci non valide nella tua organizzazione
Esistono diversi modi in cui è possibile visualizzare le politiche di gestione efficaci non valide nell'organizzazione: dalla console di AWS gestione, dall' AWS API, dall'interfaccia a riga di AWS comando (CLI) o come AWS CloudTrail evento.
**Autorizzazioni minime**
Per trovare le informazioni relative alle politiche efficaci non valide di un tipo di politica di gestione nell'organizzazione, è necessario disporre dell'autorizzazione per eseguire le seguenti azioni:
`organizations:ListAccountsWithInvalidEffectivePolicy`
`organizations:ListEffectivePolicyValidationErrors`
`organizations:ListRoots`- richiesto solo quando si utilizza la console Organizations
------
#### [ Console di gestione AWS ]
**Per visualizzare le politiche di gestione efficaci non valide dalla console**
1. Accedi alla [console AWS Organizations](https://console.aws.amazon.com/organizations/v2). È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
1. Nella **[Account AWS](https://console.aws.amazon.com/organizations/v2/home/accounts)**pagina della pagina, se l'organizzazione ha politiche efficaci non valide, viene visualizzato un banner di avviso nella parte superiore della pagina.
1. Nel banner, fai clic su **Visualizza i problemi rilevati** per visualizzare l'elenco di tutti gli account dell'organizzazione che dispongono di politiche efficaci non valide.
1. Per ogni account nell'elenco, seleziona **Visualizza problemi** per ottenere maggiori informazioni sugli errori relativi a ciascun account indicati nelle sezioni **Problemi relativi alle politiche efficaci** di questa pagina.
------
#### [ AWS CLI & AWS SDKs ]
**Per visualizzare la politica efficace di un tipo di politica di gestione per un account**
I seguenti comandi consentono di visualizzare gli account con politiche efficaci non valide
+ AWS CLI[: list-accounts-with-invalid -politica efficace](https://docs.aws.amazon.com/cli/latest/reference/organizations/list-accounts-with-invalid-effective-policy.html)
+ AWS SDKs: [ListAccountsWithInvalidEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_ListAccountsWithInvalidEffectivePolicy.html)
**I seguenti comandi consentono di visualizzare gli errori di policy effettivi su un account**
+ AWS CLI: [list-effective-policy-validation-errori](https://docs.aws.amazon.com/cli/latest/reference/organizations/list-effective-policy-validation-errors.html)
+ AWS SDKs: [ListEffectivePolicyValidationErrors](https://docs.aws.amazon.com/organizations/latest/APIReference/API_ListEffectivePolicyValidationErrors.html)
------
**AWS CloudTrail**
È possibile utilizzare AWS CloudTrail gli eventi per monitorare quando gli account delle organizzazioni adottano politiche di gestione efficaci non valide e quando tali politiche vengono corrette. Per ulteriori informazioni, consulta *Esempi di politiche efficaci* in [Comprendere le voci dei file di AWS Organizations registro](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_cloudtrail-integration.html#understanding-service-name-entries).
Se ricevi una notifica di politica effettiva non valida, puoi navigare nella AWS Organizations console o chiamarla APIs dal tuo account di gestione o amministratore delegato per trovare maggiori dettagli sullo stato di account e politiche specifici:
+ `ListAccountsWithInvalidEffectivePolicy`— Restituisce un elenco di account dell'organizzazione che dispongono di politiche efficaci non valide di un tipo specificato.
+ `ListEffectivePolicyValidationErrors`— Restituisce un elenco di errori di convalida per un account e un tipo di politica di gestione specificati. Gli errori di convalida contengono dettagli, tra cui il codice di errore, la descrizione dell'errore e le politiche che hanno contribuito a rendere non valida la politica effettiva.
## Quando una politica di gestione efficace potrebbe essere considerata non valida
Le politiche efficaci relative a un account possono diventare non valide se violano i vincoli definiti per quel particolare tipo di policy. Ad esempio, una politica potrebbe non avere un parametro obbligatorio nella politica definitiva effettiva o superare determinate quote definite per il tipo di politica.
**Esempio di policy di Backup**
Supponiamo di creare una policy di backup con nove regole di backup e di collegarla alla radice dell'organizzazione. Successivamente, si crea un'altra policy di backup per lo stesso piano di backup, con altre due regole, e la si allega a qualsiasi account dell'organizzazione. In tale situazione, esiste una politica efficace non valida sull'account. Non è valida perché l'aggregazione delle due politiche definisce 11 regole per il piano di backup. Il limite è di 10 regole di backup per piano.
**avvertimento**
Se un account dell'organizzazione dispone di una politica effettiva non valida, tale account non riceverà aggiornamenti delle politiche efficaci per il particolare tipo di politica. Continua con l'ultima politica valida valida applicata per l'account, a meno che tutti gli errori non vengano corretti.
**Esempi di possibili errori per politiche efficaci**
+ `ELEMENTS_TOO_MANY`— Si verifica quando un particolare attributo di una politica efficace supera il limite consentito, ad esempio quando vengono fornite più di 10 regole per un piano di backup.
+ `ELEMENTS_TOO_FEW`— Si verifica quando un particolare attributo di una politica efficace non soddisfa il limite minimo, ad esempio quando non è definita alcuna regione per un piano di backup.
+ `KEY_REQUIRED`— Si verifica quando nella politica effettiva non è presente una configurazione richiesta, ad esempio quando in un piano di backup manca una regola di backup.
AWS Organizations convalida le politiche efficaci prima di applicarle agli account dell'organizzazione. Questo processo di controllo è particolarmente utile se si dispone di una struttura organizzativa di grandi dimensioni e se le politiche dell'organizzazione sono gestite da più di un team.
# Policy dichiarative
Le politiche dichiarative consentono di dichiarare e applicare a livello centralizzato la configurazione desiderata per una determinata configurazione su larga scala Servizio AWS all'interno dell'organizzazione. Una volta collegata, la configurazione viene sempre mantenuta quando il servizio aggiunge nuove funzionalità o. APIs Utilizza politiche dichiarative per prevenire azioni non conformi. Ad esempio, puoi bloccare l'accesso pubblico a Internet alle risorse Amazon VPC in tutta l'organizzazione.
I vantaggi principali dell'utilizzo di politiche dichiarative sono:
+ **Facilità d'uso**: è possibile applicare la configurazione di base per an Servizio AWS con poche selezioni nelle AWS Control Tower console AWS Organizations e o con alcuni comandi utilizzando &. AWS CLI AWS SDKs
+ **Imposta una sola volta e dimentica**: la configurazione di base per an Servizio AWS viene sempre mantenuta, anche quando il servizio introduce nuove funzionalità o. APIs La configurazione di base viene mantenuta anche quando vengono aggiunti nuovi account a un'organizzazione o quando vengono creati nuovi responsabili e risorse.
+ **Trasparenza**: il rapporto sullo stato dell'account consente di esaminare lo stato attuale di tutti gli attributi supportati dalle politiche dichiarative per gli account interessati. È inoltre possibile creare messaggi di errore personalizzabili, che possono aiutare gli amministratori a reindirizzare gli utenti finali alle pagine wiki interne o fornire un messaggio descrittivo che può aiutare gli utenti finali a capire perché un'azione non è riuscita.
Per un elenco completo degli attributi Servizi AWS e degli attributi supportati, consulta. [Supportato Servizi AWS e attributi](#orgs_manage_policies_declarative-supported-controls)
**Topics**
+ [Come funzionano le politiche dichiarative](#orgs_manage_policies_declarative-how-work)
+ [Messaggi di errore personalizzati](#orgs_manage_policies_declarative-custom-message)
+ [Rapporto sullo stato dell'account](#orgs_manage_policies_declarative-account-status-report)
+ [Servizi supportati](#orgs_manage_policies_declarative-supported-controls)
+ [Nozioni di base](orgs_manage_policies-declarative_getting-started.md)
+ [Best practice](orgs_manage_policies_declarative_best-practices.md)
+ [Generazione del rapporto sullo stato dell'account](orgs_manage_policies_declarative_status-report.md)
+ [Sintassi ed esempi delle politiche dichiarative](orgs_manage_policies_declarative_syntax.md)
## Come funzionano le politiche dichiarative
Le politiche dichiarative vengono applicate nel piano di controllo del servizio, il che rappresenta un'importante distinzione dalle politiche di [autorizzazione come le politiche di controllo dei servizi (SCPs) e le politiche di controllo delle risorse ()](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html). RCPs Sebbene le politiche di autorizzazione regolino l'accesso APIs, le politiche dichiarative vengono applicate direttamente a livello di servizio per imporre un intento duraturo. Ciò garantisce che la configurazione di base venga sempre applicata, anche quando vengono introdotte nuove funzionalità o APIs vengono introdotte dal servizio.
La tabella seguente aiuta a illustrare questa distinzione e fornisce alcuni casi d'uso.
****
| | Policy di controllo dei servizi | Politiche di controllo delle risorse | Policy dichiarative |
| --- | --- | --- | --- |
| Perché? | Definire e applicare centralmente controlli di accesso coerenti sui principali (come gli utenti IAM e i ruoli IAM) su larga scala. | Per definire e applicare centralmente controlli di accesso coerenti sulle risorse su larga scala | Per definire e applicare centralmente la configurazione di base per i AWS servizi su larga scala. |
| Come? | Controllando le autorizzazioni di accesso massime disponibili dei principali a livello di API. | Controllando le autorizzazioni di accesso massime disponibili per le risorse a livello di API. | Applicando la configurazione desiderata di un Servizio AWS senza utilizzare azioni API. |
| Gestisce i ruoli collegati ai servizi? | No | No | Sì |
| Meccanismo di feedback | Errore SCP negato dall'accesso non personalizzabile. | Errore RCP negato di accesso non personalizzabile. | Messaggio di errore personalizzabile. Per ulteriori informazioni, consulta [Messaggi di errore personalizzati per le politiche dichiarative](#orgs_manage_policies_declarative-custom-message). |
| Policy di esempio | [Impedisci agli account dei membri di lasciare l'organizzazione](https://github.com/aws-samples/service-control-policy-examples/blob/main/Privileged-access-controls/Deny-member-accounts-from-leaving-your-AWS-organization.json) | [Limita l'accesso alle sole connessioni HTTPS alle tue risorse](https://github.com/aws-samples/resource-control-policy-examples/blob/main/Restrict-resource-access-patterns/Restrict-access-to-only-HTTPS-connections-to-your-resources.json) | [Impostazioni delle immagini consentite](orgs_manage_policies_declarative_syntax.md#declarative-policy-ec2-ami-allowed-images) |
Dopo aver [creato](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_create.html#create-declarative-policy-procedure) e [allegato](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_attach.html) una politica dichiarativa, questa viene applicata e applicata in tutta l'organizzazione. Le politiche dichiarative possono essere applicate a un'intera organizzazione, a unità organizzative (OUs) o a conti. Gli account che entrano a far parte di un'organizzazione erediteranno automaticamente la politica dichiarativa dell'organizzazione. Per ulteriori informazioni, consulta [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md).
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. Per ulteriori informazioni, consulta [Visualizzazione di politiche di gestione efficaci](orgs_manage_policies_effective.md).
Se una politica dichiarativa viene [scollegata](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_detach.html), lo stato dell'attributo tornerà allo stato precedente prima che la politica dichiarativa fosse allegata.
## Messaggi di errore personalizzati per le politiche dichiarative
Le politiche dichiarative consentono di creare messaggi di errore personalizzati. Ad esempio, se un'operazione API fallisce a causa di una politica dichiarativa, è possibile impostare il messaggio di errore o fornire un URL personalizzato, ad esempio un collegamento a un wiki interno o un collegamento a un messaggio che descrive l'errore. Se non si specifica un messaggio di errore personalizzato, AWS Organizations fornisce il seguente messaggio di errore predefinito:`Example: This action is denied due to an organizational policy in effect`.
È inoltre possibile controllare il processo di creazione di politiche dichiarative, aggiornamento delle politiche dichiarative ed eliminazione delle politiche dichiarative con. AWS CloudTrail CloudTrail può segnalare gli errori operativi dell'API dovuti a politiche dichiarative. Per ulteriori informazioni, consulta [Registrazione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_security_incident-response.html) e monitoraggio.
**Importante**
Non includere *informazioni di identificazione personale (PII)* o altre informazioni sensibili in un messaggio di errore personalizzato. Le PII includono informazioni generali che possono essere utilizzate per identificare o localizzare un individuo. Copre dati come quelli finanziari, medici, educativi o occupazionali. Gli esempi di PII includono indirizzi, numeri di conto corrente e numeri di telefono.
## Rapporto sullo stato dell'account per le politiche dichiarative
Il *rapporto sullo stato dell'account* consente di esaminare lo stato corrente di tutti gli attributi supportati dalle politiche dichiarative per gli account interessati. Puoi scegliere gli account e le unità organizzative (OUs) da includere nell'ambito del rapporto oppure scegliere un'intera organizzazione selezionando la radice.
Questo rapporto consente di valutare lo stato di preparazione fornendo una suddivisione per regione e indicando se lo stato corrente di un attributo è *uniforme tra gli account* (tramite`numberOfMatchedAccounts`) o *incoerente* (tramite). `numberOfUnmatchedAccounts` È inoltre possibile visualizzare il *valore più frequente*, ovvero il valore di configurazione osservato più frequentemente per l'attributo.
Nella Figura 1, è disponibile un rapporto sullo stato dell'account generato, che mostra l'uniformità tra gli account per i seguenti attributi: Accesso pubblico a blocchi VPC e Accesso pubblico a blocchi di immagini. Ciò significa che, per ogni attributo, tutti gli account inclusi nell'ambito hanno la stessa configurazione per quell'attributo.
Il rapporto sullo stato dell'account generato mostra account incoerenti per i seguenti attributi: impostazioni delle immagini consentite, impostazioni predefinite dei metadati delle istanze, Serial Console Access e Snapshot Block Public Access. In questo esempio, ogni attributo con un account non coerente è dovuto al fatto che esiste un account con un valore di configurazione diverso.
Se esiste un valore più frequente, questo viene visualizzato nella rispettiva colonna. Per informazioni più dettagliate su ciò che controlla ogni attributo, consulta [Sintassi delle politiche dichiarative ed esempi di policy](orgs_manage_policies_declarative_syntax.md).
Puoi anche espandere un attributo per visualizzare una suddivisione per regione. In questo esempio, Image Block Public Access è stato ampliato e in ogni regione, puoi vedere che c'è anche uniformità tra gli account.
La scelta di allegare una politica dichiarativa per l'applicazione di una configurazione di base dipende dal caso d'uso specifico. Utilizza il rapporto sullo stato dell'account per valutare la tua preparazione prima di allegare una politica dichiarativa.
Per ulteriori informazioni, consulta [Generazione del rapporto sullo stato dell'account](orgs_manage_policies_declarative_status-report.md).
![\[Esempio di report sullo stato dell'account con uniformità tra gli account per VPC Block Public Access e Image Block Public Access\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/declarative-status-report.png)
*Figura 1: Esempio di rapporto sullo stato dell'account con uniformità tra gli account per VPC Block Public Access e Image Block Public Access.*
## Supportato Servizi AWS e attributi
### Attributi supportati per le politiche dichiarative per EC2
La tabella seguente mostra gli attributi supportati per i servizi correlati ad Amazon EC2.
**Politiche dichiarative per EC2**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_declarative.html)
# Guida introduttiva alle politiche dichiarative
Segui questi passaggi per iniziare a utilizzare le politiche dichiarative.
1. [Scopri le autorizzazioni necessarie per eseguire attività relative alle politiche dichiarative](orgs_manage_policies_prereqs.md).
1. [Abilita le politiche dichiarative per](enable-policy-type.md) la tua organizzazione.
**Nota**
**È necessario abilitare l'accesso fiduciario**
È necessario abilitare l'accesso affidabile per il servizio in cui la politica dichiarativa applicherà una configurazione di base. In questo modo viene creato un ruolo collegato al servizio di sola lettura che viene utilizzato per generare il rapporto sullo stato dell'account contenente la configurazione esistente per gli account dell'organizzazione.
**Utilizzo della console**
Se utilizzi la console Organizations, questo passaggio fa parte del processo di abilitazione delle politiche dichiarative.
**Usando la AWS CLI**
Se si utilizza il AWS CLI, ce ne sono due distinti APIs:
[EnablePolicyType](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnablePolicyType.html), che si utilizza per abilitare le politiche dichiarative.
[Enable AWSService Access](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html), che viene utilizzato per abilitare l'accesso attendibile.
Per ulteriori informazioni su come abilitare l'accesso affidabile per un servizio specifico, AWS CLI consulta, [Servizi AWS che puoi utilizzare con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. [Esegui il rapporto sullo stato dell'account](orgs_manage_policies_declarative_status-report.md).
1. [Crea una politica dichiarativa](orgs_policies_create.md).
1. [Allega la politica dichiarativa alla radice, all'unità organizzativa o all'account dell'organizzazione](orgs_policies_attach.md).
1. [Visualizza la politica dichiarativa efficace combinata che si applica a un account](orgs_manage_policies_effective.md).
Per tutte queste fasi, è possibile accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([scelta non consigliata](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
**Altre informazioni**
+ [Scopri la sintassi delle politiche dichiarative e guarda esempi di politiche](orgs_manage_policies_declarative_syntax.md)
# Le migliori pratiche per l'utilizzo di politiche dichiarative
AWS raccomanda le seguenti best practice per l'utilizzo di politiche dichiarative.
## Sfrutta le valutazioni di prontezza
Utilizza il *rapporto sullo stato dell'account relativo* alla politica dichiarativa per valutare lo stato attuale di tutti gli attributi supportati dalle politiche dichiarative per i conti interessati. Puoi scegliere gli account e le unità organizzative (OUs) da includere nell'ambito del rapporto oppure scegliere un'intera organizzazione selezionando la radice.
Questo rapporto consente di valutare lo stato di preparazione fornendo una suddivisione per regione e indicando se lo stato corrente di un attributo è *uniforme tra gli account* (tramite`numberOfMatchedAccounts`) o *incoerente* (tramite). `numberOfUnmatchedAccounts` È inoltre possibile visualizzare il *valore più frequente*, ovvero il valore di configurazione osservato più frequentemente per l'attributo.
La scelta di allegare una politica dichiarativa per l'applicazione di una configurazione di base dipende dal caso d'uso specifico.
Per ulteriori informazioni e un esempio illustrativo, vedere. [Rapporto sullo stato dell'account per le politiche dichiarative](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-account-status-report)
## Inizia in piccolo e poi scala
Per semplificare il debug, inizia con una policy di test. Convalida il comportamento e l'impatto di ogni modifica prima di apportare la modifica successiva. Questo approccio riduce il numero di variabili da tenere in considerazione quando si verifica un errore o un risultato imprevisto.
Ad esempio, puoi iniziare con una politica di test collegata a un singolo account in un ambiente di test non critico. Dopo aver verificato che funziona secondo le vostre specifiche, potete quindi spostare la politica in modo incrementale verso l'alto nella struttura organizzativa verso più account e più unità organizzative ()OUs.
## Stabilisci processi di revisione
Implementa processi per monitorare i nuovi attributi dichiarativi, valutare le eccezioni alle politiche e apportare modifiche per mantenere l'allineamento con i requisiti operativi e di sicurezza dell'organizzazione.
## Convalida le modifiche utilizzando `DescribeEffectivePolicy`
Dopo aver apportato una modifica a una politica dichiarativa, verifica le politiche efficaci per gli account rappresentativi al di sotto del livello in cui hai apportato la modifica. Puoi [visualizzare la politica efficace utilizzando o utilizzando Console di gestione AWS l'](orgs_manage_policies_effective.md)operazione [DescribeEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DescribeEffectivePolicy.html)API o una delle sue AWS CLI varianti o dell' AWS SDK. Assicurati che l'impatto della modifica apportata sulla policy effettiva sia quello previsto.
## Comunica e allenati
Assicuratevi che le vostre organizzazioni comprendano lo scopo e l'impatto delle vostre politiche dichiarative. Fornisci indicazioni chiare sui comportamenti previsti e su come gestire gli errori dovuti all'applicazione delle politiche.
# Generazione del rapporto sullo stato dell'account per le politiche dichiarative
Il *rapporto sullo stato dell'account* consente di esaminare lo stato corrente di tutti gli attributi supportati dalle politiche dichiarative per gli account interessati. Puoi scegliere gli account e le unità organizzative (OUs) da includere nell'ambito del rapporto oppure scegliere un'intera organizzazione selezionando la radice.
Questo rapporto consente di valutare lo stato di preparazione fornendo una suddivisione per regione e indicando se lo stato corrente di un attributo è *uniforme tra gli account* (tramite`numberOfMatchedAccounts`) o *incoerente* (tramite). `numberOfUnmatchedAccounts` È inoltre possibile visualizzare il *valore più frequente*, ovvero il valore di configurazione osservato più frequentemente per l'attributo.
La scelta di allegare una politica dichiarativa per l'applicazione di una configurazione di base dipende dal caso d'uso specifico.
Per ulteriori informazioni e un esempio illustrativo, vedere. [Rapporto sullo stato dell'account per le politiche dichiarative](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-account-status-report)
## Prerequisiti
Prima di poter generare un rapporto sullo stato dell'account, è necessario eseguire le seguenti operazioni
1. L'`StartDeclarativePoliciesReport`API può essere richiamata solo dall'account di gestione o dagli amministratori delegati di un'organizzazione.
1. È necessario disporre di un bucket S3 prima di generare il report (crearne uno nuovo o utilizzarne uno esistente), deve trovarsi nella stessa regione in cui viene effettuata la richiesta e deve avere una politica di bucket S3 appropriata. Per un esempio di policy S3, consulta *Esempio di policy Amazon S3* in Esempi nel riferimento [alle](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_StartDeclarativePoliciesReport.html#API_StartDeclarativePoliciesReport_Examples) API di Amazon *EC2*
1. È necessario abilitare l'accesso affidabile per il servizio in cui la politica dichiarativa applicherà una configurazione di base. In questo modo viene creato un ruolo collegato al servizio di sola lettura che viene utilizzato per generare il rapporto sullo stato dell'account contenente la configurazione esistente per gli account dell'organizzazione.
**Utilizzo della console**
Per la console Organizations, questo passaggio fa parte del processo di abilitazione delle politiche dichiarative.
**Utilizzo del AWS CLI**
Per AWS CLI, utilizza l'API [Enable AWSService Access](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html).
Per ulteriori informazioni su come abilitare l'accesso affidabile per un servizio specifico, AWS CLI consulta, [Servizi AWS che puoi utilizzare con AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html).
1. È possibile generare un solo report per organizzazione alla volta. Il tentativo di generare un report mentre ne è in corso un altro genererà un errore.
## Accedi al rapporto sullo stato di conformità
**Autorizzazioni minime**
Per generare un rapporto sullo stato di conformità, è necessaria l'autorizzazione per eseguire le seguenti azioni:
`ec2:StartDeclarativePoliciesReport`
`ec2:DescribeDeclarativePoliciesReports`
`ec2:GetDeclarativePoliciesReportSummary`
`ec2:CancelDeclarativePoliciesReport`
`organizations:DescribeAccount`
`organizations:DescribeOrganization`
`organizations:DescribeOrganizationalUnit`
`organizations:ListAccounts`
`organizations:ListDelegatedAdministrators`
`organizations:ListAWSServiceAccessForOrganization`
`s3:PutObject`
**Nota**
Se il tuo bucket Amazon S3 utilizza la crittografia SSE-KMS, devi includere anche l'autorizzazione nella policy. `kms:GenerateDataKey`
------
#### [ Console di gestione AWS ]
Utilizza la seguente procedura per generare un rapporto sullo stato dell'account.
**Per generare un rapporto sullo stato dell'account**
1. Accedi alla [console AWS Organizations](https://console.aws.amazon.com/organizations/v2). È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
1. Nella pagina **Politiche**, scegli **Politiche dichiarative per EC2**.
1. **Nella pagina **Politiche dichiarative per EC2**, scegli **Visualizza il rapporto sullo stato dell'account** dal menu a discesa Azioni.**
1. Nella pagina **Visualizza il rapporto sullo stato dell'account, scegli **Genera** rapporto sullo stato**.
1. Nel widget **Struttura organizzativa**, specifica quali unità organizzative (OUs) desideri includere nel rapporto.
1. Seleziona **Invia**.
------
#### [ AWS CLI & AWS SDKs ]
**Per generare un rapporto sullo stato dell'account**
Utilizza le seguenti operazioni per generare un rapporto sullo stato di conformità, verificarne lo stato e visualizzare il rapporto:
+ `ec2:start-declarative-policies-report`: genera un rapporto sullo stato dell'account. Il rapporto viene generato in modo asincrono e il completamento può richiedere diverse ore. Per ulteriori informazioni, [StartDeclarativePoliciesReport](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_StartDeclarativePoliciesReport.html)consulta *Amazon EC2 API* Reference.
+ `ec2:describe-declarative-policies-report`: descrive i metadati di un rapporto sullo stato dell'account, incluso lo stato del rapporto. Per ulteriori informazioni, [DescribeDeclarativePoliciesReports](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeDeclarativePoliciesReports.html)consulta *Amazon EC2 API* Reference.
+ `ec2:get-declarative-policies-report-summary`: recupera un riepilogo del rapporto sullo stato dell'account. Per ulteriori informazioni, [GetDeclarativePoliciesReportSummary](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetDeclarativePoliciesReportSummary.html)consulta *Amazon EC2 API* Reference.
+ `ec2:cancel-declarative-policies-report`: annulla la generazione di un rapporto sullo stato dell'account. Per ulteriori informazioni, [CancelDeclarativePoliciesReport](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CancelDeclarativePoliciesReport.html)consulta *Amazon EC2 API* Reference.
Prima di generare un report, concedi alle politiche dichiarative di EC2 l'accesso principale al bucket Amazon S3 in cui verrà archiviato il report. A tale scopo, allega la seguente policy al bucket. Sostituiscilo `amzn-s3-demo-bucket` con il nome effettivo del bucket Amazon S3 e `identity_ARN` con l'identità IAM utilizzata per chiamare l'API. `StartDeclarativePoliciesReport`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DeclarativePoliciesReportDelivery",
"Effect": "Allow",
"Principal": {
"AWS": "identity_ARN"
},
"Action": [
"s3:PutObject"
],
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Condition": {
"StringEquals": {
"aws:CalledViaLast": "organizations.amazonaws.com"
}
}
}
]
}
```
------
------
# Sintassi ed esempi delle politiche dichiarative
Questa pagina descrive la sintassi delle politiche dichiarative e fornisce esempi.
## Considerazioni
+ Quando si configura un attributo di servizio utilizzando una politica dichiarativa, ciò potrebbe influire su più fattori. APIs Qualsiasi azione non conforme fallirà.
+ Gli amministratori degli account non saranno in grado di modificare il valore dell'attributo di servizio a livello di singolo account.
## Sintassi per le politiche dichiarative
[Una politica dichiarativa è un file di testo semplice strutturato secondo le regole di JSON.](http://json.org) La sintassi per le politiche dichiarative segue la sintassi di tutti i tipi di politiche di gestione. Per una discussione completa di tale sintassi, consulta [Policy syntax and inheritance for management policy types](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html). Questo argomento si concentra sull'applicazione di tale sintassi generale ai requisiti specifici del tipo di politica dichiarativa.
L'esempio seguente mostra la sintassi di base della politica dichiarativa:
```
{
"ec2_attributes": {
"exception_message": {
"@@assign": "Your custom error message.https://myURL"
}
}
}
```
+ Il nome della chiave di campo `ec2_attributes`. Le politiche dichiarative iniziano sempre con un nome di chiave fisso per il dato. Servizio AWSÈ la prima riga nella policy di esempio precedente. Attualmente le politiche dichiarative supportavano solo i servizi correlati ad Amazon EC2.
+ In`ec2_attributes`, puoi utilizzare `exception_message` per impostare un messaggio di errore personalizzato. Per ulteriori informazioni, consulta [Messaggi di errore personalizzati per le politiche dichiarative](orgs_manage_policies_declarative.md#orgs_manage_policies_declarative-custom-message).
+ In`ec2_attributes`, puoi inserire una o più delle politiche dichiarative supportate. Per questi schemi, vedi. [Politiche dichiarative supportate](#declarative-policy-examples)
## Politiche dichiarative supportate
Di seguito sono riportati gli attributi Servizi AWS e supportati dalle politiche dichiarative. In alcuni degli esempi seguenti, la formattazione degli spazi bianchi JSON potrebbe essere compressa per risparmiare spazio.
+ VPC blocca l'accesso pubblico
+ Accesso alla console seriale
+ Accesso pubblico a Image Block
+ Impostazioni delle immagini consentite
+ Metadata delle istanze
+ Snapshot Block Public Access
------
#### [ VPC Block Public Access ]
**Effetto della politica**
Controlla se le risorse in Amazon VPCs e le sottoreti possono raggiungere Internet tramite gateway Internet (). IGWs Per ulteriori informazioni, consulta [Configurazione per l'accesso a Internet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-igw-internet-access.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*.
**Contenuto della policy**
```
{
"ec2_attributes": {
"vpc_block_public_access": {
"internet_gateway_block": {
"mode": {
"@@assign": "block_ingress"
},
"exclusions_allowed": {
"@@assign": "enabled"
}
}
}
}
}
```
Di seguito sono riportati i campi disponibili per questo attributo:
+ `"internet_gateway"`:
+ `"mode"`:
+ `"off"`: VPC BPA non è abilitato.
+ `"block_ingress"`: Tutto il traffico Internet verso VPCs (ad eccezione VPCs delle sottoreti che sono escluse) è bloccato. È consentito solo il traffico da e verso i gateway NAT e i gateway Internet egress-only, poiché questi gateway consentono solo di stabilire connessioni in uscita.
+ `"block_bidirectional"`: Tutto il traffico da e verso i gateway Internet e i gateway Internet solo in uscita (ad eccezione delle sottoreti e delle sottoreti escluse) è bloccato. VPCs
+ `"exclusions_allowed"`: Un'esclusione è una modalità che può essere applicata a un singolo VPC o sottorete che lo esenta dalla modalità VPC BPA dell'account e consentirà l'accesso bidirezionale o solo in uscita.
+ `"enabled"`: Le esclusioni possono essere create dall'account.
+ `"disabled"`: Le esclusioni non possono essere create dall'account.
**Nota**
È possibile utilizzare l'attributo per configurare se le esclusioni sono consentite, ma non è possibile creare esclusioni con questo attributo stesso. Per creare esclusioni, devi crearle nell'account che possiede il VPC. Per ulteriori informazioni sulla creazione di esclusioni VPC BPA, consulta [Creare ed eliminare esclusioni](https://docs.aws.amazon.com//vpc/latest/userguide/security-vpc-bpa.html#security-vpc-bpa-exclusions) nella *Amazon* VPC User Guide.
**Considerazioni**
Se utilizzi questo attributo in una politica dichiarativa, non puoi utilizzare le seguenti operazioni per modificare la configurazione applicata per gli account inclusi nell'ambito. Questo elenco non è esaustivo:
+ `ModifyVpcBlockPublicAccessOptions`
+ `CreateVpcBlockPublicAccessExclusion`
+ `ModifyVpcBlockPublicAccessExclusion`
------
#### [ Serial Console Access ]
**Effetto politico**
Controlla se la console seriale EC2 è accessibile. Per ulteriori informazioni sulla console seriale EC2, consulta [Console seriale EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html) nella *Amazon Elastic Compute Cloud User Guide*.
**Contenuti della policy**
```
{
"ec2_attributes": {
"serial_console_access": {
"status": {
"@@assign": "enabled"
}
}
}
}
```
Di seguito sono riportati i campi disponibili per questo attributo:
+ `"status"`:
+ `"enabled"`: L'accesso alla console seriale EC2 è consentito.
+ `"disabled"`: l'accesso alla console seriale EC2 è bloccato.
**Considerazioni**
Se si utilizza questo attributo in una politica dichiarativa, non è possibile utilizzare le seguenti operazioni per modificare la configurazione applicata per gli account inclusi nell'ambito. Questo elenco non è esaustivo:
+ `EnableSerialConsoleAccess`
+ `DisableSerialConsoleAccess`
------
#### [ Image Block Public Access ]
**Effetto politico**
Controlla se Amazon Machine Images (AMIs) è condivisibile pubblicamente. Per ulteriori informazioni AMIs, consulta [Amazon Machine Images (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) nella *Amazon Elastic Compute Cloud User Guide*.
**Contenuti della policy**
```
{
"ec2_attributes": {
"image_block_public_access": {
"state": {
"@@assign": "block_new_sharing"
}
}
}
}
```
Di seguito sono riportati i campi disponibili per questo attributo:
+ `"state"`:
+ `"unblocked"`: Nessuna restrizione alla condivisione pubblica di AMIs.
+ `"block_new_sharing"`: Blocca la nuova condivisione pubblica di AMIs. AMIs che erano già condivisi pubblicamente rimangono disponibili al pubblico.
**Considerazioni**
Se si utilizza questo attributo in una politica dichiarativa, non è possibile utilizzare le seguenti operazioni per modificare la configurazione applicata per gli account inclusi nell'ambito. Questo elenco non è esaustivo:
+ `EnableImageBlockPublicAccess`
+ `DisableImageBlockPublicAccess`
------
#### [ Allowed Images Settings ]
**Effetto politico**
Controlla il rilevamento e l'uso di Amazon Machine Images (AMI) in Amazon EC2 con Allowed. AMIs Per ulteriori informazioni AMIs, consulta [Controllare l'individuazione e l'uso delle AMI in Amazon EC2 with AMIs Allowed nella Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) *Elastic Compute* Cloud User Guide.
**Contenuti della policy**
Di seguito sono riportati i campi disponibili per questo attributo:
```
{
"ec2_attributes": {
"allowed_images_settings": {
"state": {
"@@assign": "enabled"
},
"image_criteria": {
"criteria_1": {
"allowed_image_providers": {
"@@append": [
"amazon"
]
}
}
}
}
}
}
```
+ `"state"`:
+ `"enabled"`: L'attributo è attivo e applicato.
+ `"disabled"`: l'attributo è inattivo e non applicato.
+ `"audit_mode"`: L'attributo è in modalità di controllo. Ciò significa che identificherà le immagini non conformi ma non ne bloccherà l'utilizzo.
+ `"image_criteria"`: Un elenco di criteri. Supporta fino a 10 criteri con il nome da criteria\$11 a criteria\$110
+ `"allowed_image_providers"`: un elenco separato da virgole di account IDs a 12 cifre o alias del proprietario di Amazon, aws\$1marketplace, aws\$1backup\$1vault.
+ `"image_names"`: i nomi delle immagini consentite. I nomi possono includere caratteri jolly (? e \$1). Lunghezza: 1—128 caratteri. Con? , il minimo è di 3 caratteri.
+ `"marketplace_product_codes"`: i codici prodotto del AWS Marketplace per le immagini consentite. Lunghezza: 1-25 caratteri Caratteri validi: lettere (A—Z, a—z) e numeri (0—9)
+ `"creation_date_condition"`: L'età massima consentita per le immagini.
+ `"maximum_days_since_created"`: Il numero massimo di giorni trascorsi dalla creazione dell'immagine. Intervallo valido: valore minimo di 0. Valore massimo di 2147483647.
+ `"deprecation_time_condition"`: periodo massimo di deprecazione per le immagini consentite.
+ `"maximum_days_since_deprecated"`: Il numero massimo di giorni trascorsi da quando l'immagine è diventata obsoleta. Intervallo valido: valore minimo di 0. Valore massimo di 2147483647.
**Considerazioni**
Se si utilizza questo attributo in una politica dichiarativa, non è possibile utilizzare le seguenti operazioni per modificare la configurazione applicata per gli account inclusi nell'ambito. Questo elenco non è esaustivo:
+ `EnableAllowedImagesSettings`
+ `ReplaceImageCriteriaInAllowedImagesSettings`
+ `DisableAllowedImagesSettings`
------
#### [ Instance Metadata ]
**Effetto politico**
Controlla le impostazioni predefinite IMDS e l'applicazione di IMDSv2 per tutti i lanci di nuove istanze EC2. *Per ulteriori informazioni sulle impostazioni predefinite e sull' IMDSv2 applicazione dell'IMDS, consulta [Use i metadati delle istanze per gestire l'istanza EC2 nella Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) User Guide.*
**Contenuti della policy**
Di seguito sono riportati i campi disponibili per questo attributo:
```
{
"ec2_attributes": {
"instance_metadata_defaults": {
"http_tokens": {
"@@assign": "required"
},
"http_put_response_hop_limit": {
"@@assign": "4"
},
"http_endpoint": {
"@@assign": "enabled"
},
"instance_metadata_tags": {
"@@assign": "enabled"
},
"http_tokens_enforced": {
"@@assign": "enabled"
}
}
}
}
```
+ `"http_tokens"`:
+ `"no_preference"`: si applicano altre impostazioni predefinite. Ad esempio, i valori predefiniti AMI, se applicabile.
+ `"required"`: IMDSv2 deve essere usato. IMDSv1 non è consentito.
+ `"optional"`: Sono IMDSv1 IMDSv2 consentiti entrambi.
**Nota**
**Versione dei metadati**
Prima di `http_tokens` impostare su `required` (IMDSv2 deve essere usato), assicurati che nessuna delle tue istanze stia effettuando IMDSv1 chiamate. Per ulteriori informazioni, consulta la [Fase 1: Identifica le istanze con IMDSv2 =optional e verifica IMDSv1 l'utilizzo](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html#path-step-1) nella *Amazon EC2* User Guide.
+ `"http_put_response_hop_limit"`:
+ `"Integer"`: Valore intero compreso tra -1 e 64, che rappresenta il numero massimo di hop che il token di metadati può percorrere. Per non indicare alcuna preferenza, specificare -1.
**Nota**
**Limite di hop**
Se `http_tokens` è impostato su`required`, si consiglia di `http_put_response_hop_limit` impostarlo su un minimo di 2. Per ulteriori informazioni, consulta [Considerazioni sull'accesso ai metadati dell'istanza nella Guida](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html#imds-considerations) per l'utente di *Amazon Elastic Compute Cloud*.
+ `"http_endpoint"`:
+ `"no_preference"`: si applicano altre impostazioni predefinite. Ad esempio, i valori predefiniti AMI, se applicabile.
+ `"enabled"`: L'endpoint del servizio di metadati dell'istanza è accessibile.
+ `"disabled"`: l'endpoint del servizio di metadati dell'istanza non è accessibile.
+ `"instance_metadata_tags"`:
+ `"no_preference"`: si applicano altre impostazioni predefinite. Ad esempio, i valori predefiniti AMI, se applicabile.
+ `"enabled"`: È possibile accedere ai tag di istanza dai metadati dell'istanza.
+ `"disabled"`: Non è possibile accedere ai tag di istanza dai metadati dell'istanza.
+ `"http_tokens_enforced":`
+ `"no_preference"`: si applicano altre impostazioni predefinite. Ad esempio, i valori predefiniti AMI, se applicabile.
+ `"enabled"`: IMDSv2 deve essere usato. I tentativi di avviare un' IMDSv1 istanza o di attivarla IMDSv1 su istanze esistenti falliranno.
+ `"disabled"`: entrambi IMDSv1 IMDSv2 sono consentiti.
**avvertimento**
**IMDSv2 esecuzione**
Abilitare IMDSv2 l'imposizione mentre si consente IMDSv1 e IMDSv2 (token opzionale) causerà errori di avvio, a meno che non IMDSv1 sia esplicitamente disabilitato, tramite i parametri di avvio o le impostazioni predefinite dell'AMI. Per ulteriori informazioni, consulta [Launching an IMDSv1 -enabled instance fail](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html#launching-an-imdsv1-enabled-instance-fails) nella *Amazon EC2* User Guide.
------
#### [ Snapshot Block Public Access ]
**Effetto delle politiche**
Controlla se gli snapshot di Amazon EBS sono accessibili pubblicamente. Per ulteriori informazioni sugli snapshot EBS, consulta gli snapshot di [Amazon EBS nella](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html) *Amazon Elastic Block* Store User Guide.
**Contenuto della policy**
```
{
"ec2_attributes": {
"snapshot_block_public_access": {
"state": {
"@@assign": "block_new_sharing"
}
}
}
}
```
Di seguito sono riportati i campi disponibili per questo attributo:
+ `"state"`:
+ `"block_all_sharing"`: blocca tutte le condivisioni pubbliche di istantanee. Le istantanee che erano già condivise pubblicamente vengono trattate come private e non sono più disponibili pubblicamente.
+ `"block_new_sharing"`: blocca la nuova condivisione pubblica di istantanee. Le istantanee che erano già condivise pubblicamente rimangono disponibili pubblicamente.
+ `"unblocked"`: nessuna restrizione alla condivisione pubblica delle istantanee.
**Considerazioni**
Se si utilizza questo attributo in una politica dichiarativa, non è possibile utilizzare le seguenti operazioni per modificare la configurazione applicata per gli account inclusi nell'ambito. Questo elenco non è esaustivo:
+ `EnableSnapshotBlockPublicAccess`
+ `DisableSnapshotBlockPublicAccess`
------
# Policy di backup
Le policy di backup consentono di gestire e applicare centralmente i piani di backup alle AWS risorse degli account di un'organizzazione.
[AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/)consente di creare [piani di backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/about-backup-plans.html) che definiscono come eseguire il backup AWS delle risorse. Le regole del piano includono una serie di impostazioni, come la frequenza di backup, la finestra temporale durante la quale viene eseguito il backup, il Regione AWS contenitore delle risorse di cui eseguire il backup e l'archivio in cui archiviare il backup. È quindi possibile applicare un piano di backup a gruppi di AWS risorse identificati tramite tag. È inoltre necessario identificare un ruolo AWS Identity and Access Management (IAM) che conceda l' AWS Backup autorizzazione a eseguire l'operazione di backup per conto dell'utente.
Le politiche di backup AWS Organizations combinano tutti questi pezzi in documenti di testo [JSON](https://json.org). È possibile allegare una policy di backup a qualsiasi elemento della struttura dell'organizzazione, come la radice, le unità organizzative (OUs) e i singoli account. Organizations applica le regole di ereditarietà per combinare le politiche nella radice dell'organizzazione, in qualsiasi elemento principale OUs o allegate all'account. Ciò si traduce in una [policy di backup effettiva](orgs_manage_policies_effective.md) per ogni account. Questa politica efficace indica AWS Backup come eseguire automaticamente il backup delle risorse. AWS
## Come funzionano le policy di backup
Le policy di backup offrono un controllo granulare sul backup delle risorse a qualsiasi livello richiesto dall'organizzazione. Ad esempio, in una policy collegata al root dell'organizzazione puoi specificare che è necessario eseguire il backup di tutte le tabelle Amazon DynamoDB. Tale policy può includere una frequenza di backup predefinita. È quindi possibile allegare una policy di backup OUs che sostituisca la frequenza di backup in base ai requisiti di ciascuna unità organizzativa. Ad esempio, l'unità organizzativa `Developers` potrebbe specificare una frequenza di backup di una volta alla settimana, mentre l'unità organizzativa `Production` specifica una frequenza di una volta al giorno.
Puoi creare policy di backup parziali che includano singolarmente solo una parte delle informazioni necessarie per eseguire correttamente il backup delle risorse. È possibile collegare queste politiche a diverse parti dell'albero organizzativo, ad esempio l'unità organizzativa principale o l'unità organizzativa principale, con l'intenzione che tali politiche parziali vengano ereditate dagli account e di livello inferiore OUs . Quando Organizations combina tutte le policy per un account utilizzando le regole di ereditarietà, la policy effettiva risultante deve disporre di tutti gli elementi richiesti. In caso contrario, AWS Backup considera la politica non valida e non esegue il backup delle risorse interessate.
**Importante**
AWS Backup può eseguire un backup con successo solo quando viene richiamato da una policy *completa* ed efficace che contenga tutti gli elementi richiesti.
Sebbene una strategia di policy parziale descritta in precedenza possa funzionare, se una policy effettiva per un account risulta incompleta, si generano errori o risorse di cui non viene eseguito il backup. Come strategia alternativa, si consiglia di richiedere che tutti le policy di backup siano complete e convalidate autonomamente. Utilizza i valori predefiniti forniti dalle policy collegate più in alto nella gerarchia e sostituirli dove necessario nelle policy figlio includendo gli [operatori di controllo figlio di ereditarietà](policy-operators.md).
Il piano di backup efficace per ogni Account AWS membro dell'organizzazione viene visualizzato nella AWS Backup console come piano immutabile per quell'account. Puoi visualizzarlo, ma non modificarlo. Tuttavia, puoi aggiungere o rimuovere i tag del piano di backup utilizzando [TagResource](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_TagResource.html)e. [UntagResource](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UntagResource.html) APIs
Quando AWS Backup inizia un backup basato su un piano di backup creato da policy, è possibile visualizzare lo stato del processo di backup nella AWS Backup console. Un utente di un account membro può visualizzare lo stato e gli eventuali errori relativi ai processi di backup in tale account membro. Se si abilita anche l'accesso affidabile al servizio con AWS Backup, un utente dell'account di gestione dell'organizzazione può visualizzare lo stato e gli errori di tutti i job di backup dell'organizzazione. Per ulteriori informazioni, consulta [Abilitazione della gestione di più account](https://docs.aws.amazon.com/aws-backup/latest/devguide/manage-cross-account.html#enable-cross-account) nella *Guida per gli sviluppatori di AWS Backup *.
# Nozioni di base sulle policy di backup
Segui queste fasi per iniziare a utilizzare le policy di backup.
1. [Ulteriori informazioni sulle autorizzazioni necessarie per eseguire attività delle policy di backup](orgs_manage_policies_prereqs.md)
1. [Ulteriori informazioni su alcune best practice consigliate per l'utilizzo delle policy di backup](orgs_manage_policies_backup_best-practices.md).
1. [Abilitare le policy di backup per l'organizzazione](enable-policy-type.md).
1. [Creare una policy di backup](orgs_policies_create.md#create-backup-policy-procedure).
1. [Collegare la policy di backup alla root dell'organizzazione, all'unità organizzativa o all'account](orgs_policies_attach.md).
1. [Visualizzare la policy di backup effettiva combinata applicabile a un account](orgs_manage_policies_effective.md).
Per tutte queste fasi, è possibile accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([scelta non consigliata](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
**Altre informazioni**
+ [Ulteriori informazioni sulla sintassi delle policy di backup e policy di esempio](orgs_manage_policies_backup_syntax.md)
# Best practice per l'utilizzo delle policy di backup
AWS consiglia le seguenti best practice per l'utilizzo delle policy di backup.
## Scelta di una strategia delle policy di backup
Puoi creare policy di backup in parti incomplete che vengono ereditate e unite per creare una policy completa per ogni account membro. In questo caso, se si apporta una modifica a un livello senza considerare attentamente l'impatto di tale modifica su tutti gli account al di sotto di tale livello c'è il rischio di ottenere una policy effettiva incompleta. Per evitare ciò, consigliamo di verificare che le policy di backup implementate a tutti i livelli siano complete autonomamente. Considera le policy padre come policy predefinite che possono essere sovrascritte dalle impostazioni specificate nelle policy figlie. In questo modo, anche se non esiste una policy figlio, la policy ereditata è completa e utilizza i valori predefiniti. Puoi controllare quali impostazioni possono essere aggiunte, modificate o rimosse da policy figlio utilizzando gli [operatori di ereditarietà del controllo figlio](policy-operators.md#child-control-operators).
## Convalida delle modifiche al controllo delle policy di backup mediante `GetEffectivePolicy`
Dopo aver apportato una modifica a una policy di backup, controllare le policy effettive per gli account rappresentativi al di sotto del livello in cui è stata apportata la modifica. È possibile [visualizzare la policy efficace utilizzando o utilizzando l' Console di gestione AWS](orgs_manage_policies_effective.md)operazione [GetEffectivePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_GetEffectivePolicy.html)API o una delle sue varianti AWS CLI o dell' AWS SDK. Assicurati che l'impatto della modifica apportata sulla policy effettiva sia quello previsto.
## Iniziare semplicemente e apportare piccole modifiche
Per semplificare il debug, inizia con policy semplici e apporta modifiche un elemento alla volta. Convalida il comportamento e l'impatto di ogni modifica prima di apportare la modifica successiva. Questo approccio riduce il numero di variabili da tenere in considerazione quando si verifica un errore o un risultato imprevisto.
## Archivia le copie dei backup in altri account Regioni AWS e in altri account dell'organizzazione
Per migliorare la posizione di disaster recovery, è possibile archiviare copie dei backup.
+ **Un'altra regione**: se si archiviano copie del backup in altre aree geografiche Regioni AWS, si contribuisce a proteggere il backup da danneggiamenti o eliminazioni accidentali nella regione originale. Utilizza la sezione `copy_actions` della policy per specificare un vault in una o più Regioni dello stesso account in cui viene eseguito il piano di backup. A tale scopo, identifica l'account utilizzando la variabile `$account` quando specifichi l'ARN del vault di backup in cui archiviare la copia del backup. La variabile `$account ` viene automaticamente sostituita in fase di esecuzione con l'ID account in cui è in esecuzione la policy di backup.
+ **Un account diverso**: se memorizzi copie del backup in un altro account Account AWS, aggiungi una barriera di sicurezza che aiuta a proteggerti da un malintenzionato che compromette uno dei tuoi account. Utilizza la sezione `copy_actions` della policy per specificare un vault in uno o più account dell'organizzazione, separati dall'account in cui viene eseguito il piano di backup. A tale scopo, identifica l'account utilizzando il numero ID account effettivo quando specifichi l'ARN del vault di backup in cui archiviare la copia del backup.
## Limitare il numero di piani per policy
Le policy che contengono più piani sono più complicate da risolvere a causa del maggior numero di output che devono essere tutti convalidati. Fare invece in modo che ogni policy contenga un solo piano di backup per semplificare il debug e la risoluzione dei problemi. Puoi quindi aggiungere altre policy con altri piani per soddisfare altri requisiti. Questo approccio consente di mantenere tutti i problemi relativi a un piano isolati per una policy e impedisce a tali problemi di complicare la risoluzione dei problemi relativi ad altre policy e ai relativi piani.
## Utilizza gli stack set per creare i vault di backup e i ruoli IAM richiesti
Utilizza l'integrazione degli AWS CloudFormation stack set con Organizations per creare automaticamente gli archivi di backup e i ruoli AWS Identity and Access Management (IAM) richiesti in ciascuno degli account membro della tua organizzazione. Puoi creare un set di stack che includa le risorse che desideri siano disponibili automaticamente Account AWS in ogni parte dell'organizzazione. Questo approccio ti consente di eseguire i piani di backup assicurando che le dipendenze siano già soddisfatte. Per ulteriori informazioni, consulta [Creazione di uno stack set con autorizzazioni gestite dal cliente](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#create-stack-set-service-managed-permissions) nella *Guida per l'utente di AWS CloudFormation *.
## Controllare i risultati esaminando il primo backup creato in ogni account
Quando apportati una modifica a una policy, controlla il backup successivo creato dopo tale modifica per assicurarti che l'impatto della modifica sia quello desiderato. Questo passaggio va oltre la semplice analisi delle politiche efficaci e garantisce che AWS Backup interpreti le politiche e implementi i piani di backup nel modo previsto.
# Utilizzo AWS CloudTrail degli eventi per monitorare le politiche di backup nell'organizzazione
È possibile utilizzare AWS CloudTrail gli eventi per monitorare quando le politiche di backup vengono create, aggiornate o eliminate da qualsiasi account dell'organizzazione o quando esiste un piano di backup organizzativo non valido. Per ulteriori informazioni, consulta [Registrazione degli eventi per la gestione di più account](https://docs.aws.amazon.com/aws-backup/latest/devguide/logging-using-cloudtrail.html#logging-cam-events) nella *Guida per gli sviluppatori di AWS Backup *.
# Sintassi ed esempi delle policy di backup
In questa pagina viene descritta la sintassi delle policy di backup e vengono forniti esempi.
## Sintassi per le policy di backup
Una policy di backup è un file di testo normale strutturato in base alle regole di [JSON](http://json.org). La sintassi per le policy di backup segue la sintassi per tutti i tipi di policy di gestione. Per ulteriori informazioni, vedere [Sintassi ed ereditarietà delle policy per i tipi di policy di gestione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html). Questo argomento è incentrato sull'applicazione della sintassi generale ai requisiti specifici del tipo di policy di backup.
*Per ulteriori informazioni sui AWS Backup piani, consulta la Guida per [CreateBackupPlan](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_CreateBackupPlan.html)gli AWS Backup sviluppatori.*
## Considerazioni
**Sintassi delle politiche**
I nomi di chiavi duplicati verranno rifiutati in JSON.
Le politiche devono specificare le risorse Regioni AWS e le risorse di cui eseguire il backup.
Le policy devono specificare il ruolo IAM che AWS Backup assume.
L'utilizzo `@@assign` dell'operatore allo stesso livello può sovrascrivere le impostazioni esistenti. Per ulteriori informazioni, consulta [Una politica secondaria sostituisce le impostazioni in una](#backup-policy-example-5) politica principale.
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.
Per ulteriori informazioni, consulta [Operatori di ereditarietà](policy-operators.md) ed esempi di [policy di Backup](#backup-policy-examples).
**Ruoli IAM**
Il ruolo IAM deve esistere quando si crea un piano di backup per la prima volta.
Il ruolo IAM deve avere l'autorizzazione ad accedere alle risorse identificate tramite tag query.
Il ruolo IAM deve disporre dell'autorizzazione per eseguire il backup.
**Casseforti di Backup**
I vault devono esistere in ogni area specificata Regioni AWS prima che un piano di backup possa essere eseguito.
I vault devono esistere per ogni AWS account che riceve la policy valida. Per ulteriori informazioni, consulta la sezione [Creazione ed eliminazione di Backup vault](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault.html) nella *AWS Backup Developer Guide*.
Ti consigliamo di utilizzare i set di AWS CloudFormation stack e la relativa integrazione con Organizations per creare e configurare automaticamente gli archivi di backup e i ruoli IAM per ogni account membro dell'organizzazione. Per ulteriori informazioni, consulta [Creazione di uno stack set con autorizzazioni gestite dal cliente](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-getting-started-create.html#create-stack-set-service-managed-permissions) nella *Guida per l'utente di AWS CloudFormation *.
**Quote**
*Per un elenco delle [AWS Backup quote, consulta la sezione Quotas](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-limits.html#aws-backup-policies-quotas-table) nella Developer Guide.AWS Backup *
## Sintassi di backup: panoramica
La sintassi della policy di backup include i seguenti componenti:
```
{
"plans": {
"PlanName": {
"rules": { ... },
"regions": { ... },
"selections": { ... },
"advanced_backup_settings": { ... },
"backup_plan_tags": { ... },
"scan_settings": { ... }
}
}
}
```
**Elementi della policy di Backup**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| [regole](#backup-policy-rules) | Elenco delle regole di backup. Ogni regola definisce quando vengono avviati i backup e la finestra di esecuzione per le risorse specificate negli selections elementi regions and. | Sì |
| [regioni](#backup-plan-regions) | Elenco delle aree Regioni AWS in cui una politica di backup può proteggere le risorse. | Sì |
| [selezioni](#backup-plan-selections) | Uno o più tipi di risorse entro i limiti specificati regions che il backup rules protegge. | Sì |
| [impostazioni di backup\$1avanzate](#advanced-backup-settings) | Opzioni di configurazione per scenari di backup specifici. Attualmente, l'unica impostazione di backup avanzata supportata è l'abilitazione dei backup Microsoft Volume Shadow Copy Service (VSS) per Windows o SQL Server in esecuzione su un'istanza Amazon EC2. | No |
| [backup\$1plan\$1tags](#backup-plan-tags) | Tag che desideri associare a un piano di backup. Ogni tag è un'etichetta composta da una chiave e un valore definiti dall'utente. I tag possono aiutarti a gestire, identificare, organizzare, cercare e filtrare i tuoi piani di backup. | No |
| [scan\$1settings](#scan-settings) | Opzioni di configurazione per le impostazioni di scansione. Attualmente l'unica impostazione di scansione supportata è abilitare Amazon GuardDuty Malware Protection for AWS Backup. | No |
## Sintassi di backup: regole
La chiave `rules` politica specifica le attività di backup pianificate AWS Backup eseguite sulle risorse selezionate.
**Elementi delle regole di Backup**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| schedule\$1expression | Espressione Cron in UTC che specifica quando AWS Backup avvia un processo di backup. Per informazioni sull'espressione cron, consulta [Using cron and rate expression to scheduling rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-scheduled-rule-pattern.html) nella *Amazon EventBridge User* Guide. | Sì |
| target\$1backup\$1vault\$1name | Archivio di backup in cui sono archiviati i backup. Gli archivi di Backup sono identificati da nomi univoci relativi all'account utilizzato per crearli e al Regione AWS luogo in cui sono stati creati. | Sì |
| target\$1logically\$1air\$1gapped\$1backup\$1vault\$1arn | ARN del vault con intercapedine logiche in cui vengono archiviati i backup. Se fornite, le risorse completamente gestite supportate vengono salvate direttamente nel vault logicamente airgapped, mentre altre risorse supportate creano un'istantanea temporanea (fatturabile) nel vault di backup, quindi la copiano in un archivio con sistema logico airgapped. Le risorse non supportate eseguono il backup solo nell'archivio di backup specificato. L'ARN deve utilizzare i segnaposto `$region` speciali e. `$account` Ad esempio, per un archivio denominato `AirGappedVault` il valore corretto è. `arn:aws:backup:$region:$account:backup-vault:AirGappedVault` | No |
| start\$1backup\$1window\$1minutes | Il numero di minuti di attesa prima di annullare un processo di backup verrà annullato se non viene avviato correttamente. Se questo valore è incluso, devono essere necessari almeno 60 minuti per evitare errori. | No |
| complete\$1backup\$1window\$1minutes | Numero di minuti dopo l'avvio corretto di un processo di backup prima che debba essere completato o verrà annullato entro. AWS Backup | No |
| enable\$1continuous\$1backup | Specifica se crea backup continui AWS Backup . `True`causa AWS Backup la creazione di backup continui in grado di point-in-time ripristinare (PITR). `False`(o non specificate) sono le cause della creazione AWS Backup di copie di backup istantanee. *Per ulteriori informazioni sui backup continui, consulta [P oint-in-time recovery](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html) nella Developer Guide.AWS Backup * **Nota:** i backup compatibili con PITR hanno una conservazione massima di 35 giorni. | No |
| lifecycle | Speciifica quando AWS Backup trasferisce un backup alla conservazione a freddo e quando scade. *I tipi di risorse che possono passare alla conservazione a freddo sono elencati nella tabella Disponibilità delle funzionalità per risorse La disponibilità delle [funzionalità per risorse nella Guida per](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource) gli AWS Backup sviluppatori.* Ogni ciclo di vita contiene i seguenti elementi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) **Nota**: i backup passati alla conservazione a freddo devono essere conservati in celle frigorifere per un minimo di 90 giorni. Ciò significa che `delete_after_days` deve essere superiore di 90 giorni a. `move_to_cold_storage_after_days` | No |
| copy\$1actions | Speciifica se AWS Backup copia un backup in una o più posizioni aggiuntive. Ogni azione di copia contiene i seguenti elementi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) **Nota**: i backup passati alla conservazione a freddo devono essere conservati in celle frigorifere per un minimo di 90 giorni. Ciò significa che `delete_after_days` deve essere superiore di 90 giorni a. `move_to_cold_storage_after_days` | No |
| recovery\$1point\$1tags | Tag da assegnare alle risorse ripristinate dal backup. Ogni tag contiene i seguenti elementi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | No |
| index\$1actions | Speciifica se AWS Backup crea un indice di backup degli snapshot di Amazon EBS, dei backup di Amazon S3 and/or . Gli indici di backup vengono creati per cercare i metadati dei backup. Per ulteriori informazioni sulla creazione dell'indice di backup e sulla ricerca di backup, vedere [Ricerca di backup](https://docs.aws.amazon.com//aws-backup/latest/devguide/backup-search.html#backup-search-overview). **Nota:** sono necessarie [autorizzazioni aggiuntive per i ruoli IAM](https://docs.aws.amazon.com//aws-backup/latest/devguide/backup-search.html#backup-search-access) per la creazione dell'indice di backup degli snapshot di Amazon EBS. Ogni azione di indicizzazione contiene il seguente elemento: `resource_types` dove i tipi di risorse supportati per l'indicizzazione sono Amazon EBS e Amazon S3. Questo parametro specifica quale tipo di risorsa verrà attivato per l'indicizzazione. | No |
| scan\$1actions | Speciifica se un'azione di scansione è abilitata per una determinata regola. È necessario specificare un`ScanMode`. È necessario utilizzare `scan_settings` nella policy di backup gli elementi della policy di backup insieme `scan_actions` a per avviare correttamente i processi di scansione. Assicurati inoltre di disporre delle [autorizzazioni corrette per i ruoli IAM](https://docs.aws.amazon.com//aws-backup/latest/devguide/malware-protection.html#malware-access). [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | No |
## Sintassi di backup: regioni
La chiave `regions` politica specifica quali risorse vengono Regioni AWS AWS Backup cercate per trovare le risorse che soddisfano le condizioni della chiave. `selections`
**Elementi delle regioni di Backup**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| regions | Specifica i Regione AWS codici. Ad esempio: `["us-east-1", "eu-north-1"]`. | Sì |
## Sintassi di backup: selezioni
La chiave di `selections` policy specifica le risorse di cui è eseguito il backup in base alle regole di una policy di backup.
Esistono due elementi che si escludono a vicenda: e. `tags` `resources` Per essere valida, una politica efficace **deve** includere `resources` i tag `have` o la selezione.
Se desideri una selezione con condizioni sia per i tag che per le risorse, usa i `resources` tasti.
**Elementi di selezione di backup: Tag**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| iam\$1role\$1arn | Ruolo IAM che AWS Backup presuppone l'interrogazione, l'individuazione e il backup delle risorse nelle regioni specificate. Il ruolo deve disporre di autorizzazioni sufficienti per interrogare le risorse in base alle condizioni dei tag ed eseguire operazioni di backup sulle risorse corrispondenti. | Sì |
| tag\$1key | Nome chiave del tag da cercare. | Sì |
| tag\$1value | Valore che deve essere associato alla tag\$1key corrispondente. AWS Backup include la risorsa solo se tag\$1key e tag\$1value corrispondono (distinzione tra maiuscole e minuscole). | Sì |
| conditions | Tagga le chiavi e i valori che desideri includere o escludere Usa string\$1equals o string\$1not\$1equals per includere o escludere tag con una corrispondenza esatta. Usa string\$1like e string\$1not\$1like per includere o escludere tag che contengono o non contengono caratteri specifici **Nota:** limitato a 30 condizioni per ogni selezione. | No |
**Elementi di selezione del backup: Risorse**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| iam\$1role\$1arn | Ruolo IAM che AWS Backup presuppone l'interrogazione, l'individuazione e il backup delle risorse nelle regioni specificate. Il ruolo deve disporre di autorizzazioni sufficienti per interrogare le risorse in base alle condizioni dei tag ed eseguire operazioni di backup sulle risorse corrispondenti. **Nota:** In AWS GovCloud (US) Regions, è necessario aggiungere il nome della partizione all'ARN. Ad esempio, "`arn:aws:ec2:*:*:volume/*`" deve essere "»`arn:aws-us-gov:ec2:*:*:volume/*`. | Sì |
| resource\$1types | Tipi di risorse da includere in un piano di backup. | Sì |
| not\$1resource\$1types | Tipi di risorse da escludere da un piano di backup. | No |
| conditions | Etichetta le chiavi e i valori che desideri includere o escludere Usa string\$1equals o string\$1not\$1equals per includere o escludere tag con una corrispondenza esatta. Usa string\$1like e string\$1not\$1like per includere o escludere tag che contengono o non contengono caratteri specifici **Nota:** limitato a 30 condizioni per ogni selezione. | No |
**Tipi di risorse supportati**
Organizations supporta i seguenti tipi di risorse per gli `not_resource_types` elementi `resource_types` and:
+ AWS Backup gateway macchine virtuali: `"arn:aws:backup-gateway:*:*:vm/*"`
+ AWS CloudFormation pile: `"arn:aws:cloudformation:*:*:stack/*"`
+ Tabelle Amazon DynamoDB: `"arn:aws:dynamodb:*:*:table/*"`
+ Istanze Amazon EC2: `"arn:aws:ec2:*:*:instance/*"`
+ Volumi Amazon EBS: `"arn:aws:ec2:*:*:volume/*"`
+ File system Amazon EFS: `"arn:aws:elasticfilesystem:*:*:file-system/*"`
+ Cluster Amazon Aurora/Amazon DocumentDB/Amazon Neptune: `"arn:aws:rds:*:*:cluster:*"`
+ Database Amazon RDS: `"arn:aws:rds:*:*:db:*"`
+ Cluster Amazon Redshift: `"arn:aws:redshift:*:*:cluster:*"`
+ Amazon S3: `"arn:aws:s3:::*"`
+ AWS Systems Manager per SAP Database HANA: `"arn:aws:ssm-sap:*:*:HANA/*"`
+ Gateway di archiviazione AWS gateway: `"arn:aws:storagegateway:*:*:gateway/*"`
+ Database Amazon Timestream: `"arn:aws:timestream:*:*:database/*"`
+ FSx File system Amazon: `"arn:aws:fsx:*:*:file-system/*"`
+ FSx Volumi Amazon: `"arn:aws:fsx:*:*:volume/*"`
+ Volumi Amazon Elastic Kubernetes Service: `"arn:aws:eks:*:*:cluster/*"`
**Esempi di codice**
Per ulteriori informazioni, consulta [Specificare le risorse con il blocco tags e Specificare le risorse con il blocco](#backup-policy-example-6) [resources](#backup-policy-example-7).
## Sintassi di backup: impostazioni di backup avanzate
La `advanced_backup_settings` chiave specifica le opzioni di configurazione per scenari di backup specifici. Ogni impostazione contiene i seguenti elementi:
**Elementi delle impostazioni di backup avanzate**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| advanced\$1backup\$1settings | Specificate le impostazioni per scenari di backup specifici. Questa chiave contiene una o più impostazioni. Ogni impostazione è una stringa di oggetto JSON con i seguenti elementi: Attualmente l'unica impostazione di backup avanzata supportata è l'abilitazione dei backup Microsoft Volume Shadow Copy Service (VSS) per Windows o SQL Server in esecuzione su un'istanza Amazon EC2. Ogni backup avanzato imposta i seguenti elementi: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | No |
**Esempio**:
```
"advanced_backup_settings": {
"ec2": {
"windows_vss": {
"@@assign": "enabled"
}
}
},
```
## Sintassi di backup: tag del piano di backup
La chiave `backup_plan_tags` politica specifica i tag allegati a un piano di backup stesso. Ciò non influisce sui tag specificati per `rules` o`selections`.
**Elementi del tag del piano di backup**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| backup\$1plan\$1tags | Ogni tag è un'etichetta composta da una chiave e un valore definiti dall'utente: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | No |
## Sintassi di backup: impostazioni di scansione
La chiave della `scan_settings` policy specifica la configurazione per la scansione del malware utilizzando Amazon GuardDuty Malware Protection for AWS Backup. È necessario utilizzare `scan_settings` in combinazione con `scan_actions` le regole di backup per avviare correttamente i processi di scansione.
**Elementi delle impostazioni di scansione**
| Elemento | Description | Richiesto |
| --- | --- | --- |
| scan\$1settings | Opzioni di configurazione per le impostazioni di scansione. Attualmente l'unica impostazione di scansione supportata è l'abilitazione di Amazon GuardDuty Malware Protection for AWS Backup. È necessario specificare `ResourceTypes` e`ScannerRoleArn`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_backup_syntax.html) | No |
**Esempio**:
Di seguito viene illustrato come configurare `scan_actions` in una regola di backup e `scan_settings` a livello di piano per abilitare la scansione di Amazon GuardDuty Malware Protection.
`scan_actions`in una regola:
```
"scan_actions": {
"GUARDDUTY": {
"scan_mode": {
"@@assign": "INCREMENTAL_SCAN"
}
}
}
```
`scan_settings`a livello di piano:
```
"scan_settings": {
"GUARDDUTY": {
"resource_types": {
"@@assign": ["EBS"]
},
"scanner_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyGuardDutyScannerRole"
}
}
}
```
## Esempi di policy di backup
Le policy di backup di esempio che seguono sono solo a scopo informativo. In alcuni degli esempi seguenti, la formattazione degli spazi bianchi JSON potrebbe essere compressa per risparmiare spazio.
+ [Esempio 1: policy assegnata a un nodo principale](#backup-policy-example-1)
+ [Esempio 2: una politica principale viene unita a una politica secondaria](#backup-policy-example-2)
+ [Esempio 3: una politica principale impedisce qualsiasi modifica da parte di una politica relativa ai figli](#backup-policy-example-3)
+ [Esempio 4: una politica principale impedisce la modifica di un piano di backup da parte di una politica secondaria](#backup-policy-example-4)
+ [Esempio 5: una politica per i figli ha la precedenza sulle impostazioni di una politica principale](#backup-policy-example-5)
+ [Esempio 6: Specificazione delle risorse con il blocco tags](#backup-policy-example-6)
+ [Esempio 7: Specificazione delle risorse con il blocco resources](#backup-policy-example-7)
+ [Esempio 8: piano di backup con scansione di Amazon GuardDuty Malware Protection](#backup-policy-example-8)
### Esempio 1: policy assegnata a un nodo padre
Nell'esempio seguente viene illustrata una policy di backup assegnata a uno dei nodi padre di un account.
**Policy padre** - Questa policy può essere collegata al root dell'organizzazione o a qualsiasi unità organizzativa che è un padre di tutti gli account previsti.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": {
"@@assign": [
"ap-northeast-2",
"us-east-1",
"eu-north-1"
]
},
"rules": {
"Hourly": {
"schedule_expression": {
"@@assign": "cron(0 5/1 ? * * *)"
},
"start_backup_window_minutes": {
"@@assign": "480"
},
"complete_backup_window_minutes": {
"@@assign": "10080"
},
"lifecycle": {
"move_to_cold_storage_after_days": {
"@@assign": "180"
},
"delete_after_days": {
"@@assign": "270"
},
"opt_in_to_archive_for_supported_resources": {
"@@assign": "false"
}
},
"target_backup_vault_name": {
"@@assign": "FortKnox"
},
"target_logically_air_gapped_backup_vault_arn": {
"@@assign": "arn:aws:backup:$region:$account:backup-vault:AirGappedVault"
},
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": {
"@@assign": "30"
},
"delete_after_days": {
"@@assign": "120"
},
"opt_in_to_archive_for_supported_resources": {
"@@assign": "false"
}
}
},
"arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": {
"@@assign": "30"
},
"delete_after_days": {
"@@assign": "120"
},
"opt_in_to_archive_for_supported_resources": {
"@@assign": "false"
}
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyIamRole"
},
"tag_key": {
"@@assign": "dataType"
},
"tag_value": {
"@@assign": [
"PII",
"RED"
]
}
}
}
},
"advanced_backup_settings": {
"ec2": {
"windows_vss": {
"@@assign": "enabled"
}
}
}
}
}
}
```
Se nessun'altra politica viene ereditata o associata agli account, la politica effettiva resa per ciascuna di esse è Account AWS simile all'esempio seguente. L'espressione CRON implica che il backup venga eseguito una volta all'ora. L'ID account 123456789012 sarà l'ID account effettivo per ogni account.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/1 ? * * *)",
"start_backup_window_minutes": "60",
"target_backup_vault_name": "FortKnox",
"target_logically_air_gapped_backup_vault_arn": "arn:aws:backup:$region:$account:backup-vault:AirGappedVault",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "2",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"delete_after_days": "28",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
},
"arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault": {
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-west-1:111111111111:backup-vault:tertiary_vault"
},
"lifecycle": {
"delete_after_days": "28",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [
"PII",
"RED"
]
}
}
},
"advanced_backup_settings": {
"ec2": {
"windows_vss": "enabled"
}
}
}
}
}
```
### Esempio 2: una policy padre viene unita a una policy figlio
Nell'esempio seguente, una politica ereditata per i genitori e una politica per i figli sono ereditate o direttamente collegate a un' Account AWS unione per formare la politica effettiva.
**Policy padre** - Questa policy può essere collegata al root dell'organizzazione o a qualsiasi unità organizzativa padre.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": { "@@append":[ "us-east-1", "ap-northeast-3", "eu-north-1" ] },
"rules": {
"Hourly": {
"schedule_expression": { "@@assign": "cron(0 0/1 ? * * *)" },
"start_backup_window_minutes": { "@@assign": "60" },
"target_backup_vault_name": { "@@assign": "FortKnox" },
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "28" },
"delete_after_days": { "@@assign": "180" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" : {
"target_backup_vault_arn" : {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "28" },
"delete_after_days": { "@@assign": "180" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyIamRole" },
"tag_key": { "@@assign": "dataType" },
"tag_value": { "@@assign": [ "PII", "RED" ] }
}
}
}
}
}
}
```
**Policy figlia** - Questa policy può essere collegata direttamente all'account o a un'unità organizzativa che si trova a un livello inferiore qualsiasi a quello della policy padre cui è collegata.
```
{
"plans": {
"Monthly_Backup_Plan": {
"regions": {
"@@append":[ "us-east-1", "eu-central-1" ] },
"rules": {
"Monthly": {
"schedule_expression": { "@@assign": "cron(0 5 1 * ? *)" },
"start_backup_window_minutes": { "@@assign": "480" },
"target_backup_vault_name": { "@@assign": "Default" },
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "30" },
"delete_after_days": { "@@assign": "365" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:Default" : {
"target_backup_vault_arn" : {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:Default"
},
"lifecycle": {
"move_to_cold_storage_after_days": { "@@assign": "30" },
"delete_after_days": { "@@assign": "365" },
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"MonthlyDatatype": {
"iam_role_arn": { "@@assign": "arn:aws:iam::$account:role/MyMonthlyBackupIamRole" },
"tag_key": { "@@assign": "BackupType" },
"tag_value": { "@@assign": [ "MONTHLY", "RED" ] }
}
}
}
}
}
}
```
**Policy effettiva risultante** - La policy effettiva applicata agli account contiene due piani, ciascuno con un proprio set di regole e un set di risorse a cui applicare le regole.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [ "us-east-1", "ap-northeast-3", "eu-north-1" ],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/1 ? * * *)",
"start_backup_window_minutes": "60",
"target_backup_vault_name": "FortKnox",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "2",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault" : {
"target_backup_vault_arn" : {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"
},
"lifecycle": {
"move_to_cold_storage_after_days": "28",
"delete_after_days": "180",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::$account:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [ "PII", "RED" ]
}
}
}
},
"Monthly_Backup_Plan": {
"regions": [ "us-east-1", "eu-central-1" ],
"rules": {
"monthly": {
"schedule_expression": "cron(0 5 1 * ? *)",
"start_backup_window_minutes": "480",
"target_backup_vault_name": "Default",
"lifecycle": {
"delete_after_days": "365",
"move_to_cold_storage_after_days": "30",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:Default" : {
"target_backup_vault_arn": {
"@@assign" : "arn:aws:backup:us-east-1:$account:backup-vault:Default"
},
"lifecycle": {
"move_to_cold_storage_after_days": "30",
"delete_after_days": "365",
"opt_in_to_archive_for_supported_resources": { "@@assign": "false" }
}
}
}
}
},
"selections": {
"tags": {
"monthlydatatype": {
"iam_role_arn": "arn:aws:iam::&ExampleAWSAccountNo3;:role/MyMonthlyBackupIamRole",
"tag_key": "BackupType",
"tag_value": [ "MONTHLY", "RED" ]
}
}
}
}
}
}
```
### Esempio 3: una policy padre impedisce qualsiasi modifica da parte di una policy figlio
Nell'esempio seguente, una policy padre ereditata utilizza gli [operatori di controllo figlio](policy-operators.md#child-control-operators) per imporre tutte le impostazioni e impedisce che vengano modificate o sostituite da una policy figlio.
**Policy padre** - Questa policy può essere collegata al root dell'organizzazione o a qualsiasi unità organizzativa padre. La presenza di `"@@operators_allowed_for_child_policies": ["@@none"]` in ogni nodo della policy significa che una policy figlio non può apportare modifiche di alcun tipo al piano. Né una policy figlio può aggiungere altri piani alla policy effettiva. Questa policy diventa la policy effettiva per ogni unità organizzativa e account nell'unità organizzativa cui è collegata.
```
{
"plans": {
"@@operators_allowed_for_child_policies": ["@@none"],
"PII_Backup_Plan": {
"@@operators_allowed_for_child_policies": ["@@none"],
"regions": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@append": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
]
},
"rules": {
"@@operators_allowed_for_child_policies": ["@@none"],
"Hourly": {
"@@operators_allowed_for_child_policies": ["@@none"],
"schedule_expression": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "cron(0 0/1 ? * * *)"
},
"start_backup_window_minutes": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "60"
},
"target_backup_vault_name": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "FortKnox"
},
"index_actions": {
"@@operators_allowed_for_child_policies": ["@@none"],
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"@@operators_allowed_for_child_policies": ["@@none"],
"move_to_cold_storage_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "28"
},
"delete_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "180"
},
"opt_in_to_archive_for_supported_resources": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "false"
}
},
"copy_actions": {
"@@operators_allowed_for_child_policies": ["@@none"],
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"@@operators_allowed_for_child_policies": ["@@none"],
"target_backup_vault_arn": {
"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault",
"@@operators_allowed_for_child_policies": ["@@none"]
},
"lifecycle": {
"@@operators_allowed_for_child_policies": ["@@none"],
"delete_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "28"
},
"move_to_cold_storage_after_days": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "180"
},
"opt_in_to_archive_for_supported_resources": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "false"
}
}
}
}
}
},
"selections": {
"@@operators_allowed_for_child_policies": ["@@none"],
"tags": {
"@@operators_allowed_for_child_policies": ["@@none"],
"datatype": {
"@@operators_allowed_for_child_policies": ["@@none"],
"iam_role_arn": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "arn:aws:iam::$account:role/MyIamRole"
},
"tag_key": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "dataType"
},
"tag_value": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": [
"PII",
"RED"
]
}
}
}
},
"advanced_backup_settings": {
"@@operators_allowed_for_child_policies": ["@@none"],
"ec2": {
"@@operators_allowed_for_child_policies": ["@@none"],
"windows_vss": {
"@@assign": "enabled",
"@@operators_allowed_for_child_policies": ["@@none"]
}
}
}
}
}
}
```
**Policy effettiva risultante** - Se esistono policy di backup figlio, queste vengono ignorate e la policy padre diventa la policy effettiva.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/1 ? * * *)",
"start_backup_window_minutes": "60",
"target_backup_vault_name": "FortKnox",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "2",
"move_to_cold_storage_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
},
"copy_actions": {
"target_backup_vault_arn": "arn:aws:backup:us-east-1:123456789012:backup-vault:secondary_vault",
"lifecycle": {
"move_to_cold_storage_after_days": "28",
"delete_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::123456789012:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [
"PII",
"RED"
]
}
}
},
"advanced_backup_settings": {
"ec2": {"windows_vss": "enabled"}
}
}
}
}
```
### Esempio 4: una policy padre impedisce modifiche a un piano di backup da parte di una policy figlio
Nell'esempio seguente, una policy padre ereditata utilizza gli [operatori di controllo figlio](policy-operators.md#child-control-operators) per imporre le impostazioni per un singolo piano e impedisce che vengano modificate o sostituite da una policy figlio. La policy figlio può comunque aggiungere altri piani.
**Policy padre** - Questa policy può essere collegata al root dell'organizzazione o a qualsiasi unità organizzativa padre. Questo esempio è simile all'esempio precedente con tutti gli operatori di ereditarietà figlio bloccati, ad eccezione del livello superiore `plans`. L'impostazione `@@append` a tale livello consente alle policy figlio di aggiungere altri piani alla raccolta nella policy effettiva. Le eventuali modifiche apportate al piano ereditato sono ancora bloccate.
Le sezioni del piano vengono troncate per chiarezza.
```
{
"plans": {
"@@operators_allowed_for_child_policies": ["@@append"],
"PII_Backup_Plan": {
"@@operators_allowed_for_child_policies": ["@@none"],
"regions": { ... },
"rules": { ... },
"selections": { ... }
}
}
}
```
**Policy figlia** - Questa policy può essere collegata direttamente all'account o a un'unità organizzativa che si trova a un livello inferiore qualsiasi a quello della policy padre cui è collegata. Questa policy figlio definisce un nuovo piano.
Le sezioni del piano vengono troncate per chiarezza.
```
{
"plans": {
"MonthlyBackupPlan": {
"regions": { ... },
"rules": { ... },
"selections": { … }
}
}
}
```
**Policy effettiva risultante** - La policy effettiva include entrambi i piani.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": { ... },
"rules": { ... },
"selections": { ... }
},
"MonthlyBackupPlan": {
"regions": { ... },
"rules": { ... },
"selections": { … }
}
}
}
```
### Esempio 5: una policy figlio sostituisce le impostazioni in una policy padre
Nell'esempio seguente, una policy figlia utilizza [operatori di impostazione del valore](policy-operators.md#value-setting-operators) per sovrascrivere alcune delle impostazioni ereditate da una policy padre.
**Policy padre** - Questa policy può essere collegata al root dell'organizzazione o a qualsiasi unità organizzativa padre. Qualsiasi impostazione può essere sovrascritta da una policy figlio perché il comportamento predefinito, in assenza di un [operatore di controllo figlio](policy-operators.md#child-control-operators) che lo impedisce, è quello di consentire alla policy figlio di `@@assign`, `@@append` o `@@remove`. La policy padre contiene tutti gli elementi necessari per un piano di backup valido, quindi esegue correttamente il backup delle risorse se viene ereditata così com'è.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": {
"@@append": [
"us-east-1",
"ap-northeast-3",
"eu-north-1"
]
},
"rules": {
"Hourly": {
"schedule_expression": {"@@assign": "cron(0 0/1 ? * * *)"},
"start_backup_window_minutes": {"@@assign": "60"},
"target_backup_vault_name": {"@@assign": "FortKnox"},
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": {"@@assign": "2"},
"move_to_cold_storage_after_days": {"@@assign": "180"},
"opt_in_to_archive_for_supported_resources": {"@@assign": false}
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:t2": {
"target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:t2"},
"lifecycle": {
"move_to_cold_storage_after_days": {"@@assign": "28"},
"delete_after_days": {"@@assign": "180"},
"opt_in_to_archive_for_supported_resources": {"@@assign": false}
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/MyIamRole"},
"tag_key": {"@@assign": "dataType"},
"tag_value": {
"@@assign": [
"PII",
"RED"
]
}
}
}
}
}
}
}
```
**Policy figlia** - La policy figlia include solo le impostazioni che devono essere diverse dalla policy padre ereditata. È necessario disporre di una policy padre ereditata che fornisca le altre impostazioni necessarie quando viene unita in una policy effettiva. In caso contrario, la policy di backup effettiva contiene un piano di backup che non è valido e non esegue il backup delle risorse come previsto.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": {
"@@assign": [
"us-west-2",
"eu-central-1"
]
},
"rules": {
"Hourly": {
"schedule_expression": {"@@assign": "cron(0 0/2 ? * * *)"},
"start_backup_window_minutes": {"@@assign": "80"},
"target_backup_vault_name": {"@@assign": "Default"},
"lifecycle": {
"move_to_cold_storage_after_days": {"@@assign": "30"},
"delete_after_days": {"@@assign": "365"},
"opt_in_to_archive_for_supported_resources": {"@@assign": false}
}
}
}
}
}
}
```
**Policy effettiva risultante** - La policy effettiva include le impostazioni di entrambe le policy, con le impostazioni fornite dalla policy figlio che sovrascrivono le impostazioni ereditate dal padre. In questo esempio, si verificano le seguenti modifiche:
+ L'elenco delle regioni viene sostituito con un elenco completamente diverso. Se desideri aggiungere una Regione all'elenco ereditato, utilizza `@@append` anziché `@@assign` nella policy figlia.
+ AWS Backup viene eseguito ogni due ore anziché ogni ora.
+ AWS Backup consente l'avvio del backup per 80 minuti anziché 60 minuti.
+ AWS Backup utilizza il `Default` vault invece di. `FortKnox`
+ Il ciclo di vita viene esteso sia per il trasferimento nello storage a freddo sia per l'eliminazione finale del backup.
```
{
"plans": {
"PII_Backup_Plan": {
"regions": [
"us-west-2",
"eu-central-1"
],
"rules": {
"hourly": {
"schedule_expression": "cron(0 0/2 ? * * *)",
"start_backup_window_minutes": "80",
"target_backup_vault_name": "Default",
"index_actions": {
"resource_types": {
"@@assign": [
"EBS",
"S3"
]
}
},
"lifecycle": {
"delete_after_days": "365",
"move_to_cold_storage_after_days": "30",
"opt_in_to_archive_for_supported_resources": "false"
},
"copy_actions": {
"arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault": {
"target_backup_vault_arn": {"@@assign": "arn:aws:backup:us-east-1:$account:backup-vault:secondary_vault"},
"lifecycle": {
"move_to_cold_storage_after_days": "28",
"delete_after_days": "180",
"opt_in_to_archive_for_supported_resources": "false"
}
}
}
}
},
"selections": {
"tags": {
"datatype": {
"iam_role_arn": "arn:aws:iam::$account:role/MyIamRole",
"tag_key": "dataType",
"tag_value": [
"PII",
"RED"
]
}
}
}
}
}
}
```
### Esempio 6: Specificazione delle risorse con il blocco `tags`
L'esempio seguente include tutte le risorse con `tag_key` = `“env”` e `tag_value` = `"prod"` o`"gamma"`. Questo esempio esclude le risorse con `tag_key` = `"backup"` e `tag_value` =`"false"`.
```
...
"selections":{
"tags":{
"selection_name":{
"iam_role_arn": {"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"tag_key":{"@@assign": "env"},
"tag_value":{"@@assign": ["prod", "gamma"]},
"conditions":{
"string_not_equals":{
"condition_name1":{
"condition_key": { "@@assign": "aws:ResourceTag/backup" },
"condition_value": { "@@assign": "false" }
}
}
}
}
}
},
...
```
### Esempio 7: Specificazione delle risorse con il blocco `resources`
Di seguito sono riportati alcuni esempi di utilizzo del `resources` blocco per specificare le risorse.
------
#### [ Example: Select all resources in my account ]
La logica booleana è simile a quella che potresti usare nelle policy IAM. Il `"resource_types"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
}
}
},
...
```
------
#### [ Example: Select all resources in my account, but exclude Amazon EBS volumes ]
La logica booleana è simile a quella che potresti usare nelle politiche IAM. I `"not_resource_types"` blocchi `"resource_types"` and utilizzano un valore booleano `AND` per combinare i tipi di risorse.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"not_resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*"
]
}
}
},
...
```
------
#### [ Example: Select all resources tagged with "backup" : "true", but exclude Amazon EBS volumes ]
La logica booleana è simile a quella che potresti usare nelle policy IAM. I `"not_resource_types"` blocchi `"resource_types"` and utilizzano un valore booleano `AND` per combinare i tipi di risorse. Il `"conditions"` blocco utilizza un valore booleano. `AND`
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"not_resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key": { "@@assign":"aws:ResourceTag/backup"},
"condition_value": { "@@assign":"true" }
}
}
}
}
},
...
```
------
#### [ Example: Select all Amazon EBS volumes and Amazon RDS DB instances tagged with both "backup" : "true" and "stage" : "prod" ]
La logica booleana è simile a quella che potresti usare nelle politiche IAM. Il `"resource_types"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse. Il `"conditions"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse e le condizioni dei tag.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:rds:*:*:db:*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/backup"},
"condition_value":{"@@assign":"true"}
},
"condition_name2":{
"condition_key":{"@@assign":"aws:ResourceTag/stage"},
"condition_value":{"@@assign":"prod"}
}
}
}
}
},
...
```
------
#### [ Example: Select all Amazon EBS volumes and Amazon RDS instances tagged with "backup" : "true" but not "stage" : "test" ]
La logica booleana è simile a quella che potresti usare nelle politiche IAM. Il `"resource_types"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse. Il `"conditions"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse e le condizioni dei tag.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"arn:aws:ec2:*:*:volume/*",
"arn:aws:rds:*:*:db:*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/backup"},
"condition_value":{"@@assign":"true"}
}
},
"string_not_equals":{
"condition_name2":{
"condition_key":{"@@assign":"aws:ResourceTag/stage"},
"condition_value":{"@@assign":"test"}
}
}
}
}
},
...
```
------
#### [ Example: Select all resources tagged with "key1" and a value which begins with "include" but not with "key2" and value that contains the word "exclude" ]
La logica booleana è simile a quella che potresti usare nelle politiche IAM. Il `"resource_types"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse. Il `"conditions"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse e le condizioni dei tag.
In questo esempio, nota l'uso del carattere jolly `(*)` in`include*`, `*exclude*` e. `arn:aws:rds:*:*:db:*` È possibile utilizzare il carattere jolly `(*)` all'inizio, alla fine e al centro di una stringa.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"conditions":{
"string_like":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/key1"},
"condition_value":{"@@assign":"include*"}
}
},
"string_not_like":{
"condition_name2":{
"condition_key":{"@@assign":"aws:ResourceTag/key2"},
"condition_value":{"@@assign":"*exclude*"}
}
}
}
}
},
...
```
------
#### [ Example: Select all resources tagged with "backup" : "true" except Amazon FSx file systems and Amazon RDS resources ]
La logica booleana è simile a quella che potresti usare nelle policy IAM. I `"not_resource_types"` blocchi `"resource_types"` and utilizzano un valore booleano `AND` per combinare i tipi di risorse. Il `"conditions"` blocco utilizza un valore booleano `AND` per combinare i tipi di risorse e le condizioni dei tag.
```
...
"resources":{
"resource_selection_name":{
"iam_role_arn":{"@@assign": "arn:aws:iam::$account:role/IAMRole"},
"resource_types":{
"@@assign": [
"*"
]
},
"not_resource_types":{
"@@assign":[
"arn:aws:fsx:*:*:file-system/*",
"arn:aws:rds:*:*:db:*"
]
},
"conditions":{
"string_equals":{
"condition_name1":{
"condition_key":{"@@assign":"aws:ResourceTag/backup"},
"condition_value":{"@@assign":"true"}
}
}
}
}
},
...
```
------
### Esempio 8: piano di backup con scansione di Amazon GuardDuty Malware Protection
L'esempio seguente mostra una policy di backup che abilita la scansione di Amazon GuardDuty Malware Protection sui punti di ripristino del backup. La policy utilizza `scan_actions` la regola per abilitare la scansione e, `scan_settings` a livello di piano, per configurare lo scanner.
Per utilizzare questa funzionalità, è necessario disporre delle autorizzazioni di ruolo IAM appropriate. Per ulteriori informazioni, consulta [Access](https://docs.aws.amazon.com//aws-backup/latest/devguide/malware-protection.html#malware-access) nella *AWS Backup Developer Guide*.
```
{
"plans": {
"Malware_Scan_Backup_Plan": {
"regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"rules": {
"Daily_With_Incremental_Scan": {
"schedule_expression": {
"@@assign": "cron(0 5 ? * * *)"
},
"start_backup_window_minutes": {
"@@assign": "60"
},
"target_backup_vault_name": {
"@@assign": "Default"
},
"lifecycle": {
"delete_after_days": {
"@@assign": "35"
}
},
"scan_actions": {
"GUARDDUTY": {
"scan_mode": {
"@@assign": "INCREMENTAL_SCAN"
}
}
}
},
"Monthly_With_Full_Scan": {
"schedule_expression": {
"@@assign": "cron(0 5 1 * ? *)"
},
"start_backup_window_minutes": {
"@@assign": "60"
},
"target_backup_vault_name": {
"@@assign": "Default"
},
"lifecycle": {
"delete_after_days": {
"@@assign": "365"
}
},
"scan_actions": {
"GUARDDUTY": {
"scan_mode": {
"@@assign": "FULL_SCAN"
}
}
}
}
},
"selections": {
"tags": {
"scan_selection": {
"iam_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyBackupRole"
},
"tag_key": {
"@@assign": "backup"
},
"tag_value": {
"@@assign": [
"true"
]
}
}
}
},
"scan_settings": {
"GUARDDUTY": {
"resource_types": {
"@@assign": [
"EBS"
]
},
"scanner_role_arn": {
"@@assign": "arn:aws:iam::$account:role/MyGuardDutyScannerRole"
}
}
}
}
}
}
```
I punti chiave di questo esempio sono:
+ `scan_actions`è specificato all'interno di ogni regola. Il nome dello scanner `GUARDDUTY` viene utilizzato come chiave. La regola giornaliera utilizza `INCREMENTAL_SCAN` e la regola mensile utilizza`FULL_SCAN`.
+ `scan_settings`è specificato a livello di piano (non all'interno di una regola). Configura il ruolo dello scanner e i tipi di risorse da scansionare.
+ `scanner_role_arn`Devono fare riferimento a un ruolo IAM con la policy `AWSBackupGuardDutyRolePolicyForScans` gestita allegata e una policy di fiducia che consenta al responsabile del `malware-protection.guardduty.amazonaws.com` servizio di assumere il ruolo.
# Policy di tag
Le politiche relative ai tag consentono di standardizzare i tag associati alle AWS risorse negli account dell'organizzazione.
È possibile utilizzare le politiche relative ai tag per mantenere la coerenza dei tag, inclusa la preferenza tra maiuscole e minuscole per le chiavi e i valori dei tag.
## Cosa sono i tag?
I *tag* sono etichette di attributi personalizzate che assegnate o assegnate alle AWS AWS risorse. Ogni tag è costituito da due parti:
+ Una *chiave del tag* (ad esempio, `CostCenter`, `Environment` o `Project`). Le chiavi dei tag prevedono una distinzione tra lettere maiuscole e minuscole.
+ Un campo facoltativo noto come *valore del tag* (ad esempio, `111122223333` o `Production`). Non specificare il valore del tag equivale a utilizzare una stringa vuota. Come le chiavi dei tag, i valori dei tag distinguono tra maiuscole e minuscole.
Il resto di questa pagina descrive le policy di tag. Per ulteriori informazioni sui tag, consulta i seguenti argomenti:
+ Per informazioni generali sull'etichettatura, incluse le convenzioni di denominazione e utilizzo, consulta la [https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) Resources User Guide.
+ Per un elenco dei servizi che supportano l'utilizzo dei tag, consulta l'argomento della documentazione di [https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/Welcome.html).
+ Per informazioni sull'utilizzo dei tag per classificare le risorse, consultate il white paper sulle [https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) per l'etichettatura delle risorse. AWS
+ Per informazioni sull'assegnazione di tag alle risorse di Organizations, consulta [Taggare le risorse AWS OrganizationsConsiderazioni](orgs_tagging.md).
+ Per informazioni sull'etichettatura delle risorse in altri Servizi AWS, consulta la documentazione relativa a tale servizio.
## Che cosa sono le policy di tag?
Le *policy di tag* sono un tipo di policy che può semplificare la standardizzazione dei tag tra le risorse degli account dell'organizzazione. In una policy di tag specifichi le regole di tag applicabili alle risorse quando vengono taggate.
Ad esempio, una policy di tag può specificare che quando il tag `CostCenter` è collegato a una risorsa, deve utilizzare i valori di trattamento lettere maiuscole o minuscole e di tag definiti dalla policy di tag. Una policy di tag può anche specificare che le operazioni di tag non conformi vengono *applicate* su tipi di risorse specifici. In altre parole, le richieste di tag non conformi su tipi di risorse specifici non possono essere completate. Le risorse senza tag o i tag non sono definiti nella policy di tag non vengono valutati per la conformità con la policy di tag.
L'utilizzo delle politiche di tag implica l'utilizzo di più Servizi AWS:
+ Utilizza **AWS Organizations** per gestire le *policy di tag*. Quando effettui l'accesso all'account di gestione dell'organizzazione, puoi usare Organizations per abilitare la caratteristica delle policy di tag. È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione. Quindi, puoi creare le policy di tag e collegarle alle entità dell'organizzazione per rendere effettive tali regole di tag.
+ Utilizza **AWS Resource Groups** per gestire la *conformità* con le policy di tag. Quando effettui l'accesso a un account dell'organizzazione, puoi utilizzare Resource Groups per trovare tag non conformi nelle risorse dell'account. È possibile correggere i tag non conformi nel AWS servizio in cui è stata creata la risorsa. Puoi anche utilizzare [Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-editor.html) e l'API [Resource Groups Tagging](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/overview.html) per etichettare e rimuovere i tag da più servizi.
Se accedi all'account di gestione nell'organizzazione, puoi visualizzare le informazioni di conformità per tutti gli account dell'organizzazione.
Le policy di tag sono disponibili solo nelle organizzazioni in cui sono [abilitate tutte le caratteristiche](orgs_manage_org_support-all-features.md). Per ulteriori informazioni sui requisiti per utilizzare le policy di tag, consulta [Prerequisiti e autorizzazioni per le politiche di gestione per AWS Organizations](orgs_manage_policies_prereqs.md).
**Importante**
Per iniziare con le politiche sui tag, ti AWS consigliamo vivamente di seguire il flusso di lavoro di esempio descritto in [Nozioni di base sulle policy di tag](orgs_manage_policies_tag-policies-getting-started.md) prima di passare a politiche di tag più avanzate. È meglio comprendere gli effetti del collegamento di una policy di tag semplice a un singolo account prima di espandere le policy di tag a un'intera unità organizzativa o a un'organizzazione. È particolarmente importante comprendere gli effetti di una policy di tag prima di *applicare* la conformità a qualsiasi policy di tag. Le tabelle della pagina [Nozioni di base sulle policy di tag](orgs_manage_policies_tag-policies-getting-started.md) forniscono anche i collegamenti alle istruzioni per le attività più avanzate relative alle policy.
# Best practice per l'utilizzo delle policy di tag
AWS consiglia le seguenti best practice per l'utilizzo delle politiche relative ai tag.
## Decidi una strategia di capitalizzazione dei tag
Determina come desideri capitalizzare i tag e implementa in modo coerente tale strategia in tutti i tipi di risorse. Ad esempio, puoi decidere se utilizzare `Costcenter`, `costcenter` o `CostCenter` e utilizzare la stessa convenzione per tutti i tag. Per risultati coerenti nei report di conformità, evita di utilizzare tag simili con un trattamento lettere maiuscole o minuscole incoerente. Questa strategia consente di definire le policy di tag per l'organizzazione.
## Utilizza il flusso di lavoro consigliato
Inizia in piccolo creando una semplice policy di tag. Quindi collegala a un account membro che puoi usare a scopo di test. Utilizza i flussi di lavoro descritti in [Nozioni di base sulle policy di tag](orgs_manage_policies_tag-policies-getting-started.md).
## Determina le regole di tagging
Questo dipenderà dalle esigenze dell'organizzazione. Ad esempio, potresti voler specificare che quando un `CostCenter` tag è associato a Gestione dei segreti AWS segreti, deve utilizzare il trattamento dei casi specificato. Crea le policy di tag che definiscono tag conformi e collegali alle entità dell'organizzazione in cui vuoi che tali regole di tag siano in vigore.
## Istruire gli amministratori degli account
Quando sei pronto a espandere l'utilizzo delle policy di tag, istruisci gli amministratori degli account come segue:
+ Comunica la tua strategia di tag.
+ Sottolinea che gli amministratori devono utilizzare i tag su tipi di risorse specifici.
Questo è importante perché le risorse senza tag non vengono visualizzate come non conformi nei risultati di conformità.
+ Fornisci le indicazioni per verificare la conformità con le policy di tag. *Chiedi agli amministratori di trovare e correggere i tag non conformi sulle risorse del loro account utilizzando la procedura descritta nella sezione [Evaluating Compliance for an Account nella Tagging Resource User Guide](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html). AWS * Indica la frequenza con cui desideri che verifichino la conformità.
## Usa cautela nell'applicare la conformità
L'applicazione della conformità potrebbe impedire agli utenti degli account dell'organizzazione di applicare i tag alle risorse necessarie. Rivedi le informazioni in [Applica la coerenza dei tag](orgs_manage_policies_tag-policies-enforcement.md). Consulta anche i flussi di lavoro descritti in [Nozioni di base sulle policy di tag](orgs_manage_policies_tag-policies-getting-started.md).
## Sii consapevole dei limiti di etichettatura
AWS i servizi hanno generalmente un limite di 50 tag definiti dall'utente che non possono essere modificati. Quando utilizzi funzionalità come Report Required Tags, assicurati che le politiche efficaci della tua organizzazione non superino i 50 tag obbligatori per un determinato tipo di risorsa. Il superamento di questo limite può causare due problemi: le risorse potrebbero non essere in grado di raggiungere lo stato di conformità nei riepiloghi di conformità e le piattaforme Infrastructure as Code (IaC) potrebbero non riuscire a creare risorse quando sono definiti più di 50 tag come richiesti.
## Considera la possibilità di creare una SCP per impostare dei limiti attorno alle richieste di creazione di risorse
Le risorse a cui non sono mai stati associati tag non vengono visualizzate come non conformi nei report. Gli amministratori dell'account possono comunque creare risorse senza tag. In alcuni casi, è possibile utilizzare una policy di controllo dei servizi per impostare i guardrail attorno alle richieste di creazione delle risorse.
*Per sapere se un AWS servizio supporta il controllo dell'accesso tramite tag, consulta Servizi AWS That [Work with IAM nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) User Guide.* Cerca i servizi con **Sì** nella colonna **ABAC (autorizzazione basata sui tag)**. Scegli il nome del servizio per visualizzarne la documentazione sul controllo degli accessi e delle autorizzazioni.
# Nozioni di base sulle policy di tag
L'utilizzo delle politiche dei tag implica l'utilizzo di più criteri Servizi AWS. Per iniziare, esamina le pagine seguenti. Segui quindi i flussi di lavoro in questa pagina per familiarizzare con le policy di tag e i loro effetti.
+ [Prerequisiti e autorizzazioni per le politiche di gestione per AWS Organizations](orgs_manage_policies_prereqs.md)
+ [Best practice per l'utilizzo delle policy di tag](orgs_manage_policies_tag-policies-best-practices.md)
## Utilizzo delle policy di tag per la prima volta
Attieniti alla seguente procedura per iniziare a utilizzare le policy di tag per la prima volta.
| Operazione | Account a cui accedere | AWS console di servizio da usare |
| --- | --- | --- |
| Fase 1: [abilita le policy di tag per l'organizzazione.](enable-policy-type.md) | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Fase 2: [crea una policy di tag](orgs_policies_create.md#create-tag-policy-procedure). Mantieni semplice la tua prima policy di tag. Inserisci una chiave di tag nel trattamento lettere maiuscole o minuscole che desideri utilizzare e lascia tutte le altre opzioni sulle impostazioni predefinite. | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Fase 3: [collega una policy di tag a un singolo account membro che è possibile utilizzare per il test.](orgs_policies_attach.md) Dovrai accedere a questo account nella prossima fase. | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Fase 4: crea alcune risorse con tag conformi e alcune con tag non conformi. | L'account membro che stai utilizzando a scopo di test. | Qualsiasi AWS servizio con cui ti senti a tuo agio. Ad esempio, puoi utilizzare [Gestione dei segreti AWS](https://console.aws.amazon.com/secretsmanager/) e seguire la procedura in [Creazione di un segreto di base](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) per creare segreti con segreti conformi e non conformi. |
| Fase 5: [visualizza le policy di tag operative e valutare lo stato di conformità dell'account.](https://docs.aws.amazon.com/tag-editor/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | L'account membro che stai utilizzando a scopo di test. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e il AWS servizio in cui è stata creata la risorsa. Se sono state create risorse con tag conformi e non conformi, i tag non conformi vengono visualizzati nei risultati. |
| Fase 6: ripeti il processo di individuazione e correzione dei problemi di conformità fino a quando le risorse dell'account di test non siano conformi alla policy di tag. | L'account membro che stai utilizzando a scopo di test. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e il AWS servizio in cui è stata creata la risorsa. |
| In qualsiasi momento, puoi [valutare la conformità a livello di organizzazione](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). | Account di gestione dell'organizzazione.¹ | [Gruppi di risorse](https://console.aws.amazon.com/resource-groups/) |
¹ È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
## Espansione dell'uso delle policy di tag
Per espandere l'utilizzo delle policy di tag puoi eseguire le seguenti attività in qualsiasi ordine.
| Attività avanzata | Account a cui accedere | AWS console di servizio da utilizzare |
| --- | --- | --- |
| [Creare policy di tag avanzate](orgs_policies_create.md#create-tag-policy-procedure). Segui lo stesso processo degli utenti inesperti, ma prova altre attività. Ad esempio, definisci chiavi o valori aggiuntivi o specifica un trattamento lettere maiuscole o minuscole diverso per una chiave di tag. Puoi utilizzare le informazioni in [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md) e [Sintassi delle policy di tag](orgs_manage_policies_example-tag-policies.md#tag-policy-syntax-reference) per creare policy di tag più dettagliate. | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| [Allega le politiche sui tag ad account aggiuntivi o OUs.](orgs_policies_attach.md) Controlla la [policy di tag operativa per un account](orgs_manage_policies_effective.md) dopo aver collegato altre policy all'account o a qualsiasi unità organizzativa in cui l'account è membro. | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Crea una policy di controllo dei servizi per richiedere i tag quando vengono create nuove risorse. | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| [ Continua a valutare lo stato di conformità dell'account rispetto alla policy di tag operativa man mano che cambia. Correggi i tag non conformi.](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | Un account membro con una policy di tag attiva. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e il AWS servizio in cui è stata creata la risorsa. |
| [ Valuta la conformità a livello di organizzazione](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). | Account di gestione dell'organizzazione.¹ | [Gruppi di risorse](https://console.aws.amazon.com/resource-groups/) |
¹ È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
## Applicazione delle policy di tag per la prima volta
Per applicare le policy di tag per la prima volta, segui un flusso di lavoro simile all'utilizzo delle policy di tag per la prima volta e utilizza un account di test.
**avvertimento**
Usa cautela nell'applicare la conformità. Assicurati di aver compreso gli effetti dell'utilizzo delle policy di tag e segui il flusso di lavoro raccomandato. Verifica il funzionamento dell'applicazione in un account di test prima di espanderla a più account. In caso contrario, potresti impedire agli utenti degli account dell'organizzazione di applicare i tag alle risorse necessarie. Per ulteriori informazioni, consulta [Applica la coerenza dei tag](orgs_manage_policies_tag-policies-enforcement.md).
| Attività di applicazione | Account a cui accedere | AWS console di servizio da utilizzare |
| --- | --- | --- |
| Fase 1: [crea una policy di tag](orgs_policies_create.md#create-tag-policy-procedure). Mantieni semplice la tua prima policy di tag applicata. Immetti una chiave di tag nel trattamento lettere maiuscole o minuscole che desideri utilizzare e scegli l'opzione **Prevent noncompliant operations for this tag (Impedisci operazioni non conformi per questo tag)**. Quindi specifica un tipo di risorsa su cui applicarla. Continuando con l'esempio precedente, puoi scegliere di applicarla sui segreti Secrets Manager. | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Fase 2: [collega una policy di tag a un singolo account di test.](orgs_policies_attach.md) | Account di gestione dell'organizzazione.¹ | [AWS Organizations](https://console.aws.amazon.com/organizations/) |
| Fase 3: prova a creare alcune risorse con tag conformi e alcune con tag non conformi. Non ti è consentito creare un tag per una risorsa del tipo specificato nella policy di tag con un tag non conforme. | L'account membro che stai utilizzando a scopo di test. | Qualsiasi AWS servizio con cui ti senti a tuo agio. Ad esempio, puoi utilizzare [Gestione dei segreti AWS](https://console.aws.amazon.com/secretsmanager/) e seguire la procedura in [Creazione di un segreto di base](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) per creare segreti con segreti conformi e non conformi. |
| Fase 4: [valuta lo stato di conformità dell'account rispetto alla policy di tag operativa e correggi i tag non conformi. ](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-finding-noncompliant-tags.html) | L'account membro che stai utilizzando a scopo di test. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e il AWS servizio in cui è stata creata la risorsa. |
| Fase 5: ripeti il processo di individuazione e correzione dei problemi di conformità fino a quando le risorse dell'account di test non siano conformi alla policy di tag. | L'account membro che stai utilizzando a scopo di test. | [Resource Groups](https://console.aws.amazon.com/resource-groups/) e il AWS servizio in cui è stata creata la risorsa. |
| In qualsiasi momento, puoi [valutare la conformità a livello di organizzazione](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-orgs-evaluating-org-wide-compliance.html). | Account di gestione dell'organizzazione.¹ | [Gruppi di risorse](https://console.aws.amazon.com/resource-groups/) |
¹ È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
# Segnala la conformità dei tag
Le politiche relative ai tag forniscono la modalità di segnalazione per «Regole di conformità di base» e «Chiave tag obbligatoria». Puoi utilizzare questa modalità per valutare la conformità di un account della tua organizzazione alla sua efficace politica di tag. Il report generato include solo le risorse che hanno avuto almeno un tag definito dall'utente in qualsiasi momento del loro ciclo di vita.
**Importante**
Le risorse senza tag non appaiono come non conformi nei risultati.
Per trovare risorse senza tag nel tuo account, usa AWS Resource Explorer con una query che utilizza. `tag:none` Per ulteriori informazioni, consulta [Cerca risorse senza tag nella Guida per l'](https://docs.aws.amazon.com/resource-explorer/latest/userguide/using-search-query-examples.html#example-1)utente di *AWS Resource* Explorer.
**Topics**
+ [Segnalazione relativa alle «Regole di conformità di base»](#reporting-basic-compliance-rules)
+ [Segnalazione per «Chiave tag obbligatoria»](#reporting-required-tag-key)
+ [Generazione di un report di conformità a livello di organizzazione](enforcement-report.md)
## Segnalazione relativa alle «Regole di conformità di base»
Con la reportistica per le regole di conformità di base, puoi generare un rapporto di conformità basato su tag che verifica la conformità in base alle lettere maiuscole e ai valori dei tag consentiti.
**Per segnalare,**
Nella scheda Editor visuale, inserisci il valore per la chiave del tag rispetto alla quale desideri segnalare la conformità. La schermata seguente mostra un rapporto di conformità dei clienti per la chiave tag CostCenter "». In questo esempio, il rapporto evidenzierà una risorsa etichettata come conforme se corrisponde solo a un valore minuscolo della chiave di tag "CostCenter", il che significa che la stringa è uguale a «costcenter».
![\[Scheda dell'editor visivo che mostra la configurazione della politica dei tag per i tag con valori Legal e CostCenter HR\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/tag-policies-basic-compliance-reporting.png)
Il codice JSON riportato di seguito genera un rapporto di conformità per le risorse in base a un valore minuscolo della chiave del tag CostCenter "».
```
{
"tags": {
"CostCenter": {}
}
}
```
**Per riferire sulla capitalizzazione,**
Nella scheda Editor visivo, inserisci il valore per la chiave del tag rispetto alla quale desideri riportare la conformità e seleziona l'opzione Capitalizzazione. La schermata seguente mostra un rapporto di conformità dei clienti per la chiave di tag "CostCenter" con lettere maiuscole. In questo esempio, il rapporto evidenzierà una risorsa etichettata come conforme se la stringa corrisponde esattamente alla chiave del tag "»CostCenter.
![\[Scheda dell'editor visivo che mostra la configurazione della politica dei tag per i tag con lettere CostCenter maiuscole\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/tag-policies-basic-compliance-capitalization.png)
Il codice JSON riportato di seguito genera un rapporto di conformità per le risorse in base alla chiave di tag "CostCenter" con lettere maiuscole.
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
}
}
}
}
```
**Per riportare i valori dei tag consentiti con lettere maiuscole,**
Nella scheda Editor visuale, inserisci il valore per la chiave di tag rispetto alla quale desideri segnalare la conformità, seleziona l'opzione Valori consentiti e inserisci i valori per i valori dei tag consentiti. La schermata seguente mostra un rapporto sulla conformità dei clienti per la chiave di tag "CostCenter" con lettere maiuscole e valori di tag consentiti. In questo esempio, il rapporto evidenzierà una risorsa etichettata come conforme se la stringa corrisponde esattamente alla chiave del tag "CostCenter" e il valore del tag è «HR» o «Legal».
![\[Scheda dell'editor visivo che mostra la configurazione della politica dei tag per i CostCenter tag con lettere maiuscole e valori di tag consentiti: HR e Legal\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/tag-policies-basic-compliance-allowed-tag-values-with-capitalization.png)
Il codice JSON riportato di seguito genera un rapporto di conformità per le risorse in base alla chiave di tag CostCenter "" con lettere maiuscole e valori di tag consentiti «HR» e «Legal».
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"HR",
"Legal"
]
}
}
}
}
```
## Segnalazione per «Chiave tag obbligatoria»
**avvertimento**
La console AWS Resource Groups attualmente non supporta la segnalazione delle chiavi di tag richieste durante la valutazione della conformità di un account. Le risorse non conformi a cui manca una chiave di tag obbligatoria non verranno visualizzate nella sezione **Risorse con tag non conformi e non contrassegneranno l'account come non conforme**. Utilizza invece il rapporto di conformità a livello di organizzazione per trovare risorse non conformi prive di una chiave di tag obbligatoria.
Grazie alla reportistica per le chiavi di tag obbligatorie, puoi valutare se nell'operazione di creazione delle risorse mancano le chiavi di tag obbligatorie o obbligatorie. Esegui il comando seguente nella tua CLI per elencare le chiavi di tag richieste definite nella politica di tag effettiva dell'account. Puoi utilizzare queste informazioni per verificare manualmente che stai creando una risorsa con tutti i tag obbligatori, come definito dall'amministratore dell'account.
```
$ aws resourcegroupstaggingapi list-required-tags
```
**Per segnalare le chiavi dei tag richieste,**
Nella scheda Editor visivo, inserisci il valore della chiave di tag rispetto alla quale desideri segnalare la conformità e seleziona l'opzione **Contrassegna il tag come obbligatorio per la segnalazione**. La schermata seguente mostra un rapporto sulla conformità dei clienti per la chiave di tag "CostCenter" con lettere maiuscole e report per la chiave di tag richiesta. In questo esempio, il rapporto evidenzierà una risorsa etichettata come conforme se contiene la stringa esatta "CostCenter" come chiave di tag.
**Importante**
È necessario selezionare i tag Capitalizzazione e Contrassegna come obbligatori per consentire alle opzioni di reporting di generare un rapporto sui tipi di risorse selezionati a cui mancano esattamente i tag richiesti. Ad esempio, utilizzerai entrambe queste opzioni quando cercherai di verificare la corrispondenza esatta con la chiave del tag CostCenter "».
È possibile selezionare solo l'opzione Contrassegna i tag come obbligatori per la segnalazione per generare un rapporto sui tipi di risorse selezionati a cui mancano i tag richiesti. In questo scenario, il report generato contrassegnerà le risorse come conformi se presentano "CostCenter«, «CostCenter», «Costcenter», «costcenter» o qualsiasi variante simile. Questa funzionalità consente di generare report di conformità per tipi di risorse selezionati, anziché per tutte le risorse contrassegnate presenti nell'account.
Selezionando solo Capitalizzazione, verrà generato un rapporto per TUTTE le risorse con tag e tali risorse verranno contrassegnate come non conformi se la chiave del tag non corrisponde esattamente alla stringa.
![\[Scheda dell'editor visivo che mostra la configurazione della politica dei tag per la segnalazione dei tag richiesta\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/tag-policies-basic-compliance-required-tag.png)
Il codice JSON riportato di seguito genera un rapporto di conformità per le risorse in base alla chiave di tag CostCenter "" con maiuscole e tag mark come richiesto per la reportistica.
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"report_required_tag_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
}
}
}
}
```
**Per far rispettare,**
Puoi utilizzare la reportistica con strumenti IaC come CloudFormation Terraform e Pulumi per avvisare gli sviluppatori o bloccare le implementazioni con i tag obbligatori mancanti. Ora puoi utilizzare un'unica politica di tag efficace che funzioni su CloudFormation Terraform e Pulumi. Per maggiori [dettagli, consulta Applica la «chiave tag richiesta» con iAc](enforce-required-tag-keys-iac.md).
# Generazione di un report di conformità a livello di organizzazione
In qualsiasi momento, puoi generare un rapporto che elenca tutte le risorse taggate presenti nell' Account AWS organizzazione. Il report mostra se ogni risorsa è conforme alla policy di tag operativa. Tieni presente che le modifiche apportate a una policy di tag o alle risorse possono impiegare fino a 48 ore prima di essere riportate nel report di conformità a livello di organizzazione. Ad esempio, se disponi di una politica sui tag che definisce un nuovo tag standardizzato per un tipo di risorsa, le risorse di quel tipo che non dispongono di questo tag vengono mostrate come conformi nel rapporto per un massimo di 48 ore.
Puoi generare il report dall'account di gestione dell'organizzazione nella Regione `us-east-1`, a condizione che abbia accesso a un bucket Amazon S3. Il bucket deve essere collegato a una policy di bucket, come descritto in [Policy dei bucket Amazon S3 per l'archiviazione del report](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-prereqs.html#bucket-policy). Per generare il report, esegui il comando seguente:
```
$ aws resourcegroupstaggingapi start-report-creation --region us-east-1
```
Puoi generare un report alla volta.
Il completamento del report potrebbe richiedere del tempo. Puoi controllare lo stato eseguendo il seguente comando:
```
$ aws resourcegroupstaggingapi describe-report-creation --region us-east-1
{
"Status": "SUCCEEDED"
}
```
Quando il comando precedente restituisce `SUCCEEDED`, puoi aprire il report dal bucket Amazon S3.
# Applica la coerenza dei tag
Le politiche relative ai tag offrono due funzionalità per aiutarti a far rispettare la coerenza dei tag in tutti gli AWS ambienti: «Regole di conformità di base» e «Chiave tag richiesta». Puoi utilizzare queste funzionalità con due modalità di politica dei tag: applicazione e segnalazione. Questa sezione evidenzia la modalità di applicazione per entrambe le funzionalità. Per i dettagli sulla modalità di reporting per entrambe le funzionalità, vedi «Reporting tagging compliance».
**Topics**
+ [Applica le «Regole di conformità di base»](#basic-compliance-rules)
+ [Best practice](#best-practices)
+ [Applica la «chiave tag richiesta» con IaC](enforce-required-tag-keys-iac.md)
+ [Sintassi ed esempi delle policy di tag](orgs_manage_policies_example-tag-policies.md)
## Applica le «Regole di conformità di base»
Con l'applicazione delle regole di conformità di base, puoi impedire la creazione di risorse con valori di tag che non soddisfano i requisiti specificati nella tua politica sui tag. Ad esempio, puoi definire una politica che blocchi le operazioni di EC2 creazione di Amazon se la chiave di tag CostCenter '' fornita non ha un valore di tag «Business» o «Legal». Le regole di conformità di base consentono inoltre di applicare l'applicazione in base all'uso delle maiuscole e minuscole delle chiavi dei tag. L'attivazione delle maiuscole garantisce che le chiavi dei tag corrispondano esattamente alle stringhe. Le maiuscole trattano "CostCenter«, «CostCenter» e «Costcenter» come chiavi di tag uniche, il che significa che l'applicazione delle chiavi dei tag fa distinzione tra maiuscole e minuscole. L'applicazione delle maiuscole impedisce ai team di creare accidentalmente varianti di tag. La coerenza dei tag è fondamentale sia per l'accuratezza del monitoraggio dei costi che per le politiche di sicurezza ABAC (Attribute-Based Access Control) che si basano sulla corrispondenza precisa dei tag per concedere o negare l'accesso alle risorse.
**Importante**
Le regole di conformità di base non impongono la conformità dei tag alle risorse create senza tag. Questa funzionalità non impone le chiavi dei tag mancanti. Non è possibile utilizzare questa funzionalità per garantire che le chiavi tag obbligatorie o obbligatorie siano configurate al momento della creazione della risorsa. Utilizza la modalità di reporting in «Chiavi tag richieste» per applicare le chiavi tag richieste per le risorse create da strumenti IaC come CloudFormation Terraform e Pulumi. Utilizza SCPs per impedire agli utenti e ai ruoli IAM negli account di destinazione di creare determinati tipi di risorse se la richiesta non include i tag specificati.
Per applicare le regole di conformità di base con le politiche sui tag, esegui una delle seguenti operazioni quando [crei una politica sui tag:](orgs_policies_create.md)
+ Dalla scheda **Editor visivo**, seleziona l'opzione **Impedisci operazioni non conformi** per questo tag. Vedi la sezione [Creare una politica sui tag](orgs_policies_create.md) per i passaggi su come creare e allegare una politica sui tag.
+ Dalla scheda **JSON** utilizzare il campo `enforced_for`. Per informazioni sulla sintassi delle policy di tag, consultare [Sintassi ed esempi delle policy di tag](orgs_manage_policies_example-tag-policies.md).
L'immagine seguente mostra l'esperienza della scheda Visual Editor da console. In questo esempio, il cliente sta definendo una politica di tag che applicherà la convalida del valore dei tag solo per i tipi di EC2 risorse Amazon supportati dalle politiche di tag. Questa politica verificherà se il valore del tag è «Legale» o «HR» quando la chiave del tag fornita è "CostCenter" per i tipi di EC2 risorse Amazon. Questa politica impone anche l'uso delle maiuscole, il che significa che la politica cerca una stringa che corrisponda esattamente alla chiave del tag CostCenter "».
![\[Scheda dell'editor visivo che mostra la configurazione della politica dei tag per i CostCenter tag con valori Legal e HR\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/images/tag-policies-basic-compliance.png)
Il codice JSON riportato di seguito è la politica dei tag generata dall'esempio "CostCenter" precedente.
**Importante**
Ti consigliamo di utilizzare l'editor Visual quando definisci la politica dei tag per la prima volta. L'editor visivo garantisce che la sintassi della politica dei tag sia valida, senza passaggi aggiuntivi, e offre un'esperienza semplificata e cliccabile per definire la politica dei tag. È possibile utilizzare l'editor Visual o la scheda JSON per definire la politica dei tag.
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"HR",
"Legal"
]
},
"enforced_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
}
}
}
}
```
## Best practice
Segui queste best practice per l'applicazione con «Regole di conformità di base» e «Chiavi tag obbligatorie per IaC» con politiche di tag:
+ Fai **attenzione quando applichi la conformità**: assicurati di comprendere gli effetti dell'utilizzo delle politiche sui tag e di seguire i flussi di lavoro consigliati descritti in. [Nozioni di base sulle policy di tag](orgs_manage_policies_tag-policies-getting-started.md) Verifica come funziona l'applicazione delle norme su un account di prova prima di estenderlo a più account o unità organizzative. In caso contrario, è possibile agli utenti degli account dell'organizzazione venga impedito di creare le risorse necessarie.
+ **Tieni presente a quali tipi di risorse è possibile applicare la conformità** - Puoi applicare la conformità solo alle policy di tag per i [tipi di risorse supportati](orgs_manage_policies_supported-resources-enforcement.md). I tipi di risorse che supportano l'applicazione della conformità vengono elencati quando utilizzi l'editor visivo per creare una policy di tag.
+ **Comprendi le interazioni con alcuni servizi**: alcuni Servizi AWS dispongono di raggruppamenti di risorse simili a contenitori che creano automaticamente risorse per te e propagano i tag da una risorsa di un servizio all'altro. Ad esempio, i tag sui EC2 gruppi Amazon e sui cluster Amazon EMR possono propagarsi automaticamente alle istanze Amazon contenute. EC2 Potresti avere politiche di tag per Amazon EC2 più rigide rispetto a quelle per i gruppi o i cluster Amazon EMR. Se abiliti l'applicazione, la policy di tag impedisce l'applicazione di tag alle risorse e potrebbe bloccare il dimensionamento dinamico e il provisioning.
Nelle sezioni seguenti viene illustrato come trovare risorse non conformi e correggerle in modo che siano conformi.
**Topics**
+ [Identifica e correggi le incongruenze di etichettatura](orgs_manage_policies_tag-policies-identify-remediate.md)
# Applica la «chiave tag richiesta» con IaC
Le politiche di tag consentono di mantenere un'etichettatura coerente in tutte le implementazioni dell'infrastruttura come codice (IaC). Con le «chiavi tag obbligatorie», puoi assicurarti che tutte le risorse create tramite strumenti IaC come CloudFormation Terraform e Pulumi includano i tag obbligatori definiti dalla tua organizzazione.
Questa funzionalità verifica le implementazioni IaC rispetto alle politiche di tag dell'organizzazione prima della creazione delle risorse. Quando in una distribuzione mancano i tag richiesti, è possibile configurare le impostazioni IaC in modo da avvisare i team di sviluppo o impedire completamente l'implementazione. Questo approccio proattivo mantiene la conformità dei tag sin dal momento in cui vengono create le risorse, anziché richiedere una correzione manuale in un secondo momento. L'applicazione funziona su più strumenti IaC utilizzando un'unica definizione di policy di tag, eliminando la necessità di configurare regole di tagging separate per ogni strumento utilizzato dall'organizzazione.
**Topics**
+ [Applica con CloudFormation](#enforce-with-cloudformation)
+ [Applica con Terraform](#enforce-with-terraform)
+ [Applica con Pulumi](#enforce-with-pulumi)
## Applica con CloudFormation
**Nota**
Per applicare le chiavi dei tag obbligatorie con CloudFormation, è necessario specificare i tag obbligatori per il tipo di risorsa nelle politiche dei tag. Per ulteriori informazioni, consulta la sezione [Segnalazione per «Chiave tag obbligatoria»](orgs_manage_policies_tag-policies-report-tagging-compliance.md#reporting-required-tag-key).
**Imposta il ruolo di esecuzione per AWS::TagPolicies: TaggingComplianceValidator Hook**
Prima di attivare l'`AWS::TagPolicies::TaggingComplianceValidator`hook, è necessario creare un ruolo di esecuzione che l'hook utilizza per accedere ai AWS servizi. Al ruolo deve essere allegata la seguente politica di fiducia:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"resources.cloudformation.amazonaws.com",
"hooks.cloudformation.amazonaws.com"
]
},
"Action": [
"sts:AssumeRole"
]
}
]
}
```
Il ruolo di esecuzione deve inoltre disporre di una Role Policy con almeno le seguenti autorizzazioni:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"tag:ListRequiredTags"
],
"Resource": "*"
}
]
}
```
Per ulteriori informazioni sulla configurazione dei ruoli di esecuzione per le estensioni pubbliche, consulta [Configurare un ruolo di esecuzione con autorizzazioni IAM e una politica di fiducia per l'accesso alle estensioni pubbliche nella Guida](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry-public.html#registry-public-enable-execution-role) per l' CloudFormation utente.
**Attiva il AWS::TagPolicies: TaggingComplianceValidator Hook**
**Importante**
Prima di continuare, verifica di disporre delle autorizzazioni necessarie per lavorare con Hooks e visualizzare i controlli proattivi dalla console. CloudFormation Per ulteriori informazioni, consulta [Concedere le autorizzazioni IAM](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/grant-iam-permissions-for-hooks.html) per gli Hooks. CloudFormation
Dopo aver aggiornato la politica sui tag, devi attivare l'`AWS::TagPolicies::TaggingComplianceValidator`hook in ogni AWS account e regione in cui desideri applicare la conformità richiesta in materia di tag.
Questo hook AWS gestito può essere configurato in due modalità:
+ **Modalità Warn**: consente alle distribuzioni di procedere ma genera avvisi quando mancano i tag richiesti
+ **Modalità Fail**: blocca le distribuzioni prive dei tag obbligatori
Per attivare l'hook utilizzando la AWS CLI:
```
aws cloudformation activate-type \
--type HOOK \
--type-name AWS::TagPolicies::TaggingComplianceValidator \
--execution-role-arn arn:aws:iam::123456789012:role/MyHookExecutionRole \
--publisher-id aws-hooks \
--region us-east-1
```
```
aws cloudformation set-type-configuration \
--configuration '{"CloudFormationConfiguration":{"HookConfiguration":{"HookInvocationStatus": "ENABLED", "FailureMode": "WARN", "TargetOperations": ["STACK"], "Properties":{}}}}' \
--type-arn "arn:aws:cloudformation:us-east-1:123456789012:type/hook/AWS-TagPolicies-TaggingComplianceValidator" \
--region us-east-1
```
Sostituiscilo `region` con la AWS regione di destinazione e, `"FailureMode":"WARN"` se preferisci, passa `"FailureMode":"FAIL"` alla modalità di avviso.
**Attiva AWS::TagPolicies:: TaggingComplianceValidator Hook tra più account e regioni con CloudFormation StackSets**
Per le organizzazioni con più AWS account, puoi attivare l'hook di etichettatura AWS CloudFormation StackSets per la conformità in tutti gli account e le aree geografiche contemporaneamente.
CloudFormation StackSets ti consentono di distribuire lo stesso CloudFormation modello su più account e regioni con un'unica operazione. Questo approccio garantisce un'applicazione coerente dei tag in tutta l' AWS organizzazione senza richiedere la configurazione manuale in ogni account.
Da utilizzare CloudFormation StackSets per questo scopo:
1. Crea un CloudFormation modello che attivi l'hook di conformità ai tag
1. Implementa il modello utilizzandolo CloudFormation StackSets per indirizzare le unità organizzative o gli account specifici
1. Specificate tutte le regioni in cui desiderate abilitare l'applicazione
L' CloudFormation StackSets implementazione gestirà automaticamente il processo di attivazione in tutti gli account e le regioni specificati, garantendo la conformità uniforme dei tag in tutta l'organizzazione. [Per scoprire come distribuire CloudFormation Hooks in un'organizzazione con gestione dei servizi, consulta questo blog CloudFormation StackSets.AWS](https://aws.amazon.com/blogs/devops/deploy-cloudformation-hooks-to-an-organization-with-service-managed-stacksets/)
*Implementa il CloudFormation modello seguente utilizzando CloudFormation StackSets per attivare l'TaggingComplianceValidator Hook AWS:::TagPolicies: per gli account della tua organizzazione.*
**Importante**
Questo hook funziona solo come StackHook. Non ha effetto se usato come hook di risorse.
```
Resources:
# Activate the AWS-managed hook type
HookTypeActivation:
Type: AWS::CloudFormation::TypeActivation
Properties:
AutoUpdate: True
PublisherId: "AWS"
TypeName: "AWS::TagPolicies::TaggingComplianceValidator"
# Configure the hook
HookTypeConfiguration:
Type: AWS::CloudFormation::HookTypeConfig
DependsOn: HookTypeActivation
Properties:
TypeName: "AWS::TagPolicies::TaggingComplianceValidator"
TypeArn: !GetAtt HookTypeActivation.Arn
Configuration: !Sub |
{
"CloudFormationConfiguration": {
"HookConfiguration": {
"TargetStacks": "ALL",
"TargetOperations": ["STACK"],
"Properties": {},
"FailureMode": "Warn",
"TargetFilters": {
"Actions": [
"CREATE",
"UPDATE"
]}
}
}
}
```
**Nota**
Per ulteriori informazioni sull'esecuzione degli CloudFormation hook, consulta [Attivare un Hook basato su un controllo proattivo](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/proactive-controls-hooks-activate-hooks.html) nel tuo account.
## Applica con Terraform
Per applicare le chiavi dei tag richieste con Terraform, devi aggiornare Terraform Provider alla versione 6.22.0 o successiva e abilitare la convalida della politica dei tag nella configurazione del AWS provider. Per i dettagli di implementazione e gli esempi di configurazione, consulta la documentazione di [Terraform AWS](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/tag-policy-compliance) Provider sull'applicazione delle politiche dei tag.
## Applica con Pulumi
Per applicare le chiavi di tag richieste con Pulumi, devi abilitare il pacchetto di policy Tag Policy Reporting in Pulumi Cloud e configurare il tuo ruolo IAM con le autorizzazioni di lettura delle tag policy. Per i dettagli di implementazione e gli esempi di configurazione, consulta la [documentazione Pulumi](https://www.pulumi.com/docs/insights/policy/integrations/aws-organizations-tag-policies/#aws-organizations-tag-policies) sull'applicazione della politica dei tag.
# Sintassi ed esempi delle policy di tag
Questa pagina descrive la sintassi delle policy di tag e fornisce esempi.
**Topics**
+ [Sintassi delle policy di tag](#tag-policy-syntax-reference)
+ [Esempi di policy con tag](#tag-policy-examples)
+ [Esempio 1: definire l'uso delle maiuscole o minuscole per la chiave di tag a livello di organizzazione](#tag-policy-example-key-case)
+ [Esempio 2: impedire l'utilizzo di una chiave di tag](#tag-policy-example-prevent-key)
+ [Esempio 3: Specificare una politica di tag per tutti i tipi di risorse supportati di un servizio specifico AWS](#tag-policy-example-all-supported)
+ [Esempio 4: Applica le chiavi dei tag richieste per garantire la conformità](#tag-policy-example-required-tags)
## Sintassi delle policy di tag
Una policy di tag è un file di testo normale strutturato in base alle regole di [JSON](http://json.org). La sintassi per le policy di tag segue la sintassi per tutti i tipi di policy di gestione. Per una discussione completa di tale sintassi, consulta [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md). Questo argomento è incentrato sull'applicazione della sintassi generale ai requisiti specifici del tipo di policy di tag.
La seguente policy di tag mostra la sintassi della policy di tag di base:
```
{
"tags": {
"costcenter": {
"tag_key": {
"@@assign": "CostCenter"
},
"tag_value": {
"@@assign": [
"100",
"200",
"300*"
]
},
"enforced_for": {
"@@assign": [
"secretsmanager:ALL_SUPPORTED"
]
}
}
}
}
```
La sintassi della policy di tag include i seguenti elementi:
+ Il nome della chiave di campo `tags`. Le policy di tag iniziano sempre con questo nome di chiave fisso. È la prima riga nella policy di esempio precedente.
+ Una *chiave della policy* che identifica in modo univoco l'istruzione della policy. Deve corrispondere al valore per la *chiave di tag*, ad eccezione del trattamento lettere maiuscole o minuscole. Il valore della policy distingue tra maiuscole e minuscole.
In questo esempio, `costcenter` è la chiave della policy.
+ Almeno una *chiave di tag* che specifica la chiave di tag consentita con l'uso delle maiuscole e minuscole a cui desideri che le risorse siano conformi. Se il trattamento lettere maiuscole o minuscole non è definito, minuscole è il trattamento predefinito per le chiavi di tag. Il valore per la chiave di tag deve corrispondere al valore per la chiave della policy. Tuttavia, poiché il valore della chiave della policy non fa distinzione tra maiuscole e minuscole, l'uso delle maiuscole e delle minuscole può essere diverso.
In questo esempio, `CostCenter` è la chiave di tag. Questo è il trattamento lettere maiuscole o minuscole che è richiesto per la conformità con la policy di tag. Le risorse con il trattamento alternativo lettere maiuscole o minuscole per questa chiave di tag non sono conformi con la policy di tag.
In una policy di tag è possibile definire più chiavi di tag.
+ (Facoltativo) Un elenco di uno o più *valori di tag* accettabili per la chiave di tag. Se la policy di tag non specifica un valore di tag per una chiave di tag, qualsiasi valore (incluso nessun valore) viene considerato conforme.
In questo esempio, i valori accettabili per la chiave del `CostCenter` tag sono `100``200`, e`300*`.
+ (Facoltativo) Un'opzione `enforced_for` che indica se impedire le operazioni di tag non conformi su servizi e risorse specificati. Nella console, questa è l'opzione **Prevent noncompliant operations for this tag (Impedisci operazioni non conformi per questo tag)** nell'editor visivo per la creazione di policy di tag. L'impostazione predefinita per questa opzione è null.
L'esempio di tag policy specifica che il `CostCenter` tag applicato a tutte le Gestione dei segreti AWS risorse deve essere conforme a questo criterio.
**avvertimento**
Cambia l'impostazione predefinita di questa opzione solo se sei esperto dell'utilizzo delle policy di tag. In caso contrario, è possibile agli utenti degli account dell'organizzazione venga impedito di creare le risorse necessarie.
+ *Operatori* che specificano il modo in cui la policy di tag si unisce con altre policy di tag all'interno dell'albero dell'organizzazione per creare la [policy di tag operativa](orgs_manage_policies_effective.md) di un account. In questo esempio, `@@assign` viene utilizzato per assegnare le stringhe a `tag_key`, `tag_value` e `enforced_for`. Per ulteriori informazioni sugli operatori, vedi [Operatori di ereditarietà](policy-operators.md).
+ È possibile utilizzare il carattere `*` jolly nei valori dei tag.
+ Puoi utilizzare solo un carattere jolly per ogni valore di tag. Ad esempio, `*@example.com` è consentito, mentre non lo è `*@*.com`.
+ È possibile utilizzare il carattere `ALL_SUPPORTED` jolly sul `enforced_for` campo con alcuni servizi per abilitare l'applicazione di tutte le risorse supportate per quel servizio. Per un elenco dei servizi e dei tipi di risorse che supportano `enforced_for`, consultare [Servizi e tipi di risorse che supportano l'applicazione](orgs_manage_policies_supported-resources-enforcement.md).
+ Non è possibile utilizzare un carattere jolly per specificare tutti i servizi o per specificare una risorsa per tutti i servizi.
## Esempi di policy con tag
Le [policy di tag](orgs_manage_policies_tag-policies.md) di esempio che seguono sono solo a scopo informativo.
**Nota**
Prima di tentare di utilizzare queste policy di tag di esempio nell'organizzazione, tieni presente quanto segue:
Assicurati di aver seguito il [flusso di lavoro raccomandato](orgs_manage_policies_tag-policies-getting-started.md) per iniziare a utilizzare le policy di tag.
Esamina attentamente e personalizza queste policy di tag in base ai tuoi requisiti univoci.
Tutti i caratteri nella policy di tag sono soggetti a una [dimensione massima](orgs_reference_limits.md#min-max-values). Gli esempi in questa guida mostrano le policy di tag formattate con spazio vuoto aggiuntivo per migliorarne la leggibilità. Tuttavia puoi eliminare qualsiasi spazio vuoto per risparmiare spazio, se la dimensione della policy si avvicina a quella massima. Esempi di spazio bianco includono gli spazi e le interruzioni di riga che sono al di fuori delle virgolette.
Le risorse senza tag non appaiono nei risultati come non conformi.
## Esempio 1: definire l'uso delle maiuscole o minuscole per la chiave di tag a livello di organizzazione
Nell'esempio seguente viene illustrata una policy di tag che definisce solo due chiavi di tag e l'uso delle maiuscole e delle minuscole su cui si desidera che gli account dell'organizzazione vengano standardizzati.
**Policy A: policy di tag della root dell'organizzazione**
```
{
"tags": {
"CostCenter": {
"tag_key": {
"@@assign": "CostCenter",
"@@operators_allowed_for_child_policies": ["@@none"]
}
},
"Project": {
"tag_key": {
"@@assign": "Project",
"@@operators_allowed_for_child_policies": ["@@none"]
}
}
}
}
```
Questa policy di tag definisce due chiavi tag: `CostCenter` e `Project`. Il collegamento di questa policy di tag alla root dell'organizzazione ha i seguenti effetti:
+ Tutti gli account dell'organizzazione ereditano questa policy di tag.
+ Tutti gli account dell'organizzazione devono utilizzare il trattamento lettere maiuscole o minuscole definito per la conformità. Le risorse con i tag `CostCenter` e `Project` sono conformi. Le risorse con il trattamento lettere maiuscole o minuscole alternativo per la chiave di tag (ad esempio `costcenter`, `Costcenter` o `COSTCENTER`) non sono conformi.
+ Le righe `@@operators_allowed_for_child_policies": ["@@none"]` bloccano le chiavi di tag. Le policy di tag collegate a un livello inferiore nell'albero dell'organizzazione (policy figlio) non possono utilizzare gli operatori di impostazione del valore per modificare la chiave di tag, incluso il trattamento lettere maiuscole o minuscole.
+ Nello stesso modo delle policy di tag, le risorse senza tag o i tag che non sono definiti nella policy di tag non vengono valutati per la conformità con la policy di tag.
AWS consiglia di utilizzare questo esempio come guida per la creazione di una politica di tag simile per le chiavi dei tag che si desidera utilizzare. Collegala alla root dell'organizzazione. Quindi crea una policy di tag simile all'esempio successivo, che definisce solo i valori accettabili per le chiavi di tag definite.
### Fase successiva: definizione dei valori
Supponiamo di aver collegato la policy di tag precedente alla root dell'organizzazione. Quindi ora è possibile creare un policy di tag come la seguente e collegarla a un account. Questa policy definisce i valori accettabili per le chiavi di tag `CostCenter` e `Project`.
**Policy B: policy di tag dell'account**
```
{
"tags": {
"CostCenter": {
"tag_value": {
"@@assign": [
"Production",
"Test"
]
}
},
"Project": {
"tag_value": {
"@@assign": [
"A",
"B"
]
}
}
}
}
```
Se colleghi la policy A alla root dell'organizzazione e la policy B a un account, le policy vengono combinate per creare la seguente policy di tag operativa per l'account:
**Policy A\$1 Policy B = policy di tag operativa per l'account**
```
{
"tags": {
"Project": {
"tag_value": [
"A",
"B"
],
"tag_key": "Project"
},
"CostCenter": {
"tag_value": [
"Production",
"Test"
],
"tag_key": "CostCenter"
}
}
}
```
Per ulteriori informazioni sull'ereditarietà delle politiche, inclusi esempi di come funzionano gli operatori di ereditarietà ed esempi di politiche di tag efficaci, vedere. [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md)
## Esempio 2: impedire l'utilizzo di una chiave di tag
Per impedire l'utilizzo di una chiave di tag, è possibile collegare una policy di tag come la seguente a un'entità dell'organizzazione.
Questa policy di esempio specifica che nessun valore è accettabile per la chiave di tag `Color`. Specifica inoltre che nessun [operatore](policy-operators.md) è consentito nelle policy di tag figlio. Pertanto, eventuali tag `Color` sulle risorse negli account interessati sono considerati non conformi. Tuttavia, l'opzione `enforced_for` impedisce effettivamente agli account interessati di aggiungere un tag ***solo*** per le tabelle Amazon DynamoDB con il tag `Color`.
```
{
"tags": {
"Color": {
"tag_key": {
"@@operators_allowed_for_child_policies": [
"@@none"
],
"@@assign": "Color"
},
"tag_value": {
"@@operators_allowed_for_child_policies": [
"@@none"
],
"@@assign": []
},
"enforced_for": {
"@@assign": [
"dynamodb:table"
]
}
}
}
}
```
## Esempio 3: Specificare una politica di tag per tutti i tipi di risorse supportati di un servizio specifico AWS
Per specificare una politica di tag per tutti i tipi di risorse supportati di un AWS servizio specifico, si utilizza il carattere `ALL_SUPPORTED` jolly.
Questa policy utilizza il carattere `ALL_SUPPORTED` jolly per specificare che tutte le istanze Amazon EC2 con la `Environment` chiave tag possono avere solo un valore di tag pari o. `Prod` `Non-prod` Questa jolly offre un'alternativa efficace a riga singola per elencare ogni istanza Amazon EC2 singolarmente. Per un elenco di servizi e tipi di risorse che supportano la `ALL_SUPPORTED` wildcard, consulta. [Servizi e tipi di risorse che supportano l'applicazione](orgs_manage_policies_supported-resources-enforcement.md)
```
{
"tags": {
"Environment": {
"tag_key": {
"@@assign": "Environment",
"@@operators_allowed_for_child_policies": ["@@none"]
},
"tag_value": {
"@@assign": [
"Prod",
"Non-prod"
],
"@@operators_allowed_for_child_policies": ["@@none"]
},
"enforced_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
}
}
}
}
```
## Esempio 4: Applica le chiavi dei tag richieste per garantire la conformità
Questo esempio dimostra come definire una politica di tag che richieda che tutte le risorse includano tag di conformità obbligatori. Le organizzazioni utilizzano comunemente questo modello per garantire una corretta allocazione dei costi, il monitoraggio della proprietà e l'identificazione dell'ambiente.
```
{
"tags": {
"CostCenter": {
"report_required_tag_for": {
"@@assign": [
"ec2:instance",
"s3:bucket",
"rds:db",
"lambda:function"
]
},
"tag_key": {
"@@assign": "CostCenter"
}
},
"Environment": {
"report_required_tag_for": {
"@@assign": [
"ec2:ALL_SUPPORTED",
"rds:ALL_SUPPORTED",
"s3:ALL_SUPPORTED"
]
},
"tag_key": {
"@@assign": "Environment"
},
"tag_value": {
"@@assign": [
"Production",
"Staging",
"Development",
"Test"
]
}
},
"Owner": {
"report_required_tag_for": {
"@@assign": [
"ec2:ALL_SUPPORTED"
]
},
"tag_key": {
"@@assign": "Owner"
}
}
}
}
```
Quando applichi questa policy e configuri il tuo strumento IaC con Tag Policy Enforcement:
+ CostCenter: richiesto per istanze EC2, bucket S3, database RDS e funzioni Lambda
+ Ambiente: richiesto per tutte le risorse EC2, RDS e S3, con valori consentiti limitati a Produzione, Staging, Sviluppo o Test
+ Proprietario: richiesto per tutte le risorse EC2 dell'organizzazione
Esempio di codice di infrastruttura conforme a questa politica:
```
EC2Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-0c02fb55956c7d316
InstanceType: t2.micro
Tags:
- Key: CostCenter
Value: CC-12345
- Key: Environment
Value: Test
- Key: Owner
Value: john.doe@company.com
```
Se si tenta di creare una risorsa senza i tag richiesti, l'implementazione di IaC fallirà o genererà un avviso durante la fase di pianificazione, a seconda della configurazione. Se configurata in modalità di errore, la distribuzione viene bloccata prima della creazione di qualsiasi risorsa. Se configurata in modalità di avviso, la distribuzione procede ma avvisa il team dei tag mancanti. Il messaggio di errore di convalida identifica esattamente quali tag obbligatori mancano e quali risorse li richiedono.
Per istruzioni di configurazione specifiche per il tuo strumento IAc:
+ **CloudFormation**: Vedi [Applica con CloudFormation](enforce-required-tag-keys-iac.md#enforce-with-cloudformation) per attivare il tagging compliance hook
+ **Terraform**: vedi come [Applica con Terraform](enforce-required-tag-keys-iac.md#enforce-with-terraform) abilitare la convalida della politica dei tag nel Provider AWS
+ **Nota: Vedi** come abilitare il pacchetto [Applica con Pulumi](enforce-required-tag-keys-iac.md#enforce-with-pulumi) di policy Tag Policy Reporting
# Identifica e correggi le incongruenze di etichettatura
Dopo aver implementato le politiche relative ai tag nell'organizzazione, è possibile identificare le risorse con tag non conformi e correggerle per garantire la coerenza in tutto l'ambiente. AWS Questa sezione fornisce indicazioni su come individuare e correggere le incongruenze nei tag.
**Topics**
+ [Individuazione di risorse prive di tag e contrassegnate erroneamente per la propria organizzazione con Resource Explorer](finding-untagged-mistagged-resources.md)
+ [Correzione di tag non conformi nelle risorse](enforcement-correcting.md)
+ [Utilizzo di Amazon EventBridge per monitorare i tag non conformi](orgs_manage_policies_tag-policies-cwe.md)
# Individuazione di risorse prive di tag e contrassegnate erroneamente per la propria organizzazione con Resource Explorer
Per trovare risorse senza tag nel tuo account, usale con una query che utilizza Esploratore di risorse AWS . `tag:none` Resource Explorer offre funzionalità di ricerca complete per identificare le risorse prive di tag corretti o con valori di tag non coerenti all'interno dell'organizzazione.
*Per istruzioni dettagliate sull'uso di Resource Explorer per trovare risorse prive di tag e con tag errati, consulta [Cerca risorse senza tag nella Guida per l'utente](https://docs.aws.amazon.com/resource-explorer/latest/userguide/using-search-query-examples.html#example-1).Esploratore di risorse AWS *
# Correzione di tag non conformi nelle risorse
Dopo aver trovato i tag non conformi, apporta le correzioni utilizzando uno dei metodi descritti di seguito. Devi accedere all'account con la risorsa con tag non conformi:
+ Utilizza la console o le operazioni API di tagging del servizio che ha creato le AWS risorse non conformi.
+ Utilizza le [UntagResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_UntagResources.html)operazioni AWS Resource Groups [TagResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_TagResources.html)and per aggiungere tag conformi alla politica effettiva o per rimuovere tag non conformi.
# Utilizzo di Amazon EventBridge per monitorare i tag non conformi
Puoi utilizzare Amazon EventBridge, precedentemente Amazon CloudWatch Events, per monitorare quando vengono introdotti tag non conformi. Nel seguente evento di esempio, il valore `"false"` per `tag-policy-compliant` indica che un nuovo tag non è conforme alla policy di tag operativa.
```
{
"detail-type": "Tag Change on Resource",
"region": "us-east-1",
"resources": [
"arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaaa"
],
"detail": {
"changed-tag-keys": [
"a-new-key"
],
"service": "ec2",
"resource-type": "instance",
"version": 3,
"tag-policy-compliant": "false",
"tags": {
"a-new-key": "tag-value-on-new-key-just-added"
}
}
}
```
Puoi sottoscrivere eventi e specificare stringhe o modelli da monitorare. Per ulteriori informazioni su EventBridge, consulta la *[Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/)*.
# Servizi e tipi di risorse che supportano l'applicazione
I seguenti servizi e tipi di risorse supportano l'applicazione con le policy di tag:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_supported-resources-enforcement.html)
+ Consulta la [documentazione di Terraform](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/tag-policy-compliance) per il supporto dei tipi di risorse in Terraform AWS Provider.
+ Consulta la [documentazione Pulumi](https://www.pulumi.com/docs/insights/policy/integrations/aws-organizations-tag-policies/#aws-provider-types) per il supporto dei tipi di risorse in Pulumi Cloud.
# Regioni supportate
Le caratteristiche delle policy di tag sono disponibili nelle seguenti regioni:
| Nome della Regione | Parametro della regione |
| --- | --- |
| Regione Stati Uniti orientali (Virginia settentrionale)¹ | **`us-east-1`** |
| Stati Uniti orientali (Ohio) | `us-east-2` |
| Regione Stati Uniti occidentali (California settentrionale) | `us-west-1` |
| Stati Uniti occidentali (Oregon) | `us-west-2` |
| Regione Africa (Città del Capo)² | `af-south-1` |
| Regione Asia Pacifico (Hong Kong)² | `ap-east-1` |
| Asia Pacifico (Taipei) ² | `ap-east-2` |
| Regione Asia Pacifico (Mumbai) | `ap-south-1` |
| Asia Pacifico (Hyderabad) ² | `ap-south-2` |
| Regione Asia Pacifico (Tokyo) | `ap-northeast-1` |
| Regione Asia Pacifico (Seoul) | `ap-northeast-2` |
| Regione Asia Pacifico (Osaka-Locale) | `ap-northeast-3` |
| Regione Asia Pacifico (Singapore) | `ap-southeast-1` |
| Regione Asia Pacifico (Sydney) | `ap-southeast-2` |
| Regione Asia Pacifico (Giacarta) ² | `ap-southeast-3` |
| Asia Pacifico (Melbourne) ² | `ap-southeast-4` |
| Regione Asia Pacifico (Malesia) | `ap-southeast-5` |
| Asia Pacifico (Nuova Zelanda) ² | `ap-southeast-6` |
| Asia Pacifico (Thailandia) | `ap-southeast-7` |
| Regione Canada (Centrale) | `ca-central-1` |
| Canada occidentale (Calgary) ² | `ca-west-1` |
| Regione Cina (Pechino) | `cn-north-1` |
| Regione Cina (Ningxia) | `cn-northwest-1` |
| Regione Europa (Francoforte) | `eu-central-1` |
| Regione Europa (Zurigo) ² | `eu-central-2` |
| Regione Europa (Milano)² | `eu-south-1` |
| Europa (Spagna) ² | `eu-south-2` |
| Regione Europa (Irlanda) | `eu-west-1` |
| Regione Europa (Londra) | `eu-west-2` |
| Regione Europa (Parigi) | `eu-west-3` |
| Regione Europa (Stoccolma) | `eu-north-1` |
| Regione Messico (centrale) | `mx-central-1` |
| Regione del Medio Oriente (EAU) ² | `me-central-1` |
| Regione Medio Oriente (Bahrein)² | `me-south-1` |
| Regione Sud America (San Paolo) | `sa-east-1` |
| Israele (Tel Aviv) ² | `il-central-1` |
| AWS GovCloud (Stati Uniti orientali) | `us-gov-east-1` |
| AWS GovCloud (Stati Uniti occidentali) | `us-gov-west-1` |
**¹È necessario specificare la Regione `us-east-1` quando si chiamano le operazioni Organizations seguenti:**
+ [DeletePolicy](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DeletePolicy.html)
+ [DisablePolicyType](https://docs.aws.amazon.com/organizations/latest/APIReference/API_DisablePolicyType.html)
+ [EnablePolicyType](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnablePolicyType.html)
+ Qualsiasi altra operazione sulla radice di un'organizzazione, ad esempio [ListRoots](https://docs.aws.amazon.com/organizations/latest/APIReference/API_ListRoots.html).
**È inoltre necessario specificare la regione `us-east-1` quando si chiamano le seguenti operazioni API per l'applicazione di tag a gruppi di risorse che fanno parte della caratteristica delle policy di tag:**
+ [DescribeReportCreation](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_DescribeReportCreation.html)
+ [GetComplianceSummary](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetComplianceSummary.html)
+ [StartReportCreation](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_StartReportCreation.html)
**Nota**
Per valutare la conformità a livello di organizzazione con le policy di tag, è necessario anche avere accesso a un bucket Amazon S3 nella Regione Stati Uniti orientali (Virginia settentrionale) per l'archiviazione dei report. Per ulteriori informazioni, consulta la [policy sui bucket di Amazon S3 per l'archiviazione dei report](https://docs.aws.amazon.com/ARG/latest/userguide/tag-policies-prereqs.html#bucket-policy) nella *Tagging AWS * Resources User Guide.
²Queste Regioni devono essere abilitate manualmente. Per ulteriori informazioni sull'attivazione e la disabilitazione Regioni AWS, consulta [Specificare quali dispositivi può utilizzare Regioni AWS il tuo account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) nella Guida di riferimento alla gestione degli *AWS account*. La console Resource Groups non è disponibile in queste Regioni.
# Politiche relative alle applicazioni di chat
Le politiche delle applicazioni di chat ti AWS Organizations consentono di controllare l'accesso agli account della tua organizzazione da applicazioni di chat come Slack e Microsoft Teams.
[Amazon Q Developer nelle applicazioni di chat](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) è un AWS servizio che consente ai DevOps team di sviluppo software di utilizzare le chat room dei programmi di messaggistica per monitorare e rispondere agli eventi operativi nei propri ambienti Cloud AWS. Amazon Q Developer nelle applicazioni di chat elabora Servizio AWS le notifiche da Amazon Simple Notification Service (Amazon SNS) e le inoltra alle chat room in modo che i team possano analizzarle e agire di conseguenza immediatamente, indipendentemente dalla posizione.
## Come funzionano le politiche delle applicazioni di chat
Utilizzando le politiche delle applicazioni di chat, l'account di gestione o l'amministratore delegato di un'organizzazione può eseguire le seguenti operazioni all'interno dell'organizzazione:
+ Imponi quali applicazioni di chat supportate (Amazon Chime, Microsoft Teams e Slack) possono essere utilizzate.
+ Limita l'accesso del client di chat a specifici spazi di lavoro (Slack) e team (Microsoft Teams).
+ Limita la visibilità del canale Slack ai canali pubblici o privati.
+ Imposta e applica impostazioni di [ruolo](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html#role-settings) specifiche.
Le politiche delle applicazioni di chat limitano e hanno la precedenza sulle impostazioni a livello di account, come le impostazioni dei [ruoli e le](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html#role-settings) politiche del [guardrail del canale](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html#channel-guardrails). Puoi accedere e modificare le policy delle applicazioni di chat da Amazon Q Developer nelle applicazioni di chat o dalla console Organizations.
Una volta allegate le policy agli account e alle unità organizzative (OU), tutte le configurazioni attuali e future di applicazioni Amazon Q Developer in chat per gli account interessati rispetteranno automaticamente le impostazioni di governance e autorizzazioni. Per ulteriori informazioni, consulta [Comprendere l'ereditarietà delle politiche di gestione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_mgmt.html).
Se tenti di eseguire un'azione limitata da una politica delle applicazioni di chat, un messaggio di errore ti informerà che l'azione non è consentita a causa della politica delle applicazioni di chat con la raccomandazione di contattare l'account di gestione o l'amministratore delegato dell'organizzazione.
**Nota**
Le politiche delle applicazioni di chat vengono convalidate in fase di esecuzione. Ciò significa che le risorse esistenti vengono continuamente controllate per verificarne la conformità. Non vi è alcuna sovrapposizione con le autorizzazioni IAM esistenti poiché le autorizzazioni IAM basate su runtime per l'invio di notifiche o l'interazione con Amazon Q Developer nelle applicazioni di chat non sono attualmente supportate.
# Guida introduttiva alle politiche delle applicazioni di chat
Segui questi passaggi per iniziare a utilizzare le politiche delle applicazioni di chat.
1. [Scopri le autorizzazioni necessarie per eseguire le attività relative alle politiche delle applicazioni di chat](orgs_manage_policies_prereqs.md).
1. [Abilita le politiche delle applicazioni di chat per la tua organizzazione](enable-policy-type.md).
1. [Crea una politica per le applicazioni di chat](orgs_policies_create.md).
1. [Allega la policy relativa alle applicazioni di chat alla directory principale, all'unità organizzativa o all'account della tua organizzazione](orgs_policies_attach.md).
1. [Visualizza la politica combinata sulle applicazioni di chat efficaci che si applica a un account](orgs_manage_policies_effective.md).
Per tutte queste fasi, è possibile accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([scelta non consigliata](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
**Altre informazioni**
+ [Scopri la sintassi delle politiche delle applicazioni di chat e guarda esempi di politiche](orgs_manage_policies_chatbot_syntax.md)
# Sintassi ed esempi delle policy delle applicazioni di chat
Questo argomento descrive la sintassi delle politiche delle applicazioni di chat e fornisce esempi.
## Sintassi per le politiche delle applicazioni di chat
[Una policy per le applicazioni di chat è un file di testo semplice strutturato secondo le regole di JSON.](http://json.org) La sintassi per le politiche delle applicazioni di chat segue la sintassi per i tipi di policy di gestione. Per una discussione completa di tale sintassi, consulta [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md). Questo argomento si concentra sull'applicazione di tale sintassi generale ai requisiti specifici del tipo di policy delle applicazioni di chat.
L'esempio seguente mostra la sintassi di base per una politica delle applicazioni di chat:
```
{
"chatbot":{
"platforms":{
"slack":{
"client":{
"@@assign":"enabled" // enabled | disabled
},
"workspaces": { // limit 255
"@@assign":[
"Slack-Workspace-Id"
]
},
"default":{
"supported_channel_types":{
"@@assign":[
"private" // public | private
]
},
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
},
"overrides":{ // limit 255
"Slack-Workspace-Id":{
"supported_channel_types":{
"@@assign":[
"public" // public | private
]
},
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
}
}
},
"microsoft_teams":{
"client":{
"@@assign":"enabled"
},
"tenants":{ // limit 36
"Microsoft-Teams-Tenant-Id":{ // limit 36
"@@assign":[
"Microsoft-Teams-Team-Id"
]
}
},
"default":{
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
},
"overrides":{ // limit 36
"Microsoft-Teams-Tenant-Id":{ // limit 36
"Microsoft-Teams-Team-Id":{
"supported_role_settings":{
"@@assign":[
"user_role" // user_role | channel_role
]
}
}
}
}
},
"chime":{
"client":{
"@@assign":"disabled" // enabled | disabled
}
}
},
"default":{
"client":{
"@@assign":"disabled" // enabled | disabled
}
}
}
}
```
Questa politica per le applicazioni di chat include i seguenti elementi:
+ Il nome della chiave di campo `chatbot`. Le politiche delle applicazioni di chat iniziano sempre con questo nome a chiave fissa. È la riga principale di questo esempio di policy.
+ Sotto `chatbot` c'è un `platforms` blocco che contiene la configurazione per le diverse applicazioni di chat supportate: Slack, Microsoft Teams e Amazon Chime.
+ Per Slack, sono disponibili i seguenti campi:
+ `"client"`:
+ `"enabled"`: Il client Slack è abilitato. Le integrazioni con Slack sono consentite.
+ `"disabled"`: Il client Slack è disabilitato. Le integrazioni con Slack non sono consentite.
+ `"workspaces"`: elenco separato da virgole degli spazi di lavoro Slack consentiti. In questo esempio, gli spazi di lavoro Slack consentiti sono e. *Slack-Workspace-Id1* *Slack-Workspace-Id2*
+ `"default"`: Le impostazioni predefinite per le aree di lavoro Slack.
+ `"supported_channel_types"`:
+ `"public"`: Le aree di lavoro Slack incluse nell'ambito consentono i canali Slack pubblici per impostazione predefinita.
+ `"private"`: Le aree di lavoro Slack incluse nell'ambito consentono i canali Slack privati per impostazione predefinita.
+ `supported_role_settings`:
+ `"user_role"`: Gli spazi di lavoro Slack inclusi nell'ambito consentono i ruoli IAM a livello di utente per impostazione predefinita.
+ `"channel_role"`: Gli spazi di lavoro Slack inclusi nell'ambito consentono i ruoli IAM a livello di canale per impostazione predefinita.
+ `"overrides"`: Le impostazioni di override per gli spazi di lavoro Slack.
+ `Slack-Workspace-Id2`: elenco separato da virgole delle aree di lavoro Slack a cui si applica l'impostazione di override. In questo esempio, l'area di lavoro di Slack è. *Slack-Workspace-Id2*
+ `"supported_channel_types"`:
+ `"public"`: Sostituisci l'impostazione se le aree di lavoro Slack incluse nell'ambito consentono i canali Slack pubblici.
+ `"private"`: Sostituisci l'impostazione se le aree di lavoro Slack nell'ambito consentono i canali Slack privati.
+ `supported_role_settings`:
+ `"user_role"`: Sostituisci l'impostazione se le aree di lavoro Slack nell'ambito consentono i ruoli IAM a livello di utente.
+ `"channel_role"`: Sostituisci l'impostazione se le aree di lavoro Slack nell'ambito consentono i ruoli IAM a livello di canale.
+ Per Microsoft Teams, sono disponibili i seguenti campi:
+ `"client"`:
+ `"enabled"`: il client Microsoft Teams è abilitato. Le integrazioni con Microsoft Teams sono consentite.
+ `"disabled"`: il client Microsoft Teams è disabilitato. Le integrazioni con Microsoft Teams non sono consentite.
+ `"tenants"`: elenco separato da virgole dei tenant di Microsoft Teams consentiti. In questo esempio, il tenant consentito è. *Microsoft-Teams-Tenant-Id*
+ `Microsoft-Teams-Tenant-Id`: elenco separato da virgole dei team consentiti all'interno del tenant. In questo esempio, il team consentito è. *Microsoft-Teams-Team-Id*
+ `"default"`: Le impostazioni predefinite per i team all'interno del tenant.
+ `supported_role_settings`:
+ `"user_role"`: I team inclusi nell'ambito consentono i ruoli IAM a livello di utente per impostazione predefinita.
+ `"channel_role"`: I team inclusi nell'ambito consentono i ruoli IAM a livello di canale per impostazione predefinita.
+ `"overrides"`: le impostazioni di override per i tenant di Microsoft Teams.
+ `Microsoft-Teams-Tenant-Id`: elenco separato da virgole dei tenant a cui si applica l'impostazione di esclusione. In questo esempio, il tenant è. *Microsoft-Teams-Tenant-Id*
+ `Microsoft-Teams-Team-Id`: elenco separato da virgole dei team all'interno del tenant. In questo esempio, il team consentito è. *Microsoft-Teams-Team-Id*
+ `supported_role_settings`:
+ `"user_role"`: Sostituisci l'impostazione se i team inclusi nell'ambito consentono i ruoli IAM a livello di utente.
+ `"channel_role"`: sostituisci l'impostazione se i team inclusi nell'ambito consentono i ruoli IAM a livello di canale.
+ Per Amazon Chime, sono disponibili i seguenti campi:
+ `"client"`:
+ `"enabled"`: il client Amazon Chime è abilitato. Le integrazioni con Amazon Chime sono consentite.
+ `"disabled"`: il client Amazon Chime è disabilitato. Le integrazioni con Amazon Chime non sono consentite.
+ Sotto`chatbot`, c'è un `default` blocco che disabilita Amazon Q Developer nelle applicazioni di chat di tutta l'organizzazione, a meno che non venga sovrascritto a un livello inferiore. Questa impostazione predefinita disabilita anche qualsiasi nuova applicazione di chat supportata da Amazon Q Developer nelle applicazioni di chat. Ad esempio, se Amazon Q Developer nelle applicazioni di chat supporta una nuova applicazione di chat, questa impostazione predefinita disabilita anche quella nuova applicazione di chat supportata.
**Nota**
Per ulteriori informazioni sui ruoli IAM a livello di canale e sui ruoli IAM a livello di utente, consulta [Understanding Amazon Q Developer in chat applications permissions](https://docs.aws.amazon.com/chatbot/latest/adminguide/understanding-permissions.html) nella *Amazon Q Developer in chat applications Administrator Guide*.
## Esempi di policy per le applicazioni di chat
Le policy di esempio che seguono sono solo a scopo informativo.
### Esempio 1: consenti solo i canali Slack privati in uno spazio di lavoro specifico, disabilita Microsoft Teams, sono supportate tutte le modalità di autenticazione
La seguente politica si concentra sul controllo delle configurazioni consentite per le integrazioni di chatbot di Slack e Microsoft Teams.
```
{
"chatbot": {
"platforms": {
"slack": {
"client": {
"@@assign": "enabled"
},
"workspaces": {
"@@assign": [
"Slack-Workspace-Id"
]
},
"default": {
"supported_channel_types": {
"@@assign": [
"private"
]
},
"supported_role_settings": {
"@@assign": [
"channel_role",
"user_role"
]
}
}
},
"microsoft_teams": {
"client": {
"@@assign": "disabled"
}
},
"chime":{
"client":{
"@@assign":"disabled"
}
},
"default":{
"client":{
"@@assign":"disabled"
}
}
}
}
}
```
**Per Slack**
+ Il client Slack è abilitato.
+ È consentito solo lo spazio di lavoro *Slack-Workspace-Id* Slack specifico.
+ Le impostazioni predefinite consentono solo i canali Slack privati, i ruoli IAM a livello di canale e i ruoli IAM a livello di utente.
**Per Microsoft Team**
+ Il client Microsoft Teams è disabilitato.
**Per Amazon Chime**
+ Il client Amazon Chime è disabilitato.
**Dettagli aggiuntivi**
+ Il `default` blocco in basso imposta la disattivazione del client, che disattiva Amazon Q Developer nelle applicazioni di chat in tutta l'organizzazione a meno che non venga sovrascritto a un livello inferiore. Questa impostazione predefinita disabilita anche qualsiasi nuova applicazione di chat supportata da Amazon Q Developer nelle applicazioni di chat. Ad esempio, se Amazon Q Developer nelle applicazioni di chat supporta una nuova applicazione di chat, questa impostazione predefinita disabilita anche quella nuova applicazione di chat supportata.
### Esempio 2: consenti solo le integrazioni di Slack con ruoli IAM a livello di utente
La seguente policy adotta un approccio più permissivo a Slack, consentendo tutte le aree di lavoro Slack ma limitando la modalità di autenticazione ai soli ruoli IAM a livello di utente.
```
{
"chatbot":{
"platforms":{
"slack":{
"client":{
"@@assign":"enabled"
},
"workspaces":
{
"@@assign":[
"*"
]
},
"default":{
"supported_role_settings":{
"@@assign":[
"user_role"
]
}
}
},
"microsoft_teams":{
"client":{
"@@assign":"disabled"
}
},
"chime":{
"client":{
"@@assign":"disabled"
}
}
},
"default":{
"client":{
"@@assign":"disabled"
}
}
}
}
```
**Per Slack**
+ Il client Slack è abilitato.
+ Non vengono definiti spazi di lavoro Slack specifici utilizzando il carattere jolly`"*"`, quindi tutti gli spazi di lavoro sono consentiti.
+ Le impostazioni predefinite consentono solo i ruoli IAM a livello di utente.
**Per Microsoft Team**
+ Il client Microsoft Teams è disabilitato.
**Per Amazon Chime**
+ Il client Amazon Chime è disabilitato.
**Dettagli aggiuntivi**
+ Il `default` blocco in basso imposta la disattivazione del client, che disattiva Amazon Q Developer nelle applicazioni di chat in tutta l'organizzazione a meno che non venga sovrascritto a un livello inferiore. Questa impostazione predefinita disabilita anche qualsiasi nuova applicazione di chat supportata da Amazon Q Developer nelle applicazioni di chat. Ad esempio, se Amazon Q Developer nelle applicazioni di chat supporta una nuova applicazione di chat, questa impostazione predefinita disabilita anche quella nuova applicazione di chat supportata.
### Esempio 3: consenti solo le integrazioni di Microsoft Teams in uno specifico Tenant
La politica di esempio seguente blocca l'organizzazione per consentire solo le integrazioni di chatbot di Microsoft Teams all'interno del tenant specificato, bloccando completamente le integrazioni di Slack.
```
{
"chatbot":{
"platforms":{
"slack":{
"client": {
"@@assign": "disabled"
},
},
"microsoft_teams":{
"client": {
"@@assign": "enabled"
},
"tenants":{
"Microsoft-Teams-Tenant-Id":{
"@@assign":[
"*"
]
}
}
},
"chime": {
"client":{
"@@assign": "disabled"
}
}
}
}
}
```
**Per Slack**
+ Il client Slack è disabilitato.
**Per Microsoft Team**
+ *Microsoft-Teams-Tenant-Id*È consentito solo il tenant specifico, utilizzando la jolly `"*"` per consentire l'accesso a tutti i team all'interno di quel tenant.
**Per Amazon Chime**
+ Il client Amazon Chime è disabilitato.
**Dettagli aggiuntivi**
+ Il `default` blocco in basso imposta la disattivazione del client, che disattiva Amazon Q Developer nelle applicazioni di chat in tutta l'organizzazione a meno che non venga sovrascritto a un livello inferiore. Questa impostazione predefinita disabilita anche qualsiasi nuova applicazione di chat supportata da Amazon Q Developer nelle applicazioni di chat. Ad esempio, se Amazon Q Developer nelle applicazioni di chat supporta una nuova applicazione di chat, questa impostazione predefinita disabilita anche quella nuova applicazione di chat supportata.
### Esempio 4: consente l'accesso limitato ad Amazon Q Developer nelle applicazioni di chat per le aree di lavoro Slack e un tenant di Microsoft Teams
La seguente politica consente l'accesso limitato ad Amazon Q Developer nelle applicazioni di chat per aree di lavoro Slack selezionate e un tenant Microsoft Teams.
```
{
"chatbot":{
"platforms":{
"slack":{
"client":{
"@@assign":"enabled"
},
"workspaces": {
"@@assign":[
"Slack-Workspace-Id1",
"Slack-Workspace-Id2"
]
},
"default":{
"supported_channel_types":{
"@@assign":[
"private"
]
},
"supported_role_settings":{
"@@assign":[
"user_role"
]
}
},
"overrides":{
"Slack-Workspace-Id2":{
"supported_channel_types":{
"@@assign":[
"public",
"private"
]
},
"supported_role_settings":{
"@@assign":[
"channel_role",
"user_role"
]
}
}
}
},
"microsoft_teams":{
"client":{
"@@assign":"enabled"
},
"tenants":{
"Microsoft-Teams-Tenant-Id":{
"@@assign":[
"Microsoft-Teams-Team-Id"
]
}
},
"default":{
"supported_role_settings":{
"@@assign":[
"user_role"
]
}
},
"overrides":{
"Microsoft-Teams-Tenant-Id":{
"Microsoft-Teams-Team-Id":{
"supported_role_settings":{
"@@assign":[
"channel_role",
"user_role"
]
}
}
}
}
}
},
"default":{
"client":{
"@@assign":"disabled"
}
}
}
}
```
**Per Slack**
+ Il client Slack è abilitato.
+ Le aree di lavoro Slack consentite sono e. *Slack-Workspace-Id1* *Slack-Workspace-Id2*
+ Le impostazioni predefinite per Slack consentono solo i canali privati e i ruoli IAM a livello di utente.
+ Esiste un'eccezione per l'area di lavoro *Slack-Workspace-Id2* che consente sia i canali pubblici che quelli privati, nonché i ruoli IAM a livello di canale e i ruoli IAM a livello di utente.
**Per Microsoft Team**
+ Microsoft Teams è abilitato.
+ Gli inquilini autorizzati di Teams fanno *Microsoft-Teams-Tenant-Id* parte del team*Microsoft-Teams-Team-Id*.
+ Le impostazioni predefinite consentono solo i ruoli IAM a livello di utente.
+ Esiste un'eccezione per il tenant *Microsoft-Teams-Tenant-Id* che consente sia i ruoli IAM a livello di canale che i ruoli IAM a livello di utente per il team. *Microsoft-Teams-Team-Id*
**Dettagli aggiuntivi**
+ Il `default` blocco in basso imposta la disattivazione del client, che disattiva Amazon Q Developer nelle applicazioni di chat in tutta l'organizzazione a meno che non venga sovrascritto a un livello inferiore. Ciò significa che Amazon Chime è disabilitato in questo esempio. Questa impostazione predefinita disabilita anche qualsiasi nuova applicazione di chat supportata da Amazon Q Developer nelle applicazioni di chat. Ad esempio, se Amazon Q Developer nelle applicazioni di chat supporta una nuova applicazione di chat, questa impostazione predefinita disabilita anche quella nuova applicazione di chat supportata.
# Policy di rifiuto dei servizi di IA
AWS I servizi di intelligenza artificiale possono utilizzare e archiviare i contenuti dei clienti per il miglioramento del servizio, ad esempio la risoluzione di problemi operativi, la valutazione delle prestazioni del servizio, il debug o la formazione dei modelli. A tal fine, potremmo archiviare tali contenuti Regione AWS all'esterno del luogo in Regione AWS cui l'utente utilizza il servizio. Puoi rinunciare all'uso dei tuoi contenuti per migliorare il servizio utilizzando la politica di AWS Organizations opt-out.
Puoi creare politiche di opt-out per un singolo servizio di intelligenza artificiale o per tutti i servizi supportati dalle politiche di opt-out dei servizi di intelligenza artificiale. Puoi anche interrogare la politica efficace applicabile a ciascun account per vedere gli effetti delle tue scelte di impostazione.
Per informazioni più dettagliate, consulta [AWS Machine Learning and Artificial Intelligence Services](https://aws.amazon.com/service-terms) nei Termini AWS di servizio. Per un elenco dei servizi supportati dalle politiche di disattivazione dei servizi di intelligenza artificiale, consulta [Elenco dei servizi di intelligenza artificiale supportati](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_all.html#ai-opt-out-all-list).
**Topics**
+ [Considerazioni](#orgs_manage_policies-ai-opt-out-considerations)
+ [Nozioni di base](orgs_manage_policies-ai-opt-out_getting-started.md)
+ [Disattiva tutti i servizi di intelligenza artificiale](orgs_manage_policies_ai-opt-out_all.md)
+ [Sintassi ed esempi di policy di rifiuto dei servizi di IA](orgs_manage_policies_ai-opt-out_syntax.md)
## Considerazioni sull'utilizzo delle politiche di opt-out dei servizi AI
**La disattivazione comporta l'eliminazione di tutti i contenuti storici associati**
Quando si disattiva l'uso dei contenuti da parte di un servizio di AWS intelligenza artificiale, tale servizio elimina tutti i contenuti storici associati con cui è stato condiviso AWS prima dell'impostazione dell'opzione. Questa eliminazione è limitata ai contenuti archiviati che non sono necessari per fornire le funzioni del servizio.
Ad esempio, quando si utilizza un servizio mentre si è attivati, tale servizio potrebbe archiviare copie dei contenuti per migliorare il servizio. Quando si effettua l'opt-out, tutte le copie archiviate dal servizio a tale scopo vengono eliminate, ma i contenuti utilizzati per fornire il servizio non vengono eliminati.
# Guida introduttiva alle policy di rifiuto dei servizi di IA
Attieniti alla seguente procedura per iniziare a utilizzare le policy di rifiuto dei servizi di intelligenza artificiale (IA).
1. [Ulteriori informazioni sulle autorizzazioni necessarie per eseguire attività delle policy di backup](orgs_manage_policies_prereqs.md)
1. [Abilita le policy di rifiuto dei servizi di IA per l'organizzazione](enable-policy-type.md).
1. [Crea una policy di rifiuto dei servizi di IA](orgs_policies_create.md#create-ai-opt-out-policy-procedure).
1. [Collega la policy di rifiuto dei servizi di IA al root, all'unità organizzativa o all'account dell'organizzazione](orgs_policies_attach.md).
1. [Visualizza la policy di rifiuto dei servizi di IA effettiva combinata applicabile a un account](orgs_manage_policies_effective.md).
Per tutti questi passaggi, accedi come utente AWS Identity and Access Management (IAM), assumi un ruolo IAM o accedi come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
**Altre informazioni**
+ [Scopri la sintassi delle policy per le policy di rifiuto dei servizi di IA e consulta esempi di policy](orgs_manage_policies_ai-opt-out_syntax.md)
# Disattiva tutti i servizi di AWS intelligenza artificiale supportati
**In questo argomento:**
+ Puoi disattivarlo selezionando un solo pulsante nella AWS Organizations console.
+ Puoi annullare l'iscrizione allegando la politica di esempio fornita utilizzando il pulsante AWS CLI & AWS SDKs.
+ Puoi visualizzare un elenco di quelle Servizi AWS supportate dalla politica di opt-out dei servizi AI.
## Disattiva tutti i servizi di intelligenza artificiale supportati
Puoi impedire alla tua organizzazione di utilizzare i propri contenuti per il miglioramento del servizio creando e allegando una politica di disattivazione dei servizi di intelligenza artificiale. Questa politica si applica a tutti i servizi di AWS intelligenza artificiale supportati attuali e futuri. Gli account dei membri non possono aggiornare la politica.
------
#### [ Console di gestione AWS ]
**Per disattivare tutti i servizi di intelligenza artificiale**
1. Accedi alla [console AWS Organizations](https://console.aws.amazon.com/organizations/v2). È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
1. Nella pagina delle **[politiche di disattivazione dei servizi AI](https://console.aws.amazon.com/organizations/v2/home/policies/aiservices-opt-out-policy)**, **scegli Disattiva tutti i servizi**.
1. Nella pagina di conferma dell'**esclusione da tutti i servizi**, **scegli Rinuncia a tutti i servizi**.
------
#### [ AWS CLI & AWS SDKs ]
**Per disattivare tutti i servizi di intelligenza artificiale**
1. Copia «Esempio 1: disattivazione di tutti i servizi di intelligenza artificiale per tutti gli account dell'organizzazione» negli [esempi di disattivazione dei servizi di intelligenza artificiale](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_syntax.html#ai-opt-out-policy-examples).
1. Segui le istruzioni riportate in [Allegare e scollegare i servizi di intelligenza artificiale (opt-out](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_attach.html)).
------
**Nota**
Sono necessari passaggi aggiuntivi per disattivare Amazon Monitron. Per ulteriori informazioni, consultare [Termini del servizio AWS](https://aws.amazon.com/service-terms/#81._Industrial_AI_Services).
## Elenco dei servizi supportati dalla politica di esclusione dei servizi AI
Di seguito è riportato un elenco dei servizi Servizi AWS supportati dalla politica di opt-out dei servizi AI:
+ [Operazioni Amazon AI](https://aws.amazon.com/what-is/aiops)
+ [Analisi vocale dell'SDK Amazon Chime](https://docs.aws.amazon.com/chime-sdk/latest/dg/voice-analytics.html)
+ [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch)
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru)
+ [Amazon CodeWhisperer](https://docs.aws.amazon.com/codewhisperer) (ora parte di [Amazon Q Developer](https://docs.aws.amazon.com/amazonq))
+ [Amazon Comprehend](https://docs.aws.amazon.com/comprehend)
+ [Amazon Connect](https://docs.aws.amazon.com/connect)
+ [Ottimizzazione di Amazon Connect](https://docs.aws.amazon.com/connect)
+ [Lenti a contatto Amazon Connect](https://docs.aws.amazon.com/connect/latest/adminguide/contact-lens.html)
+ [AWS Servizio di migrazione del Database](https://docs.aws.amazon.com/dms)
+ [Amazon DataZone](https://docs.aws.amazon.com/datazone) (e [Amazon SageMaker Data Agent](https://docs.aws.amazon.com/sagemaker-unified-studio/latest/userguide/sagemaker-data-agent.html))
+ [AWS DevOps Agente](https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent.html)
+ [AWS Entity Resolution](https://docs.aws.amazon.com/entityresolution)
+ [Amazon Fraud Detector](https://docs.aws.amazon.com/frauddetector)
+ [AWS Glue](https://docs.aws.amazon.com/glue)
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty)
+ [Amazon Lex](https://docs.aws.amazon.com/lex)
+ [Amazon Polly](https://docs.aws.amazon.com/polly)
+ [Amazon Q](https://docs.aws.amazon.com/amazonq)
+ [Amazon Quick](https://docs.aws.amazon.com/quicksight)
+ [Amazon Rekognition](https://docs.aws.amazon.com/rekognition)
+ [Amazon Security Lake](https://docs.aws.amazon.com/security-lake/)
+ [Catena di approvvigionamento di AWS](https://docs.aws.amazon.com/aws-supply-chain)
+ [Amazon Textract](https://docs.aws.amazon.com/textract)
+ [Amazon Transcribe](https://docs.aws.amazon.com/transcribe)
+ [AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/what-is.html) (Trasforma)
+ [Amazon Translate](https://docs.aws.amazon.com/translate)
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces)
+ [AWS Security Hub](https://docs.aws.amazon.com/securityhub)
# Sintassi ed esempi di policy di rifiuto dei servizi di IA
In questo argomento viene descritta la sintassi delle policy di rifiuto dei servizi di intelligenza artificiale (IA) e vengono forniti esempi.
## Sintassi per le policy di rifiuto dei servizi di IA
Una policy di rifiuto dei servizi di IA è un file di testo normale strutturato in base alle regole di [JSON](http://json.org). La sintassi per le policy di rifiuto dei servizi di IA segue la sintassi per tutti i tipi di policy di gestione. Per una discussione completa di tale sintassi, consulta [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md). Questo argomento è incentrato sull'applicazione della sintassi generale ai requisiti specifici del tipo di policy di rifiuto dei servizi di IA.
**Importante**
L'uso di minuscole e maiuscole dei valori trattati in questa sezione è importante. Inserisci i valori con lettere maiuscole e minuscole come illustrato in questo argomento. Le policy non funzionano se si utilizzano maiuscole e minuscole impreviste.
La policy seguente mostra la sintassi delle policy di rifiuto dei servizi di IA di base. Se questo esempio fosse stato applicato direttamente a un account, tale account avrebbe esplicitamente rifiutato un servizio e accettato un altro servizio. Altri servizi possono essere accettati o rifiutati dalle policy ereditate da livelli superiori (policy di UO o root).
```
{
"services": {
"rekognition": {
"opt_out_policy": {
"@@assign": "optOut"
}
},
"lex": {
"opt_out_policy": {
"@@assign": "optIn"
}
}
}
}
```
Immagina la seguente policy di esempio collegata al root dell'organizzazione. Imposta il rifiuto di tutti i servizi di IA come impostazione predefinita per l'organizzazione. Ciò include automaticamente tutti i servizi di IA non altrimenti esplicitamente esclusi, inclusi i servizi di IA che AWS potrebbe implementare in futuro. Puoi allegare politiche per bambini a OUs o direttamente agli account per sostituire questa impostazione per qualsiasi servizio di intelligenza artificiale ad eccezione di Amazon Comprehend. La seconda voce dell'esempio seguente utilizza `@@operators_allowed_for_child_policies` impostato su `none` per evitare che venga sovrascritto. La terza voce nell'esempio imposta un'esenzione a livello di organizzazione per Amazon Rekognition. La policy accetta il servizio per tutta l'organizzazione, ma consente alle policy figlie di ignorarla se appropriato.
```
{
"services": {
"default": {
"opt_out_policy": {
"@@assign": "optOut"
}
},
"comprehend": {
"opt_out_policy": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "optOut"
}
},
"rekognition": {
"opt_out_policy": {
"@@assign": "optIn"
}
}
}
}
```
La sintassi della policy di rifiuto dei servizi di IA include i seguenti elementi:
+ L'elemento `services`. Una policy di rifiuto dei servizi di IA è identificato da questo nome fisso come elemento contenente JSON più esterno.
Una policy di rifiuto dei servizi di IA può avere una o più istruzioni sotto l'elemento `services`. Ogni istruzione contiene i seguenti elementi:
+ Una *chiave del nome del servizio* che identifica un AWS servizio di intelligenza artificiale. I seguenti nomi di chiave sono i valori validi per questo campo:
+ **`default`** - Rappresenta **tutti** i servizi di IA attualmente disponibili e include implicitamente e automaticamente tutti i servizi di IA che potrebbero essere aggiunti in futuro.
+ `aiops`
+ `aidevops`
+ `awssupplychain`
+ `chimesdkvoiceanalytics`
+ `cloudwatch`
+ `codeguruprofiler`
+ `codewhisperer`
+ `comprehend`
+ `connect`
+ `connectamd`
+ `connectoptimization`
+ `contactlens`
+ `datazone`
+ `dms`
+ `entityresolution`
+ `frauddetector`
+ `glue`
+ `guardduty`
+ `lex`
+ `polly`
+ `q`
+ `quicksightq`
+ `rekognition`
+ `securitylake`
+ `textract`
+ `transcribe`
+ `transform`
+ `translate`
+ `workspaces`
+ `securityhub`
Ogni istruzione di policy identificata da una chiave di nome servizio può contenere i seguenti elementi:
+ La chiave `opt_out_policy`. Questa chiave deve essere presente. Questa è l'unica chiave che puoi inserire sotto una chiave di nome del servizio.
La chiave `opt_out_policy` può contenere ***solo*** l'operatore `@@assign` con uno dei seguenti valori:
+ `optOut` - Scegli di rifiutare l'utilizzo del contenuto per il servizio di IA specificato.
+ `optIn` - Scegli di accettare l'utilizzo del contenuto per il servizio di IA specificato.
**Note**
Non è possibile utilizzare gli operatori di ereditarietà `@@append` e `@@remove` nelle policy di rifiuto dei servizi di IA.
Non è possibile utilizzare l'operatore `@@enforced_for` nelle policy di rifiuto dei servizi di IA.
+ A qualsiasi livello, è possibile specificare l'operatore `@@operators_allowed_for_child_policies` per controllare che cosa possono fare le policy figlie per sovrascrivere le impostazioni imposte dalle policy padre. È possibile specificare uno dei seguenti valori:
+ `@@assign` - Le policy figlie di questa policy possono utilizzare l'operatore `@@assign` per sovrascrivere il valore ereditato con un valore diverso.
+ `@@none` - Le policy figlie di questa policy non possono modificare il valore.
Il comportamento di `@@operators_allowed_for_child_policies` dipende da dove lo posizioni. Puoi utilizzare le posizioni seguenti:
+ Sotto la chiave `services` - Controlla se una policy figlia può integrare o modificare l'elenco dei servizi nella policy effettiva.
+ Sotto la chiave per un servizio di IA specifico o la chiave `default` - Controlla se una policy figlia può integrare o modificare l'elenco di chiavi in questa voce specifica.
+ Sotto la chiave `opt_out_policies` per un servizio specifico - Controlla se una policy figlia può modificare soltanto le impostazioni di questo servizio specifico.
## Esempi di policy di rifiuto dei servizi di IA
Le policy di esempio che seguono sono solo a scopo informativo.
### Esempio 1: disattivazione di tutti i servizi di IA per tutti gli account dell'organizzazione
Nell'esempio seguente viene illustrata una policy che è possibile collegare alla directory principale dell'organizzazione per disattivare i servizi di IA per gli account dell'organizzazione.
**Suggerimento**
Se copi l'esempio seguente utilizzando il pulsante Copia nell'angolo superiore destro dell'esempio, la copia non include i numeri di riga. È pronta per essere incollata.
```
| {
| "services": {
[1] | "@@operators_allowed_for_child_policies": ["@@none"],
| "default": {
[2] | "@@operators_allowed_for_child_policies": ["@@none"],
| "opt_out_policy": {
[3] | "@@operators_allowed_for_child_policies": ["@@none"],
| "@@assign": "optOut"
| }
| }
| }
| }
```
+ [1] - `"@@operators_allowed_for_child_policies": ["@@none"]` in `services` impedisce alle policy figlie di aggiungere nuove sezioni per i servizi individuali diverse dalla sezione `default` già presente. `Default` è il segnaposto che rappresenta "tutti i servizi di IA".
+ [2] - `"@@operators_allowed_for_child_policies": ["@@none"]` in `default` impedisce alle policy figlie di aggiungere nuove sezioni diverse dalla sezione `opt_out_policy` già presente.
+ [3] - `"@@operators_allowed_for_child_policies": ["@@none"]` in `opt_out_policy` impedisce alle policy figlie di modificare il valore dell'impostazione di `optOut` o di aggiungere ulteriori impostazioni.
### Esempio 2: creazione di un'impostazione predefinita dell'organizzazione per tutti i servizi, consentendo alle policy figlie di ignorare l'impostazione per i singoli servizi
La policy di esempio seguente imposta un valore predefinito a livello di organizzazione per tutti i servizi di IA. Il valore per `default` impedisce a una policy figlia di modificare il valore `optOut` per il servizio `default`, il segnaposto per tutti i servizi di IA. Se questa policy viene applicata come policy padre collegandola al root o a un'unità organizzativa, le policy figlie possono comunque modificare l'impostazione di rifiuto dei singoli servizi, come illustrato nella seconda policy.
+ Perché non è presente `"@@operators_allowed_for_child_policies": ["@@none"]` sotto la chiave `services`, le policy figlie possono aggiungere nuove sezioni per i singoli servizi.
+ `"@@operators_allowed_for_child_policies": ["@@none"]` in `default` impedisce alle policy figlie di aggiungere nuove sezioni diverse dalla sezione `opt_out_policy` già presente.
+ `"@@operators_allowed_for_child_policies": ["@@none"]` in `opt_out_policy` impedisce alle policy figlie di modificare il valore dell'impostazione di `optOut` o di aggiungere ulteriori impostazioni.
**Policy padre di rifiuto esplicito dei servizi di IA per l'utente root dell'organizzazione**
```
{
"services": {
"default": {
"@@operators_allowed_for_child_policies": ["@@none"],
"opt_out_policy": {
"@@operators_allowed_for_child_policies": ["@@none"],
"@@assign": "optOut"
}
}
}
}
```
La seguente policy di esempio presuppone che la policy dell'esempio precedente sia collegata al root dell'organizzazione o a un'unità organizzativa padre e che questo esempio venga collegato a un account interessato dalla policy padre. Sovrascrive l'impostazione di rifiuto di default e sceglie esplicitamente solo il servizio Amazon Lex.
**Policy figlia di rifiuto esplicito dei servizi di IA - Intelligenza Artificiale**
```
{
"services": {
"lex": {
"opt_out_policy": {
"@@assign": "optIn"
}
}
}
}
```
La politica efficace che ne risulta Account AWS è che l'account opti solo per Amazon Lex e rinunci a tutti gli altri servizi di AWS intelligenza artificiale a causa dell'impostazione di `default` opt-out ereditata dalla politica principale.
### Esempio 3: definizione di una policy di disattivazione dei servizi di IA a livello di organizzazione per un singolo servizio
Nell'esempio seguente viene illustrata una policy di rifiuto dei servizi di IA che definisce un'impostazione `optOut` per un singolo servizio di IA. Se questa policy è collegata al root dell'organizzazione, impedisce a qualsiasi policy figlia di sovrascrivere l'impostazione `optOut` per questo servizio. Altri servizi non sono coperti da questa politica, ma potrebbero essere influenzati dalle politiche relative ai minori in altri account. OUs
```
{
"services": {
"rekognition": {
"opt_out_policy": {
"@@assign": "optOut",
"@@operators_allowed_for_child_policies": ["@@none"]
}
}
}
}
```
# Politiche del Security Hub
AWS Security Hub le politiche forniscono ai team addetti alla sicurezza un approccio centralizzato alla gestione delle configurazioni di sicurezza in tutti i loro ambienti. AWS Organizations Sfruttando queste politiche, è possibile stabilire e mantenere controlli di sicurezza coerenti attraverso un meccanismo di configurazione centrale. Questa integrazione consente di colmare le lacune nella copertura di sicurezza creando politiche in linea con i requisiti di sicurezza dell'organizzazione e applicandole centralmente a tutti gli account e le unità organizzative (). OUs
Le policy di Security Hub sono completamente integrate e consentono agli account di gestione o agli amministratori delegati di definire e applicare le configurazioni di sicurezza. AWS Organizations Quando gli account entrano a far parte dell'organizzazione, ereditano automaticamente le politiche applicabili in base alla loro posizione nella gerarchia organizzativa. Ciò garantisce che gli standard di sicurezza vengano applicati in modo coerente man mano che l'organizzazione cresce. Le politiche rispettano le strutture organizzative esistenti e offrono flessibilità nel modo in cui le configurazioni di sicurezza vengono distribuite, pur mantenendo il controllo centrale sulle impostazioni di sicurezza critiche.
## Caratteristiche e vantaggi principali
Le policy di Security Hub forniscono un set completo di funzionalità che aiutano a gestire e applicare le configurazioni di sicurezza in tutta l'organizzazione AWS . Queste funzionalità semplificano la gestione della sicurezza garantendo al contempo un controllo costante sull'ambiente multi-account.
+ [Attiva centralmente Security Hub](https://docs.aws.amazon.com/securityhub/latest/userguide/security-hub-adv-getting-started-enable.html#security-hub-adv-getting-started-enable-org-account) su tutti gli account e le regioni della tua organizzazione
+ Crea politiche di sicurezza che definiscano la configurazione di sicurezza tra account e OUs
+ Applica automaticamente le configurazioni di sicurezza ai nuovi account quando entrano a far parte della tua organizzazione
+ Garantisci impostazioni di sicurezza coerenti in tutta l'organizzazione
+ Impedisci agli account dei membri di modificare le configurazioni di sicurezza a livello di organizzazione
## Cosa sono le politiche del Security Hub?
Le policy di Security Hub sono AWS Organizations policy che forniscono il controllo centralizzato sulle configurazioni di sicurezza tra gli account dell'organizzazione. Queste policy si integrano perfettamente AWS Organizations per aiutarti a stabilire e mantenere standard di sicurezza coerenti in tutto l'ambiente con più account.
Quando si implementano le policy di Security Hub, si ottiene la possibilità di definire configurazioni di sicurezza specifiche che si propagano automaticamente all'interno dell'organizzazione. Ciò garantisce che tutti gli account, compresi quelli appena creati, siano in linea con i requisiti di sicurezza e le migliori pratiche dell'organizzazione.
Queste politiche aiutano anche a mantenere la conformità applicando controlli di sicurezza coerenti e impedendo ai singoli account di modificare le impostazioni di sicurezza a livello di organizzazione. Questo approccio centralizzato riduce in modo significativo il sovraccarico amministrativo legato alla gestione delle configurazioni di sicurezza in ambienti complessi e di grandi dimensioni. AWS
## Come funzionano le policy di Security Hub
Quando alleghi una policy di Security Hub alla tua organizzazione o unità organizzativa, valuta AWS Organizations automaticamente la policy e la applica in base all'ambito definito. Il processo di applicazione delle policy segue regole specifiche per la risoluzione dei conflitti:
Quando le regioni compaiono sia negli elenchi di attivazione che in quelli di disabilitazione, la configurazione di disabilitazione ha la precedenza. Ad esempio, se una regione è elencata sia nelle configurazioni di attivazione che di disabilitazione, Security Hub verrà disabilitato in quella regione.
Quando `ALL_SUPPORTED` viene specificata l'abilitazione, Security Hub è abilitato in tutte le regioni attuali e future a meno che non sia disabilitato esplicitamente. Ciò consente di mantenere una copertura di sicurezza completa man mano che AWS si espande in nuove regioni.
Le politiche per i figli possono modificare le impostazioni delle politiche principali utilizzando operatori di ereditarietà, consentendo un controllo granulare a diversi livelli organizzativi. Questo approccio gerarchico garantisce che unità organizzative specifiche possano personalizzare le proprie impostazioni di sicurezza mantenendo i controlli di base.
## Terminologia
In questo argomento vengono utilizzati i seguenti termini per discutere delle politiche di Security Hub.
**Terminologia delle policy di Security Hub**
| Termine | Definizione |
| --- | --- |
| Policy operativa | La politica finale che si applica a un account dopo aver combinato tutte le politiche ereditate. |
| Ereditarietà delle policy | Processo mediante il quale gli account ereditano le politiche dalle unità organizzative principali. |
| Amministratore delegato | Un account designato per gestire le politiche del Security Hub per conto dell'organizzazione. |
| Ruolo collegato al servizio | Un ruolo IAM che consente a Security Hub di interagire con altri AWS servizi. |
## Casi d'uso per le policy di Security Hub
Le policy di Security Hub risolvono le sfide più comuni di gestione della sicurezza in ambienti con più account. I seguenti casi d'uso dimostrano come le organizzazioni in genere implementano queste politiche per migliorare il proprio livello di sicurezza.
### Caso d'uso di esempio: requisiti di conformità regionali
Una multinazionale necessita di diverse configurazioni di Security Hub per diverse aree geografiche. Creano una politica principale che abilita Security Hub in tutte le regioni utilizzando`ALL_SUPPORTED`, quindi utilizzano politiche secondarie per disabilitare aree specifiche in cui sono richiesti controlli di sicurezza diversi. Ciò consente loro di mantenere la conformità alle normative regionali garantendo al contempo una copertura di sicurezza completa.
### Caso d'uso di esempio: standard di sicurezza del team di sviluppo
Un'organizzazione di sviluppo software implementa le politiche del Security Hub che consentono il monitoraggio nelle aree di produzione mantenendo le aree di sviluppo non gestite. Nelle proprie politiche utilizzano elenchi di regioni espliciti anziché `ALL_SUPPORTED` mantenere un controllo preciso sulla copertura del monitoraggio della sicurezza. Questo approccio consente loro di applicare controlli di sicurezza più rigorosi negli ambienti di produzione, mantenendo al contempo la flessibilità nelle aree di sviluppo.
## Ereditarietà e applicazione delle politiche
Comprendere come le politiche vengono ereditate e applicate è fondamentale per una gestione efficace della sicurezza in tutta l'organizzazione. Il modello di ereditarietà segue la AWS Organizations gerarchia, garantendo un'applicazione delle policy prevedibile e coerente.
+ Le politiche allegate a livello principale si applicano a tutti gli account
+ Gli account ereditano le politiche dalle unità organizzative principali
+ È possibile applicare più politiche a un singolo account
+ Le politiche più specifiche (più vicine all'account nella gerarchia) hanno la precedenza
## Convalida di policy
Quando si creano le policy di Security Hub, si verificano le seguenti convalide:
+ I nomi delle regioni devono essere identificatori di AWS regione validi
+ Le aree devono essere supportate da Security Hub
+ La struttura delle politiche deve seguire le AWS Organizations regole di sintassi delle politiche
+ Entrambi `enable_in_regions` gli `disable_in_regions` elenchi devono essere presenti, sebbene possano essere vuoti
## Considerazioni regionali e regioni supportate
Le policy di Security Hub operano in più regioni e richiedono un'attenta considerazione dei requisiti di sicurezza globali. La comprensione del comportamento regionale consente di implementare controlli di sicurezza efficaci in tutta la presenza globale dell'organizzazione.
+ L'applicazione delle politiche avviene in ogni regione in modo indipendente
+ Puoi specificare quali regioni includere o escludere nelle tue politiche
+ Le nuove regioni vengono incluse automaticamente quando si utilizza l'`ALL_SUPPORTED`opzione
+ Le politiche si applicano solo alle regioni in cui è disponibile Security Hub
## Fasi successive
Per iniziare a usare le policy di Security Hub:
1. Consulta i prerequisiti nella Guida introduttiva alle politiche di Security Hub
1. Pianifica la tua strategia politica utilizzando la nostra guida alle migliori pratiche
1. Scopri la sintassi delle policy e visualizza esempi di policy
# Guida introduttiva alle policy di Security Hub
Prima di configurare le policy di Security Hub, assicurati di aver compreso i prerequisiti e i requisiti di implementazione. Questo argomento ti guida attraverso il processo di configurazione e gestione di queste politiche nella tua organizzazione.
## Prima di iniziare
Esamina i seguenti requisiti prima di implementare le politiche del Security Hub:
+ Il tuo account deve far parte di un' AWS Organizations organizzazione
+ Devi aver effettuato l'accesso in uno dei seguenti modi:
+ L'account di gestione dell'organizzazione
+ Un account amministratore delegato con autorizzazioni per gestire le politiche del Security Hub
+ È necessario abilitare l'accesso affidabile per Security Hub nella propria organizzazione
+ È necessario abilitare il tipo di policy Security Hub nella radice dell'organizzazione
Inoltre, verifica che:
+ Security Hub è supportato nelle regioni in cui si desidera applicare le politiche
+ Il ruolo `AWSServiceRoleForSecurityHubV2` collegato al servizio è configurato nel tuo account di gestione. Per verificare l'esistenza di questo ruolo, esegui. `aws iam get-role --role-name AWSServiceRoleForSecurityHubV2` Se devi creare questo ruolo, puoi eseguirlo `aws securityhub enable-security-hub-v2` in qualsiasi regione dal tuo account di gestione o crearlo direttamente eseguendo`aws iam create-service-linked-role --aws-service-name securityhubv2.amazonaws.com`.
## Passaggi dell’implementazione
Per implementare le politiche del Security Hub in modo efficace, segui questi passaggi in sequenza. Ogni passaggio garantisce una configurazione corretta e aiuta a prevenire problemi comuni durante la configurazione. L'account di gestione o l'amministratore delegato può eseguire questi passaggi tramite la AWS Organizations console, l'interfaccia a riga di AWS comando (AWS CLI) o. AWS SDKs
1. [Abilita l'accesso affidabile per Security Hub](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access).
1. [Abilita le politiche di Security Hub per la tua organizzazione](enable-policy-type.md).
1. [Crea una policy Security Hub](orgs_policies_create.md#create-security-hub-policy-procedure).
1. [Allega la policy Security Hub alla directory principale, all'unità organizzativa o all'account della tua organizzazione](orgs_policies_attach.md).
1. [Visualizza la politica combinata efficace di Security Hub che si applica a un account](orgs_manage_policies_effective.md).
Per tutti questi passaggi, accedi come utente AWS Identity and Access Management (IAM), assumi un ruolo IAM o accedi come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
**Altre informazioni**
+ [Scopri la sintassi delle policy per le policy di Security Hub e guarda gli esempi di policy](orgs_manage_policies_security_hub_syntax.md)
# Le migliori pratiche per l'utilizzo delle policy di Security Hub
Quando si implementano le policy di Security Hub in tutta l'organizzazione, seguire le best practice consolidate aiuta a garantire la corretta implementazione e manutenzione delle configurazioni di sicurezza. Queste linee guida riguardano specificamente gli aspetti unici della gestione e dell'applicazione delle policy di Security Hub AWS Organizations.
## Principi di progettazione delle politiche
Prima di creare le policy di Security Hub, stabilisci principi chiari per la struttura delle policy. Mantieni le policy semplici ed evita complesse regole combinate tra attributi o annidate che rendono difficile la determinazione del risultato finale. Inizia con politiche generali a livello di organizzazione e perfezionale attraverso politiche secondarie, se necessario.
Prendi in considerazione l'utilizzo strategico di elenchi di regioni vuoti. Puoi lasciarlo `enable_in_regions` vuoto quando devi disabilitare Security Hub solo in aree specifiche o lasciare `disable_in_regions` vuoto per mantenere le aree non gestite dalle policy. Questa flessibilità ti aiuta a mantenere un controllo preciso sulla copertura del monitoraggio della sicurezza.
## Strategie di gestione delle regioni
Quando gestisci le aree tramite le policy del Security Hub, prendi in considerazione questi approcci collaudati. `ALL_SUPPORTED`Utilizzalo quando desideri includere automaticamente le regioni future nella copertura di sicurezza. Per un controllo più granulare, elenca in modo esplicito le regioni anziché fare affidamento su di esse`ALL_SUPPORTED`, soprattutto quando aree diverse richiedono configurazioni di sicurezza diverse.
Documenta i requisiti specifici della tua regione, in particolare per:
+ Regioni soggette a obblighi di conformità che richiedono configurazioni specifiche
+ Differenze tra ambiente di sviluppo e ambiente di produzione
+ Regioni che prevedono l'adesione con considerazioni particolari
+ Regioni in cui il Security Hub deve rimanere disabilitato
## Pianificazione dell'eredità delle politiche
Pianificate attentamente la struttura di ereditarietà delle polizze per mantenere un controllo di sicurezza efficace, garantendo al contempo la flessibilità necessaria. Documenta quali unità organizzative possono modificare le politiche ereditate e quali modifiche sono consentite. Prendi in considerazione la possibilità di limitare gli operatori di ereditarietà (@ @assign, @ @append, @ @remove) ai livelli principali quando devi applicare controlli di sicurezza rigorosi.
## Monitoraggio e convalida
Implementa pratiche di monitoraggio regolari per garantire che le tue politiche rimangano efficaci. Rivedi periodicamente gli allegati delle politiche, soprattutto dopo i cambiamenti organizzativi. Verifica che le configurazioni delle aree corrispondano alla copertura di sicurezza prevista, in particolare quando utilizzi `ALL_SUPPORTED` o gestisci più elenchi di aree.
## strategie di risoluzione dei problemi
Durante la risoluzione dei problemi relativi alle policy di Security Hub, concentrati innanzitutto sulla priorità e sull'ereditarietà delle policy. Ricorda che le configurazioni di disabilitazione hanno la precedenza sull'attivazione delle configurazioni quando le regioni compaiono in entrambi gli elenchi. Controlla le catene di ereditarietà delle politiche per capire come le politiche relative ai genitori e ai figli si combinano per creare la politica efficace per ogni account.
# Sintassi ed esempi delle policy di Security Hub
Le policy di Security Hub seguono una sintassi JSON standardizzata che definisce il modo in cui Security Hub è abilitato e configurato all'interno dell'organizzazione. La comprensione della struttura delle politiche consente di creare politiche efficaci per i requisiti di sicurezza.
## Considerazioni
Prima di creare le policy di Security Hub, comprendi questi punti chiave sulla sintassi delle policy:
+ Entrambi `enable_in_regions` gli `disable_in_regions` elenchi sono obbligatori nella policy, sebbene possano essere vuoti
+ Nell'elaborazione di politiche efficaci, ha la `disable_in_regions` precedenza su `enable_in_regions`
+ Le politiche secondarie possono modificare le politiche principali utilizzando operatori di ereditarietà, a meno che non siano esplicitamente limitate
+ La `ALL_SUPPORTED` designazione include regioni attuali e future
+ I nomi delle aree devono essere validi e disponibili in Security Hub
## Struttura politica di base
Una policy Security Hub utilizza questa struttura di base:
```
{
"securityhub": {
"enable_in_regions": {
"@@append": ["ALL_SUPPORTED"],
"@@operators_allowed_for_child_policies": ["@@all"]
},
"disable_in_regions": {
"@@append": [],
"@@operators_allowed_for_child_policies": ["@@all"]
}
}
}
```
## Componenti della policy
Le policy di Security Hub contengono questi componenti chiave:
`securityhub`
Il contenitore di primo livello per le impostazioni delle politiche
Obbligatorio per tutte le policy di Security Hub
`enable_in_regions`
Elenco delle regioni in cui deve essere abilitato Security Hub
Può contenere nomi di regioni specifici o `ALL_SUPPORTED`
Campo obbligatorio ma può essere vuoto
In caso di utilizzo`ALL_SUPPORTED`, include le regioni future
`disable_in_regions`
Elenco delle regioni in cui il Security Hub deve essere disabilitato
Può contenere nomi di regioni specifici o `ALL_SUPPORTED`
Campo obbligatorio ma può essere vuoto
Ha la precedenza su `enable_in_regions` quando le regioni appaiono in entrambi gli elenchi
Operatori di ereditarietà
@ @assign - Sovrascrive i valori ereditati
@ @append - Aggiunge nuovi valori a quelli esistenti
@ @remove - Rimuove valori specifici dalle impostazioni ereditate
## Esempi di policy di Security Hub
Gli esempi seguenti mostrano configurazioni comuni delle policy di Security Hub.
L'esempio seguente abilita Security Hub in tutte le regioni attuali e future. Inserendola `ALL_SUPPORTED` nell'`enable_in_regions`elenco e lasciandola `disable_in_regions` vuota, questa politica garantisce una copertura di sicurezza completa man mano che nuove regioni diventano disponibili.
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"ALL_SUPPORTED"
]
},
"disable_in_regions":{
"@@assign":[
]
}
}
}
```
Questo esempio disabilita Security Hub in tutte le regioni, comprese le aree future, poiché l'`disable_in_regions`elenco ha la precedenza su. `enable_in_regions`
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"us-east-1",
"us-west-2"
]
},
"disable_in_regions":{
"@@assign":[
"ALL_SUPPORTED"
]
}
}
}
```
L'esempio seguente dimostra come le politiche secondarie possono modificare le impostazioni delle politiche principali utilizzando operatori di ereditarietà. Questo approccio consente un controllo granulare mantenendo al contempo la struttura generale delle politiche. La politica per i bambini aggiunge una nuova regione `enable_in_regions` e ne rimuove una da`disable_in_regions`.
```
{
"securityhub":{
"enable_in_regions":{
"@@append":[
"eu-central-1"
]
},
"disable_in_regions":{
"@@remove":[
"us-west-2"
]
}
}
}
```
Questo esempio mostra come abilitare Security Hub in più aree specifiche senza utilizzarlo`ALL_SUPPORTED`. Ciò fornisce un controllo preciso su quali aree hanno il Security Hub abilitato, lasciando le aree non specificate non gestite dalla policy.
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"us-east-1",
"us-west-2",
"eu-west-1",
"ap-southeast-1"
]
},
"disable_in_regions":{
"@@assign":[
]
}
}
}
```
L'esempio seguente dimostra come gestire i requisiti di conformità regionali abilitando Security Hub nella maggior parte delle regioni e disabilitandolo esplicitamente in posizioni specifiche. L'`disable_in_regions`elenco ha la precedenza, garantendo che Security Hub rimanga disabilitato in quelle aree indipendentemente dalle altre impostazioni dei criteri.
```
{
"securityhub":{
"enable_in_regions":{
"@@assign":[
"ALL_SUPPORTED"
]
},
"disable_in_regions":{
"@@assign":[
"ap-east-1",
"me-south-1"
]
}
}
}
```
# Politiche di Amazon Bedrock
Le policy di Amazon Bedrock ti consentono di applicare automaticamente le protezioni configurate in Amazon Bedrock Guardrails su qualsiasi elemento della struttura organizzativa per tutte le chiamate di inferenza del modello ad Amazon Bedrock. Ciò elimina la necessità di configurare un guardail individuale per ogni account. Amazon Bedrock Guardrails offre protezioni configurabili per aiutare a creare in sicurezza applicazioni di intelligenza artificiale generativa su larga scala, con un approccio standard per un'ampia gamma di modelli di base, tra cui: modelli supportati in Amazon Bedrock, modelli ottimizzati e modelli ospitati all'esterno di Amazon Bedrock.
Le policy di Amazon Bedrock in AWS Organizations ti consentono di fare riferimento a un guardrail creato nel tuo account di gestione in formato JSON. Puoi allegare qualsiasi politica all'elemento richiesto della struttura dell'organizzazione, ad esempio la cartella principale, le unità organizzative (OUs) e i singoli account. AWS Organizations applica le regole di ereditarietà per combinare le policy, il che si traduce in una policy efficace per ogni account che determina il modo in cui vengono applicate le protezioni per la tua applicazione di intelligenza artificiale generativa.
## Come funziona
Le policy di Amazon Bedrock ti danno il controllo sull'applicazione automatica delle protezioni all'interno dei guardrail su più account, consentendoti di applicare i guardrail su tutti i modelli o su un sottoinsieme di modelli per le chiamate di inferenza ad Amazon Bedrock. Devi fare riferimento a una versione specifica del guardrail appropriato all'interno della tua policy, che rispetti i requisiti di intelligenza artificiale responsabile della tua organizzazione. Questo è specifico della AWS regione in cui si trova il guardrail ed è necessario disporre di parapetti diversi per ogni AWS regione in cui si desidera applicare i controlli di sicurezza. Puoi quindi collegare questa policy a qualsiasi nodo dell'organizzazione e gli account al di sotto di quel nodo erediteranno automaticamente tali protezioni e le applicheranno a ogni richiamo del modello ad Amazon Bedrock.
Le policy di Amazon Bedrock ti aiutano a garantire controlli di sicurezza coerenti in tutta l'organizzazione e forniscono un approccio centralizzato per creare in sicurezza applicazioni di intelligenza artificiale generativa su larga scala.
# Guida introduttiva alle politiche di Amazon Bedrock
Prima di configurare le policy di Amazon Bedrock, assicurati di aver compreso i prerequisiti e i requisiti di implementazione. Questo argomento ti guida attraverso il processo di configurazione e gestione di queste politiche nella tua organizzazione.
## Prima di iniziare
Verifica i seguenti requisiti prima di implementare le politiche di Amazon Bedrock:
+ Il tuo account deve far parte di un'organizzazione AWS
+ Devi aver effettuato l'accesso in uno dei seguenti modi:
+ L'account di gestione dell'organizzazione
+ Un account amministratore delegato con autorizzazioni per gestire le policy di Amazon Bedrock
+ Devi abilitare il tipo di policy Amazon Bedrock nella radice della tua organizzazione
## Passaggi dell’implementazione
Per implementare le policy di Amazon Bedrock in modo efficace, segui questi passaggi in sequenza. Ogni passaggio garantisce una configurazione corretta e aiuta a prevenire problemi comuni durante la configurazione. L'account di gestione o l'amministratore delegato può eseguire questi passaggi tramite la AWS Organizations console, l'interfaccia a riga di AWS comando (AWS CLI) o. AWS SDKs
1. [Abilita le politiche di Amazon Bedrock per la tua organizzazione](enable-policy-type.md).
1. [Crea una policy Amazon Bedrock](orgs_manage_policies_bedrock_syntax.md).
1. [Allega la policy di Amazon Bedrock alla directory principale, all'unità organizzativa o all'account della tua organizzazione](orgs_policies_attach.md).
1. [Visualizza la politica combinata efficace di Amazon Bedrock che si applica a un account](orgs_manage_policies_effective.md).
# Le migliori pratiche per l'utilizzo delle politiche di Amazon Bedrock
## Usa un identificatore guardrail valido
Un identificatore errato o non valido causerà l'esito negativo di tutte le chiamate API Amazon Bedrock nell'organizzazione di destinazione. [Monitora CloudTrail eventuali avvisi di policy non validi ed efficaci per rilevare rapidamente configurazioni errate](https://docs.aws.amazon.com/organizations/latest/userguide/invalid-policy-alerts.html).
## Escludi le politiche di ragionamento automatizzato
I guardrail che includono una politica di ragionamento automatico non sono supportati per l'applicazione a livello di organizzazione. Verifica che il tuo Amazon Bedrock Guardrail selezionato non ne contenga uno.
## Concedi le autorizzazioni IAM necessarie
Utilizza le [policy basate sulle risorse di Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-resource-based-policies.html) per concedere all'organizzazione e ai suoi account membri le autorizzazioni per valutare il guardrail applicato in fase di esecuzione.
## Consulta i limiti del servizio Amazon Bedrock per Guardrails
Le chiamate all'account membro che utilizzano la politica di Amazon Bedrock verranno conteggiate ai fini delle Service Quotas per il socio. Esamina la console Service Quotas e assicurati che i limiti di runtime di Guardrails siano sufficienti per il volume delle chiamate.
## Inizia in piccolo, poi scala
Per iniziare, allega la tua polizza ad alcuni account, assicurandoti che venga applicata nel modo previsto. Assicurati di verificare che le autorizzazioni Guardrail siano configurate per consentire l'accesso da più account.
## Convalida le modifiche alle tue politiche di Amazon Bedrock utilizzando DescribeEffectivePolicy
Dopo aver apportato una modifica a una politica di Amazon Bedrock, verifica le politiche in vigore per gli account rappresentativi al di sotto del livello in cui hai apportato la modifica. È possibile visualizzare la policy effettiva utilizzando la console di AWS gestione o utilizzando l'operazione `DescribeEffectivePolicy` API o una delle sue varianti AWS CLI o AWS SDK. Assicurati che l'impatto della modifica apportata sulla policy effettiva sia quello previsto.
## Comunica e allenati
Assicurati che le tue organizzazioni comprendano lo scopo e l'impatto delle tue politiche Amazon Bedrock. Fornisci indicazioni chiare sul comportamento di Amazon Bedrock Guardrails e su cosa aspettarti.
# Sintassi ed esempi delle policy di Amazon Bedrock
Una policy di Amazon Bedrock è un file di testo semplice strutturato secondo le regole di JSON. La sintassi per le policy di Amazon Bedrock segue la sintassi di tutti i tipi di policy di gestione. Per ulteriori informazioni, consulta [Sintassi ed ereditarietà delle policy per i tipi di policy di gestione](orgs_manage_policies_inheritance_mgmt.md). Questo argomento si concentra sull'applicazione di tale sintassi generale ai requisiti specifici del tipo di policy Amazon Bedrock.
Il seguente esempio di policy di Amazon Bedrock mostra la sintassi di base della policy Amazon Bedrock:
```
{
"bedrock": {
"guardrail_inference": {
"us-east-1": {
"config_1": {
"identifier": {
"@@assign": "arn:aws:bedrock:us-east-1:123456789012:guardrail/hu1dlsv9wy1d:1"
},
"selective_content_guarding": {
"system": {
"@@assign": "selective"
},
"messages": {
"@@assign": "comprehensive"
}
},
"model_enforcement": {
"included_models": {
"@@assign": ["ALL"]
},
"excluded_models": {
"@@assign": ["amazon.titan-embed-text-v2:0", "cohere.embed-english-v3"]
}
}
}
}
}
}
}
```
## La sintassi della policy di Amazon Bedrock include i seguenti elementi:
`"bedrock"`
La chiave di primo livello per i documenti relativi alle policy di Amazon Bedrock.
`"guardrail_inference"`
Definisce la configurazione di applicazione del guardrail.
``
La regione in cui verrà applicata la politica. Ad esempio, `"us-east-1"`.
`"config_1"`
Identificatore di configurazione per le impostazioni del guardrail.
`"identifier"` (Obbligatorio)
Guardrail ARN, seguito `:version` dalla versione Guardrail.
+ Il Guardrail deve essere di proprietà dell'account di gestione. Non è possibile creare una politica utilizzando un Guardrail di un altro account.
+ Il Guardrail deve avere una versione e quella versione non può essere DRAFT. Per creare una versione del tuo guardrail, consulta [Creare una versione di un guardrail nella guida](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-versions-create.html) per l'utente di Amazon Bedrock.
+ Il Guardrail deve disporre di una politica basata sulle risorse che consenta ai membri dell'organizzazione di effettuare chiamate. `ApplyGuardrail`
+ Il Guardrail deve essere creato e utilizzato nella regione specificata.
`"selective_content_guarding"` (facoltativo).
Amazon Bedrock APIs consente di contrassegnare contenuti specifici all'interno dell'input che il chiamante desidera che i guardrail elaborino. Queste impostazioni consentono agli esecutori di decidere se rispettare o meno le decisioni di tagging dei contenuti prese dal chiamante. Quando specificato, uno dei due è obbligatorio. `"system"` `"messages"`
`"system"` (facoltativo).
Scegli in che modo le istruzioni di sistema verranno elaborate dai guardrail. Il valore predefinito è quando non specificato. `comprehensive`
+ `"comprehensive"`: valuta tutti i contenuti indipendentemente dai tag guard content.
+ `"selective"`: Valuta solo i contenuti all'interno dei tag di contenuto di guard. Non valuta alcun contenuto quando non viene specificato alcun tag.
`"messages"` (facoltativo).
Scegli in che modo il contenuto dei messaggi con conversazione con utente e assistente verrà elaborato dai guardrails. Il valore predefinito è quando non specificato. `comprehensive`
+ `"comprehensive"`: valuta tutti i contenuti indipendentemente dai tag guard content.
+ `"selective"`: Valuta solo i contenuti all'interno dei tag di contenuto di guard. Valuta tutto il contenuto dei messaggi quando non viene specificato alcun tag.
`"model_enforcement"` (facoltativo).
Informazioni specifiche del modello per la configurazione forzata del guardrail. Se non è presente, la configurazione viene applicata a tutti i modelli.
`"included_models"` (Obbligatorio)
Elenco dei modelli su cui applicare il guardrail. Quando è vuoto, applica l'applicazione a tutti i modelli. Accetta anche la parola chiave «ALL» per includere esplicitamente tutti i modelli.
`"excluded_models"` (Obbligatorio)
Modelli da escludere dall'applicazione del guardrail. Se vuoto, non esclude alcun modello dall'applicazione. Se un modello è presente sia nell'elenco dei modelli inclusi che in quelli esclusi, viene escluso.
# Politiche di Amazon Inspector
Le politiche di Amazon Inspector ti consentono di abilitare e gestire Amazon Inspector in modo centralizzato su tutti gli account della tua organizzazione. AWS Con una policy di Amazon Inspector, puoi specificare per quali entità organizzative (root o account) Amazon Inspector è abilitato e collegato automaticamente all'account amministratore delegato di Amazon Inspector. OUs Puoi utilizzare le politiche di Amazon Inspector per semplificare l'onboarding a livello di servizio e garantire l'attivazione coerente di Amazon Inspector in tutti gli account esistenti e di nuova creazione.
## Caratteristiche e vantaggi principali
Le policy di Amazon Inspector ti consentono di definire quali tipi di scansione devono essere abilitati per la tua organizzazione o sottoinsiemi di essa, garantendo una copertura uniforme e riducendo il lavoro manuale. Una volta implementate, ti aiutano a registrare automaticamente nuovi account e a mantenere la linea di base di scansione man mano che l'organizzazione cresce.
## Come funziona
Quando alleghi una policy di Amazon Inspector a un'entità organizzativa, la policy abilita automaticamente Amazon Inspector per tutti gli account membri che rientrano in tale ambito. Inoltre, se hai completato la configurazione di Amazon Inspector registrando un amministratore delegato per Amazon Inspector, quell'account avrà una visibilità centralizzata delle vulnerabilità sugli account dell'organizzazione che hanno abilitato Amazon Inspector.
Le politiche di Amazon Inspector possono essere applicate all'intera organizzazione, a unità organizzative specifiche (OUs) o a singoli account. Gli account che entrano a far parte dell'organizzazione o si trasferiscono in un'unità organizzativa con una politica Amazon Inspector allegata ereditano automaticamente la politica e dispongono di Amazon Inspector abilitato e collegato all'amministratore delegato di Amazon Inspector. Le politiche di Amazon Inspector consentono di abilitare EC2 la scansione Amazon, la scansione Amazon ECR o la scansione Lambda Standard e del codice, oltre a Code Security. Le impostazioni di configurazione e le regole di soppressione specifiche possono essere gestite tramite l'account amministratore delegato dell'organizzazione.
Quando alleghi una policy di Amazon Inspector alla tua organizzazione o unità organizzativa, AWS Organizations valuta automaticamente la policy e la applica in base all'ambito definito. Il processo di applicazione delle politiche segue regole specifiche per la risoluzione dei conflitti:
+ Quando le regioni compaiono sia negli elenchi di attivazione che in quelli di disabilitazione, la configurazione di disabilitazione ha la precedenza. Ad esempio, se una regione è elencata sia nelle configurazioni di attivazione che di disabilitazione, Amazon Inspector sarà disabilitato in quella regione.
+ Quando `ALL_SUPPORTED` viene specificata l'abilitazione, Amazon Inspector è abilitato in tutte le regioni attuali e future, a meno che non sia esplicitamente disabilitato. Ciò consente di mantenere una copertura completa man mano che AWS si espande in nuove regioni.
+ Le politiche per i figli possono modificare le impostazioni delle politiche dei genitori utilizzando operatori di ereditarietà, consentendo un controllo granulare a diversi livelli organizzativi. Questo approccio gerarchico garantisce che unità organizzative specifiche possano personalizzare le proprie impostazioni di sicurezza mantenendo i controlli di base.
### Terminologia
Questo argomento utilizza i seguenti termini per discutere delle politiche di Amazon Inspector.
| Termine | Definizione |
| --- | --- |
| Policy operativa | La politica finale che si applica a un account dopo aver combinato tutte le politiche ereditate. |
| Ereditarietà delle policy | Processo mediante il quale gli account ereditano le politiche dalle unità organizzative principali. |
| Amministratore delegato | Un account designato per gestire le politiche di Amazon Inspector per conto dell'organizzazione. |
| Ruolo collegato al servizio | Un ruolo IAM che consente ad Amazon Inspector di interagire con altri AWS servizi. |
### Casi d'uso per le politiche di Amazon Inspector
Organizations che lanciano carichi di lavoro su larga scala su più account possono utilizzare questa policy per garantire che tutti gli account abilitino immediatamente i tipi di scansione corretti ed evitare lacune. Gli ambienti normativi o orientati alla conformità possono utilizzare policy secondarie per ignorare o limitare i tipi di scansione in base all'unità organizzativa. Gli ambienti in rapida crescita possono automatizzare l'abilitazione degli account appena creati in modo che siano sempre conformi alla linea di base.
### Ereditarietà e applicazione delle politiche
Comprendere come le politiche vengono ereditate e applicate è fondamentale per una gestione efficace della sicurezza in tutta l'organizzazione. Il modello di ereditarietà segue la gerarchia AWS Organizations, garantendo un'applicazione delle policy prevedibile e coerente.
+ Le politiche allegate a livello principale si applicano a tutti gli account
+ Gli account ereditano le politiche dalle unità organizzative principali
+ È possibile applicare più politiche a un singolo account
+ Le politiche più specifiche (più vicine all'account nella gerarchia) hanno la precedenza
### Convalida di policy
Durante la creazione delle politiche di Amazon Inspector, si verificano le seguenti convalide:
+ I nomi delle regioni devono essere identificatori di regione validi AWS
+ Le regioni devono essere supportate da Amazon Inspector
+ La struttura delle politiche deve seguire le regole di sintassi AWS delle policy di Organizations
+ Entrambi `enable_in_regions` gli `disable_in_regions` elenchi devono essere presenti, sebbene possano essere vuoti
### Considerazioni regionali e regioni supportate
Le politiche di Amazon Inspector si applicano solo nelle regioni in cui è disponibile l'accesso affidabile di Amazon Inspector AWS e Organizations. Comprendere il comportamento regionale ti aiuta a implementare controlli di sicurezza efficaci in tutta la presenza globale della tua organizzazione.
+ L'applicazione delle politiche avviene in ogni regione in modo indipendente
+ Puoi specificare quali regioni includere o escludere nelle tue politiche
+ Le nuove regioni vengono incluse automaticamente quando si utilizza l'`ALL_SUPPORTED`opzione
+ Le politiche si applicano solo alle regioni in cui è disponibile Amazon Inspector
### Comportamento di distacco
Se scolleghi una policy di Amazon Inspector, Amazon Inspector rimane abilitato negli account precedentemente coperti. Tuttavia, le future modifiche alla struttura organizzativa (ad esempio l'aggiunta di nuovi account o il trasferimento di account esistenti nell'unità organizzativa) non abiliteranno più automaticamente Amazon Inspector. Qualsiasi ulteriore abilitazione deve essere eseguita manualmente o ricollegando una policy.
## Dettagli aggiuntivi
### Amministratore delegato
È possibile registrare un solo amministratore delegato per Amazon Inspector in un'organizzazione. È necessario configurarlo nella console Amazon Inspector o tramite APIs prima di allegare le politiche di Amazon Inspector.
### Prerequisiti
Devi abilitare l'accesso affidabile per AWS Organizations, avere un amministratore delegato registrato per Amazon Inspector e avere ruoli collegati ai servizi disponibili in tutti gli account.
### Regioni supportate
Tutte le regioni in cui è disponibile Amazon Inspector.
# Guida introduttiva alle politiche di Amazon Inspector
Prima di configurare le politiche di Amazon Inspector, assicurati di aver compreso i prerequisiti e i requisiti di implementazione. Questo argomento ti guida attraverso il processo di configurazione e gestione di queste politiche nella tua organizzazione.
## Scopri le autorizzazioni richieste
Per abilitare o allegare le politiche di Amazon Inspector, devi disporre delle seguenti autorizzazioni nell'account di gestione:
+ `organizations:EnableAWSServiceAccess` per `inspector2.amazonaws.com`
+ `organizations:RegisterDelegatedAdministrator` per `inspector2.amazonaws.com`
+ `organizations:AttachPolicy`, `organizations:CreatePolicy`, `organizations:DescribeEffectivePolicy`
+ `inspector2:Enable`(per account di gestione e amministratore delegato)
## Prima di iniziare
Verifica i seguenti requisiti prima di implementare le politiche di Amazon Inspector:
+ Il tuo account deve far parte di un'organizzazione AWS
+ Devi aver effettuato l'accesso in uno dei seguenti modi:
+ L'account di gestione dell'organizzazione
+ Un amministratore delegato di AWS Organizations con autorizzazioni per gestire le politiche di Amazon Inspector
+ Devi abilitare l'accesso affidabile per Amazon Inspector nella tua organizzazione.
+ Devi abilitare il tipo di policy Amazon Inspector nella radice della tua organizzazione.
Inoltre, verifica che:
+ Amazon Inspector è supportato nelle regioni in cui desideri applicare le politiche.
+ Il ruolo `AWSServiceRoleForInspectorV2` collegato al servizio è configurato nel tuo account di gestione. Per verificare l'esistenza di questo ruolo, esegui. `aws iam get-role --role-name AWSServiceRoleForInspectorV2` Se devi creare questo ruolo, puoi eseguirlo `aws inspector2 enable` in qualsiasi regione dal tuo account di gestione o crearlo direttamente eseguendo`aws iam create-service-linked-role --aws-service-name inspector2.amazonaws.com`.
## Passaggi dell’implementazione
Per implementare efficacemente le politiche di Amazon Inspector, segui questi passaggi in sequenza. Ogni passaggio garantisce una configurazione corretta e aiuta a prevenire problemi comuni durante la configurazione. L'account di gestione o l'amministratore delegato può eseguire questi passaggi tramite la AWS Organizations console, l'interfaccia a riga di AWS comando (AWS CLI) o. AWS SDKs
1. [Abilita l'accesso affidabile per Amazon Inspector](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access).
1. [Abilita le politiche di Amazon Inspector per la tua organizzazione](enable-policy-type.md).
1. [Crea una policy Amazon Inspector](orgs_manage_policies_inspector_syntax.md).
1. [Allega la policy di Amazon Inspector alla directory principale, all'unità organizzativa o all'account della tua organizzazione](orgs_policies_attach.md).
1. [Visualizza la politica combinata efficace di Amazon Inspector che si applica a un account](orgs_manage_policies_effective.md).
## Crea una policy Amazon Inspector
### Autorizzazioni minime
Per creare una policy Amazon Inspector, è necessaria la seguente autorizzazione:
+ `organizations:CreatePolicy`
### AWS Console di gestione
**Per creare una policy di Amazon Inspector**
1. Accedi alla [console AWS Organizations](https://console.aws.amazon.com/organizations/v2). È necessario accedere come utente IAM, assumere un ruolo IAM o accedere come utente root ([non consigliato](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)) nell'account di gestione dell'organizzazione.
1. Imposta un amministratore delegato per il servizio in uso nella console Amazon Inspector.
1. Una volta che l'amministratore delegato è stato configurato per Amazon Inspector, AWS visita la console dell'organizzazione per configurare le politiche. Nella console AWS dell'organizzazione, visita la pagina delle politiche di Amazon Inspector e scegli **Crea** policy.
1. Nella pagina **Crea una nuova policy di Amazon Inspector**, inserisci un **nome per la policy** e una descrizione facoltativa **della policy**.
1. (Facoltativo) Per aggiungere uno o più tag alla policy, scegli **Add tag (Aggiungi tag)** e quindi inserisci una chiave e un valore facoltativo. Lasciando vuoto il valore, questo viene impostato su una stringa vuota; non è `null`. Puoi associare fino a 50 tag a una policy. Per ulteriori informazioni, consulta [Taggare le risorse AWS OrganizationsConsiderazioni](orgs_tagging.md).
1. Inserisci o incolla il testo della policy nella casella del codice JSON. Per informazioni sulla sintassi delle policy di Amazon Inspector e sulle policy di esempio che puoi utilizzare come punto di partenza, consulta. [Sintassi ed esempi delle policy di Amazon Inspector](orgs_manage_policies_inspector_syntax.md)
1. Al termine delle modifica della policy, seleziona **Create policy (Crea policy** nell'angolo in basso a destra della pagina.
# Le migliori pratiche per l'utilizzo delle politiche di Amazon Inspector
Quando si implementano le politiche di Amazon Inspector in tutta l'organizzazione, seguire le best practice consolidate aiuta a garantire un'implementazione e una manutenzione di successo.
## Iniziare semplicemente e apportare piccole modifiche
Inizia abilitando le policy di Amazon Inspector presso un'unità organizzativa limitata (ad esempio, «Security Pilot») per convalidare il comportamento previsto prima di distribuirlo a tutti gli account. Questo approccio incrementale consente di identificare e risolvere potenziali problemi in un ambiente controllato prima di una distribuzione più ampia.
## Stabilisci processi di revisione
Monitora regolarmente la presenza di nuovi account che si uniscono alla tua organizzazione e conferma che ereditino automaticamente l'abilitazione di Amazon Inspector. Rivedi trimestralmente gli ambiti degli allegati alle policy per assicurarti che la copertura di sicurezza rimanga in linea con la struttura organizzativa e i requisiti di sicurezza.
## Convalida le modifiche utilizzando DescribeEffectivePolicy
Dopo aver allegato o modificato una policy, richiedi un account rappresentativo `DescribeEffectivePolicy` per assicurarti che l'attivazione di Amazon Inspector si rifletta correttamente. Questa fase di convalida ti aiuta a confermare che le modifiche alle policy abbiano l'effetto desiderato in tutta l'organizzazione.
## Comunica e allenati
Informa i proprietari degli account che Amazon Inspector verrà abilitato automaticamente e che i risultati potrebbero essere visualizzati nei dashboard di Security Hub o Amazon Inspector una volta collegati all'amministratore delegato di Amazon Inspector. Una comunicazione chiara aiuta a garantire che i proprietari degli account comprendano il monitoraggio di sicurezza in atto e possano rispondere in modo appropriato ai risultati.
## Pianifica la tua strategia di amministratore delegato
Designare un account di sicurezza o conformità come amministratore delegato per Amazon Inspector. Imposta l'amministratore delegato dalla console Amazon Inspector o tramite AWS Organizations. APIs Questo approccio consente un monitoraggio e una gestione della sicurezza coerenti in tutta l'organizzazione.
## Gestisci le considerazioni regionali
Abilita Amazon Inspector nelle regioni in cui vengono eseguiti i tuoi carichi di lavoro. Considera i tuoi requisiti di conformità e le tue esigenze operative per determinare quali regioni richiedono la copertura di Amazon Inspector. Documenta i requisiti specifici della tua regione per mantenere un monitoraggio coerente della sicurezza in tutta l'infrastruttura.
# Sintassi ed esempi delle policy di Amazon Inspector
Le politiche di Amazon Inspector seguono una sintassi JSON standardizzata che definisce il modo in cui Amazon Inspector è abilitato e configurato all'interno dell'organizzazione. Una policy di Amazon Inspector è un documento JSON strutturato secondo la sintassi della policy di gestione di AWS Organizations. Definisce quali entità organizzative avranno Amazon Inspector abilitato automaticamente.
## Struttura delle politiche di base
Una policy di Amazon Inspector utilizza questa struttura di base:
```
{
"inspector": {
"enablement": {
"ec2_scanning": {
"enable_in_regions": {
"@@assign": ["us-east-1", "us-west-2"]
},
"disable_in_regions": {
"@@assign": ["eu-west-1"]
}
}
}
}
}
```
## Componenti della policy
Le politiche di Amazon Inspector contengono questi componenti chiave:
`inspector`
La chiave di primo livello per i documenti relativi alle policy di Amazon Inspector, necessaria per tutte le politiche di Amazon Inspector.
`enablement`
Definisce in che modo Amazon Inspector è abilitato all'interno dell'organizzazione e contiene le configurazioni dei tipi di scansione.
`Regions (Array of Strings)`
Speciifica le regioni in cui Amazon Inspector deve essere abilitato automaticamente.
## Esempi di policy di Amazon Inspector
Gli esempi seguenti illustrano le configurazioni comuni delle policy di Amazon Inspector.
### Esempio 1: abilitare Amazon Inspector a livello di organizzazione
L'esempio seguente abilita Amazon Inspector in `us-east-1` e `us-west-2` per tutti gli account nella radice dell'organizzazione.
Crea un file`inspector-policy-enable.json`:
```
{
"inspector": {
"enablement": {
"lambda_standard_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"lambda_code_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
}
},
"ec2_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
},
"ecr_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
},
"code_repository_scanning": {
"enable_in_regions": {
"@@assign": [
"us-east-1",
"us-west-2"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-1"
]
}
}
}
}
}
```
Se collegati alla directory principale, tutti gli account dell'organizzazione abilitano automaticamente Amazon Inspector e i risultati della scansione sono disponibili per l'amministratore delegato di Amazon Inspector.
Crea e allega la policy:
```
POLICY_ID=$(aws organizations create-policy \
--content file://inspector-policy-enable.json \
--name InspectorOrgPolicy \
--type INSPECTOR_POLICY \
--description "Inspector organization policy to enable all resources in IAD and PDX." \
--query 'Policy.PolicySummary.Id' \
--output text)
aws organizations attach-policy --policy-id $POLICY_ID --target-id
```
Ogni nuovo account che entra a far parte dell'organizzazione eredita automaticamente l'abilitazione.
Se scollegati, gli account esistenti rimangono abilitati, ma gli account futuri non vengono abilitati automaticamente:
```
aws organizations detach-policy --policy-id $POLICY_ID --target-id
```
### Esempio 2: abilitare Amazon Inspector per un'unità organizzativa specifica
Crea un file`inspector-policy-eu-west-1.json`:
```
{
"inspector": {
"enablement": {
"lambda_standard_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
},
"lambda_code_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
}
},
"ec2_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
},
"ecr_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
},
"code_repository_scanning": {
"enable_in_regions": {
"@@assign": [
"eu-west-1"
]
},
"disable_in_regions": {
"@@assign": [
"eu-west-2"
]
}
}
}
}
}
```
Collegalo a un'unità organizzativa per assicurarti che tutti gli account di produzione abbiano Amazon Inspector abilitato e collegato all'amministratore delegato di Amazon Inspector: `eu-west-1`
```
aws organizations update-policy --policy-id $POLICY_ID --content file://inspector-policy-eu-west-1.json --description "Inspector organization policy - Enable all (eu-west-1)"
aws organizations attach-policy --policy-id $POLICY_ID --target-id ou-aaaa-12345678
```
Gli account esterni all'unità organizzativa non sono interessati.
# Aggiorna le politiche di implementazione
AWS Organizations Le politiche di implementazione degli aggiornamenti consentono di gestire centralmente e scaglionare gli aggiornamenti automatici su più AWS risorse e account dell'organizzazione. Con queste politiche, è possibile definire l'ordine in cui le risorse ricevono gli aggiornamenti, garantendo che le modifiche vengano convalidate in ambienti meno critici prima di entrare in produzione.
Nei complessi ambienti cloud odierni, la gestione degli aggiornamenti su numerose risorse e account può essere difficile. Le politiche di implementazione degli aggiornamenti risolvono questa sfida fornendo un approccio sistematico all'implementazione degli aggiornamenti. Utilizzando queste politiche, è possibile allineare il processo di aggiornamento alle pratiche di gestione delle modifiche dell'organizzazione, ridurre i rischi e migliorare l'efficienza operativa.
Le politiche di implementazione degli aggiornamenti sfruttano la struttura gerarchica di AWS Organizations per applicare le politiche all'intera organizzazione o a unità organizzative specifiche (). OUs Questa integrazione consente di gestire gli aggiornamenti su larga scala, eliminando la necessità di coordinamento manuale o script di automazione personalizzati.
## Caratteristiche e vantaggi principali
Le politiche di implementazione degli aggiornamenti forniscono funzionalità complete per la gestione degli aggiornamenti, offrendo al contempo vantaggi significativi alle organizzazioni che gestiscono le risorse su più account e ambienti. La tabella seguente illustra le caratteristiche principali e i vantaggi associati:
**Caratteristiche e vantaggi delle politiche di implementazione degli aggiornamenti**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/organizations/latest/userguide/orgs_manage_policies_upgrade_rollout.html)
Per ulteriori informazioni sull'ereditarietà delle politiche, vedere. [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md)
## Cosa sono le politiche di implementazione degli aggiornamenti?
Le politiche di implementazione degli aggiornamenti sono un insieme di regole che determinano come e quando gli aggiornamenti automatici vengono applicati alle risorse. AWS Queste politiche consentono di definire diversi ordini di aggiornamento per le risorse, in genere in linea con gli ambienti di sviluppo, test e produzione. In questo modo, potete assicurarvi che gli aggiornamenti vengano applicati innanzitutto ai sistemi meno critici, in modo da identificare e risolvere eventuali problemi prima che influiscano sui carichi di lavoro di produzione.
Le policy supportano tre ordini di aggiornamento: First, Second e Last. Questi ordini creano un approccio graduale agli aggiornamenti, in cui le risorse designate come «Prime» ricevono gli aggiornamenti inizialmente, seguite da «Second» dopo un periodo di attesa e infine «Ultime» dopo un altro periodo di attesa. Questo approccio scaglionato consente di convalidare gli aggiornamenti in ogni fase prima che passino a sistemi più critici.
Le politiche di implementazione degli aggiornamenti sono particolarmente utili per le organizzazioni con strutture complesse e multi-account o per quelle con requisiti rigorosi di gestione delle modifiche. Forniscono un equilibrio tra la manutenzione up-to-date dei sistemi e la riduzione al minimo del rischio di interruzioni dei servizi critici legate all'aggiornamento.
## Come funzionano le politiche di implementazione degli aggiornamenti
Le politiche di implementazione dell'upgrade si integrano perfettamente con l' AWS infrastruttura e i processi esistenti. Quando si crea e si allega una politica di implementazione dell'aggiornamento a un'unità organizzativa, questa si applica a tutti gli account all'interno di tale unità organizzativa. È quindi possibile utilizzare i tag delle risorse o gli ordini di patch per specificare quali risorse devono essere aggiornate in quale ordine.
Quando un AWS servizio supportato rilascia un aggiornamento, consulta le politiche di implementazione dell'aggiornamento per determinare l'ordine in cui le risorse devono ricevere l'aggiornamento. Il servizio applica innanzitutto l'aggiornamento alle risorse contrassegnate come «Prime» durante le finestre di manutenzione configurate. Dopo un periodo di attesa specifico per il servizio, in genere circa una settimana, le risorse contrassegnate come «Seconde» diventano idonee per l'aggiornamento. Infine, dopo un altro periodo di attesa, le risorse contrassegnate come «Ultime» ricevono l'aggiornamento.
Questo processo garantisce che gli aggiornamenti vengano applicati in modo controllato e prevedibile in tutta l'organizzazione. Consente di monitorare l'impatto degli aggiornamenti in ogni fase e di adottare azioni correttive, se necessario, prima che le modifiche raggiungano gli ambienti più critici. La natura automatizzata di questo processo riduce il sovraccarico operativo legato alla gestione degli aggiornamenti, garantendo al contempo il controllo e la visibilità necessari per mantenere la stabilità e la sicurezza delle risorse. AWS
## Terminologia
Ecco i termini chiave da comprendere quando si lavora con le politiche di implementazione degli aggiornamenti:
**Termini della politica di implementazione degli aggiornamenti**
| Termine | Definizione |
| --- | --- |
| Data attiva | La data in cui l'AMVu diventa visibile nell'API Descrivi Pending Maintenance Actions e disponibile per l'applicazione. |
| AmVu (aggiornamento automatico della versione secondaria) | Il processo di aggiornamento automatico per le versioni secondarie dei motori di database. |
| Policy operativa | L'ultimo set di regole che si applicano a un account o a una risorsa dopo aver considerato tutte le politiche ereditate e direttamente collegate. |
| Finestra di manutenzione | Periodo di tempo ricorrente durante il quale è possibile applicare aggiornamenti automatici a una risorsa. Le politiche di implementazione degli aggiornamenti funzionano all'interno di queste finestre di manutenzione configurate. |
| Unità organizzativa (UO) | Un contenitore per AWS gli account della tua organizzazione. Le politiche di implementazione degli upgrade possono essere allegate a livello di unità organizzativa per influire su tutti gli account al suo interno. |
| Ordine delle patch | La sequenza in cui le risorse ricevono gli aggiornamenti (Prima, Seconda, Ultima). |
| Obiettivo politico | L'ambito a cui si applica una politica di implementazione dell'aggiornamento, che può riguardare un'intera organizzazione, account specifici OUs o singoli account. |
| Tag delle risorse | Coppie chiave-valore che possono essere utilizzate per identificare quali risorse devono seguire ordini di aggiornamento specifici all'interno di una politica. |
| Finestra di pianificazione | L'intervallo di tempo durante il quale le risorse di uno specifico ordine di patch ricevono gli aggiornamenti. |
| Periodo di attesa specifico per il servizio | L'intervallo di tempo designato tra l'aggiornamento delle risorse di diversi ordini di aggiornamento. Questo periodo varia in base al AWS servizio e al tipo di aggiornamento. |
| Ordine di upgrade | Una designazione che determina quando una risorsa riceve aggiornamenti rispetto ad altre risorse. Può essere impostato su Primo, Secondo o Ultimo. |
| Politica di implementazione dell'aggiornamento | Il tipo di AWS Organizations policy utilizzato per gestire le pianificazioni di aggiornamento tra le risorse. |
## Casi d'uso per le politiche di implementazione degli aggiornamenti
Organizzazioni di diverse dimensioni e settori possono trarre vantaggio dalle politiche di implementazione degli aggiornamenti. I seguenti scenari fittizi illustrano le sfide comuni di gestione degli aggiornamenti e il modo in cui le politiche di implementazione degli aggiornamenti forniscono soluzioni efficienti. Questi esempi si basano sulle esperienze tipiche dei clienti, ma sono stati semplificati per evidenziare i vantaggi chiave e i modelli di implementazione.
Molte organizzazioni affrontano sfide simili: devono mantenere le proprie risorse up-to-date aggiornate alle versioni più recenti riducendo al minimo i rischi per gli ambienti di produzione. Senza un approccio centralizzato basato su policy, i team ricorrono spesso a processi manuali o a script di automazione complessi. Gli esempi seguenti dimostrano come due organizzazioni diverse potrebbero risolvere sfide simili utilizzando politiche di implementazione degli aggiornamenti:
### Caso d'uso di esempio: Global Financial Services Company
Una società di servizi finanziari gestisce centinaia di database Aurora PostgreSQL su più account. AWS Prima dell'implementazione delle politiche di upgrade, il loro DevOps team dedicava diversi giorni al mese a coordinare manualmente gli aggiornamenti del database, assicurandosi che le modifiche fossero testate negli ambienti di sviluppo prima di arrivare ai sistemi di produzione. Implementando le politiche di implementazione degli aggiornamenti, hanno:
+ Database di sviluppo contrassegnati con ordine di aggiornamento «First»
+ Database QA assegnati per l'ordine di aggiornamento «Second»
+ Database di produzione designati come ordine di aggiornamento «Ultimo»
+ Coordinamento degli aggiornamenti ridotto da giorni a minuti
+ Prima le modifiche convalidate automaticamente negli ambienti inferiori
+ Mantenimento della conformità ai requisiti di gestione delle modifiche
### Caso d'uso di esempio: IoT Device Platform Provider
Un'azienda IoT elabora milioni di eventi relativi ai dispositivi ogni giorno utilizzando più database Amazon RDS. Dovevano assicurarsi che gli aggiornamenti automatici delle versioni secondarie non interrompessero i loro servizi di produzione. Utilizzando le politiche di implementazione degli aggiornamenti, hanno:
+ Hanno creato una politica che si applica a tutta la loro struttura organizzativa
+ Gli ambienti Canary sono stati configurati per ricevere prima gli aggiornamenti
+ Configura il monitoraggio negli ambienti con upgrade anticipato
+ Tempo guadagnato per rilevare e risolvere eventuali problemi prima degli aggiornamenti di produzione
+ Ha sostituito la complessa automazione degli aggiornamenti personalizzati con una politica semplice
+ Ha mantenuto un'elevata disponibilità per i carichi di lavoro di produzione, pur rimanendo aggiornati con le versioni del database
## Servizi supportati AWS
Le politiche di implementazione degli aggiornamenti si integrano con i seguenti AWS servizi supportando al contempo gli aggiornamenti automatici delle versioni secondarie:
**Servizi supportati per le politiche di implementazione degli aggiornamenti**
| Nome del servizio | Scopo |
| --- | --- |
| Amazon Aurora PostgreSQL-Compatible Edition | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) |
| Amazon Aurora edizione compatibile con MySQL | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) |
| Amazon Relational Database Service per PostgreSQL | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html) |
| Amazon Relational Database Service per SQL Server | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html) |
| Amazon Relational Database Service per Oracle | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html#oracle-minor-version-upgrade-tuning-on) |
| Amazon Relational Database Service per MariaDB | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html) |
| Amazon Relational Database Service per MySQL | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html) |
| Amazon Relational Database Service per Db2 | [Aggiornamenti automatici delle versioni secondarie](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html) |
## Prerequisiti
Di seguito sono riportati i prerequisiti e le autorizzazioni necessarie per la gestione delle politiche di implementazione degli aggiornamenti in: AWS Organizations
+ AWS Organizations account di gestione o accesso come amministratore delegato
+ Risorse nei servizi supportati (attualmente motori di database Amazon Aurora e Amazon Relational Database Service)
+ Autorizzazioni IAM adeguate per gestire le politiche di implementazione degli upgrade
## Fasi successive
Per iniziare a utilizzare le politiche di implementazione dell'aggiornamento:
1. Consulta la [Guida introduttiva alle politiche di implementazione degli upgrade](orgs_manage_policies_upgrade_getting_started.md) pagina per scoprire come creare e gestire le politiche
1. Scopri come implementare [Procedure consigliate per l'utilizzo delle politiche di implementazione degli aggiornamenti](orgs_manage_policies_upgrade_best_practices.md) le politiche di implementazione degli aggiornamenti
1. Comprendi [Sintassi ed esempi della politica di implementazione dell'aggiornamento](orgs_manage_policies_upgrade_syntax.md)
# Guida introduttiva alle politiche di implementazione degli upgrade
Segui questi passaggi per implementare le politiche di implementazione degli aggiornamenti nella tua organizzazione. Ogni passaggio contiene collegamenti a informazioni dettagliate per aiutarti a completare l'implementazione con successo.
## Prima di iniziare
Assicurati di disporre di quanto segue:
+ Accesso amministrativo a AWS Organizations
+ Risorse nei AWS servizi supportati (come Aurora o Amazon Relational Database Service)
+ Autorizzazioni IAM necessarie configurate
## Passaggi dell’implementazione
1. [Abilita le politiche di implementazione degli aggiornamenti per la tua organizzazione.](enable-policy-type.md)
1. [Scopri come funzionano le politiche di implementazione degli upgrade.](orgs_manage_policies_upgrade_rollout.md#orgs_manage_policies_upgrade_rollout_how_work)
+ Identifica gli ambienti di sviluppo, test e produzione
+ Determina quali risorse devono essere aggiornate per prime, seconde e ultime
+ Documenta la tua strategia di etichettatura per l'identificazione delle risorse
1. [Crea una politica di implementazione degli aggiornamenti](orgs_policies_create.md#create-upgrade-rollout-policy-procedure):
+ Definisci l'ordine di implementazione predefinito (unità organizzativa o livello di account)
+ Specificate il targeting delle risorse utilizzando i tag
+ Configura eventuali esclusioni di policy
1. [Allega una politica di implementazione dell'aggiornamento a un account con un solo membro che puoi utilizzare per i test.](orgs_policies_attach.md) :
+ Inizia con un'unità organizzativa di test
+ Verifica l'ereditarietà delle politiche
+ Conferma lo stato dell'allegato alla politica
1. Contrassegna le tue risorse in base alla tua strategia per gli ordini di upgrade:
+ Applica i tag alle risorse di sviluppo per i primi aggiornamenti
+ Contrassegna le risorse di test per gli aggiornamenti di secondo ordine
+ Designate le risorse di produzione per gli aggiornamenti di ultimo ordine
1. Monitora e convalida la politica:
+ Rivedi le assegnazioni degli ordini di upgrade
+ Verifica gli effetti delle politiche sulle risorse di test
1. Verifica il processo di aggiornamento:
+ Attendi che sia disponibile un aggiornamento del servizio
+ Monitora la progressione dell'aggiornamento nei tuoi ambienti
+ Verifica che gli aggiornamenti seguano l'ordine specificato
1. Abilita le politiche di implementazione degli aggiornamenti per unità organizzative aggiuntive, se necessario
**Altre informazioni**
+ [Scopri la sintassi delle politiche di implementazione dell'upgrade e guarda le politiche di esempio](orgs_manage_policies_upgrade_syntax.md)
# Procedure consigliate per l'utilizzo delle politiche di implementazione degli aggiornamenti
AWS consiglia le seguenti best practice per l'utilizzo delle politiche di implementazione degli aggiornamenti.
**Topics**
+ [Inizia in piccolo e scala gradualmente](#orgs_manage_policies_upgrade_best_practices_scale)
+ [Stabilisci processi di revisione](#orgs_manage_policies_upgrade_best_practices_review)
+ [Convalida le modifiche alle politiche in modo efficace](#orgs_manage_policies_upgrade_best_practices_validate)
+ [Monitora e comunica le modifiche](#orgs_manage_policies_upgrade_best_practices_monitor)
+ [Mantieni la conformità e la sicurezza](#orgs_manage_policies_upgrade_best_practices_compliance)
+ [Ottimizza l'efficienza operativa](#orgs_manage_policies_upgrade_best_practices_optimize)
## Inizia in piccolo e scala gradualmente
Inizia l'implementazione con una policy di test associata a un singolo account in un ambiente non critico. Questo approccio consente di convalidare il comportamento e l'impatto delle politiche di implementazione degli upgrade senza rischiare di interrompere i carichi di lavoro critici. Una volta confermato che la policy funziona come previsto, spostala gradualmente verso l'alto nella struttura organizzativa per includere più account e unità organizzative.
Questa scalabilità graduale consente di identificare e risolvere eventuali problemi nelle prime fasi del processo di implementazione. Prendi in considerazione la creazione di un gruppo pilota di risorse che rappresenti la diversità del tuo ambiente ma comporti un rischio operativo minimo. Documenta i risultati di ogni fase di espansione per informare le future implementazioni e aggiustamenti delle politiche.
## Stabilisci processi di revisione
Implementa processi di revisione regolari per monitorare gli attributi delle politiche di implementazione di nuovi upgrade e valutare le eccezioni delle politiche. Queste revisioni devono essere in linea con i requisiti operativi e di sicurezza dell'organizzazione. Create una pianificazione per la revisione dell'efficacia delle politiche e conservate la documentazione di eventuali modifiche apportate.
Il processo di revisione dovrebbe includere valutazioni periodiche delle risorse regolate dalle politiche, la verifica che gli ordini di upgrade siano in linea con la strategia prevista e la valutazione di eventuali eccezioni alle politiche. Valuta la possibilità di stabilire criteri per stabilire quando le politiche devono essere aggiornate e di conservare un registro delle modifiche per tenere traccia dell'evoluzione delle politiche nel tempo.
## Convalida le modifiche alle politiche in modo efficace
Dopo aver apportato modifiche a una politica di implementazione degli upgrade, verifica le politiche efficaci per gli account rappresentativi a ogni livello della tua organizzazione. Utilizza la console di AWS gestione o il funzionamento dell'`DescribeEffectivePolicy`API per verificare che le modifiche abbiano l'impatto previsto. Questa convalida dovrebbe includere il controllo delle risorse tra le diverse unità organizzative e la conferma che l'ereditarietà funzioni come previsto.
Presta particolare attenzione alle risorse a cui sono assegnati ordini di aggiornamento espliciti rispetto a quelle che utilizzano valori predefiniti. Stabilisci una checklist di convalida che includa la verifica del targeting basato su tag, la conferma degli allineamenti delle finestre di manutenzione e il test dell'ereditarietà delle politiche.
## Monitora e comunica le modifiche
Stabilisci un monitoraggio completo delle politiche di implementazione degli aggiornamenti e crea canali di comunicazione chiari per condividere le informazioni relative all'aggiornamento. Documenta procedure chiare per la gestione degli errori di aggiornamento e crea piani di risposta per diversi scenari.
Mantieni una comunicazione regolare con i team che gestiscono le risorse interessate dalle politiche di aggiornamento. Prendi in considerazione la creazione di dashboard che offrano visibilità sugli aggiornamenti imminenti e sulla loro progressione prevista nei tuoi ambienti.
## Mantieni la conformità e la sicurezza
Controllate regolarmente le vostre politiche di implementazione degli upgrade per assicurarvi che siano in linea con i requisiti di conformità. Documenta tutte le decisioni relative alle politiche e mantieni registrazioni chiare dei modelli di aggiornamento e delle eccezioni. Implementa i controlli di sicurezza relativi alle modifiche delle politiche e mantieni una traccia di controllo delle modifiche alle politiche utilizzando. AWS CloudTrail
Rivedi regolarmente le autorizzazioni di accesso alle funzioni di gestione delle politiche e implementa l'accesso con privilegi minimi per l'amministrazione delle politiche. Crea procedure per le modifiche alle politiche di emergenza e conserva la documentazione dei requisiti di aggiornamento relativi alla sicurezza.
## Ottimizza l'efficienza operativa
Progetta le tue politiche per ridurre al minimo il sovraccarico operativo mantenendo i controlli necessari. Per evitare comportamenti indesiderati, non riutilizzate i tag in diversi casi d'uso. Automatizza il controllo della conformità delle politiche ove possibile e crea procedure operative standard per le attività comuni di gestione delle politiche.
Valuta la possibilità di creare modelli per diversi tipi di scenari di aggiornamento e di conservare la documentazione dei modelli di policy di successo. La revisione regolare delle metriche operative può aiutare a identificare le opportunità per l'ottimizzazione delle politiche e il miglioramento dei processi.
# Sintassi ed esempi della politica di implementazione dell'aggiornamento
Una politica di implementazione degli aggiornamenti definisce il modo in cui AWS i servizi applicano gli aggiornamenti automatici a tutte le risorse. La comprensione della sintassi delle politiche consente di creare politiche efficaci che soddisfino i requisiti di aggiornamento dell'organizzazione.
**Topics**
+ [Considerazioni](#orgs_manage_policies_upgrade_syntax_considerations)
+ [Struttura politica di base](#orgs_manage_policies_upgrade_syntax_structure)
+ [Componenti della policy](#orgs_manage_policies_upgrade_syntax_components)
+ [Esempi di politiche di implementazione degli aggiornamenti](#orgs_manage_policies_upgrade_syntax_examples)
## Considerazioni
Quando implementate le politiche di implementazione degli aggiornamenti, tenete conto di questi fattori importanti:
+ I nomi delle politiche devono essere univoci all'interno dell'organizzazione e devono essere chiari e descrittivi. Scegliete nomi che riflettano lo scopo e l'ambito della politica. Per ulteriori informazioni, consulta [Ottimizza l'efficienza operativa](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_optimize).
+ I test sono fondamentali prima di un'implementazione su larga scala. Convalida innanzitutto le nuove politiche negli ambienti non di produzione ed espandile gradualmente per garantire il comportamento desiderato. Per ulteriori informazioni, consulta [Inizia in piccolo e scala gradualmente](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_scale).
+ La propagazione delle modifiche alle policy all'interno dell'organizzazione può richiedere diverse ore. Pianificate le vostre implementazioni di conseguenza e assicuratevi che sia in atto un monitoraggio adeguato. Per ulteriori informazioni, consulta [Monitora e comunica le modifiche](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_monitor).
+ La formattazione JSON deve essere valida e rientrare nella dimensione massima della policy di 5.120 byte. Mantieni le strutture delle politiche il più semplici possibile, soddisfacendo al contempo i tuoi requisiti.
+ Le revisioni periodiche delle politiche aiutano a mantenere l'efficacia. Pianifica valutazioni periodiche delle tue politiche per assicurarti che continuino a soddisfare le tue esigenze organizzative. Per ulteriori informazioni, consulta [Stabilisci processi di revisione](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review).
+ Per le risorse senza un ordine di aggiornamento assegnato viene impostato automaticamente l'ordine «Secondo». Valuta la possibilità di impostare in modo esplicito gli ordini di aggiornamento per le risorse critiche anziché affidarti alle impostazioni predefinite. Per ulteriori informazioni, consulta [Convalida le modifiche alle politiche in modo efficace](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_validate).
+ Gli aggiornamenti manuali hanno la precedenza sugli ordini di aggiornamento definiti dalle politiche. Assicurati che i processi di gestione delle modifiche tengano conto degli scenari di aggiornamento sia automatici che manuali. Per ulteriori informazioni, consulta [Stabilisci processi di revisione](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review).
**Nota**
Quando implementate politiche di implementazione degli upgrade basate su tag dal vostro account di gestione, tenete presente che l'account di gestione non può visualizzare o accedere direttamente ai tag a livello di risorsa negli account dei membri. Ti consigliamo di stabilire un processo in cui gli account dei membri applichino tag di risorsa coerenti e quindi di creare politiche a livello di organizzazione che facciano riferimento a questi tag. Ciò garantisce il corretto coordinamento tra l'etichettatura a livello di risorsa e l'applicazione delle politiche organizzative. Puoi anche utilizzarlo [Policy di tag](orgs_manage_policies_tag-policies.md) per mantenere i tag coerenti quando le risorse vengono etichettate in tutta l'organizzazione.
## Struttura politica di base
Le politiche di implementazione dell'aggiornamento utilizzano una struttura JSON che include i seguenti elementi principali:
+ Metadati delle politiche (come le informazioni sulla versione)
+ Regole di targeting delle risorse
+ Aggiorna le specifiche dell'ordine
+ Messaggi di eccezione opzionali
+ Attributi specifici del servizio
L'esempio seguente mostra una struttura di policy di implementazione degli aggiornamenti di base:
```
{
"upgrade_rollout":{
"default":{
"patch_order":{
"@@assign":"last"
}
},
"tags":{
"devtag":{
"tag_values":{
"tag1":{
"patch_order":{
"@@assign":"first"
}
},
"tag2":{
"patch_order":{
"@@assign":"second"
}
},
"tag3":{
"patch_order":{
"@@assign":"last"
}
}
}
}
}
}
}
```
## Componenti della policy
Una politica di implementazione degli aggiornamenti è costituita da due componenti chiave che interagiscono per controllare il modo in cui gli aggiornamenti vengono applicati alle risorse. Questi componenti includono opzioni di configurazione sia per i comportamenti predefiniti che per le sostituzioni basate su tag. Comprendere come interagiscono questi componenti consente di creare politiche efficaci che soddisfino le esigenze organizzative.
### Configurazione predefinita dell'ordine delle patch
Quando si crea una politica di implementazione degli aggiornamenti senza specificare alcuna modifica specifica per ogni risorsa, per impostazione predefinita tutte le risorse seguono un ordine di aggiornamento di base. È possibile impostare questa impostazione predefinita utilizzando il campo «predefinito» nella politica. Le risorse senza l'assegnazione esplicita dell'ordine di aggiornamento tramite tag seguiranno questo ordine predefinito.
**Nota**
L'esperienza odierna della console richiede la specificazione di un ordine predefinito.
L'esempio seguente mostra come impostare tutte le risorse in modo che ricevano gli aggiornamenti per ultimi per impostazione predefinita, a meno che non vengano sovrascritte dai tag. Questo approccio è utile quando si desidera garantire che la maggior parte delle risorse venga aggiornata più avanti nel ciclo di aggiornamento:
```
"upgrade_rollout": {
"default": {
"patch_order": "last"
}
}
```
### Sovrascrittura del livello di risorsa tramite tag
È possibile sovrascrivere l'ordine di aggiornamento predefinito per risorse specifiche utilizzando i tag. Ciò consente di creare un controllo granulare su quali risorse ricevono gli aggiornamenti in quale ordine. Ad esempio, è possibile assegnare diversi ordini di aggiornamento in base ai tipi di ambiente, alle fasi di sviluppo o alla criticità del carico di lavoro.
L'esempio seguente mostra come configurare le risorse di sviluppo in modo che ricevano gli aggiornamenti per prime e le risorse di produzione per riceverli per ultime. Questa configurazione garantisce che gli ambienti di sviluppo possano convalidare gli aggiornamenti prima che raggiungano la produzione:
```
"upgrade_rollout": {
"tags": {
"environment": {
"tag_values": {
"development": {
"patch_order": "first"
},
"production": {
"patch_order": "last"
}
}
}
}
}
```
## Esempi di politiche di implementazione degli aggiornamenti
Di seguito sono riportati gli scenari più comuni relativi alle politiche di implementazione degli aggiornamenti:
### Esempio 1: innanzitutto l'ambiente di sviluppo
Questo esempio mostra come configurare le risorse nell'ambiente di sviluppo in modo che ricevano prima gli aggiornamenti. Indirizzando le risorse con il tag «development» environment, ti assicuri che i tuoi ambienti di sviluppo siano i primi a ricevere e convalidare nuovi aggiornamenti. Questo modello aiuta a identificare potenziali problemi prima che gli aggiornamenti raggiungano ambienti più critici:
```
{
"tags": {
"environment": {
"tag_values": {
"development": {
"upgrade_order": "first"
}
}
}
}
}
```
### Esempio 2: ultimo ambiente di produzione
Questo esempio dimostra come garantire che gli ambienti di produzione ricevano gli aggiornamenti per ultimi. Impostando in modo esplicito le risorse con tag di produzione sull'ultimo ordine di aggiornamento, è possibile mantenere la stabilità dell'ambiente di produzione e consentire al contempo test adeguati negli ambienti di preproduzione. Questo approccio è particolarmente utile per le organizzazioni con requisiti rigorosi di gestione delle modifiche:
```
{
"tags": {
"environment": {
"tag_values": {
"production": {
"upgrade_order": "last"
}
}
}
}
}
```
### Esempio 3: ordini di upgrade multipli che utilizzano tag
L'esempio seguente mostra come utilizzare una singola chiave di tag con valori diversi per specificare tutti e tre gli ordini di aggiornamento. Questo approccio è utile quando si desidera gestire gli ordini di upgrade tramite un unico schema di tagging:
```
{
"upgrade_rollout":{
"default":{
"patch_order":{
"@@assign":"last"
}
},
"tags":{
"devtag":{
"tag_values":{
"tag1":{
"patch_order":{
"@@assign":"first"
}
},
"tag2":{
"patch_order":{
"@@assign":"second"
}
},
"tag3":{
"patch_order":{
"@@assign":"last"
}
}
}
}
}
}
}
```
# Politiche di Amazon S3
Le policy di Amazon S3 consentono di gestire centralmente le configurazioni per le risorse Amazon S3 su larga scala tra gli account di un'organizzazione. Le politiche di Amazon S3 attualmente supportano le impostazioni per il blocco dell'accesso pubblico.
Puoi utilizzare una policy di Amazon S3 per specificare se abilitare o disabilitare tutte e quattro le impostazioni Block Public Access e tale specifica si applicherà a tutte le risorse Amazon S3 all'interno di account selezionati. Puoi utilizzare le impostazioni Block Public Access in una policy di Amazon S3 per applicare un livello di sicurezza coerente in tutta l'organizzazione ed eliminare il sovraccarico operativo legato alla gestione delle configurazioni dei singoli account.
## Come funziona
Quando si allega una policy di Amazon S3 a un'entità organizzativa, vengono definite le impostazioni che si applicano a tutte le risorse Amazon S3 all'interno degli account in tale ambito. Queste configurazioni sostituiscono le impostazioni a livello di account, consentendoti di gestire centralmente le impostazioni di Amazon S3.
Le policy di Amazon S3 possono essere applicate a un'intera organizzazione, a unità organizzative (OUs) o a singoli account. Gli account che entrano a far parte di un'organizzazione erediteranno automaticamente tutte le policy di Amazon S3 in base alla loro posizione nella gerarchia organizzativa.
Comportamento di distacco: se una policy di Amazon S3 viene scollegata, gli account tornano automaticamente alla precedente configurazione a livello di account. Amazon S3 conserva le impostazioni originali a livello di account per consentire un ripristino senza interruzioni.
## Funzionalità principali
+ Controllo unificato: tutte e quattro le impostazioni di accesso pubblico a blocchi (BlockPublicAcls,, BlockPublicPolicy IgnorePublicAcls, RestrictPublicBuckets) sono controllate insieme come un'unica configurazione
+ Ereditarietà automatica: i nuovi account ereditano automaticamente le politiche in base alla loro collocazione organizzativa
+ Ignora la protezione: impedisce le modifiche a livello di account quando le politiche dell'organizzazione sono attive
+ Ripristino senza interruzioni: le impostazioni originali dell'account vengono conservate e ripristinate quando le politiche vengono scollegate
## Prerequisiti
Prima di utilizzare le policy di Amazon S3, assicurati di avere:
+ Un' AWS organizzazione in modalità con tutte le funzionalità
+ Autorizzazioni per gestire AWS le politiche di Organizations (organizzazioni:CreatePolicy, organizzazioni:AttachPolicy, ecc.)
+ Il tipo di policy di Amazon S3 abilitato per la tua organizzazione
# Best practice per l'utilizzo delle policy di Amazon S3
Quando si implementano le policy di Amazon S3 in tutta l'organizzazione, seguire le best practice consolidate aiuta a garantire una distribuzione e una manutenzione di successo.
## Iniziare semplicemente e apportare piccole modifiche
Per semplificare il debug, inizia con policy semplici e apporta modifiche un elemento alla volta. Convalida il comportamento e l'impatto di ogni modifica prima di apportare la modifica successiva. Questo approccio riduce il numero di variabili da tenere in considerazione quando si verifica un errore o un risultato imprevisto.
## Stabilisci processi di revisione
Implementa processi per monitorare i nuovi attributi delle policy, valutare le eccezioni delle policy e apportare modifiche per mantenere l'allineamento con i requisiti operativi e di sicurezza dell'organizzazione.
## Convalida le modifiche alle policy di Amazon S3 utilizzando DescribeEffectivePolicy
Dopo aver apportato una modifica a una politica di Amazon S3, verifica le politiche efficaci per gli account rappresentativi al di sotto del livello in cui hai apportato la modifica. È possibile visualizzare la policy effettiva utilizzando la console di AWS gestione o utilizzando l'operazione DescribeEffectivePolicy API o una delle sue varianti AWS CLI o AWS SDK. Assicurati che l'impatto della modifica apportata sulla policy effettiva sia quello previsto.
## Comunica e allenati
Assicurati che la tua organizzazione comprenda lo scopo e l'impatto delle tue politiche. Fornisci indicazioni chiare sui comportamenti previsti e su come gestire gli errori dovuti all'applicazione delle politiche.
## Pianifica le esigenze legittime di accesso pubblico
Prima di implementare politiche a livello di organizzazione, identifica gli account che richiedono bucket Amazon S3 pubblici per scopi aziendali legittimi (come l'hosting di siti Web statici). Valuta la possibilità di utilizzare un allegato di policy a livello di OU o a livello di account per escludere questi account o consolida le esigenze dei bucket pubblici in account dedicati.
## Monitora l'applicazione delle politiche
Utilizzato AWS CloudTrail per monitorare l'allegato delle politiche e le azioni di applicazione. Imposta EventBridge regole per automatizzare le risposte alle violazioni o alle modifiche delle politiche.
# Sintassi ed esempi delle policy di Amazon S3
[Una policy di Amazon S3 è un file di testo semplice strutturato secondo le regole di JSON.](http://json.org) La sintassi per le policy di Amazon S3 segue la sintassi di tutti i tipi di policy di gestione. Per ulteriori informazioni, consulta [Comprendere l'ereditarietà delle policy di gestione](orgs_manage_policies_inheritance_mgmt.md). Questo argomento si concentra sull'applicazione di tale sintassi generale ai requisiti specifici delle policy di Amazon S3 e alle impostazioni di Block Public Access che aiutano a gestire.
Il seguente esempio di policy di Amazon S3 mostra la sintassi di base della policy:
```
{
"s3_attributes": {
"public_access_block_configuration": {
"@@assign": "all"
}
}
}
```
## La sintassi della policy di Amazon S3 include i seguenti elementi
`s3_attributes`
La chiave di primo livello per la configurazione delle policy di Amazon S3.
`public_access_block_configuration`
Definisce il comportamento di blocco dell'accesso pubblico per l'organizzazione.
`@@assign`
L'operatore di assegnazione che accetta uno dei due valori:
+ `"all"`- Abilita tutte e quattro le impostazioni di Amazon S3 Block Public Access a livello di organizzazione
+ `"none"`- Disattiva il controllo a livello di organizzazione, permettendo ai singoli account di gestire le proprie impostazioni di Block Public Access
Amazon S3 Block Public Access dispone di quattro impostazioni che controllano l'accesso pubblico:
1. **BlockPublicAcls**- Amazon S3 bloccherà le autorizzazioni di accesso pubblico applicate ai bucket o agli oggetti appena aggiunti e impedirà la creazione di nuove liste di controllo degli accessi pubblici (ACLs) per i bucket e gli oggetti esistenti. Questa impostazione non modifica le autorizzazioni esistenti che consentono l'accesso pubblico alle risorse di Amazon S3 utilizzando. ACLs
1. **BlockPublicPolicy**- Amazon S3 bloccherà nuove policy relative a bucket e punti di accesso che garantiscono l'accesso pubblico a bucket e oggetti. Questa impostazione non modifica le politiche esistenti che consentono l'accesso pubblico alle risorse di Amazon S3.
1. **IgnorePublicAcls**- Amazon S3 ignorerà tutto ciò ACLs che garantisce l'accesso pubblico a bucket e oggetti.
1. **RestrictPublicBuckets**- Amazon S3 ignorerà l'accesso pubblico e tra account per bucket o access point con policy che garantiscono l'accesso pubblico a bucket e oggetti.
Quando lo `@@assign` imposti`"all"`, tutte e quattro le impostazioni vengono consolidate e abilitate a livello di organizzazione, fornendo una protezione completa contro l'accesso pubblico su tutti gli account dell'organizzazione.
# AWS Shield Politiche di Network Security Director
AWS Shield Network Security Director aiuta a proteggere AWS l'ambiente individuando le risorse di elaborazione, rete e sicurezza della rete. Network Security Director valuta la configurazione di sicurezza di ogni risorsa analizzando la topologia di rete e le configurazioni di sicurezza rispetto alle AWS migliori pratiche e all'intelligence sulle minacce.
AWS Shield Le politiche di Network Security Director consentono di abilitare e gestire centralmente Network Security Director tra gli account dell'organizzazione. AWS Con una politica di Network Security Director, è possibile specificare per quali entità organizzative (root o account) è abilitato Network Security Director. OUs Quando gli account entrano a far parte dell'organizzazione, ereditano automaticamente le politiche applicabili in base alla loro posizione nella gerarchia organizzativa. Ciò garantisce che le risorse vengano analizzate per individuare eventuali lacune nella configurazione della sicurezza di rete man mano che l'organizzazione cresce. Le politiche rispettano le strutture organizzative esistenti e offrono flessibilità nel determinare quali account vengono analizzati.
AWS Shield Network Security Director è attualmente disponibile in anteprima.
## Come funziona
Quando si associa una politica di AWS Shield Network Security Director a un'entità organizzativa, la politica abilita automaticamente Network Security Director per tutti gli account membri che rientrano in tale ambito. Inoltre, se hai finalizzato la configurazione di AWS Shield Network Security Director registrando un amministratore delegato, tale account avrà una visibilità centralizzata sul livello di sicurezza della rete degli account dell'organizzazione in cui è abilitato AWS Shield Network Security Director.
AWS Shield Le policy di Network Security Director possono essere applicate all'intera organizzazione, a unità organizzative specifiche (OUs) o a singoli account. Gli account che entrano a far parte dell'organizzazione, o che vengono trasferiti in un'unità organizzativa con una policy associata, ereditano automaticamente la policy e hanno AWS Shield Network Security Director abilitato e collegato all'amministratore delegato di Network Security Director. Le policy di Network Security Director consentono di abilitare un'analisi della rete, visualizzare la topologia di rete e i risultati sulla sicurezza della rete per le risorse e ricevere consigli di correzione per risolvere le lacune di configurazione. Le impostazioni di configurazione specifiche e la soppressione dei singoli risultati possono essere gestite tramite l'account amministratore delegato di Network Security Director dell'organizzazione.
Quando si associa una policy di AWS Shield Network Security Director alla propria organizzazione o unità organizzativa, AWS Organizations valuta automaticamente la policy e la applica in base all'ambito definito. La logica di applicazione delle policy segue regole specifiche per la risoluzione dei conflitti:
+ Quando le regioni compaiono sia negli elenchi di attivazione che in quelli di disabilitazione, la configurazione di disabilitazione ha la precedenza. Ad esempio, se una regione è elencata sia nelle configurazioni di attivazione che in quelle di disabilitazione, AWS Shield Network Security Director sarà disabilitato in quella regione.
+ Quando `ALL_SUPPORTED` viene specificata l'abilitazione, AWS Shield Network Security Director è abilitato in tutte le regioni attuali e future, a meno che non sia disabilitato in modo esplicito. Ciò consente di mantenere una copertura completa man mano che AWS si espande in nuove regioni.
# Guida introduttiva alle politiche AWS Shield di Network Security Director
Prima di configurare le politiche di Network Security Director, assicurati di comprendere i prerequisiti e i requisiti di implementazione. Questo argomento ti guida nel processo di configurazione e gestione di queste politiche nella tua organizzazione.
## Prima di iniziare
Esamina i seguenti requisiti prima di implementare le politiche di AWS Shield Network Security Director:
+ Il tuo account deve far parte di un' AWS organizzazione
+ Devi aver effettuato l'accesso in uno dei seguenti modi:
+ L'account di gestione dell'organizzazione
+ Un amministratore delegato di AWS Organizations con le autorizzazioni per gestire le policy di AWS Shield Network Security Director
+ È necessario abilitare l'accesso affidabile per Network Security Director nella propria organizzazione
+ È necessario abilitare il tipo di policy Network Security Director nella radice dell'organizzazione
Inoltre, verifica che:
+ AWS Shield Network Security Director è supportato nelle regioni in cui desideri applicare le politiche
+ Il ruolo collegato al servizio AWS Shield Network Security Director è configurato nel tuo account di gestione. Se devi creare questo ruolo, puoi crearlo direttamente eseguendo. `aws iam create-service-linked-role --aws-service-name network-director.amazonaws.com`
## Passaggi dell’implementazione
Per implementare efficacemente le politiche di Network Security Director, segui questi passaggi in sequenza. Ogni passaggio garantisce una configurazione corretta e aiuta a prevenire problemi comuni durante la configurazione. Questi passaggi possono essere eseguiti tramite la AWS Organizations console, l'interfaccia a riga di AWS comando (AWS CLI) o. AWS SDKs
1. [Abilita l'accesso affidabile per AWS Shield Network Security Director](orgs_integrate_services.md#orgs_how-to-enable-disable-trusted-access).
1. [Abilita le politiche di AWS Shield Network Security Director per la tua organizzazione](enable-policy-type.md).
1. [Crea una politica AWS Shield di Network Security Director](orgs_manage_policies_network_security_director_syntax.md).
1. [Allega la policy alla directory principale, all'unità organizzativa o all'account della tua organizzazione](orgs_policies_attach.md).
1. [Visualizza la politica combinata efficace di Network Security Director che si applica a un account](orgs_manage_policies_effective.md).
# AWS Shield Sintassi ed esempi delle policy di Network Security Director
Le politiche di Network Security Director seguono una sintassi JSON standardizzata che definisce il modo in cui Network Security Director è abilitato e configurato all'interno dell'organizzazione. Una policy di AWS Shield Network Security Director è un documento JSON strutturato secondo la sintassi della policy di gestione dell' AWS Organizations. Definisce quali entità organizzative avranno AWS Shield Network Security Director abilitato automaticamente.
## Struttura politica di base
Una politica AWS Shield di Network Security Director utilizza questa struttura di base:
```
{
"network_security_director": {
"enablement": {
"network_security_scan": {
"enable_in_regions": {
"@@assign": ["us-east-1", "eu-west-1"]
},
"disable_in_regions": {
"@@assign": []
}
}
},
}
}
}
```
## Componenti della policy
AWS Shield Le politiche di Network Security Director contengono i seguenti componenti chiave:
`network_security_director`
La chiave di primo livello per i documenti relativi alle policy di Network Security Director, necessaria per tutte le politiche di Network Security Director.
`enablement`
Definisce in che modo Network Security Director è abilitato all'interno dell'organizzazione e contiene le configurazioni di scansione.
`network_security_scan`
Definisce la configurazione di applicazione per la scansione di sicurezza della rete.
`enable_in_regions`
Identificatore di configurazione per le impostazioni della regione. Definisce dove deve essere abilitata la scansione di sicurezza della rete.
`disable_in_regions`
Identificatore di configurazione per le impostazioni della regione. Definisce dove deve essere disabilitata la scansione di sicurezza della rete.