Utilizzo di condizioni di policy IAM per il controllo granulare degli accessi - Amazon DynamoDB

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

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). 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.

Nota

Alcuni AWS servizi supportano anche condizioni basate su tag, ma DynamoDB no.

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.
  • 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.

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.

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.

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 denominata GameScores per tenere traccia dei punteggi elevati o di altri dati dell'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:

{ "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.

  • 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+0009), segno di avanzamento riga (U+000A), ritorno a capo (U+000D), e i caratteri nell'intervallo da U+0020 a U+00FF.

Specifica delle condizioni: Uso delle chiavi di condizione

AWS fornisce un set di chiavi di condizione predefinite (chiavi di condizione AWS-wide) 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 nella IAM User Guide.

La seguente tabella mostra le chiavi di condizione specifiche dei servizi DynamoDB che si applicano a DynamoDB.

Chiave di condizione DynamoDB Descrizione
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 Query o Scan. Select può essere uno qualsiasi dei seguenti valori:

  • ALL_ATTRIBUTES

  • ALL_PROJECTED_ATTRIBUTES

  • SPECIFIC_ATTRIBUTES

  • COUNT

dynamodb:Attributes

Rappresenta un elenco dei nomi di attributi in una richiesta o gli attributi che vengono restituiti da una richiesta. I valori Attributes sono denominati nello stesso modo e hanno lo stesso significato dei parametri per determinate operazioni API DynamoDB, come illustrato di seguito:

  • AttributesToGet

    Utilizzato da: BatchGetItem, GetItem, Query, Scan

  • AttributeUpdates

    Utilizzato da: UpdateItem

  • Expected

    Utilizzato da: DeleteItem, PutItem, UpdateItem

  • Item

    Utilizzato da: PutItem

  • ScanFilter

    Utilizzato da: Scan

dynamodb:ReturnValues

Rappresenta il parametro ReturnValues di una richiesta. ReturnValues può essere uno qualsiasi 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

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.

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, consigliamo di evitare di utilizzare le policy basate sul rifiuto con DynamoDB poiché sono difficili da scrivere correttamente 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 ID account fittizi.

Il video seguente spiega il controllo granulare degli accessi in DynamoDB utilizzando le condizioni delle policy IAM.

1: Concessione delle autorizzazioni che limitano l'accesso agli elementi con un valore di chiave di partizione specifico

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.

{ "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 le variabili di policy, è necessario specificare esplicitamente la versione 2012-10-17 nella policy. La versione di default della sintassi della/e 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.

{ "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.

2: Concessione delle autorizzazioni che limitano l'accesso ad 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.

{ "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 rifiutati seguendo il principio del privilegio minimo, come spiegato in Wikipedia all'indirizzo https://it.wikipedia.org/wiki/Principio_del_privilegio_minimo e utilizzare un approccio allow list per numerare tutti i valori consentiti piuttosto che specificare gli attributi rifiutati.

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 (*) che trovi una corrispondenza di modelli con più caratteri.

3: Concessione delle 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.

{ "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" ] }, "StringEquals":{ "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] }

Tieni 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.

  • Le operazioni PutItem e DeleteItem sostituiscono un item intero, permettendo quindi alle applicazioni di modificare qualsiasi attributo. Di conseguenza, quando limiti un'applicazione perché aggiorni solo attributi specifici, non si dovrebbe concedere l'autorizzazione per queste API.

4: Concessione delle autorizzazioni per eseguire query solo sugli 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.

{ "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.

{ "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" } } } ] }

5: Concessione delle autorizzazioni per limitare l'accesso a determinati attributi e ai valori di chiave 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 di condizione dynamodb:LeadingKeys per limitare l'accesso solo agli elementi il cui valore della chiave di partizione corrisponde all'ID Facebook dell'utente.

{ "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" ] } } } ] }

Tieni presente quanto segue:

  • Le operazioni di scrittura permesse dalla policy (UpdateItem) possono solo modificare attribute-A o attribute-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.

Argomenti correlati