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

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

Вы можете использовать более сложные выражения с синтаксисом MASKED WITH VALUE:

SECURITY LABEL FOR anon ON COLUMN player.name
  IS 'MASKED WITH VALUE CASE WHEN name IS NULL
                             THEN $$John$$
                             ELSE anon.random_string(LENGTH(name))
                             END';

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

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% к столбцу зарплаты набор данных не потеряет смысл.

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

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

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

Для столбцов типа 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'), без указания соли. Соль нужна, чтобы увеличить сложность и избежать атак по словарю и полным перебором. Если соль не указана, вместо неё используется случайное секретное значение соли (за подробным описанием обратитесь к разделу Универсальное хеширование).

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

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

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

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

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

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

Имейте в виду, что хеширование — это форма псевдонимизации. Это означает, что данные могут быть «деанонимизированы» с помощью хешированного значения и функции маскирования. Если злоумышленники получат доступ к этим двум элементам, они смогут идентифицировать некоторых людей, используя методы атаки 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 pg_catalog.left(anon.hash(phone_number),12)';

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

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

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

Обобщение — это принцип замены исходного значения диапазоном, содержащим это значение. Например, вместо «Полу 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 предлагает несколько диапазонных типов данных, которые идеально подходят для дат и числовых значений.

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

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

Например, если вы написали функцию foo() внутри схемы bar, вы можете применить её следующим образом:

SECURITY LABEL FOR anon ON SCHEMA bar IS 'TRUSTED';

SECURITY LABEL FOR anon ON COLUMN player.score
IS 'MASKED WITH FUNCTION bar.foo()';

CREATE TABLE company (
  business_name TEXT,
  info JSONB
)

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)

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;

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)

Вы можете навсегда применить правила маскирования базы данных, используя функцию 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-17/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.restrict_to_trusted_schemas = on

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

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

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