
Тестирование / tsure052
.pdf•SecurityIdentification - разрешает серверу запросить маркер доступа, связанный с клиентом, но не разрешает производить олицетворение. Т.о., сервер может узнать ид-
рбезопасности пользователя и групп, в которые тот входит, но не может действовать в Windows NT от его имени.
•SecurityImpersonation - сервер м. пользоваться практически всеми правами и привилегиями, которыми обладает клиент, но не может установить от имени пользователя новое сетевое соединение с другим компом и не может создать новый процесс, который м. работать от имени пользователя.
•SecurityDelegation - указывает, что сервер может обратиться от имени клиента к другому серверу.
ВWindows NT 4 есть функция LogonUser, позволяющая иначе решить вопросы олицетворения. Для ее использования необходимо иметь право SeTcbPrivilege (по умолчанию его нет даже у администратора). В момент вызова этой функции исходный процесс указывает имя и пароль пользователя и создает его первичный маркер доступа, который затем приписывает вновь создаваемому процессу. При этом созданный процесс имеет полноценный возможности работы по сети.
Доступ ко всем именованным и некоторым неименованным объектам Windows NT можно контролировать. Связанная с контролем доступа информация размещается в дескрипторе безопасности (security descriptor) объекта. Он обладает следующей структурой:
|
Таблица 13 |
|
Структура дескриптора безопасности |
|
|
Поле |
Назначение |
Revision level |
Показывает версию данного идентификатора безопасности. |
Owner |
Идентификатор безопасности владельца объекта (owner security ID). |
|
Владелец объекта всегда может поменять разрешения доступа к объекту. |
Group |
Идентификатор безопасности группы (group security ID), используемый |
|
только подсистемой POSIX; другими подсистемами игнорируется. |
Discretionary |
Дискреционный список контроля доступа. В этом списке перечислены |
ACL |
пользователи и группы, которым разрешен или запрещен доступ к |
|
объекту. Обычно список контроля доступа устанавливает владелец |
|
объекта. |
System ACL |
Системный список контроля доступа, определяющий, какие записи |
|
аудита будут генерироваться системой. Системные списки контроля |
|
доступа устанавливает администратор. |
Control |
Набор флагов: |
31

