Escenarios de movimiento de datos pg_columnmask de Aurora PostgreSQL
El comportamiento pg_columnmask varía según las distintas operaciones de movimiento de datos en función de si la operación se produce en la capa de almacenamiento, lógica o aplicación. Las operaciones por almacenamiento (como la clonación) se comportan de manera diferente a las operaciones lógicas (como pg_dump) y las operaciones por aplicación (como las consultas de FDW). En esta sección se describe el comportamiento de enmascaramiento en escenarios comunes, como la replicación, las copias de seguridad, las exportaciones y las migraciones, y se explican las implicaciones de seguridad de cada uno de ellos.
Temas
Base de datos global de Aurora y réplicas de lectura
Las políticas de pg_columnmask de Aurora se almacenan en tablas del sistema de bases de datos dentro del volumen del clúster. Todas las réplicas acceden a las mismas políticas y devuelven resultados enmascarados de forma coherente. Para las implementaciones de Aurora Global Database, las políticas de pg_columnmask se replican en Regiones de AWS secundarias junto con otras tablas del sistema de bases de datos, lo que garantiza una protección de datos coherente en todas las regiones. Durante los escenarios de conmutación por error, todas las políticas de pg_columnmask permanecen intactas y funcionales.
Restauración de copias e instantáneas de bases de datos
Las operaciones de restauración de instantáneas y clonación rápida de Aurora conservan todas las políticas de pg_columnmask, roles y configuraciones como parte de las tablas del sistema de bases de datos. La base de datos clonada o restaurada hereda todas las políticas existentes del clúster de origen. Tras la clonación o la restauración, cada clúster de base de datos mantiene políticas de pg_columnmask independientes.
Replicación lógica
Durante la sincronización inicial, la replicación lógica utiliza operaciones estándar de SQL COPY y las políticas de pg_columnmask se aplican en función de los permisos del usuario de la replicación. Durante el CDC continuo (captura de datos de cambio), no se aplican políticas de enmascaramiento y los datos desenmascarados se replican a través de los registros de WAL. Los usuarios con privilegios de pg_create_subscription pueden filtrar datos desenmascarados configurando la replicación en un sistema que controlen.
Implementaciones azul/verde
Durante la restauración de las instantáneas, las políticas de pg_columnmask se incluyen automáticamente. El entorno verde comienza con una copia idéntica de todas las políticas del entorno azul. Durante la replicación, de azul a verde, los datos no se enmascaran. Los cambios posteriores en la política de enmascaramiento (comandos DDL) en el clúster azul no se replican en el clúster verde e invalidan las implementaciones azul/verde de RDS.
Transmisiones zero-ETL y CDC
La replicación de datos no se ve afectada por las políticas de pg_columnmask. Zero-ETL admite la replicación de DDL, pero no replica pg_columnmask ni las políticas de RLS. No se aplican políticas de enmascaramiento a los datos replicados en Zero-ETL.
AWS Database Migration Service
La sincronización de datos inicial se enmascara o desenmascara en función del usuario seleccionado para la tarea de DMS. Los datos de CDC siempre están desenmascarados. Aunque las políticas de RLS internas relacionadas con pg_columnmask se pueden migrar, no funcionarán en destinos non-pg_columnmask-enabled.
Exportaciones de datos
pg_columnmask trata las exportaciones como cualquier otra operación de consulta: el enmascaramiento se aplica en función de los permisos del usuario ejecutor. Esto se aplica a los comandos de SQL como COPY, SELECT INTO, CREATE TABLE AS y a la funcionalidad de exportación de S3 de Aurora PostgreSQL.
nota
Cuando los usuarios enmascarados exportan datos, los archivos resultantes contienen valores enmascarados que, al restaurarse, pueden infringir las restricciones de la base de datos.
Vistas y vistas materializadas
Tenga en cuenta las siguientes consideraciones al utilizar las vistas:
Vistas normales: utilice siempre la semántica de
INVOKER. Las políticas de enmascaramiento del usuario actual se aplican al consultar la vista, independientemente de quién la haya creado.Vistas materializadas: cuando se actualizan, se aplican las políticas de enmascaramiento del propietario de la vista materializada, no las políticas del usuario que realiza la actualización. Si el propietario tiene políticas de enmascaramiento, la vista materializada siempre contiene datos enmascarados.
Volcado y restauración de datos
pg_dump funciona como un usuario normal de la base de datos y aplica políticas de enmascaramiento en función de los permisos del usuario que se conecta. Si un usuario enmascarado realiza un volcado, el archivo de copia de seguridad contiene datos enmascarados. Las políticas de pg_columnmask se incluyen en el volcado como parte del esquema de la base de datos. La restauración correcta requiere que todos los roles a los que se hace referencia estén en la base de datos de destino y que el destino tenga instalada la extensión pg_columnmask.
nota
A partir de PostgreSQL 18, pg_dump admite la opción —no-policies que excluye la seguridad por fila (RLS) y políticas de enmascaramiento de pg_columnmask de los volcados de bases de datos. Para obtener más información, consulte pg_dump
Contenedor de datos externos
Cuando se utilizan contenedores de datos externos, las políticas de enmascaramiento en las tablas remotas se aplican en función de los permisos del usuario asignado en el servidor de origen, no de los permisos del usuario local que consulta, y aunque puede acceder a los datos remotos enmascarados mediante FDW, no puede crear políticas de DDM o RLS directamente en las tablas externas de la base de datos local.
