Регистрация пользователя в системе

В процессе регистрации пользователя в системе (logon, login process) создается маркер доступа (access token), содержащий атрибуты безопасности, которые однозначно определяют данного пользователя, группы пользователей, к которым он принадлежит и соответственные права доступа. После этого любой процесс в этой сессии запускается от имени зарегистрированного пользователя, и содержит копию созданного при регистрации маркера доступа.

Когда процесс пытается использовать какой-либо объект, система проводит сравнение атрибутов безопасности, находящихся в идентификаторе безопасности маркера доступа с каждым элементом контроля доступа (ACE) в списке контроля доступа (ACL) самого объекта. Проверяется каждый элемент ACE до тех пор, пока не будет найдено элемента, гарантирующего требуемый доступ для данного маркера безопасности, или не будет найден элемент, запрещающий такой доступ или не будет достигнут конец списка ACL. Как правило, маркер может содержать несколько элементов ACE, — в этом случае права, гарантируемые каждой записью, суммируются. Например, если один элемент ACE в маркере гарантирует доступ по чтению группе, а другой доступ по записи пользователю-владельцу маркера, который также принадлежит к этой группе, то данный пользователь будет иметь доступ к объекту и по чтению, и по записи.

Любые именованные объекты в Windows NT (и некоторые, не имеющие имен) могут быть защищены. Дескриптор безопасности (security descriptor) описывает атрибуты безопасности каждого такого объекта и включает в свой состав четыре части:

- идентификатор безопасности (SID) владельца объекта, который определяет пользователя или группу, владеющую объектом. Владелец объекта может изменять уровень доступа (access level) к объекту;

- групповой идентификатор безопасности (SID), который используется только подсистемой POSIX и игнорируется другими подсистемами Windows NT;

- избирательный список контроля доступа (Discretionary Access-Control List, DACL), идентифицирующий пользователей и группы, которым предоставлен или запрещен определенный вид доступа. ACL контролируется владельцем объекта;

- системный список контроля доступа (SACL), контролирующий сообщения аудита, генерируемые системой. Системный ACL контролируется администратором системы безопасности.

Обычно приложение, защищающее объект, является сервером в том, что определяет пользователей и группы, которым дается право на доступ к этому объекту. Приложение взаимодействует с клиентами, когда они пытаются получить доступ к защищаемому объекту. Пользователи и группы пользователей описываются с помощью идентификаторов безопасности (security identifier — SID). Такой идентификатор всегда является уникальным и хранится в базе данных системы безопасности, причем приложения могут работать с данными этой базы, используя возможности, предоставляемые функциями Win32 API. Один и тот же идентификатор используется для описания пользователя или группы и никогда не передается в пользование другому пользователю или группе с одним исключением: для каждого пользователя идентификаторы входа, создаваемые во время его регистрации в системе, действуют только в течение рабочей сессии и уничтожаются при отключении пользователя от системы. В контексте данной модели безопасности, а также всего вышеописанного идентификаторы безопасности могут быть использованы для описания перечисленных ниже объектов:

- Владельца и группы в дескрипторе безопасности;

- Доверяемого для получения определенного доступа в элементах ACE;

- Пользователя и групп в маркере доступа.

9.3.4 Список контроля доступа (Access-Control List - ACL)

Список контроля доступа содержит информацию, которая контролирует доступ или осуществляет надзор за попытками получения доступа к объекту. ACL — это структура данных, которую пользователь может включить в состав дескриптора безопасности объекта (как известно, список контроля доступа может быть пустым).

Список ACL начинается с заголовка, представляемого структурой типа ACL:

typedef struct _ACL {
	BYTE	AclRevision;	= ACL_REVISION
	BYTE	Sbz1;	выравнивание на границу параграфа
	WORD	AclSize;	sizeof(ACL + AclCount * sizeof(ACE))
	WORD	AclCount;	количество ACE в ACL
	WORD	Sbz2;	выравнивание ACL на границу 32-бит. слова
} ACL;

Заголовок содержит информацию, имеющую отношение ко всему списку ACL, включая уровень ревизии структуры, размер структуры в байтах, количество элементов контроля доступа ACE в данном ACL. Для получения этой информации можно использовать функцию GetAclInformation(). Для изменения уровня ревизии можно использовать функцию SetAclInformation().