SE_OWNER_DEFAULTED — SID владельца объекта получен в результате действия механизма «по умолчанию»; SE_GROUP_DEFAULTED — SID основной группы получен по умолчанию;
SE_DACL_PRESENT — в дескрипторе присутствует DACL; SE_DACL_DEFAULTED — DACL получен по умолчанию; SE_SACL_PRESENT — в дескрипторе присутствует SACL; SE_SACL_DEFAULTED — SACL был получен по умолчанию; SE_SELF_RELATIVE — дескриптор является самодостаточным.
В зависимости от ситуации Windows NT создает абсолютный (absolute) или самодостаточный (self-relative) дескриптор безопасности. В первом случае в дб помещены только указатели на соответствующие идентификаторы безопасности, а во втором - сами значения идентификаторов безопасности.
Типы доступа, разрешения на которые могут быть даны пользователям, определяются типом объекта.
Еще одним свойством, влияющим на разрешения для объекта, является его способность включать в себя другие объекты. Если такое возможно, объект относится к типу контейнеров (container), напр., папка, если нет - то считается простым (noncontainer) Создаваемый объект наследует разрешения от родительского контейнера.
Возможность полностью ограничить доступ на локальной машине дает только
NTFS.
Дискреционный список контроля доступа (Discretionary Access Control List, DACL) перечисляет права пользователей и групп на доступ к объекту. Права каждой учетной записи содержатся в отдельной записи контроля доступа (Access Control Entry, ACE), а в начале списка хранится число таких записей и общий размер всего списка. DACL включает следующие поля данных:
|
Таблица 14 |
|
Структура дискреционного списка контроля доступа |
|
|
Поле |
Назначение |
AclRevision |
Показывает версию данного списка контроля доступа |
AclSize |
Размер всего списка контроля доступа в байтах |
AceCount |
Число записей контроля доступа, хранящихся в данном списке |
Массив ACE |
Массив записей контроля доступа, их количество равно AceCount |
Отметим важное различие между объектом, которому приписан пустой дискреционный список контроля доступа объекта, и объектом, такового не имеющим. В
32
первом случае к объекту вообще в явном виде нет доступа, во втором - объект не охраняется и доступ к нему может получить каждый.
Структура системного списка контроля доступа (System Access Control List, SACL) аналогично DACL, и их можно рассматривать как массивы записей контрольного доступа. Они различаются типами записей, которые они содержат, и, соответственно, их назначением.
Существует три типа записей контроля доступа: два - для DACL и один для SACL. В DACL могут содержаться записи "доступ разрешен" (AccessAllowed) и "доступ запрещен" (AccessDenied). Первая запись типа "доступ запрещен" отклоняет доступ к объекту для данного пользователя или группы, при этом последующие записи не обрабатываются. В SACL находятся записи типа "системный аудит" (SystemAudit), используемые для ведения журнала безопасности.
|
Таблица 15 |
|
Поля записи контроля доступа |
|
|
Поле |
Назначение |
АсеТуре |
Тип записи контроля доступа. Может принимать значения: |
|
ACCESS_ALLOWED_ACET_YPE — разрешение на доступ; |
|
ACCESS_DENIED_ACE_TYPE — запрещение доступа; |
|
SYSTEM_AUDIT_ACE_TYPE — системный аудит; |
|
SYSTEM_ALARM_ACE_TYPE — в настоящей версии Windows NT не |
|
поддерживается. |
AceFlags |
Набор флагов: |
|
CONTAINER_INHERIT_ACE — данная запись будут наследоваться |
|
создаваемыми объектами-контейнерами (например, при создании папки); |
|
INHERIT_ONLY_ACE — данная запись не применяется к самому |
|
контейнеру и будет использоваться только при наследовании; |
|
NO_PROPAGATE_INHERIT_АСЕ — флаги CONTAINER_INHERIT_ACE и |
|
INHERIT_ONLY_ACE не переходят к объекту в процессе наследования |
|
прав; |
|
OBJECT_INHERIT_ACE — данная запись будет наследоваться только |
|
простыми объектами (например, при создании файла); |
|
FAILED_ACCESS_ACE_FLAG — используется для записей типа |
|
SYSTEM_AUDIT_ACE_TYPE для обозначения аудита неудач; |
|
SUCCESSFUL_ACCESS_ACE_FLAG — используется для записей типа |
|
SYSTEM_AUDIT_ACE_TYPE для обозначения аудита успеха. |
AceSize |
Размер всей записи контроля доступа в байтах. |
Mask |
Маска доступа. |
SID |
Идентификатор безопасности учетной записи, к которой должна быть |
|
применена маска доступа. |
33
При попытке процесса пользователя получить доступ к объекту Монитор безопасности Windows NT сравнивает информацию безопасности в маркере доступа пользователя с информацией в дескрипторе безопасности объекта. Основываясь на типе доступа к объекту, Windows NT создает маску запроса на доступ. Она последовательно сравнивается с масками доступа, находящимися в дискреционном списке контроля доступа к объекту. Каждая запись ACE в списке контроля доступа обрабатывается следующим образом:
1.SID пользователя или группы из ACE сравнивается со всеми SID, находящимися в маркере доступа пользователя. Если совпадений не обнаружено, данная запись ACE пропускается. В случае совпадения SID дальнейшая обработка зависит от типа ACE. Записи AccessDenied всегда должны быть расположены (и, следовательно, обрабатываться) раньше, чем записи AccessAllowed
2.Для записи AccessDenied типы доступа из АСЕ сравниваются с перечисленными в маске запроса на доступ. Если какой-либо тип доступа есть в обеих масках, дальнейшая обработка списка не производится, и доступ запрещается. В противном случае обрабатывается следующая запись АСЕ.
3.Для записи AccessAllowed типы доступа из АСЕ сравниваются с перечисленными в маске запроса на доступ. Если все запрашиваемые типы разрешены, последующая обработка не требуется, и процесс пользователя получает доступ к объекту. В противном случае разрешения на недостающие типы доступа ищутся в следующих записях АСЕ.
4.Если не все типы доступа требуемой маски разрешены и весь список контроля доступа просмотрен, доступ к объекту запрещается.
5.Если доступ запрещен, система проверяет случай, когда требуемая маска запроса на доступ содержит только типы доступа READ_CONTROL и/или WRITE_DAC. Если это имеет место, система проверяет, не является ли пользователь владельцем объекта. В этом случае доступ разрешается.
1.2.6. АУДИТ
Аудит — одно из средств защиты сети Windows NT. С его помощью можно отслеживать действия пользователей и ряд системных событий в сети. Фиксируются следующие параметры, касающиеся действий, совершаемых пользователями:
34
выполненное действие; имя пользователя, выполнившего действие; дата и время выполнения.
Аудит, реализованный на одном контроллере домена, распространяется на все контроллеры домена. Настройка аудита позволяет выбрать типы событий, подлежащих регистрации, и определить, какие именно параметры будут регистрироваться. Аудит приводит к дополнительной нагрузке на систему, поэтому регистрируйте лишь события, действительно представляющие интерес.
Windows NT записывает события в три журнала:
•Системный журнал (system log) содержит сообщения об ошибках, предупреждения и другую информацию, исходящую от операционной системы и компонентов сторонних производителей. Список событий, регистрируемых в этом журнале, предопределен операционной системой и компонентами сторонних производителей и не может быть изменен пользователем. Журнал находится в файле Sysevent.evt.
•Журнал безопасности (Security Log) содержит информацию об успешных и неудачных попытках выполнения действий, регистрируемых средствами аудита. События, регистрируемые в этом журнале, определяются заданной вами стратегией аудита. Журнал находится в файле Secevent.evt.
•Журнал приложений (Application Log) содержит сообщения об ошибках, предупреждения и другую информацию, выдаваемую различными приложениями. Список событий, регистрируемых в этом журнале, определяется разработчиками
приложений. Журнал находится в файле Appevent.evt.
Все журналы размещены в папке %Systemroot%\System32\Config.
При выборе событий для проведения аудита следует учитывать возможность переполнения журнала. Для настройки журнала используется диалоговое окно Event Log Settings. С помощью этого окна можно управлять:
•размером архивируемых журналов (размер по умолчанию – 512 Кбайт, можно изменить размер от 64 до 4 194 240 Кбайт.);
•методикой замещения устаревших записей журнала;
•Overwrite Events as Need – в случае заполнения журнала при записи новых событий операционная система удаляет самые старые события;
35

