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à.
Scenari di spostamento dei dati in Aurora PostgreSQL pg_columnmask
pg_columnmaskil comportamento varia tra le diverse operazioni di spostamento dei dati a seconda che l'operazione avvenga a livello di archiviazione, logico o applicativo. Le operazioni a livello di storage (come la clonazione) si comportano in modo diverso dalle operazioni logiche (ad esempiopg_dump) e dalle operazioni a livello di applicazione (come le query FDW). Questa sezione descrive il comportamento di mascheramento per scenari comuni, tra cui replica, backup, esportazioni e migrazioni, e spiega le implicazioni di sicurezza per ciascuno di essi.
Argomenti
Database globale Aurora e repliche di lettura
Le pg_columnmask policy Aurora sono archiviate nelle tabelle del sistema di database all'interno del volume del cluster. Tutte le repliche accedono alle stesse policy e restituiscono risultati mascherati in modo coerente. Per le implementazioni di Aurora Global Database, pg_columnmask le policy vengono replicate su tabelle secondarie Regioni AWS insieme ad altre tabelle di sistema di database, garantendo una protezione dei dati coerente in tutte le regioni. Durante gli scenari di failover, tutte le pg_columnmask policy rimangono intatte e funzionali.
Duplicazione del database e ripristino delle istantanee
Le operazioni di clonazione rapida e ripristino delle istantanee di Aurora preservano tutte le pg_columnmask policy, i ruoli e le configurazioni come parte delle tabelle del sistema di database. Il database clonato o ripristinato eredita tutte le politiche esistenti dal cluster di origine. Dopo la clonazione o il ripristino, ogni cluster di database mantiene politiche indipendenti. pg_columnmask
Replica logica
Durante la sincronizzazione iniziale, la replica logica utilizza operazioni SQL COPY standard e le pg_columnmask policy vengono applicate in base alle autorizzazioni dell'utente di replica. Durante il CDC (change data capture) in corso, le politiche di mascheramento non vengono applicate e i dati non mascherati vengono replicati tramite i record WAL. Gli utenti con pg_create_subscription privilegi possono potenzialmente esfiltrare i dati non mascherati impostando la replica su un sistema che controllano.
Implementazioni blu/verdi
Durante il ripristino delle istantanee, pg_columnmask le policy vengono incluse automaticamente. L'ambiente verde inizia con una copia identica di tutte le politiche dell'ambiente blu. Durante la replica dal blu al verde, i dati non vengono mascherati. Le successive modifiche alle policy di mascheramento (comandi DDL) sul cluster blu non vengono replicate sul cluster verde e invalidano le distribuzioni RDS. blue/green
Stream Zero-ETL e CDC
La replica dei dati non è influenzata dalle policy. pg_columnmask Zero-ETL supporta la replica DDL ma non replica o le policy RLS. pg_columnmask Nessuna policy di mascheramento viene applicata ai dati replicati in Zero-ETL.
AWS Database Migration Service
La sincronizzazione iniziale dei dati viene mascherata o smascherata in base all'utente selezionato per l'attività DMS. I dati CDC vengono sempre smascherati. Sebbene le pg_columnmask relative politiche RLS interne possano essere migrate, non funzioneranno su target non abilitati per pg_columnmask.
Esportazioni di dati
pg_columnmasktratta le esportazioni come qualsiasi altra operazione di interrogazione: il mascheramento viene applicato in base alle autorizzazioni dell'utente che esegue l'esecuzione. Questo vale per comandi SQL come COPY, SELECT INTO, CREATE TABLE AS e la funzionalità di esportazione S3 di Aurora PostgreSQL.
Nota
Quando gli utenti mascherati esportano dati, i file risultanti contengono valori mascherati che possono violare i vincoli del database una volta ripristinati.
Viste e viste materializzate
Tieni a mente le seguenti considerazioni quando utilizzi le viste:
Visualizzazioni normali: utilizza sempre la
INVOKERsemantica. Le politiche di mascheramento dell'utente corrente si applicano quando si esegue una query sulla vista, indipendentemente da chi ha creato la vista.Viste materializzate: quando vengono aggiornate, si applicano le politiche di mascheramento del proprietario della vista materializzata, non le politiche dell'utente che esegue l'aggiornamento. Se il proprietario ha delle politiche di mascheramento, la vista materializzata contiene sempre dati mascherati.
Dump e ripristino dei dati
pg_dumpfunziona come un normale utente del database e applica politiche di mascheramento basate sulle autorizzazioni dell'utente che si connette. Se un utente mascherato esegue un dump, il file di backup contiene dati mascherati. pg_columnmaskle politiche sono incluse nel dump come parte dello schema del database. Il ripristino riuscito richiede che tutti i ruoli di riferimento siano presenti nel database di destinazione e che sulla destinazione sia installata l'pg_columnmaskestensione.
Nota
A partire da PostgreSQL 18pg_dump, supporta l'opzione che esclude sia —no-policies la Row Level Security (RLS) che le policy di mascheramento dai dump del database. pg_columnmask Per ulteriori informazioni, consulta pg_dump.
Wrapper di dati esterni
Quando si utilizzano wrapper di dati esterni, i criteri di mascheramento sulle tabelle remote vengono applicati in base alle autorizzazioni dell'utente mappato sul server di origine, non alle autorizzazioni dell'utente che esegue le query locali e, sebbene sia possibile accedere ai dati remoti mascherati tramite FDW, non è possibile creare politiche DDM o RLS direttamente su tabelle esterne nel database locale.
