Как вы могли заметить, определения правил маскирования заключаются в одинарные кавычки. Поэтому, если в правиле маскирования нужно записать строку, экранируйте её символами доллара:

SECURITY LABEL FOR anon ON COLUMN player.name
  IS 'MASKED WITH VALUE $$CONFIDENTIAL$$';

Для отображения всех правил маскирования, объявленных в текущей базе данных, используйте anon.pg_masking_rules:

SELECT * FROM anon.pg_masking_rules;

Подробную информацию об ошибках в правилах маскирования возможно получить, задав для client_min_messages значение DEBUG.

postgres=# SET client_min_messages=DEBUG;
postgres=# SELECT anon.anonymize_database();

DEBUG:  Anonymize table public.bar with firstname = anon.fake_first_name()
DEBUG:  Anonymize table public.foo with id = NULL
ERROR:  Cannot mask a "NOT NULL" column with a NULL value
HINT:  If privacy_by_design is enabled, add a default value to the column
CONTEXT:  PL/pgSQL function anon.anonymize_table(regclass) line 47 at RAISE
SQL function "anonymize_database" statement 1

Вы легко можете удалить правило маскирования следующим образом:

SECURITY LABEL FOR anon ON COLUMN player.name IS NULL;

Чтобы удалить все правила сразу, используйте оператор:

SELECT anon.remove_masks_for_all_columns();

Самый быстрый и безопасный способ анонимизировать данные — удалить их.

Во многих случаях лучший способ скрыть содержимое столбца — заменить все значения одним статическим значением.

Например, вы можете заменить весь столбец словом CONFIDENTIAL, как указано ниже:

SECURITY LABEL FOR anon
  ON COLUMN users.address
  IS 'MASKED WITH VALUE $$CONFIDENTIAL$$';

Этот способ также называется Отклонение. В его основе лежит «сдвиг» дат и числовых значений. Например, после применения отклонения +/- 10% к столбцу зарплаты набор данных не потеряет смысл.

Данное расширение предоставляет большой выбор функций для генерации абсолютно случайных данных:

CREATE TYPE card AS ENUM ('visa', 'mastercard', ‘amex’);
SELECT anon.random_in_enum(NULL::CARD);
 random_in_enum
----------------
 mastercard

CREATE TABLE customer (
  id INT,
  ...
  credit_card CARD
);

SECURITY LABEL FOR anon ON COLUMN customer.creditcard
IS 'MASKED WITH FUNCTION anon.random_in_enum(creditcard)'

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

Предоставляются следующие функции фальсификации:

Для столбцов типа text и varchar вы можете использовать классический генератор Lorem Ipsum:

Генерация фальсифицированных данных — сложная тема. Представленные здесь функции ограничены базовым вариантом использования. Чтобы узнать о более продвинутых методах фальсификации, в частности, если вам нужны локализованные фальсифицированные данные, взгляните на PostgreSQL Faker, расширение, основанное на известной библиотеке Faker языка Python.

Данное расширение предоставляет расширенный механизм фальсификации с поддержкой локализации.

Например:

CREATE SCHEMA faker;
CREATE EXTENSION faker SCHEMA faker;
SELECT faker.faker('de_DE');
SELECT faker.first_name_female();
 first_name_female
-------------------
 Mirja

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

Предоставляются следующие функции псевдонимизации:

Второй аргумент (salt) является необязательным. Вы можете вызывать каждую функцию с затравкой вида anon.pseudo_city('bob'), без указания соли. Соль нужна, чтобы увеличить сложность и избежать атак по словарю и полным перебором. Если соль не указана, вместо неё используется значение параметра конфигурации anon.salt (за подробным описанием обратитесь к разделу Универсальное хеширование).

Затравка может представлять собой любую информацию, относящуюся к субъекту. Например, можно постоянно генерировать один и тот же фальсифицированный адрес электронной почты для конкретного человека, используя его логин в качестве затравки:

