Юридическая фирма: 30 ГБ дел клиентов и адвокатская тайна в чужом облаке

MAATRIX

В юридической фирме, где работает пять-семь юристов, а не один частнопрактикующий специалист, дела клиентов давно перестали помещаться в один компьютер и одну голову. Договоры, переписка, сканы паспортов и учредительных документов, аудиозаписи допросов, судебные акты — всё это стекается в общую папку на Google Диске или в Dropbox, потому что так проще всего дать доступ коллеге, который подхватывает дело на время отпуска. Через пару лет такой архив легко разрастается до 30 ГБ и больше, и в какой-то момент managing partner задаёт вопрос, на который отвечать неловко: а где вообще физически лежат материалы, за конфиденциальность которых фирма отвечает перед каждым доверителем лично? Ответ «в облаке, у стороннего сервиса, на серверах, которые нам не принадлежат» не соответствует уровню ответственности, который подразумевает адвокатская тайна. Ниже — практический разбор, почему так, и как перенести архив дел на сервер, который находится под полным контролем фирмы, а не под условиями использования публичного облачного сервиса.

Почему это не просто «файлы», а материалы, защищённые тайной клиента

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

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

30 ГБ, которые вынесены в заголовок, — не точная цифра для расчёта тарифа, а иллюстрация масштаба: это архив фирмы среднего размера за несколько лет работы, где на одно дело может приходиться от нескольких мегабайт (переписка и типовой договор) до нескольких гигабайт (уголовное дело со сканами, аудиозаписями и вещественными доказательствами в виде фото). Технически такой объём — это совсем немного, любой современный VPS справится с ним без проблем. Сложность не в объёме, а в том, что каждый файл в этом архиве — чьи-то персональные обстоятельства, коммерческая тайна контрагента или стратегия защиты по делу, которое ещё не закончено.

Что на самом деле происходит, когда дела лежат в общем облаке

Публичные облачные сервисы — Google Диск, Dropbox, Яндекс.Диск, OneDrive — спроектированы для удобства массового пользователя, а не для работы с материалами, требующими режима конфиденциальности. Загружая файл в такое хранилище, фирма технически передаёт его третьей стороне: инфраструктура, на которой физически хранятся данные, кто может ими управлять на стороне провайдера, в какой юрисдикции она находится и что происходит с файлом при технической поддержке или расследовании инцидента безопасности — всё это решает не фирма, а условия использования сервиса, которые обычным образом никто в компании не читал целиком.

На практике это создаёт несколько конкретных проблем, знакомых любому, кто администрировал общую папку с делами:

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

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

Свой сервер: тот же принцип тайны, но контроль остаётся у фирмы

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

Разница на практике сводится к нескольким пунктам:

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

Здесь стоит сделать честную оговорку: собственный сервер — это не автоматическая гарантия безопасности. Плохо настроенный VPS с паролем «Firma2024» на root-доступе рискованнее, чем аккуратно сконфигурированный корпоративный Google Workspace. Разница в том, что на своём сервере уровень защиты — это выбор и зона ответственности фирмы, а не то, что молча решил за неё внешний сервис. Соблюдать принцип адвокатской тайны строже, чем позволяет чужое облако общего назначения, технически возможно только тогда, когда инфраструктура целиком находится под управлением фирмы.

Как организовать хранение 30 ГБ дел: структура на практике

Для архива такого объёма не нужен ни отдельный дата-центр, ни экзотическое ПО — достаточно VPS с файловым сервером, который умеет делать всё то же, что привычное облако: папки, права доступа, ссылки для обмена, версии файлов, доступ через браузер и приложение. Наиболее практичный вариант для такой задачи — Nextcloud, разворачивается на обычном Ubuntu-сервере за один вечер, подробный процесс описан в отдельном материале — «Как установить и настроить Nextcloud на VPS».

Для фирмы с несколькими юристами и архивом 30 ГБ конфигурация сервера скромная: 2–4 vCPU, 4–8 ГБ RAM, 100–150 ГБ NVMe SSD с запасом на рост архива на несколько лет вперёд и на резервные копии. Дисковое пространство здесь важнее процессора — файлы дел не требуют вычислений, требуют надёжного и предсказуемого хранения.

Структуру папок разумно строить не «по алфавиту клиентов», а по логике доступа — это заранее закладывает разграничение прав:

/Дела
  /Активные
    /2026-014_Иванов_vs_ООО-Ромашка
    /2026-015_Петрова_наследственный-спор
  /Завершённые
    /2024
    /2025
  /Шаблоны
  /Внутренние_материалы

В Nextcloud для такой структуры используется приложение Group folders — папка, доступ к которой выдаётся не отдельным пользователям вручную, а целой группе, и права наследуются автоматически при создании новых подпапок:

# на сервере с уже установленным Nextcloud
sudo -u www-data php occ app:install groupfolders
sudo -u www-data php occ app:enable groupfolders

# создать групповую папку для активных дел
sudo -u www-data php occ groupfolders:create "Активные дела"

# привязать группу юристов с правом чтения/записи
sudo -u www-data php occ groupfolders:group 1 yuristy read write share

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

Доступ для нескольких юристов: роли и разграничение, а не общий пароль

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

• Партнёр — видит все активные дела фирмы и архив.
• Ведущий юрист по делу — полный доступ к своим делам, без доступа к чужим.
• Помощник/паралигал — доступ только к тем делам, к которым прикреплён, часто без права удаления.
• Бухгалтер/офис-менеджер — доступ к шаблонам и организационным папкам, без доступа к содержанию дел.

В Nextcloud это настраивается группами и правами на уровне групповой папки (advanced permissions), а не общим логином на всех — общий аккаунт на несколько человек делает невозможным сам журнал доступа, а значит и ответ на вопрос «кто открывал этот файл» в случае инцидента. Отдельно стоит закрыть вход двухфакторной аутентификацией на панели управления сервером и в самом Nextcloud, а для мобильного доступа юриста к делам с телефона или планшета вне офиса пригодится отдельный разбор — «Доступ юриста к делам с любого устройства».

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

sudo -u www-data php occ user:disable ivanov
sudo -u www-data php occ user:list-groups ivanov
sudo -u www-data php occ group:removeuser yuristy ivanov

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

Резервное копирование и шифрование: что защищает данные, если сервер выйдет из строя

Собственный сервер снимает риск передачи данных стороннему облаку, но добавляет фирме ответственность за резервные копии — в публичном облаке об этом заботился провайдер, теперь заботится фирма. Минимальная схема для архива 30 ГБ — ежедневный зашифрованный бэкап на отдельное хранилище, физически отделённое от основного сервера:

# пример через restic — инкрементальный бэкап с шифрованием на стороне клиента
restic -r sftp:backup-user@backup-server:/backups/dela init
restic -r sftp:backup-user@backup-server:/backups/dela backup /var/www/nextcloud/data

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

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

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