•Overwrite Events Older then X Days – в случае заполнения журнала при записи новых событий удаляются самые события, но только если они старше Х дней, иначе новые события будут проигнорированы;
•Do not Overwrite Events – в случае заполнения журнала новые события
не фиксируются. Очистка журнала производится вручную.
Для просмотра информации об ошибках и предупреждениях, а также об успешных и неудачных запусках задач используется программа Event Viewer.
По умолчанию аудит выключен, и журнал безопасности не ведется.
1.2.7. ОСОБЕННОСТИ ОРГАНИЗАЦИИ МНОГОДОМЕННЫХ СТРУКТУР В WINDOWS NT
Базы данных доменов Windows NT не поддерживают иерархической структуры и не могут быть распределены между несколькими серверами Windows NT. Эти обстоятельства существенно ограничивают максимальное количество объектов в домене. Однодоменная структура в Windows NT может реализована, если число пользователей измеряется десятками, максимум - одной-двумя сотнями. Для управления сетями Windows NT больших масштабов фирма Microsoft предлагает использовать многодоменную структуру и доверительные отношения между доменами.
Доверительные отношения между доменами обеспечивают междоменное администрирование, позволяя предоставлять пользователям из одного домена получать доступ к ресурсам другого домена.
ДОВЕРИТЕЛЬНЫЕ ОТНОШЕНИЯ
|
|
|
|
|
Домен А |
Домен В доверяет домену А |
Домен В |
||
|
|
|
|
|
Пользователи из домена А могут получить доступ к ресурсам домена В
Рис. 2 Односторонние доверительные отношения между доменами.
На Рис. 2 домен В доверяет домену А, и пользователям и глобальным группам в домене А могут быть предоставлены права на ресурсы домена В. Т.к. домен А не доверяет домену В, пользователи из домена В не получат доступа к ресурсам домена А. Это одностороннее отношение доверия. Можно установить двусторонние отношения
36