Далее, за заголовком (ACL) следует список элементов ACE. Каждый ACE определяет доверяемого (приложение, процесс, пользователя), а также подмножество прав доступа и подмножество флагов, которые определяют, предоставляются или запрещаются определенные права доступа или отслеживаются попытки получения таковых прав доверяемым. Доверяемым может быть пользовательский, групповой или входной бюджет (службы Windows NT).

Дескрипторы безопасности используют списки контроля доступа для того, чтобы позволять, запрещать или надзирать за попытками получения доступа к объекту, собственностью которого является данный дескриптор. Дескриптор безопасности может содержать два типа ACL — произвольные (Discretionary ACL, DACL) и системные (System ACL, SACL). Произвольные ACL контролируются владельцем объекта или любым другим пользователем (процессом), которому гарантируется доступ к этому объекту типа WRITE_DAC (изменение DACL), а системные ACL только системным администратором.

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

В списке SACL каждый ACE определяет тип попытки доступа для определенного доверяемого, которая (попытка) инициирует систему к генерации записи аудита в файле аудита системных событий. Системный администратор контролирует информацию в SACL объекта.

Приложение не может работать с ACL напрямую, для этого необходимо использовать функции Win32 API.

Структуры ACL и ACE выравниваются на границу двойного слова.

9.3.5 Элемент контроля доступа (Access-Control Entry - ACE)

Список контроля доступа (ACL) может содержать (или не содержать) один или несколько элементов контроля доступа (ACE), с помощью которых система безопасности контролирует или осуществляет мониторинг доступа к объекту, являющемуся владельцем данного списка.

Каждый ACE содержит следующую информацию:

- идентификатор безопасности (SID), определяющий доверенного, который может иметь какие-либо права на доступ к данному объекту. Доверенным может быть и учетная запись пользователя (user account), и учетная запись группы пользователей или входная учетная запись для приложения (например, служба Windows NT);

- маска доступа (access mask), которая определяет права доступа, контролируемые данным ACE;

- флаг, определяющий тип данного ACE;

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

Элементы ACE бывают следующих типов:

- элемент ACE запрета доступа (Access-Denied ACE) — используется в DACL для запрещения определенного доступа к доверяемому (trustee) объекту;

- элемент ACE разрешения доступа (Access-Allowed ACE) — используется в DACL для разрешения определенного доступа к доверяемому объекту;

- системный ACE (System-Audit ACE) — используется в SACL для обеспечения генерации системой сообщений аудита, когда какой-либо из доверенных пытается получить описываемый данным ACE доступ к объекту.

В списке DACL элементы ACE, запрещающие доступ, должны располагаться в начале списка ACL перед всеми ACE, разрешающими доступ. При определении, предоставить ли доступ к объекту, система проверяет маркер доступа (access token) по элементам ACE в ACL. Система прекращает проверку элементов ACE, когда происходит одно из следующих событий:

- один или несколько элементов ACE, разрешающих доступ, определенно предоставляют необходимые права доступа доверенному лицу группе, членом которой является это доверенное лицо;

- какой-либо запрещающий элемент ACE, определенно запрещает затребованный доверенным лицом тип доступа;

- все без исключения записи ACE проверены — совпадения затребованных и гарантируемых прав доступа не найдено. В этом случае система безоговорочно запрещает доверенному лицу запрошенный им доступ к объекту.

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

Если пользователь (или процесс) является членом нескольких групп, представленных элементами ACE в списке ACL, то все права, гарантированные каждой группе предоставляются доверяемому (пользователю или процессу). Например, доверяемый может запросить права на чтение/запись файла. Предположим, что один из ACE в списке ACL объекта гарантирует права чтения для группы, а другой ACE гарантирует права записи данному пользователю, тогда этот пользователь будет иметь право, как читать, так и записывать данные в этот файл.

Системный ACL обычно используется, когда администратор системы хочет производить мониторинг попыток получения какого-либо доступа к объектам. Элементы ACE системного аудита могут быть установлены, чтобы генерировать сообщения аудита, когда попытка доступа определенного типа была удовлетворена, отвергнута или и в том, и в другом случае. Система вставляет сообщения аудита системный файл аудита. Администратор может использовать специальное приложение (Event Viewer), чтобы проверять списки событий в этом файле. Другие приложения могут использовать функции Win32 API для доступа к файлу аудита.

Приложения не должны напрямую работать с элементами ACE и списками ACL. Для этого необходимо пользоваться соответствующими функции Win32 API.

⇐ Предыдущая78910111213141516Следующая ⇒

Поделиться:

Воспользуйтесь поиском по сайту: