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

Sicurezza per tabelle globali DynamoDB

Le repliche delle tabelle globali sono tabelle DynamoDB, quindi utilizzi gli stessi metodi per controllare l'accesso alle repliche utilizzati per le tabelle a regione singola, incluse le politiche di identità AWS Identity and Access Management (IAM) e le politiche basate sulle risorse. Questo argomento spiega come proteggere le tabelle globali multi-account di DynamoDB utilizzando le autorizzazioni IAM e la crittografia (). AWS Key Management Service AWS KMS Scopri le politiche basate sulle risorse e i ruoli collegati ai servizi (SLR) che consentono la replica e il ridimensionamento automatico tra più regioni, nonché le autorizzazioni IAM necessarie per creare, aggiornare ed eliminare tabelle globali, per tabelle MREC (Multi-region Eventual Consistency). Scopri anche le chiavi di crittografia per gestire in modo sicuro la replica tra regioni. AWS KMS

Fornisce informazioni dettagliate sulle politiche e le autorizzazioni basate sulle risorse necessarie per stabilire la replica tra account e tabelle tra regioni. La comprensione di questo modello di sicurezza è fondamentale per i clienti che devono implementare soluzioni di replica dei dati sicure e su più account.

Autorizzazione principale del servizio per la replica

Le tabelle globali multi-account di DynamoDB utilizzano un approccio di autorizzazione distinto perché la replica viene eseguita oltre i confini degli account. Questo viene fatto utilizzando il principio del servizio di replica di DynamoDB:. replication.dynamodb.amazonaws.com Ogni account partecipante deve consentire esplicitamente tale principale nella politica delle risorse della tabella di replica, assegnandogli autorizzazioni che possono essere vincolate a repliche specifiche in base alle condizioni del contesto di origine su chiavi come aws:SourceAccountaws:SourceArn, ecc.: vedi AWS le chiavi di condizione globali per maggiori dettagli. Le autorizzazioni sono bidirezionali, il che significa che tutte le repliche devono concedersi esplicitamente le autorizzazioni reciproche prima che la replica possa essere stabilita su una particolare coppia di repliche.

Le seguenti autorizzazioni principali del servizio sono essenziali per la replica su più account:

Ogni replica deve concedere le autorizzazioni di cui sopra a tutte le altre repliche e a se stessa, ovvero le condizioni del contesto di origine devono includere il set completo di repliche che comprende la tabella globale. Queste autorizzazioni vengono verificate per ogni nuova replica quando viene aggiunta a una tabella globale con più account. Ciò verifica che le operazioni di replica vengano eseguite solo dal servizio DynamoDB autorizzato e solo tra le tabelle previste.

Service-linked ruoli per tabelle globali con più account

Le tabelle globali multi-account DynamoDB replicano le impostazioni su tutte le repliche in modo che ogni replica sia configurata in modo identico con un throughput costante e offra un'esperienza di failover senza interruzioni. La replica delle impostazioni è controllata tramite l'ReplicateSettingsautorizzazione del responsabile del servizio, ma ci affidiamo anche ai ruoli collegati ai servizi (SLR) per gestire determinate funzionalità di replica tra più account e di scalabilità automatica e di scalabilità automatica. Questi ruoli vengono impostati una sola volta per account. AWS Una volta creati, gli stessi ruoli sono validi per tutte le tabelle globali del tuo account. Per ulteriori informazioni sui ruoli collegati ai servizi, consulta Using service-linked roles nella IAM User Guide.

Ruolo collegato al servizio di gestione delle impostazioni

Amazon DynamoDB crea automaticamente il ruolo AWSServiceRoleForDynamoDBGlobalTableSettingsManagement collegato al servizio (SLR) quando crei la prima replica globale della tabella multiaccount nell'account. Questo ruolo gestisce per te la replica delle impostazioni tra più account e più regioni.

Quando applichi politiche basate sulle risorse alle repliche, conferma di non negare nessuna delle autorizzazioni definite nell'entità to the SLR, poiché ciò potrebbe interferire con la AWSServiceRoleForDynamoDBGlobalTableSettingsManagement gestione delle impostazioni e compromettere la replica se il throughput non corrisponde tra le repliche o i GSI. Se si negano le autorizzazioni SLR richieste, la replica da e verso le repliche interessate potrebbe interrompersi e lo stato della tabella delle repliche cambierà in. REPLICATION_NOT_AUTHORIZED Per le tabelle globali con più account, se una replica rimane nello REPLICATION_NOT_AUTHORIZED stato per più di 20 ore, la replica viene convertita irreversibilmente in una tabella DynamoDB a regione singola. La SLR dispone delle seguenti autorizzazioni:

Dimensionamento automatico del ruolo collegato al servizio

Quando si configura una tabella globale per la modalità di capacità assegnata, è necessario configurare il ridimensionamento automatico per la tabella globale. Il ridimensionamento automatico di DynamoDB utilizza il servizio AWS Application Auto Scaling per regolare dinamicamente la capacità di throughput assegnata sulle repliche globali delle tabelle. Il servizio Application Auto Scaling crea un ruolo collegato ai servizi (SLR) denominato _DynamoDBTable. AWSServiceRoleForApplicationAutoScaling Questo ruolo collegato al servizio viene creato automaticamente nel tuo AWS account quando configuri per la prima volta il ridimensionamento automatico per una tabella DynamoDB. Consente ad Application Auto Scaling di gestire la capacità della tabella assegnata e creare allarmi. CloudWatch

Quando si applicano policy basate sulle risorse alle repliche, verificate di non negare alcuna autorizzazione definita nel principio di Application Auto Scaling SLR, poiché ciò AWSApplicationAutoscalingDynamoDBTablePolicy interromperebbe la funzionalità di ridimensionamento automatico.

Come utilizzano le tabelle globali AWS IAM

Le sezioni seguenti descrivono le autorizzazioni richieste per le diverse operazioni globali sulle tabelle e forniscono esempi di policy per aiutarvi a configurare l'accesso appropriato per utenti e applicazioni.

Di seguito sono riportati gli argomenti dettagliati trattati nelle sezioni seguenti:

Creazione di tabelle globali e aggiunta di repliche

Autorizzazioni per la creazione di tabelle globali

Quando una nuova replica viene aggiunta a una tabella regionale per formare una tabella globale con più account o a una tabella globale con più account esistente, il responsabile IAM che esegue l'azione deve essere autorizzato da tutti i membri esistenti. Affinché l'aggiunta della replica abbia successo, tutti i membri esistenti devono fornire le seguenti autorizzazioni nella loro politica di tabella:

Questo controllo preciso consente solo agli account autorizzati di partecipare alla configurazione globale della tabella.

Esempi di politiche IAM per la creazione di tabelle globali

Aggiornamento di una tabella globale con più account

Per modificare le impostazioni di replica di una tabella globale esistente utilizzando l' UpdateTable API, è necessaria la seguente autorizzazione sulla risorsa della tabella nella regione in cui si sta effettuando la chiamata API: dynamodb:UpdateTable

Puoi inoltre aggiornare altre configurazioni globali delle tabelle, come le politiche di ridimensionamento automatico e le impostazioni Time to Live. Le seguenti autorizzazioni sono necessarie per queste operazioni di aggiornamento aggiuntive:

Per aggiornare le impostazioni Time to Live con l'UpdateTimeToLiveAPI, è necessario disporre della seguente autorizzazione sulla risorsa della tabella in tutte le regioni contenenti repliche: dynamodb:UpdateTimeToLive

Per aggiornare una politica di ridimensionamento automatico delle repliche con l'UpdateTableReplicaAutoScalingAPI, devi disporre delle seguenti autorizzazioni sulla risorsa della tabella in tutte le regioni che contengono repliche:

Eliminazione delle tabelle globali e rimozione delle repliche

Per eliminare una tabella globale, è necessario rimuovere tutte le repliche. A differenza di Global Table con lo stesso account, non è possibile utilizzare UpdateTable per eliminare una tabella di replica in una regione remota e ogni replica deve essere eliminata tramite l'DeleteTableAPI dall'account che la controlla.

Autorizzazioni per l'eliminazione delle tabelle globali e la rimozione delle repliche

Le seguenti autorizzazioni sono necessarie sia per rimuovere singole repliche sia per eliminare completamente le tabelle globali. L'eliminazione di una configurazione di tabella globale rimuove solo la relazione di replica tra tabelle in regioni diverse. Non elimina la tabella DynamoDB sottostante nell'ultima regione rimanente. La tabella nell'ultima regione continua a esistere come tabella DynamoDB standard con gli stessi dati e impostazioni.

Sono necessarie le seguenti autorizzazioni sulla risorsa della tabella in ogni regione in cui si rimuove una replica:

Come utilizzano le tabelle globali AWS KMS

Come tutte le tabelle DynamoDB, le repliche globali delle tabelle crittografano sempre i dati inattivi utilizzando le chiavi di crittografia archiviate in AWS Key Management Service ().AWS KMS

Multi-account le tabelle globali che utilizzano CMK richiedono che la politica delle chiavi di ciascuna replica conceda le autorizzazioni al responsabile del servizio di replica DynamoDB (replication.dynamodb.amazonaws.com) per accedere alla chiave per la replica e la gestione delle impostazioni. Sono richieste le seguenti autorizzazioni:

Importante

DynamoDB richiede l’accesso alla chiave di crittografia della replica per eliminare una replica. Se desideri disabilitare o eliminare una chiave gestita dal cliente utilizzata per crittografare una replica perché stai eliminando la replica, devi prima eliminare la replica, attendere che la tabella venga rimossa dal gruppo di replica chiamando describe in una delle altre repliche, quindi disabilitare o eliminare la chiave.

Se disabiliti o revochi l'accesso di DynamoDB a una chiave gestita dal cliente utilizzata per crittografare una replica, la replica da e verso la replica si interromperà e lo stato della replica cambierà inINACCESSIBLE_ENCRYPTION_CREDENTIALS. Se una replica rimane nello INACCESSIBLE_ENCRYPTION_CREDENTIALS stato per più di 20 ore, viene convertita irreversibilmente in una tabella DynamoDB a regione singola.

Esempio AWS KMS policy

La AWS KMS policy consente a DynamoDB di accedere a entrambe AWS KMS le chiavi per la replica tra le repliche A e B. AWS KMS Le chiavi allegate alla replica DynamoDB in ciascun account devono essere aggiornate con la seguente policy:

JSON

{
    "Version":"2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": { "Service": "replication.dynamodb.amazonaws.com" },
        "Action": [
            "kms:Decrypt",
            "kms:ReEncrypt*",
            "kms:GenerateDataKey*",
            "kms:DescribeKey"
        ],
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "aws:SourceAccount": [ "111122223333", "444455556666" ],
                "aws:SourceArn": [
                    "arn:aws:dynamodb:ap-east-1:111122223333:table/ReplicaA",
                    "arn:aws:dynamodb:eu-south-1:444455556666:table/ReplicaB"
                ]
            }
        }
      }
   ]
 }