Home

Оригинальная публикация: https://tproger.ru/articles/avoid-data-leaks-when-testing/

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

Откуда берутся тестовые данные

Тестовые данные получают по-разному, у каждого из подходов свои плюсы и минусы:

• можно генерировать их в автоматизированном режиме. Для этого нужны специальные инструменты, довольно сложные;
• можно вводить тестовые данные вручную, но это требует серьезных трудозатрат;
• иногда разработчики берут рабочую базу, которая полностью копируется в тестовую среду. Но рабочая база обычно велика, и адекватно уменьшить её сложно.

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

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

«Самописные» решения

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

Все заказчики приспосабливаются к ситуации, и первое, что они начинают делать, — маскировать данные с помощью собственного набора скриптов. Объём базы при этом остаётся практически неизменным, и процедура маскирования может занимать значительное время. Кроме того, собственное решение требует квалифицированных программистов для разработки и сопровождения.

Как работают специализированные решения?

Второй путь – готовые инструментарии управления тестовыми данными, такие, как IBM InfoSphere Optim Test Data Management. Они нацелены в первую очередь на уменьшение трудоемкости и получение видимых результатов, которые можно сравнить с исходной базой. В итоге это повышает возможности контроля, сокращает затраты и обеспечивает нужный уровень безопасности. Здесь возникает задача извлечения данных ограниченного объёма, которые могут быть замаскированы за разумное время. Делается это в четыре этапа.

Этап 1. Найти конфиденциальную информацию

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

Этап 2. Идентифицировать и уточнить связи

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

Этап 3. Решить, будет ли участвовать в тесте вся база или только ее часть

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

Этап 4. Замаскировать данные

Маскирование относительно небольших объемов информации обычно проводится за пределами базы данных. Если объем очень велик — например, в аналитическом хранилище, где можно допустить присутствие и замаскированных данных и исходных аналогов, — его можно делать на стороне хранилища. Если данные выгружались и маскировались за пределами системы, формируется эталонная копия. Эту копию нужно размножить и загрузить в нужные для работы тестовых сред СУБД. И, конечно, у всех разработчиков подобных решений есть коннекторы ко всем промышленным СУБД, возможность работы с плоскими файлами и вообще со всем, к чему есть стандартные драйверы JDBC/ODBC.

Специализированные решения – самый удачный выбор

Часто у заказчика уже есть налаженная система, которая одобрена подразделением безопасности и считается неуязвимой. Она может быть основана, например, на том, что к тестовой среде имеет доступ только ограниченный круг доверенных сотрудников, которые выполняют необходимые манипуляции. К сожалению, в этом случае потребности процесса тестирования обеспечены не полностью и при увеличении количества запросов нет возможности выполнить все необходимые тесты в разумные сроки. Такая система очень плохо масштабируется из-за ограниченного объема вычислительных и человеческих ресурсов, выделенных для тестирования.

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

За материал спасибо Сергею Катаеву, руководителю отдела развития корпоративных решений в компании «Системный софт».

Обсудить в форуме