nxs-data-anonymizer: анонимизация данных для тестовых и динамических окружений

nxs-data-anonymizer

Зачем нужна анонимизация данных

Один из вариантов — один раз скопировать production-базу, удалить из неё чувствительные данные и использовать подготовленную БД для разработки.

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

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

Ручная обработка базы в таком случае требует времени и увеличивает затраты, а также влияет на Time-to-Market.

Для автоматизации этого процесса можно использовать анонимайзеры. Это могут быть как простые скрипты на PHP или Bash, так и специализированные инструменты.

Почему появился nxs-data-anonymizer

В работе Nixys часто используются две СУБД — PostgreSQL и MySQL.

Для PostgreSQL используется решение от Evrone. На момент разработки nxs-data-anonymizer оно не поддерживало MySQL, поэтому для MySQL приходилось использовать собственные Bash-скрипты.

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

Поэтому был разработан собственный инструмент, который можно было использовать как готовое решение в разных проектах.

Разработка, тестирование и подготовка инструмента заняли около месяца. Изначально nxs-data-anonymizer создавался только для MySQL, однако затем его функциональность была расширена поддержкой PostgreSQL.

Поскольку MySQL был первой поддерживаемой СУБД, примеры ниже приведены для него. Информация по PostgreSQL доступна на странице проекта в GitHub.

Основные идеи

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

Если колонка в БД должна содержать уникальные значения, такой дамп невозможно будет загрузить.

nxs-data-anonymizer позволяет указать, что генерируемые значения должны быть уникальными.

Пример анонимизации MySQL

filters:
 users:
   columns:
     username:
       value: "{{ if eq .Values.username \"admin\" }}{{ .Values.username }}{{ else }}user_{{ .Values.id }}{{ end }}"
     api_key:
       value: "{{ if eq .Values.username \"admin\" }}preset_admin_api_key{{ else }}{{- randAlphaNum 50 | nospace | lower -}}{{ end }}"
       unique: true

GitLab CI

А вот и интересующие нас моменты описанного выше решения.

Начнём со стадии anonymize, которая запускается автоматически сразу после завершения деплоя приложения в прод и миграций БД:

anonymize:
 stage: anonymize
 image: nixyslab/nxs-data-anonymizer:latest
 variables:
   GIT_STRATEGY: none
   MYSQL_HOST: ${MYSQL_HOST_PROD}
   MYSQL_USER: ${MYSQL_USER_PROD}
   MYSQL_PASSWORD: ${MYSQL_PASS_PROD}
 before_script:
 - echo "${S3CMD_CFG}" > ~/.s3cmd
 - echo "${NXS_DA_CFG}" > /nxs-data-anonymizer.conf
 script:
 - mysqldump -h ${MYSQL_HOST} -u ${MYSQL_USER} -p${MYSQL_PASSWORD} ${MYSQL_DATABASE} | /nxs-data-anonymizer -t mysql -c /nxs-data-anonymizer.conf | gzip | s3cmd put - s3://bucket/anondump.sql.gz
 only:
 - /^v.*$/
 except:
 - branches
 - merge_requests

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

Инструмент легко встраивается в CI/CD любой платформы, будь то GitLab CI, GitHub Actions или что-то ещё.

Ограничения

Здесь описан наиболее распространённый относительно простой случай.

Один из минусов такого подхода — это время на разворачивание дампов больших БД.

Что дальше?

На момент публикации статьи были выделены следующие фичи, которые планировалось реализовать в первую очередь:

• Удаление таблиц и строк в таблицах из результирующего дампа. Иногда требуется не только изменить какие-то реальные данные, но и удалить их. Например, когда делается дамп БД таск-трекера, нужно полностью удалить некоторые проекты со всеми их задачами.

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

Свои идеи и предложения по развитию инструмента можно отправить разработчикам проекта.