Privacy by design для нормальных людей: проектируйте минимизацию, а не оправдания
Сбор лишних данных создаёт одновременно риск безопасности и операционную сложность. Почему минимизация данных - это инженерное решение, а не юридическое.
Когда компания начинает собирать данные о пользователях, первый вопрос обычно звучит так: "Что нам разрешено собирать?" Это юридический вопрос, и он правильный. Но он не единственный и часто не самый важный.
Второй вопрос - "Что нам действительно нужно для работы?" - задаётся гораздо реже. А именно он определяет, насколько сложной и рискованной окажется система через два года. Полезным предварительным шагом является составление карты того, какие потоки данных существуют, до того как добавлять какие-либо меры защиты.
Лишние данные - это не нейтральный актив
Распространённое заблуждение: больше данных - это больше возможностей, а значит, собирать лучше всё подряд, а разбираться потом. На практике каждый лишний тип данных - это:
- ещё одно место хранения, которое надо защищать;
- ещё одна зависимость в схеме, которую надо поддерживать;
- ещё одна точка риска при утечке или инциденте;
- ещё одна вещь, которую нужно будет объяснять регуляторам или пострадавшим пользователям.
Данные, которые вы собрали "на всякий случай", не исчезают. Они хранятся, к ним есть доступ, они участвуют в резервных копиях, они могут быть запрошены или похищены. Операционный долг от лишних данных - такой же реальный, как технический долг от лишнего кода.
Что такое privacy by design на практике
Термин появился в 90-х в работах Энн Кавукян и звучит академично. Но если убрать формализм, за ним стоит простой принцип: решения о данных принимаются на этапе проектирования, а не когда уже что-то пошло не так.
На практике это означает несколько конкретных вопросов, которые задаются до того, как появляется первая строчка кода или первая форма для пользователя:
- Какие данные нужны для того, чтобы функция работала?
- Как долго они нужны?
- Кому внутри компании нужен к ним доступ и зачем?
- Что происходит с данными, когда пользователь уходит?
- Какой минимальный набор данных обеспечивает нужный результат?
Ответы на эти вопросы до начала разработки стоят гораздо дешевле, чем переделка схемы данных через полтора года.
Минимизация как инженерное решение
Минимизация данных часто воспринимается как ограничение - что-то, что мешает строить фичи. На деле она работает в другую сторону: система с меньшим объёмом чувствительных данных проще в архитектуре, проще в аудите, проще в обслуживании.
Несколько вещей, которые становятся легче, когда данных меньше:
- Схема базы данных не разрастается в клубок без понятной структуры.
- Доступы легче описать и ограничить: меньше таблиц, меньше ролей, меньше исключений.
- Время реакции на инцидент сокращается: вы точно знаете, что хранится и где.
- Онбординг новых сотрудников проще: они видят именно те данные, которые нужны для их работы.
Это не теория. Это результат, который отличает системы, которые легко поддерживать, от систем, которые никто не хочет трогать.
Оправдание вместо проектирования
Противоположный подход - собрать всё, а потом объяснять. Объяснять пользователям, что значит очередной пункт в согласии на обработку данных. Объяснять регуляторам, зачем хранятся данные, которые уже не нужны. Объяснять себе, почему произошедший инцидент затронул больше данных, чем мог бы.
Это дорогая стратегия - и не только финансово. Она отнимает время команды, подрывает доверие пользователей и создаёт репутационные риски, которые трудно оценить заранее.
Простые вопросы для проверки
Перед запуском любой новой функции или интеграции, которая касается пользовательских данных, я рекомендую задать три вопроса:
- Какие данные мы собираем в рамках этого изменения и зачем каждое поле?
- Есть ли поля, от которых можно отказаться без потери функциональности?
- Что произойдёт с этими данными через год - они всё ещё будут нужны?
Если на эти вопросы нет ответов - значит, проектирование данных ещё не завершено, даже если код уже готов к деплою.