SECURITY LABEL FOR anon
  ON COLUMN users.emailaddress
  IS 'MASKED WITH FUNCTION anon.pseudo_email(users.login)';

Теоретически хеширование не является надёжным методом анонимизации, однако на практике иногда необходимо создать детерминированный хеш оригинальных данных.

Например когда пара первичный/внешний ключ является «естественным ключом», она может содержать актуальную информацию (номер клиента, содержащий дату рождения или что-то подобное).

Хеширование таких столбцов позволяет сохранить ссылочную целостность даже для относительно необычных исходных данных.

Имейте в виду, что хеширование — это форма псевдонимизации. Это означает, что данные могут быть «деанонимизированы» с помощью хешированного значения и функции маскирования. Если злоумышленники получат доступ к этим двум элементам, они смогут идентифицировать некоторых людей, используя методы атаки brute force (полным перебором) или dictionary (по словарю). Поэтому соль и алгоритм, используемые для хеширования данных, нужно защищать так же надёжно, как и исходный набор данных.

В двух словах, мы рекомендуем вам использовать функцию anon.hash(), а не anon.digest(), потому что тогда соль не будет отображаться в правиле маскирования открытым текстом.

Кроме того, на практике хеш-функция вернёт длинную строку символов, например:

SELECT anon.hash('bob');
                                  hash
----------------------------------------------------------------------------------------------------------------------------------
95b6accef02c5a725a8c9abf19ab5575f99ca3d9997984181e4b3f81d96cbca4d0977d694ac490350e01d0d213639909987ef52de8e44d6258d536c55e427397

Для некоторых столбцов эта строка может быть слишком длинной, и вам, возможно, придётся вырезать некоторые части хеша, чтобы она поместилась в столбец. Например, если у вас есть внешний ключ на основе номера телефона, а столбец представляет собой varchar(12), вы можете преобразовать данные следующим образом:

SECURITY LABEL FOR anon ON COLUMN people.phone_number
IS 'MASKED WITH FUNCTION anon.left(anon.hash(phone_number),12)';

SECURITY LABEL FOR anon ON COLUMN call_history.fk_phone_number
IS 'MASKED WITH FUNCTION anon.left(anon.hash(fk_phone_number),12)';

Конечно, сокращение хеш-значения до 12 символов повысит риск «коллизии» (два разных значения имеют один и тот же фальсифицированный хеш). Решение о принятии такого риска остаётся за вами.

Частичное скрытие оставляет часть данных нетронутыми. Например: номер кредитной карты может быть заменён на «40XX XXXX XXXX XX96».

В некоторых случаях фильтр маскирования стоит применять только для определённого значения или для ограниченного количества строк в таблице.

Например, если требуется «сохранить значения NULL», то есть маскировать только те строки, которые содержат значения, можно использовать функцию anon.ternary, которая работает как выражение CASE WHEN x THEN y ELSE z:

SECURITY LABEL FOR anon ON COLUMN player.score
  IS 'MASKED WITH FUNCTION anon.ternary(score IS NULL,
                                        NULL,
                                        anon.random_int_between(0,100));

Возможно также потребуется исключить некоторые строки в таблице. Например, сохранить пароли некоторых пользователей, чтобы они по-прежнему могли подключаться к тестовой версии приложения:

SECURITY LABEL FOR anon ON COLUMN account.password
  IS 'MASKED WITH FUNCTION anon.ternary( id > 1000, NULL::TEXT, password)';

Обобщение — это принцип замены исходного значения диапазоном, содержащим это значение. Например, вместо «Полу 42 года», можно сказать «Полу от 40 до 50 лет».

Рассмотрим следующую таблицу, содержащую медицинские данные:

SELECT * FROM patient;
 id |   name   |  zipcode |   birth    |    disease
