Дескрипторы безопасности в Windows.
Дескрипторы безопасности используются в Windows для защиты и аудита ресурсов. Дескриптор безопасности содержит владельца, основную группу, дискреционный список контроля доступа и системный список контроля доступа.
Владелец и основная группа.
Поля владельца и основной группы
содержат идентификаторы безопасности. Владелец — это принципал безопасности,
владеющий объектом. Владелец ресурса располагает полным доступом к объекту,
включая возможность добавления и удаления разрешений доступа в дескрипторе
безопасности.
Основная
группа содержится в дескрипторе безопасности лишь для обеспечения совместимости
с подсистемой POSIX. Система Windows не использует эту часть дескриптора
безопасности, если не применяются утилиты, которые оперируют с POSIX. По
умолчанию принципал безопасности, создавший объект, записывает в дескриптор
безопасности свою основную группу. Основной группой Windows по умолчанию
является группа Domain Users.
Основная группа подразумевает
членство в группе. При входе пользователя операционная система вставляет SID
этой группы в маркер пользователя. Атрибут memberOf не перечисляет основную
группу, а лишь включает явно назначенное членство в группах.
Дискреционные и системные списки контроля доступа.
Списки контроля доступа ACL состоят
из двух частей. Первая часть списка контроля доступа представляет именованные
контрольные флаги. Эти параметры контролируют применение разрешений в списке
ACL и правил наследования. Вторая часть списка контроля доступа представляет
собственно сам список. Этот список контроля доступа содержит одну или несколько
записей управления доступом АСЕ. Флаги управления доступом определяют, каким
образом Windows применяет записи управления доступом внутри списка ACL.
Изначально Windows использует защищенные и автоматические флаги. Защищенные
флаги запрещают модификацию списка контроля доступа путем наследования. Этот
флаг является эквивалентом флажка Allow inheritable permissions from parent to
propagate to this object (Разрешение наследуемых разрешений доступа). Флаг
автоматически разрешает записям управления доступом в списках ACL наследовать
разрешения доступа от родительских объектов дочерним.
Записи управления доступом.
Списки управления доступом содержат
одну или несколько записей контроля доступа. В Windows записи управления
доступом разбиты на два типа: Allow (Разрешить) и Deny (Запретить). Каждый тип
АСЕ располагает объектом подтипа и необъектными подтипами. Записи управления
доступом Allow и Deny назначают уровень доступа, обеспечиваемый подсистемой
авторизации на основе права, запрашиваемого принципалом безопасности. Записи
управления доступом к объектам являются исключающими для объектов в AD DS,
поскольку они обеспечивают дополнительные поля для наследования объектов. Для
большинства остальных ресурсов, как, например, ресурсов файловой системы и
реестра, Windows использует необъектные записи управления доступом. Необъектные
записи АСЕ обеспечивают наследование контейнеров, то есть объект в контейнере
наследует запись контроля доступом контейнера. Этот принцип аналогичен
наследованию разрешений доступа файлами от родительских папок. Каждый тип
записи управления доступом располагает полем Rights и полем Trustee. Поля с
правами обычно заполняются предварительно определенными числами, представляющими
действия, которые может выполнять принципал безопасности. Рассмотрим пример с
пользователем, запрашивающим чтение или запись файла. В этом случае чтение и
запись являются двумя отдельными правами доступа. Поле доверия Trustee
представляет идентификатор безопасности, разрешающий или запрещающий указанное
право. В качестве примера можно привести пользователя или группу, которой
разрешено либо запрещено выполнять действие, указанное в поле Right.
Маркеры доступа.
Связующим звеном между SID-идентификатором
принципала безопасности и списком ACL является маркер доступа. Когда Windows
выполняет проверку подлинности пользователя с помощью Kerberos, пользователю в
процессе входа на локальном компьютере присваивается маркер доступа. Этот
маркер включает основной SID пользователя, SID-идентификаторы всех групп,
которым принадлежит пользователь, а также привилегии и права пользователя.
Примечание. Маркер
доступа также может включать в атрибуте SIDHistory дополнительные
SID-идентификаторы. Эти SID-идентификаторы могут заполняться при перемещении
учетных записей пользователей из одного домена в другой.Маркер доступа
используется подсистемой безопасности каждый раз при попытке пользователя
получить доступ к ресурсу. Когда пользователь пытается получить доступ к локальному
ресурсу, этот маркер предоставляется клиентской рабочей станцией всем потокам и
приложениям, которые запрашивают данные безопасности перед разрешением доступа
к ресурсу. Этот маркер доступа никогда не передается по сети на другие
компьютеры. Вместо этого на каждом сервере, где пользователь пытается получить
доступ к ресурсу, создается локальный маркер доступа. Например, когда
пользователь пытается получить доступ к почтовому ящику на сервере, то на этом
сервере создается маркер доступа. В данном случае подсистема безопасности на
сервере будет сравнивать SID-идентификаторы в маркере доступа с разрешениями,
предоставленными в ACL-списке почтового ящика. Если предоставленные для SID
разрешения позволяют доступ, пользователь сможет открыть почтовый ящик.
Проверка подлинности.
Для работы процессов подсистемы
безопасности, включая использование SID и ACL, нужно обеспечить способ
получения пользователями доступа к сети. По сути, пользователи должны иметь
возможность указывать свои данные для извлечения маркера доступа из контроллера
домена. Этот процесс называется проверкой подлинности.
Проверка подлинности выполняется в
исходном клиентском входе на компьютер, являющийся членом домена AD DS. Шаги
проверки подлинности зависят от операционной системы, с помощью которой клиент
входит в сеть. Например, нажимает клавиши Ctrl+Alt+Del (так называемая
комбинация безопасного входа в систему SAS (Secure Attention Sequence)), то
служба Winlogon на локальном компьютере включает окно входа в систему, а также
загружает DLL-библиотеку GINA (Graphic Identification and Authentication). По
умолчанию это файл Msgina.dll. Однако независимые производители могут создавать
альтернативные библиотеки GINA (например, клиент NetWare использовал файл
Nwgina.dll). После введения пользователем своих имени, пароля и выбора домена,
библиотека GINA передает введенные четные данные в процесс Winlogon. Служба
Winlogon передает эту информацию в локальную подсистему безопасности LSA (Local
Security Authority).
Системы Windows Vista и Windows
Server 2008 R2 не использовали DLL-библиотеку GINA. В Windows Vista и Windows Server 2008 R2 появилась новая
модель проверки подлинности, где LogonUI и Winlogon взаимодействуют
непосредственно друг с другом. Это означает, что учетные данные, которые
пользователи указывают в своих операционных системах, передаются компонентом
LogonUI непосредственно службе Winlogon, которая передает эту информацию
подсистеме LSA. Для проверки подлинности в других каталогах независимый
производитель может создать провайдер учетных данных (модуль, встраиваемый в
LogonUI), чтобы описать UI, извлекать учетные данные и передавать их службе
Winlogon. Провайдеры учетных данных работают абсолютно прозрачно для службы
Winlogon.
В любом
случае LSA немедленно применяет к паролю пользователя односторонний хэш и
удаляет открытый текстовый пароль, введенный пользователем. Затем LSA
обращается к соответствующему поставщику поддержки безопасности SSP (Security
Support Provider) через интерфейс SSPI (Security Support Provider Interface).
Например, система Windows Server 2008 R2 обеспечивает два основных SSP для
проверки подлинности сети — SSP-поставщика Kerberos и SSP-поставщика NT LAN
Manager (NTLM). Если клиенты Windows 2000 (и последующих версий) входят в сеть
Windows Server 2008 R2, то выбирается SSP-поставщик Kerberos и учетные данные
передаются этому поставщику. Затем SSP связывается с контроллером домена для
проверки подлинности пользователя.
В случае успешной проверки
подлинности пользователю предоставляется доступ в сеть. Если пользователь вошел
в домен и все необходимые ему ресурсы находятся в одном лесе, пользователю только
один раз будет предложено пройти проверку подлинности. Пока пользователь
остается в системе, все разрешения, получаемые им в сети, основаны на начальной
проверке подлинности. Хотя учетная запись пользователя проходит проверку
подлинности каждый раз при получении пользователем доступа к ресурсам на
сервере, где пользователь не проходил проверку подлинности, эта аутентификация
прозрачна для пользователя.