Глава 169. Data Governance & Compliance

Context

Security Engineering Overview

Data governance работает только вместе с security, SRE и data platform процессами.

Data Governance & Compliance в архитектуре - это не только юридические документы, а конкретные технические решения: классификация данных, контроль доступа, data lineage, PII handling, retention/deletion и доказуемый audit trail. Цель: система, которая одновременно удобна для продукта и соответствует требованиям регуляторов.

Governance principles

Data classification first

Разделяйте данные по уровням чувствительности: PII/финансовые/медицинские/публичные. Контроли строятся на классе данных, а не только на сервисе.

Least privilege by design

Доступ к данным должен быть минимально необходимым: role-based/attribute-based access, short-lived credentials, audited elevation.

Traceability

Каждая критичная трансформация данных должна быть наблюдаемой: кто изменил, когда, из какого источника и куда ушли данные дальше.

Retention and deletion

Сроки хранения и удаление данных должны быть автоматизированы на уровне хранилищ и пайплайнов, включая бэкапы и реплики.

Multi-region / Global Systems

Compliance всегда влияет на размещение данных и cross-region маршрутизацию.

Открыть главу

Регуляторная рамка: GDPR, ФЗ-152 и другие

GDPR (EU)

Фокус: Lawful basis, data subject rights, breach notification, data minimization, privacy by design.

Нужны процессы DSAR (access/erase), data mapping, audit trail, региональные ограничения и прозрачные consent flows.

ФЗ-152 (Россия)

Фокус: Правовые основания обработки ПДн, требования к защите и организационным мерам, локальные требования к хранению/обработке.

Требуется инвентаризация ПДн, контроль трансграничной передачи, сегментация контуров и журналирование доступа.

CCPA/CPRA, PCI DSS, HIPAA (и др.)

Фокус: Права субъектов данных, отраслевые требования к защите платежей/медицинской информации.

Нужны domain-specific controls: tokenization, field-level encryption, strict retention, evidence-ready audit logs.

PII handling lifecycle

Collection: собирайте только необходимые поля, вводите purpose tags для каждого класса PII.
Storage: шифрование at-rest, отдельные ключи/политики для особо чувствительных атрибутов.
Processing: маскирование/токенизация в аналитических и не-prod средах.
Transfer: mTLS, data contracts, geo-aware routing и явный контроль межрегиональных перемещений.
Access: JIT-доступ, MFA для админских операций, регулярный recertification прав.
Deletion: каскадное удаление с проверкой downstream-копий и бэкапов.

Data lineage as architecture control

Metadata catalog

Единый реестр datasets, owners, data contracts и критичности данных.

End-to-end lineage graph

Связи source -> transform -> serving layer для impact analysis перед изменениями.

Automated policy checks

Проверки на уровне CI/CD и data platform: нельзя вывести PII в неразрешённый контур.

Incident-ready evidence

Логи lineage и access событий должны позволять быстро ответить: какие данные затронуты и где они находятся.

Compliance-ready architecture checklist

У каждого критичного dataset есть owner, sensitivity-tag и retention policy.

PII в логах и трассировке редактируется/маскируется по умолчанию.

Есть automated pipeline для DSAR-запросов (доступ/исправление/удаление).

Data lineage доступен не только команде платформы, но и security/legal owners.

Регулярные compliance reviews встроены в release governance, а не проводятся ad-hoc.

Типичные антипаттерны

Собирать избыточные PII "на будущее" без ясной lawful purpose.

Хранить чувствительные данные в telemetry/logging без redaction.

Не учитывать резервные копии и архивы в стратегии удаления данных.

Делать data lineage вручную в таблицах вместо автоматизированного графа.

Считать соответствие регуляторике задачей только legal-команды, без архитектурных ограничений в коде и платформе.

Связанные главы

Security Engineering Overview

Контекст по принципам secure-by-design и эксплуатационной безопасности.

AuthN/AuthZ

Управление доступом к чувствительным данным и привилегированным операциям.

Шифрование, ключи и TLS

Криптографические механизмы для защиты данных в хранении и передаче.

Data Pipeline / ETL / ELT Architecture

Lineage, data quality и governance в контуре трансформации данных.

Database Selection Framework

Как выбор СУБД влияет на аудит, retention и политики доступа.

Multi-region / Global Systems

Региональные ограничения и трансграничная передача данных в глобальных системах.

References

Эта глава не является юридической консультацией: проверяйте требования в вашей юрисдикции совместно с legal/compliance функцией.