Залог успеха в этом деле — ясное представление об основных технических решениях и механизмах, применяемых в этой области. Предлагаем познакомиться с фундаментальными принципами оптимизации системы безопасности на примере информационных сетей под управлением Windows NT.
Упрощенная модель системы безопасности Windows NT
Рис. 1. Упрощенная схема работы системы безопасности Windows NT
|
Для начала рассмотрим в самом упрощенном виде организацию системы безопасности (рис.1). В основе защитной системы лежат две составляющие:
- SAM содержит имена учетных записей и пароли к ним, а каждая запись — специальный уникальный идентификатор SID (Security Identifier), используемый в качестве указателя на нее другими компонентами системы безопасности;
- списки управления доступом (ACL) формируются отдельно для каждого защищаемого ресурса и представляют собой таблицу, в которой содержатся указатели (SID) на учетные записи SAM и права доступа, определенные для этой записи. Подобная система безопасности работает следующим образом:
- при входе в систему (локальном или удаленном) пользователь проходит процедуру аутентификации, т. е. сообщает системе имя и пароль своей учетной записи;
- система безопасности проверяет в SAM наличие такой учетной записи и при успешном результате формирует для пользователя так называемый маркер доступа (Access Token), содержащий указатель (SID) на пользовательскую запись. Затем система безопасности «прикрепляет» этот маркер доступа ко всем процессам, которые пользователь инициирует и которыми управляет;
- при попытке пользовательского процесса получить доступ к защищенному объекту система безопасности сравнивает его SID со списком управления доступом к объекту. Если данному указателю соответствует запись в ACL, то пользователь (вернее, пользовательский процесс) получает доступ, в противном случае в доступе будет отказано.
Постановка задачи
Рассмотрим приемы и методы оптимизации работы системы безопасности на примере информационной сети, состоящей из 5 одиночных (stand-alone) серверов с операционной системой Windows NT Server и пользовательских компьютеров. При этом на каждом сервере открыто по 10 сетевых ресурсов (папки совместного доступа и принтеры).
Предположим, что в организации добавилось новое подразделение — отдел из 100 человек, сотрудники которого должны получить доступ к ресурсам на всех 5 серверах, причем одинаковый в пределах каждого разделяемого ресурса.
Попытаемся оценить: сколько и каких именно административных операций потребуется для внесения необходимых изменений в систему безопасности?
Прямое включение пользователей в списки доступа
Рис. 2. Прямое включение пользователей в списки доступа |
Если использовать самый простой способ формирования системы безопасности (рис. 2), то сначала следует добавить в базу учетных записей SAM каждого из 5 серверов по 100 учетных записей (всего 500 операций по созданию учетных записей пользователей). Затем нужно выполнить операции включения каждой учетной записи в каждый список управления доступом. Следовательно, в список управления доступом к каждому из 10 ресурсов каждого из 5 серверов должны быть включены по 100 учетных записей пользователей: 10x5x100 = 5000.
Cводный список административных действий будет таким:
Создание учетных записей
(на всех серверах) - 500
Включение учетных
записей в списки управления
доступом к объектам - 5000
Итого - 5500 операций
Как мы видим, основная тяжесть легла на формирование списков управления доступом. Поэтому в первую очередь мы займемся методами оптимизации ACL.
Использование локальных групп
Оптимизировать операции по созданию списков управления доступом можно, используя специальные разделяемые учетные записи, так называемые группы. Правила работы с группами выглядят следующим образом:
- пользовательские учетные записи объединяются в группы:
- каждой группе соответствует учетная запись в SAM, снабженная указателем SID;
- в списках доступа задаются права не только для пользовательских, но и для групповых учетных записей, причем права, назначенные для группы, автоматически распространяются на всех ее участников.
При подключении пользователя к сетевому ресурсу система безопасности сервера после успешной аутентификации формирует маркер доступа, включающий в себя в этом случае персональный указатель SID пользователя и указатели всех групповых записей, членом которых является данный пользователь.
При доступе уже к конкретному ресурсу пользовательский процесс предъявляет маркер доступа. Система безопасности сравнивает указатели маркера доступа со списками управления доступом и при совпадении разрешает соответствующий доступ.
Если таких совпадений оказывается несколько, то все найденные полномочия суммируются и образуют таким образом результирующий список разрешений для данного пользователя. Единственное исключение из этого правила связано со специальным разрешением «No Access» (безусловный отказ в доступе), которое отменяет действие всех остальных разрешений.
Рис. 3. Схема использования локальных групповых учетных записей |
Теперь рассмотрим этот механизм применительно к нашему примеру (рис 3). В соответствии с условиями задачи целесообразно воспользоваться механизмом объединения пользователей в группы, а в списки доступа ресурсов включить ссылки не на пользовательские, а на групповые учетные записи.
Для этого на каждом сервере выполним следующие действия:- создадим групповые учетные записи, например LocalEngineers;
- включим все пользовательские записи на этом сервере в созданную группу;
- включим группу в каждый из списков доступа на сервере.
Тогда для всех 5 серверов придется проделать:
Создание учетных
записей пользователей - 500
Создание учетных
записей групп - 5
Включение учетных
записей в локальные группы - 500
Включение локальных
групп в списки управления
доступом - 50
Итого - 1055 операций
- по сравнению с первым способом формирования системы безопасности мы получили почти пятикратный выигрыш по числу административных операций;
- благодаря применению технологии групп существенно сократились административные затраты на формирование списков управления доступом, однако произошло это за счет некоторого увеличения количества операций по созданию учетных записей.
Использование доменной модели
Перенесем наше внимание на рассмотрение механизмов оптимизации работы с учетными записями. В этом случае потребуется произвести некоторые изменения в конфигурации наших серверов. Во-первых, один из серверов должен теперь выполнять роль контроллера домена. Контроллер домена — это сервер, который «умеет» предоставлять свою базу учетных записей SAM для совместного доступа другим компьютерам, т. е. его учетные записи становятся таким же разделяемым ресурсом общего пользования, как сетевые принтеры и каталоги*. Каждый участник домена может «присоединить» к своей системе безопасности эту разделяемую SAM и использовать ее учетные записи так же, как свои собственные, в частности, включать их в списки управления доступом к ресурсам и в локальные группы.
Рис. 4. Схема использования разделяемых (глобальных) пользовательских учетных записей |
Таким образом, по крайней мере один из наших 5 серверов должен быть сконфигурирован в качестве контроллера домена. В базе данных SAM этого сервера создаются учетные записи для пользователей из нашей задачи.
Во-вторых, остальные 4 сервера должны выполнить специальную процедуру присоединения к домену, чтобы иметь возможность пользоваться его учетными записями. В результате каждая локальная система безопасности на серверах, являющихся членами домена, подключает к себе (присоединяет логически) учетные записи, созданные на контроллере домена. Таким образом учетные записи всех новых пользователей из нашей задачи автоматически окажутся подключенными к системам безопасности всех серверов. Соответственно отпадает необходимость создавать локальные учетные записи для пользователей на каждом сервере в отдельности.
Посмотрим, как в этом случае изменится список административных действий:
Создание учетных записей
пользователей на контроллере домена - 100
Присоединение сервера
к домену - 4
Создание локальных групп
(по одной на каждый сервер) - 5
Включение учетных записей
в локальные группы - 500
Включение локальных групп
в списки управления доступом - 50
Итого - 655 операций
Итак, мы опять получили выигрыш в выполнении административных операций. Отметим, кстати, что операции по формированию списков управления доступом и по созданию пользовательских учетных записей фактически уже сведены к возможному минимуму.
Применение глобальных групп
Остается последний тип операций, требующий дополнительной оптимизации, — действия по наполнению локальных групп (в нашем примере это 500 операций из 655).
Рис. 5. Схема использования глобальных групп |
Способ, который решает и эту проблему, связан с объединением пользовательских учетных записей контроллера домена в так называемые глобальные группы. С одной стороны, глобальные группы могут включать в себя глобальных пользователей того же домена, а с другой — являются таким же разделяемым ресурсом, как и сами пользователи. Наконец, глобальные группы могут включать и локальные группы на серверах, входящих в домен.
Применительно к нашей задаче это означает, что вместо того, чтобы на каждом сервере включать пользователей в соответствующие локальные группы, можно включить их в одну глобальную группу на самом контроллере домена (например, GlobalEngineers), а затем эту глобальную группу включить в локальные группы на каждом сервере.
Маркер доступа в этом случае содержит персональный SID пользователя, а также указатели всех групповых записей, которые прямо или опосредованно с ним связаны.
В итоге сводный перечень администраторских операций будет выглядеть так:Создание учетных записей
на контроллере домена - 100
Присоединение серверов
к домену - 4
Создание глобальных групп
на контроллере домена - 1
Включение глобальной
группы в локальные группы
на каждом сервере - 5
Включение локальных групп
в списки доступа к ресурсам - 50
Итого - 160 операций
Согласитесь, отличие полученного результата от самого первого из рассмотренных вариантов впечатляет — выигрыш получается более чем в 30 раз.
Разумеется, на практике эффект, скорее всего, будет более скромным, тем не менее при грамотном применении механизмов, рассмотренных в данной статье, положительный результат в любом случае будет ощутимым.
ОБ АВТОРЕ
Сергей Горский — преподаватель, Microsoft Certified Trainer. Контактный телефон: (095) 251-06-33, e-mail: sgorsky@hotmail.com
* Строго говоря, контроллер домена передает в общее пользование не всю SAM, а только часть ее. Учетные записи контроллера домена, которые поступают в совместный доступ, называются глобальными, оставшаяся часть — локальными. На серверах, не являющихся контроллерами домена, все записи по определению локальные.