 TechNet Magazine June 2007

TechNet Magazine June 2007

Безопасность : Управление учетными записями пользователей Windows Vista: взгляд изнутри

Управление учетными записями пользователей, или UAC, является одной из самых недооцениваемых новых возможностей Windows Vista. Но ее миссия — обеспечить возможность работать с правами обычного пользователя — может помочь решить много проблем безопасности. Давайте поближе присмотримся к проблемам, для устранения которых предназначена функция UAC, и разберемся, как она работает.

Mark Russinovich Безопасность: Защита данных с помощью шифрования диска BitLocker

Компонент BitLocker служит двум очень важным целям: обеспечению полного шифрования данных тома и проверке целостности запускаемых первыми компонентов еще до старта Windows Vista. Получите представление о работе BitLocker и о том, как он может помочь в защите вашей организации.

Byron Hynes Безопасность: Изучая брандмауэр Windows

Рост мобильности привел к изменению характера компьютерных угроз и методик защиты от них. Так как переносные компьютеры перемещаются за пределы сети и потом возвращаются обратно, появилась необходимость в улучшенных способах защиты системы. Узнайте, как лучше использовать брандмауэр Windows для защиты компьютера — при работе в Интернете и в вашей собственной внутренней сети.

Steve Riley Безопасность: Повышение безопасности в ОС Windows Vista с помощью новых списков управления доступом (ACL)

Несмотря на то, что списки ACL не претерпели кардинальных изменений, есть ряд важных нововведений, о которых нужно иметь представление при работе со списками управления доступом в среде Windows Vista. Из этой статьи вы узнаете о том, какие изменения были внесены в 30 списков ACL для повышения безопасности, как эти изменения повлияют на работу вашей организации и о том, как правильно использовать эти измененные списки в ИТ-инфраструктуре вашей организации.

Jesper Johansson Безопасность: Ограничение использования оборудования через групповые политики

USB-накопители флэш-памяти и подобные им съемные устройства могут сильно облегчить повседневную жизнь и сильно затруднить профессиональную. В целях безопасности следует подумать о том, какие виды оборудования пользователям разрешено устанавливать на рабочих компьютерах. Теперь для решения этой задачи можно использовать групповые политики.

Jeremy Moskowitz Безопасность: 4 технологии безопасности, которыми должна владеть каждая ИТ-организация

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

Matt Clapham and Todd Thompson Безопасность: Новое мощное средство управления сертификатами

Сертификаты — ключевой компонент инфраструктуры. Один истекший сертификат может парализовать весь рабочий процесс. В среду Microsoft PKI включено новое решение — Identity Lifecycle Manager Certificate Management (диспетчер жизненного цикла удостоверения, управление сертификатами, ILM-CM), которое не допустит этого. Рассмотрим, как оно поможет улучшить процессы проверки подлинности и снизить затраты на управление сертификатами.

Kevin Dallmann От редактора: Вопросы безопасности

Joshua Trupin Инструментарий: Новые программные продукты для ИТ-специалистов

Greg Steen Вопросы и ответы по SQL: 64-разрядные установочные пакеты, выделение памяти кластера и другое

Edited by Nancy Michell Обзор служебных программ: Средства PowerToy для запуска сценариев с повышенными правами в Windows Vista

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

Michael Murgolo Кабельщик: Протокол SSTP

Протоколы VPN в Windows XP и Windows Server 2003 не работают в некоторых конфигурациях. Получите представление о возможных проблемах и о том, как Windows Server «Longhorn» и Windows Vista с пакетом обновления 1 (SP1) решают их при помощи протокола SSTP.

Joseph Davies Windows PowerShell: Работа со службой Active Directory

Среда Windows PowerShell не предоставляет командлет Get-ADSIObject, но это не мешает ей обеспечивать хорошую поддержку интерфейсов ADSI. Познакомьтесь с адаптерами типов и узнайте, как пользоваться средой Windows PowerShell при работе с объектами службы каталогов.

Don Jones Эй, скриптоман!: Вокруг волнистой красной линии

Ищете более простой способ добавления терминов в словарь приложения Microsoft Word, чем внесение по одному слову вручную? Вы не одиноки! В этом месяце скриптоманы продемонстрируют, как создавать в приложении Microsoft Word пользовательские словари и как программно настраивать Word для их использования.

The Microsoft Scripting Guys Материалы о рабочей среде: Как не потерять данные

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

Wes Miller Полевые заметки: Разговаривайте с разработчиками

Заставить разработчиков создавать более управляемые приложения проще, чем кажется. Все дело в общении. Разработчики смотрят на программное обеспечение не с той же точки, что администраторы. Разговаривая с разработчиками, администраторы могут объяснить, что им важно получить, а разработчики уже воплотят это в коде.

David Aiken О Windows из первых рук: Что новые пользователи видят в меню “Пуск”

Представьте себе картину: вы покупаете новый компьютер, запускаете Windows, нажимаете кнопку “Пуск” и обнаруживаете пустое меню. Вот поэтому разработчики Windows и включили в меню “Пуск” наиболее часто используемые приложения, обеспечивая пользователю, еще не запускавшему компьютер, хорошее впечатление от первого запуска. Давайте выясним, как выбираются эти приложения.

Raymond Chen Письма в редакцию: Ответы на ваши вопросы


 Безопасность : Управление учетными записями пользователей Windows Vista: взгляд изнутри
Безопасность Марк Руссинович

Управление учетными записями пользователей Windows Vista: взгляд изнутри
Краткий обзор:
  • Работа с правами обычного пользователя
  • Виртуализация файлов и реестра
  • Состояние повышения прав учетной записи

Управление учетными записями пользователей (UAC) — функция Windows Vista, которую часто недооценивают. В моей серии из трех статей в журнале TechNet Magazine, посвященной нововведениям в ядре Windows Vista, которую можно прочесть на веб-узле technetmagazine.com, я не касался UAC, поскольку чувствовал, что эта тема достойна отдельной статьи.
В этой статье мы затронем проблемы, которые решает UAC, а также архитектуру и реализацию ее ключевых технологий. Эти технологии включают пересмотр операций, которые ранее требовали административных прав; облегченную виртуализацию, которая помогает программам правильно работать без административных привилегий; возможность явного запроса программами административных прав и изоляцию административных процессов от неадминистративных, работающих в той же пользовательской системе.

Назначение UAC
Функция UAC призвана обеспечить пользователям возможность работать с правами обычного пользователя, не прибегая к административным. Обладая административными правами, пользователь может просматривать и изменять любую часть операционной системы, включая код и данные других пользователей и даже самой Windows®. Без административных прав пользователи не могут случайно (или преднамеренно) изменить системные параметры, вредоносная программа не может изменить параметры системной безопасности или отключить антивирусное программное обеспечение, а пользователи не могут нарушить безопасность важных данных других пользователей на общедоступных компьютерах. Работа с правами обычного пользователя, таким образом, помогает уменьшить количество срочных вызовов службы поддержки в корпоративных средах, смягчить ущерб от вредоносной программы, способствует более четкой работе домашних компьютеров и защищает уязвимые данные на общедоступных.
С помощью UAC предполагалось решить несколько проблем с тем, чтобы работа под учетной записью обычного пользователя стала общепринятой практикой. Во-первых, до Windows Vista™ общепринятой моделью использования Windows была работа с привилегиями администратора. Разработчики программного обеспечения почему-то считали, что их программы должны иметь получать доступ и изменять любой файл, параметр реестра или настройку операционной системы. Даже когда в Windows NT® были введены функции безопасности и разные уровни доступа для административных учетных записей и обычных пользователей, в процессах настройки продолжала широко использоваться встроенная учетная запись “Администратор” или учетная запись, входящая в группу “Администраторы”.
Второй проблемой, которую должна была решить функция UAC, было то, что пользователи иногда нуждаются в административных правах для выполнения таких операций, как установка программного обеспечения, изменение системного времени и открытие портов в брандмауэре.
Решение этих проблем с помощью UAC состоит в том, чтобы большинство приложений запускать с правами обычного пользователя, исключить потребность в частом использовании прав администратора и поощрять разработчиков программного обеспечения создавать приложения, работающие с правами обычного пользователя. UAC достигает этого, реже требуя административных прав, обеспечивая работу более ранних версий приложений с правами обычного пользователя, позволяя обычным пользователями легко получать административные права (когда они в них действительно нуждаются), а администраторам — работать так, как если бы они были обычными пользователями.

Работа с правами обычного пользователя
В ходе полной проверки всех административных операций во время разработки Windows Vista было установлено, что многие из них могли бы выполняться обычными пользователями без ущерба для безопасности системы. К примеру, даже корпорации, в которых на настольных системах Windows XP принято использовать учетные записи обычных пользователей, не могли удалить своих мобильных пользователей из группы “Администраторы” по той простой причине, что Windows XP не делает отличий между изменением часового пояса и изменением системного времени. Пользователь переносного компьютера, который хочет настроить локальный часовой пояс так, чтобы в поездках его встречи правильно отображались в календаре, должен иметь привилегию “Изменение системного времени” (внутреннее имя SeSystemTimePrivilege), которая по умолчанию предоставляется только администраторам.
Время обычно используется в протоколах безопасности, таких как Kerberos, но часовой пояс влияет только на способ отображения времени. Поэтому в Windows Vista добавлена новая привилегия, “Изменение часового пояса” (SeTimeZonePrivilege), которая назначена группе “Пользователи” (см. рис. 1). Это позволяет корпоративным пользователям переносных компьютеров работать с учетными записями обычных пользователей.
Рис. 1 Привилегия “Изменение часового пояса”
Рис. 1 Привилегия “Изменение часового пояса”
Windows Vista также позволяет обычным пользователям настраивать параметры WEP-шифрования при подключении к беспроводным сетям, создавать подключения к виртуальной частной сети, изменять параметры управления электропитанием и устанавливать критические обновления Windows. Кроме того, в Windows Vista введены параметры групповой политики, с помощью которых обычные пользователи могут устанавливать драйверы принтера и других устройств, одобренные ИТ-администраторами, и устанавливать элементы управления ActiveX® с одобренных администраторами веб-узлов.
А что же потребительские и бизнес-приложения, которые неправильно работали с учетными записями обычного пользователя? Хотя для работы некоторых программ действительно требуются административные права, многие из них совершенно необоснованно хранят пользовательские данные в областях, общих для всей системы. Корпорация Майкрософт рекомендует, чтобы установщики глобальных приложений, которые должны работать с административными правами, для хранения исполняемых файлов и вспомогательных данных приложений создавали подкаталоги в каталоге %ProgramFiles%, а для параметров приложений — подраздел в разделе реестра HKEY_LOCAL_MACHINE\Software. Приложение может работать с разными учетными записями пользователей и поэтому должно хранить данные пользователей в соответствующих им каталогах %AppData%, а параметры, относящиеся к данному пользователю — в профиле пользователя в разделе реестра HKEY_CURRENT_USER\Software. Учетные записи обычного пользователя не имеют доступа для записи к каталогу %ProgramFiles% и разделу HKEY_LOCAL_MACHINE\Software. Однако, поскольку большинство систем Windows является однопользовательскими, а большинство пользователей вплоть до Windows Vista были администраторами, то приложения, даже если неправильно сохраняли пользовательские данные и параметры в этих местах, в любом случае работали.
В Windows Vista эти старые приложения могут работать с учетными записями обычного пользователя за счет применения виртуализации файловой системы и пространства имен реестра. Когда приложение изменяет данные в частях файловой системы или реестра, общих для всей системы, и эта операция проходит неудачно из-за отказа в доступе, Windows перенаправляет операцию в область соответствующего пользователя. Когда приложение считывает данные из системно-глобального размещения, Windows сначала проверяет данные в области пользователя и, если их там не находит, разрешает чтение из глобального размещения.
Для целей этой виртуализации Windows Vista обрабатывает процесс как устаревший, если он 32-разрядный (а не 64-разрядный), выполняется не с административными правами и не имеет файла манифеста, указывающего, что он написан для Windows Vista. Любые операции, происходящие из процесса, не подпадающего под это определение, включая доступ к сетевому общему файловому ресурсу, не виртуализуются. Состояние виртуализации процесса хранится в виде флага в его маркере, представляющем собой структуру данных ядра, которая отслеживает контекст безопасности процесса, включая его учетную запись пользователя, членство в группах и привилегии.
Чтобы увидеть состояние виртуализации процесса, можно добавить столбец “Виртуализация” к странице “Процессы” диспетчера задач. На рис. 2 показано, что для большинства компонентов Windows Vista, включая диспетчер окон рабочего стола (Dwm.exe), подсистему клиент-серверной среды выполнения (Csrss.exe) и проводник, виртуализация отключена, поскольку они либо обладают манифестом Windows Vista, либо выполняются с административными правами и, следовательно, не допускают виртуализацию. Для обозревателя Internet Explorer® (iexplore.exe) виртуализация включена, так как он может поддерживать элементы управления ActiveX и сценарии и не должен полагаться на то, что они будут правильно работать с правами обычного пользователя.
Рис. 2 Состояние виртуализации в окне диспетчера задач
Рис. 2 Состояние виртуализации в окне диспетчера задач
Области файловой системы, виртуализуемые для устаревших процессов, — это %ProgramFiles%, %ProgramData% и %SystemRoot%, за исключением некоторых определенных подкаталогов. Однако из виртуализации исключаются все файлы с расширением исполняемого файла, в том числе EXE, BAT, SCR, VBS и другие. В результате программы, которые обновляют себя под учетной записью обычного пользователя, терпят сбой вместо создания частных версий своих исполняемых файлов, которые не видны администратору, запускающему глобальный модуль обновления. Чтобы добавить к списку исключений дополнительные расширения, введите их в следующем разделе реестра и перезагрузите компьютер:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd
Для ввода нескольких расширений следует использовать мультистроковый тип, вводя каждое расширение в отдельной строке без начальной точки.
Изменения, производимые в виртуализованных каталогах устаревшими процессами, перенаправляются в виртуальный корневой каталог пользователя, %LocalAppData%\VirtualStore. Например, если виртуализованный процесс, работающий в моей системе, создает файл C:\Windows\Application.ini, фактически создается файл C:\Users\Markruss\AppData\Local\VirtualStore\Windows\Application.ini. Элемент пути Local указывает на тот факт, что если учетная запись имеет перемещаемый профиль, виртуализованные файлы не перемещаются с остальной частью профиля.
Если в проводнике перейти к каталогу, содержащему виртуализованные файлы, на панели инструментов появляется кнопка “Файлы совместимости” (рис. 3). Нажатие этой кнопки открывает соответствующий подкаталог VirtualStore, в котором собраны виртуализованные файлы.
Рис. 3 Кнопка “Файлы совместимости” говорит о наличии где-то рядом виртуализованных файлов
Рис. 3 Кнопка “Файлы совместимости” говорит о наличии где-то рядом виртуализованных файлов
На рис. 4 показано, как драйвер фильтра UAC для виртуализации файлов (%SystemRoot%\System32\Drivers\Luafv.sys) реализует виртуализацию файловой системы. Поскольку это драйвер фильтра файловой системы, он видит все операции в файловой системе, но реализует функциональные возможности только для операций из устаревших процессов. Как видно на рисунке, он изменяет путь целевого файла для устаревшего процесса, который создает файл в размещении, общем для всей системы, но не делает этого для процесса приложения Windows Vista, работающего с правами обычного пользователя. Устаревший процесс полагает, что операция прошла успешно, если она фактически создала файл в размещении, полностью доступном пользователю. Но применяемые по умолчанию разрешения для каталога \Windows не дают доступа к нему приложению, написанному для Windows Vista.
Рис. 4 Виртуализация файловой системы
Рис. 4 Виртуализация файловой системы
Виртуализация реестра реализована несколько иначе, чем виртуализация файловой системы. Виртуализованные разделы реестра включают большую часть ветви HKEY_LOCAL_MACHINE\Software, но есть и многочисленные исключения, например следующие:
HKLM\Software\Microsoft\Windows
HKLM\Software\Microsoft\Windows NT
HKLM\Software\Classes
Виртуализуются только разделы, которые часто изменяются устаревшими приложениями, но не вызывают проблем совместимости или взаимодействия. Windows перенаправляет операции изменения виртуализуемых разделов устаревшим приложением в виртуальный корневой раздел реестра пользователя в разделе HKEY_ CURRENT_USER\Software\Classes\VirtualStore. Этот раздел расположен в файле %LocalAppData%\Microsoft\Windows\UsrClass.dat, в кусте Classes пользователя, который, как и все прочие данные виртуализованных файлов, с перемещаемым профилем пользователя не перемещается.
Вместо хранения фиксированного списка виртуализованных размещений, как это делается для файловой системы, состояние виртуализации раздела хранится в виде флага REG_ KEY_DONT_VIRTUALIZE в самом разделе. С помощью служебной программы Reg.exe можно просмотреть этот флаг, а также два других флага, связанные с виртуализацией, — REG_KEY_ DONT_SILENT_FAIL и REG_KEY_ RECURSE_FLAG (см. рис. 5). Если флаг REG_KEY_DONT_SILENT_FAIL установлен и раздел не виртуализован (установлен флаг REG_KEY_DONT_VIRTUALIZE), устаревшему приложению, которому иначе было бы запрещено выполнять операции с разделом, предоставляется любой уровень доступа к разделу, который имеет пользователь, вместо доступа, затребованного приложением. Флаг REG_KEY_RECURSE_FLAG указывает, наследуют ли новые разделы флаги виртуализации родительского раздела, а не только флаги, применяемые по умолчанию.
Рис. 5 Служебная программа Reg показывает флаги виртуализации
Рис. 5 Служебная программа Reg показывает флаги виртуализации
На рис. 6 показано, как виртуализация реестра реализуется диспетчером конфигураций, который управляет реестром в ядре операционной системы, Ntoskrnl.exe. Как и в случае с виртуализацией файловой системы, устаревший процесс, создающий подраздел виртуализованного раздела, перенаправляется в виртуальный корневой раздел реестра пользователя, но процессу Windows Vista будет отказано в доступе применяемыми по умолчанию разрешениями.
Кроме виртуализации файловой системы и реестра, для правильной работы с правами обычного пользователя некоторых приложений требуется дополнительная поддержка. Например, приложение, которое проверяет членство учетной записи, под которой оно работает, в группе “Администраторы”, откажется работать, если учетная запись не входит в эту группу. Поэтому Windows Vista определяет ряд режимов совместимости приложений с тем, чтобы такие приложения всё равно смогли работать. Эти режимы совместимости, обычно применяемые к устаревшим приложениям для операций с обычными правами, показаны на рис. 7. ИТ-специалисты в корпорациях могут использовать такие инструменты, как набор средств для обеспечения совместимости приложений (ACT), который можно получить на веб-узле technet.microsoft .com/windowsvista/aa905066.aspx, и служебную программу – анализатор обычного пользователя (SUA) из этого набора или воспользоваться блогом Аарона Маргозиса (Aaron Margosis) LUA Buglight, где можно определить требования для режимов совместимости бизнес-приложений. Режимы совместимости назначаются для приложения с помощью администратора совместимости, также входящего в состав ACT, затем результирующая база данных совместимости (файл SDB) развертывается на настольных системах согласно групповой политике. Следует отметить, что в случае необходимости виртуализация может быть полностью отключена для системы с помощью параметра локальной политики безопасности.
Figure 7 Общие режимы совместимости для пользователей (Close Figure 7)

Режим совместимости | Назначение
ElevateCreateProcess | Изменение функции CreateProcess для обработки ошибок ERROR_ELEVATION_REQUIRED путем вызова службы сведений о приложении для вывода запроса на повышение.
ForceAdminAccess | Имитация запросов членства в административных группах.
VirtualizeDeleteFile | Имитация успешного удаления глобальных файлов и каталогов.
LocalMappedObject | Добавление объектов глобальных областей в пространство имен пользователя.
VirtualizeHKCRLite, VirtualizeRegisterTypeLib | Перенаправление глобальной регистрации COM-объектов в разделы пользователей.
Эффекты виртуализации
Состояние виртуализации процесса можно изменить, выбрав “Виртуализация” в контекстном меню, которое появляется, если щелкнуть процесс правой кнопкой мыши в окне диспетчера задач. На рис. А показано поведение командной строки при изменении ее состояния виртуализации. Командная строка запускается с отключенной виртуализацией, поскольку обладает манифестом Windows Vista. Поскольку она работает с правами обычного пользователя, создать файл в каталоге \Windows ей не удается, но после виртуализации с помощью диспетчера задач файл, вроде бы, успешно создается. После возвращения отключенного состояния виртуализации командной строки она не сможет найти файл, который на самом деле находится в виртуальном хранилище пользователя.
Рис. А Изменение состояния виртуализации
Рис. А Изменение состояния виртуализации

Режим одобрения администратором
Даже если пользователи запускают только программы, совместимые с правами обычного пользователя, некоторые операции все равно требуют административных прав. Подавляющее большинство установок программного обеспечения требует административных прав для создания каталогов и параметров реестра в размещениях, общих для всей системы, или для установки драйверов устройств либо служб. Изменение глобальных системных параметров Windows и приложений также требует административных прав, как, например, функция родительского контроля в Windows Vista. Большую часть этих операций можно было бы выполнить путем переключения на отдельную учетную запись администратора, но неудобство такой процедуры вероятнее всего приведет к тому, что большинство пользователей будет выполнять свои ежедневные задачи, так и оставшись в административной учетной записи.
В связи с этим Windows Vista содержит расширенные функциональные возможности “запуска от имени”, чтобы обычные пользователи могли комфортно запускать процессы с административными правами. Эти возможности нужны для того, чтобы у приложений был способ определения операций, для которых система может по мере необходимости получать административные права от имени приложения. На этом моменте я кратко остановлюсь ниже.
Далее, чтобы пользователи, действующие как системные администраторы, могли работать с правами обычного пользователя, не вводя имена пользователей и пароли каждый раз, когда им нужно обратиться к административным правам, в Windows Vista введен режим одобрения администратором (Admin Approval Mode, AAM). Эта функция создает для пользователя два набора учетных данных для входа в систему: один с правами обычного пользователя, а другой с административными. Так как каждый пользователь в системе Windows Vista или является обычным пользователем, или работает в основном как обычный пользователь в AAM, разработчики должны рассчитывать на то, что все пользователи Windows — это обычные пользователи, в результате чего будет больше программ, работающих с правами обычного пользователя без виртуализации или режима совместимости.
Предоставление процессу административных прав называется повышением прав. Если эта процедура выполняется под учетной записью обычного пользователя, она называется повышением “через плечо” (Over the Shoulder, OTS), поскольку требует ввода учетных данных для учетной записи, которая является членом группы администраторов. Это похоже на ситуацию, когда “из-за спины” обычного пользователя что-то печатает другой пользователь. Повышение, выполняемое пользователем AAM, называется повышением по согласию, поскольку пользователь просто должен одобрить присвоение его административных прав.
Windows Vista считает пользователя администратором, если он является членом любой из групп административного типа, перечисленных на рис. 8. Многие из перечисленных групп используются только в системах – участниках доменов и непосредственно не дают пользователям локальных административных прав, но позволяют им изменять параметры всего домена. Если пользователь является членом любой из этих групп, но не фактической группы администраторов, то, вместо повышений согласия, он обращается к своим административным правам через OTS-повышения.
Figure 8 Административные группы (Close Figure 8)

Встроенная группа “Администраторы”
Администраторы сертификатов
Администраторы домена
Корпоративные администраторы
Администраторы политик
Администраторы схем
Контроллеры домена
Корпоративные контроллеры домена с доступом только для чтения
Контроллеры домена с доступом только для чтения
Операторы учета
Операторы архива
Операторы шифрования
Операторы настройки сети
Операторы печати
Системные операторы
Серверы RAS
Опытные пользователи
Пред-Windows 2000 доступ
Когда пользователь, принадлежащий одной из перечисленных групп, входит в систему, Windows Vista создает маркер, представляющий версию административного идентификатора этого пользователя, но с правами обычного пользователя. Новый маркер лишается всех привилегий, назначенных пользователю, кроме привилегий, перечисленных на рис. 9, которые являются применяемыми по умолчанию привилегиями обычного пользователя. Кроме того, все группы административного типа отмечаются в новом маркере флагом USE_FOR_DENY_ONLY. На рис. 10 в окне программы Sysinternals Process Explorer (средство управления процессами, которое можно загрузить на веб-узле microsoft .com/technet/sysinternals) слева показано членство в группах и привилегии процесса, работающего с административными правами, а справа — без административных прав. (Для предотвращения неосторожного использования модель безопасности Windows требует, чтобы перед использованием привилегия со снятым флагом была включена.)
Figure 9 Привилегии обычного пользователя (Close Figure 9)

Понятное название | Внутреннее имя
Обход перекрестной проверки | SeChangeNotifyPrivilege
Завершение работы системы | SeShutdownPrivilege
Отключение компьютера от стыковочного узла | SeUndockPrivilege
Увеличение рабочего набора процесса | SeIncreaseWorkingSetPrivilege
Изменение часового пояса | SeTimeZonePrivilege
Рис. 10 Маркеры администратора AAM и обычного пользователя
Рис. 10 Маркеры администратора AAM и обычного пользователя
Группа с флагом “только для запрещения” может использоваться только для запрещения пользовательского доступа к ресурсу, но никогда не разрешает доступ. Тем самым закрывается брешь в системе безопасности, которая может возникнуть в случае полного удаления группы. Например, у файла есть список управления доступом (ACL), который запрещает любой доступ для группы “Администраторы”, но предоставляет некоторый доступ другой группе, к которой относится пользователь. Если группа администраторов отсутствует в маркере, этот пользователь получит доступ к файлу, поскольку версия его идентификатора со стандартными правами имеет больше прав доступа, чем административная.
Автономные системы, которыми обычно являются домашние компьютеры, и системы, входящие в состав доменов, обрабатывают AAM-доступ со стороны удаленных пользователей по-разному, поскольку доменные компьютеры в своих разрешениях доступа к ресурсам могут использовать доменные административные группы. Когда пользователь обращается к общедоступному файловому ресурсу на автономном компьютере, Windows запрашивает удостоверение удаленного пользователя с правами обычного пользователя, но на системах, объединенных в домен, Windows соблюдает все членства пользователя в группах домена, запрашивая административный идентификатор пользователя.

Удобное получение административных прав
Определить потребность в административных правах системы и приложений можно множеством способов. Один из них — команда контекстного меню и ярлык “Запуск от имени администратора” в пользовательском интерфейсе проводника. Эти элементы содержат цветной значок щита, который должен быть добавлен ко всем кнопкам или пунктам меню, выбор которых приводит к повышению прав. При выборе элемента “Запуск от имени администратора” проводник вызывает API-функцию ShellExecute с командой “runas”.
Подавляющее большинство программ установки требует административных прав, поэтому загрузчик образов, который инициирует запуск исполняемого файла, содержит код обнаружения установщиков для выявления устаревших версий установщиков. Часть алгоритмов используемой загрузчиком эвристики довольно проста: он ищет слова “setup”, “install” или “update” в имени файла образа или внутренней информации о версии. Более сложные алгоритмы включают просмотр в исполняемом файле последовательностей байтов, обычно применяемых сторонними разработчиками в служебных программах – установочных оболочках.
Чтобы определить, нуждается ли целевой исполняемый файл в правах администратора, загрузчик образов также вызывает библиотеку совместимости приложений (appcompat). Библиотека обращается к базе данных совместимости приложений, чтобы определить, связаны ли с исполняемым файлом флаги совместимости RequireAdministrator или RunAsInvoker.
Самый общий способ запросить для исполняемого файла административные права — добавить в его файл манифеста приложения тег requestedElevationLevel. Манифесты — это XML-файлы, содержащие дополнительные сведения об образе. Они были введены в Windows XP как способ определения зависимостей для параллельно используемых библиотек DLL и сборок Microsoft .NET Framework. Наличие в манифесте элемента trustInfo (он показан ниже во фрагменте дампа Firewallsettings.exe) означает, что исполняемый файл был написан для Windows Vista и содержит элемент requestedElevationLevel. Атрибут level этого элемента может иметь одно из трех значений: asInvoker, highestAvailable и requireAdministrator.
<trustInfo
 xmlns=”urn:schema-microsoft-com:asm.v3”>
 <security>
  <requestedPrivileges>
   <requestedExecutionLevel
    Level=”requireAdministrator”
    uiAccess=”false”/>
  </requestedPrivileges>
 </security>
</trustInfo>
Исполняемые файлы, не требующие административных прав, например Notepad.exe, имеют значение атрибута asInvoker. В некоторых исполняемых файлах заложено допущение, что администраторы всегда хотят получить максимальный доступ. Поэтому в них используется значение highestAvailable. Пользователю, запускающему исполняемый файл с этим значением, предлагается повысить права, только если он работает в режиме AAM или рассматривается как администратор согласно определенным ранее правилам и в связи с этим должен повысить права для обращения к своим административным привилегиям. Примерами приложений, для которых используется значение highestAvailable, могут служить программы Regedit.exe, Mmc.exe и Eventvwr.exe. Наконец, значение requireAdministrator всегда инициирует запрос повышения и используется всеми исполняемыми файлами, которым не удастся выполнить свои действия без административных прав.
В приложениях со специальными возможностями атрибуту uiAccess задается значение "true" для управления окном ввода в процессах с повышенными правами. Кроме того, для обеспечения этих возможностей они должны быть подписаны и находиться в одном из нескольких безопасных размещений, включая %SystemRoot% и %ProgramFiles%.
Значения, задаваемые исполняемым файлом, можно легко определить, просмотрев его манифест с помощью служебной программы Sysinternals Sigcheck, например:
sigcheck –m <executable>
При запуске образа, который запрашивает административные права, службе сведений о приложении (известна также как AIS, находится в %SystemRoot%\System32\Appinfo.dll), которая работает в процессе Service Host (%SystemRoot%\System32\Svchost.exe), предписывается запустить программу Consent.exe (%SystemRoot%\System32\Consent.exe). Программа Consent создает снимок экрана, применяет к нему эффект затемнения, переключается на рабочий стол, доступный только системной учетной записи, устанавливает затемненный снимок в качестве фона и открывает диалоговое окно повышения прав, содержащее сведения об исполняемом файле. Вывод на отдельном рабочем столе предотвращает изменение этого диалогового окна любой вредоносной программой, работающей под учетной записью пользователя.
Рис. 11 Диалоговые окна OTS-повышения
Рис. 11 Диалоговые окна OTS-повышения
Если образ является компонентом Windows, подписанным цифровой подписью корпорации Майкрософт, и находится в системном каталоге Windows, то, как показано вверху на рис. 11, в верхней части диалогового окна добавляется синяя полоса. Серая полоса (среднее диалоговое окно) обозначает образы, подписанные цифровой подписью, отличной от подписи корпорации Майкрософт, а оранжевая полоса (нижнее диалоговое окно) предназначена для неподписанных образов. Для образов, подписанных цифровой подписью, в диалоговом окне повышения показывается значок образа, описание и издатель, а для неподписанных образов — только общий значок, имя файла и примечание “Издатель неизвестен”. Это усложняет для вредоносных программ имитацию подлинного программного обеспечения. Кнопка “Сведения” внизу диалогового окна раскрывается, показывая командную строку, которая будет передана исполняемому файлу при его запуске. Диалоговое окно программы Consent для режима AAM, показанное на Figure 12, подобно окну для OTS-повышения, но вместо запроса на ввод учетных данных администратора там имеются кнопки “Далее” и “Отмена”.
Рис. 12 Диалоговое окно AAM-повышения
Рис. 12 Диалоговое окно AAM-повышения
Если пользователь отклоняет повышение прав, Windows возвращает процессу, инициировавшему запуск, ошибку “Отказано в доступе”. Если пользователь соглашается на повышение, введя учетные данные администратора или нажав кнопку “Далее”, служба AIS вызывает функцию CreateProcessAsUser для запуска процесса с необходимым административным идентификатором. Хотя технически родителем процесса с повышенными правами является служба AIS, она использует новую поддержку со стороны функции CreateProcessAsUser, которая устанавливает запускаемому процессу в качестве кода родительского процесса код процесса, который изначально его запустил (см. рис. 13). Именно поэтому процессы с повышенными правами не изображаются как потомки процесса Service Hosting службы AIS в таких средствах, как обозреватель процессов, которые показывают деревья процессов.
Рис. 13 Поток повышения прав
Рис. 13 Поток повышения прав
Даже при том, что диалоговые окна повышения выводятся на отдельном безопасном рабочем столе, по умолчанию пользователи не имеют никакого способа проверить тот факт, что они видят подлинное диалоговое окно, а не окно, открытое вредоносной программой. Для AAM это не проблема, поскольку вредоносная программа со своим фальшивым диалоговым окном Consent не может получить административных прав. Однако эта программа может дождаться ОТС-повышения обычного пользователя, перехватить его и использовать троянское диалоговое окно для захвата учетных данных администратора. С этими учетными данными вредоносная программа может получить доступ к учетной записи администратора и инфицировать ее.
В связи с этим в корпоративных средах ОТС-повышения должны быть строго запрещены. Чтобы отключить ОТС-повышения (и уменьшить количество вызовов службы поддержки), запустите редактор локальных политик безопасности (Secpol.msc) и для параметра “Управление учетными записями пользователей: поведение запроса на повышение прав для обычных пользователей” выберите значение Automaticallydenyelevationrequests.
Пользователи домашних компьютеров, которые сами отвечают за свою безопасность, должны настроить ОТС-повышения таким образом, чтобы для их применения необходимо было ввести специальное сочетание клавиш (SAS), которое вредоносная программа не сможет перехватить или имитировать. Чтобы настроить SAS, нужно запустить редактор групповых политик (Gpedit.msc), перейти к разделу “Конфигурация компьютера” – “Административные шаблоны” – “Компоненты Windows” – “Интерфейс пользователя для учетных данных” и включить параметр “Требовать достоверный путь для входа в учетную запись”. После этого обратиться к диалоговому окну повышения можно будет, нажав сочетание клавиш CTRL+ALT+DELETE.

Изоляция процессов с повышенными правами
Windows Vista устанавливает ограждение вокруг процессов с повышенными правами, чтобы защитить их от вредоносной программы, работающей на том же компьютере с правами обычного пользователя. Без такого барьера вредоносная программа может управлять административным приложением, отправляя ему фальшивый синтезированный ввод мышью и оконный ввод через оконные сообщения. Стандартная модель безопасности Windows не даст вредоносной программе, работающей в процессе с правами обычного пользователя, работать от имени другого пользователя в процессе с повышенными правами. Однако она не может запретить вредоносной программе, работающей под версией обычных прав административного пользователя, запуск процессов пользователя с повышенными правами, внедрение в них кода и запуск потоков его выполнения.
Защита Windows Vista против оконных сообщений называется изоляцией привилегий интерфейса пользователя (UIPI). Он основан на новом механизме целостности Windows, который Windows Vista использует также как ограждение вокруг процессов с повышенными правами. В этой новой модели безопасности все процессы и объекты имеют уровни целостности, а политика целостности объекта может ограничить доступ, который иначе был бы предоставлен процессу моделью безопасности Windows “Управление доступом на уровне пользователей” (DAC).
Уровни целостности (IL) представлены идентификаторами безопасности (SID), которые представляют также пользователей и группы, уровень которых закодирован в относительном идентификаторе (RID) идентификатора SID. На рис. 14 показаны отображаемое имя, SID и шестнадцатеричная версия RID идентификатора SID для четырех основных IL. В шестнадцатеричных числах видны промежутки размером 0x1000 между каждым уровнем, что допускает создание промежуточных уровней для использования приложениями со специальными возможностями интерфейса пользователя и будущего развития.
Figure 14 Основные уровни целостности (Close Figure 14)

Название | SID | RID
Низкий обязательный уровень | S-1-16-4096 | 0x1000
Средний обязательный уровень | S-1-16-8192 | 0x2000
Высокий обязательный уровень | S-1-16-12288 | 0x3000
Обязательный уровень системы | S-1-16-16384 | 0x4000
На рис. 15 перечислены политики IL объектов и типы доступа, которые они ограничивают, и их соответствие общим типам доступа, определенным для объекта. Например, политика “Нет записи” предотвращает получение процессом с более низким IL любого доступа, представляемого типом GENERIC_WRITE. По умолчанию для большинства объектов, включая файлы и параметры реестра, применяется политика “Нет записи”, которая запрещает процессу доступ для записи к объектам, имеющим более высокий IL, даже если список управления доступом на уровне пользователей (DACL) объекта предоставляет пользователю такой доступ. Другая политика применяется только к объектам-потокам и объектам-процессам. Эта политика, “Нет записи” плюс “Нет чтения”, запрещает процессу с более низким IL встраивать код и считывать данные — например пароли — из процесса, имеющего более высокий IL.
Figure 15 Политики уровней целостности (Close Figure 15)

Политика | Результат действия
Нет записи | Процесс с более низким IL не может изменить объект с более высоким IL
Нет чтения | Процесс с более низким IL не может считать данные из объекта с более высоким IL
Нет запуска | Процесс с более низким IL не может запустить объект с более высоким IL
Windows назначает каждому процессу IL, помещая его в маркер вместе с кодами SID групп, к которым относится пользователь, выполняющий процесс. На рис. 16 показаны примеры процессов, которым назначены разные IL. Процессы обычно наследуют IL своего родителя, но процесс может также запустить процесс с другим IL, как это делает служба AIS, когда запускает процесс с повышенными правами. Уровни целостности процесса можно просмотреть с помощью встроенной служебной программы Whoami, указав параметр /all, или с помощью программ Process Explorer или AccessChk (обе от Sysinternals). Обозреватель процессов может отображать коды IL процесса наряду со столбцом “Уровень целостности”.
Figure 16 Примеры назначения процессам уровней целостности (Close Figure 16)

Уровень целостности | Примеры процессов
Низкий обязательный уровень | Internet Explorer защищенного режима и процессы, им
Средний обязательный уровень | Процессы обычного пользователя и процессы ААМ без повышенных прав
Высокий обязательный уровень | Процессы, работающие с административными правами
Обязательный уровень системы | Процессы Local System, Local Service и Network Service
Каждый защищаемый объект обладает IL, который может быть явным или неявным. Процессы, потоки и маркеры всегда имеют явно назначенный IL, который обычно совпадает с IL, сохраненным в маркере соответствующего процесса. Большинство объектов не имеет явного IL, поэтому к ним по умолчанию применяется средний (Medium) уровень целостности. Уровень IL, отличный от среднего, имеют только объекты, создаваемые процессом, работающим с низким (Low) IL. Такие объекты также имеют низкий IL. Просмотреть IL файлов можно с помощью встроенного средства iCacls (%SystemRoot%\System32\iCacls.exe), а IL файлов, параметров реестра, служб и процессов — с помощью служебной программы Sysinternals AccessChk. Нарис. 17 показано, что IL каталога, к которому должен иметь доступ обозреватель Internet Explorer в защищенном режиме — Low.
Рис. 17 IL каталога “Избранное” пользователя в окне программы AccessChk
Рис. 17 IL каталога “Избранное” пользователя в окне программы AccessChk
Если у объекта есть явный IL, он хранится в записи управления доступом (ACE) нового типа, представленного в Windows Vista, — Label ACE, в списке управления системным доступом (SACL) дескриптора безопасности объекта (см. рис. 18). SID в ACE соответствует IL объекта, а с помощью флагов ACE кодируется политика целостности объекта. До Windows Vista в SACL хранились только ACE-записи аудита, которые требуют привилегии “Управление аудитом и журналом безопасности” (SeSecurityPrivilege), но для чтения записей типа Label ACE необходим только доступ “Разрешение на чтение” (READ_CONTROL). Чтобы процесс мог изменить IL объекта, он должен иметь доступ “Смена владельца” (WRITE_OWNER) к объекту и IL, равный или более высокий, чем у объекта. При этом процесс может установить IL, только равный его собственному IL или ниже. Новая привилегия “Изменение метки объекта” (SeRelabelPrivilege) дает процессу возможность изменить IL любого объекта, к которому процесс имеет доступ, и даже установить IL выше собственного IL процесса. Однако по умолчанию эта привилегия не назначается никакой учетной записи.
Рис. 18 Запись Label ACE объекта
Рис. 18 Запись Label ACE объекта
Когда процесс пытается открыть объект, то перед тем как функция ядра SeAccessCheck выполнит стандартную проверку DACL Windows, происходит проверка целостности. Согласно применяемым по умолчанию политикам целостности, процесс может открыть объект для записи только если выполняются два условия: его IL равен или выше, чем IL объекта, и DACL предоставляет процессу необходимые типы доступа. Например, процесс с низким IL не сможет открыть процесс со средним IL для записи, даже если DACL предоставляет процессу такое право.
Применяемая по умолчанию политика целостности позволяет процессам открыть любой объект — за исключением объектов-процессов и объектов-потоков — для чтения, если DACL объекта предоставляет им такой доступ. Это означает, что процесс, работающий с низким IL, может открыть любые файлы, доступные для учетной записи пользователя, под которой он работает. С помощью IL-уровней обозреватель Internet Explorer защищенного режима предотвращает блокировку изменения параметров учетной записи пользователя вредоносной программой, но не может помешать ей читать документы пользователя.
Объекты-процессы и объекты-потоки — исключения, поскольку их политика целостности содержит также компонент “Нет чтения”. Это означает, что IL процесса должен быть равен или выше, чем IL процесса или потока, который данному процессу необходимо открыть, а DACL должен предоставить ему доступ требуемых типов. На рис. 19 предполагается, что DACL-списки разрешают необходимый доступ. Здесь показаны варианты доступа процессов, работающих со средним и низким IL, к другим процессам и объектам.
Рис. 19 Доступ к объектам и процессам
Рис. 19 Доступ к объектам и процессам
Подсистема сообщений Windows также использует уровни целостности для реализации UIPI, препятствуя отправлению процессом всех сообщений, кроме нескольких информационных оконных сообщений, в окна, принадлежащие процессу с более высоким IL. Это позволяет предотвратить ввод в окна процессов с повышенными правами процессами обычных пользователей и разрушение процесса с повышенными правами отправкой ему неправильно сформированных сообщений, вызывающих переполнение внутреннего буфера. Процессы могут разрешать прохождение дополнительных сообщений сквозь защиту, вызывая API-функцию ChangeWindowMessageFilter. UIPI-изоляция также блокирует доступ к окнам процессов с более высоким IL с тем, чтобы, например, процесс обычного пользователя не мог захватить нажатия клавиш пользователем в административных приложениях.

Повышения прав и рубежи безопасности
Важно понимать, что повышения прав UAC — это дополнительные удобства, а не новые рубежи безопасности. Рубеж безопасности — когда некоторая политика безопасности диктует, что может проходить через некоторую границу, а что не может. Учетные записи пользователей — это пример рубежей безопасности в Windows, поскольку один пользователь не может обратиться к данным, принадлежащим другому пользователю, не имея на то разрешения пользователя-владельца.
Поскольку повышения прав не устанавливают рубежей безопасности, нет никакой гарантии, что вредоносная программа, работающая в системе с правами обычного пользователя, не сможет нарушить безопасность процесса с повышенными правами и получить административные права. Например, в диалоговых окнах повышения только определяется исполняемый файл, права которого будут повышены; в них ничего не говорится о том, что этот файл будет делать при выполнении. Исполняемый файл может обрабатывать аргументы командной строки, загружать DLL-библиотеки, открывать файлы данных и взаимодействовать с другими процессами. Любая из этих операций потенциально может позволить вредоносной программе нарушить безопасность процесса с повышенными правами и, таким образом, получить административные права.
Игра в песочнице с низким IL
Internet Explorer защищенного режима работает с низким IL, чтобы создать барьер против вредоносных программ, которые могут инфицировать его процесс. Это препятствует изменению вредоносной программой параметров учетной записи пользователя и установке ею себя в размещениях автозапуска. Поиграть в этой песочнице, запуская произвольные процессы с низким IL, можно с помощью служебной программы PsExec от Sysinternals с ключом -l. На рис. Б показано, что командная строка с низким IL не может создать файл во временном каталоге пользователя, которому присвоен средний IL, но может это сделать во временном каталоге обозревателя Internet Explorer, который имеет низкий IL.
Рис. БКомандная строка может создавать файлы только в размещении с таким же IL

Процессы ААМ с повышенными правами особенно восприимчивы к нарушениям безопасности, поскольку они работают под той же учетной записью пользователя, что и ААМ-процессы пользователя со стандартными правами, и совместно используют профиль пользователя. Многие приложения считывают параметры и загружают расширения, зарегистрированные в профиле пользователя, создавая возможности для повышения прав вредоносной программы. Например, при работе в общих управляющих диалоговых окнах загружаются расширения оболочки, настроенные в разделе пользователя в реестре (в ветви HKEY_CURRENT_USER). Вредоносная программа может добавить себя в качестве расширения и затем загрузиться в любой процесс с повышенными правами, который использует эти диалоговые окна.
Очевидно, из-за их общедоступного состояния под угрозу могут быть поставлены даже процессы, повышенные от учетных записей обычного пользователя. Все процессы, работающие в сеансе входа в систему, совместно используют внутреннее пространство имен, в котором Windows хранит такие объекты, как события, мьютексы, семафоры и общую память. Если вредоносная программа знает, что процесс с повышенными правами при запуске будет пытаться открыть и прочитать определенный объект общей памяти, она может создать объект, содержимое которого вызовет переполнение буфера, и затем ввести код в процесс с повышенными правами. Этот тип атаки относительно сложен, но в случае его реализации OTS-повышения перестают быть рубежом безопасности.
Практический результат введения повышений — удобство для пользователей, которые, по умолчанию работая с правами обычного пользователя, получают доступ к административным правам. Пользователям, которые хотят иметь гарантии безопасности, придется несколько поступиться этим удобством. Выполняя ежедневные задачи как обычные пользователи, с помощью функции быстрого переключения пользователей (FUS) они могут переходить на выделенную учетную запись администратора для выполнения административных операций. С другой стороны, пользователи, склонные пожертвовать безопасностью в пользу удобства, могут отключить UAC в системе в диалоговом окне “Учетные записи пользователя” панели управления. Но следует помнить, что при этом также отключается защищенный режим для Internet Explorer.

Заключение
Работа в качестве обычного пользователя обеспечивает многочисленные преимущества, включая защиту системы от случайного или преднамеренного повреждения и защиту от несанкционированного доступа данных и целостности пользователей, совместно использующих систему. Результатом различных изменений и применения технологий UAC будут радикальные перемены в модели использования Windows. С приходом Windows Vista пользователи Windows впервые могут выполнять большинство ежедневных задач и запускать большинство программ, используя права обычного пользователя, а многие корпорации теперь смогут шире развертывать учетные записи обычных пользователей.

Марк Руссинович занимает должность технического специалиста в подразделении Platform and Services корпорации Майкрософт. Он является одним из соавторов книги Microsoft Windows Internals (“Внутренняя структура Microsoft Windows”, издательство Microsoft Press, 2004 г.) и часто выступает с докладами на конференциях для ИТ-специалистов и разработчиков. Марк Руссинович перешел в корпорацию Майкрософт после недавнего приобретения ею компании Winternals Software, одним из основателей которой он являлся. Он также создал веб-узел Sysinternals, на котором опубликовал служебные программы Process Explorer, Filemon и Regmon.
© 2007 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.


 Безопасность: Защита данных с помощью шифрования диска BitLocker
Безопасность Байрон Хайнз (Byron Hynes)

Защита данных с помощью шифрования диска BitLocker
Краткий обзор:
  • Полное шифрование тома
  • Ключи BitLocker
  • Настройка BitLocker

Шифрование дисков BitLocker — определенно одна из самых обсуждаемых возможностей в Windows Vista. Однако, большинство людей еще не имело серьезной возможности опробовать BitLocker и на собственном опыте испытать,
что и как он делает — особенно на компьютере с доверенным платформенным модулем (TPM). В этой статье мы рассмотрим основы BitLocker™, позволяющие оценить его потенциал и включить в программу обновления. Начнем с предпосылок и концепций, затем рассмотрим включение BitLocker, восстановление данных, администрирование и то, какова роль BitLocker при утилизации компьютера. Справка по используемой терминологии приведена на боковой панели «Диски и тома».
Диски и тома
Терминология в области дисков и томов может сбивать с толку. Вот краткий словарь.
Раздел — секция на физическом жестком диске. Это логическая структура, определяемая в таблице разделов диска.
Том — логическая структура в Windows, составленная из одного или нескольких разделов и определяемая диспетчером томов Windows. Все приложения и все компоненты операционной системы, кроме диспетчера томов и загрузочных модулей, работают с томами, а не с разделами. В клиентских операционных системах Windows, включая Windows Vista, один раздел обычно соответствует одному тому. У серверов том часто составляется из нескольких разделов, подобно массивам дисков (RAID).
Активный раздел. Только один раздел может быть помечен как активный. Это раздел, содержащий загрузочный сектор, используемый при запуске операционной системы. Активный раздел также порой называют системным разделом или системным томом, но эти названия не имеют отношения к тому ОС Windows.
Том ОС Windows — том, содержащий установку Windows, включая папки System и System32. До выхода Windows Vista использовался (и до сих пор часто используется) термин «загрузочный раздел». Термин «том ОС Windows» понятнее и не страдает от постоянного смешения терминов «загрузочный раздел» и «системный раздел». Раньше преподаватели порой просили обучающихся запомнить, что «загрузка идет из системного раздела, а системные файлы находятся в загрузочном разделе».
До Windows Vista том ОС Windows (он же загрузочный раздел) и активный раздел (он же системный) обозначали одно и то же, поскольку жесткие диски большинства клиентских компьютеров содержали единственный большой раздел. На рис. А показаны назначения каждого раздела диска в консоли диспетчера дисков Windows Vista.
Рис. А Назначения разделов
Рис. А Назначения разделов

BitLocker выполняет две взаимодополняющие, но различные функции. Во-первых, он обеспечивает шифрование всего тома ОС Windows®. Во-вторых, на компьютерах с совместимым доверенным платформенным модулем он позволяет проверить целостность загрузочных компонентов до запуска Windows Vista™.
Для полного использования возможностей BitLocker компьютер должен быть оснащен совместимыми микрочипом TPM и BIOS. Под совместимыми понимается версия 1.2 TPM и BIOS, поддерживающая TPM и статический корень измерения доверия (Static Root of Trust Measurement), определенный в спецификациях TCG. Однако компьютеры без совместимых TPM и BIOS тоже могут использовать шифрование BitLocker.

Полное шифрование тома
BitLocker шифрует весь том ОС Windows со всеми данными. Это ключевой аспект в защите конфиденциальной информации, содержащейся на компьютерах предприятия, особенно переносных.
Переносные компьютеры крадут и теряют каждый день. Благодаря возросшим возможностям переносных устройств, а также все большей доли мобильности в работе один сотрудник может иметь при себе сотни гигабайт промышленных секретов вашего предприятия, секретных документов или сведений о клиентах частного характера. Краткий обзор сводок новостей покажет, что такие данные теряются слишком часто. (По данным Privacy Rights Clearinghouse, с 2005 года пропало или было разглашено свыше 104 миллионов записей, содержащих частные сведения.)
Большинство организаций уже находятся под действием юридических или корпоративных документов, обязывающих охранять сведения личного характера, и даже если ваше предприятие еще не входит в их число, вы наверняка были бы заинтересованы обеспечить документам сохранность.

Зачем шифровать весь том?
Если вы опытный администратор Windows, вы наверняка уже знакомы с имевшимися в Windows вариантами шифрования, например EFS, и, возможно, с шифрованием и защитой служб управления правами (RMS). Главное отличие BitLocker в том, что он работает автоматически, прозрачно и распространяется на весь том.
Например, в EFS нужно было явно указывать, какие файлы и папки шифровать. В Windows Vista появились новые параметры, добавляющие EFS гибкости. И EFS, и RMS могут пригодиться в определенных обстоятельствах, когда BitLocker не сможет помочь. Обе эти технологии требуют значительных усилий по настройке и не предназначены для защиты всего содержимого тома.
В противоположность им, BitLocker шифрует все, что записывается на защищенный им том, включая файлы операционной системы, реестр, файлы спящего режима и подкачки, приложения и их данные.
Не шифруются три элемента: загрузочный сектор, поврежденные сектора, уже отмеченные как нечитаемые, и метаданные тома. Последние состоят из трех избыточных копий данных, используемых BitLocker, включая статистическую информацию о томе и защищенные копии некоторых ключей расшифровки. Эти элементы не требуют шифрования, поскольку не являются уникальными, ценными или позволяющими определить личность.
Шифрование всего тома защищает от атак с выключением (offline attack), которые подразумевают обход операционной системы. Типичный пример — кража офисного компьютера, извлечение жесткого диска и установка его в качестве второго диска другого компьютера (под управлением другой копии Windows или вообще другой ОС), что позволяет обойти разрешения NTFS и ввод пароля. Прочитать таким образом диск, защищенный BitLocker, невозможно.

Как BitLocker шифрует данные
BitLocker использует алгоритм AES с ключом 128 бит. Для большей надежности длину ключа можно увеличить до 256 бит с помощью групповых политик или через поставщик инструментария управления Windows (WMI) для BitLocker.
Каждый сектор тома шифруется отдельно, при этом часть ключа шифрования определяется номером этого сектора. В результате два сектора, содержащие одинаковые незашифрованные данные, будут в зашифрованном виде выглядеть по-разному, что сильно затрудняет определение ключей шифрования путем записи и шифровки заранее известных данных.
Перед применением шифрования BitLocker использует алгоритм, называемый диффузором (diffuser). Не углубляясь в криптографию, можно сказать, в результате его применения даже мельчайшее изменение исходного текста приводит к абсолютному изменению всего сектора зашифрованных данных. Это также серьезно затрудняет определение ключей или дешифровку.
Если вас заинтересовали детали алгоритма шифрования BitLocker, вы можете подробнее прочитать о нем в статье Нейла Фергюсона (Neil Ferguson) «AES-CBC + Elephant Diffuser: алгоритм шифрования диска для Windows Vista».

Ключи BitLocker
Имея дело с шифрованием, стоит разбираться в ключах, и шифрование BitLocker не исключение. Архитектура его ключей изящна, но весьма непроста.
Сами секторы шифруются ключом шифрования всего тома (full-volume encryption key, FVEK). Пользователи, однако, с этим ключом не работают и доступа к нему не имеют. Сам ключ FVEK шифруется основным ключом тома (volume master key, VMK). Такой уровень абстракции дает уникальные преимущества, но делает весь процесс более трудным для понимания. Ключ FVEK хранится в строжайшей секретности, потому что при его разглашении потребовалось бы перешифровать все секторы. Поскольку перешифрование займет значительное время, стоит не допускать разглашения ключа. Поэтому система работает с ключом VMK.
Ключ FVEK (зашифрованный ключом VMK) хранится на диске среди метаданных тома. При этом он никогда не попадает на диск в расшифрованном виде.
Ключ VMK тоже шифруется, или «охраняется», одним или несколькими предохранителями ключей. Предохранитель по умолчанию — TPM. Его использование описано далее в разделе о проверке целостности. Пароль восстановления тоже создается как предохранитель на случай экстренных ситуаций. Восстановление также описано далее.
Для дополнительной защищенности можно объединить TPM с числовым ПИН-кодом или с частичным ключом, хранимым на USB-накопителе. И то, и другое — образец двухфакторной проверки подлинности. Если у компьютера нет совместимого TPM-чипа и BIOS, BitLocker может сохранить предохранитель ключа целиком на USB-накопителе. Получится ключ запуска.
BitLocker можно отключить, не расшифровывая данные. В этом случае ключ VMK защищается только новым предохранителем ключа, который хранится в незашифрованном виде. Этот ключ позволяет системе получать доступ к диску так, словно он не зашифрован.
При запуске система ищет подходящий предохранитель ключа, опрашивая TPM, проверяя порты USB или, если необходимо, запрашивая пользователя (что называется восстановлением). Обнаружение предохранителя ключа позволяет Windows расшифровать ключ VMK, которым расшифровывается ключ FVEK, которым расшифровываются данные на диске. Весь процесс показан на рис. 1.
Рис. 1 Процесс запуска BitLocker по умолчанию
Рис. 1 Процесс запуска BitLocker по умолчанию

Проверка целостности
Поскольку компоненты, выполняющие начальную стадию загрузки, должны оставаться незашифрованными (иначе компьютер не сможет запуститься), злоумышленник может изменить их код (создать rootkit) и так получить доступ к компьютеру, даже если данные на диске останутся зашифрованными.
Это открывает доступ к конфиденциальной информации, например ключам BitLocker или паролям пользователей, которые могут быть использованы для обхода других средств защиты.
Предотвращение такого хода событий было одной из исходных целей всей программы и группы разработчиков BitLocker. До некоторой степени, шифрование почти позволяло достичь конечной цели. Полное шифрование тома позволяет BitLocker сберегать целостность системы и не давать Windows запуститься, если компоненты, выполняющие начальную стадию загрузки, были изменены.
Если компьютер снабжен совместимым TPM, при каждом его запуске каждый из компонентов ранней загрузки — BIOS, MBR, загрузочный сектор и код диспетчера загрузки — проверяет запускаемый код, подсчитывает значение хэша и сохраняет его в специальных регистрах TPM, называемых регистрами конфигурации платформы (platform configuration registers, PCR). Значение, сохраненное в PCR, может быть заменено или стерто только при перезапуске системы. BitLocker использует TPM и значения, сохраненные в PCR, для защиты ключа VMK.
TPM может создать ключ, привязанный к конкретным значениям PCR. После создания этот ключ шифруется модулем TPM, и расшифровать его сможет только этот конкретный модуль. Причем для этого потребуется, чтобы текущие значения PCR совпадали со значениями на момент создания ключа. Это называется запечатыванием (sealing) ключа в TPM.
По умолчанию BitLocker запечатывает ключи к измерениям CRTM, BIOS и любым расширениям платформы, необязательному ROM-коду, коду MBR, загрузочному сектору NTFS и диспетчеру загрузки. Если любой из этих элементов неожиданно оказывается измененным, BitLocker блокирует диск и не даст получить к нему доступ или расшифровать.
По умолчанию BitLocker настроен на обнаружение и использование TPM. С помощью настроек групповой или локальной политики можно разрешить работу BitLocker без TPM с хранением ключей на внешнем флэш-накопителе USB, но тогда становится невозможно проверять целостность системы.

Первичное включение BitLocker
BitLocker доступен в редакциях Windows Vista Enterprise и Windows Vista Ultimate (а также как необязательный компонент следующей версии Windows Server® под кодовым именем «Longhorn»).
В нижеследующем изложении предполагается, что для тестирования доступен компьютер с совместимым TPM. Если требуется включить BitLocker на компьютере без TPM, следуйте инструкциям на боковой панели «Использование BitLocker без TPM».
Использование BitLocker без TPM
По умолчанию BitLocker настроен на использование TPM, поэтому при его отсутствии Windows с неизмененными настройками не даст включить BitLocker. Однако, выполнив приведенные далее шаги, взятые из «Пошагового руководства шифрования дисков Windows BitLocker», вы сможете использовать BitLocker на компьютере без TPM.
Для выполнения этих шагов необходимо войти в систему с администраторскими привилегиями. Даже при отсутствии TPM компьютер должен поддерживать чтение с флэш-накопителя USB во время загрузки. Кроме того, необходимо иметь и сам готовый к использованию флэш-накопитель — при запуске BitLocker и при каждой последующей перезагрузке компьютера.
Шифрование диска BitLocker на компьютере без совместимого TPM включается так:
  1. нажмите кнопку Пуск, введите gpedit.msc в поле поиска и нажмите ВВОД;
  2. если появится диалоговое окно контроля учетных записей, подтвердите желаемость действия, нажав кнопку «Продолжить»;
  3. в дереве консоли редактора объектов групповых политик выберите пункт «Редактор локальной политики», щелкните «Административные шаблоны», затем «Компоненты Windows», после чего дважды щелкните «Шифрование диска BitLocker»;
  4. Дважды щелкните настройку «Установка панели управления: включить дополнительные параметры запуска». Появится одноименное диалоговое окно;
  5. Выберите вариант «Включить», установите флажок «Разрешить использование BitLocker без совместимого TPM» и нажмите кнопку «ОК». Теперь вместо TPM можно использовать ключ запуска;
  6. закройте редактор объектов групповой политики;
  7. чтобы новые настройки групповых политик вступили в силу немедленно, нажмите кнопку «Пуск», введите gpupdate.exe /force в поле поиска и нажмите клавишу ВВОД. Дождитесь завершения процесса.

Важный шаг в процессе включения BitLocker — убедиться, что тома настроены верно. Для работы BitLocker требуется, чтобы активный раздел был не зашифрован. Это необходимо для считывания загрузочного сектора, диспетчера загрузки и загрузчика Windows (эти компоненты защищаются средствами проверки целостности системы, описанными ранее). Поскольку другие компоненты Windows могут нуждаться во временном доступе к активному разделу, корпорация Майкрософт рекомендует отводить ему не меньше 1,5 ГБ. Также не помешает настроить разрешения NTFS, чтобы пользователи не смогли случайно записать данные на этот том.
Сама Windows будет установлена на другой, больший том, который можно зашифровать. Если установка Windows производится на новый компьютер, можно вручную настроить тома в соответствии с инструкциями, приведенными в Пошаговом руководстве шифрования дисков Windows BitLocker.
Для подготовки системы можно использовать средство подготовки диска для BitLocker. Это средство берет на себя все заботы по настройке дисков. Оно доступно как Windows Vista Ultimate Extra, а также для потребителей, занимающихся развертыванием Windows Vista Enterprise. Подробные инструкции по использованию этого средства см. в статье базы знаний support.microsoft.com/kb/930063.
Средство подготовки автоматически уменьшает размер тома (если он один), создает второй раздел, делает его активным, вносит все необходимые изменения в конфигурацию и переносит стартовые файлы в нужное место.
После настройки томов включить BitLocker не составляет труда. В разделе «Безопасность» панели управления щелкните значок шифрования дисков BitLocker. После утвердительного ответа на запрос UAC появится диалоговое окно, показанное на рис. 2.
Рис. 2 Включение BitLocker
Рис. 2 Включение BitLocker
Дальнейшая последовательность шагов зависит от состояния микросхемы TPM компьютера. Если он не инициализирован, запустится мастер инициализации TPM. Для успешной инициализации следуйте его указаниям (потребуется перезагрузить компьютер).
После инициализации TPM появится страница сохранения пароля восстановления (рис. 3). Пароль восстановления нужен для возвращения доступа к данным в случае сбоя в модуле TPM или другой неисправности. С помощью этой страницы можно сохранить его на флэш-накопителе USB или на сетевом диске, а также напечатать для помещения в безопасное место. Нужно выбрать хотя бы один из этих вариантов, причем сохранять можно в нескольких экземплярах. После сохранения кнопка «Далее» станет доступной. Нажмите ее.
Рис. 3 Сохранение пароля восстановления
Рис. 3 Сохранение пароля восстановления
На следующей странице — «Зашифровать выбранный том» — можно указать, запускать ли проверку системы перед шифрованием. Проверка потребует перезагрузки, но это лучший способ убедиться, что TPM, BIOS и порты USB будут успешно использованы BitLocker. Если возникли проблемы, после перезагрузки будет отображено сообщение об ошибке. В противном случае появится строка состояния «Выполняется шифрование».
Вот и все Шифрование продолжит выполняться в фоновом режиме, а вы можете продолжать использовать свой компьютер. После завершения шифрования появляется соответствующее сообщение. Можно самостоятельно отслеживать текущее состояние шифрования, перемещая курсор на значок шифрования диска BitLocker в панели инструментов внизу экрана. Подробнее весь процесс описан в пошаговом руководстве, упомянутом выше.
Некоторых пользователей удивляет, что при запуске компьютера BitLocker не запрашивает ничего у пользователя и не вмешивается каким-либо иным заметным способом. Это происходит потому, что по умолчанию в проверке целостности системы до разблокировки диска BitLocker полагается на TPM. Это происходит автоматически и прозрачно для пользователя.
Можно настроить BitLocker на запрос ПИН-кода или требование ключа, сохраненного на флэш-накопителе USB. Эта конфигурация безопаснее и рекомендуется для ситуаций, когда плюсы от дополнительной защиты перевешивают неудобства введения ПИН-кода. В моем понимании, так дело обстоит всегда (другими словами, мой настольный компьютер требует ввода ПИН-кода, а переносной — ключа на накопителе USB.)

