Privacy by Design: принципы проектирования

1) Зачем это нужно (цель и область)

PbD гарантирует, что приватность встроена в продукт по умолчанию, а не «наклеена» сверху. Для iGaming это снижает регуляторные риски (GDPR/ePrivacy/локальные законы), защищает уязвимых пользователей, повышает доверие и снижает стоимость инцидентов. Охват: веб/мобайл, KYC/AML/RG, платежи, маркетинг/CRM, аналитика/DWH, логи/APM, партнеры/вендоры.

2) Семь принципов (и как их приземлить в операциях)

1. Проактивность, не реактивность

Threat modeling (LINDDUN/STRIDE) на этапе discovery.
Privacy-acceptance критерии в Jira/PR шаблонах.

2. Приватность по умолчанию (Privacy by Default)

Все тумблеры маркетинга/персонализации — off, пока нет согласия.
Сбор только «строго необходимых» идентификаторов по умолчанию.

3. Приватность встроена в дизайн

PII хранится в региональном контуре (data residency), control plane — без PII.
Токенизация/псевдонимизация ключей в сервисных событиях.

4. Полная функциональность (win-win)

Режимы «анонимной аналитики» и «персонализации с согласием».
Равный UX без дискриминации отказавшихся от трекинга.

5. Безопасность сквозь жизненный цикл

Шифрование at rest/in transit; BYOK/HYOK; сегментация сетей; секрет-менеджмент.
WORM-журналы для доказательств и аудита.

6. Прозрачность

Короткие политики и «summary box» ключевых условий; панель приватности в профиле.
Отчетность: кто/что/когда/зачем доступался к данным.

7. Ориентация на пользователя

Простые тексты, отсутствие темных паттернов, доступность WCAG AA+.
Легкий отзыв согласия и удобные каналы DSAR.

3) Роли и RACI

DPO/Head of Compliance — политика PbD, DPIA/TRA, контроль рисков. (A)

Security/Infra Lead — криптография, доступы, журналы, вендоры. (R)

Product/UX — privacy-требования в фичах, отсутствие dark patterns. (R)

Engineering/Architecture — токенизация, изоляция tenant/region, API-контракты. (R)

Data/Analytics — де-PII конвейеры, PETs, агрегирование. (R)

Legal — правовые основания, тексты и локали. (C)

Marketing/CRM — согласия/ suppression, честные коммуникации. (R)

Internal Audit — выборки артефактов, CAPA. (C)

4) Классификация и таксономия данных

PII базовые: ФИО, e-mail, телефон, адрес, дата рождения, IP/ID устройства.
Чувствительные PII: биометрия (селфи/живость), KYC-документы, платежные реквизиты, RG/SE статусы.
Операционные: игровые события, логи/трейсы (PII-free по умолчанию).
Маркетинг/аналитика: идентификаторы cookies/SDK (по согласию).

Правила: минимизация, раздельное хранение, явная цель и срок хранения.

5) Жизненный цикл данных (Data Lifecycle)

1. Сбор — только необходимые поля; CMP/согласия; проверки возраста.
2. Передача — TLS 1.2+/mTLS, подпись вебхуков, региональный роутинг.
3. Хранение — шифрование, токенизация, ротация ключей, изоляция по рынкам.
4. Использование — RBAC/ABAC, «need-to-know», PETs для аналитики.
5. Обмен — DPA/SCC, минимальные наборы, аудируемые каналы.
6. Ретенция/удаление — срок по категории; каскадные delete jobs; крипто-удаление архивов.
7. Отчетность/аудит — логи доступа и экспорта, артефакты DPIA/DSAR.

6) DPIA/TRA (как делать коротко)

Триггеры: новые категории PII, особые категории, новые вендоры, трансграничные передачи, высокие риски RG/биометрии.
Шаблон DPIA: цель → категории данных → правовое основание → потоки/карта → риски → меры (тех/орг) → остаточный риск → решение.
Артефакты: диаграмма потоков, список полей, таблица рисков, протокол согласований.

7) Архитектурные паттерны PbD

Tenant/Region Isolation: физическая/логическая сегрегация БД, ключей и секретов.
Control vs Data Plane: глобальный контроль — без PII; PII только локально.
De-PII Pipeline: перед экспортом в DWH — хэш/соль, усечение, k-анонимность/кохортирование.
Tokenization Gateway: токены вместо первичных идентификаторов в сервис-шине.
Edge без PII: CDN/edge-кэш — только публичный контент.
Fail-Closed: неизвестный `player_region` → запрет операций с PII.

8) Технические меры и стандарты

Шифрование: AES-256/GCM at rest; TLS 1.2+/1.3; PFS.
Ключи: KMS, BYOK/HYOK, ротация, доступ по HSM-ролям, журнал ключевых операций.
Доступ: RBAC/ABAC, JIT-доступы, раздельные админ- и аудит-роли.
Журналы: неизменяемые (WORM), хеш-цепочки, хранение в регионе.
DevSecOps: секреты в Vault, SAST/DAST, линтер PII-полей, privacy-тесты в CI.
Тест-данные: синтетика по умолчанию; если ре-данные — де-идентификация и короткая ретенция.

