PostgreSQL Anonymizer 3.2 corrige problemas de seguridad y bloquea el enmascaramiento ejecutado como superusuario. Una actualización debe revisar los roles de los procesos existentes, sus copias de seguridad y sus resultados, en lugar de neutralizar la protección para conservar los scripts antiguos.
Fechar correctamente el anuncio e identificar el componente
El comunicado de PostgreSQL Anonymizer 3.2 está fechado el 4 de septiembre de 2026; PostgreSQL.org lo volvió a publicar el 9 de septiembre. El evento es el anuncio del 4 de septiembre, sin suponer una hora de disponibilidad. PostgreSQL Anonymizer es una extensión: sus correcciones y condiciones previas no describen indistintamente todo PostgreSQL. [anuncio de PostgreSQL.org]
La versión 3.2 anuncia el bloqueo del enmascaramiento ejecutado por un superusuario y la migración progresiva de pseudo_* a seeded_*, según el anuncio del editor.
Un informe independiente describe dos vías distintas de elevación de privilegios reproducidas en 3.1.3: la primera afecta al propietario de una tabla sin un segundo actor privilegiado; la segunda exige que un operador privilegiado importe un archivo de reglas cuyo contenido haya sido influido por un atacante. Estas condiciones previas no permiten afirmar que exista una explotación activa ni establecer todas las versiones afectadas. [informe 665]
Inventariar los procesos y los roles
Un rol es una identidad a la que PostgreSQL asigna permisos; un superusuario dispone de privilegios que superan los de un rol de aplicación corriente. La seudonimización sustituye un valor por otro para limitar su identificación directa. Su determinismo significa que, con los mismos parámetros, una misma entrada puede producir una misma salida; una colisión es el caso en que entradas distintas producen el mismo valor. La configuración regional es el parámetro de idioma y región que influye en ciertos formatos. El enmascaramiento estático modifica datos, la réplica produce una copia y la exportación produce un conjunto de datos externo: estos modos no se califican con los mismos derechos.
Empiece documentando la versión de la extensión, el modo de enmascaramiento y la identidad efectiva, sin ejecutar ningún proceso ni modificar una base de datos de producción. No desactive anon.nosuperuser para sortear la nueva protección.
| Entorno | Versión | Modo | Rol efectivo | Propietario | Operación | Permiso por confirmar | Prueba |
|---|---|---|---|---|---|---|---|
| Por completar | Por verificar | Estático, réplica o exportación | Por verificar | Por designar | Por describir | Por confirmar | Por adjuntar |
Calificar un rol dedicado en pruebas
Los permisos mínimos se deducen de las funciones que realmente se utilizan y de la documentación de la versión de destino; no existe un comando universal de asignación de derechos (GRANT) adecuado para todos los procesos. Un plan propuesto, no ejecutado, comienza con una restauración de prueba autorizada y datos sintéticos. Verifica la ejecución, los errores, la copia de seguridad y la recuperación, y conserva después una vuelta atrás basada en una restauración validada, no en desactivar una protección ni en un cambio improvisado.
Este plan también incluye relaciones, valores nulos, colisiones y repetición: compruebe que una relación siga siendo utilizable, que un valor nulo conserve el comportamiento esperado, que las colisiones se midan y que los resultados repetidos correspondan a la propiedad buscada. El determinismo no garantiza el anonimato. [documentación de las funciones]
Ejemplo exclusivamente sintético: tres personas ficticias P01, P02 y P03 tienen respectivamente Personne_A, Personne_B y Personne_A en un campo de nombre; P03 tiene un valor opcional nulo. Dos pedidos ficticios C01 y C02 están vinculados a P01 y P02. La configuración regional, los mismos parámetros y el mismo valor inicial («semilla») se registran para las repeticiones. Ninguno de estos registros es real.
| Caso | Resultado esperado | Prueba |
|---|---|---|
| Relaciones C01→P01 y C02→P02 | Referencias coherentes después del proceso | NO EJECUTADO |
| Valor nulo P03 | Comportamiento documentado y conservado | NO EJECUTADO |
| Colisión Personne_A / Personne_B | Colisión medida, no supuesta ausente | NO EJECUTADO |
| Repetición con la misma semilla y parámetros | Resultado comparado para el determinismo deseado | NO EJECUTADO |
| Nombre de función antiguo y nuevo | Comparados sin imponer la igualdad de valores | NO EJECUTADO |
| Restricciones del esquema | Resultado controlado | NO EJECUTADO |
Tratar la corrección como un cambio controlado
La nueva familia seeded_* sustituye progresivamente a pseudo_*, que se conservan por compatibilidad en 3.2, pero están obsoletas y destinadas a retirarse posteriormente. No debe suponerse ninguna correspondencia de valores idénticos. Compruebe la configuración regional, las funciones disponibles y los resultados esperados en la versión de destino. [anuncio de la versión 3.2]
Plan propuesto y no ejecutado: inventario; copia de seguridad de la configuración, los roles y los datos sintéticos; restauración aislada; validación de un rol dedicado; pruebas; decisión de detenerse o cambiar; vuelta atrás probada mediante restauración. No se trata de volver a ciegas a una versión anterior de la extensión. Para el marco de continuidad y recuperación, consulte el plan de continuidad y recuperación.
El propietario del proceso define los resultados esperados; el administrador valida los derechos y la restauración; el equipo que utiliza los datos confirma que las relaciones y restricciones siguen siendo utilizables. Un fallo de restauración, un permiso inexplicado o una incoherencia de datos suspende el cambio. Este pequeño conjunto permite verificar el método: no mide el riesgo global de colisión ni la resistencia a la reidentificación con datos reales. Sigue siendo necesario consultar la documentación correspondiente a la versión instalada; las páginas latest pueden cambiar.