Cenários de movimentação de dados do pg_columnmask do Aurora PostgreSQL
O comportamento de pg_columnmask varia nas diferentes operações de movimentação de dados, dependendo se a operação ocorre na camada de armazenamento, lógica ou de aplicação. As operações em nível de armazenamento (como clonagem) se comportam de maneira diferente das operações lógicas (como pg_dump) e das operações em nível de aplicação (como consultas FDW). Esta seção descreve o comportamento de mascaramento em cenários comuns, incluindo replicação, backups, exportações e migrações, e explica as implicações de segurança de cada um.
Tópicos
Aurora Global Database e réplicas de leitura
As políticas pg_columnmask do Aurora são armazenadas em tabelas do sistema de banco de dados dentro do volume do cluster. Todas as réplicas acessam as mesmas políticas e exibem resultados consistentemente mascarados. Para implantações do Aurora Global Database, as políticas pg_columnmask são replicadas para as Regiões da AWS secundárias junto com outras tabelas do sistema de banco de dados, garantindo proteção de dados consistente em todas as regiões. Durante os cenários de failover, todas as políticas pg_columnmask permanecem intactas e funcionais.
Clone de banco de dados e restauração de snapshot
As operações de clone rápido e restauração de snapshot do Aurora preservam todas as políticas pg_columnmask, perfis e configurações como parte das tabelas do sistema de banco de dados. O banco de dados clonado ou restaurado herda todas as políticas existentes do cluster de origem. Após a clonagem ou a restauração, cada cluster de banco de dados mantém políticas pg_columnmask independentes.
Replicação lógica
Durante a sincronização inicial, a replicação lógica usa operações SQL COPY padrão e as políticas pg_columnmask são aplicadas com base nas permissões do usuário de replicação. Durante o CDC (captura de dados de alteração) em andamento, as políticas de mascaramento não são aplicadas e os dados não mascarados são replicados por meio de registros do WAL. Usuários com privilégios pg_create_subscription podem exfiltrar dados não mascarados configurando a replicação em um sistema que eles controlem.
Implantações azuis/verdes
Durante a restauração do snapshot, as políticas pg_columnmask são incluídas automaticamente. O ambiente verde começa com uma cópia idêntica de todas as políticas do ambiente azul. Durante a replicação do azul para o verde, os dados não são mascarados. Alterações subsequentes da política de mascaramento (comandos DDL) no cluster azul não são replicadas para o cluster verde e invalidam as implantações azul/verde do RDS.
Fluxos ETL zero e CDC
A replicação de dados não é afetada pelas políticas pg_columnmask. O ETL zero comporta a replicação de DDL, mas não replica as políticas de RLS nem pg_columnmask. Nenhuma política de mascaramento é aplicada aos dados replicados em ETL zero.
AWS Database Migration Service
A sincronização inicial de dados é mascarada ou não mascarada com base no usuário selecionado para a tarefa do DMS. Os dados do CDC nunca são mascarados. Embora as políticas de RLS internas relacionadas a pg_columnmask possam ser migradas, elas não funcionarão em destinos não habilitados para pg_columnmask.
Exportações de dados
A pg_columnmask trata as exportações como qualquer outra operação de consulta: o mascaramento é aplicado com base nas permissões do usuário em execução. Isso se aplica a comandos SQL, como COPY, SELECT INTO, CREATE TABLE AS e à funcionalidade de exportação do S3 do Aurora PostgreSQL.
nota
Quando usuários mascarados exportam dados, os arquivos resultantes contêm valores mascarados que podem violar as restrições do banco de dados quando restaurados.
Visualizações e visões materializadas
Lembre-se das seguintes considerações ao utilizar visualizações:
Visualizações regulares: sempre usam a semântica
INVOKER. As políticas de mascaramento do usuário atual se aplicam ao consultar a visualização, independentemente de quem a criou.Visões materializadas: quando atualizadas, as políticas de mascaramento do proprietário da visão materializada se aplicam, não as políticas do usuário que realiza a atualização. Se o proprietário tiver políticas de mascaramento, a visão materializada sempre conterá dados mascarados.
Despejo e restauração de dados
pg_dump funciona como um usuário regular do banco de dados e aplica políticas de mascaramento com base nas permissões do usuário conectado. Se um usuário mascarado realizar um despejo, o arquivo de backup conterá dados mascarados. As politicas pg_columnmask são incluídas no despejo como parte do esquema do banco de dados. A restauração bem-sucedida exige que todos os perfis referidos existam no banco de dados de destino e que o destino tenha a extensão pg_columnmask instalada.
nota
A partir do PostgreSQL 18, pg_dump comporta a opção —no-policies que exclui tanto a segurança por linha (RLS) e as políticas de mascaramento pg_columnmask dos despejos do banco de dados. Para acessar mais informações, consulte pg_dump
Wrapper de dados externos
Ao usar wrappers de dados externos, as políticas de mascaramento em tabelas remotas são aplicadas com base nas permissões do usuário associado no servidor de origem, não nas permissões do usuário de consulta local. Embora você possa acessar dados remotos mascarados por meio do FDW, não pode criar políticas de DDM ou RLS diretamente em tabelas externas em seu banco de dados local.