9) PETs (Privacy-Enhancing Technologies)

Псевдонимизация: замена ID на токены; ключ-мап хранится отдельно.
Анонимизация: агрегаты, k-анонимность/ℓ-diversity, бининг/кохорты.
Дифференциальная приватность: шум на отчетах, «privacy budget».
Федеративная аналитика: локальные модели, экспорт только весов/агрегатов.
Маскирование/редакция: удаление EXIF, затирка полей в KYC-документах.

10) UX без темных паттернов

Равная заметность «Отклонить все»/«Принять все»/«Настроить».
Понятные тексты целей и примеры использования данных.
Отказ от персонализации не ухудшает базовый опыт.
Панель приватности в 1–2 клика отовсюду; доступность AA+.

11) Вендоры и передача данных

Реестр вендоров: юрисдикции DC, суб-процессоры, сертификация, регионы хранения, DPA/SCC/IDTA.
Политика «минимального набора»: только нужные поля, запрет свободного экспорта.
Уведомление и пересмотр при смене локаций/суб-процессоров.

12) Данные и события (минимальная модель)

data_asset{id, category{KYC    PCI    RG    CRM    LOG    ANON}, region, owner, retention_days, lawful_basis, pii{yes/no}}
processing_event{id, actor, purpose, lawful_basis, started_at, ended_at, records_count, export{yes/no, basis_id}}
access_log{id, subject_id_hash, actor, action{read/write/export/delete}, ts_utc, reason, ticket_id}
erasure_job{id, subject_id_hash, scope, started_at, completed_at, evidence_id}

13) KPI/KRI и дашборд PbD

PII Minimization Index (среднее число PII-полей на фичу).
Residency Coverage (% записей в правильном регионе).
Export Justification Rate (сколько экспортов со ссылкой на основание).
DSAR SLA (медиана выполнения/точность).
Tag Firing Violations (теги без согласия).
Auditability Score (% кейсов с полным пакетом артефактов).
Incidents/Findings (повторяющиеся замечания аудита/регулятора).

14) Чек-листы

A. Перед разработкой фичи (Design)

• Определены цели и правовые основания обработки.
• Карта данных и список полей с пометкой PII/чувствительные.
• DPIA/TRA выполнены; остаточные риски приняты.
• Продуман «анонимный режим» или режим с минимумом данных.

B. Перед релизом (Build/Release)

• Секреты в менеджере, ключи/шифрование настроены.
• Логи без PII; события и аудит включены.
• Региональный роутинг и политика retention активны.
• Тесты: consent-гейты, deny-by-default для тегов, erasure-путь.

C. В операциях

• Квартальные ревью доступов и экспортов.
• Мониторинг firing-нарушений и трансграничных запросов.
• DSAR/удаления выполняются в срок; артефакты сохраняются.

15) Шаблоны (быстрые вставки)

A) Шаблон DPIA (короткий)

B) Политика минимизации полей

C) Клауза с вендором (PbD-обязательство)

D) Ответ на DSAR (выдержка)

16) Частые ошибки и как их избежать

Сбор «на всякий случай». → Политика минимизации + код-ревью схем.
Сырые логи с PII в APM. → Маскирование/редакция на агенте, локальные хранилища.
Глобальный DWH с PII. → Только де-PII агрегаты/псевдонимы.
Отсутствие артефактов DPIA/consent. → WORM-репозиторий, авто-снимки UI/текстов.
Неучтенные вендоры/SDK. → Ежеквартальный реестр, запрет «серых» подключений.

17) 30-дневный план внедрения

Неделя 1

1. Утвердить PbD-политику и шаблоны DPIA/TRA.
2. Построить карту данных/потоков по ключевым зонам (KYC/PCI/RG/CRM/Логи).
3. Выделить региональные периметры (EU/UK/…); определить модель ключей (BYOK/HYOK).

Неделя 2

4) Включить токенизацию/де-PII конвейеры и deny-by-default для тегов.
5) Настроить WORM-журналы (доступы/экспорты/consent/удаления).
6) Обновить договоры с вендорами (DPA/SCC, локации, суб-процессоры).

Неделя 3

7) Внедрить privacy-тесты в CI (линтер PII, скрин-фиксация CMP, erasure-E2E).
8) Релиз панели приватности в профиле; улучшить тексты и локали.
9) Провести обучение команд (Product/Eng/Data/CS/Legal).

Неделя 4

10) Провести DPIA-ревью топ-фич, закрыть CAPA.
11) Запустить дашборд KPI/KRI (Residency, Exports, DSAR SLA).
12) План v1.1: дифф. приватность для отчетов, федеративные пайплайны.

18) Взаимосвязанные разделы

GDPR: управление согласием пользователей / Политика cookies и CMP

Локализация данных по юрисдикциям

Проверка возраста и возрастные фильтры

AML/KYC и хранение артефактов

Дашборд комплаенса и мониторинг / Регуляторные отчеты

Внутренний/внешний аудит и аудиторские чек-листы

BCP/DRP / Шифрование At Rest & In Transit