Как настроить общий доступ к файлам без домена?

Общий доступ к файлам без домена можно организовать безопасно и предсказуемо, если вынести данные на отдельный узел, завести на нем именные учетные записи и считать права, резервные копии и увольнение сотрудников частью одной системы. Для организации на 20 человек Active Directory не обязательна. Обязателен порядок, который обычно ошибочно ждут именно от домена.

Плохая схема тоже работает первые месяцы. Кто-то открывает папку на своем рабочем компьютере, всем сообщает один пароль, а бухгалтерские документы лежат рядом с общими шаблонами. Затем владелец компьютера уходит в отпуск, пароль меняют только половине коллег, случайно удаленный каталог обнаруживают через неделю. Проблема не в SMB и не в отсутствии домена. Проблема в том, что у файлов нет назначенного владельца, у людей нет различимых учетных записей, а у администратора нет процедуры.

Для 20 человек достаточно автономного файлового узла

Отдельный файловый узел в рабочей группе закрывает задачу небольшой организации, пока все сотрудники работают в одном офисе или подключаются через управляемый VPN, а права укладываются в несколько понятных ролей. Этим узлом может быть NAS, сервер с Windows Server или Linux-сервер с Samba. Пользователь видит привычный путь вида \\files\company, но проверяет его учетную запись сам файловый узел, а не контроллер домена.

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

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

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

NAS, Windows Server и Samba решают разные задачи

Выбор платформы зависит от того, кто будет ее обслуживать и какие приложения должны работать рядом с файлами. Покупать NAS только потому, что у него меньше пунктов в первоначальной настройке, так же недальновидно, как ставить Windows Server ради знакомого Проводника.

NAS подходит, когда нужны в основном общие папки, снимки и простое управление пользователями. Перед покупкой проверьте срок обновлений производителя, поддержку актуальных версий SMB, порядок замены отказавшего диска и возможность выгрузить резервную копию на независимый носитель. Наличие двух или четырех дисков само по себе ничего не говорит о резервном копировании.

Windows Server в рабочей группе разумен, когда администратор хорошо знает Windows, нужны NTFS-права, аудит или совместимость с прикладной программой. За знакомый интерфейс придется платить лицензиями, обновлениями, отдельным управлением локальными учетными записями и клиентскими реквизитами. Заранее проверьте, нужны ли лицензии клиентского доступа для выбранного выпуска и сценария.

Linux с Samba дает гибкий файловый сервис, если в организации или у подрядчика есть настоящая компетенция Linux. Здесь надо документировать сопоставление пользователей, ACL, обновления, мониторинг и восстановление конфигурации. Официальное руководство Samba по smbpasswd отдельно указывает, что пользователь SMB обычно должен сначала существовать в системной базе, а команда добавляет его в локальную базу паролей Samba. Пропущенный шаг дает знакомую ситуацию: учетная запись вроде создана, а вход не работает.

Папка на Windows 11 годится только как временная мера при миграции или аварии. Она зависит от рабочего компьютера, его перезагрузок и владельца, смешивает пользовательские программы с серверной нагрузкой и плохо ремонтируется без остановки работы. Домашняя экономия быстро исчезает после первого рабочего дня, потраченного на восстановление случайно выключенного ПК.

Условия лицензии Windows 11 разрешают доступ к программному обеспечению с не более чем 20 других устройств для файловых и ряда других служб. Это не рекомендация строить файловое хранилище на рабочей станции. Лимит относится к устройствам, а не к сотрудникам, и организация на 20 человек легко упирается в него после появления вторых компьютеров и служебных узлов. Даже до лимита обычный ПК остается единственной точкой отказа, которую кто-то может выключить вечером.

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

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

Без домена личность пользователя живет на сервере

Каждому сотруднику нужна отдельная локальная учетная запись на файловом узле. Общий логин office удобен ровно до первого удаления файла, спора о доступе или увольнения: журнал покажет один логин, а смена пароля остановит сразу весь офис.

