Panoramica di Comprendere il controllo granulare degli accessi in DynamoDB Specifica delle condizioni: Uso delle chiavi di condizione Argomenti correlati

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

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.

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

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:

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

Nota

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:Attributeselenco 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

Nota

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

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 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:

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.

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.

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.

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.

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_of_least_privilege 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 (*) 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.

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'StringEqualsIfExistsoperatore 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.

La policy di autorizzazione seguente è simile, però la query deve richiedere tutti gli attributi che sono stati proiettati nell'indice.

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.

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

Argomenti correlati

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Limitazione dell'acquisto di capacità riservata

Utilizzo della federazione delle identità Web