Файловый сервер без общего пароля: персональные доступы и журнал скачиваний

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

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

Сначала люди и задачи, потом аккаунты

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

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

Полезно набросать простую матрицу «роль — область — операции». Условный пример для небольшой компании:

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

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

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

Чтение, загрузка, перезапись и удаление — это четыре разных права

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

• Просмотр списка без скачивания. Человек видит, что файл существует, но не получает содержимого. Пригодится, когда нужно подтвердить наличие документа, не раздавая его.
• Загрузка без перезаписи. Подрядчик может принести новую версию файла под новым именем, но не может затереть существующий. Ошибка «залили не туда» превращается из потери данных в лишний файл, который легко убрать.
• Перезапись. Выдавайте тем, кто действительно ведёт живой документ. Именно перезапись чаще всего объясняет фразу «вчера тут было другое».
• Удаление. Отдельный и редкий выбор, не побочный эффект роли «работает с проектами».

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

Разберём на примере из нашей матрицы. Внешний редактор в /review может загружать файлы, но не перезаписывать. Он присылает правки к тексту: сначала article-v1.docx, потом, исправив, article-v2.docx. В журнале это две отдельные записи Upload с одним username и разными путями, и по ним видно, как шла работа. Будь у него право перезаписи, вторая загрузка могла бы лечь поверх первой, и в папке остался бы один файл, а прежняя версия исчезла бы без следа в виде самого документа.

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

Как нарезать папки, чтобы права не путались

В SFTPGo виртуальная папка сопоставляет виртуальный путь реальному пути или другому хранилищу, об этом говорит страница про виртуальные папки. Это удобно: пользователь видит аккуратное дерево /projects, /review, а на диске всё может лежать иначе. Но есть две детали, о которых стоит помнить заранее.

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

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

Как человек входит и что значит «отозвать один аккаунт»

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

SFTPGo поддерживает вход по паролю и по публичному ключу. Для людей, которые работают через SFTP-клиент, ключ обычно лучше: приватная часть остаётся на устройстве владельца, а на сервере хранится только публичная. Её нельзя случайно продиктовать по телефону. Для тех, кто не хочет возиться с клиентом, в продукте есть веб-интерфейс клиента, Web Client: человек заходит из браузера под своим именем и видит только свои разрешённые пути.

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

Есть тонкость, о которой полезно помнить: отзыв учётной записи не стирает историю. Записи журнала с её именем остаются, и это хорошо, потому что позже можно ответить на вопрос «что делал этот аккаунт до отключения». Поэтому имя пользователя лучше не переиспользовать. Если новый сотрудник получит логин i.petrova спустя год, в журнале два разных человека сольются под одной строкой. Давайте каждому новому человеку новое имя, пусть даже скучное, вроде i.petrova2.

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

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

Читаем запись о передаче

Теперь посмотрим на то, ради чего многие и начинают этот переход. Журнал SFTPGo, как следует из описания логов, представляет собой поток JSON-записей, а поле sender различает виды событий. Нас интересуют записи о передачах: в них есть тип операции (Upload или Download), имя пользователя, путь к файлу, размер в байтах, время, идентификатор соединения, протокол и, если что-то пошло не так, описание ошибки.

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

{"sender":"Upload","username":"i.petrova","file_path":"/acts-out/act-0412.pdf","size_bytes":184320,"time":"2026-03-10T09:14:02Z","connection_id":"SFTP_a1b2","protocol":"SFTP"}
{"sender":"Download","username":"v.sidorov","file_path":"/projects/offer-draft.docx","size_bytes":52410,"time":"2026-03-10T11:47:35Z","connection_id":"DAV_c3d4","protocol":"DAV"}

Разберём, что здесь можно прочитать.

• Тип события. Первая запись говорит о загрузке на сервер, вторая о скачивании с него. Это направление движения данных, а не оценка того, что с файлом стало дальше.
• Username. Ключевое поле, ради которого мы и меняли схему. Теперь это не общий shared, а конкретная учётная запись.
• Путь. Позволяет проверить, что действие произошло в области, которая этой роли положена. Если бухгалтерский аккаунт скачивает что-то из /projects, а по матрице у него там нет прав, значит, матрица и реальность разошлись, и это повод её проверить, а не просто закрыть вопрос.
• Размер. Сравнивается с размером файла, который вы знаете. Скачивание на 4 КБ вместо 50 МБ скорее похоже на оборванную передачу, чем на полученный документ.
• Время. Привязывает событие к рабочему дню человека. Ночная загрузка у того, кто работает с девяти до шести, не обвинение, а вопрос для спокойного разговора.
• connection_id. Связывает записи одного соединения. Если за одну сессию были листинг, три скачивания и одна загрузка, по идентификатору соединения вы соберёте это в одну историю, а не станете гадать по времени.
• Протокол. Различает, пришёл ли человек по SFTP, через веб-клиент или иным способом, который у вас включён. Если вы разрешили только SFTP, а в журнале внезапно другой протокол, пора проверить конфигурацию.
• Ошибка. Если она есть, передача, возможно, не состоялась. Запись о скачивании с ошибкой нельзя считать доказательством получения файла целиком.

Теперь сопоставим две записи с различающимися правами из нашей матрицы. Бухгалтер в первой записи пишет в /acts-out, где ей разрешена загрузка, и это нормально. Менеджер во второй записи читает из /projects, где ему разрешено скачивание. Если бы тот же менеджер попытался загрузить файл в /incoming-bank, сервер отказал бы ему на уровне прав, а в журнале появилась бы ошибка, но не успешная запись. Так права и журнал дополняют друг друга: права определяют, что вообще может случиться, а журнал фиксирует, что случилось из разрешённого.

Рассмотрим, чем эти две записи отличаются по существу, если смотреть на них глазами проверяющего.

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

Заметна и разница в протоколах: первая передача пришла по SFTP, вторая через DAV. Если по вашей политике менеджеры должны работать только через веб-клиент или SFTP, такая запись становится поводом проверить, какие протоколы реально включены, а не поводом искать виноватого.

Журнал нужно читать, а не только хранить

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

Что журнал не доказывает

Теперь о самой важной границе. В журнале стоит v.sidorov. Это идентификатор учётной записи, а не человека перед экраном. Документация прямо различает эти вещи: лог содержит идентификатор аккаунта, но не удостоверяет, кто именно в тот момент нажимал кнопки.

Почему это существенно, видно по нескольким сценариям:

1. Сотрудник продиктовал пароль коллеге, потому что торопился.
2. Приватный ключ скопирован на второй компьютер, а потом ноутбук остался открытым.
3. Учётные данные утекли через заражённый компьютер, и сессию открыл посторонний.
4. Автоматический скрипт под личной учёткой скачивает файлы по расписанию, и человек о конкретной передаче вообще не знает.

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

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

Разбор одной передачи

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

Шаг первый: найти в журнале передачи Download по пути /projects/offer-draft.docx за интересующий период. Находим запись с v.sidorov, временем около полудня, размером, равным размеру файла, и без ошибки. Значит, передача состоялась целиком.

Шаг второй: проверить, было ли это действие разрешено. По матрице у менеджера в /projects право скачивания есть, так что формального нарушения нет. Это важный результат: вопрос не «как он смог», а «что он сделал с разрешённым доступом».

Шаг третий: по connection_id собрать всю сессию. Что делал аккаунт до и после: открывал ли другие файлы, скачивал ли пакетом, откуда подключался по протоколу. Если соединение пришло по обычному для этого человека каналу в рабочее время, картина спокойная. Если нет, появляется основание для разговора и, возможно, для смены ключа.

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

Где всё это держать

Файловому серверу с личными аккаунтами не нужна экзотика, но нужен диск с запасом, процессор для шифрования соединений и стабильная сеть. Для небольшой команды хватает скромной конфигурации, а рост определяется объёмом файлов и числом одновременных сессий, и точное число людей без собственного замера обещать нельзя. На VPS MAATRIX доступны NVMe-диски, процессоры AMD EPYC и root-доступ, а значит, вы сами ставите сервис, настраиваете пользователей и решаете, как хранить журналы. В публичном предложении перечислены локации UK, US, RU и FR; актуальное наличие образов и расположение уточняйте в форме заказа.

Если ориентироваться на тарифную линейку, то для старта с несколькими людьми и небольшим архивом смотрят на младшие варианты вроде Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) или Uab (2 vCPU, 4 ГБ, 80 ГБ). Для архивов побольше и более активной работы подойдут Heka (4 vCPU, 8 ГБ, 160 ГБ) и выше. Это ресурсы, а не обещание ёмкости: реальную нагрузку проверяют на своих данных. Отдельно учтите, что автоматические резервные копии в тарифах не заявлены, поэтому копирование самих файлов и журналов придётся продумать самостоятельно.

Если вы переезжаете с обычного хостинга и вместе с сайтом хотите перенести хранилище, пригодится материал о переносе сайта и сервера с общего хостинга на свой VPS.

Что получается в итоге

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