4.5 Приватность и защита данных

Обзор и мотивация

Безопасность защищает данные от несанкционированного доступа. Приватность задаёт другой вопрос: следует ли вам вообще собирать, использовать и хранить эти данные и есть ли у людей, которых они описывают, право голоса? Эти две области пересекаются, но не одно и то же. Можно быть совершенно безопасным и всё же нарушать приватность. Это делается накоплением данных, которые вы не вправе держать, использованием их в целях, на которые люди никогда не соглашались, или перемещением через границы способами, запрещёнными законом. Для больших команд приватность проектное ограничение. Она касается каждого сервиса, обрабатывающего персональную информацию, а сегодня это почти все.

Ставки высоки и растут. Регулирование приватности распространилось по всему миру. Оно несёт штрафы, растущие с выручкой, и даёт отдельным людям принудительно осуществимые права над их данными. Для корпораций небрежное обращение с персональными данными приглашает регуляторные действия, коллективные иски и потерю доверия клиентов, дорогую для восстановления. Для государства обязанность ещё тяжелее. Граждане не могут выбрать другого поставщика своих налоговых, медицинских данных или данных о пособиях, поэтому государство обязано им особой заботой. А провалы приватности разъедают общественное доверие, от которого зависит государство.

Эта глава воспринимает приватность как инженерную дисциплину. Мы охватываем проектирование под приватность с самого начала, ответственную минимизацию и хранение данных, классификацию и защиту чувствительных категорий вроде PII и PHI, обращение с согласием и правовым основанием и управление требованиями к трансграничной передаче и местонахождению данных, всё сильнее определяющими архитектуру.

См. также: глава 4.6 (соответствие требованиям и управление), глава 7.1 (стратегия данных и управление) и глава 4.1 (основы безопасности и культура).

Ключевые принципы

Приватность по замыслу и по умолчанию. Закладывайте приватность с самого начала и делайте самую защищающую приватность настройку значением по умолчанию.
Минимизация данных. Собирайте только то, что действительно нужно, храните только пока нужно и делитесь только при необходимости.
Ограничение цели. Используйте данные только для конкретных целей, раскрытых при сборе.
Правовое основание. Имейте действительное правовое обоснование для каждой деятельности по обработке.
Права личности. Уважайте права людей на доступ, исправление, удаление и перенос их данных.
Прозрачность. Говорите людям прямо, что вы собираете, зачем и с кем делитесь.
Подотчётность. Умейте продемонстрировать соответствие, а не просто заявлять о нём.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Агрессивная минимизация данных	Меньше риск, меньше воздействие утечки, проще соответствие	Может ограничить аналитику и будущие варианты продукта
Долгое хранение	Богатая история для аналитики, ML, споров	Больше обязательство, экспозиция при взломе, сложность удаления
Токенизация	Сужает охват соответствия, защищает сырые данные	Добавленная сложность системы, хранилище токенов для защиты
Умолчания opt-in	Сильнее доверие, ясное соответствие	Меньше объёмы данных, труднее метрики роста
Региональное местонахождение данных	Выполняет юридические мандаты, строит доверие к суверенитету	Архитектурная сложность, выше стоимость, дублированная инфраструктура
Централизованное озеро данных	Мощь аналитики, единый источник	Сосредоточенный риск, труднее ограничение цели

Центральное напряжение между аппетитом бизнеса к данным и обязательством, которое представляют эти данные. Продуктовые и аналитические команды естественно хотят собирать больше и хранить дольше. Дисциплина приватности тянет в другую сторону. Зрелое разрешение переосмысляет данные как обязательство, которое нужно обосновывать, а не актив, который нужно копить. Каждое решение о сборе и хранении должно оправдывать себя против риска, который оно создаёт. Местонахождение данных добавляет измерение «стоимость против соответствия». Выполнение требований суверенитета может умножить инфраструктуру, но на некоторых рынках и в государственных контекстах это просто не подлежит обсуждению.

Вопросы для обсуждения с командой

