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à.
# Come le autorizzazioni e le policy forniscono la gestione degli accessi
La parte di gestione degli accessi di AWS Identity and Access Management (IAM) ti aiuta a definire cosa può fare un'entità principale in un account. Un'entità principale è una persona o un'applicazione autenticata tramite un'entità IAM (utente o ruolo IAM). La gestione degli accessi viene spesso definita come *autorizzazione*. Puoi gestire l'accesso AWS creando policy e collegandole a identità o risorse IAM (utenti IAM, gruppi IAM o ruoli IAM). AWS Una policy è un oggetto AWS che, se associato a un'identità o a una risorsa, ne definisce le autorizzazioni. AWS valuta queste politiche quando un principale utilizza un'entità IAM (utente IAM o ruolo IAM) per effettuare una richiesta. Le autorizzazioni nelle policy determinano l’approvazione o il rifiuto della richiesta. La maggior parte delle policy viene archiviata AWS come documenti JSON. Per ulteriori informazioni sui tipi di policy e i relativi utilizzi, consulta [Politiche e autorizzazioni in AWS Identity and Access Management](access_policies.md).
## Policy e account
Se gestisci un singolo account in AWS, definisci le autorizzazioni all'interno di quell'account utilizzando le politiche. Se gestisci le autorizzazioni su più account, è più difficile gestire le autorizzazioni per i tuoi utenti IAM. Puoi utilizzare i ruoli IAM, le politiche basate sulle risorse o le liste di controllo degli accessi (ACLs) per le autorizzazioni tra account. Tuttavia, se possiedi più account, ti consigliamo invece di utilizzare il AWS Organizations servizio per aiutarti a gestire tali autorizzazioni. Per ulteriori informazioni, consulta [Cos'è AWS Organizations?](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) nella *Guida AWS Organizations per l'utente*.
## Policy e utenti
Gli utenti IAM sono identità nell' Account AWS. Quando si crea un utente IAM, l'utente non potrà accedere ad alcun elemento nell'account finché non gli viene concessa l'autorizzazione. È possibile fornire autorizzazioni a un utente IAM creando una policy basata su identità, che è una policy collegata all'utente IAM o a un gruppo IAM a cui appartiene l'utente IAM. L'esempio seguente mostra una policy JSON che consente all'utente IAM di eseguire tutte le azioni di Amazon DynamoDB (`dynamodb:*`) sulla tabella `Books` nell'account `123456789012` all'interno della regione `us-east-2`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-east-2:123456789012:table/Books"
}
}
```
------
Dopo il collegamento di questa policy all'utente IAM, l'utente disporrà dell'autorizzazione per eseguire tutte le operazioni nella tabella `Books` dell'istanza DynamoDB. La maggior parte degli utenti IAM dispone di più policy che si combinano per rappresentare il totale delle autorizzazioni concesse.
Le operazioni o le risorse che non sono esplicitamente consentite da una policy vengono rifiutate per impostazione predefinite. Ad esempio, se la policy precedente è la policy singola collegata a un utente, quell'utente può eseguire operazioni DynamoDB nella tabella `Books`, ma non può eseguire operazioni in altre tabelle. Allo stesso modo, all'utente non è consentito eseguire alcuna azione in Amazon EC2, Amazon S3 o in qualsiasi AWS altro servizio perché le autorizzazioni per lavorare con tali servizi non sono incluse nella politica.
## Policy e gruppi IAM
Puoi organizzare gli utenti IAM in *gruppi IAM* e collegare una policy a un gruppo IAM. In quel caso, i singoli utenti IAM hanno ancora le proprie credenziali, ma tutti gli utenti IAM in un gruppo IAM dispongono delle autorizzazioni collegate al gruppo IAM. Utilizza i gruppi IAM per facilitare la gestione delle autorizzazioni.
![\[Questo diagramma mostra. come gli utenti IAM possono essere organizzati in gruppi IAM per facilitare la gestione delle autorizzazioni, poiché ognuno degli utenti IAM ha le autorizzazioni assegnate a un gruppo IAM.\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/iam-intro-users-and-groups.diagram.png)
Gli utenti o i gruppi IAM possono avere più policy a loro collegate, le quali concedono diverse autorizzazioni. In questo caso, la combinazione di policy determina le autorizzazioni effettive del principale. Se il principale non dispone dell'`Allow`autorizzazione esplicita sia per un'azione che per una risorsa, non dispone di tali autorizzazioni.
## Sessioni e ruoli dell’utente federato
I presidi federati non hanno identità permanenti nel modo in cui li hanno gli utenti Account AWS IAM. Per assegnare le autorizzazioni ai principali federati, puoi creare un’entità definita come *ruolo* e stabilire le autorizzazioni per il ruolo. Quando un principale federato SAML o OIDC accede AWS, l'utente viene associato al ruolo e gli vengono concesse le autorizzazioni definite nel ruolo. Per ulteriori informazioni, consulta [Creazione di un ruolo per un provider di identità di terze parti](id_roles_create_for-idp.md).
## Policy basate su identità e policy basate su risorse.
Le policy basate su identità sono policy di autorizzazione che si collegano a un'identità IAM, come un utente, un gruppo o un ruolo IAM. Le policy basate su risorse sono policy di autorizzazione che si collegano a una risorsa, come un bucket Amazon S3 o una policy di attendibilità del ruolo IAM.
Le ***policy basate su identità*** controllano quali operazioni l'identità può eseguire, su quali risorse e in quali condizioni. Le policy basate su identità possono essere ulteriormente suddivise:
+ **Politiche gestite: politiche** autonome basate sull'identità che puoi associare a più utenti, gruppi e ruoli nel tuo. Account AWS Puoi utilizzare due tipi di policy gestite:
+ **AWS politiche gestite: politiche** gestite create e gestite da. AWS Se non conosci l'utilizzo delle politiche, ti consigliamo di iniziare utilizzando le politiche AWS gestite.
+ **Policy gestite dal cliente**: le policy gestite che sono create e gestite nel tuo Account AWS. Le policy gestite dai clienti offrono un controllo più preciso sulle policy rispetto alle policy AWS gestite. Puoi creare, modificare e convalidare una policy IAM nell'editor visivo oppure creando direttamente il documento di policy JSON. Per ulteriori informazioni, consultare [Definire le autorizzazioni IAM personalizzate con policy gestite dal cliente](access_policies_create.md) e [Modificare le policy IAM](access_policies_manage-edit.md).
+ **Policy in linea**: le policy che sono create, gestite e direttamente incorporate in un singolo utente, gruppo o ruolo. Nella maggior parte dei casi, non è consigliato l'uso di policy inline.
Le ***policy basate su risorse*** controllano quali operazioni uno specifico principale può eseguire, su quale risorsa e in quali condizioni. Le policy basate risorse sono policy inline. Non esistono policy gestite basate su risorse. Per consentire l'accesso multi-account, puoi specificare un intero account o entità IAM in un altro account come principale in una policy basata sulle risorse.****
Il servizio IAM supporta solo un tipo di policy basata su risorse detta *policy di attendibilità* del ruolo, collegata a un ruolo IAM. Poiché un ruolo IAM è sia un'identità che una risorsa che supporta policy basate su risorse, a un ruolo IAM è necessario collegare sia una policy di attendibilità che una policy basata su identità. Le politiche di fiducia definiscono quali entità principali (account, utenti, ruoli e responsabili degli utenti AWS STS federati) possono assumere il ruolo. Per capire in che modo i ruoli IAM si differenziano da altre policy basate su risorse, consulta [Accesso alle risorse multi-account in IAM](access_policies-cross-account-resource-access.md).
Per scoprire quali servizi supportano le policy basate su risorse, consulta la pagina [AWS servizi che funzionano con IAM](reference_aws-services-that-work-with-iam.md). Per ulteriori informazioni sulle policy basate su risorse, consulta la pagina [Policy basate sulle identità e policy basate su risorse](access_policies_identity-vs-resource.md).