Восстановление BitLocker
Имея дело с шифрованием, особенно в деловой и корпоративной среде, следует обязательно обеспечить прошедшему проверку подлинности пользователю доступ к своим данным, даже если обычные методы доступа или ключи недоступны. В BitLocker это называется восстановлением.
Если происходят непредвиденные изменения в компонентах начальной загрузки, теряется загрузочный USB-ключ или пользователь забывает ПИН-код, BitLocker не сможет успешно завершить загрузку. Том будет оставлен заблокированным, и Windows не сможет запуститься. Вместо этого код BitLocker в диспетчере загрузки отобразит текстовый экран. Если пароль восстановления был сохранен на флэш-накопителе USB (иногда называемом ключом восстановления), появляется экран, подобный показанному на рис. 4.
Рис. 4 Поиск ключа восстановления
Рис. 4 Поиск ключа восстановления
Чтобы BitLocker смог прочитать флэш-накопитель USB, тот должен быть подключен с самого начала. Поэтому, если имеется этот накопитель с ключом, нужно вставить его и нажать ESC. Если ключа нет, нажмите ВВОД. Появится экран, показанный на рис. 5. Тот же экран появится, если ключ восстановления не сохранялся на флэш-накопителе USB.
Рис. 5 Ввод пароля BitLocker
Рис. 5 Ввод пароля BitLocker
Теперь BitLocker ожидает ввода 48-значного цифрового пароля, который разблокирует диск. Это число напечатано на странице, если была выбрана печать пароля восстановления, или хранится в файле, если был выбран этот вариант сохранения.
Простейший путь управления паролями восстановления в рамках предприятия — их автоматическое хранение в службах Active Directory®. Подробно об этом см. go.microsoft.com/fwlink/?LinkId=87067.
В следующей статье мы подробно остановимся на управляемости BitLocker, а пока достаточно сказать, что он поставляется с полноценным поставщиком WMI, который позволяет контролировать BitLocker (и TPM) через любую совместимую с WMI систему WBEM. Это, в частности, означает, что управлять BitLocker можно через сценарии на любом языке сценариев, способном получать доступ к объектам WMI, например VBScript и Windows PowerShell™.
Вместе с BitLocker также поставляется средство командной строки manage-bde.wsf, использующее провайдер WMI для управления BitLocker на локальном и удаленном компьютере. Для получения более подробной информации о нем запустите командную строку с повышенными привилегиями и введите manage-bde.wsf /?.

Безопасное списание
Каждый компьютер в конце концов приходится списывать. Обычно предприятия тратят значительные средства и усилия на то, чтобы диски таких компьютеров были предварительно полностью очищены. Большинство методов удаления секретных данных требуют значительного времени и денег или выливаются в полное уничтожение оборудования. Средство BitLocker предоставляет более эффективные решения.
Вместо фактического удаления данных BitLocker гарантирует, что секретные сведения не хранятся на диске небезопасным образом. Поскольку все содержимое диска зашифровано, данные можно считать навсегда утерянными, если уничтожены все копии ключей шифрования. Сам жесткий диск остается неповрежденным и может быть повторно использован.
Существует большое число подходов к списанию томов, защищенных BitLocker. Можно удалить все копии ключей из метаданных тома, оставив их копии в надежно защищенном центральном архиве. После этого можно без опаски перевозить компьютеры или временно списать, если им предстоит провести значительное время без работы. Это гарантирует, что авторизованные пользователи смогут получить доступ к данным, в то время как все остальные, например новые владельцы оборудования, — нет.
Можно удалить все копии ключей из метаданных тома и из всех архивов, таких как Active Directory (это можно сделать, например, созданием новых ключей, которые нигде не будут храниться). Без ключей расшифровки никто не сможет восстановить данные.
В любом из этих случаев удаление и уничтожение ключей, содержащихся в метаданных тома, производится практически мгновенно и может выполняться администратором на многих системах разом. На это требуется минимум сил и времени, а результат — очень высокая степень непрерывной защиты. Средство форматирования в Windows Vista было обновлено. Теперь команда format удаляет метаданные тома и перезаписывает их секторы для надежного удаления всех ключей BitLocker.

Несколько заключительных слов
BitLocker — мощное средство, разработанное для защиты от конкретных угроз, с чем оно прекрасно справляется. Но не стоит считать его панацеей. Совершенно необходимо продолжать использование остальных защитных и управляющих мер, например надежных паролей.
BitLocker предназначен для защиты от атак с отключением оборудования. Если Windows запущена, BitLocker разблокировал том. Иными словами, он не обеспечивает защиту работающей системы. В этом его дополняют такие технологии, как EFS и RMS.
Подробнее о BitLocker см. на веб-узле Майкрософт, начиная с technet.microsoft.com/windowsvista/aa905065.aspx. Подробнее о спецификациях TPM и TCG см. в разделе «TPM Specifications» веб-узла TCG по адресу go.microsoft.com/fwlink/?LinkId=72757.

Байрон Хайнз (Byron Hynes) работает в группе поддержки пользователей Windows Server в Майкрософт. До этого работал консультантом и инструктором. Связаться с ним можно по адресу bhynes@microsoft.com.


 Безопасность: Изучая брандмауэр Windows
Безопасность Стив Райли (Steve Riley)

Изучая брандмауэр Windows
Краткий обзор:
  • Входящая и исходящая защита
  • Платформа фильтрации Windows
  • Интерфейс повышенной безопасности
  • Сетевые профили

В давние времена, в палеокомпьютерную эру никто не задумывался об установке брандмауэра на каждый отдельный компьютер. Да и зачем? Тогда вряд ли кто-либо слышал об Интернете, никто не знал про TCP/IP, а маршруты протоколов локальный сетей не выходили за пределы здания или за территорию предприятия. Важные данные хранились на
мэйнфрейме или файловых серверах — информация, которую люди держали на своих настольных компьютерах, была не особо важной, а собственный вес компьютера обеспечивал немалую степень физической безопасности. Если имелось подключение к Интернету, использовалось несколько преобразователей протоколов и маршрутизатор с фильтрацией пакетов (я имею в виду “брандмауэр”) на границе сети, который, скорее всего, требовал настройки огромного числа правил и исключений.
Современные компьютерные среды значительно отличаются от таких древних. Всё вокруг подключено к Интернету (и использует протокол TCP/IP), а мобильные устройства — просто обыденность. Работодатель обеспечивает вас переносным компьютером не потому, что заботится о вас — он заботится о том, чтобы получить от вас больше пользы. Он хочет, чтобы вы работали всегда, когда у вас появится пять свободных минут и подключение по Wi-Fi. Переносные компьютеры стоят дороже, чем настольные, но это полностью окупается производительностью. Как вы понимаете, именно мобильность делает их столь привлекательными для вас и ваших конкурентов.
Зададимся таким вопросом: какой процент от общего количества времени, в течение которого ваш компьютер включен и подсоединен к какой-либо сети, составляет время подключения к вашей корпоративной сети? Если вы работаете в режиме, похожем на мой, то не больше 20 процентов. Это означает, что только 20 процентов времени мой переносной компьютер находится в безопасности в пределах корпоративной сети корпорации Майкрософт, защищенный от внешних атак механизмами демилитаризованной зоны.Но как же быть с теми 80 процентами времени, когда мой переносной компьютер с различными целями подключается напрямую к Интернету? (А я очень часто подключаюсь к самым опасным сетям в мире: к ЛВС отеля во время конференции по компьютерной безопасности!) Да и при подключении к корпоративной сети — как насчет угроз, исходящих от других компьютеров в этой среде?
Средства безопасности разрабатываются после, а иногда значительно позже, появления угроз. Вирусы были клиентской проблемой, потому что люди широко использовали дискеты, и поэтому первая антивирусная программа появилась на клиентском компьютере. Позже, когда с ростом популярности электронной почты вредоносные программы превратились в сетевых червей, которые распространялись по ней, программы защиты от вредоносного ПО также эволюционировали, и появились шлюзы электронной почты. С развитием Интернета к вредоносным программам добавились трояны, и вслед за этим антивирусное программное обеспечение переместилось на прокси-серверы доступа в Интернет. Это широко известный эволюционный путь, который никто не ставит под сомнение.
А теперь давайте применим ту же логику к брандмауэрам. Для защиты от компьютерных угроз вчерашнего дня брандмауэра на границе сети хватало. Теперь его недостаточно, потому что угрозы многочисленнее, сложнее и все быстрее распространяются. При этом мы еще не касаемся того, что оборудование и способы работы значительно отличаются от используемых в прошлом. Многие компьютеры содержат секретную информацию, хранимую локально, и они могут длительное время находиться далеко от корпоративной сети (то есть за границей сети). Поэтому брандмауэру суждено стать защитным механизмом каждого отдельного клиента. Для клиентов брандмауэры больше не являются необязательными. Не делайте этой ошибки: не пренебрегайте ими. Для защиты компьютера от вашей собственной корпоративной сети и от Интернета клиентские брандмауэры жизненно важны.

Клиентские брандмауэры и “театр безопасности”
Многие люди не знали о том, что первый выпуск Windows® XP содержал клиентский брандмауэр. Это и не удивительно, так как по умолчанию брандмауэр был выключен, а включить его можно было, сделав довольно много щелчков мышью. Брандмауэр просто появился, причем достаточно скрытно, при этом не настаивая на своем использовании и не давая руководств по применению. Но он действительно работал. Если бы вы включили этот брандмауэр, то он защитил бы вас от вирусов Nimda, Slammer, Blaster, Sasser, Zotob и любых других попыток передать непрошенный трафик через порт вашей сети. Понимания важность защиты клиента, разработчики пакета обновления 2 (SP2) для Windows XP включили брандмауэр по умолчанию, создали два профиля (Интернет и корпоративная сеть) и интегрировали его с групповыми политиками.
К сожалению, два фактора замедлили восприятие брандмауэра Windows XP SP2: проблемы с приложениями и “театр безопасности”. Многие боялись, что брандмауэр помешает правильной работе их приложений. Такое, однако, случалось нечасто, что объясняется принципом работы брандмауэра. Он позволял любому исходящему трафику покинуть компьютер, но при этом блокировал весь входящий трафик, который не являлся ответом на некоторый предыдущий исходящий запрос. Единственный случай, когда такая схема нарушала работу клиентского приложения, — если оно создавало прослушивающий сокет и ожидало получения входящих запросов. Брандмауэр Windows XP обеспечивал простые настройки исключений для программ или портов (но, к сожалению, не с помощью групповой политики).
Большим препятствием являлся “театр безопасности”, устраиваемый производителями других клиентских брандмауэров. Некоторые люди полагали, что принципа работы брандмауэра Windows XP, а именно разрешения исходящему трафику беспрепятственно покидать компьютер, для полнофункциональной работы клиентского брандмауэра недостаточно. Аргументом было то, что клиентский брандмауэр должен задерживать весь трафик, входящий и исходящий, до тех пор, пока пользователь не даст явного разрешения.
Давайте разберемся. Здесь возникают два сценария.
  • Если вы работаете с правами локального администратора, и ваш компьютер заражен вредоносной программой, то она просто отключит брандмауэр. Вы проиграли.
  • Если вы не работаете как локальный администратор, и ваш компьютер заразился вредоносной программой, то эта программа заставит брандмауэр стороннего производителя открыть диалоговое окно, которое содержит иностранный текст (там что-то про порты и IP-адреса) и задает очень серьезный вопрос: “Вы разрешаете это сделать?”. Единственным ответом, конечно, будет “Да, да, да, тупой компьютер, и прекрати меня доставать!” И как только этот диалог исчезнет с экрана, исчезнет и ваша безопасность. Или, что еще чаще случается, вредоносная программа просто внедрится в существующий сеанс программы, действия которой уже одобрены, и вы даже не увидите диалогового окна. Вы опять проиграли.
Существует важный постулат безопасности, который необходимо усвоить: защита относится к ресурсу, который вы хотите защитить, а не к тому, от чего вы защищаетесь. Правильный подход — это запустить простой, но эффективный брандмауэр Windows на каждом компьютере вашей организации для защиты каждого компьютера от других компьютеров по всему миру. Если вы пытаетесь заблокировать исходящие подключения от компьютера, безопасность которого уже нарушена, то как вы можете быть уверены, что компьютер делает то, что вы просите? Ответ прост: никак. Исходящая защита — это “театр безопасности”, это уловка, которая только создает впечатление улучшения безопасности, при этом не делая ничего для действительного ее улучшения. Вот почему исходящей защиты не было в брандмауэре Windows XP и вот почему ее нет и в брандмауэре Windows Vista™. (Далее я еще остановлюсь на управлении исходящим трафиком в Windows Vista.)

Что нового в Windows Vista?
Основой для брандмауэра Windows Vista является платформа фильтрации Windows, часть нового сетевого стека. Как и Windows XP, Windows Vista по умолчанию блокирует входящий трафик. В зависимости от того, какой профиль используется на компьютере, применяется несколько стандартных исключений для сетевых служб (о профилях я расскажу далее). При желании можно написать правила, разрешающие входящие подключения. Так же, как и Windows XP, Windows Vista по умолчанию пропускает весь исходящий трафик интерактивных процессов, но ограничивает исходящий трафик служб, который определен в ограничениях служб. И, опять же, можно написать правила для блокировки дополнительных исходящих подключений.
Серьезным отличием Windows Vista от Windows XP является новый интерфейс повышенной безопасности и полная поддержка групповых политик в области настроек и правил (см. рис. 1). Старая панель управления в интерфейсе пользователя осталась практически без изменений, только настройки журнала и протокола ICMP переместились в новый интерфейс. Этот новый интерфейс пользователя, оснастка MMC “Повышенная безопасность”, обеспечивает новые возможности и гибкость. Имеется также новый контекст netsh advfirewall в команде netsh, с помощью которого можно запускать сценарии добавления и удаления правил, настраивать и показывать глобальные и профильные политики и просматривать состояние активности брандмауэра. Для вас, разработчики: файлы FirewallAPI.dll и Netfw.h обеспечивают программное управление всеми параметрами брандмауэра.
Рис. 1 Брандмауэр Windows в режиме повышенной безопасности
Рис. 1 Брандмауэр Windows в режиме повышенной безопасности
Управление в оснастке MMC “Повышенная безопасность” осуществляется с помощью мастера. При создании правила вы можете выбрать один из четырех типов: для программы, для порта, предопределенное или пользовательское. Пояснения см. на рис. 2.
Figure 2 Четыре типа правил (Close Figure 2)

Тип | Назначение
Программа | Используется для разрешения или блокировки трафика определенной программы.
Порт | Используется для разрешения или блокировки трафика через определенный порт TCP или UDP.
Предопределенное | Использует ранее существовавшую группу правил для включения сетевых возможностей Windows (таких как общий доступ к файлам и принтерам или удаленный помощник).
Пользовательское | Предоставляет вам всю приборную панель, давая возможность настроить правило так, как вы хотите.
При написании правил можно использовать множество элементов — все они доступны для локальных правил и правил, применяемых с помощью групповой политики. В их число входят: учетные записи и группы пользователей и компьютеров службы Active Directory®, исходные и конечные IP-адреса, исходные и конечные порты TCP и UDP, номера протоколов IP, программы и службы, типы интерфейсов (проводной, беспроводной или удаленный доступ) и типы и коды ICMP.
Будучи настроенным, брандмауэр обрабатывает правила в следующем порядке.
Ограничения служб Некоторые службы в Windows Vista ограничивают себя для снижения вероятности новой атаки типа Blaster. Одно из ограничений — это список портов, которые необходимы данной службе. Брандмауэр следит за этим и запрещает использование (или указание использовать) данной службой другого порта.
Правила безопасности подключения Оснастка MMC “Повышенная безопасность” наряду с поддержкой брандмауэра отвечает и за работу протокола IPsec. Любые правила, которые включают политики IPsec, выполняются во вторую очередь.
Обход проверки подлинности Это позволяет определенным компьютерам, прошедшим проверку подлинности, обойти другие правила.
Блокирующие правила Эти правила явно блокируют определенный входящий и исходящий трафик.
Разрешающие правила Эти правила явно разрешают определенный входящий и исходящий трафик.
Правила брандмауэра хранятся в реестре, но где именно, я не скажу. Ну... ладно, вы найдете их здесь:
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Defaults\FirewallPolicy\FirewallRule
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules
  • HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
Но только не редактируйте эти правила прямо в реестре. Иначе мы найдем вас, выкрадем вашего домашнего любимца и продадим на eBay! Ну, может, до этого и не дойдет, но единственный поддерживаемый способ редактировать правила — это использовать MMC режима повышенной безопасности.

Сетевые профили
В Windows Vista определено три сетевых профиля: доменный, частный и общий. Если компьютер принадлежит домену, и вход в домен успешно выполнен, автоматически применяется профиль домена — самостоятельно сделать этот выбор вы не можете. Когда компьютер подключен к внутренней сети, в которой нет домена (например к домашней сети или сети в небольшом офисе), вы (или администратор) должны применить частный профиль. Наконец, когда компьютер подключен непосредственно к Интернету, следует применить общий профиль.
Как Windows Vista определяет, куда поместить ваш компьютер? Если происходит изменение сети (получен новый IP-адрес, обнаружен новый шлюз, применяемый по умолчанию, или получен новый интерфейс), служба сетевого расположения (NLA) выявляет это изменение. Она создает сетевой профиль, который включает информацию о существующих интерфейсах, о том, прошел ли компьютер проверку подлинности при подключении к контроллеру домена, MAC-адрес шлюза и т.д., и присваивает этому профилю GUID. Затем NLA уведомляет брандмауэр, и тот применяет соответствующую политику (для каждого из трех существующих профилей определена своя политика).
Если интерфейс новый и компьютер ранее с ним не сталкивался, а служба NLA не выбрала профиль домена, вы увидите диалоговое окно, в котором вас попросят указать тип сети, к которой вы подключаетесь. Как ни странно, вариантов три: домашняя, рабочая и публичная. Вы можете подумать, что “рабочая” означает профиль домена, но на самом деле это не одно и то же. Помните, что профиль домена вы не увидите, так как при подключении компьютера к домену служба NLA выбирает его автоматически. На самом деле оба варианта — “домашняя” и “рабочая” — относятся к частному профилю. Функционально они одинаковы — отличаются только значки. (Примечание. Чтобы выбрать частный профиль, вы должны быть локальным администратором или иметь возможность повысить права до локального администратора.) Как и следовало ожидать, “публичная” относится к общему профилю.
В Windows Vista сетевой профиль применяется ко всем интерфейсам компьютера. Вот краткое описание алгоритма дерева решений службы NLA.
  1. Исследовать все подключенные сети.
  2. Имеется ли интерфейс, подключенный к сети, определенной как публичная? Если да, настроить профиль компьютера как общий и выйти.
  3. Имеется ли интерфейс, подключенный к сети, определенной как частная? Если да, настроить профиль компьютера как частный и выйти.
  4. Все ли интерфейсы видят контроллер домена и выполнил ли компьютер успешный вход в него? Если да, настроить профиль компьютера как доменный и выйти.
  5. Иначе настроить профиль компьютера как общий.
Целью является выбор как можно более ограничивающего профиля. Однако здесь есть два очевидных побочных эффекта. Во-первых, если порт Ethernet вашего компьютера подключен к вашей корпоративной сети, а его адаптер беспроводной связи подключен к сети кафе Starbucks этажом ниже, компьютер выберет общий профиль, а не профиль домена. Во-вторых, если ваш компьютер подключен прямо к Интернету (в общем профиле) или подключен к вашей домашней ЛВС (в частном профиле), и вы устанавливаете VPN-подключение к корпоративной сети, ваш компьютер остается в общем или частном профиле.
Что это может означать? Политика брандмауэра для профиля домена включает правила для удаленной поддержки, удаленного администрирования, общего доступа к файлам и принтеру и т.д. Если вы используете эти правила, чтобы удаленно подключиться к клиенту, у вас ничего не получится, если клиент выбрал какой-либо другой профиль. Но не расстраивайтесь — можно написать правила брандмауэра, которые разрешают необходимые вам входящие подключения, а затем применить их только к VPN-подключениям.Теперь можно выполнять администрирование ваших клиентов с помощью VPN, даже если они не используют профиль домена.

Управление исходящими подключениями
Ранее я упоминал, что исходящая защита в клиентских брандмауэрах — не более чем “театр безопасности”. Однако один из видов управления исходящей защитой очень полезен: это административное управление определенными типами трафика, которые вы определенно не хотите разрешать. Брандмауэр Windows Vista уже делает это для ограничений служб. Он позволяет службе использовать необходимые ей порты и блокирует любые другие ее действия. Можно создать дополнительные правила, которые будут разрешать или блокировать определенный трафик в соответствии политикой безопасности вашей организации (см. рис. 3).
Рис. 3 Мастер создания правила для нового входящего подключения
Рис. 3 Мастер создания правила для нового входящего подключения
Скажем, вы вдруг захотели запретить пользователям работать с определенным клиентом мгновенной передачи сообщений. Вы можете создать правило (конечно, в групповой политике) для блокировки подключений этого клиента к регистрационным серверам.
Но на пути применения такого подхода есть практические ограничения. Например, Windows Live™ Messenger (который вы, возможно, все еще знаете как MSN® Messenger) имеет множество различных серверов, которые могут использоваться для входа, и их список постоянно меняется. Кроме того, если используемый по умолчанию порт 1863/tcp заблокирован, он переключится на порт 80/tcp. Правило для блокировки подключения Windows Live Messenger к регистрационным серверам будет слишком сложным и подверженным постоянным корректировкам. Я привел этот пример, чтобы проиллюстрировать, что административное управление исходящим трафиком может быть полезным, но оно не заменяет политик ограниченного использования программ, если необходимо соблюдать строгий контроль программного обеспечения, которое пользователям разрешено устанавливать и запускать.

Защитите свой компьютер
Демилитаризованной зоны больше нет. Теперь каждый компьютер должен следить за собственной безопасностью. Как программы защиты от вредоносного программного обеспечения были перенесены с клиентского компьютера на границу, так и брандмауэры должны быть перемещены с границы на клиентов. Вы можете сделать это мгновенно, включив брандмауэр, который у вас уже установлен.
Если вы работаете в операционной системе Windows XP или уже перешли на Windows Vista, брандмауэр Windows доступен всем вашим клиентам и обеспечит защиту, которая необходима для улучшения безопасности в пределах организации — даже если ваши мобильные сотрудники находятся за тысячи километров от офиса.
Дополнительные материалы
  • Технический центр Windows Vista TechCenter. Переходите к использованию брандмауэра Windows в режиме повышенной безопасности
  • Технический центр Windows Vista TechCenter. Брандмауэр Windows в режиме повышенной безопасности — диагностика и устранение неполадок
  • Презентация Стива Райли на TechEd Europe. Брандмауэр Windows Vista и улучшения IPSec
  • Кабельщик. Новый брандмауэр Windows в Windows Vista и Windows Server “Longhorn”
  • Виртуальная лаборатория брандмауэра Windows Vista

Стив Райли (Steve Riley), старший специалист по разработке стратегий безопасности в группе корпорации Майкрософт по вопросам надежного использования компьютерной техники и пишущий редактор журнала TechNet Magazine. Он постоянно летает по всему миру, выступая на конференциях и помогая заказчикам в обеспечении безопасности. Его последняя книга — Protect Your Windows Network (Защита сети Windows. Издательство Addison-Wesley, 2005 г.). С ним можно связаться по адресу steve.riley@microsoft.com.


 Безопасность: Повышение безопасности в ОС Windows Vista с помощью новых списков управления доступом (ACL)
Безопасность Джеспер Йохансон (Jesper Johansson)

Повышение безопасности в ОС Windows Vista с помощью новых списков управления доступом (ACL)
Краткий обзор:
  • Новые возможности списков ACL
  • Усиление контроля над администраторами
  • Разрешения для учетной записи Trusted Installer
  • Изменения в учетных записях пользователей и в группах

Принципиальная структура списков управления доступом в ОС Windows Vista не претерпела кардинальных изменений, но есть ряд небольших, но важных изменений, о которых необходимо иметь представление. Некоторые из этих изменений
необходимы из-за проблем со списками ACL, присущих ОС Windows® XP. Первая проблема состоит в том, что большинство пользователей в ОС Windows XP являются администраторами, то есть учетные записи этих пользователей являются членами встроенной группы «Администраторы». Эта проблема очень распространена среди домашних пользователей, потому что всем учетным записям, добавляемым во время установки системы, автоматически даются права администраторов. Таким образом, все программы, запускаемые этими пользователями, также выполняются с правами администраторов, что предоставляет этим программам полный доступ к операционной системе. В случае вредоносных программ эта проблема встает особенно остро.
Другая проблема, которая раздражает многих пользователей, заключается в том, что по умолчанию списки ACL включают в себя записи управления доступом (ACE) для встроенного участника безопасности «Все», членов группы «Опытные пользователи» и т.п. К примеру, список ACL корневой папки загрузочного раздела ОС Windows XP (обычно C:\) предоставляет права на чтение всем и права на создание папок членам группы «Пользователи». Помимо этого, в ОС Windows XP накладывается ряд ограничений на действия, которые можно совершать со списками ACL. К примеру, невозможно установить разрешения для текущего владельца объекта. Можно установить разрешения для владельца объекта, но они не переносятся в случае изменения текущего владельца. Также владельцы объектов неявным образом обладают правами на эти объекты независимо от установленных разрешений.
При разработке ОС Windows Vista™ в корпорации Майкрософт был развернут проект для решения многих из этих проблем и обеспечения поддержки других возможностей, таких как управление учетными записями пользователей (UAC). В этой статье внимание уделяется основным изменениям, связанным с управлением доступом в ОС Windows Vista. В следующем выпуске журнала, который выйдет через месяц, будет приведен обзор инструментов для настройки управления доступом.

Изменения в учетных записях пользователей и группах
Некоторые учетные записи пользователей и группы появились в ОС Windows Vista впервые, а некоторые учетные записи пользователей и группы, которые есть в ОС Windows XP, отсутствуют в ОС Windows Vista. Также была изменена функциональность некоторых учетных записей и групп. Каждое из изменений влияет на способ настройки управления доступом.
Учетная запись «Администратор» по умолчанию отключена Встроенная учетная запись «Администратор» с относительным идентификатором безопасности (RID) 500 по умолчанию в большинстве случаев теперь отключена. Изначально подразумевалось, что эта учетная запись будет использоваться только в крайних случаях. Она предназначалась для восстановления системы и данных в случаях, когда все остальные способы оказались безуспешны. Однако очень часто она используется в качестве обычной административной учетной записи, что нарушает несколько принципов безопасности. Самым главным из этих принципов является принцип отслеживания и определения ответственности. В случае использования упомянутой учетной записи невозможно отследить, кто именно совершал изменения в системе. Поэтому использование этой учетной записи не приветствовалось. Возможно, в дальнейшем в корпорации Майкрософт будет принято решение полностью отказаться от этой учетной записи, на сегодняшний же день ее сделали отключенной она по умолчанию. В случае если в группе «Администраторы» кроме этой учетной записи больше нет других членов, возможно использование идентификатора RID 500 в консоли восстановления и в безопасном режиме, но в остальных случаях его невозможно и не нужно использовать.
Обратите внимание, что встроенная учетная запись «Администратор» — это не то же самое, что учетная запись-член группы «Администраторы». Далее в тексте подразумевается, что «Администратор» (с заглавной буквы) — это учетная запись с идентификатором RID 500, а просто слово «администратор» — это любая другая учетная запись, которая является членом группы «Администраторы». Название группы «Администраторы» также будем писать с заглавной буквы.
В ОС Windows XP учетная запись «Администратор» обладает рядом особых прав, которыми не обладает никакая другая учетная запись с правами администратора. В ОС Windows Vista для этой учетной записи из всех этих прав оставлено только два. Во-первых, отключенная учетная запись «Администратор» может использоваться в консоли восстановления, в случае, если в системе больше нет других локальных администраторов. Во-вторых, на эту учетную запись не распространяются ограничения управления учетными записями (UAC), и поэтому она всегда обладает полными правами. Это относится и к учетной записи «Администратор домена» с идентификатором RID 500 в домене.
Ограничения прав группы «Опытные пользователи» Из практических соображений от группы «Опытные пользователи» было решено отказаться. Сама группа осталась, но было убрано большинство разрешений, которые назначались этой группе. Не секрет, что пользователь, который является членом группы «Опытные пользователи» является на самом деле администратором, который просто еще не установил себе соответствующие права. Однажды я продемонстрировал, как можно за 45 минут получить полный доступ к компьютеру под управлением системы Windows XP с пакетом обновления 2 и всеми необходимыми обновлениями путем предоставления своей учетной записи прав администратора. Это время потребовалось на оценку обстановки, написание небольшой программы на языке C++, выход из системы и затем повторный вход. Все это было возможно благодаря тому, что моя учетная запись была членом группы «Опытные пользователи».
Полностью убрать из системы эту группу было нельзя, потому что во многих организациях существует сложная система настроенных разрешений, в которой участвуют учетные записи-члены этой группы. Тем не мене, в последующих версиях ОС Windows планируется полностью отказаться от этой группы. Настоятельно рекомендуется уже сейчас начать планирование действий для постепенного отказа от использования группы «Опытные пользователи».
Учетная запись Trusted Installer Во многих местах в настройках разрешений файловой системы можно увидеть учетную запись Trusted Installer. На самом деле это служба, а не учетная запись. Безопасность служб была усилена, поэтому теперь каждая служба является полноценным участником безопасности, наравне с учетными записями пользователей. Описание этой возможности приводится в журнале TechNet Magazine в номере за январь 2007 г. В книге Граймса и Йохансона Безопасность ОС Windows Vista (издательство Wiley Press, 2007 г.) подробно описывается усиление безопасности служб, а также повышение эффективности этих служб за счет других возможностей, таких как брандмауэр и служба IPsec.
Идентификатор безопасности (SID) для служб теперь не назначается привычными администраторами безопасности, такими как NT AUTHORITY или администратор домена. Полное название виртуальной учетной записи для службы TrustedInstaller — «NT SERVICE\TrustedInstaller», а идентификатор безопасности (SID) этой записи
S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464
Идентификатор безопасности (SID) можно получить для любой, даже для несуществующей службы. Для этого нужно выполнить команду «sc showsid», как это показано на рис. 1.
Рисунок 1 Команда «sc showsid» выводит на экран идентификатор SID для любой, даже несуществующей службы
Рисунок 1 Команда «sc showsid» выводит на экран идентификатор SID для любой, даже несуществующей службы
Этот идентификатор безопасности (SID) начинается со строчки S-1-5-80. Октет 80 соответствует относительному идентификатору SECURIY_SERIVCE_ID_BASE_RID. Это означает, что идентификатор службы назначается администратором безопасности NT SERVICE. Это справедливо для любой службы. Остальная часть идентификатора и относительные идентификаторы RID зависят от имени службы. Это позволяет разработчику службы устанавливать для нее разрешения, даже если служба еще не была собрана и установлена. Идентификатор определяется именем службы и поэтому совпадает на различных компьютерах.
В консоли управления службами службе «TrustedInstaller» соответствует отображаемое имя «Установщик модулей Windows».
Учетные записи Центра справки и поддержки удалены Учетные записи «Support_xxxxxx» и «HelpAssistant» отсутствуют в системе Windows Vista при установке с нуля, однако при обновлении с предыдущей версии ОС Windows эти учетные записи сохраняются. Учетная запись «Support_xxxxxx» использовалась для запуска сценариев из Центра справки и поддержи. Некоторые поставщики OEM, которые поставляли свои собственные справочные системы, могли также добавлять в систему собственные учетные записи поддержки. Неясно, что произойдет с этими учетными записями, но, скорее всего, поставщики OEM просто перестанут их создавать. На самом деле, эти записи попросту больше не нужны. Более того, с точки зрения обеспечения безопасности неправильно, что пользователи могли запускать сценарии из центра справки с правами других учетных записей. Лучше, если таких учетных записей вообще не будет. В ОС Windows Vista есть другой способ выполнять эти задачи.
Учетная запись «HelpAssistant» использовалась во время сеансов работы с удаленным помощником. Так же как и центр справки и поддержки, удаленный помощник был переработан таким образом, чтобы для его работы не требовалась учетная запись «HelpAssistant», соответственно, эта запись была удалена.
Новые идентификаторы безопасности сетевого расположения В операционных системах на основе ядра Windows NT® всегда присутствовали идентификаторы безопасности (SID) сетевого расположения, такие как «NETWORK» и «INTERACTIVE». С их помощью можно было различать пользователей, выполнивших выход через сеть и интерактивно. Также в системах был идентификатор безопасности (SID) «REMOTE INTERACTIVE LOGON», который назначался пользователям, выполнившим вход через службу терминалов. На самом деле у пользователей службы терминалов в маркере безопасности есть оба идентификатора: «REMOTE INTERACTIVE LOGON» и «INTERACTIVE LOGON». В ОС Windows Vista помимо этих двух идентификаторов были добавлены еще два: «DIALUP» и «INTERNET». Смысл выделения пользователей, выполнивших вход через телефонное подключение, не совсем ясен, особенно учитывая тот факт, что все больше и больше пользователей предпочитают не использовать такие соединения в качестве единственного способа подключения к сети. Тем не менее, этот идентификатор присутствует. Идентификатор «INTERNET» очевидно предназначен для выделения пользователей, выполнивших вход из-за пределов локальной сети. Идентификатором «NETWORK», тем не менее, отмечаются любые пользователи, выполнившие вход через локальную сеть или через Интернет.
Идентификатор «OWNER RIGHTS» и права владельца Теперь в системе есть идентификатор безопасности (SID) «OWNER RIGHTS», который применяется к владельцу файла, который является им на момент обращения. Основное назначение этого идентификатора — ограничивать действия, которые может совершать с файлом сам владелец. По сравнению с правами владельца в системе Windows XP, в системе Windows Vista есть два существенных отличия. Во-первых, если запись ACE распространяется на владельца файла, то назначаемые этой записью права имеют приоритет перед фактом владения файлом. Это очень значительное изменение. Оно сильно повлияет на определенные аспекты администрирования системы, так как многие привыкли к тому, что владелец неявно обладает полными правами. Во-вторых, идентификатор безопасности (SID) «OWNER RIGHTS» может использоваться для ограничения действий, которые может совершать с объектом его владелец.
Представьте, что есть папка, владельцем которой является пользователь Jesper. Список ACL этой папки представлен на рис. 2. Пользователь Jesper обладает правами только на чтение, несмотря на то, что он является владельцем этой папки. Если он попытается скопировать файл в эту папку, возникнет ошибка, потому что у пользователя Jesper нет разрешений на запись в папку. Из сообщения об ошибке это понять не так просто. При попытке скопировать с помощью Проводника Windows® файл в папку, владельцем который пользователь является, но разрешениями на запись в которую он не обладает, произойдет следующее. Сначала Проводник сообщит, что необходимо расширить права для копирования файла, и попросит пользователя их расширить, но копирование файла не произойдет, так как прав на копирование объектов в эту папку у пользователя нет. Выдается сообщение об ошибке «У вас нет разрешений на выполнение этого действия», где есть кнопки для двух вариантов действий: «Повторить» (как будто это может помочь) и «Отмена». И все это несмотря на то, что пользователь является владельцем папки.
Рисунок 2 Доступ к папке есть только у учетной записи «Local System» и еще у одного пользователя
Рисунок 2 Доступ к папке есть только у учетной записи «Local System» и еще у одного пользователя
Если пользователь Jesper попытается изменить список ACL файла, ему будет предложено поднять уровень его маркера. Так как он является владельцем файла, он сможет это сделать. У владельца сохраняются неявные права на чтение и изменение списков ACL (права «READ_CONTROL» и «WRITE_DAC»), если только иное не задано с помощью записи ACE для идентификатора «OWNER RIGHTS».
Чтобы понять, как работает идентификатор SID «OWNER RIGHTS», добавим его к приведенному выше списку ACL. Теперь учетная запись имеет разрешения, показанные на рис. 3.
Рисунок 3 Добавление разрешений на доступ к папке для идентификатора безопасности «OWNER RIGHTS» изменяет разрешения для пользователя Jesper
Рисунок 3 Добавление разрешений на доступ к папке для идентификатора безопасности «OWNER RIGHTS» изменяет разрешения для пользователя Jesper
После установки таких разрешений пользователь Jesper может спокойно скопировать файл в папку, потому что он является владельцем папки и у него есть соответствующие права. Однако при попытке пользователя Jesper изменить список ACL папки возникнет ошибка. Запись ACE для идентификатора «OWNER RIGHTS» указывает, что у владельца есть только разрешения на изменение объекта. Разрешений на изменение списка управления доступом на уровне пользователей (DACL) у владельца нет. Таким образом, основное назначение идентификатора «OWNER RIGHTS» — избавиться от идентификатора маркера WRITE_DAC (то есть от возможности изменения владельцем дескриптора безопасности).
В случае смены администратором владельца объекта разрешение для идентификатора «OWNER RIGHTS» на нового владельца автоматически не переносятся. В данном случае запись ACE для этого идентификатора отключается за счет установки наследования при запрете применения этой записи к вложенным папкам и файлам. Другими словами, эта запись ACE не применяется ни к каким объектам. Это необходимо, чтобы администратор мог сохранить за собой возможность контроля над объектом. Чтобы запись ACE для идентификатора «OWNER RIGHTS» снова стала активной, необходимо, чтобы ее вручную активировал пользователь «Администратор». Для этого он должен указать для этой записи область применения: к данной папке, вложенным папкам, к папкам и файлам, в зависимости от необходимости.
Есть ряд задач, для решения которых полезно использовать идентификатор безопасности (SID) «OWNER RIGHTS». Например, у администратора может возникнуть необходимость разрешить пользователям создавать файлы и папки на файловом сервере, но запретить им редактировать списки ACL для этих папок. Также возможна ситуация, когда пользователи, которые ранее являлись членами некоторой группы и создали ряд объектов, впоследствии были по определенным соображениям удалены из этой группы. Необходимо ограничить возможность таких пользователей изменять параметры этих ранее созданных ими объектов.
Также идентификатор «OWNER RIGHTS» очень успешно применяется для повышения безопасности служб. Когда служба создает временный объект во время запуска, идентификатором владельца этого объекта является основной идентификатор безопасности (SID) процесса службы, обычно это «LocalSystem», «NetworkService» или «LocalService», а не идентификатор безопасности самой службы. Это означает, что любая другая служба, запущенная в том же контексте процесса, может изменить этот объект. Такая возможность крайне нежелательна. Задавая для этого объекта разрешения для идентификатора безопасности (SID) «OWNER RIGHTS» система может ограничить доступ остальным службам к этому объекту.

