transp_anon – динамическое маскирование через Access Methods в PostgreSQL

Значимый прорыв формирует отрасль ИИ: i_rozhnev 31 минуту назад transp_anon – динамическое маскирование через Access Methods в PostgreSQL 6 мин 1. 6K Блог компании Тантор Лабс Базы данных * PostgreSQL * Обзор Меня зовут Илья Рожнёв, я разработчик СУБД в ”Тантор Лабс”. Мы могли с вами видеться на московском PG BootCamp Russia 2026 где я выступал с докладом про OLAP-нагрузки на реплике.

Это моя первая статья на Хабре, поэтому буду рад вашему фидбеку. ВступлениеEnterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к базе данных аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. В прошлой статье, Александр Дубов рассказывал о pg_anon – инструменте статического маскирования данных, которое отлично подходит для случаев, когда таблица копируется полностью.

Технические детали

Но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое, и сегодня я расскажу об инструменте transp_anon, который входит в новый релиз СУБД Tantor Postgres 18. Вообще, поскольку в ванильном PostgreSQL «из коробки» полноценного динамического маскирования на уровне ядра нет, задачу приходится решать с помощью расширений или сторонних инструментов, таких как:pg_anonymizepostgresql_anonymizerдругие инструменты маскирования, например, через прокси.

Нам понравилось решение pg_anonymize. Мы активно использовали и развивали этот инструмент, сделав свой форк transp_anon, но в процессе эксплуатации мы столкнулись с архитектурными ограничениями оригинального расширения, которое приводило к утечкам данных. Чтобы понять, из-за чего маскируемые данные могли попасть “не в те руки”, пришлось разобраться в том, как работала старая архитектура.

Как работала legacy-архитектура transp_anonРазработчик схемы базы задает для колонок таблицы правила маскировки. Для обычных пользователей данные не меняются, но если к базе подключился пользователь с меткой MASKED, расширение включается в работу. -- создадим маскируемую роль CREATE ROLE skynet LOGIN; GRANT SELECT ON TABLE people TO skynet; SECURITY LABEL FOR transp_anon ON ROLE skynet IS 'MASKED'; -- добавим правила маскировки для колонок SECURITY LABEL FOR transp_anon ON COLUMN people.

Отраслевые последствия

lastname IS 'MASKED WITH FUNCTION transp_anon. fake_last_name()'; SECURITY LABEL FOR transp_anon ON COLUMN people. phone IS 'MASKED WITH FUNCTION transp_anon.

partial(phone,2,$$******$$,2)'; --меняем роль на маскируемую ALTER ROLE skynet; select * from people; id | firstname | lastname | phone ----+-----------+-----------+------------ T1 | Sarah | Stranahan | 06******11 Здесь магия маскировки работает через подход, называемый Query Rewriting. На этапе post_parse_analyze расширение “смотрело” на сам запрос и модифицировало его, подменяя прямой доступ к колонкам, на вызов функций. В псевдокоде это выглядит так:-- оригинальный запрос, правила маскировки мы создали выше SELECT * FROM people; -- после того как transp_anon обработал запрос SELECT id, firstname, transp_anon.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.