Права доступа в Windows: NTFS, SMB, настройка ACL и безопасность

Права доступа в Windows определяются двумя уровнями: ACL файловой системы NTFS и разрешениями общего ресурса SMB. Для локального пути действует NTFS ACL. При обращении по сетевому пути UNC, например \\fileserver\departments, Windows учитывает разрешения SMB и NTFS, а итоговый доступ ограничивает более строгий уровень.

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

Запись "права доступа 1 2 2" не относится к общепринятому стандартному формату Windows ACL. В NTFS обычно используются имена разрешений, флаги наследования, SID и access mask. Числовое значение можно расшифровать только по контексту конкретной команды, программы или платформы.

Права доступа в Windows: краткий ответ и принцип работы

Каждая проверка доступа связывает учетную запись, ресурс и набор разрешений. Учетная запись получает SID, входит в одну или несколько групп, а ACL объекта содержит записи ACE для пользователей и групп. Windows вычисляет результат по этим записям, наследованию и типу обращения: чтение, запись, изменение, удаление или запуск.

Для файлового сервера удобно разделять роли. Например, группа FS-Accounting-Read получает чтение, FS-Accounting-Modify получает изменение, а отдельная административная группа управляет ACL. Пользователей добавляют в группы, а не назначают каждому отдельную запись на папке.

Что определяет итоговый доступ к файлу или папке

В модели Windows участвуют следующие элементы:

Субъект, пользовательская или сервисная учетная запись с конкретным SID.
Ресурс, файл, папка, общий ресурс или другой защищаемый объект.
Разрешение, операция, например чтение содержимого, запись, удаление или полный доступ.
DACL, список разрешающих и запрещающих ACE.
Владелец, учетная запись или группа, которая может менять дескриптор безопасности.
Наследование, перенос записей ACL с родительской папки на вложенные объекты.

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

Локальный доступ и доступ по SMB

Путь D:\Shares\Projects проверяется по NTFS ACL. Путь \\fileserver\Projects проходит проверку разрешений SMB, после чего Windows проверяет NTFS ACL на сервере. Если Share разрешает изменение, а NTFS разрешает только чтение, по сети пользователь получит чтение. Если Share разрешает чтение, а NTFS запрещает его, чтение тоже завершится отказом.

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

Подробная схема создания общих папок, настройки NTFS и Share-разрешений приведена в руководстве по SMB-ресурсам в Windows Server 2026.

Как устроены права доступа NTFS

NTFS хранит дескриптор безопасности объекта. В него входят владелец, DACL и, при включенном аудите, SACL. DACL определяет разрешения, а SACL задает события, которые Windows должна записывать в журнал безопасности.

Пользователи, группы и записи ACL

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

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

Роль	Группа	Типичный доступ
Читатель	`Dept-Read`	Чтение и выполнение
Редактор	`Dept-Modify`	Чтение, создание, изменение и удаление
Администратор ресурса	`Dept-Admins`	Полный контроль, включая изменение ACL

Наследование прав в дереве папок

Наследуемая ACE приходит с родительской папки и обычно распространяется на папки, файлы или оба типа объектов. Явная ACE задана непосредственно на текущем объекте. При диагностике смотрите на источник записи и область применения, например "эта папка, вложенные папки и файлы".

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

Перед массовым изменением сохраните ACL:

icacls D:\Shares\Projects /save C:\Admin\projects-acl.txt /t /c

Параметр /t обходит вложенные объекты, а /c продолжает обработку после ошибки. Файл ACL храните с описанием даты, владельца и цели изменения.

Почему явный запрет требует осторожности

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

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

Разрешения общего доступа SMB и эффективные права

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

Как сравнить разрешения SMB и NTFS

Запишите точный UNC-путь и локальный путь на сервере.
Определите учетную запись, под которой выполняется подключение.
Проверьте членство пользователя в доменных и локальных группах.
Откройте свойства общего ресурса и вкладку Share Permissions.
На вкладке Security проверьте NTFS ACL и область применения ACE.
Сравните локальную проверку с сетевой, используя одинаковую учетную запись.