Списки ACL по умолчанию
Списки ACL, которые устанавливаются по умолчанию в системе Windows XP, хорошо продуманы, если не принимать во внимание мелкие недочеты, такие, как разрешение пользователям создавать файлы в корневой папке загрузочного раздела. Тем не менее, некоторые поставщики OEM считали, что они лучше знают, как обеспечить достаточный уровень безопасность. На рис. 4 показано изображение списка ACL для папки «Windows» на компьютере от одного очень известного поставщика OEM. Компьютер работает под управлением системы Windows XP Media Center Edition. По сути, безопасность файловой системы этим поставщиком OEM была отключена.
Рисунок 4 Список ACL, настроенный поставщиком OEM
Рисунок 4 Список ACL, настроенный поставщиком OEM
В ОС Windows Vista списки ACL претерпели ряд изменений. В ОС Windows XP привычным является тот факт, что владельцем всех файлов операционной системы является группа «Администраторы», таким образом, у всех членов этой группы есть полный доступ к этим файлам. В системе Windows Vista это не так.
Учетная запись Trusted Installer В ОС Windows Vista владельцем большинства системных файлов является идентификатор безопасности (SID) «TrustedInstaller», и только у этого идентификатора есть полный доступ к этим файлам. Эта мера является частью комплекса мер, принятых в ОС Windows Vista для обеспечения целостности системы. Она препятствует процессам, запущенным с правами администратора или учетной записи «Local System», автоматически изменять эти файлы. Чтобы удалить системный файл, необходимо стать владельцем этого файла, а затем добавить запись ACE, позволяющую удалить его. Такой подход предоставляет некоторую степень защиты от процессов, запущенных с правами учетной записи «LocalSystem» с системной меткой целостности. Процессы с более низкой целостностью не могут повысить свои права для изменения владельца объекта. Некоторым службам можно установить средний уровень целостности, несмотря на то, что они запущены с правами учетной записи «Local System». Такие службы не смогут заменить системные файлы, поэтому в случае атаки и захвата управления этой службой, атакующая программа также не сможет заменить системные файлы, поэтому вредоносным программам (в том числе скрытым) будет сложнее установить себя в систему. Также администраторы больше не смогут удалить системные файлы, которые они по каким-то своим соображениям считают ненужными.
Записи ACE на запрещение Некоторых администраторов шокирует тот факт, что теперь в файловой системе у многих объектов присутствует запрещающая запись ACE «для всех». Если разрешить отображение скрытых файлов, можно увидеть папку «Documents and Settings», но при попытке зайти в эту папку возникнет ошибка «Доступ запрещен». Чтобы понять, почему так происходит, взгляните на структуру папки на рис. 5.
Рисунок 5 «Documents and Settings» является точкой соединения, а не папкой
Рисунок 5 «Documents and Settings» является точкой соединения, а не папкой
На самом деле «Documents and Settings» — совсем не папка. Это точка соединения. Точки соединения очень схожи с символическими ссылками, которые просто перенаправляют доступ в другое место файловой системы. В данном случае эта точка соединения указывает на папку C:\Users. В ОС Windows Vista было изменено пространство имен файловой системы, и данные пользователей были перенесены в папку C:\Users. Элементы пространства имен «C:\Documents and Settings\<Имя пользователя>» также были перенесены. Например, содержимое папки «C:\Documents and Settings\<Имя пользователя>\Application Data» теперь располагается в папке «C:\Users\<Имя пользователя>\appdata\roaming». Все изменения можно легко увидеть, если в командной строке выполнить команду «dir /s». Результат работы этой команды показан на рис. 5. Такие значительные изменения в пространство имен были внесены, чтобы обеспечить более наглядное представление для пользователей и более четко отделить документы от данных. Вместо того чтобы хранить все данные приложений внутри папки «Мои документы», разработчики могут создавать собственные папки внутри папки профиля пользователя, и пользователь легко сможет обнаружить там эти папки. Данные приложений, общие для всех пользователей, теперь располагаются в скрытой папке «%systemroot%\ProgramData», а не в папке «Documents and Settings\All Users\Application Data».
Папка «C:\Documents and Settings» была оставлена для обратной совместимости с приложениями, в которых жестко запрограммировано использование этого имени папки, вместо рекомендуемых к использованию переменных среды. Если бы папки «C:\Documents and Settings» не стало, работа таких приложений была бы нарушена. Поэтому эта и другие папки теперь представлены в виде точек соединения или символических ссылок. Работа приложений, в которых эти пути заданы явным образом, все же может быть нарушена. Это зависит от способа доступа к данным в этих папках. Но такие приложения и так некорректно работают на компьютерах с локализованными версиями ОС Windows. В данном случае ключевым моментом являются именно ошибки в приложении. Если после обновления ОС Windows, например, после установки пакета обновлений 2 для ОС Windows XP или обновление системы до ОС Windows Vista, перестают работать приложения сторонних разработчиков, в большинстве случае это происходит из-за неверных предположений, которые были сделаны разработчиками этих приложений, или из-за некорректного использования некоторых возможностей системы.
При попытке открыть файл путем ввода в строке адреса пути «C:\Documents and Settings\<Имя пользователя>\Мои документы\файл.txt» файл откроется без проблем, при условии, конечно, что он такой файл в этой папке есть. Тем не менее, при попытке открыть саму папку «C:\Documents and Settings\<Имя пользователя>\Мои документы» возникнет ошибка «Доступ запрещен». Чтобы понять, почему так происходит, взгляните на список ACL на рис. 6.
Рисунок 6 Запись ACE на запрещение в папке «Documents and Settings»
Рисунок 6 Запись ACE на запрещение в папке «Documents and Settings»
Взгляните на первую запись ACE в списке. Эта запись, запрещающая для всех получение перечня содержимого папки. Программы могут получить доступ к файлам по полному пути, потому что установлено разрешение для всех на обход перекрестной проверки (известное также под названием «SeChangeNotifyPrivilege»). Попытки же получить список содержимого папки будут приводить к ошибке из-за запрещающей записи ACE. Это и есть причина, по которой нельзя увидеть, что же находится внутри папки «C:\Documents and Settings» или удалить эту «папку». Благодаря запрещающим записям ACE пользователи не могут удалить точку соединения и нарушить работу старых приложений. Также эти записи служат напоминанием для разработчиков о необходимости отказа от использования старого пространства имен и перехода к использованию переменных среды или строковых параметров реестра, чтобы уберечь приложения от последствий из-за внесения изменений в будущем или из-за языковых различий.
Эти точки соединения по умолчанию являются скрытыми, поэтому большинство пользователей их никогда не увидит. Если же все-таки пользователь увидит эти точки соединения, он не сможет их удалить благодаря запрещающим записям ACE.
Пропуск перекрестной проверки Пользователи могут получить доступ к файлам, на доступ к которым у них есть права, несмотря на то, что эти файлы находятся в папках, доступ к которым запрещен для этих пользователей. Причина этого заключается в том, что в системе установлено разрешение для всех на пропуск перекрестной проверки. Это разрешение (известное также под названием «SeChangeNotifyPrivilege») на самом деле является самым основным разрешением в системе Windows. Оно назначается процессу, у которого удалены все другие разрешения, пока этот процесс специально не запросит убрать и это разрешение. Если в ОС Windows Vista запустить процесс с помощью команды «runas /trustlevel:0x10000 <», то программа, указанная в параметре <команда> будет запущена с ограниченным маркером безопасности. Из этого маркера будут изъяты все разрешения, кроме разрешения «SeChangeNotifyPrivilege».
Для справки: при запуске процесса со значением параметра «trustlevel» 0x20000 в маркере безопасности будет присутствовать обычный набор идентификаторов безопасности (SID), но будут отсутствовать разрешения. Значение 0x40000 соответствует обычному маркеру.

Разрешения по умолчанию
В ОС Windows Vista разрешения по умолчанию для файловой системы несколько отличаются от разрешений в ОС Windows XP. Списки ACL для папок «%systemdrive%» (обычно значение этой переменной соответствует загрузочному разделу C:\) в ОС Windows XP или Windows Server® 2003 выглядят так (или для ранних версий Windows XP почти так):
D:AR
(A;OICI;FA;;;BA)
(A;OICIIO;FA;;;CO)
(A;;0x1200a9;;;WD)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;CI;0x100004;;;BU)
(A;CIIO;0x100002;;;BU)
Ниже приведен список ACL для той же папки в ОС Windows Vista:
D:PAI
(A;;FA;;;BA)
(A;OICIIO;GA;;;BA)
(A;;FA;;;SY)
(A;OICIIO;GA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)
Между этими двумя списками есть ряд различий, которые стоит отметить. Во-первых, встроенной группе «BA» («BUILTIN\Администраторы») в списке соответствуют две записи, а не одна. При этом результирующие права, которые получает учетная запись, в обоих случаях одинаковы. В ОС Windows Vista одна запись ACE предоставляет полный доступ к корневой папке и не распространяется на вложенные объекты, а другая запись распространяется только на вложенные папки и файлы и предоставляет все встроенные права («GA» или, иначе, «полный доступ»). То же самое относится и к записям ACE для участника безопасности «SY» («LocalSystem»). В ОС Windows XP одна запись ACE предоставляла полный доступ как непосредственно к корневой папке, так и вложенным папкам и файлам. Результирующие разрешения в первом и во втором случае совпадают. Разделение на две записи было сделано для упрощения управления, а также на случай необходимости восстановления списка ACL.
Интересное отличие заключается в отсутствии в варианте для системы Windows Vista записи ACE для участника безопасности «CO» («Создатель-владелец»). Это означает, что теперь при создании пользователем объекта в корневой папке файловой системы этому объекту не будут назначаться специальные разрешения для его создателя.
Также видно, что отсутствует запись ACE для участника безопасности «WD» («Все»). Многих пользователей, которые интересовались вопросами безопасности, волновал вопрос присутствия этой записи ACE, несмотря на то, что они не всегда осознавали последствия совершаемых ими действий. Сотрудники корпорации Майкрософт безуспешно пытались в течение нескольких лет объяснить, что участник безопасности «Все» и встроенная группа «Пользователи» функционально идентичны. В конце концов, они отчаялись и просто убрали эту запись из списка. Благодаря наличию идентичной записи ACE для встроенной группы «BU» («BUILTIN\Пользователи»), которая также наследуется вложенными папками и файлами, в итоге удаление этой записи не вызвало никаких изменений.
Помимо этого, две из записей ACE для группы «BU» были заменены на записи ACE для участника безопасности «AU» («Прошедшие проверку»). Причина для этого заключается в том, что учетная запись «Гость» является членом встроенной группы «Пользователи» (благодаря членству встроенного участника безопасности «ИНТЕРАКТИВНЫЕ» в группе «Пользователи»), но не является членом участника безопасности «Прошедшие проверку». Чтобы у пользователя «Гость» были права на чтение и выполнение файлов, запись ACE с номером 0x1200a9 («Чтение и выполнение») по-прежнему назначается для группы «BU». Записи ACE, которые разрешают создавать файлы и папки, относятся теперь только к пользователям, прошедшим проверку. Это постепенный переход от системы Windows XP к системе Windows Vista. В отличие от ОС Windows XP, в ОС Windows Vista пользователь «Гость» не может создавать файлы в корневой папке. Не следует забывать, что на практике такое ограничение редко требовалось. Чтобы создавать файлы в корневой папке, необходимо включить учетную запись «Гость» и получить доступ к корню загрузочного раздела. По умолчанию учетная запись «Гость» отключена.
Напоследок предлагается обратить внимание еще на две примечательные записи ACE. В ОС Windows XP есть запись ACE, наследуемая вложенными папками, устанавливающая разрешение 0x100004 для встроенной группы «Пользователи». Эта запись позволяет пользователям создавать вложенные папки, в них еще вложенные папки, и так далее. Также есть запись ACE 0x100002 только для наследования, которая распространяется на вложенные папки. Эта учетная запись позволяет пользователям создавать файлы и вложенные папки в папках, которые они создали в корневой папке. Другими словами, в совокупности эти две записи ACE позволяют пользователям, в том числе и пользователю «Гость», создавать файлы и папки в корневой папке.
В ОС Windows Vista в списке ACL есть соответствующие записи ACE: запись ACE только для наследования, которая распространяются на вложенные контейнеры и файлы и предоставляют права на чтение («GR»), запись («GW»), выполнение («GX») и на чтение дескриптора безопасности («SD»), а также запись ACE, которая применяется только к корневой папке и предоставляет разрешение «LC». Аббревиатура «LC» на самом деле относится к разрешениям для службы Active Directory®. В службе Active Directory это разрешение позволяет пользователю получить список дочерних объектов контейнера. Шестнадцатеричное значение этого разрешения 0x4. Для папки такое значение соответствует разрешению «FILE_ADD_SUBDIRECTORY». Это разрешение функционально эквивалентно разрешению со значением 0x100004, потому что в списке ACL уже есть запись ACE 0x1200a9, в котором установлен флаг 0x100000 (обозначает возможность использования объекта для синхронизации). Другими словами, в сумме эти разрешения обладают таким же эффектом, что и разрешения в ОС Windows XP — пользователи могут создавать вложенные папки в корневой папке.
Можно легко заметить, что в записях ACE сплошь и рядом присутствуют шестнадцатеричные числа, например, 0x1200a9. На самом деле эти значения являются битовыми масками, соответствующими установленным флагам доступа для конкретных записей ACE. Такие программы, как «icacls», «sc» или «scedit» при выводе записей из списка ACL вместо чисел отображают понятные текстовые названия для разрешений, если такие соответствия имен значениям разрешений существуют.
Чтобы определить, что обозначает разрешение LC, достаточно посетить веб-узел MSDN®, найти на странице строчку «LC», и посмотреть на значение, которое соответствует этой записи в колонке «Право доступа». Для разрешения «LC» там будет значение «ADS_RIGHT_ACTRL_DS_LIST». В файле «Iads.h» можно найти, что этой строчке соответствует численное значение 0x4. В этом файле находятся значения для разрешений, которые относятся к службе Active Directory (содержат префикс «ADS_RIGHT»). Остальные разрешения и соответствующие им шестнадцатеричные значения расположены в файле «AccCtrl.h». Узнав шестнадцатеричное значение, можно легко найти соответствующую маску доступа в файлах «WinNT.h» или «AccCtrl.h», чтобы узнать, что именно обозначает эта маска.
Более подробную информацию можно получить из книги Джеспера Йохансона и Стива Райли (Steve Riley) «Защита сети под управлением Windows» (издательство «Addison-Wesley», 2005 г.). В 17-й главе этой книги подробно описывается, как анализировать строчки на языке описания дескрипторов безопасности (SDDL) и записи ACE.
Разрешения, назначаемые вложенным папкам, создаваемым в корневой папке, в ОС Windows Vista определяются исключительно записью ACE (A;OICIIO;SDGXGWGR;;;AU). Это является самым большим различием между записями в списке ACL корневой папки в ОС Windows Vista и Windows XP. Вместо разрешения полного доступа создателю вложенных папок, как это было в ОС Windows XP, в Windows Vista изменение этих папок разрешается пользователям, прошедшим проверку.
В итоге получается, что в новом списке ACL у создателя объекта больше нет каких-либо специальных прав на этот объект, благодаря чему ситуация с правами становится более понятной. С другой стороны, теперь у пользователей, прошедших проверку, есть права на изменение даже тех вложенных папок, которые были созданы администраторами. Это очень существенное отличие от ОС Windows XP. В системе Windows XP члены группы «Пользователи» и пользователи, прошедшие проверку, не обладали правами на доступ к объектам, созданным в корневой папке администраторами. Несмотря на то, что на первый взгляд новые записи ACE кажутся странными и неправильными, их конечный эффект практически не отличается от записей в системе Windows XP.
Если подвести итог, в ОС Windows Vista все пользователи, включая пользователя «Гость», обладают правами на чтение и исполнение в корневой папке. Правами на создание новых файлов и папок обладают только пользователи, прошедшие проверку. При этом они обладают не полными правами на созданные этими пользователями папки и файлы, а только правами на изменение. Другими словами, разрешения в ОС Windows Vista лишь слегка ограничивают доступ по сравнению с системой Windows XP. Смысла в отключении учетной записи «Гость» больше нет.

Изменения в маркерах безопасности
Когда в ОС Windows XP вход выполняется пользователем, который является членом группы «Администраторы», маркер безопасности этого пользователя содержит идентификатор SID группы «Администраторы». Такой пользователь обладает всеми правами группы «Администраторы». В ОС Windows Vista это больше не так благодаря системе управления учетными записями пользователей. Идентификатор SID группы «Администраторы» по прежнему присутствует в маркере безопасности пользователя, но у этого идентификатора установлен режим «только запрет», как это показано на снимке экрана программы Process Explorer на рис. 7.
Рисунок 7 Система UAC до повышения полномочий устанавливает для идентификатора SID «Администраторы» режим «только запрет»
Рисунок 7 Система UAC до повышения полномочий устанавливает для идентификатора SID «Администраторы» режим «только запрет»
При осуществлении управления доступом этот идентификатор SID в маркере используется только для отказа в доступе, другими словами, он сопоставляется только запрещающим записям ACE. Любые разрешающие записи ACE для этого идентификатора SID игнорируются. Это означает, что пользователь не является на протяжении всего времени полноценным администратором, даже, несмотря на то, что он выполнил вход в систему как администратор.

Уровни целостности
Теперь в системе Windows поддерживается такой параметр процессов и объектов, как «уровень целостности». Уровни целостности также представляются в виде записей ACE, но не на пользовательском уровне управления доступом (DACL). Эти записи относятся к системному списку управления доступом (SACL) и обладают дополнительными специальными полями. Например, флаг «NW» указывает, что процесс с более низким уровнем целостности не может изменять объект с более высоким уровнем целостности (разрешение «SDDL_NO_WRITE_UP»). В статье Марка Руссиновича (Mark Russinovich) «Внутренне устройство управления учетными записями пользователей в системе Windows Vista» этого выпуска журнала TechNet Magazine приводится подробное описание работы уровней целостности.

Заключение
Несмотря на то, что таких революционных изменений в управлении доступом, которые были сделаны с выходом ОС Windows 2000, в ОС Windows Vista не произошло, в ней было сделано много небольших изменений. Каждое изменение в отдельности кажется незначительным, но в сумме все эти изменения заставляют пересмотреть многие принципы управления системой. Также есть ряд нововведений, к которым относятся, прежде всего, управление учетными записями пользователей и усиление безопасности служб. Некоторые администраторы могут быть очень разочарованы первым опытом работы с ОС Windows Vista. Встречались комментарии о том, что ОС Windows Vista является «тиранической» и не позволяет удалять некоторые элементы операционной системы, которые по той или иной причине раздражают администраторов. Тем не менее, есть очень веские причины для всех этих изменений, и если затратить некоторые время на их анализ, можно осознать необходимость этих изменений.

Джеспер Йохансон (Jesper Johansson) — архитектор безопасности в большой компании, занимающейся продажами через Интернет. В его обязанности входит разработка стратегии безопасности, охватывающей большой перечень различных служб и параметров. Он работает в этой области уже 20 лет и написал множество статей и две книги о компьютерной безопасности. В свободное от основной деятельности время он работает инструктором подводного плавания.


 Безопасность: Ограничение использования оборудования через групповые политики
Безопасность Джереми Московитц (Jeremy Moskowitz)

Ограничение использования оборудования через групповые политики
Краткий обзор:
  • Ограничение установки оборудования
  • Ограничение отдельных устройств
  • Ограничение классов устройств

Действительно — эти удобные USB-диски и съемные носители определенно делают повседневную жизнь проще, а профессиональную усложняют. Необходим способ контроля, позволяющий определить,
какие устройства можно использовать, а какие нельзя. К счастью, групповые политики в ОС Windows Vista™ и следующей версии сервера Windows Server® под кодовым именем «Longhorn» позволяют разрешить применение USB-мышей и одновременно запретить USB-накопители флэш-памяти; разрешить чтение CD-ROM, но запретить запись DVD; разрешить Bluetooth и запретить PCMCIA.
Управлением оборудованием заведуют два раздела групповой политики: Конфигурация компьютера — Административные шаблоны — Система — Доступ к съемным запоминающим устройствам (рис. 1) и Конфигурация компьютера — Административные шаблоны — Система — Установка устройств — Ограничения на установку устройств (рис. 2).
Рис. 1 Предопределенные ограничения использования оборудования в групповых политиках
Рис. 1 Предопределенные ограничения использования оборудования в групповых политиках
Рис. 2 Настройка ограничения использования отдельных видов устройств
Рис. 2 Настройка ограничения использования отдельных видов устройств
Название первого набора — доступ к съемным запоминающим устройствам — говорит само за себя. Если включить эту политику для некоего вида съемных устройств (CD или DVD, дискеты и т.п.), можно ограничить операции чтения или записи для всего класса устройств. Но у этих политик нет богатства возможностей набора «Ограничения на установку устройств».
В «Доступе к съемным запоминающим устройствам» есть такие группы настроек политики: «Специальные классы: запретить чтение» и «Специальные классы: запретить запись». Выглядит полезно, но политика доступа к съемным устройствам не может предотвратить установку драйверов устройств — к моменту обнаружения оборудования драйвер уже установлен. Запрещается только чтение с устройства или запись на него. В следующем разделе, рассматривая настройки политики «Ограничения на установку устройств», мы увидим, как ограничить использование и драйвера тоже.

Классы и идентификаторы
Самое главное — знать, что именно нужно ограничить. Ограничить широко или ограничить точечно. Можно внести ограничения в целый «класс» из многих устройств, а можно наложить сверхточный запрет только на одно из них. А можно наоборот, разрешить только отдельные устройства, например USB-мыши. Но есть проблема: ограничиваемое оборудование нужно уметь распознавать.
Так что, сказав «Устанавливать драйверы джойстиков нельзя» и «А можно только USB-мыши», следует уметь определять, что начинается установка джойстика или USB-мыши. Можно использовать Интернет для поиска кода устройства (Hardware ID), совместимого кода (Compatible ID) или класса устройства. А можно просто использовать само устройство — подключить его к компьютеру и посмотреть его код, совместимый код и класс. Зная их, запретить или разрешить устройство нетрудно.
Давайте, для примера, ограничим использование семейства звуковых карт Creative AutoPCI ES1371/ES1373. Если нужно запретить что-то другое (конкретные USB-устройства, USB-порты и т.п.), делайте все то же, только заменив коды устройств на свои.
Запустим диспетчер устройств на машине, где искомое оборудование уже установлено. Найдя в нем нужное устройство, щелкаем его правой кнопкой мыши и выбираем пункт «Свойства» а затем вкладку «Сведения». По умолчанию выбран пункт «Описание устройства». Интересно, но не полезно. В раскрывающемся списке свойств выберем пункт «Коды (ID) оборудования» (рис. 3).
Рис. 3 Вкладка «Сведения»
Рис. 3 Вкладка «Сведения»
Появившийся список кодов упорядочен от наиболее точно соответствующих устройству до наименее точно соответствующих. На первой строчке можно увидеть, что конкретно эта звуковая карта — ревизия 2 модели ES1371. Точнее некуда. При движении по списку вниз коды будут все менее точными, вплоть до охватывающих все семейство продуктов.
Но можно еще выбрать пункт «Совместимые коды (ID)». Они тоже описывают устройство, хотя и менее точно, чем предыдущие. С помощью совместимых кодов можно составить список похожего оборудования и запретить его разом — поскольку точность ниже, совпадений будет больше. С другой стороны, так под запретом может оказаться что-то нужное.
Ну и, наконец, наименее точная категория — пункт «Класс устройства». В случае с нашей звуковой картой это просто «Media». Таким классом обладает масса устройств, так что, повторюсь, чем менее точно вы определяете запрет, тем более предусмотрительным следует быть.
Выбрав, какое значение использовать для указания устройства, щелкнем его правой кнопкой мыши, выберем «Копировать» и сохраним текст в блокноте. Это нужно сделать потому, что на следующих шагах значение потребуется вводить в точности так, как оно представлено. Все буквы верхнего регистра должны остаться в верхнем, а нижнего — в нижнем.
Если для извлечения кодов и классов устройств вам удобнее командная строка, используйте программу Devcon, доступную на узле support.microsoft.com/kb/311272. Обратите также внимание, что корпорация Майкрософт опубликовала список идентификаторов для распространенных классов, который можно использовать, если нет доступа к самому устройству. См. go.microsoft.com/fwlink/?LinkId=52665.

Контроль доступа к устройствам через групповые политики
Хотя дальше мы рассмотрим все настройки политик раздела Конфигурация компьютера — Административные шаблоны — Система — Установка устройств — Ограничения на установку устройств, показанного на рис. 2, только одна из них нужна для завершения нашего первого примера.
Создадим объект групповой политики (GPO) и свяжем его с подразделением (OU) или с доменом и т.д., который включает целевые компьютеры под управлением Windows Vista. Начав редактирование этого объекта, пройдем в «Конфигурация компьютера — Административные шаблоны — Система — Установка устройств — Ограничения на установку устройств — Запретить установку устройств с указанными кодами устройств». В настройках политики выберем «Включено», там же нажмем «Показать» и диалоговом окне «Вывод содержания» нажмем «Добавить». В диалоговое окно «Добавление элемента» скопируем ранее сохраненные данные (рис. 4).
Рис. 4 Вставка точного кода устройства
Рис. 4 Вставка точного кода устройства
Еще момент. Если устройство уже установлено, оно не будет чудесным образом удалено и запрещено. Так что ограничивать доступ к оборудованию нужно на ранних стадиях развертывания Windows Vista. Однако при этом Windows Vista будет проверять политику доступа при каждом удалении и повторной установке устройства. Отличный пример — USB-накопители (их регулярно вставляют и вытаскивают). Поскольку проверка будет произведена только при повторном появлении устройства, ограничения доступа будут наложены тогда же (даже если драйвер устройства на компьютере уже присутствует). Сложнее с устройствами, которые поставляются вместе с компьютером и не удаляются (а потому и не устанавливаются повторно). Выход из подобной ситуации уже требует размышлений.
При включении компьютера, который еще ничего не знает об устанавливаемом устройстве, Windows попытается установить драйвер и будет отображать ход выполнения этой задачи. Если включена политика, ограничивающая такие устройства, будет достигнут результат, показанный на рис. 5.
Рис. 5 Отказ в установке устройства
Рис. 5 Отказ в установке устройства

