Compliance начинает приносить пользу тогда, когда превращается из внешнего требования в набор архитектурных ограничений на данные и процессы.
Глава показывает, как GDPR, ФЗ-152, data lineage, PII handling, access control и аудит изменений влияют на схему данных, потоки, ретеншн, residency и способы работы команд.
В design review через этот материал удобно обсуждать data minimization, auditability и legal constraints как часть system design, а не как позднюю юридическую надстройку.
Практическая польза главы
Практика проектирования
Используйте материал по data governance, compliance требованиях и архитектурных обязанностях команд, чтобы формировать архитектурные security-требования до этапа реализации.
Качество решений
Проверяйте решения через модель угроз, security invariants и управляемость контролей в production, а не только через чеклист соответствия.
Interview articulation
Стройте ответ в формате threat -> control -> residual risk, показывая связь между бизнес-сценарием и техническими мерами защиты.
Trade-off framing
Явно описывайте компромиссы по data governance, compliance требованиях и архитектурных обязанностях команд: UX friction, latency overhead, стоимость сопровождения и требования 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
Сроки хранения и удаление данных должны быть автоматизированы на уровне хранилищ и пайплайнов, включая бэкапы и реплики.
Related
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-команды, без архитектурных ограничений в коде и платформе.
References
- GDPR (Regulation (EU) 2016/679)
- EDPB Guidelines
- Федеральный закон №152-ФЗ "О персональных данных" (ГАРАНТ)
- NIST Privacy Framework
Эта глава не является юридической консультацией: проверяйте требования в вашей юрисдикции совместно с legal/compliance функцией.
Связанные главы
- Security Engineering Overview - Дает архитектурную основу secure-by-design, на которой строятся governance-политики и compliance-контроли.
- Identification -> AuthN -> AuthZ - Связана с контролем доступа к PII, привилегированными действиями и аудитом операций с данными.
- Шифрование, ключи и TLS - Покрывает криптографическую защиту данных at-rest и in-transit, что критично для регуляторных требований.
- Data Pipeline / ETL / ELT Architecture - Дополняет тему lineage и quality-контролей в каналах трансформации и доставки данных.
- Multi-region / Global Systems - Объясняет data residency, региональные ограничения и трансграничные потоки, важные для compliance в глобальных системах.