Законы о конфиденциальности определяют проектирование

🌐 Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Изображение создано с помощью ИИ

Переведено ИИ. Сообщество еще не проверило перевод. Читать на английском

Модуль 4 из 6 главы Качество данных и управление ими, глава 5 курса Data Architect. Каждый модуль самостоятелен. Назад: Знайте свои данные · Далее: Согласие и право на забвение

Вопрос, на который отвечает этот модуль: чего законы о конфиденциальности и отраслевые нормы требуют от проекта Salesforce?

Когда я работал в Австралии, я встречал множество начинающих архитекторов, которые никогда не слышали о GDPR. Европейцы часто не слышали о законе о конфиденциальности Калифорнии, или Канады, или Бразилии. Это естественно: вы знаете правила там, где работаете. Но эти законы действуют поверх границ и формируют проектирование систем, хотя ни один из них не посвящен Salesforce. Поэтому им место в курсе по архитектуре данных.

Вам не нужно становиться юристом. Но нужно видеть, что нормативный акт может изменить, где хранятся данные, что вы собираете, кто их видит, зачем вы можете их использовать, как долго храните, куда отправляете, можете ли удалить, какую историю сохраняете и что сможете доказать потом. Это не только юридические вопросы. Это вопросы архитектуры данных.

Этот модуль — архитектурные рекомендации, а не юридическая консультация. Какие законы применяются и чего они требуют, решают юридический отдел и специалисты по соответствию требованиям. Архитектор превращает эти требования в обеспечиваемый проект.

Законы не останавливаются на границе

Сначала самое большое заблуждение: «мы не в Европе, значит, GDPR к нам не относится». Может быть, а может быть, и нет. Территориальная сфера действия GDPR (Общего регламента ЕС по защите данных) охватывает организации за пределами ЕС, которые предлагают товары или услуги людям в ЕС или отслеживают их поведение там (статья 3, Regulation (EU) 2016/679 (opens in a new tab)). Поэтому то, где находится штаб-квартира вашей компании, еще не закрывает вопрос. Где ваши клиенты, сотрудники, люди, чьи данные вы храните, ваши системы, ваши обработчики? Куда перемещаются данные? Это снова ландшафт из главы 4. Нельзя принимать хорошие решения о конфиденциальности, не зная, куда идут данные.

Нормативные акты, которые стоит узнавать

Вот названия, которые архитектор должен знать, и что каждый из них охватывает. Это таблица для узнавания, а не матрица применимости: не читайте ее с выводом «у нас есть клиенты в Калифорнии, значит, применяется требование X». Это решает юридический отдел. Ваша задача — знать достаточно, чтобы задать вопрос до того, как система построена.

Закон или стандарт	Где или что	Почему архитектору стоит его узнавать
GDPR (opens in a new tab)	Европейский союз	Персональные данные, законная обработка, права людей, хранение, передача, конфиденциальность в проектировании (privacy by design)
CCPA с поправками CPRA (opens in a new tab)	Калифорния	Права потребителей в отношении персональной информации, которую о них собирают компании
PIPEDA (opens in a new tab)	Канада	Как организации частного сектора обращаются с персональной информацией
LGPD (opens in a new tab)	Бразилия	Общий закон Бразилии о защите персональных данных
Privacy Act 1988 (opens in a new tab)	Австралия	Как организации обращаются с персональной информацией согласно Австралийским принципам конфиденциальности (Australian Privacy Principles)
HIPAA (opens in a new tab)	Здравоохранение США	Защищенная медицинская информация в охватываемых контекстах
PCI DSS (opens in a new tab)	Платежные карты	Защита данных счетов платежных карт
Sarbanes-Oxley (SOX) (opens in a new tab)	Публичные компании США	Средства контроля и доказательства, на которых держится финансовая отчетность
COPPA (opens in a new tab)	США, дети в интернете	Персональная информация, собираемая онлайн у детей

Список растет (все больше штатов США принимают собственные законы), и законы меняются. Поэтому я не хочу, чтобы вы заучили таблицу и решили, что освоили архитектуру конфиденциальности. Выучите названия, а потом выучите вопросы, которые их переживут.

Что общего у этих законов

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

Права. Люди могут попросить показать свои данные, исправить их, удалить и забрать с собой; по законам Калифорнии и Бразилии они также могут отказаться от их продажи. Каждый такой запрос означает, что нужно найти данные человека — все.

Передача данных. GDPR и LGPD контролируют персональные данные, покидающие их юрисдикцию, и требуют надлежащей защиты там, куда они попадают; PIPEDA ожидает того же уровня защиты, когда данные обрабатывает третья сторона, где бы она ни находилась. Это снова ландшафт: какие стрелки пересекают границу?

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

Подотчетность. Вы должны уметь показать соответствие требованиям: реестры того, что вы обрабатываете и зачем, оценки воздействия для обработки с высоким риском, а по GDPR и LGPD — инспектор по защите данных (data protection officer). Архитектура должна порождать эти записи.

Начните с того, что является персональным

Прежде чем защищать персональную информацию, найдите ее. Что-то очевидно: имя, домашний адрес, телефон, электронная почта. Что-то нет: местоположение, идентификаторы устройств, IP-адреса, изображения, поведенческие данные — все, что можно связать с человеком. И контекст важен. Доставка Steve Trucking несет имя получателя, адрес, номер телефона, заметки к доставке и фотографии. На фотографии может быть коробка на крыльце, или человек, или интерьер дома. Доставка — это операционные данные, но некоторые ее атрибуты персональные. Поэтому модуль 3 и классифицировал поля: конфиденциальность начинается со знания того, что вы храните.

Где они живут?

«В Salesforce». Скорее всего, не только в Salesforce. Пришли ли они от розничного партнера? Скопированы ли в Snowflake, загружены ли в Data 360, записаны ли в журнал интеграции, выгружены ли пользователем, остались ли в истории полей, отправлены ли в архив, скопированы ли в песочницу, переданы ли партнеру, использованы ли в диалоге агента? Персональные данные расползаются. Поэтому, когда юристы спрашивают «где мы храним информацию об этом человеке?», ответ «мы знаем, где текущее значение» не годится. Мне нужны ландшафт и происхождение: куда ушли копии.

Click to enlarge

Один номер телефона, много копий. Конфиденциальность относится и к копиям.

Почему вам можно их использовать?

Иметь данные и иметь право их использовать — не одно и то же. У Steve Trucking есть номер телефона получателя, чтобы согласовать сегодняшнюю доставку. Делает ли это его списком для маркетинга? Нет. Правовое основание зависит от юрисдикции и ситуации, и тут ведут юристы, но архитектура должна нести ответ: зачем данные собраны, какое использование разрешено, нужно ли было согласие, дано ли оно, отозвано ли, и для какого канала, адреса и цели. Разрешение на использование данных должно быть представимо в виде данных, потому что документ с политикой не может принять решение во время работы системы. Следующий модуль это моделирует.

Собирать меньше — это архитектурное решение

Одно из самых сильных средств защиты конфиденциальности — не собирать данные или не копировать их туда, где они не нужны. Нужен ли Snowflake номер телефона получателя? Нужен ли аналитике полный адрес? Нужны ли песочнице настоящие фотографии доставок? Нужны ли агенту персональные данные получателя, чтобы ответить на этот вопрос? Если нет, самым сильным контролем может быть просто не класть их туда. Каждая копия, которую вы не сделали, — это копия, которую не нужно защищать, хранить, удалять, отслеживать для нее согласие, проверять или включать в отчет об утечке. Дешевле всего управлять теми чувствительными данными, которые вы никогда не копировали.

Хранение — часть модели

«Пока будем хранить все» — это политика хранения. Просто плохая. Для важных данных я хочу знать уже на этапе проектирования, как долго они нам нужны и зачем; устанавливает ли один нормативный акт минимум, а другой — максимум; когда начинается отсчет; и что происходит в конце: удалить, отправить в архив, обезличить — и где копии? Финансовые записи, возможно, придется хранить установленный срок. Код от ворот получателя не нужен ни для чего через годы после доставки. Эти решения не ждут, пока база данных станет большой.

Анонимизированные, псевдонимизированные, зашифрованные, замаскированные

Замените «Jane Smith» на 7F92A1. Анонимизирована ли Jane? Нет, если в другой таблице по-прежнему написано 7F92A1 = Jane Smith. Это псевдонимизация: прямой идентификатор заменен, но данные можно снова связать с человеком с помощью информации, которая хранится отдельно, и по GDPR псевдонимизированные данные остаются персональными данными (статья 4(5)). Анонимизация идет дальше: данные больше нельзя разумными средствами связать с человеком (пункт 26 преамбулы). Поэтому, когда кто-то говорит «нам не нужно это удалять, мы просто уберем имя», будьте осторожны. Если человека по-прежнему можно разумными средствами идентифицировать, вы эту черту не пересекли. Удовлетворяет ли результат закону, решают юристы; задача архитектора — точно сказать, что делает система: можно ли снова связать данные, какие ключи остаются, где хранятся сопоставления?