Другие ограничения оборудования
Выше мы запретили только одно устройство. Если бы мы хотели, мы бы могли пойти обратным путем — по умолчанию запретить все устройства и затем разрешить только нужные. Список нужных настроек групповых политик уже был приведен на рис. 2 — это ветка Конфигурация компьютера — Административные шаблоны — Система — Установка устройств — Ограничения на установку устройств. Доступно несколько вариантов.
Прежде всего это пункт «Разрешить администраторам игнорировать политики ограничения установки устройств». По умолчанию локальные администраторы в Windows Vista подпадают под действие таких ограничений. Если же включить эту политику, они смогут не обращать внимания на ограничения и устанавливать любое оборудование.
Затем — «Разрешить установку устройств с использованием драйверов, соответствующих этим классам установки устройств». Устройства, чьи описания перечислены в этой политике, явно разрешены к установке в системе. Обратите внимание, что вводятся классы установки, а не коды устройств, как в примере выше.
Обратный эффект достигается политикой «Запретить установку устройств с использованием драйверов, соответствующих этим классам установки устройств».
Две настройки — «Отображать специальное сообщение, когда установка запрещена политикой (текст всплывающего уведомления)» и «Отображать специальное сообщение, когда установка запрещена политикой (заголовок всплывающего сообщения)» — позволяют использовать собственное сообщение вместо системного (рис. 5).
Как было упомянуто выше, самый неточный способ указать нужное оборудование — использование классов. Следует отметить, что политика «Разрешить установку устройств, соответствующих какому-либо из этих кодов устройств» не воспринимает коды классов. Чтобы использовать их, надо обратиться либо к политике «Разрешить установку устройств с использованием драйверов, соответствующих этим классам установки устройств», либо к обратной «Запретить установку устройств с использованием драйверов, соответствующих этим классам установки устройств». Последнюю лучше всего использовать вместе с «Запретить установку устройств, не описанных другими параметрами политики». Запретив все по умолчанию, мы используем эту настройку, чтобы выборочно разрешить нужные устройства.
В нашем случае я использовал политику «Запретить установку устройств с указанными кодами устройств», чтобы запретить отдельные виды оборудования, основываясь на кодах устройств. Если бы мы хотели использовать для этой цели классы устройств, пришлось бы уточнять другие параметры, например «Разрешить установку устройств с использованием драйверов, соответствующих этим классам установки устройств» или «Запретить установку устройств с использованием драйверов, соответствующих этим классам установки устройств».
«Запретить установку съемных устройств» — готовый способ быстрого запрещения любых устройств, являющихся съемными, включая USB-устройства. Эта настройка имеет довольно общий характер, так что лучше не полагаться на нее слишком сильно. Вместо этого составьте список достаточно ограничивающих кодов устройств и используйте способы, описанные выше, для их запрещения.
Наконец, «Запретить установку устройств, не описанных другими параметрами политики» — всеобъемлющая политика, запрещающая все, что не разрешено к установке явно. Ее связка с различными разрешающими политиками (например «Разрешить установку устройств, соответствующих какому-либо из этих кодов устройств») — мощный инструмент для разрешения только нужного оборудования.

Заключение
Групповые политики в Windows Vista обладают рядом исключительных преимуществ, очень полезных для разрешения использования только того оборудования, которое необходимо. Просто настройте их на ранней стадии развертывания, и нежелательные устройства в вашей рабочей среде не появятся.
Интервью с Майклом Деннисом (Michael Dennis), главным менеджером программы групповых политик в Майкрософт
Недавно мне выпала возможность взять интервью у Майкла Денниса, который в Майкрософт стоял у штурвала групповых политик с самого их появления. Сейчас он покидает группу разработчиков групповых политик в поисках новых возможностей в Майкрософт. Мы с Майклом решили освежить в памяти то, что произошло в этой области за последние 9 лет, с чего все начиналось и куда движется.

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

Майкл Деннис Главные достижения принадлежат тем временам, когда мы сфокусировались на разработке того, что впоследствии получило название групповой политики. Уже существовали системные политики в Windows NT® 4.0, так что мы оглядывались на них и их недостатки. Поскольку это был период разработки Active Directory®, можно было сразу смотреть, где управляемость серверов и клиентов требовала улучшения.
Идея, что групповые политики нужно сделать иерархичными и что этого раньше никто не делал, стала для нас главной. И мы сосредоточились на базовой инфраструктуре, клиентских процессах и интеграции с Active Directory.
Побочным продуктом нашего лучшего достижения стало наше худшее достижение. Интерфейс, включенный в Windows 2000, был непростым. Для его эффективного использования надо было иметь кандидатскую степень по групповым политикам. Администратор должен был четко представлять структуру всего механизма. Было бы здорово, если бы мы уже тогда смогли создать консоль управления групповой политикой (GPMC) и результирующую политику (RSoP) — это было в спецификациях.

ДМ Что, по вашему мнению, в групповых политиках могло бы быть лучше?

МД Отрадно, что все, что я хотел добавить со времен выпуска Windows 2000, присутствует в Windows Vista — RSoP, GPMC, расширенные настройки и т.д. Хотелось бы, чтобы все это было реализовано гораздо раньше.
Кроме того, хочется, чтобы инфраструктура групповых политик была легко расширяемой. Использование нашей модели расширений для клиента и сервера требует значительных усилий со стороны разработчиков. Можно возразить, что структура шаблонов ADM/ADMX и так обеспечивает достаточную расширяемость. Но было бы определенно лучше, если бы и со стороны групповых политик это наблюдалось.
Еще хочется большей гибкости для партнеров и разработчиков сторонних инструментов в отчетах GPMC. В этой области громко заявили о себе средства сторонних разработчиков.

ДМ Какие сведения о вашей группе малоизвестны?

МД Иногда люди не очень представляют, где место нашей группы в общей картине. Мы создаем инфраструктуру, транспорт, серверную и клиентскую части. Но только в работе над Windows Vista мы держали связь со 120 разными группами в Майкрософт, чтобы к финальному выпуску все политики были на местах.
Читателям хотелось бы сказать, что не стоит винить групповые политики в задержках во время загрузки или входа в систему. Вините те полезные действия, которые эти политики выполняют. Если вы указываете сделать что-то тяжелое, это будет делаться. Например, вы указали установить Microsoft Office на каждую машину. Прекрасно. Только помните, что это будет выполнено. Весь Office будет установлен до появления приглашения входа в систему. Задержка ли это? Вы скажете «да», а я, как администратор, который это применял, скажу — это именно то, что вы потребовали от компьютера.

ДМ Какова ваша любимая часть групповых политик?

МД Сейчас это ряд новых настроек, появившихся в Windows Vista. Настройки съемных устройств (запрещение USB-устройств флэш-памяти и т.п.) — это то, о чем нас давно и настойчиво просили. В Windows Vista порядка 2400 настроек, что дает администраторам значительный уровень контроля. Люблю спрашивать клиентов, чем нужно управлять, и потом показывать, как это делать.

ДМ Почему был сделан переход с файлов ADM на ADMX?

МД Технически, для организации новой возможности централизованного хранилища в Windows Vista мы могли обойтись и без перехода. Он был сделан ради полноценной поддержки разных языков.
Ранее в многоязычных средах можно было попасть в ситуацию, когда содержимое ADM-файлов в GPO по ошибке записывалось на другом языке. Формат ADM был позаимствован у Windows NT 4.0, которая получила его от Windows 98, которая унаследовала его от Windows 95. Если бы в то время существовал XML, он был бы хорошим кандидатом на роль формата наших файлов.
Но теперь XML есть, поддерживать несколько языков с ним проще, и, кроме того, с этим схематизированным языком в будущем будет можно легко вносить улучшения в область реестра и настроек.

ДМ Что стало самым трудным в вашей работе над групповыми политиками?

МД Самая большая и постоянная проблема — добиться управляемости остальных компонентов Windows через политики.
Группа N может заявить что-то вроде «Мы создали отличную функцию. Кому придет в голову ее отключать?». И их легко понять. Но нам пришлось пройти через немало таких возражений.
Еще есть технические трудности, связанные с включением политикой некоторых функций, например нового брандмауэра Windows в режиме повышенной безопасности (WFAS). С ним мы намучились. Корректно включить его политикой — задача совсем не тривиальная. Интерфейс, который группа WFAS создала для Windows Vista, просто отличный, но его реализация стоила многих трудов.
Во время работы над версиями Windows до Windows Vista отдельные группы не особо задумывались об интеграции компонентов, за которые они отвечали, с политиками. Но во время разработки Windows Vista значительное количество групп обращались к нам с вопросом, как этого добиться. Большой прогресс!
ДМ Чем вы теперь думаете заниматься?

МД Перехожу в группу «Mobile Information Worker», отвечающую за смартфоны, КПК и т.п. Буду заниматься переносом технологий управления Windows Server System на устройства Windows Mobile®.
Попытаюсь приложить в новой области свои устоявшиеся представления и страсть к управляемости. А у группы разработчиков групповых политик сейчас есть все, чтобы развивать направление самостоятельно.

ДМ Что вы еще хотели бы сказать нашим читателям?

МД Самое главное во всей разработке групповых политик было понять, что на самом деле нужно пользователям. Если у пользователей есть четкое видение ситуаций, в которых не помешала бы поддержка со стороны групповых политик, и если имеется реальная потребность в этой поддержке, стоит сказать о своих соображениях нам.
У нас есть подходящий механизм обратной связи, доступный для всех по адресу WindowsServerFeedback.com. Ищите кнопку «Group Policy».
Если кто-то говорит: «Вот описание проблемы, вот чего надо достичь, и вот почему я хочу, чтобы система умела делать вот что», — это очень ценная для нас информация. Ответственные за выработку решений в области групповых политик читают каждую запись, получаемую с этого узла.
Еще раз скажу — если вы хотите помочь в развитии групповых политик, расскажите нам о своих нуждах. Но, пожалуйста, не говорите просто «Мне нужна политика, которая делает вот что». Обязательно объясните, почему. Мы должны знать, «почему». А «как» — мы определим и сами.
ДМ Спасибо, что уделили нам время и рассказали о своем опыте работы в группе разработчиков групповых политик в Майкрософт. Всего хорошего!
МД Спасибо вам, Джереми.

Джереми Московитц (Jeremy Moskowitz), обладатель сертификата MCSE и звания MVP по групповым политикам. Он ведет форум GPanswers.com, посвященный групповым политикам, а также серию семинаров интенсивного обучения групповым политикам. Его последняя книга — «Group Policy: Management, Troubleshooting and Security» (Групповые политики: управление, разрешение вопросов и безопасность) (изд. Sybex, 2007). С Джереми Московитцем можно связаться через форум www.GPanswers.com.


 Безопасность: 4 технологии безопасности, которыми должна владеть каждая ИТ-организация
Безопасность Мэтт Клэпэм (Matt Clapham) and Тодд Томпсон (Todd Thompson)

4 технологии безопасности, которыми должна владеть каждая ИТ-организация
Краткий обзор:
  • Панель управления рисками.
  • Противодействие вредоносному программному обеспечению.
  • Обнаружение неполадок сети.

В плане ИТ-безопасности большинство предприятий сталкивается с примерно одинаковыми вопросами. Корпорация Майкрософт не является исключением. Мы потратили два года на работу в группе, занимающейся вопросами управления рисками и выполнения нормативных требований,
подразделения MMS (Microsoft® Managed Solutions — управляемые решения корпорации Майкрософт). (Подробнее о подразделении MMS см. Корпорация Майкрософт дает новый заряд энергии своему подразделению информационных технологий.)
Группа, занимающаяся вопросами управления рисками и выполнения нормативных требований, несет ответственность за определение, мониторинг и исправление состояния риска для всех сред MMS (как для ориентированных на клиента служб, так и для координации инфраструктуры). Сначала наш менеджер, Арджуна Шунн (Arjuna Shunn), осознал, что нам необходимо технологическое решение, обеспечивающее нужные средства управления и контроля в централизованном, взаимосвязанном виде. Рассмотренные в этой статье технологии являются прямым результатом наших ранних идей, помноженных на двухлетний опыт использования в нашей работе различных продуктов корпорации Майкрософт и сторонних производителей.
Прежде всего, нам были необходимы технологии безопасности, которые обеспечивали бы три основных типа контроля (упреждающий, выявляющий и корректирующий), а также предоставляли бы возможность аудита и создания отчетности. Мы представляли себе этот набор средств поделенным на четыре категории: панель управления рисками, противодействие вредоносному программному обеспечению, обнаружение неполадок сети и управление требуемой конфигурацией. Мы постарались включить в наши операции по управлению рисками хотя бы по одному средству из каждой категории. И обнаружили, что, используя преимущества технологий каждой из четырех категорий, группа ИТ-безопасности может достичь разумного баланса между ценой и эффективностью.
Две наши основные операции по управлению рисками — реагирование на события в плане безопасности и управление выполнением нормативных требований — существенно выиграли от такого подхода, но нам все еще предстоит многое сделать для достижения того уровня координации между отдельными средствами, которого мы в результате хотим добиться. Взаимосвязанный набор технологий дает гораздо больше в плане оперативной эффективности, но, к сожалению, в отрасли еще нет такой интегрированной системы.
К счастью, для групп ИТ-безопасности не все потеряно; это лишь вопрос времени, когда четыре системы начнут работать совместно и взаимодействовать для повышения эффективности. Когда это случится, они не только обеспечат активный мониторинг защищенности системы, но также пригодятся для выполнения аудита и прочих повседневных ИТ-операций. В этой статье описывается наилучшее применение каждой системы, а в качестве примечаний приводятся некоторые примеры ее использования.

Панель управления рисками
По нашему мнению, панель RMD (risk management dashboard — панель управления рисками) совершенно необходима. Это самая важная технология в работе группы ИТ-безопасности. Мониторинг рисков CIA2 (confidentiality, integrity, availability, and accountability — конфиденциальность, целостность, доступность и отчетность) на предприятии часто выполняется разрозненными системами и процессами, не имеющими единого интерфейса для объединения и корреляции данных, а также устранения рисков. Кроме того, нормативные требования определяют уровни прозрачности данных предприятия, которые всё труднее обеспечивать, а налаженной системы для удобного отслеживания правил от их создания до применения на предприятии не существует. Об этом свидетельствуют обычные трудности организаций, связанные с получением данных, определением корреляции, оценкой, исправлением и соответствием требованиям. (Диспетчер System Center Operations Manager 2007, хотя и не является полноценным RMD-решением, описанным в этой статье, всё же обеспечивает единый интерфейс для мониторинга нескольких ресурсов и сбора соответствующих оповещений, как показано на рис. 1.)
Рис. 1 Диспетчер System Center Operations Manager 2007 обеспечивает единый интерфейс для просмотра оповещений и сетевого управления ресурсами
Рис. 1 Диспетчер System Center Operations Manager 2007 обеспечивает единый интерфейс для просмотра оповещений и сетевого управления ресурсами
Получение данных затрудняется невозможностью объединения и нормализации данных от разрозненных источников. Объединение данных является сложной задачей само по себе, потому что требует отказаться от слишком распространенного подхода бессистемного сбора данных и включения их в отчет. Даже когда объединение выполняется, остаются еще большие сложности с нормализацией, потому что чрезвычайно трудно установить общую инфраструктуру, необходимую для поддержки нормализации данных. А без нормализации невозможно осмысленно сравнивать связанные с безопасностью и работоспособностью события, получаемые от различных систем.
Для выполнения необходимой автоматизации панель управления рисками должна иметь доступ к каналам данных от других источников помимо технологий безопасности, описанных в этой статье. Для определения общей ситуации с рисками может использоваться много не связанных с безопасностью данных. Для расследования происшествий может использоваться вся информация, например журналы маршрутизаторов, учет элементов систем, состояние исправлений, осуществившие в текущий момент вход в систему пользователи, отчеты о производительности и данные об управлении изменениями. Следовательно, общей системе требуется доступ ко всем этим данным. Мы знаем, что даже инфраструктуры предприятий, в наибольшей степени основанные на продуктах корпорации Майкрософт, включают в себя технологии других производителей, поэтому панель RMD должна принимать данные и от последних через определенный общий интерфейс.
Если данные могут быть получены и нормализованы, следующим шагом является их сопоставление. Цель — определить связь последовательности событий (например неполадки сети, отчета антивируса и необходимого изменения конфигурации), образующих единый блок связанных с рисками данных, на которые необходимо отреагировать. Это требует большого ручного труда по определению логической системы связей, которая в результате будет обеспечивать осмысленное оповещение о рисках. На основе существующих в настоящее время технологий создать такую логику как минимум непросто.
Оценка данных также требует обширной ручной работы. Даже если обнаружена корреляция, аналитику необходимо просмотреть связанные данные, чтобы определить ее значимость. Значимость коррелированных данных не выше значимости правил, на которых основана корреляция. Поэтому необходим дальнейший ручной анализ связанных данных для оценки рисков, которым подвергается ИТ-среда. При этом снижению объема ручного вмешательства, требуемого для достижения нужного уровня сортировки событий, может служить четкая и кодифицированная схема управления рисками. Без такой схемы сложно разработать практический набор правил корреляции в определенной реализации.
Если допустить, что система достигла этапа оценки риска, то следующим этапом будет автоматизированное устранение этого риска. В настоящее время это возможно только на предприятиях, и даже в этом случае выполняется только для ограниченного набора технологий, например для управления исправлениями или антивирусов. Возглавляемое системой RMD автоматизированное устранение рисков даст ИТ-администратору огромные возможности по обеспечению приемлемого уровня ИТ-рисков. Когда одновременно выявляется несколько рисков, корреляционная логика должна помочь определить приоритет реагирования на каждое происшествие, основываясь на данных классификации элементов системы.
И, наконец, задачей огромной сложности для ИТ-отделов является обеспечение подтверждения соответствия различным нормативным требованиям. Как отмечалось выше, рассматриваемая система должна обладать такой функциональностью. Включенная в политику централизованная система управления рисками может быть очень полезна для создания отчетов и подтверждений соответствия требованиям. Но политика должна отвечать не только на вопросы «где» и «почему». Для автоматизированного устранения рисков политика должна быть преобразована в набор стандартов, в отношении которых панель управления может выполнять мониторинг, обеспечение выполнения и предоставление обратной связи.
После сказанного мы можем дать обобщенное определение идеальной панели управления рисками как метода обеспечения унифицированного интерфейса для оценки работоспособности корпоративной системы, обеспечения соответствия нормативным требованиям и политике, а также процессов управления рисками. Это достигается путем объединения информации от разрозненных продуктов и источников, связанных с безопасностью и работоспособностью системы, в единую взаимосвязанную картину рисков. Хорошее RMD-решение должно:
  • выполнять объединение, нормализацию и определение корреляции данных от разрозненных источников;
  • обеспечивать автоматизированный сбор информации и оценку рисков;
  • сопоставлять нормативные правила с политиками, а также поддерживать аудит и составление отчетов;
  • предоставлять унифицированную инфраструктуру, которую можно модифицировать в соответствии с потребностями конкретного предприятия.
Панель должна позволять организовывать и отображать данные в определенных разрезах, например, показывая: наиболее важные происшествия по типу или системе, которая является их источником; ожидающие разрешения происшествия; разрешенные происшествия и т.п. Она также должна давать возможность раскрывать каждую строку отчета для получения более подробной информации. Рассматривая какое-либо событие, пользователь должен иметь удобный доступ к любым связанным с ним данным. Это повысит качество решений и позволит принимать их быстрее.
Необходимо отметить, что панель RMD также полезна для администраторов, не входящих в группу обеспечения безопасности. Заключая в себе целостный взгляд на среду, эта панель может стать центральной точкой просмотра текущего состояния для всего персонала. Например, панель может оповещать группу системы обмена сообщениями об атаке SMTP-шлюза по типу «отказ в обслуживании». Это событие является происшествием в области безопасности для группы управления рисками, однако группа системы обмена сообщениями будет воспринимать его как происшествие в области доступности службы. Хотя группа системы обмена сообщениями, возможно, не ответственна за установление и разрешение таких происшествий, она, по крайней мере, может быть заинтересована в информации о них, поскольку они влияют на управляемые ею элементы системы.

Технологии противодействия вредоносному программному обеспечению
Комплексная система противодействия вредоносному программному обеспечению важна для защиты инфраструктуры от непредвиденных угроз, скрывающихся в коде и действиях пользователей. Сегодня в целом существует два отдельных типа средств для защиты от вредоносного программного обеспечения: антивирусы и средства борьбы с программами-шпионами (так, защитник Windows®, показанный на рис. 2, относится ко второй категории). Обе категории эффективно предотвращают, обнаруживают и ликвидируют последствия различных типов «инфекции». Впрочем, объединение обоих типов средств защиты в одно общее решение — лишь вопрос времени. Когда это произойдет, в системе появится единый пакет программ, противодействующих вредоносному ПО.
Рис. 2 Защитник Windows оберегает клиентов от программ-шпионов
Рис. 2 Защитник Windows оберегает клиентов от программ-шпионов
Комплексное решение по борьбе с вредоносным ПО должно выполнять мониторинг в режиме реального времени и периодическое сканирование. Оно должно централизованно сообщать об известном вредоносном ПО (включая вирусы, программы-шпионы и rootkit-программы), а также о неизвестном вредоносном ПО на основании типичных схем опасного поведения. Надежная технология противодействия вредоносному ПО должна следить за всеми классическими точками входа (включая файловую систему, реестр, оболочку, обозреватель, электронную почту и подключенные приложения) путем тесной интеграции с операционной системой и приложениями.
Кроме того, решение по противодействию вредоносному ПО должно обеспечивать безопасность не только базовой системы. Такое решение должно следить за распространенными службами обмена сообщениями и совместной работы, через которые часто проникают зараженные файлы, например за SharePoint® и программами обмена мгновенными сообщениями. Оно должно обеспечивать автоматизированное предотвращение нежелательных действий, запрещая те из них, чья вредоносность установлена или подозревается, а также тщательно сканируя данные пользователя для удаления таких угроз, как скрывающиеся в документах макровирусы, еще не заразившие систему.
Нет нужды говорить, что средства противодействия вредоносному ПО бесполезны без обновления. Система должна содержать свои базы сигнатур и средства удаления в актуальном состоянии, чтобы быть готовой к самым новым угрозам. При обнаружении таковой поставщик защитных программ должен предоставить дополнительные средства защиты прежде, чем уязвимость «нулевого дня» будет использована злоумышленником. Простое в управлении решение по противодействию вредоносному ПО также должно иметь централизованную настройку и возможность обновления.
Конечно, производительность системы не должна приноситься в жертву такой защите. Снижение производительности означает снижение продуктивности работы. Пользователи могут даже попытаться отключить такое решение по противодействию вредоносному ПО, что приведет к полному отсутствию защиты.
Наконец, не следует недооценивать важность дополнительных технологий для помощи системе противодействия вредоносному ПО. Брандмауэры, ограничение прав пользователей и другие элементы также повышают защиту от вредоносного кода и действий пользователей.

Обнаружение неполадок сети
В то время, как средства противодействия вредоносному ПО следят за компьютерам, средство NAD (network anomaly detection — обнаружение неполадок сети) контролирует типичные пути распространения, следя за известными признаками подозрительного поведения и передавая эту информацию на панель RMD для обработки (в категорию NAD, например, должен быть включен брандмауэр, как показано на рис. 3). Подозрительным поведением может быть хорошо известный трафик атаки (например червя или «отказа в обслуживании») или отправка по электронной почте данных, отвечающих определенному шаблону (например номера социального страхования США).
Рис. 3 Брандмауэр является важной составляющей решения по обнаружению неполадок сети
Рис. 3 Брандмауэр является важной составляющей решения по обнаружению неполадок сети
Несмотря на все усилия ИТ-менеджмента, в любой крупной корпоративной сети неизбежно происходят эпизодические происшествия с вредоносным программным обеспечением. Решение NAD может обеспечить систему раннего предупреждения, помогающую ускорить устранение рисков. Более того, возможности решения NAD по мониторингу данных, а также способность обнаруживать и прекращать утечки конфиденциальной информации — полезные средства защиты информации в средах, где возникают проблемы утечки данных и соответствия нормативным требованиям.
Как и в случае технологий противодействия вредоносному ПО, решение NAD должно постоянно адаптироваться к новейшим угрозам и типам конфиденциальных данных, иначе ценность его будет невысока. Кроме того, хорошая система NAD должна хорошо различать действительные неполадки и сводить к минимуму число ложных сообщений об обнаружении. В противном случае администраторы могут начать игнорировать сообщения, поступающие от системы NAD, предполагая, что каждое сообщение является лишь очередной ложной тревогой.
После небольшой настройки и обучения система NAD должна отличать и отслеживать типичные схемы использования трафика. Это необходимо, поскольку новые типы вредоносного программного обеспечения и прочие атаки могут обнаруживать себя за счет изменения такой схемы. Существенную роль в общей системе NAD играет сетевое оборудование, потому что данное решение должно обрабатывать данные маршрутизаторов, коммутаторов и брандмауэров. Предупреждения системы NAD затем могут обрабатываться корреляционным модулем панели RMD.
При этом существует заманчивая возможность — встроить средства обнаружения неполадок сети в программы противодействия вредоносному ПО или брандмауэры компьютеров, что создаст систему защиты, в которой все подключенные компьютеры помогают отслеживать и, в идеале, останавливать угрозы до их широкого распространения.

Управление требуемой конфигурацией
Одна из крупнейших задач, с которыми сталкиваются ИТ-отделы больших предприятий, — поддержание надлежащей конфигурации систем. Существует множество причин для поддержания конфигурации систем. Вот лишь некоторые из них: удобство управления, простота масштабирования, обеспечение соответствия требованиям, блокирование различных форм проникновения, повышение продуктивности работы и т.д. Многое из перечисленного — компоненты безопасности.
Управление требуемой конфигурацией для большинства предприятий остается в значительной мере непроработанной задачей — сказывается ее сложность и начальные затраты. Однако исследования показывают, что в длительной перспективе поддержание систем дает сокращение расходов и повышает надежность. Решение по отслеживанию заданной конфигурации (desired configuration monitoring — DCM) может в этом помочь.
Хорошая система DCM должна автоматически сканировать сеть для обеспечения надлежащего развертывания новых систем, а также для проверки соответствия существующих систем установленным требованиям. Независимо от того, какая стоит задача — обеспечение развертывания последних исправлений или минимизация числа имеющих привилегии домена пользователей, — полное решение DCM должно настраивать системы, анализировать их и предоставлять отчетность о том, насколько конфигурация каждой системы близка к идеальной. Корректировки могут быть простыми (как внесение исправлений в новые системы сети при их развертывании) или принудительными (например принудительные настройки клиентов электронной почты пользователей). Ключевой задачей является привязка их к политикам предприятия и нормативным положениям. (Система DCM также может помогать в обнаружении и удалении заражения вредоносным программным обеспечением, так как простые типы заражения будут хорошо заметны в результатах сканирования.)
Система DCM является одним из основных источников сообщений для корреляционного модуля панели RMD, а также предоставляет существенные подробности того, насколько рассматриваемый компьютер отличается от нормы. Своевременность данных может отличаться в зависимости от того, одно или пять оповещений о происшествии в области безопасности поступило. Таким образом, каждый элемент системы необходимо сканировать с пропорциональной его значению частотой. Например, элемент с низкой значимостью можно сканировать всего один раз в месяц, элемент средней значимости — каждую неделю, а элемент высокой — по меньшей мере раз в день.
Правильная настройка системы DCM также является фундаментальным элементом хорошего механизма NAP (network access protection — защита доступа к сети). Она позволяет системе проверять соответствие конфигурации подключенных к сети компьютеров и блокировать новые или неизвестные компьютеры до окончания проверки. Кроме того, система DCM должна искать уязвимости конфигурации (например слабые списки управления доступом к общим ресурсам), чтобы администраторы могли предпринять соответствующие меры.
Не следует считать, что система DCM применима только к компьютерам, например клиентам или серверам. В нее могут быть включены сетевые устройства и сама основная служба каталогов. При наличии достаточно понятной схемы сети идеальная система DCM легко обеспечит соответствие связанных устройств стандартам. Только представьте возможности! Не нужно вручную настраивать конфигурацию маршрутизатора, ее обеспечит DCM. Или, скажем, набор стандартных настроек групповой политики связан с определенным набором серверов или клиентов. Система DCM должна отслеживать их состояние и предупреждать в случае изменения настроек домена.
Собранные системой DCM данные должны быть достаточно надежны для использования в ИТ-аудите. Хорошая система DCM должна иметь возможность управления изменениями и соответствием нормативным требованиям, чтобы вопросы аудита могли решаться своевременно и практически без задержек. Например, одна из рутинных контрольных проверок — проверка того, что членство локального администратора на MMS-серверах не изменилось. Система DCM просто создана для обеспечения выполнения этого правила!
Даже если ваш ИТ-отдел не готов к самокорректируемой системе DCM, можно развернуть и получить отличные результаты от варианта этой системы — мониторинга требуемой конфигурации. Эта система также предоставляет отчеты и оповещения о проблемах конфигурации, но экономический эффект, скорее всего, будет не тот, потому что устранение проблем производится в значительной мере вручную. При этом, тем не менее, будет возможно определять корреляцию в данных и уведомлениях, необходимых панели RMD.
Здесь стоит сделать небольшое предупреждение. В любой из описанных выше форм система DCM должна быть ограничена только минимумом важных элементов конфигурации и данными о состоянии основных участков. Иначе она может войти в конфликт с гибкостью, необходимой ИТ-группе. Если требования системы DCM к конфигурации устареют, система быстро станет восприниматься как обуза, а не полезный инструмент. Так что важно не отставать от последних представлений об оптимальной конфигурации элементов. Более того, предлагается включить в систему DCM регулярные обновления схем конфигурации рассматриваемых элементов систем или приложений в соответствии с передовыми рекомендациями.

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

Мэтт Клэпэм (Matt Clapham) — инженер по вопросам безопасности группы, занимающейся вопросами развития инфраструктуры и безопасности, подразделения информационных технологий корпорации Майкрософт. До этого два года работал в группе, занимающейся вопросами управления рисками и выполнения нормативных требований, подразделения управляемых решений корпорации Майкрософт.
Тодд Томпсон (Todd Thompson) — инженер по вопросам безопасности в группе, занимающейся вопросами развития инфраструктуры и безопасности, подразделения информационных технологий корпорации Майкрософт. До этого два года работал в группе, занимающейся вопросами управления рисками и выполнения нормативных требований, подразделения управляемых решений корпорации Майкрософт.


 Безопасность: Новое мощное средство управления сертификатами
Безопасность Кевин Долманн (Kevin Dallmann)

Новое мощное средство управления сертификатами
Краткий обзор:
  • Архитектура ILM-CM
  • Администрирование и шаблоны
  • Создание рабочего процесса

Был спокойный денек, вы тихо занимались делами — и вдруг вам звонят из службы поддержки: на одном из серверов истек срок действия сертификата. Вся система стоит, а ваша компания теряет время (и деньги), пока вы обновляете сертификат.
Если вы заведуете инфраструктурой открытых ключей (PKI), вы наверняка не раз удивлялись неожиданно истекшему сертификату. Спокойный денек... О спокойных деньках пришлось забыть.
Включив службы PKI в Windows® 2000 и Windows Server® 2003, Майкрософт создала удобное и недорогое средство создания собственной среды PKI в организации. К сожалению, в службах PKI не было возможности управлять жизненным циклом созданных сертификатов. Но Майкрософт недавно приобрела средство управления сертификатами, после чего выпустила Identity Lifecycle Manager (диспетчер жизненного цикла удостоверений, ILM), который объединяет управление сертификатами с предоставлением удостоверений и функциями контроля сервера Microsoft® Identity Integration Server (MIIS). В этой статье мы рассмотрим, как ILM может помочь в управлении сертификатами и смарт-картами в рамках организации.

Архитектура ILM-CM
В основе архитектуры ILM Certificate Management (управления сертификатами ILM, ILM-CM) лежит сервер ILM-CM и его компоненты (рис. 1). Сервер ILM-CM можно установить на отдельном сервере, настроенном на взаимодействие с одним или несколькими центрами сертификации (CA). Для работы ILM-CM необходима СУБД SQL Server™, используемая для хранения информации о сертификатах, политик и других сведений о сертификационной среде. Для управления учетными записями и разрешениями безопасности требуются службы Active Directory®. Необходимые компоненты и их версии показаны на рис. 2.
Figure 2 Поддержка инфраструктуры ILM-CM (Close Figure 2)

