Privacy by Design

Privacy by Design (GDPR)

1) О чем это и зачем

Privacy by Design (PbD) — принцип, согласно которому приватность закладывается в продукт с самого начала: в бизнес-требования, архитектуру, код, процессы и эксплуатацию. В терминах GDPR это проявляется в «privacy by design и by default» (минимизация сборов, настройки по умолчанию — максимально приватные, прозрачность и подотчетность).

• Минимизировать сбор и обработку персональных данных (ПДн).
• Обеспечить законность, прозрачность, корректность, ограничение целей и сроков.
• Снизить риски (технические и правовые), упростить аудит и доказуемость соответствия.

2) Роли, правовые основы и принципы GDPR

2.1 Роли

Контролер (Controller): определяет цели/средства обработки.
Процессор (Processor): обрабатывает ПДн от имени контролера по договору DPA.
Субъект данных (Data Subject): физлицо, к которому относятся ПДн.
DPO (офицер по защите данных): по требованию — независимый контроль и консультации.

2.2 Правовые основания (выбираем и документируем)

Согласие, договор, законный интерес, правовая обязанность, жизненно важные интересы, общественная задача. Для каждого — цель, данные, удержание, возможность отзыва (для согласия).

2.3 Принципы обработки (ст. 5)

Законность, справедливость, прозрачность

Ограничение цели

Минимизация данных

Точность

Ограничение хранения

Целостность и конфиденциальность

Подотчетность (accountability) — умение доказать соответствие.

3) Процесс PbD в SDLC (reference framework)

1. Инициация: формулировка целей обработки и правовых оснований, назначение owner’ов данных и DPO-пойнта.
2. Картирование данных (Data Mapping): источники → поля → доверительная модель → куда текут → кто читает → где хранятся → срок.
3. Оценка рисков/DPIA: LINDDUN-модель угроз приватности, оценка воздействия, меры снижения.
4. Архитектурные решения: выбор схем минимизации, псевдонимизации, шифрования, разграничения.
5. Требования к UX/согласиям/уведомлениям: понятные тексты, granular consent, настройка по умолчанию.
6. Реализация: приватные дефолты, безопасная телеметрия, логирование без секретов/PII.
7. Верификация: тесты приватности, статический анализ, приватные unit-тесты, протоколы DPIA.
8. Эксплуатация: DSAR-процессы, ретенции и удаление, мониторинг инцидентов, ревью поставщиков.
9. Регулярный пересмотр: re-DPIA при изменении целей/технологий.

4) Инженерные паттерны PbD

4.1 Минимизация и декомпозиция

Собирать только необходимые поля; применять progressive profiling.
Разделяйте идентификатор и контент: храните ключ связи отдельно (token/reference).

4.2 Псевдонимизация и анонимизация

Псевдонимизация: храните реальный идентификатор отдельно; рабочий слой видит токен.
Анонимизация: используйте k-анонимность, l-diversity, t-closeness; для аналитики — дифференциальная приватность (ε-budget).

4.3 Контроль доступа и разделение ролей

PoLP, ABAC/RBAC, segregation of duties, отдельные контуры для админов и аналитиков.
Тех. меры: mTLS, SSO/OIDC, scoped-токены, временные учетки для доступа к ПДн.

4.4 Шифрование и изоляция

In Transit: TLS 1.3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Отдельные ключи на арендатора/датасет; крипто-удаление для «права на забвение».

4.5 Ретенция и удаление

Явные политики TTL per поле/цели; auto-purge в пайплайнах; «двухфазное» удаление (логическое → физическое).
Для бэкапов — раздельные ключи и короткие окна хранения персональных снапшотов.

4.6 Приватная телеметрия и логирование

По умолчанию — без PII; использовать токены/хэширование с солью.
Маскирование/токенизация чувствительных полей на продьюсере.

4.7 UX приватности и согласия

Granular consent по категориям (аналитика, маркетинг, персонализация).
«Приватные дефолты»: все не критичное — выключено, пока не согласился.
Четкая опция «Отозвать согласие» и just-in-time уведомления при новом использовании.

5) DPIA и LINDDUN (коротко)

DPIA (оценка воздействия на защиту данных): требуется при высокой рисковости (масштабный мониторинг, оценка, новая технология). Состоит из описания обработки, необходимости/пропорциональности, оценки рисков, мер снижения.
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Для каждой угрозы — контрмеры (минимизация, псевдонимизация, DP, прозрачность, управление согласиями, аудит).

6) Трансграничные передачи

Выяснить локации хранения/доступа поставщиков.
Использовать SCC (стандартные договорные положения) и проводить Transfer Impact Assessment.
Техмеры: end-to-end шифрование, клиентская криптография для особо чувствительных данных, ограничение удаленного доступа.

7) Поставщики и процессоры (Vendor Management)

DPA/вложенные процессоры, технические и организационные меры, субпроцессоры — под контроль.
Регулярные ревью и аудиты; право на инспекцию; план выхода/миграции (data export).

