PostgreSQL Anonymizer: правила маскирования в схеме и разные режимы их применения

Security labels сохраняют политику рядом с объектами базы. MASKED-роль получает изменённую выдачу, а static-функции меняют хранимые данные. При Replica Masking логическая репликация передаёт оригинальные данные подписчику, и маски применяются там: канал нуждается в защите, журналы могут содержать оригинал, а привилегированные лица могут отключить обработку. Wrappers объявляют внешние таблицы и накладывают правила на их столбцы.

Описанное назначение — anonymization by design: разработчики приложения определяют правила маскирования непосредственно в схеме, где известна семантика модели данных. Это цель проекта, без автоматического подтверждения правового соответствия или гарантии отсутствия утечек.

Документация показывает CI-тесты на подставных данных, аналитику с сохранением выбранных показателей, маскированные dumps, обновляемую реплику и обработку CSV через foreign table. /dump.sh принимает только plain SQL, тогда как обычный pg_dump от masked-роли допускает custom format. Это отдельные пути; ограничения одного не перенесены на другой.

Отделить определение маски от способа её применения: закрепить правила в схеме и выбирать режим выдачи, разрушительной замены, экспорта или репликации под задачу. Разные режимы имеют разные границы доступа и целостности, поэтому одна политика не превращает их в одинаковые по безопасности операции.

Источник прямо называет трудность поиска прямых и косвенных идентификаторов в модели и выбора способа скрытия. Также описана потребность иметь копию production-базы, которая одновременно маскирована и обновляется; это эксплуатационная задача, без доказанного рыночного спроса.