Передача данных между странами и регионами

1) Что считается трансграничной передачей и почему это важно

• хостинг/репликация в другом регионе,
• удаленный доступ третьей стороны (включая саппорт/админдоступ),
• маршрутизация через глобальные облачные сервисы, CDN, диагностические/аналитические SDK.

В iGaming/финтехе трансграничность влияет на лицензирование, партнерства с PSP/банками и риск-профиль инцидентов.

2) Правовые основы (обобщенная модель)

1. Законность обработки у источника: цель, основание (договор/обязанность/легитимный интерес/согласие), минимизация и ретеншн.

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

3. Дополнительные меры защиты: тех/орг меры, подтверждающие, что риски доступа третьих сторон и госорганов снижены до приемлемого уровня.

3) DTIA: оценка переноса (Data Transfer Impact Assessment)

DTIA отвечает на вопросы: «Куда передаем? Кто получает? Какие законы/риски доступа к данным? Достаточны ли наши меры?»

1. Операция и контекст (категории ПД/субъектов, цели, объемы, частота).

2. Получатели и цепочка сабпроцессоров (локации, роли, субобработчики).

3. Правовой анализ страны-получателя (риски госдоступа, процедуры запроса данных, средства правовой защиты).

4. Технические/организационные меры: шифрование, разделение ключей, псевдонимизация, ограничения доступа.

5. Остаточный риск и решение: «передавать/усилить меры/не передавать».

6. План мониторинга: пересмотры по событиям (смена провайдера/гео/закона).

4) Типовые механизмы передачи (по аналогии с GDPR и эквивалентами)

Адекватность: можно передавать без доп. договорных инструментов, но с базовыми мерами (минимизация, шифрование, ретеншн).
Стандартные договорные положения (SCC/аналог): контрактные гарантии + DTIA + допмеры.
Корпоративные правила (BCR): для транснациональных групп; требуют одобрения регулятора и зрелой внутренней программы приватности.
Иные основания: явное согласие, необходимость для договора с субъектом, важные общественные интересы — узкие и плохопереносимые в операционку.

5) Технические и организационные меры (конструктор)

Криптография и ключи

Шифрование in transit и at rest; минимально TLS 1.2+/AES-256.
Split-key / envelope encryption: ключи остаются в стране происхождения (KMS/HSM «дома»), в стране-получателе — только оберточные ключи.
Клиентское шифрование для особо чувствительных наборов.

Де-идентификация

Псевдонимизация до передачи: стабильные токены вместо PII; запрещен прямой джойн с PII в стороне получателя.
Анонимизация/агрегация для аналитики и отчетности (где возможно); дифференциальная приватность для публикаций.

Доступ и эксплуатация

JIT-доступы, RBAC/ABAC, контроль экспортов (DLP), WORM-логи.
Запрет прод-ПД в dev/stage; синтетика или маскирование.
Гео-ограничения и IP allowlist для админдоступов.

Контроль вендоров

DPA/договор с запретом вторичных целей и onward transfer без согласия.
Реестр субпроцессоров с географией; SLA уведомлений об инцидентах.
Ежегодные ревью/аудиты; мониторинг изменений юрисдикций/хостинга.

6) Архитектурные паттерны «data/key residency»

• «EU-only» / «BR-only» / «IN-only» кластеры; синхронизация анонимных агрегатов во «всемирный» DWH.
• Гео-шардинг с маршрутизацией по происхождению пользователя и месту лицензии.

• Данные могут храниться глобально в шифрованном виде, а ключи — только в стране происхождения (split-key, remote KMS).
• Запросы на дешифрацию проходят через авторизованный «ключевой прокси» с аудитом и квотами.

• Server-side analytics и серверные постбеки (аффилиаты/атрибуция) вместо «жирных» браузерных SDK.
• Edge-слой с редактированием событий (удаление PII) до попадания в глобальные пайплайны.

7) Региональные особенности (высокоуровнево)

Европейский подход (GDPR): глава о передаче + DTIA; особое внимание к доступу госорганов и средствам правовой защиты.
США (штатные режимы конфиденциальности): акцент на «продаже/совместном использовании» и договорных ограничениях у третьих лиц; отдельные сигналы (например, GPC) для рекламных сценариев.
Бразилия (LGPD): допускает передачу при адекватности/договорных гарантиях/сертификации/согласии; практики схожи с европейскими (RIPD для рискованных обработок).
Индия, Азия и др.: возможны локальные требования к хранению копий, регистрация/уведомления регуляторам, ограничения по «чувствительным» наборам — проверяйте отраслевые нормы и условия лицензий/платежных партнеров.