Используйте эти слова точно, потому что они решают разные задачи. Шифрование защищает данные от несанкционированного раскрытия; уполномоченный пользователь все равно может их расшифровать. Маскирование меняет то, что видят определенные пользователи или среды. Псевдонимизация отделяет прямую идентифицируемость, сохраняя путь назад. Анонимизация убирает разумную возможность идентифицировать человека. Только последнее выводит данные из категории «персональных».

Нормативные акты становятся требованиями

Юристам не нужно говорить мне создать набор разрешений; это моя сторона границы. Юристы могут сказать: «доступ к этой категории персональной информации имеют только сотрудники с законной служебной необходимостью». Тогда я перевожу: кто они, как мы определяем эту категорию, как предоставляется доступ, что происходит, когда человек меняет должность, может ли ее читать интеграция, может ли агент, можно ли ее выгрузить и как мы докажем, кто ее видел? Владельцы устанавливают политику, архитекторы ее обеспечивают. Юристы и специалисты по соответствию требованиям устанавливают обязательство, владельцы данных — бизнес-политику, а архитектор проектирует обеспечение.

Click to enlarge

От нормативного акта к доказательствам: юристы толкуют, владелец устанавливает политику, архитектор делает так, чтобы это работало и было доказуемо.

И соответствие требованиям — это не продукт. Нельзя купить «соответствие: вкл.». Шифрование может поддержать требование, функции аудита дают доказательства, инструменты хранения исполняют политику, данные о согласии поддерживают разрешенное использование, но лицензия на функцию не делает архитектуру соответствующей требованиям. Соответствие складывается из всего проекта: люди, политика, процесс, данные, средства контроля и доказательства. Salesforce — его часть, но не целое. И если политика достаточно важна, чтобы ее обеспечивать, спросите, достаточно ли она важна, чтобы ее доказывать: кто открывал эту запись 17 марта, кто изменил это поле, что было в той выгрузке? Доказательствам посвящен модуль 6.

Конфиденциальность меняет ландшафт

В Steve Trucking персональные данные получателя приходят через три интеграции с партнерами. Salesforce они нужны для выполнения доставок; бригадам нужна их часть, только для своих остановок и только в день доставки; Snowflake хочет аналитику по доставкам; финансам нужно достаточно, чтобы выставить счет, но не то, что видит бригада. И один розничный партнер никогда не должен видеть получателей другого. Конфиденциальность меняет стрелки: некоторые поля не идут в Snowflake, аналитика получает менее идентифицируемую версию, бригады видят только свои остановки, сроки хранения ниже по потоку отличаются от операционных. Требование конфиденциальности не стоит рядом с диаграммой ландшафта. Оно ее меняет.

Вопросы, которые переживут нормативные акты

Нормативные акты меняются, поэтому держите при себе устойчивый набор вопросов для любых чувствительных или регулируемых данных:

• Что это? Персональные, чувствительные, финансовые, медицинские, платежные, детские или иначе регулируемые данные?
• Где они живут? Каждая копия: интеграции, история, аналитика, архивы, песочницы, журналы, использование ИИ.
• Почему нам можно их использовать? Какая цель и какое правовое основание применяются? Участвует ли согласие?
• Кто может их использовать? Люди, системы, партнеры, интеграции, агенты.
• Как долго мы их храним и что происходит в конце?
• Может ли человек осуществить свои права в отношении них? Доступ, исправление, удаление, переносимость, возражение — как предусматривает закон.
• Можем ли мы доказать, что произошло? Доступ, изменения, выгрузки, согласие, удаление, хранение.

Управление ИИ становится законом

ИИ добавляет еще одного потребителя управляемых данных. Может ли система ИИ использовать эти данные, с какой целью, для заземления (grounding), в сочетании с чем, повторять их в своих ответах, записывать в журнал где и на какой срок? Управление ИИ переходит из политики компаний в закон: Регламент Европейского союза об ИИ (AI Act, Regulation (EU) 2024/1689 (opens in a new tab)) — первый масштабный пример. Чего он требует, зависит от системы и способа использования. Направление для архитекторов ясное: ИИ не стоит вне управления данными; это еще один потребитель управляемых данных.

Что здесь решает архитектор

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

Нормативные акты не становятся архитектурой оттого, что их названия написали на слайде. Они становятся архитектурой, когда меняют то, как данные собираются, классифицируются, перемещаются, защищаются, хранятся, удаляются и как это доказывается.

Дополнительно

• Официальные источники нормативных актов даны ссылками в таблице выше (на английском, проверено 2026-10-14).
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): статья 3 (территориальная сфера действия), статья 4(5) (псевдонимизация), пункт 26 преамбулы (анонимная информация).
• Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab), EUR-Lex.