Частному детективу нельзя оставлять следы в облаке: сервер для материалов

MAATRIX

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

Что на самом деле копится в деле

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

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

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

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

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

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

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

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

Что меняется, когда материалы лежат на своём сервере

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

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

Это не «защита от всего» — это возврат контроля за конкретными решениями, которые в публичном облаке принимает не детектив, а сервис.

Как устроить хранение материалов технически

Практическая схема, которая закрывает основные риски, без избыточной сложности.

1. Сервер и базовая защита. Берёте VPS или выделенный сервер, сразу отключаете вход по паролю и переходите на SSH-ключи — это закрывает самый массовый вектор атак на новый сервер, подбор пароля по SSH. Настройка описана в материале про SSH-ключи вместо пароля. Дополнительно стоит включить двухфакторную аутентификацию для SSH — это отдельный барьер даже в случае утечки самого ключа.

2. Шифрование диска. Материалы расследования должны быть нечитаемы, даже если физический носитель окажется не в тех руках — например, при выводе сервера из эксплуатации провайдером. Шифрование раздела через LUKS на Linux:

cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 evidence_vol
mkfs.ext4 /dev/mapper/evidence_vol
mount /dev/mapper/evidence_vol /mnt/evidence

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

3. Файловое хранилище с веб-доступом. Чтобы не работать напрямую через файловую систему, поверх диска ставится Nextcloud — свой аналог облака, но на собственном сервере: с веб-интерфейсом, синхронизацией на телефон и десктоп, но без стороннего провайдера в цепочке. Установка описана в материале по Nextcloud на VPS. Для детектива это значит: фото со слежки заливаются с телефона напрямую на свой сервер, минуя Google Фото или общую галерею с автозагрузкой в чужое облако.

4. Сеть — сервис не должен смотреть в открытый интернет. Разумная практика — закрыть веб-интерфейс хранилища за VPN и не открывать порт 443 наружу вовсе, либо ограничить его конкретными IP. Поднимается WireGuard, доступ к панели материалов появляется только после подключения к VPN с рабочего ноутбука или телефона. Это резко сокращает поверхность атаки: сканеры и боты, которые круглосуточно перебирают открытые порты в интернете, просто не увидят сервис.

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

borg init --encryption=repokey-blake2 /mnt/backup/evidence_repo
borg create --stats /mnt/backup/evidence_repo::case-2026-08-27 /mnt/evidence

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

6. Ограничение доступа, если работаете не в одиночку. Если к расследованию подключён помощник или напарник, у него не должно быть root-доступа к серверу целиком — только к папке конкретного дела, над которым он работает. В Nextcloud это делается через отдельные учётные записи и права на конкретные каталоги; на уровне сервера — через отдельного системного пользователя без sudo-прав.

Организация материалов по делам

Техническая защита не работает сама по себе без порядка в структуре. Практичная схема каталогов:

/mnt/evidence/
  cases/
    2026-08-case-0142/
      raw/            — исходные фото и видео без обработки
      reports/        — итоговые отчёты и документы для клиента
      notes/          — рабочие заметки
      correspondence/ — переписка с клиентом по делу
    2026-08-case-0143/
      ...
  archive/
    closed/           — завершённые дела, готовые к архивированию

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

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

find /mnt/evidence/archive/closed -maxdepth 1 -type d -mtime +365 -exec rm -rf {} \;

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

Передача материалов клиенту без следов в постороннем сервисе

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

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

occ files:sharing:list --output=json

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

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

7z a -p -mhe=on report-case-0142.7z /mnt/evidence/cases/2026-08-case-0142/reports/

Флаг -mhe=on шифрует не только содержимое файлов, но и список файлов внутри архива — сторонний сервис, через который потенциально пройдёт архив при пересылке, не увидит даже имена вложенных документов.

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