8) Права субъектов данных (DSAR)

Доступ, исправление, удаление, ограничение, переносимость, возражение, не быть объектом AADM (профилирование/автоматизация).
SLA и автоматизация: трекинг запросов, доказательство идентификации, журнал ответов.
Технические хуки в продукте: быстрый поиск и экспорт по идентификатору; каскадное удаление по ретенциям.

9) Автоматизированные решения и профилирование (ст. 22)

Если решения с «значительным воздействием» принимаются автоматом — обеспечить право на вмешательство человека, объяснимость, прозрачность признаков.
Log-путь и версионирование моделей; механизм апелляции.

10) Безопасность обработки (ст. 32) и инциденты (ст. 33/34)

Риск-ориентированные меры: шифрование, целостность, устойчивость, планы восстановления (RTO/RPO).
Инциденты с ПДн: процесс обнаружения → триаж → оценка риска → уведомление регулятора ≤ 72 часов (где требуется) и субъектов (если высокий риск).
Отдельный плейбук, контакт-лист DPO/юристов, шаблоны уведомлений.

11) Приватность и ML/аналитика

Data Governance наборов: дата-линейдж, лицензии/основания, согласия.
Техники: дифференциальная приватность, federated learning, secure aggregation, минимизация фичей.
Защита от атак: membership/model inversion — регулярные оценки утечек, настройка ε, шум/clip.
Синтетические данные — только с проверкой отсутствия восстановления персон.

12) Архитектурные схемы (паттерны)

12.1 «Двухконтурная» архитектура идентификаторов

Контур A (PDS — Personal Data Store): реальные идентифицирующие данные (РИД), доступ — строго ограничен, ключи/шифрование/аудит.
Контур B (Operational): бизнес-данные с токенами; связи через брокер токенов с лимитами и аудитом.

12.2 Шина согласий (Consent Service)

Централизованный сервис, хранящий версии согласий и историю.
SDK: `can_use(category, purpose)` — решает на лету; все логируется.

12.3 Политики ретенции как код

Конфигурация YAML: сущность → поля → TTL → действие при истечении (анонимизация/удаление/огрубление).
Планировщик выполняет job’ы, отчетность доступна DPO.

13) Мини-рецепты

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) Документация и подотчетность

ROPA (Records of Processing Activities) — реестр операций: цель, правовое основание, категории данных/субъектов, передачи, сроки хранения, меры.
Политики: приватность, куки, информационные уведомления в продукте (на понятном языке).
Обучение персонала и ежегодные ревью.

15) Частые ошибки

Сбор «на всякий случай» и хранение «навсегда».
Согласие как единственное основание, хотя подходит договор/законный интерес.
«Пустые» баннеры cookie без реальных переключателей.
Отсутствие картирования данных и неготовность к DSAR.
Логи с PII, незащищенные бэкапы, смешение РИД и операционных данных.
Нет контроля поставщиков и трансграничных передач.

16) Чек-листы

• Определены цель обработки и правовое основание; обновлен ROPA.
• Выполнено картирование данных и DPIA (при необходимости).
• Реализованы минимизация, псевдонимизация, шифрование (в пути/на покое).
• Согласия — гранулярные, с понятным UX; дефолты — приватные.
• Настроены политики ретенции как код; удаление/анонимизация проверены.
• Логи/телеметрия — без PII; маскирование включено.
• Подготовлены DSAR-хуки и экспорт.
• Проведено обучение команды и утверждение DPO.

• Ежеквартальный обзор ретенций и правовых оснований.
• Периодический аудит процессоров/субпроцессоров.
• Мониторинг инцидентов и готовность к уведомлению ≤ 72 ч.
• Пересмотр DPIA при изменениях процессов/технологий.
• Хранение артефактов соответствия (DPIA, ROPA, отчеты тестов).

17) FAQ

В: Можно ли полностью «убежать» от согласий?
О: Иногда — да (договор/законная обязанность/законный интерес), но только при строгой необходимости и с оценкой баланса интересов. Маркетинг и некритичная аналитика — чаще всего требуют согласия.

В: Достаточно ли псевдонимизации?
О: Нет, это все еще персональные данные. Для выхода из сферы GDPR нужна надежная анонимизация (проверяемая на невозможность повторной идентификации).

В: Как быть с ML и персонализацией?
О: Минимизируйте фичи, используйте DP/federated подходы, логируйте решения, обеспечьте право на вмешательство человека и отказ от профилирования.

В: Что делать при конфликте бизнеса и приватности?
О: Перепроектировать сбор (progressive profiling), переключиться на агрегаты/синтетику, переоценить правовое основание, предложить опцию без трекинга.

• «Менеджмент секретов»
• «Шифрование At Rest»
• «Шифрование In Transit»
• «Аудит и неизменяемые журналы»
• «Подпись и верификация запросов»
• «Управление ключами и ротация»