----+----------+----------+------------+---------------
  1 | Alice    |    47678 | 1979-12-29 | Heart Disease
  2 | Bob      |    47678 | 1959-03-22 | Heart Disease
  3 | Caroline |    47678 | 1988-07-22 | Heart Disease
  4 | David    |    47905 | 1997-03-04 | Flu
  5 | Eleanor  |    47909 | 1999-12-15 | Heart Disease
  6 | Frank    |    47906 | 1968-07-04 | Cancer
  7 | Geri     |    47605 | 1977-10-30 | Heart Disease
  8 | Harry    |    47673 | 1978-06-13 | Cancer
  9 | Ingrid   |    47607 | 1991-12-12 | Cancer

Мы можем построить представление на основании этой таблицы, в котором будут исключены некоторые столбцы (SSN и name) и обобщить почтовый индекс и дату рождения следующим образом:

CREATE VIEW anonymized_patient AS
SELECT
    'REDACTED' AS lastname,
    anon.generalize_int4range(zipcode,100) AS zipcode,
    anon.generalize_tsrange(birth,'decade') AS birth,
    disease
FROM patient;

Анонимизированная таблица теперь выглядит так:

SELECT * FROM anonymized_patient;
 lastname |   zipcode     |           birth             |    disease
----------+---------------+-----------------------------+---------------
 REDACTED | [47600,47700) | ["1970-01-01","1980-01-01") | Heart Disease
 REDACTED | [47600,47700) | ["1950-01-01","1960-01-01") | Heart Disease
 REDACTED | [47600,47700) | ["1980-01-01","1990-01-01") | Heart Disease
 REDACTED | [47900,48000) | ["1990-01-01","2000-01-01") | Flu
 REDACTED | [47900,48000) | ["1990-01-01","2000-01-01") | Heart Disease
 REDACTED | [47900,48000) | ["1960-01-01","1970-01-01") | Cancer
 REDACTED | [47600,47700) | ["1970-01-01","1980-01-01") | Heart Disease
 REDACTED | [47600,47700) | ["1970-01-01","1980-01-01") | Cancer
 REDACTED | [47600,47700) | ["1990-01-01","2000-01-01") | Cancer

Обобщенные значения по-прежнему полезны для статистики, поскольку они остаются верными, но они менее точны и, следовательно, снижают риск идентификации.

Postgres Pro предлагает несколько диапазонных типов данных, которые идеально подходят для дат и числовых значений.

Для числовых значений доступны следующие функции:

Схема pg_catalog не является доверенной по умолчанию. Эта мера безопасности принимается, чтобы предотвратить использование пользователями сложных функций в правилах маскирования (таких как pg_catalog.query_to_xml, pg_catalog.ts_stat или функций системного администрирования), которые не должны применяться в качестве функций маскирования.

Однако данное расширение предоставляет привязки к некоторым полезным и безопасным функциям из схемы pg_catalog:

Если требуется больше связок, выполните одно из следующих действий:

Вы также можете использовать свою собственную функцию в качестве маски. Функция должна быть либо деструктивной (например, частичное скрытие), либо вносить некоторые случайные значения в набор данных (например, фальсификация).

Для сложных типов данных, возможно, придётся создать собственную функцию. Этим приёмом придётся часто пользоваться, если нужно скрыть определённые части поля JSON.

Например:

CREATE TABLE company (
business_name TEXT,
info JSONB
)

Поле info содержит неструктурированные данные, как показано ниже:

SELECT jsonb_pretty(info) FROM company WHERE business_name = 'Soylent Green';
          jsonb_pretty
----------------------------------
{
    "employees": [
        {
            "lastName": "Doe",
            "firstName": "John"
        },
        {
            "lastName": "Smith",
            "firstName": "Anna"
        },
        {
            "lastName": "Jones",
            "firstName": "Peter"
        }
    ]
}
(1 row)

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

CREATE SCHEMA custom_masks;

-- Для этого требуются права суперпользователя
SECURITY LABEL FOR anon ON SCHEMA custom_masks IS 'TRUSTED';