Компонент | Версия
Active Directory | Windows Server 2003
Сервер баз данных | SQL Server 2000 с пакетом обновления 3 (SP3) или выше; SQL Server 2005
Центр сертификации | Windows Server 2003 Enterprise Edition или Data Center Edition
SMTP | SMTP-сервер
Рис. 1 Архитектура ILM-CM
Рис. 1 Архитектура ILM-CM
После установки среды ILM-CM все запросы сертификатов будут направляться на сервер ILM-CM. Он хранит в базе данных SQL Server всю связанную с сертификатами информацию, которую можно использовать для создания отчетов, изменения и поддержания рабочего состояния.
Архитектура ILM-CM состоит из трех элементов верхнего уровня: сервера ILM-CM, подключаемых модулей центров сертификации и клиентских компонентов. Серверную часть можно установить на центре сертификации или на сервере, используемом в основном для ILM-CM. После этого сервер ILM-CM будет обращаться к центрам сертификации, базе SQL Server и службам Active Directory. Он также обеспечивает веб-портал, с помощью которого менеджеры по сертификации указывают политики сертификации и рабочие процессы, а подписчики на сертификаты могут запрашивать новые сертификаты и обновлять существующие.
Чтобы центр сертификации мог обратиться к серверу ILM-CM, в этом центре необходимо установить и настроить политики ILM-CM и модули выхода. Эти два компонента используются для записи сертификационных сведений в базу данных. Когда центр сертификации выдает сертификат, модуль выхода должен отослать информацию об этом на сервер ILM-CM, который запишет ее в базу данных.
Если планируется поддержка смарт-карт, нужно также установить клиентское программное обеспечение ILM-CM по работе с такими картами. Это нужно сделать на каждом клиентском компьютере, который должен обращаться к серверу ILM-CM.

Установка ILM-CM
Установка сервера ILM-CM весьма проста и полностью контролируется мастером. Но перед его запуском следует предпринять несколько предварительных шагов.
Первое, что потребуется — службы Active Directory и расширение схемы ILM-CM. Расширение схемы несет несколько дополнительных атрибутов безопасности Microsoft .NET Framework, которые необходимы для реализации шаблонов профилей.
Также понадобится установка .NET Framework 2.0 и всех компонентов, упомянутых ранее — SQL Server, центров сертификации и SMTP-сервера. Если ILM-CM будет установлен не на том же компьютере, что и центр сертификации, нужно установить на компьютере последнего модули ILM-CM, запустив на нем мастер установки ILM-CM. По завершении установки вы сможете посетить портал ILM-CM, направив обозреватель по адресу http://hostname/CLM.
Для включения уведомлений об истечении или обновлении сертификата нужно настроить службу ILM-CM на сервере ILM-CM. Начните с создания соответствующей учетной записи в Active Directory. Затем в службах ILM-CM сделайте эту запись учетной записью для входа. Потом добавьте эту учетную запись к группе локальных администраторов и группе IIS_WPG на сервере ILM-CM, а также внесите ее в групповые политики «Работа в режиме операционной системы», «Создание журналов безопасности» и «Замена маркера уровня процесса». После этого сервер сможет отправлять по электронной почте уведомления об истекшем сроке годности владельцам сертификатов или менеджерам, если анализ базы данных SQL Server покажет такие сертификаты.

Администрирование ILM-CM
Управление ILM-CM осуществляется через веб-интерфейс, поделенный на функциональные области: управление учетными записями, сертификатами и смарт-картами. Подключившись к порталу ILM-CM и имея достаточные администраторские полномочия, можно увидеть список из большого числа административных задач, позволяющих управлять средой ILM-CM (рис. 3). Раздел «Common Tasks» (Общие задачи) предоставляет различные возможности, в том числе подписку пользователей на новые наборы сертификатов и смарт-карты. Здесь же находятся средства управления запросами и их утверждения.
Рис. 3 Административные задачи на портале ILM-CM
Рис. 3 Административные задачи на портале ILM-CM
Найти пользователя или сертификат можно с помощью области задач «Manage Users and Certificates» (Управление пользователями и сертификатами). Предоставляются варианты: найти, восстановить, отозвать или обновить сертификат. Имеется список случаев отзыва.
Если в организации используются смарт-карты, обратите внимание на раздел «Manage User Smart Cards» (Управление смарт-картами пользователей). Например, если пользователь заблокировал свою карту, менеджер может разблокировать ее. Можно осуществлять поиск и просматривать смарт-карты, находящие в локальном устройстве чтения.
Область «Requests» (Запросы) позволяет просматривать и удовлетворять запросы пользователей на сертификаты. К примеру, можно отобразить список всех сертификатов, запрос на которые пока не удовлетворен. Область «Administration» (Администрирование) позволяет создавать и управлять шаблонами профилей. Наконец, область «Reports» (Отчеты) предназначена, как нетрудно догадаться, для разработки и создания отчетов о пользователях и сертификатах.
Если ваша учетная запись не имеет административных привилегий, то после входа на портал ILM-CM вам будет представлена страница, предназначенная подписчикам. На ней пользователи сертификатов могут самостоятельно осуществлять управление ими (рис. 4). Допускается просмотр и управление сертификатами и смарт-картами в соответствии с действующей политикой. Например, можно запросить сертификат или смарт-карту, просмотреть выданные сертификаты и сменить ПИН-код карты.
Рис. 4 Страница портала, предназначенная для пользователей
Рис. 4 Страница портала, предназначенная для пользователей
Любому предприятию совсем не просто создать высоконадежный, делегированный рабочий процесс выпуска, обновления, замены и отзыва сертификатов или смарт-карт. ILM-CM дает возможность делегировать эти задачи и тем самым обеспечить большую защищенность. Пусть, к примеру, пользователь забыл ПИН-код своей смарт-карты. В рамках модели делегированного рабочего процесса он может позвонить в службу поддержки и ответить на ряд проверочных вопросов. Если все правильно, служба поддержки разблокирует карту. Другой пример делегированного рабочего процесса — восстановление сертификата файловой системы с шифрованием (EFS) в случае его непреднамеренного удаления или утери переносного компьютера.

Шаблоны профилей
Шаблон профиля — базовый компонент, обеспечивающий полное управление рабочим процессом в ILM-CM. Это административный объект, содержащий один или несколько шаблонов сертификатов. Созданный и настроенный шаблон профиля определяет ход рабочего процесса в сертификационной среде. Ключевой аспект шаблона профиля — возможность содержать несколько шаблонов сертификатов, трактуемых как единое целое. В результате управлять учетными записями пользователей можно с помощью единственного шаблона, который отслеживает жизненный цикл процесса сертификации.
Шаблоны профилей можно настроить на хранение сертификатов на компьютере (шаблоны, основанные на программном обеспечении) или на смарт-карте (шаблоны, основанные на оборудовании). Создаются шаблоны копированием базового шаблона, доступного в административном портале ILM-CM. Затем определяется ряд компонентов политики управления (рис. 5).
Рис. 5 Шаблон профиля
Рис. 5 Шаблон профиля
Большинство компонентов политики применимы и к программным, и к аппаратным профилям (рис. 6). Некоторые из них заслуживают отдельного упоминания. Политика подачи заявлений на сертификаты используется для определения различных аспектов того, как будет происходить процесс подачи. Например, можно настроить сбор данных: пользователи должны будут ввести такие сведения, как код своего подразделения, адрес электронной почты и имя непосредственного начальника. Еще можно настроить автоматическую печать официального документа по факту выдачи сертификата пользователю.
Figure 6 Политики программных профилей (Close Figure 6)

Компонент | Описание
Сведения о профиле | Общая информация о шаблоне профиля. Здесь осуществляется добавление к шаблону профиля шаблонов сертификатов.
Политика дублирования | Определяет сущности рабочего процесса существующего сертификата.
Политика подачи заявок | Определяет рабочий процесс подачи заявок на сертификаты.
Политика сетевого обновления | Похожа на обычную политику обновления, но может обновлять существующие сертификаты, содержимое сертификатов, шаблоны и прошивку смарт-карт.
Политика восстановления от имени | Восстанавливает закрытый ключ или сертификат пользователя.
Политика обновления | Определяет рабочий процесс обновления сертификата с истекшим сроком.
Политика возвращения | Определяет процесс восстановления отозванного сертификата.
Политика восстановления | Определяет рабочий процесс восстановления сертификата, который был случайно удален или находился на украденном или поврежденном компьютере.
Политика отзыва | Определяет рабочий процесс отзыва всех сертификатов, содержащихся в профиле.
Большую пользу может принести политика сетевого обновления. Она похожа на обычную политику обновления, но может обновлять содержимое сертификатов, их шаблоны, прошивку смарт-карт, а также сертификаты, чей срок годности истекает. Для полноценного использования этой политики нужно разрешить службе ILM-CM и в файле web.config доступ к многозначному атрибуту в Active Directory. Необходимо также установить на клиентские компьютеры службу сетевого обновления.
Политика восстановления от имени может пригодиться, если используется шифрование EFS. Допустим, кто-то случайно удаляет свой сертификат шифрования. Можно применить эту политику для организации такого рабочего процесса, в котором группа безопасности службы поддержки имеет возможность запросить закрытый ключ этого пользователя. Затем пользователю отправляется электронное письмо с секретным паролем, сгенерированным сервером ILM-CM. Получив его, пользователь переходит по секретной ссылке на сервере ILM-CM и получает сертификат со своим закрытым ключом. Политика восстановления от имени также весьма полезна в случае, когда сотрудник покидает организацию, но его данные необходимо восстановить для отправки в архив по административным или иным соображениям.
Политика обновления позволяет сделать процесс обновления более безопасным за счет отправки пользователям по электронной почте одноразовых секретных ключей, которые будут использованы для обновления сертификатов. Политика возвращения определяет рабочий процесс на случай, если сертификат был отозван, а потом потребовалось восстановить его и удалить из списка отзывов сертификатов.
Два компонента относятся только к политикам программной сертификации и не применимы к смарт-картам — это политика восстановления и политика отзыва. Если хранившийся на компьютере сертификат был удален, или был украден или поврежден сам компьютер, политика восстановления определит процесс возвращения сертификата или ключей, если они сохранены в центре сертификации. Политика отзыва позволяет администратору либо задать единственно допустимую причину отзыва, либо вводить описание причины каждый раз при отзыве сертификата.
Пять дополнительных политик применимы только к шаблонам профилей смарт-карт (рис. 7).
Figure 7 Политики профилей смарт-карт (Close Figure 7)

Компонент | Описание
Политика замены | Определяет профиль на случай потери или кражи смарт-карты.
Политика отключения | Определяет процесс отключения сертификатов на смарт-карте до их истечения.
Политика увольнения | Определяет процесс отзыва всех сертификатов на смарт-карте.
Политика разблокировки | Определяет, кто может разблокировать ПИН-код пользователя смарт-карты.
Политика временных карт | Определяет смарт-карту с небольшим сроком действия. Пользователь получает новые сертификаты для создания подписи, но сможет расшифровывать свои данные с помощью существующих сертификатов шифрования профиля.
Для политики, применяемой при увольнении, можно задать несколько различных операций, например удаление пользовательских данных со смарт-карты, блокировка пользовательского и администраторского ПИН-кодов и установление нового ПИН-кода. Политика разблокировки обычно используется, когда пользователь забыл ПИН-код или когда выпускается новая карта с ПИН-кодом, установленным службой ILM-CM. Запрос на разблокировку смарт-карты подается пользователем.
Отчеты, как и в любом продукте для администрирования, занимают не последнее место. Для любой организации важна способность создавать снимки состояния сертификационной среды и смарт-карт. ILM-CM содержит несколько встроенных отчетов, в число которых входят списки смарт-карт, сводка запросов на сертификат, использование и срок истечения годности сертификатов и многие другие. Как и в других системах создания отчетов, при необходимости можно написать собственные запросы, поскольку вся информация хранится в базе данных SQL Server.

Разработка рабочего процесса
Рассмотрим, как с помощью ILM-CM определить эффективный рабочий процесс. Пусть, например, есть несколько системных администраторов, ответственных за управление и поддержку сертификатов SSL. Первый требующий ответа вопрос — каковы ключевые аспекты этого процесса?
Способ создания файла запроса сертификата зависит от типа системы. Поэтому первый шаг — создание страницы в интрасети с детальными инструкциями по созданию таких запросов для каждого типа систем.
Создав файл запроса, администратор может отправить его на пользовательский портал ILM-CM для утверждения. С помощью рабочего процесса ILM-CM администратор может определить нескольких лиц, проверяющих и утверждающих запрос. После удовлетворения запроса пользователь может получить сертификат из ILM-CM. Поскольку там сведения о сертификате хранятся в базе данных SQL Server, администраторы имеют доступ к информации о прошлых периодах.
Через год срок действия сертификата приближается к концу, и ILM-CM отсылает по электронной почте уведомление пользователю о том, что его сертификат скоро истечет и должен быть обновлен. Использование этого рабочего процесса поможет избежать ситуаций, когда из-за неожиданно истекшего сертификата рабочий день идет насмарку.

Заключение
Если ваше предприятие использует среду Microsoft PKI, ILM-CM определенно поможет управлять ею. Он позволяет улучшить процессы проверки подлинности и снизить стоимость и сложность управления цифровыми сертификатами и смарт-картами. С его помощью можно создать соответствующие рабочие процессы, которых так не хватает современным предприятиям.
Майкрософт также предоставляет API-интерфейс к ILM-CM. Если вы используете собственные приложения, вы можете интегрировать их с ILM-CM.
Подробнее об ILM-CM см. на веб-узле microsoft.com/technet/clm. Краткое руководство доступно по адресу go.microsoft.com/fwlink/?LinkId=87336.

Кевин Долманн (Kevin Dallmann) — старший системный инженер-консультант в компании Accenture. Он отвечает за поддержку Active Directory и PKI в крупных корпоративных средах. Кевин имеет сертификаты MCSE и MCT, он преподает на курсах по изучению продуктов Microsoft.


 От редактора: Вопросы безопасности
От редактора
Вопросы безопасности
Джошуа Трупин (Joshua Trupin)

Вы заметили, что вопросы безопасности в последнее время стали более управляемыми? Конечно, мы в редакции TechNet Magazine с удовольствием вписали бы это в число своих личных заслуг, но кроме нас были и другие факторы. Два самых важных из них — осведомленность и надежность.
Осведомленность — это когда вы в курсе возможных угроз и приемов социальной инженерии, плюс регулярная установка исправлений и обновлений к имеющемуся программному обеспечению. Надежность же дополняет картину: это концепция того, что создавать ПО можно изначально более безопасным, плюс уменьшение контактной зоны за счет отключения некоторых возможностей в настройках по умолчанию.
Да! Конечно же, еще регулярное чтение журнала TechNet Magazine. Как я мог забыть! Вы держите в руках наш уже практически знаменитый выпуск, посвященный безопасности, а в нем как минимум семь статей, которые позволят вам успешнее вызывать благоговейный трепет у коллег своими знаниями теории и практики безопасности. Марк Руссинович (Mark Russinovich) открывает выпуск обзором внутреннего устройства контроля учетных записей, Стив Райли (Steve Riley) покоряет глубины брандмауэра Windows, а Джеспер Йохансон (Jesper Johansson) исследует изменения списков ACL, внесенные в Windows Vista. Джереми Московитц (Jeremy Moskowitz) рассказывает о групповых политиках и установке ограничений на использование устройств, Майкл Мерголо (Michael Murgolo) уделяет внимание запуску сценариев с повышенными привилегиями с помощью PowerToys, и это, разумеется, не конец. Так что этот выпуск можно смело считать лучшим за всю историю печатного дела на земном шаре.
Раз уж мы не собираемся терять боевую готовность, нужно сказать о новейшем предложении в области безопасности от Майкрософт. Microsoft Forefront — «надежность», один из кусочков нашей головоломки. Это линейка бизнес-приложений сферы безопасности, которые предоставляют защиту трех областей: клиентских операционных систем, серверов приложений и сети. Линейкой предусмотрены инструменты для Exchange Server и SharePoint, а также включение ISA Server и Intelligent Application Gateway в контроль за сетевым трафиком. А Microsoft System Center включает второй кусочек мозаики, «осведомленность», позволяя собирать данные о состоянии ваших компьютеров, упрощая организацию и выполнение операций, создавая отчеты и повышая стандарты. Среди прочего в него входит новое поколение технологий управления настройками и мониторинга хода работы.
Подробнее о Forefront и System Center можно узнать на веб-узле Microsoft Infrastructure — Microsoft.com/infrastructure. Ну и чтобы складывать головоломки безопасности на высшем уровне, не забывайте о TechNet Magazine.
— Джошуа Трупин

Мы хотели бы поблагодарить следующих технических специалистов по продуктам корпорации Майкрософт: Конрада Байера (Conrad Bayer), Девида Кросса (David Cross), Майкла Дениса (Michael Dennis), Шона Эйзенгофера (Shon Eizenhoefer), Джейсона Гармса (Jason Garms), Расса Хамфриеса (Russ Humphries), Джеспера Йохансона (Jesper Johansson), Джона Ламберта (John Lambert), Эрика Перлина (Eric Perlin), Марка Руссиновича (Mark Russinovich), Джона Шварца (Jon Schwartz), Дэвида Соломона (David Solomon), Грега Стемпа (Greg Stemp), Джона Стефенса (John Stephens), Кевина Салливана (Kevin Sullivan), Джима Трухера (Jim Truher) и Бака Вуди (Buck Woody).


 Инструментарий: Новые программные продукты для ИТ-специалистов
Инструментарий Новые программные продукты для ИТ-специалистов and Грег Стин (Greg Steen)
Создание мини-приложений, управляемых данными
Пакет PowerGadgets
Пакет PowerGadgets позволяет преобразовать данные в наглядные диаграммы, шкалы и карты
Средство PowerGadgets Creator предоставляет графический пользовательский интерфейс для настройки внешнего вида мини-приложения, осей, источников данных, способа отображения данных и других параметров. Все эти действия можно также совершать с помощью командной строки среды Windows PowerShell, которая была настроена для работы с пакетом PowerGadgets. Можно легко добавить мини-приложение в боковую панель ОС Windows Vista с помощью кнопки со значком «плюс» в верхней части этой панели, или запустив это мини-приложение из командной строки с параметром –sidebar.
Эти мини-приложения можно применять для самых разных целей. Благодаря возможности запрашивать данные у веб-служб, можно, например, отслеживать данные службы персонала и автоматически получать уведомления при принятии на работу нового сотрудника. Или, к примеру, с помощью сценариев среды Windows PowerShell можно через интерфейсы WMI получать в одном месте данные о средней загрузке процессоров всех веб-серверов организации.
Если необходимо проанализировать данные за какой-либо прошлый период, достаточно просто импортировать CSV-файл и наложить график на карту, чтобы, например, узнать, в каком из удаленных офисов самая широкая полоса пропускания канала. Также с помощью сценария можно легко отправлять по электронной почте руководству наглядные графики пропускной способности канала и бесперебойной работы, чтобы там могли быть уверены, что у группы эксплуатации все нормально.
Цены: от 299 долл. США за одну лицензию на средство PowerGadgets Creator или 599 долл. США за одну лицензию на средство PowerGadgets Creator и 10 клиентских лицензий.

Отслеживание состояния среды
Система контроля RoomAlert 11E
www.roomalert.com
Наличие хорошего средства для наблюдения за состоянием серверов важно для ИТ-инфраструктуры, но состояние серверов — это не единственное, что необходимо отслеживать. Наблюдение за состоянием физической среды функционирования ИТ-инфраструктуры не менее важно. Необходимо контролировать работу вентиляции, температурный режим, влажность, состояние электросети, уровень задымленности и затопление помещения. Если ИТ-инфраструктура сконцентрирована в специальном комплексе, все эти параметры контролируются средствами этого комплекса. Но если в организации используются свои центры обработки данных, стойки с оборудованием и серверные шкафы, то решение RoomAlert 11 E от компании AVTech окажется весьма полезным.
Наблюдение за состоянием среды с помощью системы контроля RoomAlert 11E
В комплект поставки этой системы входят: один датчик температуры и влажности, один цифровой датчик температуры, один внешний датчик для электросети и непосредственно само устройство. Можно дополнительно подключить до восьми датчиков-переключателей и до трех цифровых датчиков температуры и влажности или блоков расширения. Цифровые датчики могут быть расположены на расстоянии до 30 метров, а датчики переключателей, в зависимости от используемого контроллера, — на расстоянии сотен метров от устройства.
Устройство является автономным модулем со встроенным административным веб-интерфейсом. Требования к системе ограничиваются наличием компьютера с ОС Windows, на который устанавливается программное обеспечение для обнаружения этого устройства в сети. Для начала работы достаточно просто подключить к устройству датчики, подключить устройство к компьютерной сети, запустить программу обнаружения устройства в сети и с помощью веб-интерфейса настроить параметры уведомлений о событиях. Также перед началом эксплуатации рекомендуется обновить микропрограмму устройства до последней версии.
Самой важной частью внедрения этого устройства является планирование элементов среды, состояние которых необходимо отслеживать в конкретной ИТ-инфраструктуре, и а также планирование размещения датчиков и самого устройства. Нужно иметь в виду, что для отслеживания состояния электросети само устройство должно быть подключено к альтернативному источнику электроэнергии или к ИБП. В противном случае такое отслеживание окажется попросту бессмысленным.
Комания AVTech также предлагает беспроводное решение — систему контроля RoomAlert 26W, которая предоставляет большую свободу при выборе места расположения устройства относительно мест расположения датчиков. Кроме того, при использовании беспроводного устройства отпадает необходимость протягивать кабели к датчикам.
Помимо факторов среды, состояние которых можно отслеживать с помощью входящих в комплект поставки датчиков, может возникнуть необходимость контролировать и другие факторы среды. На веб-узле компании AVTech представлен список дополнительных типов датчиков, которые можно подключить к устройству RoomAlert 11 E. Можно приобрести датчики для отслеживания температуры, влажности, состояния электросети, а также датчики затопления помещения или отдельного объекта, датчики задымления, движения, перемещения воздушных потоков и датчики контроля на входе в помещение.
Цены: система контроля RoomAlert 11E от 495 долл. США, датчики от 25 до 400 долл. США.

Обзор книги
Средства SQL Server 2005 — взгляд изнутри
www.awprofessional.com
Количество новых возможностей и средств SQL Server™ 2005 порой поражает. Несколькими членами группы SQL Server корпорации Майкрософт была написана очень хорошая книга, с помощью которой можно очень быстро разобраться во всех новых возможностях и средствах новой версии сервера SQL Server. Эта книга может одновременно служить и руководством для начинающих, и полезным справочником для тех, которые уже достаточно хорошо знаком с сервером SQL Server 2005.
Книга «Средства SQL Server 2005 — взгляд изнутри» (издательство «Addison-Wesley Professional», 2006 г.) описывает весь набор средств, входящих в состав сервера SQL Server 2005, начиная от средства настройки контактной зоны сервера SQL Server, и заканчивая интерфейсом управляющих объектов SQL Server (SMO) для платформы .NET, который пришел на смену старому интерфейсу SQL-DMO. В начале книги дается беглый обзор линейки продуктов SQL Server, а затем приводится весь перечень компонентов, входящих в комплект поставки SQL Server 2005. Далее следует краткий обзор всех средств, включенных в выпуск, разбитых на следующие категории: средства установки и обновления, средства для настройки, средства для управления и администрирования, средства для отслеживания состояния и эксплуатации, средства для проектирования баз данных, схем и отчетов, средства для отладки и оптимизации запросов, средства для обслуживания, а также объектные модели для разработки. Затем приводится подробное описание каждого средства.
Книга охватывает довольно обширную область, поэтому в этом обзоре приводятся лишь самые значимые моменты. Раздел, посвященный установке и настройке, будет крайне полезен для тех, кто впервые столкнулся с продуктом SQL Server 2005. В книге очень хорошо выделены все трудности, с которыми можно столкнуться при обновлении базы данных, подробно описано, как с помощью инструмента «Помощник по обновлению» создать отчет, в котором будут перечислены все проблемы, возникающие в процессе обновления. Также приводится пошаговое руководство по установке и описание возможных вариантов конфигурации. Особенно полезен раздел книги, в котором описывается использование средства «Настройка контактной зоны» для ограничения перечня устанавливаемых компонентов только необходимыми службами и протоколами.
Также в книге хорошо описана среда SQL Management Studio, которая пришла на замену таким средствам, как Query Analyzer, Enterprise Manager и Analysis Manager. В книге приводится подробное руководство по применению графического пользовательского интерфейса этой среды и подробная информация о функциях нового пользовательского интерфейса. Например, показано, как теперь с помощью сценариев можно легко открыть несколько объектов в новом окне запроса. Также очень полезен раздел, в котором описано, как с помощью таких средств как SQL Profiler, Activity Monitor и Microsoft Operations Manager (MOM) определять узкие места и особенности использования, а также получать уведомления обо всех проблемах с используемым экземпляром базы данных.
Тем, кто уже использует сервер SQL Server 2005 или планирует обновление до этой версии, следует подробно ознакомиться с этой книгой.
Цены: 59,99 долл. США при покупке по каталогу, 53,99 долл. США при покупке непосредственно в издательстве.

Управление на основе веб-технологий
Средство myLittleAdmin для SQL Server 2005
Интерфейс средства myLittleAdmin поддерживает обложки
Веб-интерфейс позволяет выполнять большинство необходимых действий, таких как создание новых баз данных, изменение существующих баз данных и их содержимого, а также работа со снимками и схемами. Редактировать свойства существующих объектов базы данных очень просто благодаря удобной сетке данных, которая поддерживает редактирование, что позволяет изменять значения в отдельных строках таблиц. Древовидный интерфейс очень похож на интерфейс среды SQL Server Management Studio, поэтому осваивать работу со средством myLittleAdmin очень несложно. Единственное, что может сбить с толку, это отсутствие некоторых привычных контекстных меню, вызываемых щелчком правой кнопки мыши.
Средство myLittleAdmin позволяет также редактировать учетные записи, серверные роли и учетные данные в экземпляре сервера SQL. С его помощью можно даже выполнять такие нужные задачи, как создание и изменение устройств резервного копирования и связанных серверов, причем эти действия можно выполнять удаленно.
Помимо всего вышеперечисленного, средство myLittleAdmin позволяет выполнять такие задачи, как мгновенные запросы, подключение и отключение баз данных, резервное копирование и восстановление баз данных, импортирование данных в формате CSV и сжатие баз данных. Можно даже просмотреть журнал ошибок и состояние монитора активности для устранения неполадок.
Цены: от 590 долл. США за лицензию на один сервер. В качестве набора инструментов для поставщиков услуг размещения веб-узлов стоимость составляет от 990 долл. США за лицензию на один сервер.


 Вопросы и ответы по SQL: 64-разрядные установочные пакеты, выделение памяти кластера и другое
Вопросы и ответы по SQL 64-разрядные установочные пакеты, выделение памяти кластера и другое and Под редакцией Нэнси Мичел (Nancy Michell)
Эффективность работы электронной документации
В. Каждый раз, как я открываю электронную документацию (BOL) по SQL Server™ на своей настольной системе, она работает очень медленно, хотя у меня и быстрый компьютер. На других системах, которыми я пользуюсь, этого не происходит. Что может быть причиной возникновения задержек?
О. Возможно, эти задержки связаны с настройками параметров загрузки справки. Электронная документация имеет три варианта ее отображения. Первый — сначала обратиться к справке в Интернете и лишь затем к локальной; второй — сначала использовать локальные данные и лишь затем Интернет; третий — ограничиться только локальной справкой. Выбор между ними делается при первом использовании электронной документации по SQL Server, но его можно изменить.
Откройте электронную документацию, зайдите в меню «Сервис». Выберите пункт «Параметры» и перейдите в раздел «Справка | Справка в сети». Выберите один из двух первых вариантов, чтобы загрузить справку локально.
Пока электронная документация открыта, не помешает проверить ее версию, чтобы убедиться в том, что установленная версия является самой последней и лучшей. Посмотрите строку заголовка в верхней части экрана. Если указана более ранняя дата, чем февраль 2007 г., или если дата вообще отсутствует, то эта версия устарела и следует загрузить последнюю версию с веб-узла, расположенного по адресу microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx. На этом веб-узле электронная документация обновляется несколько раз в год.

32-разрядные и 64-разрядные установочные пакеты
В. Не могу разобраться, какие типы и версии приложения SQL Server можно устанавливать на серверы x86, x64/EMT64 и IA64. Говорят, что у SQL Server 2005 не такие типы установочных пакетов, как у SQL Server 2000. Так ли это?
SQL Server 2000 поставляется в виде установочных пакетов двух типов (и различных выпусков): 32-разрядных и 64-разрядных. Его можно устанавливать на платформы x86 и x64/EMT64, на которых это приложение будет работать как 32-разрядное. 64-разрядная версия SQL Server 2000 работает на платформе IA64.
SQL Server 2005 поставляется в виде установочных пакетов трех типов (и различных выпусков). Его можно устанавливать на платформы x86 или x64/EMT64 в качестве 32-разрядного приложения, на платформу x64/EMT64 в качестве 64-разрядного приложения, если она работает под управлением операционной системы Windows x64/EMT64, и на платформу IA64 в качестве 64-разрядного приложения.

Рис. 1Поиск по электронной документации по SQL Server на веб-узле Windows Live
Но если SQL Server занимает весь объем ОЗУ сервера и при этом происходит запуск нового экземпляра SQL Server. Что происходит с памятью имеющегося экземпляра SQL Server? Очевидно, стоит планировать в расчете на худший вариант, когда только один узел сохраняет рабочее состояние и всем экземплярам SQL Server приходится работать на нем.
О. В общем случае можно согласиться с тем, что лучше всего устанавливать максимальное значение памяти сервера меньшим, чем общее количество памяти машины. Однако совсем не факт, что лучшим вариантом в данном случае является одна треть общего объема памяти.
Вас беспокоит, что из строя могут одновременно выйти три из четырех серверов кластера, и тогда этим трем экземплярам SQL Server придется умещаться на четвертом сервере. Это, однако, маловероятно.
В большинстве случаев лучше настраивать каждый экземпляр таким образом, чтобы он использовал большую часть памяти каждого узла. Пусть, например, на каждом узле в наличии есть 32 ГБ ОЗУ. Разумным будет установить для каждого экземпляра примерно 28 ГБ памяти.
Теперь в случае отказа узла выполняющийся на этом узле экземпляр переключится на пассивный узел и потенциально может получить доступ к 28 ГБ памяти. Состояние двух других экземпляров не изменится. Они будут продолжать выполняться на двух других узлах кластера.
Вы говорите о рассчитанном на восстановление при отказе кластере из четырех узлов с пятью экземплярами SQL Server и одним экземпляром служб Analysis Services. Если вы используете SQL Server 2000 в режиме расширенной адресации (AWE), то для экземпляров реляционной базы данных следует настроить какие-то тщательно подобранные предельные значения объема памяти, так как они не будут освобождать память, которую получили. В более гибкой ситуации, когда используются 64-разрядные экземпляры SQL Server 2005, имеющие доступ к большому адресному пространству независимо от наличия расширений AWE, всё происходит иначе. Даже если в этой ситуации используется AWE, память может динамически освобождаться по запросу. Таким образом, ответ на вопрос, что происходит с изначальным экземпляром SQL Server и памятью, которую он занял во время восстановления при отказе, сопровождающемся запуском на компьютере нового экземпляра, зависит от того, используется SQL Server 2000 или SQL Server 2005 и используются ли расширения AWE.
Планирование исходя из сценария худшего случая, в принципе, разумно, но на практике очень маловероятно, что вам удастся сохранить работоспособность при выходе из строя трех из четырех узлов кластера, на котором выполняются пять экземпляров СУБД SQL Server и один экземпляр служб Analysis Services — если только это не система с завышенными техническими характеристиками. У оставшегося узла не хватит ресурсов процессора для обслуживания имеющихся экземпляров на сравнимом уровне производительности. Исходя из этого, в общем случае лучше проектировать решение, при котором поддерживается оптимальная производительность при потере одного узла, а при потере большего их количества может потребоваться некоторое вмешательство вручную. Такое решение, скорее всего, обеспечит хорошее сочетание высокой доступности (HA) и достаточно полного использования дорогостоящих ресурсов.
Наконец, при использовании SQL Server 2005 конечный пользователь может фактически масштабировать кластер до восьми узлов. Для SQL Server 2000 максимально возможным был кластер из четырех узлов.

Предельные возможности зеркального отображения
В. Читая о зеркальном отображении баз данных SQL Server 2005, я обнаружил ограничение предельного количества зеркально отображаемых баз данных для экземпляра сервера, равное 10 базам. Мне необходимо иметь два отдельных экземпляра SQL Server с раздельными хранилищами данных, автоматическим переключением между этими экземплярами и резервированием данных.
Я планировал использовать одноранговую (P2P) транзакционную репликацию SQL Server 2005 в сочетании с сервером кластеров Microsoft® (MSCS), при этом у меня бы был IP-адрес кластера, который присваивался бы одному из двух узлов, чтобы весь трафик вставки, обновления, удаления и чтения записей направлялся на один узел кластера. Я бы использовал дополнительный узел в качестве пассивного, но выполнял бы репликацию транзакций на него. В случае отказа сервер MSCS передавал бы обращения к этому IP-адрес на другой узел, и, так как он настроен как одноранговый и двунаправленный, то для начала публикации транзакций на исходный узел (после того как он снова начнет работать) никаких ручных действий не требовалось бы. Для снижения потребности в общем дисковом ресурсе для кворума я бы использовал на сервере MSCS конфигурацию в виде набора узлов большинства.
Вариант зеркального отображения всё еще рассматривается. Мы сократили число баз данных на кластер SQL Server с 1000 до 100. Следует ли, всё же, подвергать системы такой нагрузке?
О. Информацию и указания по зеркальному отображению в SQL Server см. в электронной документации или на веб-узле технического центра SQL Server, расположенного по адресу microsoft.com/technet/prodtechnol/sql и msdn2.microsoft.com/sql.
Ваш вопрос вызвал длительное обсуждение. После выпаривания явных несерьезностей в сухом остатке имеются следующие неплохие ответы.
Ответ номер один сводится к тому, что не существует принудительного ограничения количества баз данных, для которых может выполняться зеркальное отображение в определенном экземпляре. Полагаю, что вы узнали о нем из статьи, в которой отмечается, что лучшие методы работы предполагают зеркальное отображение не более чем 10 баз данных для одного экземпляра, но это просто приблизительная оценка, а не ограничение — никаких конкретных ограничений нигде не установлено. Всё зависит от имеющихся в наличии ресурсов системы.
Зеркальное отображение может быть приемлемым вариантом, но 1000 баз данных для него — практически неподъемно, если только не используется действительно очень мощный сервер. Если вы не хотите использовать общее хранилище данных, но хотите применять встроенные в SQL Server технологии, можно попробовать использовать зеркальное отображение, доставку журналов или репликацию. Каждый из вариантов имеет свои положительные и отрицательные стороны.
Ответ номер два сводится к тому, что при наличии большого количества баз данных без общего хранилища и при желании использовать решение в области аварийного восстановления корпорации Майкрософт стоит рассмотреть вариант применения доставки журналов с использованием набора небольших пользовательских вспомогательных программ, снижающих административную нагрузку. Такая программа может выполнять резервное копирование и восстановление баз данных по очереди, чем устранять необходимость в запуске нескольких агентов доставки журналов. Обратите внимание, что в этом случае существует некоторая вероятность потери данных. Не существует встроенного решения, которое не требовало бы для полной сохранности данных ни общего хранилища данных, ни СУБД,.
Конечно, остается вопрос о том, как сервер MSCS будет обнаруживать отказ и осуществлять восстановление. Настройки MNS в кластере обычно не устраняют полностью потребность в общем хранилище данных, а просто устраняют потребность в выделенном номере логического устройства (LUN) для кворума. Единственный способ реализовать эту схему — настроить кластер на управление только IP-адресами и сетевыми именами. SQL Server не может быть кластеризован без общего хранилища данных, поэтому невозможно кластеризовать SQL-службу, что означает, что кластер не сможет обнаруживать и отслеживать службы SQL Server в типовой конфигурации.
Службу SQL Server можно кластеризовать, добавив ее в качестве обычной службы, которую нужно отслеживать, но тогда возникает проблема с восстановлением при отказе: в случае кластеризации данной службы сервер MSCS будет пытаться при восстановлении при отказе запустить эту службу на пассивном узле, но какая-то SQL-служба уже будет на нем запущена. Конечно, его можно использовать для простой кластеризации IP-адресов и сетевых имен, а затем в случае необходимости осуществлять восстановление при отказе вручную. То же самое можно выполнять с помощью службы NLB (Network Load Balancing — балансировка сетевой нагрузки), что используется в других случаях. Подробнее см. в статье microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog04.mspx.
Учитывая количество баз данных, которые нужно поддерживать, более удачным решением может быть доставка журналов. Конечно, в этом случае нужно будет автоматизировать данный процесс с помощью пакета служб DTS/SSIS, иначе выполнение резервного копирования вручную, перемещение и применение активных журналов при отказе может занять слишком много времени.

Благодарим за технические консультации следующих специалистов по информационным технологиям корпорации Майкрософт: Бориса Барышникова (Boris Baryshnikov), Чэда Бойда (Chad Boyd), Алана Доби (Alan Doby), Патрика Галлуччи (Patrick Gallucci), Синди Гросс (Cindy Gross), Чака Лэдда (Chuck Ladd), Пэт Мартин (Pat Martin), Випула Шаха (Vipul Shah), Нельсона Таггарта (Nelson Taggart), Картик Тамхейн (Kartik Tamhane), Кена Тэннера (Ken Tanner), Чака Тимона (Chuck Timon), Джоржа Уолтерса (George Walters), Кевина Уоррена (Kevin Warren) и особенно Бака Вуди (Buck Woody).


 Обзор служебных программ: Средства PowerToy для запуска сценариев с повышенными правами в Windows Vista
Обзор служебных программ Средства PowerToy для запуска сценариев с повышенными правами в Windows Vista and Майкл Мерголо (Michael Murgolo)
Загрузить исходный код для этой статьи: Utility2007_06.exe (159KB)
Хотя управление учетными записями пользователей — серьезный шаг вперед в безопасности, возможность повышать разрешения является очень важной для выполнения определенных административных задач и функций. В этой статье представлено несколько средств PowerToy для повышения прав, которые делают повышение более мощным и гибким.
В операционной системе Windows Vista представлено множество средств решения вопросов безопасности, и управление учетными записями пользователей (UAC) — одно из самых значительных. При использовании UAC даже пользователи с правами администратора выполняют большинство приложений с правами обычного пользователя, но обладают “потенциалом повышения прав” для выполнения определенных административных задач и
функций приложений. После использования Windows Vista™ в течение нескольких месяцев повышение прав (при необходимости) задач или приложений становится привычкой. Однако когда я попытался повысить права некоторых типов задач в Windows Vista, я столкнулся с множеством проблем. Эти неудачи меня очень разочаровали.
Поэтому я, в духе старых средств Windows® PowerToy, создал несколько новых инструментов PowerToy для запуска сценариев с повышенными правами. Найти все средства, о которых я собираюсь рассказать, можно в материалах для загрузки по адресу technetmagazine .com/code07.aspx. А почитать о том, как работает UAC, можно в статье “Мечта о работе с правами обычного пользователя достигается с помощью UAC”, написанной в ноябре 2006 г. Алексом Хитоном (Alex Heaton) (см. колонку “Дополнительные материалы”).

Средство Elevate Command PowerToy
Первым неудобством было отсутствие способа повысить права приложения из командной строки или из диалогового окна “Запуск программы”. Поспрашивав людей в Майкрософт, я нашел сценарий, написанный Джоном Стивенсом (John Stephens), инженером по разработке программного обеспечения корпорации Майкрософт. В сценарии я обнаружил то, что мне было нужно. Оказывается, если передать команду “runas” API-функции ShellExecute или ее COM-эквиваленту, методу ShellExecute объекта Shell.Application, запущенное приложение выведет запрос на повышение прав (подробнее см. в боковой панели). Это позволило мне создать первое средство PowerToy для повышения прав — Elevate Command PowerToy.
Это средство (состоящее из файлов ElevateCommand.inf, elevate.cmd и elevate.vbs) добавляет в систему команду elevate. Это позволяет из командной строки, сценария или диалогового окна “Запуск программы” запускать приложения с запросом на повышение прав. Например, следующая команда открывает файл Win.ini в Блокноте (после вывода запроса на повышение прав):
elevate notepad c:\Windows\Win.ini
При использовании команды elevate с сервером сценариев Windows (WSH), оболочкой Windows PowerShell™ или другими сценариями необходимо в качестве запускаемого приложения указать исполняемый файл сервера сценариев (например wscript, cscript или powershell). Так, для запуска VBS-файла нужно использовать такой код:
elevate wscript “C:\windows\system32\
slmgr.vbs” –dli
Рис. 2Командные строки с повышенными правами

Установка и реализация
Для установки этих средств PowerToy щелкните правой кнопкой мыши файл INF, выберите “Установить” и подтвердите повышение прав. Для удаления используйте пункт панели управления “Программы и компоненты”.
Если вы будете изучать файлы INF более подробно и заинтересуетесь, почему три средства PowerToy устанавливают файлы elevate.cmd и elevate.vbs в разные места, поясняю. Большинство средств PowerToy реализуются путем добавления подраздела runas в раздел HKEY_CLASSES_ROOT\objecttype\Shell для типа объекта в реестре.
Однако для некоторых средств PowerToy существовали типы объектов, в которых я хотел использовать два пункта контекстного меню, которые вызывают повышение прав (“CMD Prompt Here as Administrator” и “PowerShell Prompt Here as Administrator” для типов объектов Drive и Directory; “Run as Administrator” и “Run as Administrator with Command Prompt” для всех типов объектов WSH). Так как у каждого типа объекта может быть только один подраздел runas, для вызова команды elevate я должен был реализовать второе действие. Но так как я хотел, чтобы каждый файл INF можно было устанавливать и удалять независимо, я должен был разместить соответствующие копии elevate.cmd и elevate.vbs в разных местах. (Увеличивать значения счетчиков использования файлов из простого файла INF невозможно. Конечно, лучше было бы использовать MSI-установщики, но я хотел иметь такие, которые можно создавать и изменять с помощью текстового редактора.) Одним из побочных эффектов является тот факт, что значок защиты будут содержать только пункты контекстного меню, реализованные с помощью подраздела runas.

Заключение
Я надеюсь, что эти средства будут полезными для вас и улучшат впечатление от использования UAC. Возможно, они вдохновят вас на создание собственных средств PowerToy. (Те, кто использует в Windows Vista другие языки сценариев, например Perl или Python, также легко смогут создать PowerToy для повышения прав сценария и с помощью этих языков.) Как и все средства PowerToy, они не поддерживаются: это средства “на свой страх и риск”. В любом случае, не скучайте, повышая права!
Дополнительные материалы
  • Мечта о работе с правами обычного пользователя достигается с помощью UAC
  • Обзор управления учетными записями пользователей
  • Повышение прав с помощью ShellExecute
  • Метод ShellExecute
  • Команды и сопоставление файлов
  • Старая игрушка опять пригодилась


 Кабельщик: Протокол SSTP
Кабельщик Протокол SSTP and Джозеф Дэвис (Joseph Davies)
Эта статья основана на предварительной версии Windows Server под кодовым именем «Longhorn». Любая содержащаяся в ней информация может быть изменена.
Протоколы VPN в Windows XP и Windows Server 2003 не работают в некоторых конфигурациях. Получите представление о возможных проблемах и о том, как Windows Server «Longhorn» и Windows Vista с пакетом обновления 1 (SP1) решают их при помощи протокола SSTP.
Благодаря поддержке виртуальных частных сетей (VPN) в Windows XP и Windows Server 2003 можно соединяться с частной интрасетью через Интернет так, словно компьютер подключен к локальному Ethernet-порту. Но протоколы VPN в Windows XP и Windows Server 2003 не работают при определенных настройках брандмауэра,
а также в некоторых случаях непрямого доступа, например когда компьютер находится за службой NAT или веб-прокси, — тогда трафик VPN-соединений блокируется. Для разрешения этих проблем в следующую версию Windows Server® под кодовым именем «Longhorn» и Windows Vista™ с пакетом обновления SP1 (обе в стадии тестирования) включена поддержка нового протокола Secure Socket Tunneling Protocol (SSTP, протокол безопасного туннелирования сокетов).

Проблемы доступа через VPN
В Windows® XP и Windows Server 2003 подключение к интрасети через Интернет обеспечивается протоколами VPN — туннельным протоколом точка-точка (PPTP) и туннельным протоколом уровня 2 с защитой протокола IP (L2TP/IPsec). Они инкапсулируют пакеты, передающиеся между клиентом удаленного доступа и интрасетью, к которой тот подключен.
VPN-трафик, основанный на PPTP, состоит из TCP-соединения на порт 1723 VPN-сервера для поддержания самого туннеля и инкапсулированных протоколом GRE пакетов VPN-данных. Но PPTP-трафик может конфликтовать с брандмауэрами, NAT и веб-прокси. Чтобы предотвратить возможные проблемы, в брандмауэре следует разрешать и TCP-соединение, и инкапсулированные в GRE данные. Хотя GRE — стандартный метод инкапсуляции IP-пакетов, многие поставщики услуг Интернета блокируют такие пакеты, и данные теряются. Кроме того, линии связи в отелях и интернет-кафе часто настроены на пропуск обычного веб- и почтового трафика, но не PPTP. Это не все — если компьютер находится за NAT, сам механизм NAT должен быть способен переадресовывать GRE-трафик. В противном случае удастся установить TCP-соединение, но инкапсулированные в GRE данные не смогут пройти ни туда, ни обратно. Наконец, PPTP-трафик не может идти через веб-прокси.
Другой протокол VPN, имеющийся в Windows XP и Windows Server 2003, — L2TP/IPsec — использует протокол IKE для обеспечения ESP-защиты VPN-трафика, и точно так же может конфликтовать с брандмауэрами, NAT и веб-прокси.
Для его работы брандмауэр надо настроить на разрешение IKE-трафика и инкапсулированных в ESP данных. Если VPN-клиент находится за NAT, и клиент, и VPN-сервер должны поддерживать IPsec NAT-Traversal (NAT-T). При этом VPN-сервер не может размещаться за NAT, а L2TP/IPsec-трафик не может идти через веб-прокси.

Новый взгляд на VPN
Как нетрудно заметить, работа протоколов VPN в Windows XP и Windows Server 2003 сопряжена с определенными трудностями. Но поддержка протокола SSTP в Windows Vista с пакетом обновления 1 (SP1) и Windows Server «Longhorn» разрешит их благодаря использованию HTTP через SSL. Протокол SSL известен также под названием TLS. HTTP через SSL на TCP-порт 443 — протокол, уже некоторое время применяемый в Интернете для передачи закрытых данных, например номеров кредитных карт. Если веб-адрес начинается с «https:», значит, используется HTTP через SSL.
Использование этого протокола решает многие проблемы подключения VPN. Брандмауэры, NAT и веб-прокси обычно разрешают прохождение такого трафика, поскольку его распространенность очень высока.
Протокол SSTP для обмена инкапсулированными пакетами IPv4 и IPv6 использует сеанс HTTP через SSL, установленный между VPN-клиентом и сервером. Обратите внимание, что VPN-соединение, основанное на HTTP через SSL, отличается от соединения, устанавливаемого приложением, использующим HTTP через SSL. Например, веб-клиент Outlook® позволяет получать доступ через Интернет к корпоративной электронной почте на сервере Microsoft Exchange. Клиент устанавливает зашифрованный сеанс HTTP через SSL, но это не то же самое, что соединение удаленного доступа. Он позволяет просматривать почту, но не поддерживает возможность перейти по ссылкам, ведущим на внутренние адреса интрасети.
(SSTP не поддерживает веб-прокси с проверкой подлинности, где прокси требует такую проверку во время HTTP-запроса на соединение.)
Имеющаяся в Windows реализация HTTP через SSL может существенно снизить затраты на поддержку удаленного доступа. Например, уменьшается количество звонков в службу поддержки и ликвидируются проблемы, связанные с помещением VPN-серверов за NAT. И поскольку SSTP работает практически везде, пользователи не испытывают трудностей и не отвлекаются от работы.
Поскольку поддержка SSTP встроена в Windows, вам не придется беспокоиться об установке и настройке на сервере и на клиенте программного обеспечения VPN сторонних разработчиков. Кроме того, SSTP обеспечивает лучшую балансировку нагрузки VPN-соединений благодаря использованию существующих систем балансировки SSL.
Новые возможности SSTP
  • В SSTP встроена поддержка защиты сетевого доступа (NAP), позволяющая полнее защитить ценные ресурсы сети благодаря обеспечению принудительного соответствия требованиям к уровню работоспособности системы. Подробнее о NAP см. microsoft.com/nap.
  • Кроме того, SSTP поддерживает передачу по SSTP-туннелю «родного» трафика IPv6, а также основанные на IPv6 SSTP-соединения в рамках Интернета IPv6.
  • Далее, в рамках SSTP от SSTP-клиента к SSTP-серверу устанавливается единственный сеанс HTTP через SSL. VPN-решения сторонних разработчиков, основанные на SSL, используют два сеанса. Использование единственного сеанса обеспечивает меньшую загрузку сети и лучшую балансировку нагрузки.
  • Наконец, SSTP полностью интегрирован в клиентские VPN-компоненты Windows Vista с пакетом обновления 1 (SP1) и Windows Server «Longhorn», а также в «Маршрутизацию и удаленный доступ» в Windows Server «Longhorn». SSTP — еще один протокол VPN, для которого доступны те же протоколы проверки подлинности и способы настройки, например папка «Сетевые подключения» и диспетчер подключений, использовавшиеся для подключений на базе PPTP или L2TP/IPsec.
В отличие от протоколов PPTP и L2TP/IPsec в Windows XP и Windows Server 2003, SSTP не поддерживает VPN-подключения типа «сеть-сеть».

SSTP в Windows
Компьютер под управлением Windows Server «Longhorn» с включенной маршрутизацией и удаленным доступом может выступать VPN-сервером SSTP. Устанавливать сервер IIS не нужно, поскольку компонент «Маршрутизация и удаленный доступ» отслеживает входящие соединения на конкретный уникальный код ресурса (URI) /sra_{BA195980-CD49-458b-9E23- C84EE0ADCD75}/. Но этот компонент и сервер IIS могут сосуществовать.
Компьютер под управлением Windows Vista (с учетом улучшений, добавляемых будущим пакетом обновления 1, запланированным к выходу в этом году) или Windows Server «Longhorn» является VPN-клиентом SSTP, способным инициировать SSTP-соединения с VPN-сервером SSTP. SSTP-сервер должен обладать сертификатом компьютера с установленными свойствами «Проверка подлинности сервера» или «Улучшенный ключ». Этот сертификат используется SSTP-клиентами для проверки подлинности SSTP-сервера при установлении сеанса SSL. SSTP-клиент проверяет сертификат компьютера SSTP-сервера. Чтобы этот сертификат прошел проверку, на SSTP-клиенте должен быть установлен корневой центр сертификации (CA) центра сертификации, выпустившего сертификат SSTP-сервера.
На рис. 1 сравниваются параметры различных протоколов VPN в Windows Server «Longhorn» и Windows Vista с пакетом обновления 1. Возможности SSTP описаны на боковой панели «Новые возможности SSTP».
Figure 1 Сравнение различных протоколов VPN (Close Figure 1)

Атрибут | PPTP | L2TP/IPsec | SSTP
Инкапсуляция | GRE | L2TP через UDP | SSTP через TCP
Шифрование | Point-to-Point Microsoft (MPPE) RC4 | IPsec ESP с алгоритмом тройного DES (3DES) или AES | SSL с алгоритмом RC4 или AES
Протокол поддержки туннеля | PPTP | L2TP | SSTP
Момент проверки подлинности пользователя | Перед началом шифрования | После установления сеанса IPsec | После установления сеанса SSL
Сертификаты, необходимые для установления туннеля VPN | Нет | Сертификаты компьютеров у VPN-клиента и VPN-сервера | Сертификат компьютера на VPN-сервере и сертификат корневого центра сертификации на VPN-клиенте

Как работает SSTP
Когда компьютер под управлением Windows Server «Longhorn» или Windows Vista с пакетом обновления 1 инициирует VPN-соединение SSTP, происходит следующее:
  1. SSTP-клиент устанавливает TCP-соединение с SSTP-сервером на динамически выбранном TCP-порте на стороне клиента и TCP-порте 443 на стороне сервера;
  2. SSTP-клиент отправляет SSL-сообщение Client-Hello, обозначая свое намерение создать сеанс SSL с SSTP-сервером;
  3. SSTP-сервер отправляет свой сертификат компьютера SSTP-клиенту;
  4. SSTP-клиент проверяет полученный сертификат, определяет метод шифрования, используемый для сеанса SSL, генерирует ключ сеанса SSL и шифрует его открытым ключом сертификата SSTP-сервера;
  5. SSTP-клиент отправляет зашифрованный ключ сеанса SSL SSTP-серверу;
  6. SSTP-сервер расшифровывает полученный ключ закрытым ключом своего сертификата компьютера. Все дальнейшие сообщения будут шифроваться полученным методом шифрования и ключом сеанса SSL;
  7. SSTP-клиент отправляет SSTP-серверу запрос по HTTP через SSL;
  8. SSTP-клиент и SSTP-сервер организуют между собой SSTP-туннель;
  9. SSTP-клиент и SSTP-сервер организуют между собой PPP-подключение. При этом производится проверка учетных данных пользователя методом проверки подлинности PPP, а также устанавливаются настройки, соответствующие трафику IPv4 или IPv6;
  10. SSTP-клиент начинает отправлять трафик IPv4 или IPv6 по соединению PPP.
На рис. 2 показана структура пакетов IPv4 или IPv6, отправляемых по VPN-соединению, основанному на SSTP.
Рис. 2Структура SSTP-пакетов
Пакет IPv4 или IPv6 сначала объединяется с заголовком PPP и заголовком SSTP. Получившаяся комбинация шифруется ключом сеанса SSL. Добавление заголовка TCP и заголовка IPv4 (для SSTP-соединений через Интернет IPv4) или заголовка IPv6 (для SSTP-соединений через Интернет IPv6) завершает формирование пакета.
Подробнее об SSTP можно узнать в блоге «Маршрутизация и удаленный доступ» по адресу blogs.technet.com/rrasblog.


 Windows PowerShell: Работа со службой Active Directory
Windows PowerShell Работа со службой Active Directory and Дон Джонс (Don Jones) Среда Windows PowerShell не предоставляет командлет Get-ADSIObject, но это не мешает ей обеспечивать хорошую поддержку интерфейсов ADSI. Познакомьтесь с адаптерами типов и узнайте, как пользоваться средой Windows PowerShell при работе с объектами службы каталогов.
Каждый, кто хоть сколько-то испытывал среду Windows PowerShell, обязательно попробовал воспользоваться командлетом Get-WMIObject, также известным под удобным псевдонимом gwmi. Как я описывал в своей статье в прошлом месяце, этот командлет отражает основное усовершенствование среды Windows PowerShell по сравнению с предыдущими языками сценариев и
оболочками командной строки (см. technetmagazine.com/issues/2007/05/PowerShell). Gwmi обеспечивает простой быстрый доступ к инструментарию управления Windows® (WMI), позволяя выполнять невероятное количество задач и при этом устраняя необходимость в написании сложных сценариев.
Командлет Get-WMIObject является настолько хорошим примером возможностей среды Windows PowerShell™, что при каждой его демонстрации в классе учащиеся непременно распространяют его функциональные возможности на другие области администрирования операционной системы Windows. Один из первых вопросов, которые мне обычно задают, сводится примерно к следующему: “А есть командлет Get-ADSIObject?”.

Поддержка интерфейсов ADSI в среде Windows PowerShell
Аббревиатура ADSI расшифровывается как «Active Directory® Services Interface» (интерфейс службы каталогов Active Directory). Несмотря на название, интерфейсы ADSI не предназначены исключительно для службы Active Directory. Более точным прочтением было бы «активный интерфейс служб каталогов», потому что интерфейсы ADSI могут связываться с множеством служб каталогов, включая каталоги в стиле ОС Windows NT®, и не только с доменами Windows NT, но и с локальным диспетчером SAM (Security Accounts Manager — диспетчер учетных записей безопасности) на входящих и не входящих в домен компьютерах. При такой гибкости командлет Get-ADSIObject наверняка невероятно полезен. К сожалению, группа разработки среды Windows PowerShell не смогла «втиснуть» этот командлет в ее первую версию.
Однако это не говорит о том, что в среде Windows PowerShell отсутствует поддержка интерфейсов ADSI. Фактически, в ней настолько хорошо реализована эта поддержка, что об отсутствии командлета Get-ADSIObject можно даже не вспоминать!
Все начинается с адаптера типов [ADSI]. Понятие «адаптер типов» следует немного объяснить. Вспомните: среда Windows PowerShell построена на платформе Microsoft® .NET Framework (2.0 или более поздней версии, если быть точным). В результате в среде Windows PowerShell практически всё (от объектов инструментария WMI до файлов и папок) представляется в виде объектов Framework. Однако группа разработки Windows PowerShell не решилась предоставить администраторам ОС Windows прямой доступ к объектам Framework. Например, многие такие объекты работают в каком-то смысле непоследовательно, а основной задачей проектирования Windows PowerShell было обеспечение последовательности. Еще одной причиной было то, что объекты Framework являются слишком мощным средством для администрирования Windows, а при разработке среды Windows PowerShell одним из основных критериев была простота. В результате появились адаптеры типов.
Как можно понять из названия, адаптер типа преобразует тип объекта .NET Framework в более последовательный, а иногда и более простой формат. Например, вы создаете новую строковую переменную:
[string]$var = “Hello”
При этом используется экземпляр типа System.String, обрабатываемый адаптером .NET. Адаптер типа [ADSI] подключен к классам DirectoryServices в .NET Framework, включая тип DirectoryEntry.

Извлечение объектов из службы каталогов
Подключиться к объектам службы каталогов весьма просто. Например, для подключения к пользователю по имени Don из подразделения IT домена Contoso.com необходимо воспользоваться примерно таким кодом:
$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”
Если вы работали с интерфейсами ADSI на языке VBScript или другом языке, код покажется вам довольно знакомым. Это стандартная строка запроса протокола LDAP, являющегося собственным средством доступа службы Active Directory. Нет необходимости указывать имя контроллера домена или любые иные подробные данные; в этом полном доменном имени (FQDN) содержится достаточно информации для нахождения контроллера домена и извлечения объекта (предполагается, конечно же, наличие соответствующих полномочий).
Работа с локальными учетными записями безопасности сводится почти к тому же, но вместо поставщика LDAP используется поставщик WinNT:
$user = [ADSI]”WinNT://don-pc/don”
Обратите внимание, что в моникерах LDAP и WinNT учитывается регистр. Хотя сама среда Windows PowerShell в общем случае регистр не учитывает, эти ресурсы интерфейсов ADSI учитывают, поэтому необходимо обращать внимание на регистр ввода.
На рис. 1 показано, что произойдет, если взять полученную в результате переменную $user и передать ее Get-Member. Будет получен список свойств этого объекта. К сожалению, это не полный список всех свойств объекта, и он не включает его методы. Лежащий в основе данной процедуры класс Framework System.DirectoryServices.DirectoryEntry работает в этом плане немного странно, а среда Windows PowerShell может отображать только то, что ей выдает класс Framework.
Рис. 1Извлечение списка свойств объекта
Извлечение объектов в основном требует знания того, как построить строку запроса. Поставщик WinNT достаточно прост в использовании. Просто указывается имя компьютера или домена, ставится косая черта и затем имя объекта. Эта методика хорошо работает с доменами службы Active Directory (которые, в конечном итоге, имеют обратную совместимость с доменами Windows NT). И, фактически, использование поставщика WinNT для извлечения объектов службы Active Directory иногда является самым простым путем, так как поставщик WinNT выдает неструктурированное представление домена. Это означает, что не нужно знать, в каком подразделении (OU) расположен объект, потому что поставщик WinNT не видит подразделения.
Для извлечения объектов LDAP необходима в некоторой степени большая точность. В начале идет информация, наиболее точно указывающая объект, например каноническое имя объекта или названия подразделения (OU). Затем — полный путь к объекту, начиная с его родительского контейнера и заканчивая самим доменом. Например, пользователь Don, который находится в подразделении Sales, входящем в подразделение West домена Contoso.com, будет выглядеть следующим образом:
LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com
Этот формат требует определенного навыка и знания расположения объекта. На рис. 2 приведена сводка различных составляющих полного доменного имени.
Figure 2 Компоненты полного доменного имени (FQDN) (Close Figure 2)

Компонент | Назначение | Пример
cn | Каноническое имя объекта. Также используется для не являющихся подразделениями (OU) контейнеров, например пользователей и компьютеров. | cn=Don
ou | Подразделение. | ou=Sales
dc | Компонент доменного имени. Каждый компонент доменного имени службы DNS получает имеет собственный компонент “dc=”. | dc=domain, dc=com

Немного помощи от друга
Для создания и удаления объектов обычно необходимо сначала выполнить подключение к контейнеру объекта, например подразделению, а затем обратиться к этому контейнеру с запросом о создании или удалении объекта. Я постоянно забываю правильный синтаксис, но, к счастью, группа Microsoft Scripting Guys всегда протянет руку помощи в виде программы ADSI Scriptomatic.
Хотя изначально эта программа создавалась для языка VBScript, она остается полезным руководством для среды Windows PowerShell, так как фактический синтаксис интерфейса ADSI тот же. Например, после загрузки этого инструмента я выбираю вариант создания нового пользователя. Я игнорирую весь генерируемый этим средством код, заканчивая кодом «End connect to a container», который выглядит следующим образом:
Set objUser =
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo
Перевод в код среды Windows PowerShell прост. Сначала я подключаюсь к контейнеру, в котором хочу создать пользователя. Чтобы сохранить единообразность с кодом Scriptomatic, я буду использовать для представления подразделения переменную $objContainer. Я также создам переменную $strName для хранения имени нового пользователя:
$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”
Затем скопирую из Scriptomatic код, удалю все следы любых инструкций Set языка VBScript и добавлю к именам переменных символ “$”:
$objUser = $objContainer.Create(“user”,
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()
Вот и все, что нужно сделать. В подразделении Test домена Contoso .com создан новый пользователь.

Изменение объектов службы каталогов
После подключения к объекту (например пользователю или группе) его можно изменять. Используя поставщик WinNT, можно напрямую изменять многие свойства, например показанные на рис. 1. Так, чтобы отобразить и затем изменить свойство «Description» пользователя, следует выполнить:
Write-Host $user.Description
$user.Description = “New Description”
$user.SetInfo()
При этом важно помнить, что изменения свойств выполняются в локальном кэше свойств, являющемся временной зоной хранения, которая поддерживается на вашем компьютере интерфейсами ADSI. При вызове метода SetInfo кэш записывается обратно в домен или на компьютер, из которого был извлечен объект, т.е. изменения фактически сохраняются в службу каталогов.
Объекты службы Active Directory не предоставляют свойства для большинства атрибутов объектов. Вместо этого можно использовать методы Get и Put:
Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()
Объектам поставщика WinNT свойственна значительная упрощенность, так как службы каталогов Windows NT не хранят много информации о таких объектах, как пользователи и группы. В службе Active Directory, напротив, хранится большое количество информации, и выяснить правильные имена атрибутов может быть непросто. Например, при желании изменить фамилию пользователя необходимо изменять свойство «Sn». Почему «Sn»? Это сокращение от слова «surname» (фамилия).
К счастью, корпорация Майкрософт предоставляет хорошую систему перекрестных ссылок, расположенную по адресу msdn2.microsoft.com/ms677286.aspx. В этих справочных материалах приводятся имена атрибутов для каждой существенной области консоли «Пользователи и компьютеры» службы Active Directory, так что, зная, как изменить что-то через консоль, можно узнать и имя стоящего за этим атрибута. Более полная система перекрестных ссылок для перехода от элементов консоли к именам атрибутов содержится в книге «ADSI Scripting: TFM» («Программирование ADSI: TFM»), автор Кейд Фэссетт (Cade Fassett), издательство SAPIEN Press, 2007 г.

Что сделать не получится
К сожалению, поддержка интерфейсов ADSI в среде Windows PowerShell не настолько крепка, как поддержка других технологий, например инструментария WMI. Например, довольно непросто перечислить членов групп локального компьютера. При работе со службой Active Directory также выявляется ряд сложных ситуаций. По своему опыту могу отметить, что извлечение, создание и удаление основных объектов работает нормально. Изменение свойств объектов работает достаточно хорошо, хотя к некоторым свойствам получить доступ не удается. Наибольшие сложности у меня возникли при работе с локальными объектами и группами через поставщика WinNT.
Но нельзя сказать, что ряд операций вообще нельзя выполнить. Просто некоторые операции выполняются более сложно или менее интуитивно. Вот например:
$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com”
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”)
$group.psbase.CommitChanges()
Этот код добавляет пользователя User1 в группу Techs. Начало кода достаточно понятное. С помощью полного доменного имени извлекается группа. Затем, чтобы добавить полное доменное имя нужного пользователя, используется коллекция Member этой группы, а точнее ее метод Add. Однако последний шаг не так уж интуитивен. Для сохранения изменений вызывается метод CommitChanges скрытого класса PSBase.
PSBase — особый класс, непосредственно представляющий нижележащий объект .NET Framework. В этом случае в среде Windows PowerShell нет непосредственного доступа к методу CommitChanges (фактически, адаптер ADSI не представляет доступа ни к каким методам), так что необходимо обращаться к лежащему в основе классу. Это не невозможно, но и не интуитивно. Хорошая иллюстрация того, что возможности служб каталогов еще не полностью внедрены в среду Windows PowerShell.
Тому есть ряд объяснений. Прежде всего, группа разработки среды Windows PowerShell добавила в оболочку текущую поддержку интерфейсов ADSI на довольно поздней стадии цикла разработки. Как часто говорит архитектор оболочки Джеффри Сновер (Jeffrey Snover), «чтобы начать поставки, надо выбрать». Группа располагает ограниченным временем на разработку и выпуск оболочки, поэтому ее члены должны принимать решения о том, что нужно оставить для следующей версии. Иначе бы они тратили годы на добавление функциональных возможностей и так никогда не выпустили бы поддерживаемый продукт.
Еще одна причина, однако, — лежащий в основе .NET Framework. Его класс DirectoryServices достаточно сложен, и адаптация этой сложности для среды Windows PowerShell заняла бы много времени и потребовала бы тщательного планирования. Классы Framework, по-моему, тоже в большей степени рассчитаны на работу со службой Active Directory и не обеспечивают выдающейся поддержки поставщика WinNT. Среда Windows PowerShell, конечно же, наследует эти ограничения от Framework.
Я ожидаю весьма значительное расширение поддержки служб каталогов в Windows PowerShell. И эта поддержка, может быть, даже будет осуществляться не через уровень интерфейсов ADSI, а через базовые улучшения .NET Framework. А пока существующая в Windows PowerShell поддержка интерфейсов ADSI позволяет выполнять большинство административных задач, например создавать пользователей, изменять их основные свойства и т.д.
Не забывайте, что многие связанные со службами каталогов задачи могут быть выполнены через инструментарий WMI. Несколько отличных примеров использования инструментария WMI для предоставления более обширной информации о локальной группе, чем предоставляют сами интерфейсы ADSI, см. в сценариях, расположенных по адресу microsoft.com/technet/scriptcenter/scripts.


 Эй, скриптоман!: Вокруг волнистой красной линии