Каков ваш срок хранения для каждого класса персональных данных и что принуждает к удалению? Данные, хранимые «на всякий случай», это данные, ждущие взлома или судебного запроса, поэтому каждому полю и каждой записи нужен определённый срок жизни, привязанный к цели. Решите расписание по типу данных, затем принуждайте к нему автоматическим удалением, а не доверяйте, что кто-то вспомнит. Для корпораций это одновременно сужает экспозицию при взломе и стоимость хранения, а для государства соответствует установленным законом обязательствам держать данные граждан не дольше, чем позволяет закон. Принесите выборку самых старых хранимых записей и спросите, кому они ещё нужны и на каком основании, потому что честный ответ нередко «никому». Если удаление ручное или отсутствует, данные копятся вечно, а ваше обязательство молча растёт в балансе.
Какие чувствительные поля вы можете токенизировать или псевдонимизировать, чтобы сократить и риск, и охват соответствия? Замена номеров карт или национальных идентификаторов токенами ограничивает сырые значения небольшим строго контролируемым хранилищем, резко сокращая системы в охвате аудитов вроде PCI-DSS. Псевдонимизация отделяет идентификаторы от остальной записи, снижая риск при сохранении полезности данных для аналитики и тестирования. Решите, какие значения высокой чувствительности оправдывают хранилище токенов (добавленная сложность, хранилище для защиты), а каким достаточно маскирования в журналах и не-эксплуатации. Принесите карту того, где сегодня текут сырые чувствительные значения, потому что каждая система, касающаяся их, система, которую вы должны защищать и проверять. Для регулируемых и государственных данных это сужение охвата один из немногих ходов, снижающих и стоимость, и риск вместе, поэтому начните с самых чувствительных полей.
Перед выпуском вашей следующей функции, что запускает оценку воздействия на защиту данных и кто её проводит? Приватность, прикрученная к законченной системе, дорога и неполна, поэтому DPIA должна проходить рано, рядом с моделированием угроз безопасности, пока вы ещё можете дёшево менять проект. Решите триггер (новая обработка в масштабе, данные особых категорий, новая цель) и назовите, кто владеет оценкой, чтобы она не провалилась в щель под давлением поставки. Настоящая DPIA может поймать избыточный сбор до запуска, например заменив точное местоположение на данные о грубом регионе без потери для продукта. Принесите предстоящую функцию и пройдите по ней: какие персональные данные она собирает, зачем и достигает ли менее навязчивый проект той же цели. Для государственных услуг, от которых граждане не могут отказаться, эта ранняя проверка часть обязанности заботы, поэтому сделайте её барьером, а не запоздалой мыслью.
Когда персональные данные пересекают границу, включая резервные копии, журналы и субобработчиков, какой правовой механизм покрывает каждое пересечение и можете ли вы это доказать? Правила местонахождения и передачи теперь определяют архитектуру не меньше любого требования производительности, а пересечения, ловящие команды, редко очевидные: журнал, отправленный в зарубежный инструмент наблюдаемости, резервная копия, реплицированная в более дешёвый регион, или субобработчик, тихо переносящий данные за рубеж. Для большой организации конкурирующие давления реальны, потому что инфраструктура, привязанная к региону, стоит больше и дублирует эксплуатацию, но одна незаконная передача может аннулировать выход на рынок или вызвать предписание об исполнении. Принесите текущую карту потоков данных, называющую каждое место, где персональные данные физически лежат или путешествуют, правовой механизм для каждой пересекаемой границы (решение об адекватности, стандартные договорные условия или эквивалент) и список субобработчиков с их местонахождением. Для государственных контекстов и контекстов суверенных данных воспринимайте местонахождение как жёсткое архитектурное ограничение, а не пункт договора, поскольку некоторые записи никогда не должны покидать аккредитованные национальные среды, а подотчётный орган не может делегировать эту обязанность поставщику.
Какое правовое основание стоит за каждой деятельностью по обработке и смогли бы вы защитить этот выбор перед регулятором завтра? Согласие лишь один из нескольких правовых фундаментов, и команды нередко по умолчанию берут его, когда договор, юридическая обязанность, публичная задача или законные интересы были бы и честнее, и долговечнее. Это важно в масштабе, потому что слабое или неверно выбранное основание может аннулировать весь конвейер, а распутывание обработки, на которую у вас не было права, гораздо дороже выбора правильного основания заранее. Открыто взвесьте конкурирующие соображения: согласие даёт людям контроль, но может быть отозвано и должно быть свободно данным, конкретным и непакетным, тогда как основание вроде законных интересов избегает усталости от согласий, но требует документированной проверки баланса. Принесите реестр, отображающий каждую деятельность по обработке на заявленное основание, подтверждающие его свидетельства и то, как бы вы отозвали или сменили его, если бы оспорили. В государстве большая часть основной обработки опирается на публичную задачу, а не согласие, поэтому будьте точны там, где начинается необязательное отзываемое согласие, потому что смешение двух подтачивает доверие, которое граждане вынуждены оказывать.
Если бы человек сегодня воспользовался правом на доступ, удаление или переносимость, могли бы вы удовлетворить это по каждой системе в установленный законом срок? Права личности легко обещать в политике приватности и трудно выполнять в архитектуре, рассыпавшей копии персональных данных по резервным копиям, кэшам, аналитическим хранилищам и нижестоящим сервисам. Для большой команды это момент, когда абстрактное соответствие становится конкретным инженерным тестом, а пропущенный установленный законом срок и подлежащий отчёту отказ, и сигнал, что вы не видите собственных данных. Конкурирующее соображение стоимость и сложность, поскольку построение настоящего стирания и экспорта между системами реальная работа, но альтернатива ручное, медленное, подверженное ошибкам исполнение, не масштабирующееся и тихо нарушающее закон. Принесите честное прохождение одного настоящего запроса от приёма до завершения, включая то, как достигаются резервные копии и третьи лица, и засеките его относительно законного срока. Для государственных услуг, которые люди не могут покинуть, воспринимайте самообслуживаемое, полное и проверяемое исполнение прав как часть обязанности заботы, а не функцию для планирования на потом.

