Network Share Permissions — это права на вход в папку именно по сети: через \\server\share. Они решают не всю задачу безопасности, но без них настройка общей папки часто превращается в хаос: пользователи видят лишнее, кто-то случайно удаляет файлы, а администратор потом не понимает, почему «я же всё запретил».
На практике я настраиваю такие права по простому правилу: на уровне общей папки даю базовый минимум, а детальные права закрываю через NTFS-разрешения и группы. Так схема получается понятной, проверяемой и не разваливается после первого же изменения в штате.
- Что именно ограничивают Network Share Permissions
- Как сочетать Share Permissions и NTFS-разрешения
- Нормальная схема прав для ограниченного доступа
- Пошаговая настройка Network Share Permissions в Windows
- Как строить доступ: группы лучше пользователей
- Что выбрать в зависимости от ситуации
- Сценарии, которые чаще всего встречаются на практике
- Несколько человек должны читать и писать в одну папку
- Все сотрудники читают, но писать должны только двое
- В одной папке лежат данные разных отделов
- Временные сотрудники или подрядчики
- Как проверить, что доступ действительно ограничен
- Частые ошибки при настройке Network Share Permissions
- Как лучше сделать, чтобы потом не разгребать
Что именно ограничивают Network Share Permissions
Когда вы открываете свойства папки в Windows и переходите в Доступ → Расширенная настройка → Разрешения, вы видите именно сетевые разрешения общей папки. Они работают только при подключении по сети. Если человек сел за сам сервер и открыл папку локально, эти права на него не действуют — там работают NTFS-разрешения.
На уровне Network Share Permissions обычно есть три варианта:
- Read — пользователь может читать файлы, открывать папки и запускать программы, но не может создавать или менять файлы.
- Change — пользователь может читать, создавать, изменять, переименовывать и удалять файлы в пределах разрешений NTFS.
- Full Control — даёт управление самой общей папкой, включая изменение share-разрешений. Для обычных пользователей это почти всегда лишнее.
Главная особенность: итоговый доступ считается по самому строгому уровню. То есть если на уровне Network Share Permissions у пользователя Read, а на NTFS у него Modify, по сети он всё равно сможет только читать. И наоборот: если share даёт Change, но NTFS только Read, писать пользователь не сможет.
Не меняйте массово права на старых папках без проверки. Сначала посмотрите, кто реально пользуется доступом, сделайте резервную копию настроек и протестируйте схему на одной папке.
Как сочетать Share Permissions и NTFS-разрешения
Самая частая ошибка — пытаться решить всё только через Network Share Permissions. Это неудобно, потому что на уровне общей папки прав мало: Read, Change и Full Control. Для нормальной работы нужны NTFS-разрешения: они позволяют гибко управлять доступом к папкам, файлам, наследованием и отдельными действиями.
| Уровень прав | Где настраивается | Что контролирует | Как обычно использовать |
|---|---|---|---|
| Network Share Permissions | Свойства папки → Доступ → Расширенная настройка → Разрешения | Доступ к общей папке по сети | Дать базовый вход: Read для всех допустимых пользователей, Change для групп записи, Full Control только администраторам |
| NTFS Permissions | Свойства папки → Безопасность → Дополнительно | Доступ к файлам и папкам на диске | Точно раздать Read, Modify, Full Control, настроить наследование и владельца |
| Эффективные права | Результат пересечения Share и NTFS | То, что пользователь реально сможет сделать | Проверять через тестового пользователя или вкладку Effective Access |
Пример. Пользователь входит в группу FS_Project_Change. На уровне Network Share Permissions группе выдан Read, а на NTFS — Modify. В итоге пользователь сможет только читать. Чтобы он мог писать, нужно поднять share-уровень до Change, но оставить NTFS-разрешения под контролем.
Нормальная схема прав для ограниченного доступа
Для большинства рабочих папок я использую такую схему:
- Administrators / Server Admins — Full Control на Share и NTFS.
- Группа чтения, например
FS_Invoices_Read— Read на Share и Read на NTFS. - Группа записи, например
FS_Invoices_Change— Change на Share и Modify на NTFS. - Все остальные — без доступа или только Read, если папка действительно предназначена для широкого чтения.
Почему так удобно: на уровне общей папки не нужно каждый раз думать о тонкостях. Вы просто открываете сетевой вход через Read, а реальное разделение делаете группами NTFS. Если позже понадобится дать кому-то запись, вы добавляете пользователя в группу записи, а не лезете каждый раз в глубокую структуру разрешений.
Пошаговая настройка Network Share Permissions в Windows
- Создайте понятную структуру папок.
Например:D:\Shares\Finance,D:\Shares\Projects,D:\Shares\Contracts. Не смешивайте в одной папке данные с разными требованиями к доступу, если потом планируете их разделять. - Создайте группы доступа.
В домене лучше использовать Active Directory-группы:FS_Finance_Read,FS_Finance_Change,FS_Finance_Admin. В рабочей группе можно использовать локальные группы на сервере, но управлять ими сложнее. - Откройте сетевые разрешения.
Правый клик по папке → Свойства → вкладка Доступ → Расширенная настройка → Разрешения. - Уберите лишние записи.
Если папка не должна быть доступна всем, удалите Everyone. Если доступ нужен широкому кругу сотрудников, можно оставить Everyone или Authenticated Users только на Read, но для конфиденциальных данных лучше использовать явные группы. - Добавьте нужные группы.
Например:DOMAIN\FS_Finance_Read→ Read,DOMAIN\FS_Finance_Change→ Change,DOMAIN\Server Admins→ Full Control. - Настройте NTFS-разрешения.
Вкладка Безопасность → Изменить → добавьте те же группы. Для чтения — Read, для записи — Modify, для администраторов — Full Control. - Проверьте наследование.
Если все вложенные папки должны иметь одинаковую модель доступа, наследование можно оставить. Если папка должна жить по отдельным правилам, отключайте наследование осознанно и лучше сначала скопируйте унаследованные разрешения. - Протестируйте доступ с обычного пользователя.
Не проверяйте только из-под администратора. Зайдите с учётной записи пользователя, который должен читать, затем с пользователем записи, затем с пользователем без доступа.
Как строить доступ: группы лучше пользователей
Права напрямую пользователям — это почти всегда будущая проблема. Через месяц вы уже не вспомните, почему Иванову дали доступ, почему Петрова оставили после перевода, а Сидорова добавили в две разные группы с разными правами.
Лучше делать так:
- Пользователи входят в обычные рабочие группы:
Sales,Accounting,Project_Alpha. - Рабочие группы входят в файловые группы доступа:
FS_Sales_Read,FS_Accounting_Change. - Права на папку выдаются только файловым группам.
Так при смене сотрудника вы меняете состав рабочей группы или файловой группы, а не пересобираете ACL на папке. Для небольших компаний это может показаться лишним, но когда папок больше десяти, такой подход экономит много времени.
Что выбрать в зависимости от ситуации
| Ситуация | Network Share Permissions | NTFS-разрешения | Комментарий |
|---|---|---|---|
| Обычная папка отдела: все сотрудники отдела читают и пишут | FS_Department_Change → Change |
FS_Department_Change → Modify |
Простая схема. Не давайте Full Control обычным сотрудникам. |
| Все могут читать, писать могут только ответственные | Everyone или Authenticated Users → Read; группа записи → Change |
Группа чтения → Read; группа записи → Modify | Подходит для шаблонов, инструкций, общих справочников. |
| Конфиденциальная папка: доступ только отдельным людям | Только явные группы: Read или Change | Только явные группы: Read или Modify | Everyone лучше убрать. Для чувствительных данных включите аудит и Access-Based Enumeration. |
| Пользователи должны создавать файлы, но не удалять чужие | Группа записи → Change | Расширенные NTFS-разрешения: создать файлы/записать данные, но без Delete | Обычный Change/Modify включает удаление. Если удаление нельзя разрешать, настраивайте детальные NTFS-права. |
| Администраторы должны управлять папкой | Server Admins или Administrators → Full Control |
Та же группа → Full Control | Full Control на уровне share не нужен обычным пользователям. |
Сценарии, которые чаще всего встречаются на практике
Несколько человек должны читать и писать в одну папку
Создайте группу FS_Project_ReadWrite, добавьте туда нужных пользователей и выдайте:
- на Network Share Permissions — Change;
- на NTFS — Modify.
Не давайте каждому пользователю права отдельно. Через месяц начнутся вопросы: кто имел доступ, кого уже можно убрать, почему один пользователь может больше другого. Группа решает это сразу.
Все сотрудники читают, но писать должны только двое
Например, папка с инструкциями. Тогда:
- группа чтения
FS_Manuals_Readполучает Read; - группа записи
FS_Manuals_Changeполучает Change на уровне share и Modify на NTFS; - обычные пользователи не входят в группу записи.
Если папка действительно общедоступная внутри компании, можно оставить Authenticated Users на Read. Если инструкции не должны видеть подрядчики или гости сети, лучше убрать широкие записи и добавить только нужные группы.
В одной папке лежат данные разных отделов
Если внутри \\server\Company находятся папки бухгалтерии, продаж и HR, а доступ у них разный, такая структура быстро станет проблемой. Наследование начнёт конфликтовать с исключениями, а пользователи будут жаловаться, что «раньше работало».
Лучшее решение — разделить такие данные на разные общие папки: \\server\Finance, \\server\Sales, \\server\HR. Если пользователям неудобно запоминать много путей, можно использовать DFS-пространство, но сами права всё равно должны оставаться на отдельных папках.
Временные сотрудники или подрядчики
Для временного доступа не давайте права напрямую человеку «на всякий случай». Создайте отдельную группу, например FS_Project_Alpha_Temp, добавьте туда временные учётные записи и ограничьте срок действия учётных записей или членства в группе.
После завершения проекта группу нужно очистить. Иначе через полгода в правах останутся учётные записи людей, которые уже не имеют отношения к компании.
Как проверить, что доступ действительно ограничен
Проверка — обязательная часть настройки. Без неё вы видите только то, что настроили, но не то, что реально работает.
- Зайдите на клиентском компьютере под обычным пользователем, не администратором.
- Откройте путь вида
\\server\share. - Проверьте чтение: откройте файл, зайдите во вложенные папки.
- Проверьте запись: создайте тестовый файл, измените его, попробуйте удалить.
- Проверьте запрет: пользователь без доступа должен получать отказ, а не видеть папку «на всякий случай».
- Если пользователь должен видеть только свои папки, включите Access-Based Enumeration на общей папке.
Access-Based Enumeration не заменяет права, но скрывает папки, к которым у пользователя нет доступа. Это удобно для больших файловых структур: человек не видит лишние разделы и меньше путается.
Если права добавили, а пользователь всё равно не может зайти, проверьте несколько вещей:
- пользователь действительно входит в нужную группу;
- после изменения членства в группе пользователь перелогинился или обновил токен;
- нет явной записи Deny, которая блокирует доступ;
- share-права не строже NTFS-прав;
- пользователь подключается именно к той общей папке, где вы меняли настройки.
Частые ошибки при настройке Network Share Permissions
- Выдать Everyone Full Control. Это превращает общую папку в открытую зону, где любой авторизованный пользователь может менять права и удалять данные.
- Настраивать только Share Permissions. На этом уровне нет гибкости. Детальное управление должно быть на NTFS.
- Давать права пользователям напрямую. Так быстро теряется контроль. Группы проще проверять и чистить.
- Использовать Deny без необходимости. Запрещающая запись перекрывает разрешающие и часто ломает доступ там, где администратор этого не ожидал.
- Оставлять старые группы после реорганизации. Доступ остаётся даже тогда, когда люди уже перешли в другой отдел или уволились.
- Считать скрытую папку защитой. Share с символом
$в конце имени просто не отображается в обычном списке. Если права позволяют, доступ по прямому пути всё равно возможен. - Проверять доступ только из-под администратора. Администратор почти всегда видит больше, чем обычный пользователь.
- Отключать наследование везде подряд. Это создаёт сложную структуру прав, которую потом трудно объяснить и поддерживать.
Как лучше сделать, чтобы потом не разгребать
Хорошая настройка Network Share Permissions выглядит скучно, и это нормально. Чем меньше исключений, тем проще её поддерживать.
- Используйте понятные имена групп:
