Юридическая фирма: защищённая передача документов клиенту без публичных ссылок

MAATRIX

Помощник юриста собирает пакет документов для клиента — проект договора, справку, скан доверенности — загружает в общее облако фирмы и присылает клиенту ссылку «поделиться». Клиент открывает, скачивает, задача закрыта за две минуты. Только по умолчанию такая ссылка действует не «для этого конкретного клиента», а для любого, к кому она попадёт: перешлют в чат, продублируют в письме не тому адресату, откроют по старой ссылке через полгода, когда дело давно закрыто, а доступ никто не отозвал. Ниже — почему публичная ссылка «у кого есть адрес» не годится для документов клиента юридической фирмы, и как устроить передачу так, чтобы доступ был именно у того, кому он предназначен.

Публичная ссылка — это не доступ клиенту, а доступ всем, кто её получит

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

Технически такая ссылка не различает, кто по ней перешёл — самого клиента, его бухгалтера, которому он переслал документ для проверки, или постороннего человека, которому адрес попал случайно при пересылке цепочки писем. Система просто отдаёт файл тому, у кого есть адрес: публичная ссылка проектировалась как удобный способ поделиться, а не как инструмент контролируемого доступа для одного конкретного получателя.

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

Что реально происходит в юридической фирме с потоком клиентских документов

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

Проблема не в том, что кто-то в фирме делает это со злым умыслом или из небрежности — проблема в том, что удобный по умолчанию способ и есть источник риска:

• Ссылка «для клиента X» технически не привязана к клиенту X. Она привязана к файлу или папке, а получить её может кто угодно, кому клиент решит переслать документ — например, своему бухгалтеру. Клиент вправе показать свой документ кому захочет, но фирма при этом теряет контроль над тем, кому ещё известен адрес, по которому лежит остальной пакет из той же папки.
• Никто в фирме не видит список выданных ссылок целиком. У каждого сотрудника — своя история «поделился с клиентом», но единого реестра действующих ссылок обычно нет. Спросить через полгода «какие ссылки на дела клиента Иванова сейчас рабочие» — и ответа не найдётся.
• Ссылка не имеет срока годности, если её специально не выставить. По умолчанию большинство публичных ссылок остаются рабочими бессрочно, пока кто-то вручную не отзовёт доступ. На практике этого почти никогда не делают: дело закрыто, документы отправлены, про саму ссылку все забыли.
• Уволенный сотрудник мог создавать эти ссылки годами. Без учёта, кто и когда делился клиентскими файлами, при уходе сотрудника отозвать конкретно его ссылки физически невозможно — их просто никто не найдёт в общем массиве.
• Клиент, чьё дело давно закрыто, годами может открывать документы по старой ссылке, если её не отозвали, — и то же самое может любой, кому эта ссылка попала за прошедшее время.

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

Альтернатива: доступ авторизован под конкретного клиента, а не выдан по адресу

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

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

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

Два рабочих сценария: личный кабинет клиента и защищённая одноразовая ссылка

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

Личный кабинет клиента. Разворачивается на базе файлового хранилища на собственном сервере — практичный вариант с открытым кодом, который умеет папки, права, версии файлов и веб-доступ, — Nextcloud, пошаговая установка описана в отдельном материале — «Как установить и настроить Nextcloud на VPS». Каждому клиенту с активным делом заводится отдельная учётная запись с доступом только к своей папке — не общая ссылка, а персональный логин:

# создание учётной записи клиента с ограниченным доступом
sudo -u www-data php occ user:add --display-name="Иванов А.С., дело 2026-014" client_ivanov_014

# папка клиента — доступна только этой учётной записи
sudo -u www-data php occ files:transfer-ownership --path="Дела/2026-014_Иванов" client_ivanov_014

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

Защищённая одноразовая ссылка. Для разового документа — выслать проект договора на согласование, отправить справку — полноценный личный кабинет избыточен. Здесь работает публичная ссылка того же Nextcloud, но с обязательными ограничениями, которые превращают её из «адрес для всех» в разовый защищённый доступ:

sudo -u www-data php occ files_sharing:create \
  --path="/Дела/2026-014_Иванов/Проект-договора.pdf" \
  --permissions=1 \
  --expire-in-days=5 \
  --password="сгенерированный-пароль" \
  client_ivanov_014

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

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

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

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

Решение — та же логика авторизованного доступа, только в обратную сторону: клиенту выдаётся возможность загрузить файл в конкретную папку своего дела, а не отправить его произвольным каналом. В личном кабинете Nextcloud это делается через учётную запись клиента с правом записи только в свою папку — клиент кладёт файл туда, куда разрешено, и физически не видит чужие дела. Если постоянного кабинета у клиента нет, годится защищённая ссылка с режимом «загрузка без просмотра» — файл принимается, но содержимое папки клиенту не видно.

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

Организация в масштабе фирмы: кто отвечает и когда доступ закрывается

В фирме с несколькими юристами и десятками активных клиентов одновременно ручной контроль ссылок и учётных записей быстро превращается в отдельную задачу, если её не формализовать заранее. Несколько практических правил, которые снимают основную часть риска:

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

sudo -u www-data php occ config:app:set core shareapi_enforce_expire_date --value yes
sudo -u www-data php occ config:app:set core shareapi_expire_after_n_days --value 14

• Закрытие доступа сразу по завершении дела, а не «когда-нибудь потом вспомним». Учётная запись клиента отключается одной командой, как только дело закрыто и клиент подтвердил получение всех документов:

sudo -u www-data php occ user:disable client_ivanov_014

• Журнал выданных ссылок и учётных записей — минимум, кто, когда и какому клиенту выдал доступ, с каким сроком. Если через несколько месяцев возникнет вопрос «мы точно закрывали доступ клиенту после завершения дела», должен быть ответ, а не догадка по памяти.
• Один ответственный за учётные записи клиентов, а не право у каждого юриста заводить и удалять доступы бесконтрольно — иначе реестр снова рассыпается на индивидуальные привычки сотрудников.
• Двухфакторная аутентификация на вход в панель управления сервером — отдельный слой защиты для сотрудников фирмы, чтобы компрометация одного пароля не давала возможности создавать доступы от чужого имени, настройка разобрана в материале «Двухфакторная аутентификация для панелей управления».

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

Частые вопросы