Принципы Privacy by Design для инструментов передачи файлов
Как применять принципы Privacy by Design к инструментам передачи файлов, обеспечивая защиту данных на каждом этапе процесса обмена.
Privacy by Design в инструменте передачи файлов означает, что конфигурация по умолчанию уже защищает персональные данные — без каких-либо действий со стороны пользователя. Статья 25 GDPR закрепляет два аспекта: защита данных в силу дизайна (статья 25(1)) требует встроить надлежащие технические меры в продукт с самого начала проектирования; защита данных по умолчанию (статья 25(2)) требует, чтобы конфигурация «из коробки» обрабатывала только необходимые данные, предоставляла доступ только нужным лицам и хранила данные лишь столько, сколько необходимо. В России принципы минимизации и защиты ПДн закреплены в 152-ФЗ, а ФСТЭК России определяет технические требования к системам защиты. Для инструмента передачи это выражается в клиентском шифровании по умолчанию, сроке истечения ссылок менее 30 дней, минимальном сборе метаданных и отзыве доступа в один клик.
Семь принципов Каукяна применительно к передачам
Фреймворк Энн Каукяна 1990-х годов — проактивность, конфиденциальность как настройка по умолчанию, встроенность в дизайн, полная функциональность, сквозная безопасность, видимость и прозрачность, уважение к конфиденциальности пользователя — напрямую проецируется на архитектуру передачи файлов. Проактивность: выявляйте слабые шифры в кодовой базе до развёртывания через автоматическое SAST-сканирование. По умолчанию: AES-256-GCM включён без опции отключения. Встроенность: шифрование происходит в пайплайне загрузки, а не на отдельном шаге. Полная функциональность: зашифрованные файлы всё равно поддерживают предпросмотр через клиентское дешифрование. Сквозная безопасность: платформа никогда не видит открытый текст. Видимость: публикуйте спецификацию шифрования. Уважение: предоставьте пользователям контроль над хранением и сроками.
Статья 25(1): обязательства на этапе проектирования
Статья 25(1) требует принятия мер «как на момент определения средств обработки, так и на момент самой обработки». Это означает, что обязательства по защите данных закладываются при проектировании архитектуры, а не добавляются задним числом. Выберите транспортный протокол (HTTPS с TLS 1.3), набор шифров (AES-256-GCM или XChaCha20-Poly1305), функцию производства ключей (PBKDF2-SHA-256 при 600 000 итерациях или Argon2id) и регион хранения (ЕС) до написания первой строки кода. Задокументируйте выбор в Architecture Decision Record, чтобы будущие инженеры понимали ограничения.
Статья 25(2): обязательства по конфигурации по умолчанию
Статья 25(2) устанавливает четыре умолчания: ограничить объём собираемых данных, ограничить обработку, ограничить срок хранения, ограничить доступность. Для инструмента передачи это означает: запрашивать только email отправителя и получателя (не полное имя, телефон, адрес); обрабатывать файл единожды и удалять; хранить 7 дней, а не бессрочно; ограничить доступ конкретными получателями, а не публичным URL, индексируемым поисковиками.
Минимизация данных в форме загрузки
Форма загрузки отправителя — то место, где начинается минимизация. Плохой дизайн: запросить имя отправителя, компанию, телефон, имя получателя, компанию получателя, сообщение. Каждое поле — точка персональных данных, хранимая и анализируемая. Хороший дизайн: только email, необязательное поле для сообщения, без пикселей трекинга. HexaTransfer реализует минимальные формы. Удаляйте EXIF-метаданные из изображений на серверной стороне, если клиентская очистка недоступна. Не логируйте имена файлов, если они содержат персональные данные — хешируйте их для журнала аудита и храните маппинг только на сервере под строгим контролем доступа.
Шифрование по умолчанию без отговорок о производительности
AES-256-GCM в современных браузерах через Web Crypto API работает со скоростью около 200–500 МБ/с на ноутбуке 2020 года выпуска. Файл размером 100 МБ шифруется менее чем за секунду. XChaCha20-Poly1305 из Libsodium показывает аналогичную скорость. Аргумент о производительности как причине сделать шифрование опциональным несостоятелен. Используйте ключи на файл, производные от секрета пользователя — пароля или случайного ключа, встроенного в фрагмент URL (после #, чтобы серверы его не видели). Архитектура Firefox Send 2017–2019 годов служит проверенным примером: фрагмент URL нёс ключ, сервер видел только шифртекст.
Псевдонимизация там, где это возможно
Статья 4(5) определяет псевдонимизацию. Согласно рецесс 28, она поощряется на всём протяжении регламента. Для передачи файлов псевдонимизация означает замену прямых идентификаторов в системных метаданных: sender@company.com превращается в SHA-256-хэш в журнале аудита, а таблица маппинга хранится отдельно под более жёсткими контролями доступа. Если злоумышленник компрометирует журнал аудита в одиночку, он видит только хэши, а не граф контактов. Таблица маппинга — меньше и в отдельном хранилище — защищается другими ключами и политиками доступа.
Прозрачность через публикацию архитектуры
Статья 25 не предписывает открытый код, но прозрачность — это принцип privacy-by-design. Публикуйте: спецификацию шифрования (алгоритм, KDF, итерации, длину тега аутентификации), диаграмму потоков данных, список субобработчиков с юрисдикциями, расписание хранения, сроки уведомления о нарушениях и схему журнала аудита. Криптографические утверждения, которые нельзя проверить — расплывчатое «военное шифрование», — являются тревожным сигналом. Если провайдер не называет шифр, предполагайте слабую защиту. HexaTransfer публикует технические спецификации для проверки.
Контроль пользователя как настройка по умолчанию, а не премиум-функция
Privacy by Design идёт не туда, когда контроли заперты за платными уровнями. Защита ссылок паролем не должна стоить дополнительно. Ограничения скачивания не должны быть премиум. Отзыв ссылки не должен требовать обращения в поддержку. Минимальная жизнеспособная позиция конфиденциальности — истечение, пароль, отзыв, уведомления о скачивании — должна быть бесплатной. Это одновременно позиция GDPR и коммерческая: пользователи доверяют продуктам, дающим контроль без платёжного барьера.
Журналирование с соблюдением принципа
Журналы аудита сами по себе являются персональными данными. Журналируйте слишком много — создадите новую поверхность нарушения. Журналируйте слишком мало — не сможете выполнить требования статьи 33 или продемонстрировать соответствие по статье 5(2). Баланс: логируйте тип события, временну́ю метку, хэш ID файла, хэш ID актора, результат. Не логируйте полные IP — усекайте до /24 (IPv4) или /64 (IPv6). Не логируйте полные User-Agent — извлекайте семейство браузера и основную версию. Храните в течение минимального периода, необходимого для безопасности и соответствия (обычно шесть месяцев), затем выводите из ротации.
Тестирование позиции до запуска
Проведите аудит потоков данных с инженером, не участвовавшим в разработке. Вопросы: для каждой системы, какие персональные данные проходят через неё? Где они хранятся? Как долго? Кто может получить к ним доступ? Как фиксируется доступ? Как они удаляются? Сравните ответы с обязательствами по статье 25, задокументированными в DPIA. Проведите пенетрационное тестирование против заявленной архитектуры: видит ли сервер действительно только шифртекст? Действительно ли ключ в фрагменте URL исключён из журналов? Архитектуры с устойчивыми принципами privacy-by-design — такие как 7-дневное истечение HexaTransfer с клиентским AES-256-GCM — проходят эти проверки, потому что архитектура делает то, что написано в документации.
Встраивайте конфиденциальность; не прикручивайте её снаружи. Попробуйте на https://hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.
Безопасная отправка больших файлов со сквозным шифрованием
Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.
Отправить файл