Юристу нельзя в чужое облако: где хранить материалы дел

MAATRIX

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

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

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

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

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

Что конкретно не должно лежать где попало

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

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

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

Что даёт собственный сервер вместо чужого облака

Разница не в том, что «сервер безопаснее по умолчанию» — сам по себе сервер ничем не безопаснее облака, если его не настроить. Разница в том, кто принимает решения:

• Вы выбираете физическую локацию. Сервер можно арендовать в конкретной стране и дата-центре — это ваш осознанный выбор, а не то, что решил алгоритм балансировки нагрузки провайдера.
• Вы решаете, кто имеет доступ. Единственный способ попасть на сервер — через выданный вами SSH-ключ или VPN-туннель. Нет «поддержки провайдера», у которой есть техническая возможность заглянуть в файлы по умолчанию — весь стек шифрования и доступа настраиваете вы сами.
• Вы контролируете, что стоит на сервере. Никаких сторонних приложений, аналитики, автоматической индексации содержимого файлов — только то ПО, которое вы сами установили.
• Вы не зависите от пользовательского соглашения третьей стороны. Условия использования VPS у хостинг-провайдера касаются инфраструктуры (железо, сеть, канал), а не содержимого ваших файлов — контент вы шифруете и защищаете сами, и провайдер к нему доступа не имеет.
• Вы сами решаете, что происходит при завершении договора с провайдером. Данные можно выгрузить и перенести в любой момент — они не «живут» внутри чужой экосистемы, из которой сложно выйти.

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

Базовая архитектура: один сервер, разграниченный доступ, шифрование диска

Для одиночного юриста или небольшого бюро достаточно одного арендованного сервера (VPS или выделенного, в зависимости от объёма дел) со следующей структурой.

Шифрование диска. Данные на диске должны быть зашифрованы, чтобы содержимое было бессмысленно даже при физическом изъятии носителя или его копировании кем-то с доступом к дата-центру. На Ubuntu/Debian это делается через LUKS ещё на этапе установки системы, либо через шифрованный раздел под данные дел отдельно от системного:

# создаём зашифрованный раздел под /data (диск/раздел укажите свой)
sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup luksOpen /dev/sdb1 legal_data
sudo mkfs.ext4 /dev/mapper/legal_data
sudo mkdir -p /data/cases
sudo mount /dev/mapper/legal_data /data/cases

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

Доступ только по ключу, без паролей. SSH должен принимать вход исключительно по ключу:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AllowUsers ivanov petrova

Структура папок с разграничением прав. Даже в бюро из нескольких юристов не у каждого должен быть доступ ко всем делам:

sudo groupadd case-2026-014
sudo useradd -m -G case-2026-014 ivanov
sudo mkdir -p /data/cases/2026-014
sudo chown root:case-2026-014 /data/cases/2026-014
sudo chmod 770 /data/cases/2026-014

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

Удалённый доступ из суда, из дома, из другого офиса

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

Практичный вариант — VPN на базе WireGuard: сервер отдаёт доступ только тем устройствам, у которых есть настроенный клиентский конфиг, а весь трафик между устройством юриста и сервером идёт зашифрованным туннелем, даже если юрист подключён к публичному Wi-Fi в здании суда.

# на сервере
sudo apt install wireguard
wg genkey | tee server_private.key | wg pubkey > server_public.key

# /etc/wireguard/wg0.conf на сервере
[Interface]
Address = 10.10.0.1/24
PrivateKey = <server_private_key>
ListenPort = 51820

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.10.0.2/32

После поднятия туннеля файловый доступ к делам организуется поверх него — например, через Samba или SFTP, доступный только из VPN-подсети, а не из открытого интернета. Для юриста в моменте это выглядит как обычная сетевая папка на ноутбуке, но физически весь путь данных идёт через зашифрованный канал до сервера, локацию и настройки которого вы контролируете.

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

Резервное копирование без утечки на сторону

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

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

# инициализация зашифрованного репозитория borgbackup
borg init --encryption=repokey-blake2 ssh://backup-user@second-server:22/./legal-backups

# ежедневный бэкап с ротацией
borg create --stats --compression zstd \
  ssh://backup-user@second-server/./legal-backups::cases-{now:%Y-%m-%d} \
  /data/cases

borg prune --keep-daily=14 --keep-weekly=8 --keep-monthly=12 \
  ssh://backup-user@second-server/./legal-backups

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

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

Что делать при закрытии дела и при уходе юриста из бюро

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

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

Уход сотрудника. Отзыв доступа — это удаление пользователя из групп на сервере и отзыв его SSH-ключа и VPN-конфига:

sudo deluser petrova case-2026-014
sudo wg set wg0 peer <public_key_of_petrova> remove

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

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