Сохраненные учетные данные Windows могут скрывать реальную причину отказа. При повторной проверке удалите старое подключение командой net use * /delete, затем подключите ресурс заново с нужной учетной записью.

Доступ к общим папкам на сервере

Пример структуры:

D:\Shares\Departments\Finance
D:\Shares\Departments\HR
D:\Shares\Departments\IT

На корне ресурса можно дать авторизованным пользователям минимальное чтение, а на папках отделов назначить группы Finance-Read, Finance-Modify и соответствующие административные группы. Пользователь финансового отдела не должен автоматически получать доступ к HR из-за наследования от общей папки.

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

Особенности доступа через NAS и гибридную инфраструктуру

NAS может использовать локальные учетные записи, Active Directory, LDAP или собственную ACL-модель. Название группы в Windows не гарантирует совпадение с группой на хранилище. При интеграции проверяйте домен, SID, способ сопоставления пользователей, версию SMB и правила ACL на стороне NAS.

Правила NTFS нельзя механически переносить на TrueNAS или другой сервер хранения. Реализация ACL, наследования и владельцев может отличаться. Для отдельного NAS полезно свериться с руководством по контролю доступа и делегированию прав в TrueNAS.

Как настроить права доступа пользователям и группам Windows

Шаг 1. Описать матрицу доступа

До открытия окна свойств зафиксируйте роли и операции. Минимальная матрица может выглядеть так:

Роль	Чтение	Создание и изменение	Удаление	Изменение ACL
Сотрудник	Да	Нет	Нет	Нет
Редактор	Да	Да	Да	Нет
Владелец данных	Да	Да	Да	По регламенту
Администратор	Да	Да	Да	Да

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

Шаг 2. Создать группы безопасности

В Active Directory создайте группы по ресурсу и уровню доступа. Пример имен: FS-Projects-Read, FS-Projects-Modify, FS-Projects-Admins. Добавьте пользователей в нужные группы и дождитесь обновления сеанса.

Проверить текущий токен можно так:

whoami /user
whoami /groups

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

Шаг 3. Назначить NTFS-разрешения через свойства папки

Создайте тестовую папку, например D:\Shares\Projects-Test.
Откройте свойства, вкладку Security и кнопку Advanced.
Проверьте владельца и состояние наследования.
Добавьте группу чтения или изменения.
Выберите базовое разрешение и область применения.
Удалите лишние записи только после проверки их назначения.
Проверьте Effective Access для тестовой учетной записи.

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

Шаг 4. Опубликовать папку по SMB

На сервере задайте понятное имя общего ресурса, проверьте Share Permissions и убедитесь, что сетевой путь ведет к нужному локальному каталогу. Не используйте широкую группу без причины. После публикации проверьте подключение с клиентского компьютера по UNC-пути.

Рабочие команды для проверки подключений:

net share
net use
net use \\fileserver\Projects

Для размещения тестового Windows Server в облаке можно использовать Timeweb Cloud, но сетевую доступность, доменную интеграцию и правила безопасности нужно настроить отдельно.

Шаг 5. Проверить доступ от имени разных ролей

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

Снимите ACL до и после настройки:

icacls D:\Shares\Projects-Test /t
icacls D:\Shares\Projects-Test /save C:\Admin\projects-test-acl.txt /t /c

Тестовая проверка должна включать локальный путь и UNC-путь. После завершения удалите временные группы, учетные записи и тестовые данные.

Что означает "права доступа 1 2 2" в Windows

Windows NTFS не использует универсальную трехзначную запись "1 2 2" для обозначения прав пользователя, группы и остальных. Такой формат чаще связывают с POSIX-моделью chmod, условными кодами панели управления или битовыми значениями конкретного приложения.

Чем числовые права Windows отличаются от chmod