Взгляд по секторам

Стартап. С крошечной командой и малым запасом времени воспринимайте приватность как дешёвую страховку, а не программу, которой вы не можете укомплектовать. Собирайте только поля, нужные вашей основной функции, ведите лёгкую таблицу с картой данных, чтобы действительно мочь ответить на запрос об удалении, и держите адреса электронной почты и токены вне журналов. Ясный поток согласия и настоящее стирание стоят сейчас полдня; дооснащение ими после того, как ваш первый корпоративный клиент или регулятор спросит, стоит гораздо больше, а избыточно собранные данные это обязательство, от удержания которого вы ничего не выигрываете.

Малый бизнес. Без выделенного специалиста по приватности и при ограниченном бюджете опирайтесь на средства приватности, уже встроенные в покупаемые инструменты, и предпочитайте поставщиков, делающих обращение с данными прозрачным, а местонахождение ясным. Формулируйте решение как «купить или построить»: вы почти никогда не строите токенизацию или исполнение прав самостоятельно, поэтому выбирайте платформы, предлагающие правила хранения, экспорт и удаление из коробки. Знайте, какие персональные данные вы держите и где неверная или потерянная запись стоила бы вам клиента, и записывайте правовое основание для каждого использования, пусть документ и короток.

Крупная организация. В масштабе проблема в согласованности по многим командам: общая карта данных, стандартизированные уровни классификации и принудительное хранение, чтобы ни одна группа не стала слабым звеном. Бюджетируйте инженерию стирания между системами, хранилищ токенов и архитектуры с учётом местонахождения явно и управляйте субобработчиками централизованно, чтобы один поставщик не мог нарушить обязательство передачи от вашего имени. Делайте DPIA барьером в процессе поставки и измеряйте состояние приватности, потому что аудиторы и регуляторы попросят вас продемонстрировать соответствие, а не просто заявить.

Государственный сектор. Правила закупок, обязанности прозрачности и публичная подотчётность определяют каждый выбор, а граждане не могут унести свои налоговые, медицинские данные или данные о пособиях в другое место, поэтому обязанность заботы повышена. Привязывайте чувствительные записи к аккредитованным национальным средам, включая резервные копии и аналитику, обязывайте каждого поставщика договором к тем же обязательствам местонахождения и удаления и документируйте правовое основание (нередко публичная задача) для основной обработки, держа необязательные использования на отдельном отзываемом согласии. Публикуйте простыми словами, что вы собираете и зачем, и делайте исполнение прав надёжным в установленные законом сроки, потому что провал приватности здесь разъедает общественное доверие, от которого зависит услуга.

Примеры

Стартап. Потребительское приложение ранней стадии собирает только данные, которые ему действительно нужны, потому что каждое лишнее поле это обязательство, которое оно предпочло бы не защищать позже. Оно ведёт простую таблицу с картой данных о том, где живут персональные данные, чтобы действительно мочь ответить на запрос об удалении, держит адреса электронной почты и токены вне журналов и задаёт базовое правило хранения, очищающее данные давно мёртвых учётных записей. Построение ясного потока согласия и настоящего удаления сейчас стоит полдня; дооснащение ими после того, как спросит первый корпоративный клиент или регулятор, стоит гораздо больше.

Крупная организация. Глобальное потребительское приложение проводит DPIA перед запуском новой функции рекомендаций и обнаруживает, что она без нужды собирала бы точное местоположение; команда переходит на данные о грубом регионе, снижая риск без потери для продукта. Номера карт токенизируются, так что сырые значения держит только небольшое строго контролируемое хранилище, резко сокращая охват PCI (индустрии платёжных карт) компании. Автоматические правила хранения очищают данные неактивных учётных записей по расписанию, а поток самообслуживания позволяет пользователям экспортировать и удалять свои данные в законный срок по всем системам, включая резервные копии.

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

Бизнес-обоснование: мотивы, ROI и TCO

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

У отдачи есть и реальный плюс. Сильная приватность конкурентное отличие, а на регулируемых и государственных рынках предпосылка для получения бизнеса вообще. Минимизация данных прямо снижает экспозицию при взломе и стоимость хранения, а токенизация сужает дорогой охват аудитов вроде PCI-DSS. Обосновывая это перед руководством, подавайте приватность двояко: как управление обязательством с поправкой на риск при реальной регуляторной экспозиции и как актив доверия, открывающий рынки. Подчеркните, что приватность по замыслу дёшева в сравнении с приватностью через судебный иск и что данные, накопленные без цели, это обязательство в балансе, ждущее реализации.

Антипаттерны и ловушки

Собираем всё, решим потом. Накопление данных без цели, максимизирующее обязательство без выгоды.
Хранение по небрежности. Никогда ничего не удалять, потому что нет расписания, так что данные копятся вечно.
Театр согласия. Заранее отмеченные флажки, пакетное согласие или тёмные паттерны, юридически недействительные и подтачивающие доверие.
Стирание, пропускающее резервные копии. Удаление из основного хранилища с оставлением копий в резервных копиях, журналах и аналитике.
PII в журналах и тестовых данных. Разнос чувствительных данных в слабо контролируемые среды, где их легко раскрыть.
Игнорирование потоков данных. Упущение того, что журналы, резервные копии, аналитика и субобработчики перемещают данные через границы.
Приватность как только юридическая забота. Воспринимание её как бумажной работы, а не инженерного проектного ограничения.
Нет карты данных. Невозможность ответить, где живут персональные данные, что делает невозможными запросы о правах и реагирование на утечки.

Модель зрелости

Уровень 1: Начальный. С приватностью обращаются реактивно, если вообще. Персональные данные собираются свободно без описи, минимизации или ограничений хранения. Согласие запоздалая мысль, процесса для запросов о доступе или стирании нет, а то, где данные физически живут, не рассматривается.