CREATE FUNCTION custom_masks.remove_last_name(j JSONB)
RETURNS JSONB
VOLATILE
LANGUAGE SQL
AS $func$
SELECT
json_build_object(
  'employees' ,
  array_agg(
    jsonb_set(e ,'{lastName}', to_jsonb(anon.fake_last_name()))
  )
)::JSONB
FROM jsonb_array_elements( j->'employees') e
$func$;

Затем проверьте правильность работы функции:

SELECT custom_masks.remove_last_name(info) FROM company;

Если всё в порядке, вы можете объявить эту функцию как маску поля info:

SECURITY LABEL FOR anon ON COLUMN company.info
IS 'MASKED WITH FUNCTION custom_masks.remove_last_name(info)';

И использовать её:

SELECT anonymize_table('company');
SELECT jsonb_pretty(info) FROM company WHERE business_name = 'Soylent Green';
          jsonb_pretty
-------------------------------------
{
    "employees": [                 +
        {                          +
            "lastName": "Prawdzik",+
            "firstName": "John"    +
        },                         +
        {                          +
            "lastName": "Baltazor",+
            "firstName": "Anna"    +
        },                         +
        {                          +
            "lastName": "Taylan",  +
            "firstName": "Peter"   +
        }                          +
    ]                              +
}
(1 row)

Это самый простой пример. Как видите, управлять сложной структурой JSON с помощью языка SQL возможно, но поначалу это может быть сложно. Существует несколько способов обхода ключей и обновления значений. Вам, вероятно, придётся попробовать разные подходы в зависимости от ваших реальных данных JSON и производительности, которую вы хотите достичь.

Вы можете навсегда применить правила маскирования базы данных, используя функцию anon.anonymize database().

Рассмотрим простой пример:

CREATE TABLE customer (
  id SERIAL,
  full_name TEXT,
  birth DATE,
  employer TEXT,
  zipcode TEXT,
  fk_shop INTEGER
);

INSERT INTO customer
VALUES
(911,'Chuck Norris','1940-03-10','Texas Rangers', '75001',12),
(312,'David Hasselhoff','1952-07-17','Baywatch', '90001',423)
;

SELECT * FROM customer;

 id  |   full_name      |   birth    |    employer   | zipcode | fk_shop
-----+------------------+------------+---------------+---------+---------
 911 | Chuck Norris     | 1940-03-10 | Texas Rangers | 75001   | 12
 112 | David Hasselhoff | 1952-07-17 | Baywatch      | 90001   | 423

Вы также можете использовать функции anonymize_table() и anonymize_column() для удаления данных из подмножества строк базы данных:

SELECT anon.anonymize_table('customer');
SELECT anon.anonymize_column('customer','zipcode');

Перестановка перемешивает значения в пределах столбца.

Этот способ полезен для внешних ключей, поскольку будет сохранена ссылочная целостность.

Есть также некоторые функции, которые могут добавить искажение во все значения столбца:

Когда активировано динамическое маскирование, запрещено изменять тип данных столбца, если на нём есть маска.

Чтобы изменить замаскированный столбец, вам нужно временно отключить механизм маскирования следующим образом:

BEGIN;
SELECT anon.stop_dynamic_masking();
ALTER TABLE people ALTER COLUMN phone TYPE VARCHAR(255);
SELECT anon.start_dynamic_masking();
COMMIT;

Механизм динамического маскирования будет строить маскирующие представления для замаскированных таблицах. Это означает, что невозможно напрямую удалить замаскированную таблицу. Вы получите такую ошибку:

DROP TABLE people;
psql: ERROR:  cannot drop table people because other objects depend on it
DETAIL:  view mask.company depends on table people

Для эффективного удаления таблицы необходимо добавить параметр CASCADE, чтобы маскирующее представление тоже удалялось:

DROP TABLE people CASCADE;

Просто удалить защитную метку можно следующим образом:

SECURITY LABEL FOR anon ON ROLE bob IS NULL;

Сделать сразу все недоверенные роли обычными можно так:

SELECT anon.remove_masks_for_all_roles();

