Клиентское шифрование vs серверное шифрование для загрузок

Почему выбор шифрования важен для загружаемых документов

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

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

Команды часто говорят «шифрованное хранилище», имея в виду разное. Иногда они говорят про защищённое соединение при загрузке (HTTPS). Иногда — про шифрование на диске (шифрование в покое). Иногда — про шифрование файла ещё до отправки с устройства пользователя, чтобы сервер никогда не видел открытый текст (клиентское шифрование). Это разные вещи. Они защищают от разных сбоев.

Выбор безопасности также формирует повседневную удобность и поддержку. Больше приватности может означать больше трений: дополнительные шаги для просмотра файла, сложный шаринг, ограниченный поиск и предпросмотры, а также сложное восстановление, когда кто‑то теряет устройство или ключ. Проще организованный доступ позволяет индексирование, антивирусную проверку, предпросмотры и сброс пароля, но при этом увеличивает, что ваш сервер (и кто‑то, кто его скомпрометирует) может увидеть.

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

Быстрые определения: клиентское vs серверное шифрование

Практический вопрос прост: когда файл шифруется, и кто сможет расшифровать его позже?

Серверное шифрование означает, что файл приходит на ваш бэкенд в читаемом виде, и сервер шифрует его перед сохранением. Это шифрование «в покое»: если кто‑то украдёт диск или получит сырой доступ к бакету хранения, он увидит непонятные данные. Ваш сервер при этом может расшифровывать файл по мере необходимости.

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

Реальная граница — владение ключами:

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

В обеих моделях вам всё равно нужны аутентификация и права доступа. Шифрование не заменяет контроль доступа.

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

Модели угроз: против чего вы на самом деле пытаетесь защититься

Шифрование помогает только тогда, когда вы ясно понимаете риски, которые хотите снизить. «Никто, кроме адресата, не должен читать файл» ведёт к другим решениям, чем «уменьшить ущерб при утечке хранилища».

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

• Украденные или повторно использованные пароли (захват аккаунта)
• Чрезмерный доступ инсайдеров (саппорт, админы, подрядчики)
• Скомпрометированный облачный аккаунт или неверно настроенный бакет хранения
• Баг или утечка, раскрывающая базы данных или бэкапы
• Вредоносное ПО на устройстве пользователя

Также полезно разделять, где может произойти утечка:

• В пути: файл движется с устройства на сервер
• В хранении: объектное хранилище, строки базы данных, бэкапы, логи
• При просмотре/обработке: предпросмотры, OCR, поиск, конвертации

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

Шифрование не останавливает всё. Если устройство заражено, вредоносное ПО может забрать файл до шифрования или после расшифровки. Если кто‑то видит документ, он всё ещё может сделать скриншот, переслать или распечатать его.

Что защищает каждая модель (и что не защищает)

Полезный способ сравнить подходы — спросить: кто может увидеть файл в открытом виде в какой‑то момент? Ответ формирует масштаб утечки, риск от инсайдеров и безопасность бэкапов.

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

При клиентском шифровании атакующий, взломавший вашу инфраструктуру, обычно получает только зашифрованные объекты. Без ключей, хранящихся у пользователей, такие объекты гораздо менее полезны.

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

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

Также следите за утечками за пределами «файлового хранилища». Многие инциденты происходят через:

• Резервные копии и снимки, которые захватывают расшифрованные файлы или ключи
• Логи, где записываются имена файлов, метаданные или извлечённый текст
• Миниатюры, предпросмотры и поисковые индексы
• Экспорты в почту, чат или систему заявок
• Временные файлы, создаваемые во время загрузки или конвертации

UX‑компромиссы, которые пользователи заметят сразу

Главная разница — не в математике, а в том, что пользователи могут делать легко, а что становится сложно.

Серверное шифрование часто кажется незаметным. Пользователи заходят, загружают и сразу видят предпросмотр. Саппорт может сбросить доступ. Руководитель обычно может переназначить права, если кто‑то болеет.

Клиентское шифрование меняет онбординг и повседневную работу. Пользователям может понадобиться более надёжная фраза‑пароль, локальный ключ на устройстве или дополнительный шаг для разблокировки. Смена устройства, очистка браузера или переустановка приложения может привести к потере доступа, если вы заранее не предусмотрели резервное копирование ключей.

Восстановление аккаунта — место, где команды часто удивляются. Если только пользователь владеет ключом расшифровки, «Забыли пароль» может превратиться в «доступ утерян навсегда». Вы можете добавить ключ восстановления или эскроу‑поток, но нужно честно объяснять, что это значит.

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

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

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

Требования, специфичные для типов документов: контракты, удостоверения и медицинские записи

Лучший выбор зависит не столько от типа файла, сколько от рабочего процесса: кто должен его читать, как быстро, как часто и как долго.

Контракты

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

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

Клиентское шифрование подходит, если приложение по сути — это хранилище, например для хранениия подписанных PDF для небольшой группы руководителей. Компромисс — слабее встроенное удобство, если вы не добавите клиентские инструменты.

Удостоверения (паспорта, права)

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

Распространённый подход — серверное шифрование в сочетании с жёстким контролем доступа, подробными журналами аудита и короткими сроками хранения. Клиентское шифрование имеет смысл, если персонал вообще не должен видеть удостоверения, но тогда нужен альтернативный способ верификации.

Медицинские документы

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

Клиентское шифрование может уменьшить воздействие при взломе сервера или злоупотреблении доступом админов. Но оно также может создать реальные UX и операционные проблемы: сброс пароля, смена устройства и экстренный доступ становятся сложнее.

Прежде чем выбирать, свяжите каждый тип документа с рабочим процессом:

• Кто должен его читать (и откуда)
• Насколько быстро он должен загружаться
• Как долго вы храните
• Какие функции продукта важны (предпросмотр, поиск, автоматическое удаление)

Как выбрать: пошаговый процесс принятия решения

Начните с выписывания того, что вы храните, и кто с этим взаимодействует. Папка «uploads» — это не политика.

Шаг 1: картируйте доступ, а не просто «пользователи»

Перечислите роли и ответьте на два вопроса: кто должен иметь возможность открыть файл, и кто никогда не должен этого делать (включая админов)? Укажите также сроки хранения.

Шаг 2: выберите модель угроз

Честно скажите, от чего вы защищаетесь.

• Если риск инсайдеров — главный приоритет, клиентское шифрование выглядит привлекательнее.
• Если потеря устройства и сбросы пароля происходят часто, вы заплатите за это сложностью восстановления.

Затем проверьте опыт пользователя:

1. Восстановление и поддержка: что происходит, когда кто‑то забывает пароль или теряет телефон? Если нужно восстановить доступ, чистое клиентское шифрование может не подойти.

2. Обязательные функции: нужны ли предпросмотры, поиск, OCR, электронная подпись или обработка через API? Многие из этих функций проще, если где‑то в цепочке есть серверная расшифровка.

3. Аудит и соответствие: нужны ли подробные логи о том, кто и когда получил доступ? Обе модели могут вести логи, но клиентские дизайны требуют дополнительной проработки, чтобы избежать ситуаций «мы не можем помочь вам».

Большинство команд выбирает гибрид: серверное шифрование для большинства документов и клиентское шифрование для небольшой группы «никогда не показывать персоналу» загрузок.

Частые ошибки и ловушки

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

Второй по распространённости просчёт — внедрение клиентского шифрования без плана восстановления. Если пользователь теряет устройство, забывает фразу или уходит из компании, сможете ли вы восстановить доступ, не нарушая своих обещаний по безопасности? «Мы не можем помочь вам» может сойти для личного хранилища, но обычно не проходит в бизнес‑приложении.

Эти ошибки приводят к реальным утечкам и обходам безопасности:

• Предоставление админам скрытого пути «видеть всё» или разрешение саппорту имитировать пользователей без строгих логов и второго одобрения.
• Расшифровка в браузере или приложении и оставление копий (кешированные предпросмотры, временные скачивания, синхронизированные папки).
• Отправка «безопасных» документов через небезопасные каналы позже (электронная почта, скриншоты в чат, файлы в тикетах).
• Сделать защищённый поток настолько неудобным, что пользователи переходят на личные диски или фотографируют экран.
• Предположение, что «шифрование в покое» автоматически обеспечивает требования по согласию, истории доступа, срокам хранения и уведомлениям об утечках.

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

Быстрый чек‑лист перед финальным выбором

Напишите одним простым предложением: кто должен иметь возможность читать эти файлы, а кто никогда не должен, даже в случае, если кто‑то получит доступ к вашим серверам.

Затем проверьте:

• Кто может расшифровывать и когда? Перечислите точные роли и условия. Если политика говорит «только загрузивший», не добавляйте тихие лазейки через общие ключи.
• Можете ли вы быстро отзывать доступ? Увольнение и отвод доступа — настоящий тест. Решите, привязан ли доступ к аккаунту, устройству или группе.
• Что происходит после потери устройства или сброса пароля? Если нужно восстановление, защищайте этот процесс строгими подтверждениями.
• Нужны ли предпросмотры, антивирусная проверка или OCR? Если да, спланируйте, где происходит расшифровка и кто может её инициировать.
• Достаточно ли подробны ваши журналы аудита? Определите, что считается «просмотром» и «скачиванием», и фиксируйте пользователя, время, устройство и причину.

Пример сценария: небольшая команда, хранящая удостоверения и медицинские PDF

Небольшая клиника использует приложение, где персонал загружает направления пациентов (PDF) и фото страховых удостоверений. Цель — быстро передавать документы нужным людям и уменьшить ущерб от потерь устройств, скомпрометированных аккаунтов или ошибок в облаке.

Один рабочий подход — серверное шифрование с жёсткими ролями. Файлы шифруются в покое, и доступ контролируется правами: ресепшн может загружать, биллинг — просматривать удостоверения, а врачи — направления. Это проще в повседневной работе, потому что персонал может открывать документы на десктопе или мобильном без дополнительных шагов, а руководители могут переназначать доступ во время отсутствия.

Другой подход — клиентское шифрование для самых чувствительных элементов. Файл шифруется на устройстве до загрузки, и сервер хранит только шифротекст. Это уменьшает последствия взлома сервера и внутреннего доступа, но меняет операции:

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

Пользователи будут чувствовать трения при шаринге, мобильном доступе и восстановлении после потери телефона. Эти детали важнее самой модели шифрования.

Следующие шаги: решите, задокументируйте политику и реализуйте

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

Оформите решение в коротком внутреннем наборе правил, которым люди смогут следовать:

• Какие типы файлов разрешены и где они могут храниться
• Кто может получать доступ и делиться ими, и как одобряется доступ
• Правила хранения и удаления
• Как работает восстановление после сброса пароля и потери устройства
• Как обрабатываются экспорты (скачивания, почта, мессенджеры) и когда они блокируются

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

Если вы строите на безкодовой платформе вроде AppMaster (appmaster.io), полезно с самого начала смоделировать роли и потоки одобрения, чтобы затем адаптироваться по мере изменения требований без переписывания всего приложения. Главное — сделать безопасный путь удобным для реальных пользователей.