Уровень 2: Развитие. Появляются базовые практики, различающиеся по командам. Политика приватности существует и базовое согласие фиксируется, есть некоторая осведомлённость о хранении. Запросы о правах обрабатываются вручную и медленно, классификация данных неформальна, и одна команда может картировать свои данные, тогда как другая собирает свободно. Ничто не принуждается последовательно по организации.

Уровень 3: Стандартизация. Приватность по замыслу документирована и принуждается по организации. DPIA проводятся для проектов повышенного риска, данные картированы и классифицированы по уровням, а сроки хранения принуждаются автоматическим удалением. Правовое основание документировано для каждой деятельности по обработке, действительные механизмы согласия на месте, запросы о правах исполняются в сроки, а местонахождение учтено для регулируемых данных.

Уровень 4: Управление. Программа приватности измеряется и контролируется относительно базовых значений. Вы отслеживаете время исполнения запросов о правах относительно установленных законом сроков, покрытие политикой хранения и возраст самых старых записей, число полей персональных данных в охвате и сколько из них токенизировано или псевдонимизировано, доли завершения DPIA для подходящих функций и число неуправляемых трансграничных потоков, найденных в аудитах. Метрики питают определённые пороги, так что нарушение цели (запрос о правах приближается к сроку, неожиданная передача, дрейф хранения) запускает документированный отклик, а не остаётся незамеченным.

Уровень 5: Оркестрация. Приватность это проектное ограничение по умолчанию, непрерывно улучшающееся и интегрированное по организации. Минимизация, токенизация и автоматическое хранение стандарт, запросы о правах самообслуживаемы и полны по всем системам, включая резервные копии, а потоки данных и местонахождение непрерывно отслеживаются и принуждаются. Положение приватности адаптируется по мере сдвигов регулирования, рынков и архитектуры, возвращая уроки в проектирование, так что базовый уровень продолжает расти, а не просто держится.

Идеи для обсуждения

Как вы разрешаете напряжение между аналитическими командами, хотящими больше данных, и приватностью, хотящей меньше?
Какова реалистичная архитектура для исполнения стирания по основным хранилищам, резервным копиям и нижестоящим копиям?
Какое правовое основание подходит каждой из ваших деятельностей по обработке и можете ли вы защитить выбор?
Как держать персональные данные вне журналов и не-эксплуатационных сред, не мешая отладке?
Какие требования местонахождения данных применяются на ваших рынках и как резервные копии и аналитика их усложняют?
Как следует объединить моделирование угроз приватности и безопасности в одну проектную деятельность?

Главные выводы

Приватность определяет, использовать ли персональные данные и как; она отлична от безопасности и дополняет её.
Закладывайте приватность с самого начала с помощью DPIA и защищающих приватность умолчаний.
Минимизируйте сбор, принуждайте к срокам хранения и стройте настоящую возможность стирания.
Классифицируйте PII, PHI и особые категории и защищайте их пропорционально токенизацией и маскированием.
Устанавливайте и документируйте правовое основание; делайте согласие свободно данным, конкретным и отзываемым.
Воспринимайте местонахождение данных и трансграничную передачу как архитектурные ограничения первого порядка.
Данные это и обязательство, и актив; накопление их без цели это риск, ждущий реализации.

Источники и дополнительное чтение

Ann Cavoukian, Privacy by Design: The 7 Foundational Principles
European Union, General Data Protection Regulation (GDPR) text and guidance
National Institute of Standards and Technology, Privacy Framework and SP 800-122 (Guide to Protecting PII)
ISO/IEC 27701, Privacy Information Management
Daniel Solove, Understanding Privacy
OECD, Privacy Guidelines and Fair Information Practice Principles (FIPPs)
California Consumer Privacy Act (CCPA/CPRA) statutory text and regulator guidance

4.5 Приватность и защита данных

Обзор и мотивация

Ключевые принципы

Рекомендации

Проектируйте под приватность с самого начала

Минимизируйте, храните и стирайте ответственно

Классифицируйте и защищайте чувствительные данные

Правильно обращайтесь с согласием и правовым основанием

Управляйте трансграничной передачей и местонахождением данных