Эй, скриптоман! Вокруг волнистой красной линии and Сценаристы-скриптоманы
Загрузить исходный код для этой статьи: HeyScriptingGuy2007_06.exe (151KB)
Ищете более простой способ добавления терминов в словарь приложения Microsoft Word, чем внесение по одному слову вручную? Вы не одиноки! В этом месяце скриптоманы продемонстрируют, как создавать в приложении Microsoft Word пользовательские словари и как программно настраивать Word для их использования.
Рис. 1Показаны орфографические ошибки в документе, открытом в Word.
Заметили что-то необычное? Правильно: Word подчеркнул волнистыми линиями термины программирования, такие как Msgbox. Почему? Потому что Word не распознает эти термины. Не распознает эти термины? Просто поразительно. В конце концов, за последние несколько лет программисты напечатали термин Msgbox несколько миллионов раз. Еще несколько миллионов раз они проверяли правописание, и подтверждали, что термин Msgbox написан правильно. И все же программа отмечает термины Msgbox, StrReverse и LTrim как неправильно написанные слова? Как же так?
Пока вы не бросились в защиту Word: конечно нам известно, что можно вручную добавить эти термины в его словарь. Но мы же скриптоманы (мы готовы кричать об этом), что нам известно о ручном труде? Кроме того, добавление вручную названий функций языка VBScript и классов инструментария управления Windows® (WMI), а также атрибутов объектов интерфейсов безопасности службы Active Directory® (ADSI) может быть как минимум несколько утомительным. А что, если мы хотим выполнить это на всех наших компьютерах? Что, если мы хотим поделиться правильным написанием слов со своими преданными читателями? Что, если... в общем, вы поняли.
Смысл вот в чем: конечно же должен существовать более простой способ добавления в словарь скриптоманских терминов (и всех остальных терминов, собственного говоря), чем внесение по одному слову вручную.
Как выяснилось, такого способа нет. До встречи через месяц.
Эй, ладно, мы просто пошутили. Конечно же существует более простой способ добавления терминов в словарь. И через мгновение мы его покажем. Сначала, тем не менее, давайте уделим пару минут обсуждению словарей.
Кстати, говоря о словарях, можно отметить интересный факт. Почему американцы пишут слово «color» без буквы u («color», а не «colour»)? Почему американцы пишут «center»”, а не «centre»? Мы знаем, почему: потому что Ною Вебстеру (Noah Webster), составителю первого американского словаря, не нравились английские правила написания слов, так что он просто произвольно поизменял это написание.
Ну, да. Получилось скучновато. Но сами попробуйте рассказать интересную историю о словарях!
Кроме стандартного встроенного словаря, Microsoft Word также позволяет создавать любое количество пользовательских словарей. По умолчанию Word поставляется с пользовательским словарем Custom.dic, который обычно находится в папке Application Data\Microsoft\Proof, расположенной внутри папки профиля пользователя (в ОС Windows XP по умолчанию \Documents and Settings\имя_пользователя). Если щелкнуть правой кнопкой мыши по неправильно написанному слову и выбрать команду «Добавить в словарь», слово будет добавлено в словарь Custom.dic.
Как выясняется, Custom.dic — это старый добрый простой текстовый файл. Откройте его в программе Блокнот, и увидите примерно такой список слов:
Aaberg
Aalling
Abbas
Abercrombie
Abola
Abolrous
Abrus
А вот как можно программно добавлять скриптоманские термины в словарь приложения Microsoft Word. Всё, что необходимо сделать, — это создать текстовый файл с этими терминами, а затем настроить Word на использование этого файла в качестве пользовательского словаря. Насколько это сложно? Учитывая тот факт, что скриптоманы согласились сделать всё самостоятельно, очевидно, что это совсем не сложно.
Но подождите: прежде, чем приступить, необходимо еще раз ненадолго отклониться от темы. В объектной модели Microsoft Word информация о пользовательских словарях хранится в коллекции CustomDictionaries. В свою очередь программным способом доступ к этой коллекции можно осуществить, обратившись к объекту Word.Application и свойству CustomDictionaries. Например, на рис. 2 показан сценарий, возвращающий информацию обо всех пользовательских словарях, связанных с экземпляром Microsoft Word.
Figure 2 Сценарий, получающий данные из пользовательского словаря (Close Figure 2)
Set objWord = CreateObject(“Word.Application”)

Set colDictionaries = objWord.CustomDictionaries

For Each objDictionary in colDictionaries
  Wscript.Echo “Name: “ & objDictionary.Name
  Wscript.Echo “Language ID: “ & objDictionary.LanguageID
  Wscript.Echo “Language-specific: “ & objDictionary.LanguageSpecific
  Wscript.Echo “Location: “ & objDictionary.Path
  Wscript.Echo “Read-only: “ & objDictionary.ReadOnly
  intType = objDictionary.Type
  Select Case intType
    Case 0 Wscript.Echo “Type: Spelling”
    Case 1 Wscript.Echo “Type: Grammar”
    Case 2 Wscript.Echo “Type: Thesaurus”
    Case 3 Wscript.Echo “Type: Hyphenation”
    Case 4 Wscript.Echo “Type: Spelling (complete)”
    Case 5 Wscript.Echo “Type: Spelling (custom)”
    Case 6 Wscript.Echo “Type: Spelling (legal)”
    Case 7 Wscript.Echo “Type: Spelling (medical)”
    Case 8 Wscript.Echo “Type: Hangual-Hanja Conversion”
    Case 9 Wscript.Echo “Type: Hangual-Hanja Conversion (custom)”
  End Select
  Wscript.Echo
Next

objWord.Quit
Запустив приведенный на рис. 2 сценарий, вы получите информацию, аналогичную приведенной ниже:
Name: CUSTOM.DIC
Language ID: 0
Language-specific: False
Location: C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof
Read-only: False
Type: Spelling (custom)
Довольно ловко, не так ли?
Конечно, получение информации о существующих словарях не совсем то же самое, что и создание нового пользовательского словаря; это как разница между чтением о каком-то миллионере и обладанием миллионом долларов. Поэтому давайте посмотрим, сможем ли мы выяснить, как создать новый пользовательский словарь в текстовом редакторе Word.
Начнем с добавления всех функций языка VBScript в новый словарь, названный Scripting.dic. С функций языка VBScript мы начинаем потому, что для этого не нужно прилагать больших усилий. После этого, однако, мы покажем, как добавить в словарь классы инструментария WMI, атрибуты интерфейса ADSI и командлеты среды Windows PowerShell™, практически ничего при этом не делая. (Нет необходимости добавлять, что в том, как ничего не делать, скриптоманы разбираются очень хорошо.)
Для начала нужно создать в Microsoft Word пользовательский словарь, что несложно сделать следующим образом:
Set objWord = CreateObject _
  (“Word.Application”)

Set colDictionaries = _
  objWord.CustomDictionaries
colDictionaries.Add “Scripting.dic”

objWord.Quit
Как видите, сначала создается экземпляр объекта Word.Application. Возможно, вы обратили внимание, что мы не устанавливаем значение свойства Visible равным True, и, следовательно, не делаем текстовый редактор Word видимым на экране. Почему? Да просто потому, что выполнение этого сценария занимает около секунды. Поэтому нет особого смысла в том, чтобы Word на мгновение появился на экране и затем сразу исчез. Но при желании видеть его мигающие экземпляры (если нет иных причин, кроме как убедиться, что сценарий действительно что-то делает) достаточно просто добавить в качестве второй строки кода сценария следующее:
objWord.Visible = True
После создания объекта Word.Application для получения объектной ссылки на коллекцию CustomDictionaries необходимо воспользоваться следующей строкой:
Set colDictionaries = _
  objWord.CustomDictionaries
Затем нужно вызвать метод Add, чтобы добавить пользовательский словарь. Обратите внимание, что этот файл может и не существовать. Если Word не найдет файл Scripting.dic, он просто создаст новый, пустой файл с таким именем. Вот код добавления пользовательского словаря:
colDictionaries.Add “Scripting.dic”
Возможно, вы также обратили внимание, что при добавлении нового словаря мы не указывали путь. Вместо этого мы просто передали методу Add имя файла (Scripting.dic). Всё правильно. В подобном случае файл Scripting.dic будет создан в папке для словарей и других средств проверки текстов, установленной по умолчанию (например C:\Documents and Settings\kenmyer\Application Data\Microsoft\Proof).
А что, если бы мы хотели, чтобы наш словарь находился в другом месте? Нет проблем. Эта команда создает файл Scripting.dic в папке C:\Scripts:
colDictionaries.Add _
  “C:\Scripts\Scripting.dic”
А что, если в дальнейшем мы захотим избавиться от этого пользовательского словаря? Опять же, нет проблем. В этом случае мы можем обратиться к этому словарю и воспользоваться методом Delete, чтобы избавиться от него:
Set objWord = CreateObject _
  (“Word.Application”)
Set objDictionary = _
  objWord.CustomDictionaries _
  (“C:\Scripts\Scripting.dic”)
objDictionary.Delete

objWord.Quit
Рис. 3Документ в текстовом редакторе Word после добавления пользовательского словаря
Это весьма удобно, раз уж даже мы так считаем, особенно с учетом того факта, что файлом Scripting.dic и сценарием создания пользовательского словаря можно с кем-нибудь поделиться. Сделайте это, и без всяких усилий их версии Word также будут считать слово Msgbox написанным правильно. На самом деле, если бы мы, скриптоманы, были и правда ленивыми, то закончили эту ежемесячную колонку прямо сейчас, а вы все равно извлекли бы из нее какую-то пользу. Но, как говорится, всё еще впереди.
Примечание. Мы и правда ленивы. Но, видя, что нам необходимо чем-то заполнить остаток места, выделенного для этой статьи, мы решили добавить еще один или два дополнительных сценария.
Как вы, наверно, знаете, язык VBScript и сервер сценариев Windows немного стеснительны. Они не любят говорить о себе. Однако инструментария WMI, интерфейсов ADSI и среды Windows PowerShell это не касается. Нужно только спросить, и эти технологии сами многое расскажут о своих классах, свойствах, методах. Всё, что только можно захотеть узнать.
Возьмем, например, интерфейс ADSI. На рис. 4 показан сценарий, выполняющий привязку к схеме службы Active Directory и извлекающий все атрибуты объекта учетной записи пользователя. Затем эти атрибуты записываются в файл C:\Scripts\Scripting.dic.
Figure 4 Добавление имен атрибутов ADSI в пользовательский словарь (Close Figure 4)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

Set objSchemaUser = GetObject(“LDAP://schema/user”)

For Each strAttribute in objSchemaUser.MandatoryProperties
  objFile.WriteLine strAttribute
Next

For Each strAttribute in objSchemaUser.OptionalProperties
  objFile.WriteLine strAttribute
Next

objFile.Close
Видите, как это удобно? С помощью всего нескольких строк кода мы создали словарь, содержащий все атрибуты объекта «пользователь» службы Active Directory. Поделитесь этим кодом с друзьями-скриптоманами, и все вы больше никогда не будете беспокоиться из-за того, что такие имена атрибутов, как streetAddress или givenName, отмечаются как написанные с ошибками. И, конечно же, это бесконечно расширяемо. Хотите добавить свойства класса computer? Тогда подставьте эту строку текста программы:
Set objSchemaComputer = _
  GetObject(“LDAP://schema/computer”)
Или может классы инструментария WMI? На рис. 5 показан сценарий, извлекающий список всех классов инструментария WMI, найденных в пространстве имен root\cimV2, и записывающий эту информацию в файл C:\Scripts\Scripting.dic.
Figure 5 Добавление имен классов WMI в пользовательский словарь (Close Figure 5)
Const ForWriting = 2

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFSO.OpenTextFile(“C:\Scripts\Scripting.dic”, ForWriting)

strComputer = “.”

Set objWMIService=GetObject(“winmgmts:\\” & strComputer & “\root\cimv2”)

For Each objClass in objWMIService.SubclassesOf()
  objFile.WriteLine objClass.Path_.Class
Next

objFile.Close
Забыли о пользователях среды Windows PowerShell? Скриптоманы никогда так не поступят. Ну, если честно, мы и правда забыли о вас. Но мы вспомнили и приводим этот состоящий из одной строки сценарий, который возвращает все имена командлетов и записывает их в файл C:\Scripts\Scripting.dic:
Get-Command | Foreach-Object `
{Add-Content c:\scripts\scripting.dic -value `
$_.Name}
Что хорошо в статье этого месяца, так это то, что мы все извлекли из нее какой-то урок. Вы научились создавать в Microsoft Word пользовательские словари и программно настраивать Word для их использования. А мы, скриптоманы, узнали, что если есть желание что-то сделать, то лучше всего попытаться найти кого-то, кто сделает это за вас. Но если уж ничего не выходит, то всегда можно сделать всё самому.


 Материалы о рабочей среде: Как не потерять данные
Материалы о рабочей среде Как не потерять данные and Уэс Миллер (Wes Miller) Удивительно, как часто пропадают важные данные. Но на самом деле они пропадают потому, что люди плохо их защищают. Узнайте о важных шагах, которые стоит предпринять для защиты данных предприятия.
Информация жаждет быть свободной. Неважно, кому она вверена на сохранение и сколь тщательно закрыт доступ к этим нулям и единичкам — они обязательно найдут, где просочиться. Каждый день в новостях говорят о маленьких и больших потерях данных. Это просто нелепо, что важные данные теряются
Рис. 2Любовь к маме не оправдывает выбор такого пароля
Надежность пароля и локальная проверка подлинности очень важны, но все же нельзя считать данные защищенными, если они не зашифрованы или если доступ к ним не ограничен физически. Одними паролями проблему не решить. Пароль — лишь средство защититься от тех, кто хочет получить несанкционированный интерактивный доступ к системе, не используя специальных средств.

Физическая безопасность
Особо важные данные не должны располагаться на компьютере, к которому легко получить физический доступ или который легко унести с собой. Если вы боитесь, что ваши компьютеры могут пострадать от того, что кто-то загрузит Windows PE и получит с ее помощью данные, виновата в этом отнюдь не Windows PE. Виноваты следующие обстоятельства. Ваши компьютеры плохо защищены физически. Или защищены хорошо, но вы не доверяете пользователям, имеющим доступ к ним. Или данные расположены на компьютере, который не защищен (или не может быть защищен) физически. Или компьютеры вообще не могут быть физически защищены, и при этом не используются средства шифрования томов, например BitLocker™ в Windows Vista. (Подробнее о BitLocker см. в статье Байрона Хайнза (Byron Hynes) в этом же номере TechNet Magazine.)
Прикиньте, какие из компьютеров могут подвергаться опасности. Можно ли физически защитить их? Не поместить ли их в вычислительный центр или другое подобное место с ограниченным доступом? Если так сделать нельзя, или если это переносной компьютер, используется ли шифрование томов? Если никакой из этих шагов предпринять не удается, либо переместите данные на компьютер, который можно физически обезопасить, либо зашифруйте их. Если бы в упомянутом выше случае похищения переносного компьютера использовались средства шифрования томов, данные были бы практически недоступны для похитителя.
Сам факт помещения компьютера в вычислительный центр не гарантирует его безопасности. Если там имеется десяток выделенных линий доступа в Интернет, риск ничуть не уменьшается. Доступ через Интернет позволяет на шаг приблизиться к физическому доступу, так что не стоит недооценивать исходящие от него угрозы. Подумайте, не стоит ли переместить их в отдельный сегмент сети, где по крайней мере будет дополнительный слой защиты между Интернетом и этими компьютерами.

Снижение риска для данных
Другой возможный защитный ход — дать пользователям доступ к данным на физически защищенном сервере только через специальные приложения и «толстые» клиенты. Это может подразумевать и обеспечение доступа через VPN, чтобы охватить сотрудников, не находящихся в офисе. Никогда не следует подчинять расположение данных текущим обстоятельствам пользователя. Если он находится в месте, откуда нельзя получить высокоскоростной доступ к нужным данным, это отнюдь не причина перемещать их на его компьютер. Если же вы должны хранить данные на компьютере, который никак нельзя переместить в безопасное место, используйте шифрование томов.

Внутренняя безопасность компьютера
Следует быть готовым и к тому, что, несмотря на все ваши усилия, жесткий диск компьютера будет извлечен и подключен к другому компьютеру под управлением Windows, где списки ACL файловой системы NTFS можно сбросить.
Для борьбы с этой ситуацией используйте шифрование томов, включенное в Windows Vista. Для большинства других версий Windows есть соответствующие продукты сторонних разработчиков. Они отличаются сложностью использования, но могут шифровать весь том или отдельные файлы и каталоги в соответствии с возможностями файловой системы EFS. Если том зашифрован, получить находящиеся на нем данные сможет только специалист самого высокого класса.

Защита архивов
Данные резервного копирования тоже следует защищать. Большинство людей оправдывает отсутствие такой защиты двумя причинами: шифрование при резервном копировании отнимает слишком много времени или программное обеспечение не поддерживает такое шифрование.
Но если вы осуществляете резервное копирование компьютеров, и особенно если следуете передовым рекомендациям по изъятию резервных копий с рабочих машин, нужно обязательно защитить сами эти данные. Либо используйте файловую систему с шифрованием (EFS), если она доступна, либо другое ПО шифрования томов (например BitLocker в Windows Vista или ПО сторонних разработчиков), или приобретите программное обеспечение резервного копирования, поддерживающее шифрование достойного уровня. Данные нельзя считать защищенными лишь потому, что при резервном копировании они были хаотично разбросаны по магнитной ленте или жесткому диску. Следует исходить из того, что сам механизм записи будет взломан.

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

Надежное удаление
Все мы знаем о случаях, когда жесткие диски и иные накопители, купленные на аукционе eBay или на местных барахолках, проходили через специальную экспертизу, а то и через обычные средства восстановления файлов, в результате чего на свет всплывали данные, которые должны были быть полностью удалены перед продажей носителей.
Если у вас используются флэш-накопители USB, подумайте об использовании средств принудительного шифрования. Стоит шифровать диски, содержащие особо ценные данные. Я, вопреки распространенному мнению, не верю, что простого шифрования тома перед утилизацией достаточно. Помните сравнение с медицинскими отходами? Относитесь к таким данным как к опасным отходам, а к программам надежного удавления — как к средствам обеззараживания. Перед списанием жестких дисков или компьютеров на продажу, а то и просто перед перемещением их куда-то используйте инструменты удаления данных, соответствующие спецификациям министерства обороны США 5220.22-M, например программу SDelete Марка Руссиновича. В противном случае следующий владелец компьютера станет и владельцем всех данных предыдущего.

Аудит
Последний (но не по значимости) элемент защиты данных — аудит, а то и моделирование угроз, жизненного цикла данных в организации. Выявите слабые места, где возможна утечка данных, и тщательно наблюдайте за ними. В Windows есть различные встроенные средства аудита. При этом, однако, не стоит перебарщивать. Наблюдайте за теми областями, за которыми стоит наблюдать, и тогда сведений о наблюдениях не будет слишком много. Следите за слабыми местами и предпринимайте в них разумные меры предосторожности. Не залепляйте бреши в защите жвачкой. И обеспечьте должный уровень обученности пользователей тому, как обращаться с данными. Именно пользователи соединяют все уровни предприятия. Более подробное руководство см. на боковой панели «Дополнительные источники». Не забывайте следовать всем приведенным здесь рекомендациям, это сделает ваш сон крепче.
Дополнительные источники
«Основное руководство по оптимизации инфраструктуры — от начал к стандартизации» продемонстрирует, как поднять ИТ-инфраструктуру от начального уровня с высокой долей ручного труда и низкой стабильностью до стандартизированного уровня с большей степенью автоматизации, обязательными стандартами конфигурации и улучшенным ходом работы. Руководство можно загрузить по адресу go.microsoft.com/?linkid=5795711. «Дополнительные руководства по оптимизации инфраструктуры» см. на веб-узле microsoft.com/io. Дополнительные советы см. в статье «10 непреложных законов безопасности».


 Полевые заметки: Разговаривайте с разработчиками
Полевые заметки Разговаривайте с разработчиками and Дэвид Айкен (David Aiken) Заставить разработчиков создавать более управляемые приложения проще, чем кажется. Все дело в общении. Разработчики смотрят на программное обеспечение не с той же точки, что администраторы. Разговаривая с разработчиками, администраторы могут объяснить, что им важно получить, а разработчики уже воплотят это в коде.
Это странно, но разработчики смотрят на программное обеспечение не так, как администраторы. Разработчики имеют дело с кодом, проходами по стеку, XML-файлами настроек, идентификаторами GUID и сборками. Администраторы общаются со сценариями и оснастками консоли MMC (во всяком случае, хотели бы).
Небольшое отступление. Мне порой кажется, что весь процесс создания программного обеспечения никуда не годится. Мы тратим кучу сил и времени, чтобы определить, что нужно конечному пользователю. Мы создаем прототипы, проводим исследования удобства использования, берем интервью, делаем еще множество дел, но когда дело доходит до обеспечения простого, последовательного административного интерфейса, мы садимся в лужу. В очень большую лужу.
Я раньше думал, что Xcopy, Regedit и Notepad — лучшие средства для установки программного обеспечения. Теперь я знаю, что лучшее средство — установщик Microsoft (MSI), который можно настраивать, устанавливать и удалять. Я знаю, что было бы не лучшей идеей заставлять администратора настраивать веб-службу, редактируя XML «Блокнотом», и что оснастки MMC (или сценарии Windows PowerShell™) куда приятнее. Я знаю, что содержимое стека — не лучший способ представить администратору причину ошибки и возможные пути ее устранения, и что хорошо описанное событие в журнале приложения куда лучше. Я знаю, что для создания программного обеспечения, которым администраторы смогут пользоваться, нужно рассматривать их как пользователей.
Поставив этот знак равенства, можно вернуться к определению случаев использования, созданию прототипов, проведению исследований об удобстве использования и т.д. Тогда это позволит предоставить администраторам максимально возможное удобство работы. Другими словами, поможет им устанавливать, настраивать, отслеживать, разрешать вопросы и устранять неисправности, не звоня мне. Если я использую средства управления, встроенные в операционную систему, с которой они знакомы, я значительно снижаю затраты на сопровождение своего приложения (не возникает столько проблем), меньше раздражаю пользователей (приложение реже перестает работать и его легче вернуть в норму) и увеличиваю шансы, что купят мое программное обеспечение, а не ваше (что выливается в чудесную яхту на Карибском море).
Ладно, про яхту это я слишком. Но создание разработчиками более управляемых приложений — совсем не мечта, а вполне достижимая цель. И от вас это тоже зависит. В следующий раз, когда что-то пойдет не так, не надо просто посылать разработчикам электронное письмо и тихо говорить нехорошие слова. Вместо этого предложите им записывать событие в журнал приложения или завести счетчик производительности либо еще какой-нибудь индикатор неисправности. А лучше предложите возможную причину и решение. Попросите задействовать сценарий Windows PowerShell или консоль MMC для настройки приложения. На самом деле, разработчики не всегда знают, что вы вообще есть, не говоря уже о ваших нуждах. Просто дайте им знать.


 О Windows из первых рук: Что новые пользователи видят в меню “Пуск”
О Windows из первых рук Что новые пользователи видят в меню “Пуск” and Рэймонд Чен (Raymond Chen) Представьте себе картину: вы покупаете новый компьютер, запускаете Windows, нажимаете кнопку “Пуск” и обнаруживаете пустое меню. Вот поэтому разработчики Windows и включили в меню “Пуск” наиболее часто используемые приложения, обеспечивая пользователю, еще не запускавшему компьютер, хорошее впечатление от первого запуска. Давайте выясним, как выбираются эти приложения.
Мы подумали: а не заполнить ли изначально пустое меню “Пуск” текстом. Чем-нибудь вроде “Это место пока пустое, но как только вы запустите программу, она обязательно здесь появится”. Сказано — сделано. Меню больше не выглядело глупо. Теперь оно выглядело глупо и отвратительно.
Еще немного экспериментов, — и мы, наконец, остановились на том, что вы сейчас наблюдаете в Windows XP. В прошлом месяце вы видели, что список часто используемых программ строится на системе баллов — в этом динамическом списке появляются программы с наибольшим количеством баллов. Для новых пользователей мы искусственно добавили несколько баллов различным программам. В результате начальное меню “Пуск” представляет собой набор нескучных программ, которые дают пользователю некоторое представление о том, что может делать его компьютер.
Количество искусственных баллов тщательно подобрано таким образом, чтобы их хватило для попадания нужных программ в список часто используемых, но чтобы это количество не превышало реальные баллы, зарабатываемые программами при запуске приложений пользователем.
Однако эти искусственные баллы не предоставлялись при обновлении Windows 2000. В этом случае баллы, которые использовались в меню “Пуск” Windows 2000 для интеллектуальных меню, переходили в систему баллов Windows XP. В результате в меню “Пуск” после обновленной установки Windows XP сразу же отображались программы, которые пользователь часто запускал в Windows 2000.
В первоначальном выпуске Windows XP искусственные баллы были распределены таким образом, что первые три из шести позиций в списке наиболее часто используемых программ выбирались Windows, а последние три — производителем компьютера. Если вы покупали розничную, а не предустановленную копию Windows XP, то система Windows XP заполняла две из трех позиций и одну оставляла пустой. В этом случае самая первая программа, которую вы запускали, сразу же попадала в меню “Пуск”.
В пакете обновления 1 (SP1) для Windows XP эти шесть позиций были немного изменены. Две позиции выбирались Windows, одна министерством юстиции США, а последние три — производителем компьютера. Как и прежде, при покупке розничной копии Windows XP две позиции производителя компьютера выбирались Windows, а последняя оставалась пустой.
Меню “Пуск” — одна из самых заметных частей интерфейса пользователя Windows, и, как вы видите, значительные усилия тратятся на то, чтобы сделать это меню более естественным и понятным.


 Письма в редакцию: Ответы на ваши вопросы
Письма в редакцию Ответы на ваши вопросы
Знакомство с Windows PE
После прочтения статьи Вэса Миллера (Wes Miller) «Знакомство с Windows PE» в выпуске журнала TechNet Magazine за сентябрь 2006 г. я создал меню с помощью мастера на основе технологии HTA (HTML for Applications — HTML для приложений). У меня возникло несколько вопросов о том, как обеспечить работу этого меню со средой Windows® PE 2.0.
— Энди (Andy)

Ниже приведены ваши вопросы и ответы Вэса на каждый из них.

Как узнать, запускаются ли дополнительные программные компоненты HTA и сервер сценариев Windows (WSH) из моего ISO-файла?
Если дополнительные компоненты были установлены в ISO-файл в соответствии с инструкциями, приведенными в документации, они должны работать нормально. Я слышал о двух распространенных ситуациях, когда компоненты не работают: если для подготовки образа не выполнялась команда peimg /prep, или если с программой ImageX не использовался параметр /commit для фактического применения изменений к образу Windows PE при его отключении.

Должен ли быть установлен инструментарий управления Windows (WMI)? Файлы мастера, описанные в статье, выдают ошибку обозревателя Internet Explorer®.
Если установлены компоненты HTA, файлы мастера должны работать — они очень просты. Инструментарий WMI для них не нужен — собственно, я написал их до того, как появилась возможность добавить инструментарий WMI в среду Windows PE.

Как включить OC.bat в файл startnet.cmd?
Если вы пользуетесь средой Windows PE 2.0, то применять пакетный файл OC.bat не требуется вообще. Он необходим только в версии 1.x. Среда Windows PE 2.0 позволяет добавлять компоненты непосредственно, без промежуточной помощи OC.bat.

Могу ли я пользоваться текстом программ Вэса в своем меню, когда все настрою?
Вы можете свободно брать любые примеры текста программ и использовать их по своему желанию, но не можете продавать или распространять их как часть пакета примеров кода. Подробности см. в лицензионном соглашении на веб-узле журнала TechNet Magazine.

Где можно найти Windows PE?
Где можно найти средства Windows PE Build Tools? Можно ли их загрузить с сервера, или их надо покупать?
— Франклин (Franklin)
Средства Windows PE Build Tools для Windows Vista™ входят в пакет автоматической установки Windows (WAIK). Этот пакет можно найти и загрузить по адресу go.microsoft.com/fwlink/?LinkId=85377.
Пакет WAIK предназначен только для операционных систем из семейства Windows Vista. Для развертывания ОС Windows XP есть много аналогичных средств в пакете Business Desktop Deployment Solution Accelerator. Однако для ОС Windows Vista изменился порядок лицензирования среды Windows PE. Раньше (для ОС Windows XP) среда Windows PE предоставлялась только через лицензирование гарантии на программное обеспечение (подробности см. по адресу microsoft.com/licensing/sa/benefits/winpe.mspx).

Диспетчер ресурсов файлового сервера
Будет ли пакет диспетчера ресурсов файлового сервера предоставлен для свободной загрузки и использования с исходным выпуском ОС Windows Server® 2003? Или этот пакет совместим только с выпуском R2?
— Дэн (Dan)
Диспетчер ресурсов файлового сервера является функцией ОС Windows Server 2003 R2. Из-за наличия зависимостей от данной версии в настоящее время не планируется предоставление пакета для предыдущих выпусков ОС.

Внутреннее устройство ядра
После прочтения статьи Марка Руссиновича (Mark Russinovich) “Внутреннее устройство ядра Windows Vista. Часть 3” у меня возникли два вопроса. Во-первых, я заметил, что программа Process Explorer показывает, где случайным образом расположены файлы exe или DLL при каждом сеансе загрузки. Возможно ли, что вредоносное программное обеспечение сможет воспользоваться тем же механизмом для определения местоположения кода для атаки? Во-вторых, при наличии всего 256 точек начала случайного выбора (если я понял статью правильно), что мешает вредоносному программному обеспечению воспользоваться методом полного перебора, если атакуемый код остается статическим на протяжении всего сеанса?
— Джо (Joe)

У Марка есть ответы на все Ваши вопросы:

Программа Process Explorer демонстрирует ситуацию «курицы и яйца»: вредоносное программное обеспечение не может определить местоположение библиотек DLL, потому что оно не может определить местоположение API-интерфейса, который возвращает эту информацию. Полный перебор для вредоносного программного обеспечения не является надежным методом внедрения, потому что при неверном угадывании наиболее вероятно произойдет сбой инфицируемого приложения. Случайный выбор по меньшей мере замедлит распространение вируса. В лучшем же случае это поможет предотвратить инфицирование системы вредоносным программным обеспечением.

Свяжитесь с нами
Хотели бы что-то сказать? Не стесняйтесь! Мы ценим мысли наших читателей. Отправьте нам электронное письмо на адрес tnmag@microsoft.com.