Разработка ПО с учетом требований KVKK и GDPR: Чек-лист от архитектуры до тестирования

Защита персональных данных часто воспринимается исключительно как задача юридического отдела: составляется текст уведомления, в договор добавляется пункт — и на этом работа считается завершенной. Однако большая часть принципов, требуемых законодательством, должна быть реализована непосредственно в архитектуре программного обеспечения. В этой статье общие принципы закона KVKK № 6698 в Турции, Закона о защите персональных данных в ТРСК и GDPR в ЕС переведены в практический чек-лист для команды разработки. Для юридической оценки обязательно следует привлечь экспертов; здесь же рассматривается техническая сторона вопроса.

1. Инвентаризация данных: какое поле является персональными данными?

Для каждой таблицы и столбца в схеме базы данных должна храниться информация о том, являются ли они «персональными данными или данными особой категории, с какой целью они обрабатываются и как долго хранятся». Эта инвентаризация лежит в основе обязанностей по регистрации (подобно VERBİS) и запросов субъектов данных. Практический метод: комментарии к столбцам внутри схемы и отдельная таблица словаря данных.

comment on column employees.national_id is 'персональные данные; цель: расчет зарплаты; хранение: трудовые отношения + юридический срок';
comment on column employees.health_note is 'особая категория; цель: врач предприятия; доступ: только роль здравоохранения';

2. Ограничение целей и минимизация данных

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

3. Срок хранения и автоматическое удаление

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

4. Контроль доступа: на уровне базы данных

Надежная реализация принципа «доступ только у авторизованных лиц» — это когда правило заложено на уровне самих данных. С помощью PostgreSQL Row Level Security каждый запрос фильтруется в соответствии с правами пользователя; ошибка в коде приложения не приведет к раскрытию неавторизованных данных. Доступ администраторов при этом должен быть временным и обоснованным.

5. Шифрование: при передаче и хранении

• При передаче данных обязателен TLS; старые протоколы и наборы шифров отключены.
• При хранении используется шифрование на уровне диска или базы данных; для полей особой категории может рассматриваться дополнительное шифрование столбцов.
• Пароли никогда не хранятся в виде открытого текста; используются современные и медленные алгоритмы хеширования (например, Argon2 или bcrypt).
• Управление ключами: ключи хранятся не в коде и не в базе данных, а в отдельной системе управления секретами.

6. Логирование и контрольный журнал (аудит)

Должно фиксироваться, кто, когда и с какой целью обращался к персональным данным. Тем не менее, логи сами по себе тоже содержат персональные данные: в содержимом логов не должно быть лишних данных (например, полного идентификационного номера), а для самих логов должны быть определены собственные сроки хранения и права доступа.

Соответствие требованиям — это не текст, а поведение: система собирает данные в необходимом объеме, хранит их столько, сколько нужно, показывает нужным людям и фиксирует свои действия.

7. Техническая подготовка к реализации прав субъектов данных

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

8. Третьи стороны и передача данных

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

9. Практика безопасной разработки

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

10. Тестовые и демонстрационные данные

Копирование реальных персональных данных в тестовую среду — распространенная и рискованная привычка. Тестовые среды должны работать с синтетическими или анонимизированными данными; это также исключает ненужный доступ со стороны команды разработки.

Краткий чек-лист

1. Инвентаризация данных и классификация на уровне столбцов
2. Отсутствие полей без цели
3. Срок хранения в системе, автоматическое удаление/анонимизация
4. Контроль доступа на уровне базы данных
5. Шифрование при передаче и хранении, безопасное хранение паролей
6. Журнал аудита (с собственным правилом хранения)
7. Возможность экспорта и удаления для запросов субъектов данных
8. Инвентаризация третьих сторон и оценка передачи данных
9. Безопасная разработка на базе OWASP
10. Анонимизированные тестовые данные

Согласие и уведомление: как это выглядит в интерфейсе?

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

Минимизация при переносе данных и интеграциях

Интеграции часто настраиваются по принципу «отправить всю запись». Между тем в SMS-сервис должны отправляться только телефон и сообщение, а в бухгалтерию — только сумма и центр затрат. Для каждой интеграции документируется список отправляемых полей; этот список является техническим приложением к договору обработчика данных. В ответах API также не должны возвращаться лишние данные: если для экрана списка идентификационный номер не нужен, API не должен его предоставлять.

Пример логирования: не записывать лишнего

// Плохо: записывает персональные данные в лог
logger.info('Сотрудник обновлен', { employee });

// Хорошо: только идентификатор и названия измененных полей
logger.info('Сотрудник обновлен', { employee_id: employee.id, fields: ['phone', 'address'], actor: user.id });

Запись всего тела запроса в логи ошибок является частым источником утечек; чувствительные поля перед логированием должны маскироваться.

Оценка воздействия на защиту данных: когда она необходима?

GDPR требует проведения оценки воздействия на защиту данных (DPIA) для операций обработки с высоким риском (систематический мониторинг, данные особой категории, масштабное профилирование); в KVKK аналогичный подход, ориентированный на риски, прослеживается в решениях и руководствах Совета. Для команды разработки это означает, что в проектах, включающих отслеживание геолокации, биометрию или поддержку принятия решений на базе ИИ, до начала проектирования должна быть проведена оценка рисков совместно с юридическим отделом. Эта оценка напрямую влияет на архитектурные решения (какие данные не будут собираться, через какой срок они будут удалены).

Передача за границу: где находится сервер?

Облачные сервисы, почтовые провайдеры и аналитические инструменты могут обрабатывать данные в других странах. В Турции закон KVKK связывает передачу за границу с определенными условиями; в GDPR также существуют такие механизмы для передачи в третьи страны, как решение о достаточности или стандартные договорные положения. Конкретный вывод для команды разработки: место обработки данных каждого внешнего сервиса должно быть зафиксировано в инвентаризации, а изменение расположения (смена региона провайдера) должно рассматриваться как изменение.

Подготовка к уведомлению об инцидентах

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

Комплаенс — это не разовое мероприятие, а непрерывный процесс

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

В системах Cy Logic, обрабатывающих персональные данные (HR, табельный учет, CRM, порталы), данный чек-лист является исходным материалом на этапе проектирования, а не формой, заполняемой по завершении проекта.