Адвокатская тайна и облачный диск: почему это плохо кончается

MAATRIX

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

Адвокатская тайна — это про контроль, а не про настройку приватности

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

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

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

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

• Файл реплицируется на серверы провайдера, чаще всего в нескольких дата-центрах одновременно — ради отказоустойчивости, но и это означает, что копий больше одной, и вы не выбираете, сколько и где.
• Метаданные (кто, когда, откуда, с какого устройства открывал файл) собираются и хранятся отдельно от самого содержимого — это часть работы любого современного облачного сервиса, а не злой умысел, но именно эти метаданные тоже относятся к материалам дела.
• Автоматические системы сервиса — антивирусное сканирование, индексация для поиска, превью документов — так или иначе обращаются к содержимому файла программным образом. Это не «человек читает», но это и не «к файлу никто не прикасался».
• Доступ к инфраструктуре у сотрудников поддержки провайдера технически существует — вопрос только в том, при каких условиях и по какому регламенту он используется, а этот регламент вы не устанавливаете и не можете проверить его исполнение изнутри.
• Изменение условий использования или политики конфиденциальности провайдер вносит в одностороннем порядке, и он не обязан согласовывать это лично с вами как с адвокатом, ведущим конкретное дело.

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

Собственный сервер как более защищаемая позиция

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

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

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

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

Как это выглядит на практике: базовая инфраструктура

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

Шифрование диска. На большинстве дистрибутивов Linux полнодисковое шифрование включается ещё на этапе установки системы (LUKS). Если сервер уже развёрнут и нужно зашифровать отдельный раздел под хранилище файлов дела:

cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 case_files
mkfs.ext4 /dev/mapper/case_files
mount /dev/mapper/case_files /srv/case-files

Ключ шифрования при этом хранится отдельно от сервера — на защищённом носителе, а не в текстовом файле рядом с данными.

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

Доступ только по ключу, без паролей. В /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
Port 2222

После изменений — systemctl restart sshd и проверка входа по ключу в отдельной сессии до закрытия текущей, чтобы не остаться без доступа.

Защита от перебора. fail2ban с базовым jail для SSH закрывает попытки подбора пароля или ключа автоматическими ботами — устанавливается пакетом fail2ban, конфиг /etc/fail2ban/jail.local с секцией [sshd] enabled = true.

Шифрованные резервные копии. Материалы дела бесполезно защищать на основном сервере, если бэкап лежит открытым текстом где-то ещё. Инструмент вроде borgbackup позволяет хранить зашифрованные снапшоты:

borg init --encryption=repokey-blake2 /path/to/backup-repo
borg create /path/to/backup-repo::case-files-{now} /srv/case-files

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

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

Разграничение доступа внутри команды

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

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

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

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