В POSIX права обычно группируются для владельца, группы и остальных, а цифры складываются из битов чтения, записи и выполнения. В NTFS ACL хранит отдельные ACE для SID, тип записи Allow или Deny, набор разрешений и флаги наследования.

У числовой маски Windows нет смысла без определения инструмента. Одно и то же число может обозначать разные комбинации прав в разных API, утилитах или интерфейсах. Поэтому переносить запись 1 2 2 в свойства NTFS или заменять ею Read, Write и Execute нельзя.

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

Сохраните полный текст, где появилась запись.
Запишите имя программы, команду, версию Windows и тип ресурса.
Определите, относится ли число к access mask, коду роли, режиму наследования или Unix-правам.
Найдите перечисление флагов именно для этого инструмента.
Сопоставьте маску с именами разрешений.
Проверьте расшифровку практическим тестом на копии папки.

Без этих данных корректная трактовка невозможна. В рабочем отчете указывайте не только число, но и SID, путь, тип ACE и область наследования.

Как читать права через icacls

Утилита icacls показывает ACL NTFS в текстовом виде:

icacls D:\Shares\Projects

В выводе встречаются сокращения вроде (F) для полного доступа, (M) для изменения, (RX) для чтения и выполнения, (R) для чтения и (W) для записи. Флаги наследования рядом с записью показывают, куда распространяется ACE. Точное значение нужно сопоставлять с полным выводом и контекстом каталога.

Для просмотра ACL в PowerShell:

$acl = Get-Acl -Path 'D:\Shares\Projects'
$acl.Owner
$acl.Access | Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited, InheritanceFlags, PropagationFlags

Get-Acl помогает увидеть владельца, тип доступа и наследование. Set-Acl меняет ACL, поэтому перед его применением сохраните исходное состояние и протестируйте скрипт на отдельной папке.

Как исправить ошибку "отказано в доступе" в Windows

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

Проверка учетной записи и членства в группах

Проверьте имя и SID текущего пользователя:

whoami
whoami /user
whoami /groups

Если права недавно выдали через группу, завершите сеанс и войдите снова. Подключение к SMB может использовать сохраненные учетные данные. Команда net use покажет активные подключения, а net use * /delete удалит их после подтверждения.

Проверка владельца, ACL и наследования

Откройте Advanced Security и проверьте владельца, явные записи, унаследованные ACE и область применения. Убедитесь, что запрет не приходит через другую группу. Сравните ACL родительской папки и самого файла.

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

Проверка доступа по SMB

Сначала откройте файл локально на сервере, затем повторите действие через UNC-путь. Если локальный доступ работает, а сетевой нет, проверьте Share Permissions, имя сервера, учетные данные, сетевую аутентификацию и доступность TCP-порта SMB.

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

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

Базовый набор:

icacls D:\Shares\Projects /verify
icacls D:\Shares\Projects /t
Get-Acl -Path 'D:\Shares\Projects' | Format-List
whoami /groups

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

Для системной проверки политик доступа пригодится руководство по аудиту политик и прав доступа в Windows и других системах.

Практический чеклист настройки и проверки прав доступа Windows

Перед выдачей прав

Определите владельца ресурса и классификацию данных.
Составьте матрицу ролей и операций.
Создайте группы чтения, изменения и администрирования.
Проверьте границы наследования.
Сохраните исходные ACL.
Подготовьте тестовую папку и учетные записи.

После выдачи прав

Проверьте чтение, создание, изменение и удаление для каждой роли.
Сравните локальный и SMB-доступ.
Проверьте Effective Access, явные запреты и наследование.
Убедитесь, что резервное копирование и сервисы продолжают работать.
Включите аудит только для нужных ресурсов и операций.
Сохраните итоговый ACL и запишите дату, автора и причину изменения.
Удалите временные учетные записи и тестовые данные.

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

Главное правило: сначала определите роль и ожидаемую операцию, затем назначьте право группе, проверьте NTFS и SMB, после чего подтвердите результат реальным тестом.