Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Аудит доступа к персональным данным (согласно GDPR) в базе данных и его последствия для администратора безопасности
Три года назад в Европе прогремел GDPR – новый закон о защите персональных данных. Озвучен он был заранее и готовились к нему основательно, благо что после принятия до вступления в силу оставалось целых два года. Многие компании успели заложить бюджет для приведения информационных систем в соответствие с новым законодательством.
Сейчас, по прошествии трех лет, некоторые проекты уже реализованы и можно сделать небольшие наброски стандартного аудиторского проекта по GDPR, а также последующего приведения системы в соответствие с нормами аудита. Под катом:
- Персональные данные в базе данных
- Что требует GDPR (доступ, хранение, удаление)
- А поговорить? (Интервью с бизнесом)
- Маскировка данных в DEV и ACC
- И напоследок
Персональные данные в базе данных
Персональные данные (ПД) бывают прямые и косвенные. Прямые это все что напрямую относится к физическому лицу, которое можно безошибочно по этим данным определить и опознать. Например это все учетные записи пользователей. Это также все поставщики или заказчиков, если это физ.лица, и конечно это сотрудники, которых часто в системе проводят как поставщиков (услуг труда).
Косвенные ПД это все, что можно отследить с привязкой к прямым данным. Например это номера и состав заказов, сделанных заказчиком, это действия пользователей совершенные под их учетными записями, это записи о смене позиции человека, привязанные к его ID в системе.
В общем виде, это выглядит так:
Во-первых, этот список не исчерпывающий. Во-вторых, вглубину можно копать достаточно долго. Например только по мастер данным в HR можно найти много нюансов. В каждой порядочной базе данных находятся десятки таблиц содержащих прямые ПД и тысячи, содержащих косвенные.
Что требует GDPR (доступ, хранение и удаление)
Закон достаточно требовательно относится к любым манипуляциям с ПД, начиная с момента заполучения таких данных и заканчивая тем, что рано или поздно но такие данные нужно утилизировать.
Даже если предположить что все данные в системе получены законным путем (а как иначе) и их хранение и переработка необходимы для нормального ведения бизнеса, все равно остается немало других требований:
- Ограничение доступа. Данные должны быть использованы и доступны только для тех, кто имеет право ими пользоваться по долгу службы. Сам закон говорит что данные должны получить «protection against unauthorized or unlawful processing».
- Безопасное хранение. Система в которой хранятся ПД должна быть надежной и безопасной, защищенной от явных уязвимостей (привет техническому аудиту).
- Маскировка. Данные в не продакшн системе, в идеале не должны храниться в открытом виде. Закон напрямую этого не говорит, но учитывая что в системах тестирования часто доступ у пользователей шире, а также обновляются такие системы реже чем продакш, и поэтому данные там остаются надолго – многие компании сделали шаг в сторону маскировки данных в таких системах.
- Удаление. Наконец, GDPR говорит что данные не должны храниться бесконечно в формате, позволяющем установить связь с конкретным физическим лицом. Другими словами, данные нужно регулярно архивировать и анонимизировать. (Storage limitation)
А поговорить? (Интервью с бизнесом)
Все персональные данные персональные, но некоторые персональнее. Невозможно выстраивать систему строгой защиты вокруг любых ПД, также как и невозможно полностью обезопасить базу данных от любых технических угроз. И проаудировать всю систему тоже невозможно. В какой-то момент надо устанавливать приоритеты, основываясь на рисках.
После первоначальной инвентаризации того какие данные хранятся в системе, обязательно надо обсудить с бизесом, в чем риск каждого конкретного типа данных.
Например если система хранит HR данные, то какие именно данные наиболее рискованные? Адрес, банковский счет, количество детей, зарплатный лист? Если система хранит только данные по рабочему расписанию или общедоступный на LinkedIn имейл, то может и нет смысла беспокоиться по поводу защиты этих данных?
Данные по заказчикам и поставщикам как правило всегда достаточно сильно охраняются. Но тем не менее, не всегда сотрудникам работающим с клиентами или поставщиками необходимо знать ВСЕ поля мастер данных или все данные контактных лиц. Опять же, есть дьявольские поля, вроде «комментарий» или «иное», куда вообще можно записать все что угодно, от личного телефона, то клички собаки клиента. Это может быть чревато.
Интервью с каждым ответственным за процесс должно выявить:
- какие данные в системе вы еще не увидели (новые кастомизированные таблицы, например);
- какие данные наиболее всего нуждаются в защите, где самые большие риски;
- из каких сторонних систем в базу данную приходят данные.
- Последний пункт особенно значим для этапа маскирования и удаления данных. Идем к нему.
Маскировка данных в DEV и ACC
Представьте что данные это деньги, а разработчики это дети. Настоящие персональные данные в девелопменте или тестировании это все равно что дети, играющиеся настоящими купюрами. Очень часто, все будет протекать штатно и без эксцессов. Но может случиться и форсмажор – купюру где-то забудут, порвут.
В идеале данные замаскировать. Изменить имена физических лиц с реальных на вымышленные, например Вася Пупкин будет Вххх Пхххххн, а его банковский счет будет не 4044 5061 7789 0001, а например 0000 0000 0002 0001.
Есть целые компании успешно занимающиеся маскировкой данных. Маскировка включает взаимосвязи – и Вася Пупкин будет выглядеть одинаково Вххх Пхххххн во всех таблицах, где он ранее был. Остается уникальный номер физического лица, без конкретных данных.
Решение правильное, но несет в себе много сложностей. Вот пара из них:
- как тестировать интеграции? Не везде можно синхронно замаскировать данные, а тестировочные системы затем и нужны, чтобы тестировать что все правильно работает, выгружается, подтягивается. Если данные в одной тест системе замаскированы, а в другой нет, то ничего хорошего не получится.
- недоделанная функциональность. Часто целые функции работают опираясь на правильные данные – например налоги считаются исходя из остатков на счетах или счет формируется сразу копируя ИНН. Или система использует ИНН чтобы подтянуть расходы поставщика. И если замаскировать банковские или финансовые данные физического лица, то финансовый модуль просто невозможно будет нормально протестировать.
И конечно удаление данных. Аудитор GDPR будет требовать, чтобы данные регулярно удалялись, например, используя lifecycle management. С одной стороны это соответствует нормам GDPR, с другой это также необходимо если физическое лицо, вздумает воспользоваться правом на забвение (Right to erasure).
В действительности сразу возникают новые вопросы:
- какой срок максимального хранения? (кто определяет сроки – бизнес или ИТ исходя из технических возможностей? Налоговое законодательство?)
- после истечения срока, если данные удалены в продакшене, нужно ли чистить все тестировочные системы?
Увы, к моменту когда возникает момент отвечать на все эти вопросы, бюджет, выделенный на проект GDPR, как правило, уже заканчивается.
И напоследок
Путь от бурного энтузиазма через пик высоких ожиданий к бездне отчаяния проходит любой новый проект, и рано или поздно реальность, ожидания и возможности выходят на плато.
В данном случае администратору безопасности необходимо держать в голове возможные вопросы аудиторов и стратегию закрытия максимальных рисков. За полгода подготовить систему к соответствию GDPR практически невозможно, но возможно понять как могут быть самые тонкие и самые опасные места и выработать жизнеспособный план.
Разработчики будут сопротивляться, бизнес будет просить быстрых и легких решений, аудиторы будут пугать большими штрафами, но самое главное, что процесс улучшения и налаживания безопасности будет идти.