(Раздел намеренно обобщен: перед запуском обязательно актуализируйте локальное право и требования ваших лицензий и PSP.)

8) Что документировать (артефакты)

Реестр передач: страны/провайдеры/механизм (адекватность/SCC/BCR/иное)/категории ПД/основания/сроки.
DTIA по каждой передаче (и обновления при изменениях).
DPA/контракты с процессорами/сабпроцессорами; список субпроцессоров по регионам.
Политика key residency и схемы KMS/HSM.
Процедуры инцидентов с учетом географии и сроков уведомлений.
Data map/lineage для каскадов и экспортов.

9) Инциденты и уведомления при трансграничной передаче

Быстро определить объем и географию затронутых ПД, применимые регуляторы/сроки уведомлений.
Скоординировать действия с провайдерами/сабпроцессорами; получить технические артефакты (логи, временные окна, ключи доступа).
Коммуникации — «минимально достаточные», без раскрытия лишнего; для затронутых субъектов — понятные рекомендации (смена паролей, контроль транзакций и т. п.).
Пост-морем: обновление DTIA, усиление мер, корректировка договоров.

10) Метрики и контроль качества

DTIA Coverage — доля передач с актуальными оценками воздействия.
Key Residency Enforcement — % дешифраций, прошедших через региональный KMS.
Vendor Geo Accuracy — совпадение обещанной и фактической географии обработки.
Export Violations — попытки/факты несанкционированных экспортов.
Incident MTTD/MTTR по трансграничным кейсам.
RoPA/Transfer Registry Completeness — полнота реестров.
Retention Adherence для данных, переданных за рубеж.

11) Чек-листы (операционные)

Перед стартом передачи

• Цель/основание/минимизация определены, внесено в RoPA.
• Выбран механизм: адекватность / SCC (или аналог) / BCR / иное.
• Проведен DTIA, приняты допмеры (шифрование, split-keys, псевдонимизация).
• DPA/контракты с ограничениями onward transfer, право аудита.
• Настроены логирование доступов, DLP, алерты экспортов.

В эксплуатации

• Мониторинг географии (провайдеры/реплики/CDN/SDK).
• Ежегодный/событийный пересмотр DTIA и списков сабпроцессоров.
• Тесты восстановления/санитизации при DR-сценариях.

При изменениях

• Re-DTIA при смене страны/провайдера/правового режима.
• Обновление реестров и уведомление DPO/юристов.
• Проверка «key residency» и маршрутов дешифрации.

12) Матрица «категория данных → мера защиты → можно ли передавать»

13) Шаблоны для вашей wiki/репозитория

DTIA-Template.md (разделы 1–6 + чек-лист допмер).
Transfer-Registry.xlsx/MD (операция → страна → провайдер → механизм → меры).
Key-Residency-Policy.md (архитектура KMS/HSM, роли, аудит).
Vendor-DPA-Checklist.md (ограничения, сабпроцессоры, локации, уведомления).
DR-Sanitization-Runbook.md (как чистить восстановленные окружения).
Geo-Monitoring SOP (как контролировать фактическую географию).

14) Дорожная карта внедрения (6 шагов)

1. Инвентаризация передач: источники ПД, получатели, маршруты, SDK/теги.
2. Юридический контур: выбор механизмов (адекватность/SCC/BCR), подготовка DPA, запуск реестра.
3. DTIA и допмеры: крипто-архитектура (split-keys, key residency), псевдонимизация, DLP/аудит.
4. Архитектура «data residency»: гео-кластеры, правила маршрутизации, server-side analytics.
5. Операции и мониторинг: гео-мониторинг провайдеров/сабпроцессоров, DR-санитизация, метрики.
6. Аудиты/обучение: ежегодный пересмотр DTIA/реестров, тренировки инцидентов, отчеты для руководства.

Итог

Управление трансграничной передачей — это не «галочка в договоре», а комбинация юридических механизмов, крипто-архитектуры и операционной дисциплины. Четкий DTIA, договорные ограничения, «data/key residency», псевдонимизация и контроль вендоров позволяют безопасно масштабировать продукт по регионам, не теряя скорость и соответствие требованиям регуляторов и платежных партнеров.