Обезличивание БД АБС

Внешняя команда разбирает базу АБС —
не выпустив из банка ни одного реквизита

Аналитик видит структуру, суммы, даты и связи как есть. ФИО, паспорт, ИНН, телефон, номер счёта — только под маской. Сырьё не покидает контур банка, и банк проверяет это сам.

Посмотреть на примере скачать документ
Зачем

Проблема

Чтобы снять аналитику или разобрать структуру АБС, внешней команде нужен доступ к базе. Но в базе — персональные данные и банковская тайна: их нельзя ни выносить за периметр, ни показывать подрядчику.

Обычный ответ — «сделаем обезличенную копию» — упирается в терабайты и в месяцы ручной разметки тысяч таблиц. И почти всегда остаются дыры, через которые настоящее значение всё же вытаскивается.

Как устроено

Схема

КОНТУР БАНКА · СЫРЬЁ ОТСЮДА НЕ ВЫХОДИТ Боевая АБС · Oracle сырьё, ПДн доступ только у DBA банка дамп / реплика Схема ANON вьюхи маскируют ПДн на лету структура и суммы — как есть владелец вьюх заперт SELECT Внешний аналитик видит только маски роль «только чтение ANON» Единственный выход наружу шлюз с журналом всех запросов только после сборки ANON облачная модель · аналитика Штатный аудит СУБД пишет каждый запрос аналитика банк видит, что уходило, своим инструментом — без нашего кода
Два ключа в разных руках: сырьё читает только запертый владелец вьюх, наружу ходит только роль, у которой к сырью доступа нет.
На примере

Что видит аналитик в одной строке клиента

Слева — как лежит в боевой базе. Справа — что отдаёт вьюха ANON той же строки. Прогон на открытом банковском датасете Berka.

Боевая база
client_idC00000001
ФИОJana Novakova
SSN / ИНН705128 / 1234
телефон+420 603 118 227
e-mailjana.n@email.cz
адресPraha, Korunní 12
дата рожд.1990-05-12
Вьюха ANON
client_idC00000001 — ключ цел
ФИОNM_9C26FB4B5CED
SSN / ИННNM_A1F0…
телефон999-999-9999
e-mailNM_6DB0E97D9C
адрес∅ пусто
дата рожд.1990 — только год

Личность скрыта, а внутренний ключ client_id остаётся — связи между таблицами и отчёты по ним не рвутся.

Тот же SQL

Запрос к ANON — как к обычной базе

Аналитик пишет привычный SQL. Он не знает ключа, не вызывает функцию токенизации, не читает базовые таблицы — их в его правах нет. Отдаётся только то, что во вьюхе.

SELECT client_id, full_name,
       phone, birth_date
FROM   anon.client
WHERE  rownum <= 3;
client_idfull_namephonebirth
C00000001NM_9C26FB…999-999-99991990
C00000002NM_E14D48…999-999-99991965
C00000003NM_218770…999-999-99991960

до копейки

Отчётность сходится

Обезличенное даёт тот же результат

Суммы, даты и балансовые счета во вьюхах настоящие — маскированы только личности. Штатный отчёт, снятый с ANON, совпадает с боевым. Сверка оборота на 1 056 320 проводках:

боевая база
6 257 793 560
оборот по дебету и кредиту
=
схема ANON
6 257 793 560
тот же результат
Три замка

Банк проверяет сам, без доверия нам на слово

Только ANON в правах

У нашей учётки нет ни одного права на рабочие схемы. Проверяется одним запросом по правам.

Сырьё читает «никто»

Единственный, кто видит сырьё, — владелец вьюх, а под ним нельзя залогиниться. Вьюхи при этом работают.

Всё в их журнале

Штатный аудит СУБД пишет каждый наш запрос. Банк видит, что уходило, своим инструментом.

Свободный текст

ПДн внутри назначения платежа

Если отчёт категоризирует проводку по словам в назначении, поле нельзя занулять. Структурные реквизиты — ИНН, телефон, счёт — вырезаются по форме, а классифицирующие слова остаются. Имя в прозе требует локальной модели в контуре.

Было
Оплата пенсия, Иванов, ИНН 30512345678901, тел +998901234567
Стало
Оплата пенсия, Иванов, ИНН [скрыто], тел [скрыто]
Приёмка

ИБ сам пытается достать ПДн — и не может

Батарея проверок от имени учётки аналитика. На стенде все пройдены:

Что нужно от банка

Доступ и сервер

Сервер

VM в контуре, Linux, 16 ГБ памяти с запасом. Тяжёлая база — на стороне банка, наш сервер только гоняет сессию разбора.

Доступ

Копия из дампа под вьюхи; на время сборки — права собрать ANON, после — только чтение ANON.

Контроль

Включённый штатный аудит на нашу учётку и рубильник выхода наружу — у банка.

скачать подробный документ со скриптами