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à.
# Utilizzo di condizioni di policy IAM per il controllo granulare degli accessi
Quando si concedono le autorizzazioni in DynamoDB, è possibile specificare le condizioni che determinano il modo in cui una policy di autorizzazioni viene applicata.
## Panoramica di
In DynamoDB, si ha la possibilità di specificare le condizioni nel momento in cui si concedono le autorizzazioni utilizzando una policy IAM (consultare [Identity and Access Management per Amazon DynamoDB](security-iam.md)). Ad esempio, puoi:
+ Concedere autorizzazioni per permettere agli utenti accesso in sola lettura a determinati elementi e attributi in una tabella o indice secondario.
+ Concedere autorizzazioni per permettere agli utenti di accedere in sola scrittura a determinati attributi in una tabella, in base all'identità di tale utente.
In DynamoDB è possibile specificare le condizioni in una policy IAM utilizzando chiavi di condizione, come illustrato nel caso d'uso nella sezione seguente.
### Caso d'uso delle autorizzazioni
Oltre a controllare l'accesso alle operazioni API DynamoDB, è possibile controllare anche l'accesso a singoli elementi e attributi di dati. Ad esempio, puoi eseguire le operazioni seguenti:
+ Concedere autorizzazioni su una tabella, ma limitare l'accesso ad item specifici in tale tabella sulla base di determinati valori delle chiavi primarie. Un esempio potrebbe essere un'app di social network per i giochi, in cui tutti i dati di gioco degli utenti vengono archiviati in un'unica tabella, ma nessun utente può accedere agli elementi dei dati di cui non sono proprietari, come mostrato nell'illustrazione seguente:
![\[Un caso d’uso che concede l’accesso a livello di tabella a un utente ma limita l’accesso a elementi di dati specifici.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/info-hiding-horizontal.png)
+ Nascondi le informazioni in modo che solo un sottoinsieme di attributi sia visibile all'utente. Un esempio potrebbe essere un'app che mostra dati dei voli per gli aeroporti nelle vicinanze, in base alla posizione dell'utente. I nomi delle compagnie aeree, gli orari di arrivo e di partenza e il numero dei voli vengono tutti visualizzati. Tuttavia, gli attributi come i nomi dei piloti, o il numero dei passeggeri, sono nascosti, come mostrato nell'illustrazione seguente:
![\[Un caso d’uso che mostra solo un sottoinsieme di dati agli utenti, ma nasconde determinati attributi dei dati.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/info-hiding-vertical.png)
Per implementare questo tipo di controllo degli accessi granulare, scrivere una policy di autorizzazioni IAM che specifichi le condizioni per accedere alle credenziali di sicurezza e le autorizzazioni associate. Quindi applichi la policy agli utenti, ai gruppi o ai ruoli che crei utilizzando la console IAM. La policy IAM può limitare l'accesso ai singoli elementi in una tabella, agli attributi in tali elementi o a entrambi nello stesso tempo.
Puoi utilizzare la federazione delle identità sul Web per controllare l'accesso degli utenti che si autenticano con Facebook, Google o Login with Amazon. Per ulteriori informazioni, consulta [Utilizzo della federazione delle identità Web](WIF.md).
Puoi utilizzare l'elemento `Condition` IAM per implementare una policy di controllo degli accessi fine-grained. Aggiungendo un elemento `Condition` a una policy di autorizzazioni, è possibile consentire o negare l'accesso agli elementi e agli attributi nelle tabelle e negli indici DynamoDB, in base ai tuoi particolari requisiti aziendali.
Il video seguente spiega il controllo granulare degli accessi in DynamoDB attraverso le condizioni delle policy IAM.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/LbEmo_yulb0?si=VTSlNHVocAEYwhJi)
## Comprendere il controllo granulare degli accessi in DynamoDB
Il controllo granulare degli accessi in DynamoDB consente di creare limiti di autorizzazione precisi a più livelli:
1. **Controllo degli accessi a livello di elemento: limita gli utenti ad accedere** solo agli elementi che contengono valori chiave specifici, che in genere corrispondono alla loro identità o all'ambito di autorizzazione.
1. **Controllo dell'accesso a livello di attributo:** limita gli attributi (colonne) che gli utenti possono visualizzare o modificare, in modo da proteggere le informazioni sensibili e consentire l'accesso ai dati non sensibili all'interno degli stessi elementi.
1. **Controlli specifici dell'operazione:** applica regole di autorizzazione diverse in base al tipo di operazione eseguita.
Questi controlli sono implementati tramite policy IAM che utilizzano chiavi di condizione specifiche per DynamoDB.
## Specifica delle condizioni: Uso delle chiavi di condizione
AWS fornisce un set di chiavi di condizione predefinite (AWS-wide condition keys) per tutti i AWS servizi che supportano IAM per il controllo degli accessi. Ad esempio, puoi utilizzare la chiave di condizione `aws:SourceIp` per controllare l'indirizzo IP del richiedente prima che un'operazione venga effettuata. Per ulteriori informazioni e un elenco delle chiavi AWS-wide, consulta Available [Keys for Conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) nella IAM User Guide.
Di seguito sono riportate le chiavi delle condizioni specifiche del servizio DynamoDB che si applicano a DynamoDB.
**`dynamodb:LeadingKeys`**
Rappresenta il primo attributo chiave di una tabella, ovvero la chiave di partizione. Il nome della chiave `LeadingKeys` è plurale, anche se la chiave viene utilizzata con operazioni con item singolo. Inoltre, devi utilizzare il modificatore `ForAllValues` quando utilizzi `LeadingKeys` in una condizione.
**`dynamodb:Select`**
Rappresenta il parametro `Select` di una richiesta. `Select` può essere uno qualsiasi dei seguenti valori:
+ `ALL_ATTRIBUTES`
+ `ALL_PROJECTED_ATTRIBUTES`
+ `SPECIFIC_ATTRIBUTES`
+ `COUNT`
Sebbene spesso associata alle operazioni di interrogazione e scansione, questa chiave di condizione si applica a tutte le operazioni DynamoDB che restituiscono gli attributi degli articoli ed è essenziale per controllare l'accesso agli attributi in tutte le azioni API. L'utilizzo di vincoli StringEqualsIfExists o vincoli simili su questa chiave di condizione applicherà i vincoli alle operazioni in cui si applica questa chiave di condizione, ignorandoli alle operazioni in cui non è applicabile.
**`dynamodb:Attributes`**
Rappresenta un elenco degli attributi di *primo livello a cui si accede tramite una richiesta.* Un attributo di primo livello è accessibile tramite una richiesta se esso, o qualsiasi attributo annidato in esso contenuto, è specificato nei parametri della richiesta. Ad esempio, una `GetItem` richiesta che specifica un `ProjectionExpression` di`"Name, Address.City"`, l'`dynamodb:Attributes`elenco includerebbe «Nome» e «Indirizzo». Se il `Attributes` parametro è enumerato in una politica di controllo degli accessi dettagliata, prendi in considerazione anche la possibilità di applicare restrizioni `ReturnValues` e `Select` parametri per garantire l'accesso limitato a determinati attributi attraverso più azioni API come, e. `GetItem` `Query` `Scan`
Questa condizione viene valutata solo sugli attributi specificati nella richiesta (come in a ProjectionExpression), non sugli attributi nella risposta. Se nella richiesta non ProjectionExpression viene fornito alcun valore, tutti gli attributi verranno restituiti indipendentemente da eventuali restrizioni sugli attributi nella politica. Consulta la sezione «Garantire l'applicazione delle restrizioni basate sugli attributi» di seguito per i dettagli su come proteggere correttamente l'accesso agli attributi.
**`dynamodb:ReturnValues`**
Rappresenta il `ReturnValues` parametro di una richiesta. A seconda dell'azione dell'API, `ReturnValues` potrebbe essere uno dei seguenti valori:
+ `ALL_OLD`
+ `UPDATED_OLD`
+ `ALL_NEW`
+ `UPDATED_NEW`
+ `NONE`
**`dynamodb:ReturnConsumedCapacity`**
Rappresenta il parametro `ReturnConsumedCapacity` di una richiesta. `ReturnConsumedCapacity` può essere uno qualsiasi dei seguenti valori:
+ `TOTAL`
+ `NONE`
**`dynamodb:FirstPartitionKeyValues`**
Rappresenta il primo attributo chiave di una tabella, in altre parole, la prima chiave di partizione. Il nome della chiave `FirstPartitionKeyValues` è plurale, anche se la chiave viene utilizzata con operazioni con item singolo. Inoltre, è necessario utilizzare il `ForAllValues` modificatore quando si utilizza in una condizione. `FirstPartitionKeyValues` `FirstPartitionKeyValues`e `LeadingKeys` può essere utilizzato come intercambiabile.
**`dynamodb:SecondPartitionKeyValues`**
Simile a `dynamodb:FirstPartitionKeyValues`. Rappresenta la seconda chiave di partizione delle risorse. Il nome della chiave `SecondPartitionKeyValues` è plurale, anche se la chiave viene utilizzata con operazioni con item singolo.
**`dynamodb:ThirdPartitionKeyValues`**
Simile a `dynamodb:FirstPartitionKeyValues`. Rappresenta la chiave di terza partizione delle risorse. Il nome della chiave `ThirdPartitionKeyValues` è plurale, anche se la chiave viene utilizzata con operazioni con item singolo.
**`dynamodb:FourthPartitionKeyValues`**
Simile a `dynamodb:FirstPartitionKeyValues`. Rappresenta la quarta chiave di partizione delle risorse. Il nome della chiave `FourthPartitionKeyValues` è plurale, anche se la chiave viene utilizzata con operazioni con item singolo.
### Garantire l'applicazione delle restrizioni basate sugli attributi
Quando si utilizzano condizioni basate sugli attributi per limitare l'accesso a attributi specifici, è importante capire come vengono valutate queste condizioni:
+ **Le condizioni degli attributi vengono valutate solo sugli attributi specificati nella richiesta**, non sugli attributi nella risposta.
+ **Per le operazioni di lettura senza ProjectionExpression** (GetItem, Query, Scan, ecc.), tutti gli attributi verranno restituiti indipendentemente dalle restrizioni sugli attributi previste dalla policy. Per evitare questa potenziale esposizione di dati sensibili, implementa entrambe le condizioni degli attributi (`dynamodb:Attributes`) e deve essere richiesta una condizione che richieda attributi specifici (`dynamodb:Select`).
+ **Per le operazioni di scrittura** (PutItem UpdateItem,, DeleteItem), il ReturnValues parametro può restituire elementi completi, esponendo potenzialmente attributi limitati anche quando l'operazione di scrittura stessa è conforme alla politica dell'utente. Per evitare questa esposizione, implementate nella vostra policy sia le condizioni relative agli attributi (`dynamodb:Attributes`) che le restrizioni su ReturnValues (`dynamodb:ReturnValues`).
### Limitazione dell'accesso utente
Molte policy di autorizzazioni IAM permettono agli utenti di accedere solo a quegli elementi in una tabella in cui il valore della chiave di partizione corrisponde all'identificatore dell'utente. Ad esempio, l'app di gioco menzionata in precedenza limita l'accesso in questo modo, tanto che gli utenti possono solo accedere ai dati di gioco collegati al loro ID utente. Le variabili di sostituzione IAM `${www.amazon.com:user_id}`, `${graph.facebook.com:id}` e `${accounts.google.com:sub}` contengono identificatori degli utenti per Login with Amazon, Facebook e Google. Per scoprire come un'applicazione effettua l'accesso a uno di questi provider di identità e ottiene gli identificatori, consulta [Utilizzo della federazione delle identità Web](WIF.md).
**Importante**
Il controllo granulare degli accessi non è supportato per limitare la replica delle tabelle globali. L’applicazione di condizioni di policy per il controllo granulare degli accessi ai [principali di servizio o ai ruoli collegati al servizio](globaltables-security.md) DynamoDB utilizzati per la replica delle tabelle globali può interrompere la replica all’interno di una tabella globale.
**Nota**
Ognuno degli esempi presenti nella sezione seguente imposta la clausola `Effect` su `Allow` e specifica solo le operazioni, le risorse e i parametri permessi. L'accesso è consentito solo a ciò che è elencato esplicitamente nella policy IAM.
In alcuni casi è possibile riscrivere queste policy in modo che si basino sul rifiuto (vale a dire impostare la clausola `Effect` su `Deny` e invertire tutta la logica nella policy). Tuttavia, si consiglia di evitare di utilizzare le policy basate sul rifiuto con DynamoDB poiché la loro scrittura corretta è difficile rispetto alle policy basate sulle concessioni. Inoltre, le future modifiche all'API DynamoDB (o le modifiche agli input API esistenti) possono rendere una policy basata sul rifiuto inefficace.
### Policy di esempio: utilizzo di condizioni per il controllo granulare degli accessi
In questa sezione vengono illustrate varie policy per implementare il controllo degli accessi granulare sulle tabelle e gli indici di DynamoDB.
**Nota**
Tutti gli esempi utilizzano la regione us-west-2 e contengono account fittizi. IDs
#### Esempio 1: Controllo di accesso di base basato su chiavi di partizione con restrizioni sugli attributi
Ad esempio, considera un'app di gioco per dispositivi mobili che consente ai giocatori di scegliere e giocare a una varietà di giochi diversi. L'app utilizza una tabella DynamoDB `GameScores` denominata per tenere traccia dei punteggi più alti e di altri dati utente. Ogni item nella tabella è identificato univocamente da un ID utente e dal nome del gioco a cui l'utente ha giocato. La tabella `GameScores` ha una chiave primaria costituita da una chiave di partizione (`UserId`) e da una chiave di ordinamento (`GameTitle`). Gli utenti possono avere accesso solo ai dati di gioco associati al proprio ID utente. Un utente che desidera giocare deve appartenere a un ruolo IAM denominato `GameRole`, a cui è collegata una policy di sicurezza.
Per gestire le autorizzazioni degli utenti in quest'app, potresti scrivere una policy di autorizzazioni come la seguente:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAccessToOnlyItemsMatchingUserID",
"Effect":"Allow",
"Action":[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores"
],
"Condition":{
"ForAllValues:StringEquals":{
"dynamodb:LeadingKeys":[
"${www.amazon.com:user_id}"
],
"dynamodb:Attributes":[
"UserId",
"GameTitle",
"Wins",
"Losses",
"TopScore",
"TopScoreDateTime"
]
},
"StringEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES"
}
}
}
]
}
```
------
Oltre a concedere le autorizzazioni per operazioni DynamoDB specifiche (elemento `Action`) sulla tabella `GameScores` (elemento `Resource`), l'elemento `Condition` utilizza le seguenti chiavi di condizione specifiche di DynamoDB che limitano le autorizzazioni, come illustrato di seguito:
+ `dynamodb:LeadingKeys`: questa chiave di condizione consente agli utenti di accedere solo agli elementi in cui il valore della chiave di partizione corrisponde al proprio ID utente. Questo ID, `${www.amazon.com:user_id}`, è una variabile di sostituzione. Per ulteriori informazioni sulle variabili di sostituzione, consulta [Utilizzo della federazione delle identità Web](WIF.md).
+ `dynamodb:Attributes`: questa chiave di condizione limita l'accesso agli attributi specificati in modo che solo le operazioni elencate nella policy di autorizzazione possano restituire valori per questi attributi. Inoltre, la clausola `StringEqualsIfExists` garantisce che l'app debba fornire sempre un elenco di attributi specifici su cui agire e che l'app non possa richiedere tutti gli attributi.
Quando viene valutata una policy IAM, il risultato è sempre o true (l'accesso viene consentito) o false (l'accesso viene negato). Se una parte dell'elemento `Condition` è false, l'intera policy restituisce false e l'accesso viene quindi negato.
**Importante**
Se utilizzi `dynamodb:Attributes`, devi specificare i nomi di tutti gli attributi della chiave primaria e della chiave di indicizzazione per la tabella e qualsiasi indice secondario che sia elencato nella policy. In caso contrario, DynamoDB non potrà utilizzare questi attributi della chiave per effettuare l'operazione richiesta.
I documenti delle policy IAM possono contenere solo i seguenti caratteri Unicode: tabulatore orizzontale (U\$10009), segno di avanzamento riga (U\$1000A), ritorno a capo (U\$1000D), e i caratteri nell'intervallo da U\$10020 a U\$100FF.
#### Esempio 2: concedere autorizzazioni che limitano l'accesso agli elementi con un valore specifico della chiave di partizione
La seguente policy di autorizzazioni concede le autorizzazioni per permettere un insieme di operazioni DynamoDB sulla tabella `GamesScore`. Utilizza la chiave di condizione `dynamodb:LeadingKeys` per limitare le operazioni degli utenti solo sugli elementi il cui valore di chiave di partizione `UserID` corrisponda all'ID utente univoco di Login with Amazon per questa app.
**Importante**
L'elenco delle operazioni non include le autorizzazioni per l'operazione `Scan` poiché `Scan` restituisce tutti gli elementi, indipendentemente dalle chiavi principali.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"FullAccessToUserItems",
"Effect":"Allow",
"Action":[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:PutItem",
"dynamodb:UpdateItem",
"dynamodb:DeleteItem",
"dynamodb:BatchWriteItem"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores"
],
"Condition":{
"ForAllValues:StringEquals":{
"dynamodb:LeadingKeys":[
"${www.amazon.com:user_id}"
]
}
}
}
]
}
```
------
**Nota**
Quando si utilizzano variabili di policy, è necessario specificare esplicitamente la versione 2012-10-17 nella policy. La versione di default della sintassi della policy di accesso, 2008-10-17, non supporta le variabili di policy.
Per implementare l'accesso in sola lettura, puoi rimuovere le operazioni che possono modificare i dati. Nella policy seguente solo quelle operazioni che forniscono accesso in sola lettura sono incluse nella condizione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ReadOnlyAccessToUserItems",
"Effect":"Allow",
"Action":[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores"
],
"Condition":{
"ForAllValues:StringEquals":{
"dynamodb:LeadingKeys":[
"${www.amazon.com:user_id}"
]
}
}
}
]
}
```
------
**Importante**
Se si utilizza `dynamodb:Attributes`, è necessario specificare i nomi di tutti gli attributi della chiave primaria e della chiave di indicizzazione per la tabella e qualsiasi indice secondario che sia elencato nella policy. In caso contrario, DynamoDB non potrà utilizzare questi attributi della chiave per effettuare l'operazione richiesta.
#### Esempio 3: concedere autorizzazioni che limitano l'accesso a attributi specifici in una tabella
La seguente policy di autorizzazioni permette l'accesso solo a due attributi specifici in una tabella aggiungendo la chiave di condizione `dynamodb:Attributes`. Questi attributi possono essere letti, scritti o valutati in una scrittura condizionale o un filtro di scansione.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"LimitAccessToSpecificAttributes",
"Effect":"Allow",
"Action":[
"dynamodb:UpdateItem",
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:BatchGetItem",
"dynamodb:Scan"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores"
],
"Condition":{
"ForAllValues:StringEquals":{
"dynamodb:Attributes":[
"UserId",
"TopScore"
]
},
"StringEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES",
"dynamodb:ReturnValues":[
"NONE",
"UPDATED_OLD",
"UPDATED_NEW"
]
}
}
}
]
}
```
------
**Nota**
La policy adotta un approccio allow list, che permette l'acceso a un insieme denominato di attributi. Puoi scrivere, invece, una policy equivalente che rifiuti l'accesso ad altri attributi. Questo approccio deny list non è consigliato. Gli utenti possono determinare i nomi di questi attributi negati seguendo il principio del privilegio minimo, come spiegato in Wikipedia all'indirizzo http://en.wikipedia. org/wiki/Principle\$1of\$1least\$1privilege e utilizza un approccio basato sulla lista degli indirizzi consentiti per enumerare tutti i valori consentiti, anziché specificare gli attributi negati.
Questa policy non permette `PutItem`, `DeleteItem` o `BatchWriteItem`. Queste operazioni sostituiscono sempre l'intero item precedente, il che permetterebbe agli utenti di eliminare i valori precedenti per gli attributi a cui non hanno il permesso di accedere.
La clausola `StringEqualsIfExists` nella policy di autorizzazioni garantisce quanto segue:
+ Se l'utente specifica il parametro `Select`, allora il suo valore deve essere `SPECIFIC_ATTRIBUTES`. Questo requisito previene che l'operazione API restituisca attributi per cui non si ha il permesso, come ad esempio da una proiezione di indice.
+ Se l'utente specifica il parametro `ReturnValues`, allora il suo valore deve essere `NONE`, `UPDATED_OLD` o `UPDATED_NEW`. Questo viene richiesto poiché l'operazione `UpdateItem` effettua anche operazioni di lettura implicite per verificare che un item esista prima di sostituirlo, in modo tale che i valori di attributo precedenti possano essere restituiti se richiesto. Limitare `ReturnValues` in questo modo garantisce che gli utenti possano solo leggere o scrivere gli attributi permessi.
+ La clausola `StringEqualsIfExists` assicura che, nel contesto delle operazioni consentite, per ogni richiesta possa essere utilizzato solo uno di questi parametri, `Select` o `ReturnValues`.
Di seguito vengono elencate alcune variazioni a questa policy:
+ Per permettere le operazioni di sola lettura, puoi rimuovere `UpdateItem` dall'elenco delle operazioni consentite. Poiché nessuna delle operazioni rimanenti accetta `ReturnValues`, puoi rimuovere `ReturnValues` dalla condizione. Puoi anche modificare `StringEqualsIfExists` in `StringEquals` poiché il parametro `Select` ha sempre un valore (`ALL_ATTRIBUTES`, se non diversamente specificato).
+ Per consentire le operazioni di sola scrittura, puoi rimuovere tutto tranne `UpdateItem` dall'elenco delle operazioni consentite. Poiché `UpdateItem` non accetta il parametro `Select`, puoi rimuovere `Select` dalla condizione. È necessario anche modificare `StringEqualsIfExists` in `StringEquals` poiché il parametro `ReturnValues` ha sempre un valore (`NONE`, se non diversamente specificato).
+ Per permettere tutti gli attributi il cui nome corrisponde a un modello, utilizza `StringLike` anziché `StringEquals` e utilizza un carattere jolly (\$1) che trovi una corrispondenza di modelli con più caratteri.
#### Esempio 4: concedere le autorizzazioni per impedire gli aggiornamenti su determinati attributi
La seguente policy di autorizzazioni limita l'accesso degli utenti in modo che possa aggiornare solo gli attributi specifici identificati dalla chiave di condizione `dynamodb:Attributes`. La condizione `StringNotLike` impedisce a un'applicazione di aggiornare gli attributi specificati utilizzando la chiave di condizione `dynamodb:Attributes`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"PreventUpdatesOnCertainAttributes",
"Effect":"Allow",
"Action":[
"dynamodb:UpdateItem"
],
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores",
"Condition":{
"ForAllValues:StringNotLike":{
"dynamodb:Attributes":[
"FreeGamesAvailable",
"BossLevelUnlocked"
]
},
"StringEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES",
"dynamodb:ReturnValues":[
"NONE",
"UPDATED_OLD",
"UPDATED_NEW"
]
}
}
}
]
}
```
------
Tenere presente quanto segue:
+ L'operazione `UpdateItem`, come altre operazioni di scrittura, richiede l'accesso in lettura agli elementi, in modo che possa restituire valori prima e dopo l'aggiornamento. Nella policy limiti l'operazione per poter accedere solo agli attributi che è permesso aggiornare specificando la chiave di condizione `dynamodb:ReturnValues`. La chiave di condizione limita il valore di `ReturnValues` nella richiesta mentre specifica solo `NONE`, `UPDATED_OLD` o `UPDATED_NEW` e non include `ALL_OLD` o `ALL_NEW`.
+ L'`StringEqualsIfExists`operatore assicura che, se `dynamodb:Select` o `dynamodb:ReturnValues` è presente nella richiesta, questa deve corrispondere ai valori specificati. Ciò impedisce alle operazioni di restituire articoli completi.
+ Quando si limitano gli aggiornamenti degli attributi, è necessario controllare anche quali dati possono essere restituiti per impedire la divulgazione di informazioni sugli attributi protetti.
+ Le operazioni `PutItem` e `DeleteItem` sostituiscono un item intero, permettendo quindi alle applicazioni di modificare qualsiasi attributo. Pertanto, quando si limita un'applicazione all'aggiornamento solo di attributi specifici, non è necessario concedere l'autorizzazione per tali attributi. APIs
#### Esempio 5: concedere le autorizzazioni per interrogare solo gli attributi proiettati in un indice
La seguente policy di autorizzazioni consente le query su un indice secondario (`TopScoreDateTimeIndex`), utilizzando la chiave di condizione `dynamodb:Attributes`. Inoltre limita le query in modo che possano richiedere solo gli attributi specifici che sono stati proiettati nell'indice.
Per richiedere all'applicazione di specificare un elenco di attributi nella query, la policy specifica anche la chiave di condizione `dynamodb:Select` in modo che richieda che il parametro `Select` dell'operazione DynamoDB `Query` sia `SPECIFIC_ATTRIBUTES`. L'elenco di attributi è limitato a un elenco specifico che viene fornito utilizzando la chiave di condizione `dynamodb:Attributes`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"QueryOnlyProjectedIndexAttributes",
"Effect":"Allow",
"Action":[
"dynamodb:Query"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex"
],
"Condition":{
"ForAllValues:StringEquals":{
"dynamodb:Attributes":[
"TopScoreDateTime",
"GameTitle",
"Wins",
"Losses",
"Attempts"
]
},
"StringEquals":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES"
}
}
}
]
}
```
------
La policy di autorizzazione seguente è simile, però la query deve richiedere tutti gli attributi che sono stati proiettati nell'indice.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"QueryAllIndexAttributes",
"Effect":"Allow",
"Action":[
"dynamodb:Query"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex"
],
"Condition":{
"StringEquals":{
"dynamodb:Select":"ALL_PROJECTED_ATTRIBUTES"
}
}
}
]
}
```
------
#### Esempio 6: concedere le autorizzazioni per limitare l'accesso a determinati attributi e valori delle chiavi di partizione
La policy di autorizzazione seguente specifica le operazioni di DynamoDB (specificate nell'elemento `Action`) su una tabella e un indice di tabella (specificati nell'elemento `Resource`). La policy utilizza la chiave `dynamodb:LeadingKeys` condition per limitare le autorizzazioni solo agli elementi il cui valore della chiave di partizione corrisponde all'ID Facebook dell'utente.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"LimitAccessToCertainAttributesAndKeyValues",
"Effect":"Allow",
"Action":[
"dynamodb:UpdateItem",
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:BatchGetItem"
],
"Resource":[
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores",
"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex"
],
"Condition":{
"ForAllValues:StringEquals":{
"dynamodb:LeadingKeys":[
"${graph.facebook.com:id}"
],
"dynamodb:Attributes":[
"attribute-A",
"attribute-B"
]
},
"StringEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES",
"dynamodb:ReturnValues":[
"NONE",
"UPDATED_OLD",
"UPDATED_NEW"
]
}
}
}
]
}
```
------
Tenere presente quanto segue:
+ Le azioni di scrittura consentite dalla policy (`UpdateItem`) possono solo modificare l'attributo-A o l'attributo-B.
+ Poiché la policy permette `UpdateItem`, un'applicazione può inserire nuovi item e gli attributi nascosti saranno null nei nuovi item. Se questi attributi sono proiettati in `TopScoreDateTimeIndex`, la policy ha il vantaggio aggiuntivo di impedire le query che causeranno operazioni di recupero dalla tabella.
+ Le applicazioni non possono leggere nessun attributo che non sia elencato in `dynamodb:Attributes`. Con questa policy in atto, un'applicazione deve impostare il parametro `Select` su `SPECIFIC_ATTRIBUTES` nelle richieste di lettura e solo gli attributi nell'allow list possono essere richiesti. Per le richieste di lettura, l'applicazione non può impostare `ReturnValues` su `ALL_OLD` o `ALL_NEW` e non può effettuare operazioni di scrittura condizionali basate su attributi che non siano questi.
#### Esempio 7: negare le autorizzazioni per limitare l'accesso a attributi specifici in una tabella
La seguente politica nega l'accesso agli attributi sensibili e garantisce che questa restrizione non possa essere aggirata omettendo un'espressione di proiezione. Consente l'accesso generale alla `CustomerData` tabella negando esplicitamente l'accesso agli attributi e agli attributi. `SSN` `CreditCardNumber`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData"
},
{
"Effect":"Deny",
"Action":[
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData",
"Condition":{
"ForAnyValue:StringEquals":{
"dynamodb:Attributes":[
"SSN",
"CreditCardNumber"
]
}
}
},
{
"Effect":"Deny",
"Action":[
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/CustomerData",
"Condition":{
"StringNotEqualsIfExists":{
"dynamodb:Select":"SPECIFIC_ATTRIBUTES"
}
}
}
]
}
```
------
## Argomenti correlati
+ [Identity and Access Management per Amazon DynamoDB](security-iam.md)
+ [Autorizzazioni API DynamoDB: riferimento a operazioni, risorse e condizioni](api-permissions-reference.md)