доверия между доменами, где пользователи и глобальные группы в домене А получают доступ к ресурсам домена В и наоборот.:
|
Домен А доверяет домену В |
|
||
|
|
|
|
|
Домен А |
Домен В доверяет домену А |
Домен В |
||
|
|
|
|
|
Пользователи из обоих доменов могут получить доступ к их ресурсам
Рис. 3 Двусторонние доверительные отношения между доменами.
Доверительные отношения не транзитивны: из того, что домен А доверяет домену В, а домен В доверяет домену С, не следует, что А доверяет С. Следовательно, администрирование в многодоменной структуре связано с ручной установкой большого числа доверительных отношений между доменами, что крайне неудобно. Кроме того, доменной архитектуре присущ целый ряд серьезных недостатков, а именно:
1.Невозможность учета потребностей, возникающих при разработке крупномасштабных систем, поскольку домен представляет собой одномерную базу данных и не поддерживает иерархии объектов.
2.Отсутствие механизмов для подключения к базе данных параметров, управляющих новыми сервисами. Номенклатура объектов NTDS и набор их свойств не могут быть изменены. Для управления новыми сервисами организуются новые базы данных
3.Негибкость управляющей схемы. Невозможно дать одному пользователю права по управлению только данным конкретным объектом. Пользователь может быть включен в некоторую административную группу, которая осуществляет управление всеми объектами домена единообразно.
4.Сложность системы доверительных отношений, требующейся для организации управления многодоменной структурой.
5.Зависимость работы домена Windows NT от сервера, являющегося первичным контроллером домена. Все изменения в NTDS осуществляются на этом сервере. Далее первичный контроллер домена реплицирует эту информацию на один или несколько резервных контроллеров домена. Выход из строя данного сервера делает домен неуправляемым. Превращение резервного контроллера домена в первичный требует вмешательства администратора.
37
6.Невозможность добавления или уничтожения базы данных домена на сервере Windows NT без переинсталляции операционной системы с последующим воссозданием системы допусков пользователей к объектам файловой системы. Каждый сервер Windows NT может содержать базу данных только одного домена.
7.Отсутствие механизма перемещения объектов между доменами. Объект должен быть
уничтожен и создан заново. Абсолютно невозможно слияние двух доменов в один. Таким образом, операционная система Windows NT имеет ряд серьезных недостатков, к которым относятся структура NTDS и несертифицированные сетевые протоколы. Преодолеть эти недостатки можно за счет использования средств интеграции IntranetWare и Windows NT. Кроме того, заметный шаг вперед сделан в
Windows 2000, где появились службы Активных каталогов (Active Directory).
1.2.8.ИСПОЛЬЗОВАНИЕ СРЕДСТВ ИНТЕГРАЦИИ INTRANETWARE И WINDOWS NT
Уфирмы Novell имеется продукт под названием NDS for Windows NT (При использовании NDS для NT на рабочие станции и сервера Windows NT должен быть установлен IntranetWare клиент для Windows NT). Использование этого продукта позволяет управлять безопасностью гетерогенной сети, состоящей из серверов и рабочих станций Windows NT и серверов IntranetWare через NDS. Для этого на сервере, являющимся первичным контроллером домена Windows NT, подменяется единственный программный модуль SAMSRV.DLU, который имеет следующее назначение. Приложения, которым необходим доступ к базе данных домена, вызывают программный модуль SAMUB.DLL, который в свою очередь, через модуль удаленного запуска программ RPC (REMOTE PROGRAM CONTROL), вызывает модуль SAMSRV.DLL,
расположенный на сервере, являющимся первичным контроллером домена. Этот модуль через интерфейс SAM осуществляет обращение к базе данных домена. При подмене
SAMSRV.DLL разработки фирмы Microsoft на SAMSRV.DLL фирмы Novell запрос перенаправляется не в базу данных домена, а в NDS. При выключении сервера, являющегося первичным контроллером домена, NDS через Novell клиент для Windows NT (NT Client) осуществляет проверку наличия на первичном контроллере домена модуля SAMSRV.DLL фирмы Novell, и в случае его отсутствия, осуществляет копировние этого модуля на первичный контроллер домена. Таким образом NDS для NT сохраняет свою конфигурацию после установки очередного Service Pack для Windows
38
NT. В результате домен Windows NT со всеми своими группами становится объектом NDS, а все пользователи домена автоматически становятся пользователями NDS.
Всем пользователям NDS можно назначить некоторые полномочия в домене Windows NT, определив их принадлежность к глобальным группам. В принципе, за счет расширения схемы NDS, можно назначать этим пользователям доступ к любым ресурсам Windows NT, а не только тем, доступ к которым осуществляется через базу данных домена (например, можно управлять правами доступа к ресурсам системы MS Exchange)
Применение NDS for NT позволяет:
•осуществлять единое централизованное управление гетерогенной сетью, состоящей из IntranetWare и рабочих станций и серверов Windows NT;
•формировать иерархическую структуру доменов Windows NT;
•использовать другие преимущества NDS.
Использование NDS for NT требует замены на серверах и рабочих станциях Windows NT клиентской части для серверов NetWare разработки фирмы Microsoft (Gateway service for NetWare на серверах, и клиент для сетей NetWare на рабочих станциях) на Novell Client for Windows NT. Этот клиент выполняет следующие функции:
•наиболее полно поддерживает возможности NDS;
•поддерживает автоматическое распределение программного обеспечения через
Novell Application Launcher;
•включает утилиту Workstation Manager, которая позволяет осуществлять управление локальной системой безопасности рабочих станций Windows NT через NDS. На рабочей станции пользователя указывается, какое из деревьев IntranetWare осуществляет управление конфигурацией данной рабочей станции.
Параметры управления конфигурацией рабочей станции содержатся в объекте NDS NT Configuration, который может быть поставлен в соответствие пользователю, группе или контейнеру в NDS. Он определяет следующее:
•схему, согласно которой пользователю NDS ставится в соответствие пользователь Windows NT; возможны 3 варианта выполнения этой схемы:
-пользователям NDS ставится в соответствие один уже существующий на локальной станции пользователь Windows NT;
-создается новый пользователь рабочей станции Windows NT, имя которого
39
совпадает с именем пользователя NDS;
-пользователь Windows NT создается временно, только на сеанс работы пользователя NDS на рабочей станции Windows NT.
•локальные группы, в которые войдет данный пользователь;
•местоположение файлов, определяющих политики и профили пользователя на рабочей станции Windows NT;
•порядок перехода на новую версию Novell Client для Windows NT;
•параметры, определяющие внешний вид заставки вызова клиента Windows NT.
Таким образом, достигается возможность централизованного управления рабочими станциями Windows NT через NDS.
1.2.9. ИЗМЕНЕНИЯ В СИСТЕМЕ БЕЗОПАСНОСТИ WINDOWS 2000 ПО СРАВНЕНИЮ С
WINDOWS NT SERVER 4.0
Windows 2000 отличается от NT версии 4 гораздо сильнее, чем NT 4.0 от NT 3.51.
1.2.9.1.Файловая система NTFS5 и её отличия от NTFS4
Самое главное, за что ругали NT4, и в чём она уступала NetWare, это за отсутствие квотирования - ограничения максимального объёма дискового пространства для пользователя, которое он сможет использовать. Устанавливаются квоты через Properties NTFS раздела, закладка Quota. Через Quota Entries... можно выставлять квоты для каждого отдельного пользователя.
Второе, достаточно важное отличие NTFS5 от старой версии возможность поиска файла по имени его владельца. С помощью Access Control List можно легко проверить, какие файлы доступны пользователю, и установить права доступа к отдельным файлам или каталогам.
Кроме непосредственного изменения самой структуры NTFS, в W2k добавлен Microsoft Index Server, который значительно ускоряет поиск файлов, особенно по их содержимому, за счёт индексации содержимого дисков. Управляется эта служба через раздел Indexing Service окна Computer Management. В этом разделе можно просмотреть, какие директории индексируются, и, при желании, добавить новые или удалить старые. Работает это c любыми разделами, а не только с NTFS.
В NTFS5 добавлена такая функция как точки монтирования или, по-другому, точки соединения (junction point). Функция эта давно знакома пользователям различных
40