Как известно, надежность цепи определяется самым слабым ее звеном. Если говорить о системе безопасности организации, здесь самым слабым звеном является элементарное незнание принципов защиты Windows NT. Даже если произошел переход на платформу Windows 2000, все равно — знание основ системы безопасности NT послужит неоценимым подспорьем для работы с Windows 2000.

Многие ошибочно полагают, что система безопасности NT является централизованной и что основной контроллер домена (PDC) целиком и полностью контролирует безопасность домена. Но, к сожалению, система безопасности NT — децентрализованная. Она представляет собой сложную комбинацию тесно связанных между собой «зон ответственности», таких, как политика учетных записей, права пользователей, политики аудита, списки контроля доступа, административные полномочия и системные службы. Причем все еще больше усложняется при работе в домене и при установлении доверительных отношений. Хотя политика безопасности на уровне домена влияет на каждую систему, входящую в состав домена, тем не менее рабочие станции NT и серверы, не являющиеся контроллерами домена (DC), функционируют как вполне самостоятельные единицы со своими настройками безопасности. И более того, можно говорить об управлении локальной безопасностью на нескольких уровнях (системном и объектном).

Чтобы сконфигурировать систему безопасности домена, нужно ясно понимать алгоритм взаимовлияния политики безопасности на уровне домена и локальной системы безопасности рабочей станции. Кроме того, необходимо знать, как работает система безопасности на каждом уровне.

Локальная безопасность на уровне системы

Каждая станция NT поддерживает локальную базу данных учетных записей (SAM) в реестре по адресу: HKEY_LOCAL_MACHINESAM. В локальной базе SAM хранятся локальные учетные записи пользователей, групп, права доступа и политика учетных записей. Учетные записи SAM данной станции также известны как локальные учетные записи компьютера (machine local accounts), поскольку они позволяют выполнять регистрацию и получать доступ к ресурсам только данной локальной системы. Аналогично, группы пользователей локальной SAM иногда называют локальными группами компьютера (machine local groups), они могут работать только в контексте локальной системы (в противовес этому, пользователи домена и группы домена работают на любой станции, принадлежащей домену).

Для просмотра и обслуживания локальных учетных записей и локальных групп необходимо зарегистрироваться в системе и открыть User Manager. С помощью этой программы осуществляется администрирование SAM, в том числе настройка политики учетных записей, прав пользователей и политики аудита.

Политика учетных записей (Account policy). В меню Policies следует выбрать пункт Account — откроется окно Account Policy (см. Экран 1). Использование учетных записей определяют настройки для пароля и блокировок. Можно потребовать от пользователей соблюдать ограничения на минимальную длину пароля, регулярно менять пароли и запретить повторное их использование. Настройки блокировок снижают риск перехвата паролей со стороны злоумышленников.

Экран 1. Установка политик для учетных записей.

Права пользователей (User rights). Выбираем Policies, User Rights в меню User Manager — открывается окно User Rights Policy. Права пользователя (иногда называемые привилегиями) — это особые полномочия, которые дают возможность выполнять определенные операции на системном уровне. Например, чтобы зарегистрироваться с локальной консоли, требуется право Logon locally. В окне User Rights Policy приводится список привилегий, доступных пользователю локальной станции.

Экран 2. Установка политики аудита.

Политика аудита (Audit policy). Нужно выбрать Policies, Audit — откроется окно Audit Policy (см. Экран 2). Эта политика устанавливает тип событий безопасности, регистрируемых системой в локальном журнале безопасности (Security log). NT поддерживает семь категорий аудита. Среди них аудит процесса регистрации пользователей, доступа к файловой системе, выполнения программ, изменения политики безопасности, изменения настроек учетных записей. Систему можно настроить на запись событий аудита об успешном или неудачном завершении проверки для каждой категории.

Для просмотра локального журнала безопасности требуется открыть программу Event Viewer и выбрать в меню Log пункт Security. Для настройки параметров журнала используется Log, Log Settings.

Здесь настраивается максимальный размер журнала и действия системы при достижении журналом указанного размера. Система может переписывать самые старые записи журнала; перезаписывать записи, устаревшие на указанное число дней (если журнал заполнен, то до истечения этого срока события не регистрируются, пока не будут выполнены условия устаревания записей). Можно запретить системе осуществлять перезапись журнала. В этом случае необходимо периодически самостоятельно его очищать, поскольку при заполнении журнала события перестают регистрироваться (простое увеличение размера журнала не приведет к возобновлению регистрации событий; сначала нужно освободить место в журнале).