Локальная учетная запись действует только в базе того устройства, где ее создали. Два пользователя a.ivanov с одинаковым паролем на двух компьютерах не становятся одной сущностью: у них разные идентификаторы безопасности. При подключении к ресурсу Windows передает серверу имя и доказательство знания пароля, а сервер сверяет их со своей базой. Поэтому на клиенте можно войти под одним именем, а к папке подключиться как FILES\a.ivanov.

Практичная модель для 20 человек выглядит так:

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

Не копируйте один и тот же пароль локального администратора на все компьютеры и сервер. Microsoft отдельно предупреждает, что повторное использование локальных административных паролей помогает злоумышленнику перемещаться между устройствами с украденным паролем или его хешем. Совпадающие обычные имя и пароль на рабочем ПК и сервере иногда уменьшают число запросов на ввод реквизитов, но создают путаницу при смене пароля. Я предпочитаю один раз сохранить отдельные учетные данные файлового узла в диспетчере учетных данных Windows.

Учетный журнал должен отвечать хотя бы на вопросы, кто вошел, кто изменил права и кто удалил или переименовал критичный файл. Он не обязан хранить каждое открытие каждого документа годами. Такой объем быстро превращает журнал в мусор. Настройте аудит на папки с чувствительными данными и административные действия, а срок хранения привяжите к реальной процедуре разбора инцидентов.

Права надо выдавать группам, а не людям

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

В Windows доступ к файлу проходит две проверки: разрешения общего ресурса SMB и разрешения файловой системы NTFS. Итоговый доступ ограничивает более строгая комбинация. Человек может иметь Change на общем ресурсе, но только чтение на каталоге NTFS, и запись не сработает. Обратная ситуация тоже блокирует запись. Это различие часто путают, после чего администратор бессистемно добавляет Everyone: Full Control.

Есть две нормальные стратегии. Первая задает широкое разрешение изменения на уровне общего ресурса для аутентифицированных сотрудников, а детали ограничивает группами NTFS. Вторая зеркально настраивает оба уровня. Для маленькой команды первая проще для проверки, но административный полный доступ все равно должен остаться у отдельной группы. Гостевой доступ и анонимную запись следует отключить.

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

Владелец данных и администратор системы выполняют разные работы. Руководитель бухгалтерии решает, кто должен читать папку бухгалтерии. Администратор применяет решение и хранит запись об изменении. Если администратор сам угадывает бизнес-права, при первой реорганизации схема перестает соответствовать работе компании.

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

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

Рабочую группу можно настроить воспроизводимо

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

Ниже пример для автономного Windows Server. Он создает локального пользователя и группу бухгалтерии, добавляет пользователя в группу, публикует папку и задает NTFS-права. Пароль вводится скрыто и не попадает в историю команд.

$Password = Read-Host "Password for n.sadykova" -AsSecureString
New-LocalUser -Name "n.sadykova" -Password $Password -PasswordNeverExpires:$false
New-LocalGroup -Name "FS_Accounting_RW"
Add-LocalGroupMember -Group "FS_Accounting_RW" -Member "n.sadykova"

New-Item -ItemType Directory -Path "D:\Shares\Accounting"
New-SmbShare -Name "Accounting" -Path "D:\Shares\Accounting" `
  -ChangeAccess "FILES\FS_Accounting_RW" `
  -FullAccess "FILES\FS_Admins"

icacls "D:\Shares\Accounting" /inheritance:r
icacls "D:\Shares\Accounting" /grant `
  "FILES\FS_Admins:(OI)(CI)(F)" `
  "FILES\FS_Accounting_RW:(OI)(CI)(M)"

Здесь FILES надо заменить именем сервера, а группу FS_Admins создать заранее и заполнить отдельными административными учетными записями. Флаг (OI)(CI) передает разрешения файлам и вложенным каталогам, (M) дает изменение, (F) дает полный доступ. Не запускайте этот фрагмент вслепую на существующей папке: /inheritance:r удаляет унаследованные разрешения, поэтому сначала снимите текущий список ACL.

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