Скрипт pg_dump_anon.sh поддерживает большинство параметров обычной команды pg_dump. Также поддерживаются переменные среды (PGHOST, PGUSER и т. д.) и файлы .pgpass.

Пользователь с именем bob может экспортировать анонимный архив базы данных app следующим образом:

/opt/pgpro/ent-15/bin/pg_dump_anon.sh -h localhost -U bob --password --file=anonymous_dump.sql app

Чтобы получить дополнительные сведения о поддерживаемых параметрах, просто введите ./pg_dump_anon.sh --help.

Идея обобщения состоит в том, чтобы заменить данные более широкими и менее точными значениями. Например, вместо «Бобу 28 лет» можно сказать «Бобу от 20 до 30 лет». Это полезно для аналитики, потому что данные остаются верными, избегая при этом риска идентификации.

Обобщение — это способ достижения k-анонимности.

Postgres Pro может легко использовать обобщение благодаря диапазонным типам данных, которые являются очень эффективным способом хранения и работы с набором значений, содержащихся между нижней и верхней границей.

Рассмотрим таблицу с медицинскими данными:

SELECT * FROM patient;
     ssn     | firstname | zipcode |   birth    |    disease
-------------+-----------+---------+------------+---------------
 253-51-6170 | Alice     |   47012 | 1989-12-29 | Heart Disease
 091-20-0543 | Bob       |   42678 | 1979-03-22 | Allergy
 565-94-1926 | Caroline  |   42678 | 1971-07-22 | Heart Disease
 510-56-7882 | Eleanor   |   47909 | 1989-12-15 | Acne
 098-24-5548 | David     |   47905 | 1997-03-04 | Flu
 118-49-5228 | Jean      |   47511 | 1993-09-14 | Flu
 263-50-7396 | Tim       |   47900 | 1981-02-25 | Heart Disease
 109-99-6362 | Bernard   |   47168 | 1992-01-03 | Asthma
 287-17-2794 | Sophie    |   42020 | 1972-07-14 | Asthma
 409-28-2014 | Arnold    |   47000 | 1999-11-20 | Diabetes
(10 rows)

Мы хотим, чтобы анонимизированные данные оставались достоверными, потому что они будут использоваться для статистики. Можно построить представление этой таблицы, чтобы удалить бесполезные столбцы и обобщить косвенные идентификаторы:

CREATE MATERIALIZED VIEW generalized_patient AS
SELECT
  'REDACTED'::TEXT AS firstname,
  anon.generalize_int4range(zipcode,1000) AS zipcode,
  anon.generalize_daterange(birth,'decade') AS birth,
  disease
FROM patient;

Это даст нам менее точное представление данных:

SELECT * FROM generalized_patient;
 firstname |    zipcode    |          birth          |    disease
-----------+---------------+-------------------------+---------------
 REDACTED  | [47000,48000) | [1980-01-01,1990-01-01) | Heart Disease
 REDACTED  | [42000,43000) | [1970-01-01,1980-01-01) | Allergy
 REDACTED  | [42000,43000) | [1970-01-01,1980-01-01) | Heart Disease
 REDACTED  | [47000,48000) | [1980-01-01,1990-01-01) | Acne
 REDACTED  | [47000,48000) | [1990-01-01,2000-01-01) | Flu
 REDACTED  | [47000,48000) | [1990-01-01,2000-01-01) | Flu
 REDACTED  | [47000,48000) | [1980-01-01,1990-01-01) | Heart Disease
 REDACTED  | [47000,48000) | [1990-01-01,2000-01-01) | Asthma
 REDACTED  | [42000,43000) | [1970-01-01,1980-01-01) | Asthma
 REDACTED  | [47000,48000) | [1990-01-01,2000-01-01) | Diabetes
(10 rows)

Расширение pgpro_anonymizer предоставляет функции обобщения для всех встроенных диапазонных типов. Как правило, эти функции принимают маскируемое значение в качестве первого параметра, а второй параметр является длиной шага.

Для числовых значений:

Для значений времени:

Возможные значения шагов: микросекунда, миллисекунда, секунда, минута, час, день, неделя, месяц, год, десятилетие, столетие и тысячелетие.

k-анонимность — это стандартный отраслевой термин, используемый для описания свойства анонимизированного набора данных. Принцип k-анонимности гласит, что в заданном наборе данных любого анонимизированного человека нельзя отличить как минимум от k-1 других людей. Другими словами, k-анонимность можно описать как гарантию «укрытия в толпе». Низкое значение k увеличивает риск идентификации на основании связи с другими источниками данных.

По сути, статическое маскирование полностью перезаписывает замаскированные таблицы на диске. Это может занимать много времени в зависимости от вашей среды. И во время этого процесса таблицы будут заблокированы.

При динамическом маскировании реальные данные заменяются «на лету» каждый раз, когда недоверенный пользователь отправляет запрос в базу данных. Это означает, что у недоверенных пользователей будет более медленный отклик, чем у обычных (доверенных). Обычно это нормально, потому что недоверенные пользователи как правило считаются менее важными, чем обычные.

Если вы примените к таблице три или четыре правила, время отклика для недоверенных пользователей должно быть примерно на 20-30% больше, чем для обычных.

Поскольку правила маскирования применяются для каждого запроса со стороны недоверенных пользователей, динамическое маскирование уместно, когда у вас есть ограниченное количество недоверенных пользователей, которые подключаются к базе данных только время от времени. Например, аналитик данных подключается раз в неделю для создания бизнес-отчёта.

Если есть несколько недоверенных пользователей или если недоверенный пользователь очень активен, рекомендуется один раз в неделю экспортировать замаскированные данные на дополнительный экземпляр и позволить этим пользователям подключаться к этому дополнительному экземпляру.

Если процесс резервного копирования вашей базы данных занимает один час с использованием pg_dump, то анонимизация и экспорт всей базы данных с использованием pg_dump_anon.sh ориентировочно займёт два часа.

Ниже приведён обзор возможных действий пользователей в зависимости от имеющихся у них прав:

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

По умолчанию доверенной объявлена только схема anon. Это означает, что функции из pg_catalog по умолчанию нельзя использовать в правилах маскирования.

За подробной информацией обратитесь к разделу Использование функций pg_catalog.

Большинство функций данного расширения объявлены с тегом SECURITY INVOKER. Это означает, что эти функции выполняются с правами пользователя, который их вызывает. Это важное ограничение.

Данное расширение содержит ещё несколько функций, объявленных с использованием тега SECURITY DEFINER.

Допустим, есть огромный объём HTTP‑журналов, хранящихся в таблице. Вы хотите удалить IP‑адреса и извлечь лишь 10% данных из этой таблицы:

CREATE TABLE http_logs (
  id integer NOT NULL,
  date_opened DATE,
  ip_address INET,
  url TEXT
);

SECURITY LABEL FOR anon ON COLUMN http_logs.ip_address
IS 'MASKED WITH VALUE NULL';

SECURITY LABEL FOR anon ON TABLE http_logs
IS 'TABLESAMPLE BERNOULLI(10)';

Теперь можно выполнить статическое маскирование, динамическое маскирование или создать анонимные дампы. Маскированные данные будут представлять собой 10% от объёма реальных данных.

Синтаксис полностью совпадает с синтаксисом предложения TABLESAMPLE, которое можно добавлять в конце оператора SELECT.

Также можно задать коэффициент выборки на уровне базы данных. Этот коэффициент будет применяться ко всем таблицам, для которых не определено собственное правило TABLESAMPLE.

SECURITY LABEL FOR anon ON DATABASE app
IS 'TABLESAMPLE SYSTEM(33)';

Извлечение подмножества базы данных с сохранением ссылочной целостности является непростой задачей, и данное расширение его не поддерживает.

Если требуется сохранить ссылочную целостность в анонимизированном наборе данных, выполните следующие шаги:

Существуют и другие инструменты для извлечения выборки в Postgres Pro, но pg_sample — один из лучших.