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