Get-SmbShareAccess -Name "Accounting"
icacls "D:\Shares\Accounting"
Get-LocalGroupMember -Group "FS_Accounting_RW"

В выводе первой команды должны остаться только ожидаемые группы и уровни Change или Full. icacls покажет строки с (OI)(CI)(M) для рабочей группы и (OI)(CI)(F) для администраторов. Третья команда перечислит именных участников роли. После настройки войдите с тестовой учетной записью чтения и тестовой учетной записью изменения: проверка только из-под администратора ничего не доказывает.

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

Подключение клиентов требует одного соглашения об именах

Все пользователи должны подключаться к одному имени сервера, например \\files\company, а не чередовать имя, IP-адрес и случайные псевдонимы. Единое имя упрощает инструкции, журналы, замену оборудования и диагностику. Закрепите адрес сервера в DHCP или DNS, но открывайте ресурс по имени.

На Windows ресурс можно подключить явной командой:

net use S: \\files\company /user:FILES\a.ivanov * /persistent:yes

Звездочка заставит Windows запросить пароль, а не сохранит его в командной строке. Проверить активные подключения можно командой net use. Удалить конкретное сопоставление можно так:

net use S: /delete

Windows не разрешает в одной пользовательской сессии подключаться к одному имени сервера одновременно под разными именами. Microsoft описывает это поведение как штатное. Если сотрудник уже открыл \\files\public под старой общей учетной записью, а затем подключает \\files\accounting под личной, он получает сообщение о другом имени и пароле или системную ошибку 1219.

Правильное исправление состоит не в создании DNS-псевдонимов ради обхода ограничения. Посмотрите net use, закройте файлы, удалите старые подключения и сохраненные реквизиты для сервера, затем подключитесь под одной личной учетной записью. Псевдоним скрывает конфликт и позволяет одному компьютеру держать две личности, что портит аудит.

Не раздавайте пользователям IP-адрес сервера как основной путь. В среде без домена Kerberos обычно недоступен, и SMB использует NTLM. Подключение по IP точно не улучшает эту модель, мешает аккуратной замене узла и создает еще один вариант имени в кеше. Если имя не разрешается, исправьте локальный DNS или DHCP, а не инструкцию для сотрудников.

SMB нужно защищать как внутренний сервис

Файловый ресурс нельзя публиковать напрямую в интернет. Порт TCP 445 должен быть доступен только из нужных офисных сетей и VPN. Для удаленной работы сначала поднимается управляемый VPN, после чего клиент обращается к тому же имени сервера. Проброс 445 на маршрутизаторе экономит десять минут настройки и создает постоянную внешнюю поверхность атаки.

Отключите SMB1 и гостевой доступ. Microsoft указывает, что SMB1 не устанавливается по умолчанию в современных выпусках Windows, и рекомендует удалить его, если старый компонент все еще включен. Если древний сканер умеет писать только по SMB1, не ослабляйте весь сервер. Изолируйте устройство, обновите его или дайте ему отдельный промежуточный каталог с жестко ограниченным доступом.

Подписание SMB и шифрование решают разные задачи. Подпись подтверждает целостность сообщений и защищает от подмены и relay-атак. Шифрование SMB 3 скрывает содержимое трафика от прослушивания. В документации Microsoft по SMB signing прямо сказано, что стойкость защиты зависит от сеансового ключа, который в рабочей группе обычно получен через NTLMv2, а Kerberos предпочтительнее. Отсутствие домена не делает подпись бесполезной, но хороший уникальный пароль здесь особенно важен.

