Дескриптор безопасности

Дескрипторы безопасности — это структуры данных с информацией о безопасности для защищаемых объектов Windows , то есть объектов, которые можно идентифицировать по уникальному имени. Дескрипторы безопасности могут быть связаны с любыми именованными объектами, включая файлы , папки , общие ресурсы, ключи реестра , процессы, потоки, именованные каналы, службы, объекты заданий и другие ресурсы. ^[1]

Дескрипторы безопасности содержат списки управления доступом по усмотрению (DACL), которые содержат записи управления доступом (ACE), которые предоставляют или запрещают доступ доверенным лицам, таким как пользователи или группы. Они также содержат список управления доступом к системе (SACL), который контролирует аудит доступа к объектам. ^{[2] [3]} ACE могут быть явно применены к объекту или унаследованы от родительского объекта. Порядок ACE в ACL важен: ACE, которым запрещен доступ, располагаются выше в порядке, чем ACE, предоставляющие доступ. Дескрипторы безопасности также содержат владельца объекта.

Обязательный контроль целостности реализуется посредством нового типа ACE в дескрипторе безопасности. ^[4]

Разрешения для файлов и папок можно редактировать с помощью различных инструментов, включая Windows Explorer , WMI , инструменты командной строки, такие как Cacls , XCacls, ICacls , SubInACL, ^[5] бесплатную консоль Win32 FILEACL, ^{[6] [7]} бесплатную программную утилиту SetACL и другие коммунальные услуги. Чтобы редактировать дескриптор безопасности, пользователю необходимы разрешения WRITE_DAC для объекта, ^[8] разрешение, которое обычно делегируется по умолчанию администраторам и владельцу объекта.

Разрешения в NTFS

В следующей таблице приведены разрешения NTFS и их роли (в отдельных строках). В таблице представлена ​​следующая информация: ^{[9] [10] [11]}

• Код разрешения: каждая запись управления доступом (ACE) определяет свое разрешение в двоичном коде. Существует 14 кодов (12 в старых системах).
• Значение. Каждый код разрешения имеет значение в зависимости от того, применяется ли он к файлу или папке. Например, код 0x01 в файле указывает на разрешение на чтение файла, а на папке — на разрешение отображать содержимое папки. Однако знать только смысл бесполезно. В ACE также должно быть указано, к кому применяется разрешение и предоставлено ли это разрешение или отказано.
• Входит в: Помимо индивидуальных разрешений, ACE может указывать специальные разрешения, известные как «общие права доступа». Эти специальные разрешения являются эквивалентами ряда индивидуальных разрешений. Например, GENERIC_READ (или GR) является эквивалентом «Чтение данных», «Чтение атрибутов», «Чтение расширенных атрибутов», «Разрешения на чтение» и «Синхронизировать». Поскольку имеет смысл запрашивать эти пять одновременно, удобнее запрашивать «GENERIC_READ».
• Псевдоним: две утилиты командной строки Windows ( icacls и cacls ) имеют свои собственные псевдонимы для этих разрешений.

Большинство этих разрешений не требуют пояснений, за исключением следующих:

1. Для переименования файла требуется разрешение «Удалить». ^[12]
2. Проводник не показывает «Синхронизировать» и всегда устанавливает его. Многопоточным приложениям, таким как Проводник и Командная строка Windows, требуется разрешение «Синхронизировать», чтобы иметь возможность работать с файлами и папками. ^[13]

Сноски

1. GENERIC_READ, известный как «Чтение» в проводнике.
2. GENERIC_EXECUTE, известный как «Чтение и выполнение» в проводнике.
3. GENERIC_WRITE, известный как «Запись» в проводнике.
4. GENERIC_ALL, известный как «Полный доступ» в проводнике.
5. проводнике известен как «Изменить».

Смотрите также

• Контроль доступа § Компьютерная безопасность
• Аудит безопасности информационных технологий
• Авторизация
• Компьютерная безопасность
• Информационная безопасность
• Токен (архитектура Windows NT)
• идентификатор безопасности Windows
• SDDL

Рекомендации

1. «Защищаемые объекты». Майкрософт . 24 апреля 2008 г. Проверено 16 июля 2008 г.
2. «Что такое дескрипторы безопасности и списки контроля доступа?» Майкрософт . Архивировано из оригинала 5 мая 2008 г. Проверено 16 июля 2008 г.
3. «DACL и ACE» . Майкрософт . 24 апреля 2008 г. Проверено 16 июля 2008 г.
4. https://msdn.microsoft.com/en-us/library/bb625957.aspx Что такое механизм обеспечения целостности Windows?
5. Домашняя страница SubInACL
6. Домашняя страница FILEACL. Архивировано 29 августа 2012 г. на Wayback Machine.
7. "FILEACL v3.0.1.6" . Майкрософт . 2004-03-23. Архивировано из оригинала 16 апреля 2008 года . Проверено 25 июля 2008 г.
8. «Тип данных ACCESS_MASK» . Майкрософт . 24 апреля 2008 г. Проверено 23 июля 2008 г.
9. «Как работают разрешения» . Майкрософт . 21 июня 2013 г. Проверено 24 ноября 2017 г.
10. Ричард Сивил. «Как это работает. Разрешения NTFS, часть 2». Майкрософт . Проверено 24 ноября 2017 г.
11. Ричард Сивил. «Как это работает. Разрешения NTFS». Майкрософт . Проверено 24 ноября 2017 г.
12. Чен, Раймонд (22 октября 2021 г.). «Переименование файла — это многоэтапный процесс, только одним из которых является изменение имени файла». Старая новая вещь . Майкрософт . Открытие с разрешением DELETE дает разрешение на переименование файла. Требуется разрешение DELETE, поскольку старое имя удаляется.
13. Чен, Раймонд (18 ноября 2019 г.). «Я установил один и тот же список ACL для графического интерфейса и для icacls, но результаты разные». Старая новая вещь . Майкрософт .

Внешние ссылки

• Описание команды CACLS на SS64.com
• Страница SetACL SourceForge