Остальные субъекты локальной безопасности

Некоторые субъекты безопасности — ACL, списки управления аудитом, полномочия администратора, системные службы — работают независимо от SAM.

Списки контроля доступа (ACL). Для доступа к файлам и каталогам используются разрешения на объектном уровне. Каждый объект обладает списком разрешений, называемым ACL, который определяет, какие пользователи и группы имеют право обращаться к объекту и как именно. Не путайте разрешения (permissions) с правами (rights) — в NT это совсем не одно и то же. Назначение прав осуществляется через User Manager, как было сказано выше, тогда как разрешения настраиваются на объектном уровне через списки контроля доступа — ACL.

Экран 3. Просмотр списка ACL файла.

Чтобы просмотреть список ACL какого-либо файла, нужно открыть Windows Explorer и обратиться к контекстному меню файла. Выбрав Properties, следует открыть вкладку Security и щелкнуть Permissions. NT назначает пользователям кумулятивный доступ на основе его принадлежности той или иной группе. Например, на Экране 3 приведен список ACL для файла budget.doc. Члены группы SalesReps при работе с указанным файлом имеют разрешение Change (т. е. Read и Write). Однако пользователям группы RestrictedUsers в доступе к файлу отказано, поскольку для этой группы в ACL имеется указание No Access, которое перекрывает любое другое разрешение для групп.

Списки управления аудитом (Audit control lists). Каждый объект имеет список управления аудитом, описывающий тип событий, которые система регистрирует в журнале Security при обращении к объекту. Для каждого типа доступа (Read, Write, Delete) можно указать, следует ли регистрировать успешные и неуспешные события. Например, для регистрации случаев обращения пользователя к конфиденциальному документу, который пользователь не имеет право просматривать, достаточно включить для этого документа аудит с тем, чтобы NT фиксировала попытки неуспешного запроса на чтение (разрешение Read) членов группы Everyone. Для отслеживания изменений в документе включается аудит использования разрешения Write.

Для просмотра списка управления аудитом следует запустить Windows Explorer, открыть контекстное меню объекта и выбрать Properties. Затем нужно открыть вкладку Security и щелкнуть Auditing. Для просмотра списка управления аудитом, соответствующего разделу реестра, требуется запустить regedt32.exe, указать нужный раздел, а затем выбрать в меню Security, Permissions or Security, Auditing.

Административные полномочия (Administrative authority). Чтобы понять смысл административных полномочий, рассмотрим встроенные группы Administrators и Power Users. Члены группы Administrators могут помечать для совместного использования каталоги и принтеры, создавать и обслуживать локальные учетные записи SAM, назначать права пользователям и устанавливать политики аудита. В отличие от группы Administrators, члены Power Users не могут устанавливать политики аудита.

Системные службы (System services). Системные службы — это дверь в систему NT, поэтому необходимо понять назначение каждой из них и установить, должна ли быть запущена та или иная служба. Для просмотра локальных системных служб нужно открыть модуль Services в Control Panel. Чтобы просмотреть системные службы удаленного компьютера, следует запустить Server Manager, выбрать нужный компьютер, затем выбрать в меню Computer, Services (если на локальной станции отсутствует Server Manager, можно просто скопировать файл srvmgr.exe с контроллера домена).

Безопасность на уровне домена

Хотя системы NT могут независимо и достаточно безопасно функционировать и вне домена, полагаться только на систему безопасности хоста при наличии большого числа сетевых пользователей не следует. Когда станция не входит в состав домена, пользователи должны для регистрации в системе вводить локальные учетные записи SAM. Вне домена на каждой станции, к ресурсам которой обращается пользователь, приходится держать такую учетную запись. Наличие нескольких учетных записей для одного пользователя порождает множество проблем. Возникают трудности с синхронизацией паролей. Когда сотрудник покидает компанию, приходится на всех станциях удалять учетные записи, под которыми он работал в различных системах. Пропустив одну такую запись, в дальнейшем можно столкнуться с несанкционированным доступом (т. е. пользователь по-прежнему может зарегистрироваться в системе, хотя он уже не работает в компании). Чтобы этого не произошло, нужно организовать домен и для каждого пользователя создать одну учетную запись, которая будет действительна на всех серверах домена, к которым он обратится.