Windows 11 24H2 и Windows Server 2025 требуют подписание для новых входящих и исходящих сценариев по умолчанию. Старый NAS или МФУ может перестать подключаться после обновления клиента. Не выключайте требование подписи как первое средство. Сначала проверьте обновление прошивки и поддержку SMB 2 или 3, затем включите аудит несовместимых клиентов. Microsoft рекомендует не отключать подпись даже при снижении скорости, потому что она защищает от подмены и перехвата проверки подлинности.

Шифрование стоит требовать для чувствительных папок и сетей, которым вы не доверяете полностью. Оно потребляет ресурсы процессора, поэтому скорость проверяют на вашем оборудовании и типичных файлах. В закрытой офисной сети с управляемыми коммутаторами подписание может быть обязательным, а шифрование выборочным. Через чужую или общую сеть трафик должен идти внутри VPN, даже если SMB умеет шифровать данные.

Разделите пользовательские компьютеры, серверы и гостевой Wi-Fi сетевыми правилами. Файловый узел должен принимать SMB от рабочих устройств, но не от телевизоров, личных телефонов и посетителей. Административный интерфейс NAS или сервера разрешите только администраторской станции или отдельной управляющей сети.

Снимок помогает после ошибки, резервная копия после аварии

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

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

Задание резервного копирования должно работать от отдельной служебной учетной записи. Пользователю, который меняет документы, не нужны права удаления копий. Файловому серверу тоже не обязательно иметь постоянный полный доступ к месту хранения истории. Чем меньше общих реквизитов между рабочими данными и копиями, тем труднее одной украденной учетной записью уничтожить оба набора.

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

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

Заранее разделите два показателя. Допустимая потеря данных отвечает на вопрос, сколько последних часов работы компания способна повторить. Допустимое время простоя показывает, сколько часов она может ждать возврата сервиса. Ежедневная копия не подходит, если бухгалтерия не готова заново вводить целый день, а запасной диск в сейфе не обеспечивает быстрый запуск, если никто не умеет развернуть на нем папки и права. Эти числа определяют частоту копий, скорость канала, объем истории и необходимость запасного узла.

Рост ломает ручное управление раньше, чем хранилище

Переход к домену нужен не при магическом двадцать первом сотруднике. Он нужен, когда стоимость ручного управления личностями, компьютерами и политиками становится выше стоимости центральной службы каталогов. Файловый сервер может справляться с объемом и сотней пользователей, пока администратор уже теряет часы на одинаковые изменения в разных системах.

Сигналы к пересмотру архитектуры видны заранее:

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

До миграции поддерживайте реестр пользователей и групп файлового узла. Раз в месяц владелец каждой закрытой папки подтверждает список групп, а администратор сверяет отключенных сотрудников, служебные учетные записи и права резервного копирования. Это ручная процедура, но для 20 человек она прозрачнее плохо внедренного домена.

Подготовьте миграцию до того, как она понадобится. Используйте именные учетные записи, выдавайте права группам, обращайтесь к серверу по одному DNS-имени и не зашивайте IP-адреса в ярлыки и приложения. Тогда при появлении каталога вы сопоставите старые роли с новыми группами и перенесете данные, не объясняя каждому сотруднику новый путь. Общий логин и десятки прямых ACL придется разбирать вручную.

Если компании нужен отдельный серверный узел и нет своего специалиста по инфраструктуре, системный интегратор должен передать не только установленное оборудование, но и схему прав, план копирования, перечень учетных записей, правила сети и проверенный сценарий восстановления. GSE может подобрать серверную платформу S200 и выполнить системную интеграцию с дальнейшей круглосуточной поддержкой по Казахстану. Требуйте, чтобы результат проекта оставался понятным вашей организации, а не зависел от одного инженера.

Без домена можно долго работать нормально. Нельзя долго работать без именных учетных записей, ролевых групп, отдельной копии и человека, который закрывает доступ в день кадрового изменения. Если эти четыре вещи уже работают, Active Directory станет осознанным следующим уровнем управления, а не дорогой попыткой исправить папку Общая.