В январе 2002 года Microsoft выступила с инициативой "Trustworthy Computing", направленной на обеспечение безопасности платформы Windows. Это событие напрямую повлияло на отсрочку даты выпуска следующей волны продуктов Microsoft (собранных под "зонтиком" .NET), но дополнительные месяцы усилий разработчиков привели к тому, что новые продукты стали гораздо безопаснее и стабильнее, чем любые из их предшественников.
Марсин Полич (Marcin Policht)
В январе 2002 года Microsoft выступила с инициативой "Trustworthy Computing", направленной на обеспечение безопасности платформы Windows. Это событие напрямую повлияло на отсрочку даты выпуска следующей волны продуктов Microsoft (собранных под "зонтиком" .NET), но дополнительные месяцы усилий разработчиков привели к тому, что новые продукты стали гораздо безопаснее и стабильнее, чем любые из их предшественников.
Эта статья является первой в серии, которая охватывает улучшения в области безопасности, введенные в ОС Windows 2003 Server.
Новые функции разработаны с тем, чтобы предложить возросший уровень безопасности, практически, в каждой сфере функциональных возможностей новой операционной системы. Мы начнем с той из них, что оказывает влияние на огромное число пользователей и администраторов Windows.
Разрешения NTFS и общие разрешения, определяемые по умолчанию
В предыдущих версиях Windows разрешения по умолчанию наделяли правом Full Control (Полный доступ) группу Everyone (Все) (для обеих систем разрешений), что делало файловую систему полностью незащищенной (в случае локального доступа к системе). Начиная с Windows XP Professional, этот подход претерпел изменение.
Разрешения NTFS на корневом диске, предоставляемые группе Everyone ограничены правом Read (Чтение) и Execute (Выполнение) и предоставляются только на корневом каталоге. Это означает, что группа Everyont не может наследовать эти разрешения на любом из подкаталогов, созданном в корневом каталоге. Группа Everyone также исключена из списка управления доступом (Access Control List) для обеспечения большей безопасности таких областей файловой системы, как Program Files или каталоги Windows. Пользователи, в дополнение к правам Read и Execute, могут создавать подкаталоги (способные наследовать права) и файлы в подкаталогах. (Обратите внимание, что это не распространяется на корневой диск). Уровень разрешений, предоставляемых учетной записи System и членам локальной административной группы, не изменяется - они, по-прежнему, сохраняют права Full Control по отношению к корневому каталогу и всем его подкаталогам и файлам. Группа Creator Owner наделена правом Full Control к подкаталогам и файлам в них, что позволяет пользователям в полной мере управлять создаваемыми ими подкаталогами.
Общие разрешения для вновь создаваемых общих ресурсов для группы Everyone теперь ограничены правом Read.
Кроме того, группа Everyone больше не включает в свой состав анонимный идентификатор безопасности (anonymous SID), дающий возможность неавторизованного доступа к файловой системе. Вы также можете быстро проверить, насколько хорошо работает ваша система безопасности на уровне NTFS, с помощью вкладки Effective Permissions окна Advanced Security Settings для выбранного файла или папки. Это позволяет устранить необходимость приблизительной оценки и сложного анализа наследования и прямого назначения прав NTFS. Однако, эта функция не принимает в расчет общие разрешения на пользование ресурсом.
Владение файлами и папками
Теперь вы можете не только завладеть выбранным объектом файловой системы (файлом или папкой), но также передать его любому пользователю, используя вкладку Owner диалогового окна Advanced Security Setting этого файла или папки. Эта функция упрощает работу с дисковыми квотами Windows, основанными на свойствах владения. Например, администратор создает новый файл от имени пользователя (например, через копирование файла или установку новой программы), что приводит к тому, что администратор становится владельцем этого файла. Следовательно, размер нового файла не будет засчитываться в лимит квоты этого пользователя. В прошлом, это решение требовало громоздкого обходного пути или использования инструментов сторонних производителей. Теперь, с помощью функциональной возможности назначения владельца, доступного через пользовательский интерфейс, эта проблема может быть решена очень просто (для любого типа операционной системы, использующей NTFS - включая Windows NT 4.0, 2000 и XP Professional - если это изменение осуществляется на Windows 2003 Server).
Обратите внимание на то, что подобные функциональные возможности (эффективные разрешения и назначение владельца) также доступны для объектов Active Directory, управляемых с серверов Windows 2003 (через вкладки Effective Permissions и Owner в диалоговом окне Advanced Security оснастки Active Directory Users and Computers).
Настройка служб Windows
Изменения в настройках служб Windows могут быть сгруппированы в две основные категории:
Службы, запускаемые при включении: Некоторые, наиболее уязвимые службы, такие как Clipbook, Network DDE (и Network DDE DSDM), Telnet и WebClient, являются отключенными по умолчанию. Другие активируются только по мере необходимости (например, Intersite Messaging в ходе повышения статуса контроллера домена; или Routing and Remote Access Service (служба ма
Службы, запускаемые в контексте учетной записи: Некоторые службы запускаются в контексте безопасности Local System, потому что эта учетная запись имеет неограниченные локальные привилегии. И, наоборот, во многих случаях учетная запись Local System заменяется на Local Service или Network Service. Обе они имею права, незначительно превышающие те, что даны аутентифицированным пользователям. Как следует из ее названия, учетная запись Local Service предназначена для локальных системных служб (и не имеет возможности аутентифицироваться в сети), в то время как Network Service назначается для служб, требующих сетевого доступа. (Она имитирует компьютерные учетные записи при аутентификации по сети).
Аутентификация
Усовершенствования механизмов аутентификации применяются для проведения аутентификации как в локальных системах, так и в доменах Active Directory.
Настройки аутентификации в локальной системе по умолчанию ограничивают использование локальных учетных записей с пустым паролем только для работы с консоли. Это означает, что подобные учетные записи (без назначения пароля) не могут использоваться для любого другого типа доступа, исходящего с удаленных систем (таких, как подключение дисков или соединения "удаленный рабочий стол/удаленная поддержка").
Изменения аутентификации в Active Directory являются более заметными, когда имеешь дело с доверительными отношениями между деревьями (cross-forest trust). Доверительные отношения между деревьями позволяют создавать основанные на Kerberos доверительные отношения между корневыми доменами лесов (что требует, чтобы оба леса находились на функциональном уровне Windows 2003, что, в свою очередь, подразумевает, что все контроллеры доменов работают под управлением ОС Windows 2003 Server и все домены являются доменами функционального уровня Windows 2003).
Подобные доверительные отношения являются транзитивными, что означает, что они распространяются на все домены более низкого уровня в каждом из этих лесов. Это позволяет любому пользователю из одного леса получить защищенный доступ к любому ресурсу, расположенному в другом лесе, включая вход в систему из другого леса (используя соглашение об именовании UPN). При настройках по умолчанию, аутентификация осуществляется в пределах всего леса, давая всем участникам безопасности из других лесов такие же возможности доступа к локальным ресурсам, что и у пользователей и компьютеров локального леса. Но, в любом случае, доступ пользователей к ресурсам зависят от разрешений, определенных на этих ресурсах.
Если вы не чувствуете себя на "короткой ноге" с подобным типом сценария, то можете настроить выборочную аутентификацию на основе доверительных отношений уровня леса, что требует функционального уровня леса Windows 2003. В этом случае, вы можете обозначить пользователей или группы учетных записей из другого леса, которым разрешено аутентифицироваться, а также выбирать ресурсы в вашем лесу, к которым эти учетные записи будут иметь доступ. Этот процесс состоит из двух основных этапов:
Первый этап включает в себя назначение участникам безопасности из другого леса разрешения "Allowed to Authenticate" (допускается к аутентификации) для объекта Active Directory, представляющего учетную запись компьютера, на котором содержится этот ресурс. Например, представьте себе, что существуют доверительные отношения между двумя лесами функционального уровня Windows 2003 - ForestA и ForestB - настроенных на выборочную аутентификацию. Пользователь UserA в домене DomainA леса ForestA должен получить доступ к общему ресурсу ShareB на ServerB в домене DomainB леса ForestB. Чтобы достичь этого, должна быть выполнена следующая последовательность шагов:
Администратор DomainA создает глобальную группу (например, GroupA) в DomainA и включаете пользователя UserA в качестве ее члена. Вы можете также назначить соответствующие разрешения непосредственно UserA (одним из преимуществ этого подхода является прозрачность), но работа с отдельными пользовательскими учетными записями становится неэффективной, если их слишком много.
Запускаете оснастку Active Directory Users and Computers с фокусом на DomainB. Выделяете ServerB и выполняете двойной щелчок мыши на его изображении, чтобы вызвать диалоговое окно свойств ServerB.
Щелкаете вкладку Security и добавляете DomainAGroupA к списку в верхней части этого диалогового окна. В нижней части активируете окно метки в столбце Allow для разрешений "Allowed to Authenticate" и "Read". На этом первый шаг завершен - теперь членам глобальной группы DomainAGroupA разрешено аутентифицироваться при доступе к DomainBServerB.
На втором этапе просто назначьте требуемый уровень прав для ресурса ShareB на ServerB для глобальной группы DomainAGroupA (в качестве альтернативы можно добавить глобальную группу DomainAGroupA в локальную группу домена DomainB и назначить разрешения для этой локальной группы). Это может быть сделано с помощью стандартных методов (с помощью графического интерфейса или инструментов командной строки, например, CACLS).
Межлесная (cross-forest) аутентификация может также осуществляться для регистрационных имен пользователей через Internet Authentication Service (хотя в этом случае требуются двунаправленные доверительные отношения между лесами).