Соответствие требованиям начинает приносить пользу тогда, когда превращается из внешней проверки в набор архитектурных ограничений на данные и процессы.
Глава показывает, как GDPR, ФЗ-152, происхождение данных, обработка персональных данных, контроль доступа и аудит изменений влияют на схему данных, потоки, сроки хранения, размещение данных и способы работы команд.
На ревью дизайна через этот материал удобно обсуждать минимизацию данных, проверяемость решений и регуляторные ограничения как часть системного дизайна, а не как позднюю юридическую надстройку.
Практическая польза главы
Практика проектирования
Проектируйте классификацию данных, владельцев, сроки хранения, удаление и контроль доступа как часть архитектуры, а не как документацию после релиза.
Качество решений
Проверяйте, можно ли доказать происхождение данных, правовое основание обработки, доступы и соблюдение правил хранения.
Аргументация на интервью
Стройте ответ вокруг маршрута данных: сбор, хранение, обработка, передача, доступ, удаление и аудит.
Формулировка компромиссов
Явно обсуждайте цену ограничений: удобство продукта, скорость аналитики, стоимость хранения, сложность удаления и регуляторный риск.
Контекст
Security Engineering Overview
Управление данными работает только вместе с безопасностью, инженерией надёжности сервисов (SRE) и процессами платформы данных.
и соответствие требованиям проигрывают, когда остаются пачкой юридических документов: к моменту проверки оказывается, что в коде и хранилищах их никто не реализовал. В архитектуре это конкретные технические решения — классификация данных, контроль доступа, происхождение данных, обработка персональных данных, сроки хранения, удаление и доказуемый журнал аудита. Граница простая: система должна остаться удобной для продукта и при этом выдержать регуляторную проверку, а не разваливаться на первом же запросе от регулятора.
Принципы управления данными
Классификация данных
Разделяйте по уровню чувствительности: публичные, финансовые, медицинские и . Без явного класса меры защиты привязываются к сервису, и одни и те же персональные данные в разных сервисах защищаются по-разному — это и есть дыра, которую находит проверка.
Минимально необходимые права
Широкий доступ «чтобы не блокировать команды» — это список людей, который придётся объяснять при расследовании утечки. Сужайте права точечно: ролевая или атрибутная модель, , и регулярное .
Прослеживаемость
Когда регулятор спрашивает, откуда взялось конкретное значение, ответ «посмотрим в коде» не подходит. По критичным преобразованиям держите : кто изменил данные, когда, из какого источника и куда они ушли дальше. Это фиксируется в .
Сроки хранения и удаление
Удаление «по тикету раз в квартал» гарантированно пропустит копию в бэкапе или реплике, и эта копия всплывёт на проверке. и автоматизируйте на уровне хранилищ, конвейеров, резервных копий и реплик.
Связано
Multi-region / Global Systems
Соответствие требованиям влияет на размещение данных, региональные ограничения и маршрутизацию между регионами.
Регуляторная рамка: GDPR, ФЗ-152 и другие
GDPR (EU)
Фокус: , , , и .
В архитектуре это , , , региональные ограничения и понятный .
ФЗ-152 (Россия)
Фокус: Правовые основания обработки , требования к защите, организационные меры и ограничения на хранение или обработку.
На уровне платформы это инвентаризация персональных данных, контроль , сегментация контуров и журналирование доступа.
CCPA/CPRA, стандарт PCI DSS, HIPAA (и др.)
Фокус: и отраслевые требования к защите платёжной, медицинской и другой регулируемой информации.
Нужны профильные меры: , , строгие и готовые к проверке журналы аудита.
Жизненный цикл персональных данных
- Сбор: собирайте только необходимые поля и фиксируйте цель обработки для каждого класса персональных данных.
- Хранение: применяйте шифрование при хранении, отдельные ключи и политики для особо чувствительных атрибутов.
- Обработка: используйте , маскирование и в аналитических и тестовых контурах.
- Передача: защищайте каналы через по протоколу защиты транспортного уровня (), и явный контроль межрегиональных перемещений.
- Доступ: выдавайте права через доступ по запросу, для администраторов и регулярное ревью доступа.
- Удаление: проверяйте каскадное удаление в нижестоящих копиях, витринах, резервных копиях и архивах.
Происхождение данных как архитектурный контроль
Каталог данных
Единый хранит наборы данных, , и .
Сквозной граф происхождения
Связи от источника через преобразования до дают заранее увидеть, кого заденет изменение, — какие потребители и какие регуляторные обязательства, — до того как оно уедет в прод.
Автоматические проверки политик
Проверки на уровне конвейера сборки и доставки (CI/CD) и не дают вывести персональные данные в неразрешённый контур — нарушение ловится до выкатки, а не постфактум по жалобе.
Доказательства для аудита
и журнал происхождения должны быстро отвечать, какие регулируемые данные затронуты и где они находятся.
Чек-лист архитектуры, готовой к проверке
У каждого критичного набора данных есть владелец, метка чувствительности и .
Персональные данные в логах, метриках и трассировках маскируются или удаляются по умолчанию.
Есть автоматизированный путь для запросов субъектов данных: доступ, исправление и удаление.
Прослеживаемость происхождения данных доступна командам безопасности, продукта и регуляторного сопровождения, а не заперта внутри платформенной команды, к которой все ходят за выгрузками.
встроены в , а не проводятся вручную после релиза.
Типичные антипаттерны
Собирать избыточные персональные данные «на будущее» без ясной цели и правового основания обработки.
Хранить чувствительные данные в телеметрии или логах без маскирования и редактирования.
Не учитывать резервные копии и архивы в стратегии удаления данных.
Вести происхождение данных вручную в таблицах вместо автоматизированного графа.
Считать соответствие требованиям задачей только юристов, без архитектурных ограничений в коде и платформе.
Источники
- GDPR (Regulation (EU) 2016/679)
- EDPB Guidelines
- Федеральный закон №152-ФЗ "О персональных данных" (ГАРАНТ)
- NIST Privacy Framework
Эта глава не является юридической консультацией: проверяйте требования в вашей юрисдикции вместе с юридической функцией и ответственными за соответствие требованиям.
Связанные главы
- Security Engineering Overview - Даёт архитектурную основу безопасного проектирования, на которой строятся политики управления данными и проверки соответствия требованиям.
- Identification -> AuthN -> AuthZ - Связана с контролем доступа к персональным данным, привилегированными действиями и аудитом операций с данными.
- Шифрование, ключи и протокол защиты транспортного уровня (TLS) - Покрывает криптографическую защиту данных при хранении и передаче, что критично для регуляторных требований.
- Архитектура конвейеров данных: извлечение, преобразование и загрузка (ETL и ELT) - Дополняет тему происхождения данных и контроля качества в каналах трансформации и доставки данных.
- Multi-region / Global Systems - Объясняет территориальное размещение данных, региональные ограничения и трансграничные потоки в глобальных системах.