Когда может понадобиться обезличивание персональных данных

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

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

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

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

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

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

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

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

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

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

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