Когда станция или сервер становятся членами домена, не теряется ни одна из специфичных локальных настроек безопасности. Более того, система становится более защищенной в связи с участием в домене. Станция — член домена — «доверяет» выполнение процедуры аутентификации пользователей домена контроллерам домена. Значит, пользователь может регистрироваться в системе как с помощью локальной учетной записи, так и с помощью записи в домене. Для станции, которая является членом домена, в списках ACL для файлов и других объектов могут присутствовать пользователи и группы домена. NT автоматически добавляет группу Domain Admins в состав локальной группы Administrators (поэтому члены Domain Admins имеют административные полномочия на всех станциях — членах домена).

Базы данных SAM серверов и рабочих станций ограничены рамками локального компьютера, тогда как SAM контроллера домена не имеет этого ограничения. SAM основного контроллера домена (PDC) — это SAM всего домена, и программа User Manager for Domains, запущенная с любой станции домена, открывает SAM на PDC. Когда пользователь или группа создаются с помощью User Manager for Domains, изменения записываются в SAM на PDC. Через короткое время PDC реплицирует эти изменения SAM на резервные контроллеры — BDC. Следовательно, с учетом задержки на репликацию, все контроллеры домена совместно используют SAM и обладают одинаковым набором пользователей, групп и политик. Например, при активизации аудита через User Manager for Domains включается аудит для PDC. После репликации NT включает аудит для каждого сервера BDC.

Безопасность на уровне домена и локальная безопасность: за и против

Приобретая дополнительную функциональность, система безопасности NT-станции после вхождения в домен все же продолжает подчиняться локальным установкам. Изменения в программе User Manager for Domains не оказывают никакого влияния на политики локальных пользователей или их систему прав. Например, когда с помощью User Manager for Domains для какого-либо пользователя назначается право Logon locally, данный пользователь получает право локальной регистрации с консоли любого контроллера домена. Но если нужно, чтобы он мог регистрироваться локально на любой станции — члене домена, нужно на данной станции предоставить такое право с помощью программы User Manager.

Политика учетных записей и политика аудита, установленная для DC, никак не влияют на аналогичные локальные установки станций — членов домена. Например, предположим, что, зарегистрировавшись в домене, мы открыли User Manager for Domains и установили минимальную длину пароля. Это действие никак не отразится на локальной базе SAM сервера или рабочей станции, принадлежащей домену, поэтому при слабой локальной политике наша станция становится менее защищенной. Хакеры не особенно разборчивы: чем локальная учетная запись хуже доменной для взлома системы?

Поэтому лучше стараться не создавать большое количество локальных учетных записей. Вместо этого стоит создать для каждого пользователя одну доменную учетную запись, которой можно будет воспользоваться на любом компьютере домена. Если все же на станции уже создано много локальных учетных записей, лучше провести реконфигурацию SAM в удаленном режиме. Для этого следует просто скопировать на свой компьютер программу User Manager for Domains (usrmgr.exe) с любого сервера NT. Запустив программу, нужно выбрать User, Select Domain, но не вводить имя домена. Вместо этого следует ввести два обратных слеша и имя удаленной станции (т. е. при реконфигурации SAM компьютера Kramer надо ввести kramer). Чтобы убедиться, что открыта база SAM удаленной станции, а не домена, обратите внимание на заголовок окна, в котором должно присутствовать введенное имя и два обратных слеша.

Итак, система безопасности NT не является централизованной, как может показаться на первый взгляд. Каждый компьютер имеет дискретную конфигурацию из сотен настроек, которые требуют внимания со стороны администратора системы. Даже в домене централизованными можно признать только учетные записи пользователей и группы — при условии, что администратор старается не создавать локальные учетные записи на станциях — членах домена. Следовательно, знание основ настроек системы безопасности NT — краеугольный камень для построения безопасной сети в целом.

Рэнди Франклин Смит — редактор Windows 2000 Magazine и президент компании Monterey Technology Group. Он автор публикуемой два раза в месяц колонки Win2K Security для электронного издания Windows IT Security Channel в сети Windows 2000 Magazine Network. Связаться с ним можно по адресу: rsmith@montereytechgroup.com.