June 2008 June 2008
Безопасность: Великий спор: безопасность через маскировку
Безопасность через маскировку включает в себя принятие мер, которые не удаляют направление атаки, а скрывают его. Некоторые считают это порочной практикой, тогда как другие заявляют, что все может быть полезно в рамках общей стратегии. Это довольно горячий спор, и в этой статье наших лучшие эксперты по безопасности противостоят друг другу, объясняя безопасность через маскировку и представляя обе стороны в этом споре. Jesper M. Johansson and Roger Grimes
Безопасность: Новые средства PowerToy для повышения прав в Windows Vista
В этой статье Майкл Мерголо поделится самыми свежими сведениями о средствах PowerToy для запуска программ с повышенными полномочиями. Вашему вниманию предлагаются расширенные средства запуска программ с правами администратора, которые применимы для средств работы со сценариями от независимых поставщиков, способ вернуть удобные функции Windows XP, удаленные из Windows Vista, и множество других полезных программных средств. Michael Murgolo
Безопасность: Усовершенствования в технологии шифрования диска BitLocker
В Windows Vista с пакетом обновления 1 и Windows Server 2008 внесены важные изменения в BitLocker, включая поддержку томов данных и улучшенную защиту от криптографических атак. Байрон Хайнз (Byron Hynes) изучает новые функции, демонстрирует, как использовать BitLocker на сервере и рассказывает о недавних сообщениях в СМИ, касающихся BitLocker. Byron Hynes
Безопасность: Блокировка приложений с помощью политик ограниченного использования программ
Когда необходимо уменьшить общие расходы на обслуживание настольных компьютеров в организации, блокировка приложений может немало помочь в этом, позволяя ограничить проблемы в области ИТ, связанные с неподдерживаемыми приложениями. Узнайте, как можно использовать политики ограниченного использования программ и групповую политику для контроля над тем, какие приложения выполняются в информационной инфраструктуре. Chris Corio and Durga Prasad Sayana
Безопасность: Управление брандмауэром Windows Vista
В последнее обновление брандмауэра Windows Vista добавлен ряд новых впечатляющих функций, делающих его наиболее привлекательным решением для корпоративных сред. Йеспер Йоханссон представляет краткий обзор эволюции брандмауэра Windows и подробно рассматривает улучшения, такие как новые правила и профили, изоляция доменов и шифрование, с которыми должны ближе познакомиться администраторы. Jesper M. Johansson
Безопасность: Защита электронной почты с помощью цифровых сертификатов
Протокол S/MIME позволяет скрывать передаваемую информацию, проверять серверы и подтверждать подлинность сообщений. Узнайте о том, как обеспечить безопасность электронной почты с помощью сертификатов и как устранять проблемы, с которыми можно столкнуться в системе S/MIME. Matt Clapham and Blake Hutchinson
Columns
Письмо редактора: Великий спор: | Письма в редакцию: Мнения читателей: | Инструментарий: Новые продукты для специалистов по информационным технологиям:
Вопросы и ответы по SQL: Ошибки ввода/вывода, зеркалирование баз данных и другое : Пол Рэндал отвечает на ваши вопросы о SQL Server, показывая, как создавать повреждения в тестовой базе данных, помогая избежать цикла сжатия-роста, и объясняя, как можно определить, сколько баз данных можно сделать зеркальными, прежде чем начнет падать производительность.Paul S. Randal | Обзор служебных программ: Советник по переходу на Windows Vista: Готовы к обновлению систем организации на Windows Vista? Узнайте о том, как советник по переходу на Windows Vista помогает определить готовность систем к переходу на Windows Vista и поддерживаемые версии операционной системы.Lance Whitney | Sharepoint изнутри: Децентрализованное администрирование узла: Исследуйте преимущества и последствия делегирования административного контроля над узлами SharePoint отдельным подразделениям при поддержке централизованного административного контроля над инфраструктурой SharePoint.Pav Cherny
Язык сценариев Windows PowerShell: Отличный внешний вид: Узнайте о том, как объектно-ориентированная природа Windows PowerShell позволяет применить форматирование выводных данных.Don Jones | Эй, сценарист!: Работа с прохладцей тоже бывает вознаграждена!: Сценаристы размышляют о тяжком труде, истинном счастье и выводе данных в командном окне в наглядной табличной форме.The Microsoft Scripting Guys | Документы о рабочей среде: Безопасность и соответствие требованиям: ИТ-специалистам часто оказываются в ситуации, когда поставленные перед ними цели противоречат друг другу. Например, ради соответствия требованиям часто приходится снижать безопасность.Wes Miller
Бизнес информационных технологий: 10 ключей к тому, чтобы стать лидером в области охраны окружающей среды: Поскольку важность роли ИТ-отделов в деятельности компании по охране окружающей среды все более увеличивается, ИТ-специалисты занимаются поиском возможности осуществления коренных изменений, чтобы стать идейными лидерами своих компаний и отраслей. В статье представлен обзор становления эффективным идейным лидером в области инициатив по охране окружающей среды и экологической устойчивости в вашей организации.Michael Walsh and Eliza Walsh | Заметки разъездного инженера: Совместная работа с разделенным экраном: Разработанная в Microsoft Research India технология Split Screen позволяет двум пользователям совместно использовать один монитор, запуская на каждой стороне свой экземпляр ОС.Kentaro Toyama | О Windows из первых рук: Два наихудших компьютера, которые когда-либо существовали: Рэймонд Чен с любовью вспоминает о работе с двумя самыми плохими компьютерами, которые когда либо производились.Raymond Chen


Безопасность
Великий спор: безопасность через маскировку
Йеспер М. Йоханссон (Jesper M. Johansson) and Roger Grimes
Краткий обзор:
  • Определение безопасности через маскировку
  • Оценка мер безопасности через маскировку
  • Оценка полезности переименования учетной записи администратора
  • Принятие решений по управлению риском на основе имеющейся информации

Термин «безопасность через маскировку» часто подвергается остракизму со стороны работников сферы безопасности, особенно тех, что считают себя специалистами Почти являющаяся ругательством в некоторых кругах, безопасность
через маскировку, как отмечено в англоязычной Википедии (en.wikipedia.org/wiki/Security_through_obscurity), представляет один из действительно противоречивых аспектов безопасности. Часто можно увидеть насмешливые упоминания о людях, чьи усилия игнорируются как «просто безопасность через маскировку».
Безопасность через маскировку является по сути нарушением принципа Керкхофа, утверждающего, что система должна быть защищенной благодаря своим проектным решениям, а не тому, что эти решения неизвестны оппоненту. Принцип Керкхофа основан на том, что секреты быстро выплывают наружу.
В качестве отличного примера возьмем протокол проверки подлинности Windows NT® LAN Manager (NTLM), изначально считавшийся секретным. Чтобы создать программный продукт Samba для взаимодействия с операционными системами на основе UNIX, разработчикам Samba пришлось вскрыть и проанализировать протокол. Результатом стала наиболее полная существующая документация по NTLM (monyo.com/technical/samba/translation/ntlm.en.html), а также обнаружение ряда ошибок. Поскольку криптография является истоком безопасности в столь значительной степени и столь многие секретные решения разработчиков были раскрыты, многие специалисты считают, что информационная безопасность должна всегда следовать принципу Керкхофа.
Но всегда ли плоха безопасность через маскировку? В этой статье мы разберем, что из себя представляет безопасность через маскировку, почему многие считают ее потерей времени (а многие нет) и покажем, почему ответ, как и всегда, гораздо сложнее, чем кажется на первый взгляд.

Введение в безопасность через маскировку
«Не изменяйте имена по умолчанию» – автор Стив Райли (Steve Riley)
В вопросе переименования я придерживаюсь подхода «не менять ничего». Это даже не проблема безопасности – это вопрос управления системой. И по мере того, как я трачу все больше времени на размышления в пространстве управления системой (поскольку управление и безопасность становятся одним целым), мне все больше нравится идея не делать ничего, что потенциально может повысить хрупкость системы. А один из гарантированных путей ее повысить – сменить что либо, установленное по умолчанию. Пользователи делают это по двум (ладно, трем) причинам:
  • Это известное требование для функции, предоставляемой изменением.
  • Предполагается, что это улучшит безопасность.
  • (Осторожно: впереди глупость.) Кто-то прочел об этом в журнальной статье.
Если необходимо изменить имя по умолчанию по причине номер один, смело делайте это. Изменения такого рода редко ведут к нестабильности системы, часто потому, что они тестировались заранее.
Если же изменение вносится по причине номер 2, я бы советовал остановиться и хорошо подумать. Изменения такого рода практически никогда не тестируются производителями программного обеспечения и, следовательно, производитель не может предсказать, как будет вести себя система после их внесения. Вдобавок существуют альтернативы и как правило гораздо лучшие, способные предоставить истинную безопасность.
Если какой-нибудь негодяй и узнает имя учетной записи, что с того? Реально преграждает ему путь в систему все равно пароль и стойкость этого пароля. Стремление изменять имена учетных записей по умолчанию, такие как «Администратор» и «Гость», на что-нибудь не столь легко угадываемое часто указывает на желание избежать сложных паролей или кодовых фраз. Исправьте настоящую проблему (скверные секреты), и это позволит избежать хрупкости (изменения имен по умолчанию).

Безопасность через маскировку не включает мер, которые совершенно не смягчают проблемы. Например, организация, блокирующая протокол NNTP на пограничных маршрутизаторах, чтобы не дать сотрудникам читать группы новостей, но допускающая исходящие подключения по SSH, не применяет безопасность через маскировку. Поскольку по протоколу SSH может туннелировать любой протокол, проблема не маскируется, глупая мера по ее устранению не годится ни на что, кроме как на принуждение законных пользователей к нарушению политик безопасности ради выполнения своих законных задач. Подобные меры – не безопасность через маскировку; они просто глупы и бессмысленны.
Как предполагает первое слово термина «безопасность через маскировку», меры такого рода предоставляют некоторую защиту. Однако также предполагается (в чем и состоит проблема), что для реальной остановки атаки на одном или нескольких направлениях не делается ничего. (Направление атаки – это по сути средство, которым злоумышленник может получить доступ к системе.)
Предположим, что имеется уязвимый веб-сервер, который можно атаковать через порт 80 TCP, используя широко известный способ вторжения. Чтобы закрыть это конкретное направление, можно внести исправление в веб-сервер или отключить его – в обоих случаях направление будет полностью перекрыто. Можно также частично перекрыть его, используя брандмауэр или IPsec для закрытия порта 80 на всех компьютерах, кроме нескольких избранных. Это не перекроет направление атаки полностью, но существенно смягчит проблему.
Безопасность через маскировку, с другой стороны, включает принятие мер, которые не перекрывают направление атаки, а только скрывают его. Например, можно решить переместить веб-сервер с порта 81 на порт 80, так что лишь те, кто знают, где его найти, смогут сделать это. Во всяком случае, так предполагается. В реальности перемещение веб-сервера на порт 81 останавливает лишь некоторые атаки, а в основном просто создает неудобства конечному пользователю. Компетентный злоумышленник просто проведет сканирование портов и применит уловитель веб-заголовков по большому числу портов, чтобы обнаружить веб-серверы на нестандартных портах. Найдя один из них, он сможет применить вышеупомянутый способ вторжения против сервера, поскольку направление атаки не было удалено, а только (временно) замаскировано.
Значит ли это, что не стоит и пытаться? Ответ зависит от разных факторов. Как и всегда в области информационной безопасности, все сводится к управлению рисками. Чтобы понять ключевые факторы, которые следует рассмотреть, стоит бросить быстрый взгляд на ряд других мер безопасности через маскировку и затем обсудить одну из них – переименование учетной записи администратора – более подробно.

Оценка мер безопасности
Примеров безопасности через маскировку существует множество. Это могут быть действия, предпринимаемые диспетчерами систем и сетей либо разработчиками программного обеспечения. Но все они имеют общую черту – предназначение для смягчения уязвимости, путем сокрытия ее от потенциальных взломщиков.
Не могут ли некоторые из этих процедур иметь хотя бы некоторый положительный эффект? Будет ли справедливым утверждение, что безопасность через маскировку плоха в целом? По крайней мере часть из этих мер определенно имеет своих защитников. Например, в Windows® возможно скрыть буквы дисков в проводнике Windows. Многие среды, в первую очередь школьные компьютерные классы, используют эту методику, чтобы предотвратить сохранение пользователями данных на жесткий диск. Само собой, большинство приложений по-прежнему могут сохранять данные на жесткий диск, так что в итоге ценность такой меры безопасности невелика. Но применившие ее учреждения часто заявляют, что она уменьшает объем данных на жестком диске.
Метод безопасности через маскировку иного рода часто реализуется в Windows – отключение административных общих сетевых ресурсов (таких как C$, Admin$, и т.д.). Предполагается, что это должно лишить злоумышленника возможности удаленно подключиться к компьютеру. В действительности, это не просто не так – злоумышленник с учетной записью, которая может использовать административные общие ресурсы, может удаленно включить эти самые ресурсы вновь. И все же многие организации клянутся, что отключение этих ресурсов уменьшает число вредоносных программ в их сетях.
Один из моих любимых примеров бессмысленных усилий – это параметр «Разрешать отстыковку без входа в систему» в Windows. Если он отключен, то кнопка «отстыковать компьютер» убирается с экрана входа в систему. Идея состоит в том, что благодаря этому злоумышленник не сможет корректно отстыковать компьютер. Само собой, любой взломщик может просто запихать и компьютер и станцию расширения в сумку и уйти с ними независимо от того, видна эта кнопка или нет. Такая вероятность едва ли тянет даже на безопасность через маскировку.
Другой четкий пример – это параметр «Разрешить операторам сервера планировать выполнение заданий по расписанию», которая, в точном соответствии с названием, позволяет пользователям, входящим в группу операторов сервера, создавать расписание заданий. Этот вопрос щекотлив потому, что такие задачи могут выполняться как локальная система, и только администраторы должны иметь возможность планировать выполнение заданий, выполняющихся как локальная система. Само собой, операторы серверов потенциально могут сделать себя администраторами множеством различных способов, так что запрещение им планировать выполнение заданий по расписанию не имеет большого значения.
Однако многие организации предпочитают этот параметр, поскольку он позволяет их специалистам быть операторами, а не администраторами, что означает меньшую вероятность случайного уничтожения ими сервера. Это уже само по себе может дать некоторые выгоды.
Так каково же заключение? Очевидно, что некоторые из этих проблем могут быть весьма сложны. Мы с пользой провели немало времени, споря об этих типах мер Роджер твердо на стороне, считающей подобные практические приемы ценными. Йеспер, с другой стороны, верит, что они в лучшем случае, как правило, являются потерей времени. Давайте изучим один из наиболее часто приводящихся (и спорных) примеров в пользу безопасности через маскировку: переименование учетной записи администратора. Роджер приведет аргументы в пользу этой меры, Йеспер – против нее. Известные специалисты по безопасности Аарон Маргосис (Aaron Margosis) и Стив Райли (Steve Riley) также вступят в спор во врезках «Переименование учетной записи администратора» и «Не изменяйте имена по умолчанию» соответственно.

Сокрытие учетной записи администратора.
Переименование учетной записи администратора с относительным идентификатором (RID) 500 на нечто неизвестное часто рекомендуется специалистами по безопасности, а также несколькими руководствами Майкрософт по укреплению безопасности системы. В групповой политике даже имеется параметр для переименования учетной записи администратора, как показано на рис. 1. Идея состоит в том, что если учетная запись администратора переименована, взломщику будет сложнее войти в систему в качестве настоящего администратора. Само собой, очевидная проблема с использованием групповой политики для этой операции состоит в том, что переименованная учетная запись администратора будет иметь одинаковое имя на всех компьютерах, к которым применен объект групповой политики. Это понижает ценность данной конкретной меры безопасности для маскировки.
Рис. 1 Переименование учетной записи администратора
Рис. 1 Переименование учетной записи администратора (Щелкните изображение, чтобы увеличить его)
В данном контексте также важно понимать, что любой пользователь с законной учетной записью может извлечь имя учетной записи администратора, была ли она переименована или нет. Учетная запись администратора всегда имеет RID 500. Просто спросив имя учетной записи с RID 500, любой пользователь с учетной записью может увидеть, как она называется, что показано на рис. 2.
Рис. 2 Поиск переименованной учетной записи администратора
Рис. 2 Поиск переименованной учетной записи администратора (Щелкните изображение, чтобы увеличить его)

Мнение Роджера
Основной известный мне аргумент против переименования учетной записи администратора состоит в том, что не составляет труда преобразовать имя учетной записи любого участника безопасности в ее зависимый идентификатор безопасности (SID) и найти ее относительный идентификатор (RID). К тому же истинная учетная запись администратора всегда имеет RID 500. Так что, если взломщик всегда может преобразовать имена учетных записей в сочетания SID/RID и найти RID 500, какой в этом смысл?
Но тут все не так просто, как кажется. Чтобы перевести имя учетной записи пользователя в SID/RID, необходим доступ к портам NetBIOS либо LDAP. Большинство брандмауэров периметра не допускают подобный тип доступа через Интернет, так что если взломщик не обойдет брандмауэр полностью, ничего ему перевести не удастся. Кроме того, анонимные переводы SID не работают на Windows XP и более поздних версиях Windows, кроме как на контроллерах домена (DC). В случае большинства открытых сети компьютеров (наиболее подверженных риску) взломщику для выполнения переводов имен в SID потребуются учетные данные, подлинность которых проверена.
Так что для начала атаки с переводом при настоящей глубокой защите необходимо преодолеть изрядное число препятствий. И даже если взломщик проникнет настолько далеко, он окажется там же, где он бы был, если б имя учетной записи осталось стандартным. Переименование учетной записи может только улучшить безопасность. И определено не может повредить ей.
Это еще один секрет Если злоумышленник не знает имени учетной записи администратора, оно становится еще одной «секретной» меткой, подобной паролю, которую ему надо узнать. Конечно, имена учетных записей пользователей вряд ли могут оказаться такими же сложными, как пароль администратора, но это еще одно препятствие, которое может экспоненциально усложнить проблему угадывания/взлома паролей. Те, кто когда-либо выполнял тестирование уязвимости паролей, уже знают, насколько увеличивает работу необходимость угадывать и имя и пароль пользователя. Это усложняет и без того трудную задачу, делая ее намного более трудной.
Отражает автоматизированные вредоносные программы и дилетантов с чужими сценариями Я выполняю практическую работу по обеспечению безопасности Windows уже 22 года, и мне довелось вести восемь приманок на Windows, открытых Интернету, в течении последних пяти лет. За все это время мне ни разу не приходилось видеть, чтобы автоматизированные вредоносные программы (производящие подавляющее большинство атак) использовали любую другую метку учебной записи, кроме «Администратор» (или root в случае систем *NIX). Переименование учетной записи администратора немедленно побеждает все вредоносные программы, полагающиеся на имя администратора. А это означает уменьшение угрозы безопасности.
То же касается подростков, пользующихся готовыми сценариями взлома. Все «крутейшие» руководства по взлому Windows, которые я только знаю, упоминают о методиках перевода имени в SID, но по какой-то причине я ни разу не сталкивался с этим на одной из моих приманок, если там имелась также «фальшивая» учетная запись администратора для увода их со следа. Хорошим взломщикам следует всегда проверять, является ли найденная ими учетная запись администратора реальной записью администратора (RID 500), но они этого не делают. Я не знаю почему. Вероятно, виноваты ленивые взломщики и обычное человеческое поведение.
Останавливает и большинство профессионалов Это удивляет большинство людей. После работы с приманками в течение нескольких лет быстро различаешь автоматические атаки, деток со сценариями и профессионалов. За последние пять лет при миллионах обнаруженных атак против моих приманок я никогда не видел, чтобы профессионалы выполняли перевод SID при наличии фальшивой учетной записи администратора.
Я уверен, что некоторые из профессиональных преступников выполняют перевод SID, но готов поспорить, что это ничтожное меньшинство, которое мне ни разу не удалось зафиксировать. Почему профессионалы не делают этого? Предполагаю, что они не видят причины пробовать что-то, чего не практикуют все остальные.
Упрощает предупреждения Теперь оппоненты могут возразить, что если переименование учетной записи администратора станет обычной практикой, оно утратит свое значение как прием маскировки. Аргумент состоит в том, что вредоносные программы, подростки со сценариями и профессионалы изменят свою тактику по умолчанию на поиск иных имен, чем только «Администратор». Это обоснованное предположение. К счастью, оно не меняет одного важного условия. Во-первых, если учетная запись Windows с суперполномочиями не называется «Администратор», взломщикам прибавляется работы. Это просто факт. А если взломщику надо работать больше, чуть понижается вероятность выбора им этого направления для атаки, позволяя другим уменьшающим воздействие мерам глубокой защиты обнаруживать вредоносную деятельность быстрее.
И это ведет меня к последнему аргументу в пользу переименования. Если учетная запись администратора никогда не называется «Администратор», а вместо этого создается другая учетная запись с таким именем, как показано на рис. 3, то получится хороший механизм предупреждения. Если отслеживание событий обнаруживает попытку входа в систему с использованием имени по умолчанию, это событие следует немедленно исследовать.
Рис. 3 Попытки входа в систему через учетную запись-приманку, именуемую «Администратор», могут служить ранним предупреждением
Рис. 3 Попытки входа в систему через учетную запись-приманку, именуемую «Администратор», могут служить ранним предупреждением (Щелкните изображение, чтобы увеличить его)
Наши журналы событий полны «неверных» входов в систему, которые ничего не значат. Обычно это просто попытка пользователя (или Windows) войти в систему, используя неверный пароль, или что-нибудь в таком духе. Но как же можно легко отличить нормальные попытки входа от вредоносных, если учетная запись администратора именуется «Администратор»? Если учетной записи с таким именем никогда не было, и обнаруживается попытка входа в систему с использованием имени этой учетной записи, то ясно, что это вряд ли делается с хорошими намерениями. Ранее предупреждение с низким отношением шума к сигналу весьма ценно в современной защите.

Очередь Йеспера
«Переименование учетной записи администратора» - автор Аарон Маргосис (Aaron Margosis)
Йеспер, в идеальном мире вы были бы абсолютно правы. Пароли будут всегда достаточно стойки, чтобы сделать тупой перебор нереальным, а учетные записи локального администратора -500 всегда будут использоваться только для аварийного восстановления. В реально мире неверно ни то, ни другое.
Несмотря на вашу замечательную проповедь безопасности и, в частности, великолепную серию о кодовых фразах, написанную вами ("The Great Debates: Pass Phrases vs. Passwords" («Великие Дебаты: парольные фразы против паролей») части 1, 2 и 3 на go.microsoft.com/fwlink/?LinkId=113157; go.microsoft.com/fwlink/?LinkId=113159; и go.microsoft.com/fwlink/?LinkId=113160), многие системные администраторы не обладают современным пониманием того, что представляет из себя стойкий пароль.
Не так давно пароль, состоящий из 8 случайных знаков, выбранных из разных наборов знаков, считался стойким, закон Мура сделал это неверным. Обучение пользователей (и системных администраторов) является слабым звеном и, вероятно, останется им, пока тема надежности паролей не станет модной на кабельных каналах новостей.
Так что, учитывая, что реальный подбор паролей в наши дни не требует 600 миллиардов лет, а, вместо этого, зачастую может быть сделано за время, уходящее на завтрак, добавление множителя х1000 может иметь реальную ценность. К тому же переименование учетной записи делает ее неуязвимой для множества автоматических атак, бьющих по учетной записи, именуемой «Администратор».
Время и усилия, уходящие на переименование учетной записи администратора, обычно невелики, как вы заметили, чаще всего это простой параметр GPO. Между прочим, стандартная настройка для настольных компьютеров федеральных служб правительства США (csrc.nist.gov/fdcc), требует переименования учетной записи -500. Переименование является лишь одним из многих требуемых параметров и не относится к тем, что требуют из ряда вон выходящего количества времени или внимания. Не приходилось мне видеть и того, чтобы благодаря ему у кого-то создалось ложное чувство защищенности – я никогда не слышал слов: «Нам не нужно управление обновлениями, поскольку мы переименовали свои учетные записи администраторов.»
Приносит ли переименование пользу, когда новое имя учетной записи одинаково для всей организации? Польза не особенно велика, но она есть: во-первых, это блокирует автоматизированные атаки, ожидающие имя «Администратор», и, во вторых, потенциальные злоумышленники не обязательно входят в число лиц, знающих новое имя. (Гораздо больший риск возникает, когда локальные учетные записи администраторов, переименованы они или нет, используют общий пароль внутри организации. Управление паролями остается большей и более важной проблемой. Отключение учетной записи -500 – один из способов ее решения, но это блокирует важный способ восстановления, когда доменные учетные записи не могут быть использованы.) Я также могу указать, что наши руководства по безопасности давно рекомендуют переименовывать учетные записи по умолчанию, так что такое действие хорошо протестировано и полностью поддерживается.
Я думаю, мы все знаем теперь, что меры маскировки (сами по себе) не являются адекватной защитой. Но они могут дополнять другие меры безопасности, как ясно демонстрируют данные Роджера. Так как стоимость реализации невысока, организациям не следует отбрасывать их.

Помимо аргументов в пользу переименования учетной записи администратора, существуют и веские аргументы против. Но перед тем, как углубляться в них, я должен признать, что последний довод Роджера довольно весок. Однако в хорошо управляемой среде следует проверять любой вход в систему через учетную запись администратора, поскольку эту запись не следует использовать иначе как в ситуациях аварийного восстановления.
Это избыточно Основной риск, который (предположительно) должно уменьшать переименование учетной записи администратора, – это удаленный подбор пароля кем-либо. Но только пользователь, не имеющей другой уполномоченной учетной записи на компьютере, будет остановлен переименованием учетной записи администратора. Такой злоумышленник обычно опробует серию случайных паролей, чтобы войти в систему через учетную запись администратора. Однако при этом он получит одинаковое сообщение об ошибке вне зависимости от того, угадал ли он неверно имя учетной записи или пароль.
Это указывает на то, что один из основных аргументов в пользу переименования учетной записи администратора (то, что это отпугнет подростков) – порочен. Это отпугнет их ничуть не в большей мере, чем сохранение имени по умолчанию, поскольку разница им не видна! Что ни делай, они переберут тот же набор случайных паролей и перейдут к следующей потенциальной жертве.
Это значит, что пока пароль на учетной записи администратора достаточно стоек для отражения атак, переименование учетной записи не предоставляет дополнительных выгод. Допустим, что эта учетная запись защищена 15-символьным паролем, состоящим из букв верхнего и нижнего регистра, чисел и знаков, выбранных со всей клавиатуры. Угадывание такого пароля через сеть займет примерно 591,310,404,907 лет. В порядке сравнения можно сказать, что это примерно в 43 раза больше времени существования вселенной.
Допустим, мы переименуем учетную запись администратора, выбирая одно из 1000 возможных значений. Время на угадывание пароля растянется до 591,310,404,906,787 (в 43,161 раз больше, чем время существования вселенной). Повысили ли мы безопасность? Конечно, на три порядка. Понизили ли мы вероятность, что злоумышленник угадает наш пароль? Ну, она бесконечно мала в обеих случаях. Другими словами, в реальности мы ничуть не улучшили ситуацию по сравнению с использованием изначального имени учетной записи администратора. То, что переименование учетной записи позволяет разделаться с вредоносными программами, которые используют ее, еще не значит, что эти программы преуспели бы, не будь она переименована. Если используется стойкий пароль, как это и следует делать, можно практически гарантировать, что они будут отражены вне зависимости от имени учетной записи.
Известно, что многие руководства по безопасности требуют переименования учетной записи администратора, но это еще не делает такую меру полезной или даже допустимой. Это просто лишает пользователя принять нормальное решение по управлению риском насчет нее. Руководства по безопасности часто требуют установки параметров, которые ничего не меняют и во многих случаях даже не существуют. Чтобы продвинуться в области безопасности, мы рань или поздно должны подняться над требованиями, реально проанализировать проблемы и оценить, имеет ли смысл их устранять или нет. Здесь важно помнить один ключевой момент – тот факт, что злоумышленник нацеливается на тот или иной компонент, не является сам по себе достаточной причиной для изменения этого компонента. Изменения следует вносить только в том случае, если можно ожидать, что без их внесения атака будет успешной.
Если предположить наличие стойкого пароля, вероятность успеха атаки практически равняется нулю независимо от того, переименована учетная запись или нет. Следовательно, при наличии стойкого пароля безопасность не требует переименования учетной записи. Вдобавок, если вы, подобно мне, основываетесь на предположении, что компьютер, вероятно, будет тем более стабилен, чем меньше поправок и изменений в него вносить (твердо установленный факт, между прочим), то это добавляет еще одну причину не переименовывать учетную запись администратора.
Отвлекает внимание на малозначимые улучшения Одна из проблем с малозначимыми улучшениями безопасности через маскировку состоит в том, что они угрожают отвлечь внимание организации от действительно значимых улучшений. Например, время и усилия, уходящие на переименование учетной записи администратора, можно использовать на что-нибудь еще. Если это что-то имеет большее значение, чем переименование учетной записи администратора, то организация упустила шанс. Это может и не показаться значительной ценой, но представьте себе переименование 50 000 учетных записей администратора, и моя мысль станет понятна.
Что еще хуже, вполне реальна возможность того, что руководство организации успокоится после введения малозначимого улучшения. Руководители не всегда понимают минимальную полезность улучшений безопасности через маскировку и могут отказаться от дальнейших шагов. Это действительно может создать значительный риск для организации, хотя его и можно избежать, если руководство просто посвятит некоторое время и усилия ознакомлению со значением применяемых улучшений.
Управление им затратно Наконец, в зависимости от того, насколько умело реализовано улучшение, управление им может стать довольно дорогостоящим. Если просто установить объект групповой политики на переименование учетной записи администратора, затраты очень малы. Все будут знать имя, и стоимость развертывания будет практически равна нулю. Однако предоставляемая им полезность также минимальна, поскольку, как я уже сказал, все обладатели учетной записи будут знать это имя. То есть, чтобы реально выиграть от этого улучшения, необходимо использовать различные имена на различных узлах, и такая система становится довольно дорогой в управлении.
Гораздо лучше вместо этого использовать средство вроде passgen (protectyourwindowsnetwork.com/tools.htm), чтобы установить полностью случайный 100-значный пароль на всех учетных записях администратора в сети и использовать другие учетные записи для повседневного управления. Учитывая, что учетная запись администратора предназначена исключительно для целей аварийного восстановления (кроме как на Windows Small Business Server 2003), это не должно никак повлиять на систему управления сетью. Вдобавок, у злоумышленника будет больше шансов найти иголку на дне Тихого Океана, чем верно угадать пароль для любой из учетных записей администратора. Достаточно сосредоточиться на стойких, уникальных паролях и пусть хакеры-подростки подбирают, пока не надоест.

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

Йеспер М. Йоханссон (Jesper M. Johansson) является специалистом по архитектуре программного обеспечения, работающим над программными средствами защиты данных, и пишущим редактором журнала TechNet Magazine. Он защитил докторскую диссертацию по информационным системам управления, более 20 лет работает в области обеспечения компьютерной безопасности и обладает званием Microsoft MVP в области безопасности предприятий. Последняя книга Йеспера – Windows Server 2008 Security Resource Kit («Комплект ресурсов безопасности Windows Server 2008»).
Roger Grimes (обладатель сертификатов CPA, CISSP, MCSE: Безопасность), старший консультант по вопросам безопасности для группы ACE в корпорации Майкрософт, является автором или соавтором 8 книг по компьютерной безопасности и автором более 200 статей в журналах. Он часто выступает на конференциях по безопасности и ведет рубрику о безопасности в InfoWorld.
© 2008 Корпорация Майкрософт и CMP Media, LLC. Все права защищены. Запрещается воспроизведение статьи или ее части без разрешения.


Безопасность
Новые средства PowerToy для повышения прав в Windows Vista
Майкл Мерголо (Michael Murgolo)
Краткий обзор:
  • Запуск от имени администратора для средств работы со сценариями от стороннего поставщика
  • Запуск программ от имени другого пользователя
  • Запуск интерпретаторов команд CMD и Windows PowerShell от имени системы
  • Мини-приложение для запуска программ с повышенными правами с помощью операции перетаскивания
Загрузить исходный код для этой статьи: Elevation2008_06.exe (197KB)

Представляем следующую редакцию средств PowerToy для запуска с повышением прав для Windows Vista. Я обратил на них внимание в июньском номере TechNet Magazine за 2007 год. Теперь, через год, я покажу вам, как мне удалось расширить функциональность запуска от имени администратора для
некоторых из моих любимых средств работы со сценариями от сторонних поставщиков; продемонстрирую, чем можно заменить полезное свойство Windows® XP, отсутствующее в Windows Vista®; познакомлю вас с некоторыми полезными средствами в составе средств PowerToy для запуска с повышением прав.

Запуск от имени администратора для дополнительных средств работы со сценариями
Одной из тем, которые я обсуждал в предыдущей статье (доступной на technet.microsoft.com/magazine/cc162321.aspx), была возможность применения пункта меню «Запустить от имени администратора» для собственных средств работы со сценариями Windows. Для этой статьи я сделал несколько средств PowerToy «Запуск от имени администратора», которые можно использовать для средств работы со сценариями от сторонних поставщиков:
  • AutoIt v3 (www.hiddensoft.com)
  • AutoHotkey (www.autohotkey.com)
  • ActivePerl (www.activestate.com)
  • KiXtart 2010 (www.kixtart.org)
Код для каждой из этих программ включен в комплект загружаемых файлов для этой статьи, находящийся по адресу technetmagazine.com. Файлы называются, соответственно, ElevateAutoIt3.inf, ElevateAutoHotKey.inf, ElevatePerlScript.inf и ElevateKiXtart.inf. Установка AutoIt v3, AutoHotkey и ActivePerl довольно проста: загрузите соответствующее приложение и установите его в каталог по умолчанию. Когда интересующие вас приложения установлены, для каждого из них можно будет установить соответствующее средство PowerToy «Запуск от имени администратора».
К сожалению, к программе KiXtart 2010 нет установщика. Для того, чтобы установить KiXtart в каталог по умолчанию, что позволит нормально работать средству PowerToy, я добавил INF-файл, который установит installKiXtart 2010 (v 4.60) в каталог Program Files\KiXtart и зарегистрирует расширение имени KIX.
Загрузите файл KiX2010_460.zip с www.kixtart.org/?p=downloads и разархивируйте его в какой-нибудь каталог. Скопируйте файл Install_KiXtart.inf (он входит в состав комплекта загружаемых файлов к этой статье) в тот же каталог. Затем щелкните правой кнопкой мыши файл Install_KiXtart.inf и выберите «Установить». После этого установите средство PowerToy ElevateKiXtart.inf.

Средство PowerToy «Запуск программ от имени другого пользователя»
Контроль учетных записей (UAC) был разработан для того, чтобы снизить уязвимость операционной системы от вредоносных программ. Это достигается тем, что все пользователи, включая администраторов, запускают большинство программ только со стандартными правами. Для выполнения задач по администрированию и некоторых других функций приложений предусмотрена возможность повышения прав. Эта возможность реализуется выбором пункта «запуск от имени администратора» в контекстном меню, которое можно вызвать, щелкнув исполняемый файл правой кнопкой мыши. Средства PowerToy для запуска с повышенными правами, которые обсуждались в июньском номере за 2007 год, позволяют использовать эту возможность для других типов объектов и файлов.
Встроенная в Windows Vista функциональность довольно неплохо работает для большинства задач по администрированию. Однако один важный вариант использования не был реализован в Windows Vista. Во многих подразделениях ИТ существует практика, когда сетевые администраторы используют одну учетную запись для своих каждодневных задач (вроде чтения почты и составления документов) и другую учетную запись для администрирования сети или локального компьютера.
В результате снижается риск того, что администратор случайно запустит вредоносную программу во время обычной работы и тем самым нарушит безопасность всей системы или домена, в котором он находится. В Windows XP в меню, вызываемом щелчком правой кнопки мыши, был пункт «Запустить от имени...». Но в Windows Vista этот пункт меню заменен пунктом «Запустить от имени администратора».
Однако средство командной строки «runas» в Windows Vista осталось. К сожалению, его нельзя использовать для основной задачи второй учетной записи: для запуска оснасток консоли управления (MMC). Предположим, что вам поручены какие-то задачи по управлению учетными записями в службе каталогов Active Directory®. Над своими каждодневными задачами вы работаете как обычный пользователь, а для задач администрирования у вас есть учетная запись, входящая в группу локальных администраторов компьютера (так что вы можете устанавливать на компьютер необходимые средства управления сетью). Компьютер работает под управлением Windows Vista со включенным контролем учетных записей . Чтобы запустить модуль «Active Directory – пользователи и компьютеры» (ADU&C) от имени администратора службы каталогов Active Directory, вы могли бы попробовать команду runas, как показано ниже:
runas /user:mydomain\admin
"mmc.exe %windir%\system32\dsa.msc"
К сожалению, ADU&C так не запустится. Вместо этого вы увидите такую ошибку программы runas: «Для выполнения операции требуется повышение прав». Что же происходит? Дело в том, что исполняемые файлы MMC помечены как требующие наивысшего уровня прав. Поскольку наивысший возможный уровень прав для учетный записи, используемой для администрирования, это администратор, для запуска ADU&C требуется повышение прав. Поскольку runas не запрашивает повышения прав, происходит ошибка.
Таким образом, описанный вариант работы в Windows Vista затруднен, потому что в контекстном меню нет пункта «Запустить от имени...». Кроме того, отсутствуют встроенные средства запуска приложения, требующего повышения прав, от имени другого пользователя.
Если бы я не привел здесь решения этой проблемы, у меня получилась бы довольно грустная статья. К счастью, одно из моих исходных средств повышения прав PowerToy предоставляет ключ к разрешению второй проблемы, и мне удалось довести другое до решения первой. (Хотел бы я, чтобы решение проблемы повышения прав принадлежало мне, но увы, его нашел Гов Махарадж (Gov Maharaj) из группы изучения совместимости приложений с Windows).
Получилось, что при помощи команды runas можно использовать средство PowerToy «команда Elevate». Если выполнение предыдущей команды не приводит к запросу повышения прав, то эта работает нормально:
runas /user:mydomain\admin
"elevate mmc.exe%windir%\system32\dsa.msc"
Этой командой runas запускает elevate.cmd (технически это тот же cmd.exe) от имени другого пользователя, а уже интерпретатор команд с повышенными правами запускает mmc.exe.
В конце концов, я скомбинировал этот прием с сопоставлениями для файлов EXE and MSC и, добавив к этому пользовательский интерфейс, написанный в виде приложения HTML, получил средство PowerToy, создающее пункт «Запустить от имени другого пользователя» в меню, доступном по щелчку правой кнопкой мыши. При выборе этого пункта меню вызывается приложение HTML, как показано на рис. 1.
Рис. 1 Средство «Запуск программ от имени другого пользователя»
Рис. 1 Средство «Запуск программ от имени другого пользователя» (Щелкните изображение, чтобы увеличить его)
Введите имя пользователя и домен; если учетная запись расположена на локальном компьютере, установите флажок «Использовать локальную учетную запись». Затем нажмите кнопку «Запустить», чтобы запустить приложение от имени обычного пользователя, или «Запустить как администратор», чтобы запустить приложение с повышенными правами. После нажатия одной из этих кнопок запустится runas.exe и запросит пароль или ПИН-код смарт-карты.
Поскольку это средство PowerToy использует средство PowerToy «команда Elevate», сначала нужно установить его. Для этого щелкните правой кнопкой мыши файл RunAs.inf, выберите «Установить» и подтвердите повышение прав. Для удаления этого средства используйте пункт панели управления «Программы и компоненты».
Некоторые из ярлыков файлов MSC из папки «Администрирование» (например «Управление компьютером») будут работать с этим средством PowerToy. Однако имейте в виду, что ярлыки, создаваемые при установке средств администрирования Windows Server® 2003 с использованием adminpak.msi, – это не стандартные ярлыки файлов MSC, а ярлыки установщика Windows Installer. Из-за этого «Проводник» не показывает пункт «Запустить от имени другого пользователя» в меню этих ярлыков.
Для таких ярлыков придется искать настоящие файлы MSC и щелкать их правой кнопкой мыши или создавать новые ярлыки для файлов MSC. Кроме того, runas не работает с Internet Explorer®, потому что Internet Explorer в Windows Vista был перепроектирован для работы в режиме повышенной безопасности (дополнительная информация по этому вопросу находится на support.microsoft.com/?id=922980).
Обратите внимание: после создания мною этих средств PowerToy, но до выхода в свет этой статьи, группа Windows Sysinternals выпустила новое средство с функциями, очень похожими на средство PowerToy «Запуск от имени другого пользователя». Оно называется ShellRunas и находится на веб-узле Windows Systernals: technet.microsoft.com/sysinternals/cc300361.
Поскольку ребята из Sysinternals всю жизнь пишут настоящий код, то, быть может, лучше использовать их средство. Я решил оставить свою версию в этой статье для того, чтобы на его примере показать, как можно решить данную задачу и вообще расширить функции оболочки с помощью сценариев и приложений HTML.

Запуск интерпретаторов команд CMD и PowerShell в данной папке от имени системной учетной записи
Иногда необходимо запускать программы в контексте системной учетной записи. Например, многие средства распространения программного обеспечения, такие как System Center Configuration Manager (SCCM), используют клиентский агент, который для выполнения своих задач запускается от имени системной учетной записи.
Чтобы протестировать поведение установщика программного обеспечения, работающего от имени системной учетной записи, перед тем как начинать распространять программу с помощью, например SCCM, было бы полезно запустить установщик из интерпретатора команд, работающего от имени системной учетной записи. Так я решил сделать собственные средства PowerToy для запуска интерпретаторов команд CMD и PowerShell в данной папке от имени системной учетной записи.
В Windows XP я привык реализовывать такие функции через сценарии интерпретатора команд:
@echo off
sc create CmdAsSystem type= own type= interact
binPath= "cmd /c start cmd /k (cd c:\ ^& color ec ^&
title ***** SYSTEM *****)"
net start CmdAsSystem
sc delete CmdAsSystem
Однако если попытаться выполнить этот сценарий из командной строки с повышенными полномочиями в Windows Vista, появится сообщение об ошибке, показанное ниже, а запрос командной строки от имени системной учетной записи не появится.:
ВНИМАНИЕ! Служба CmdAsSystem настроена как интерактивная, ее поддержка отключена. Служба может не работать должным образом.
Проблема в том, что этот сценарий пробует создать и запустить интерактивную службу. В Windows Vista из-за изоляции сеанса 0 интерактивные службы не работают нормально. (Что такое «изоляция сеанса 0», можно узнать в техническом документе «Службы в Windows Vista», находящемся по адресу microsoft.com/whdc/system/vista/Vista_Services.mspx.)
Чтобы обойти это ограничение, я воспользовался средством Psexec, разработанным командой Sysinternals (см. technet.microsoft.com/sysinternals/bb897553.aspx). Это средство позволяет запускать процессы от имени системной учетной записи. К сожалению, большинство средств Sysinternals не содержат установщиков. Поэтому я написал файл INF (который можно загрузить вместе с остальным кодом), который устанавливает весь пакет Sysinternals (в том числе и Psexec) в каталог Program Files\Sysinternals Suite. В качестве дополнительного сюрприза этот файл INF создает в меню «Пуск» ярлыки для всех графических средств пакета.
Чтобы установить пакет, сначала загрузите SysinternalsSuite.zip с technet.microsoft.com/ sysinternals/bb842062.aspx и распакуйте его в папку. Скопируйте в ту же папку мой файл INF (Install_SysinternalsSuite.inf), щелкните его правой кнопкой мыши и выберите «Установить». Поскольку это новое средство PowerToy использует средство PowerToy « команда Elevate», потом установите и его. После этого можно будет установить CmdHereAsSystem.inf и PowerShellHereAsSystem.inf. Когда установятся эти средства PowerToy, пункты CMD Prompt Here as System и PowerShell Prompt Here as System появятся в меню, вызываемом в «Проводнике» для папок и устройств щелчком правой кнопки мыши, как показано на рис. 2.
Рис. 2 Параметры средств CMD Prompt Here и PowerShell Prompt Here от имени системной учетной записи
Рис. 2 Параметры средств CMD Prompt Here и PowerShell Prompt Here от имени системной учетной записи
На рис. 3 показано окно интерпретатора команд CMD, работающее от имени системной учетной записи. Я выбрал яркий цвет как напоминание о том, что командная строка работает от имени системной учетной записи и, если будет введена неправильная команда, то с системой могут произойти непредвиденные (и опасные для ее целостности) вещи.
Рис. 3 Осторожно и ответственно используйте окно интерпретатора команд CMD от имени системной учетной записи
Рис. 3 Осторожно и ответственно используйте окно интерпретатора команд CMD от имени системной учетной записи
И последнее. Эти средства PowerToy добавляют команды к системе, так что их можно запустить из командной строки или из диалога «Пуск». Например, в результате исполнения следующей команды из диалога «Пуск» будет запущено окно интерпретатора команд CMD от имени системной учетной записи в папке Windows:
cmdassystem "c:\windows"
Соответствующая команда для интерпретатора команд Windows PowerShellTM — psassystem. Обратите внимание, что я также изменил средства PowerToy для запуска интерпретаторолв команд CMD и PowerShell в данной папке от имени администратора, чтобы установить соответствующие команды — соответственно, cmdasadmin и psasadmin.

Мини-приложение для повышения прав
Большинство моих средств PowerToy требуют щелчка правой кнопкой мыши. Однако в это обновление я включил и кое-что более занятное в качестве сюрприза. Это мини-приложение для боковой панели Windows, которое я назвал мини-приложением для повышения прав (показано на рис. 4). Это цель для операции перетаскивания. Просто перетащите исполняемый файл или сценарий, у которого в проводнике Windows определено действие runas, и он запустится с повышенными правами.
рис. 4 Мини-приложение для повышения прав
рис. 4 Мини-приложение для повышения прав
Если у вас установлена предыдущая версия моих средств PowerToy для повышения прав, то мини-приложение будет работать для сервера сценариев Windows, сценариев интерпретатора команд Windows PowerShell, приложений HTML, а также для пакетов и исправлений установщика Windows (так же, как и для исполняемых файлов и сценариев командной строки, у которых действие runas определено в Windows Vista по умолчанию). И, конечно же, можно перетаскивать несколько элементов вместе. (Попробуйте перетащить папку на мини-приложение и посмотрите, что получится).
Чтобы установить мини-приложение, дважды щелкните мини-приложение для повышения прав (находится в пакете загрузки кода). Если вам интересно посмотреть на код мини-приложения, добавьте к имени файла расширение CAB Затем извлеките содержимое из файла CAB.

Заключение
Комплект загружаемых файлов к этой статье содержит как новые средства PowerToy, так и старые, из исходной статьи. В некоторые из старых средств я внес небольшие изменения. Например, исходные версии и средства запуска интерпретатора команд Windows PowerShell в данной папке от имени администратора, и сценариев WSH с повышенными правами устанавливали свои собственные копии файлов elevate.cmd и elevate.vbs. Поскольку нескольким новым средствам PowerToy также нужны эти файлы, я поменял эти средства так, что для их установки должна быть установлено средство PowerToy «команда Elevate» (тогда все средства совместно используют эту копию файлов). Чтобы определить, требуется ли установка командной строки с повышенными правами, проверьте заголовок файла INF.
В некоторых исходных PowerToy также есть мелкие изменения, не влияющие на функциональность. Перед установкой новых средств PowerToy всегда удаляйте старую версию. Поскольку этот набор разросся до 17 инструментов, я добавил сценарии интерпретатора команд для установки и удаления всего набора (соответственно, InstallAllPowerToys.cmd и UninstallAllPowerToys.cmd). Этот файл можно поменять, чтобы устанавливать и удалять только нужные инструменты.
Имейте в виду, что InstallAllPowerToys.cmd по умолчанию не устанавливает средство запуска от имени администратора сценариев от сторонних разработчиков. Этот сценарий можно поменять так, чтобы он устанавливал средства PowerToy только для того программного обеспечения, которое уже установлено. При запуске любого их этих сценариев он перезапускает себя с повышенными правами. UninstallAllPowerToys.cmd также удаляет все старые версии средств PowerToy.
Как и все мои средства PowerToy, они не поддерживаются: это средства для использования «на свой страх и риск». Это не официальные продукты корпорации Майкрософт, а мои собственные программы. Они были протестированы мной и несколькими другими добровольцами на 32-разрядной версии Windows Vista с языком по умолчанию US English. Наконец, любое из этих средств может перестать работать при выходе обновлений, пакетов обновлений или новых версий операционной системы Windows.

Майкл Мерголо (Michael Murgolo) – cтарший консультант по инфраструктуре в консультационной службе корпорации Майкрософт. Он специализируется на операционных системах, развертывании, сетевых службах, службе каталога Active Directory, управлении системами, автоматизации и управлении обновлениями. Майкл Мерголо является специалистом в области развертывания и переноса рабочих сред.


Безопасность
Усовершенствования в технологии шифрования диска BitLocker
Байрон Хайнз (Byron Hynes)
Краткий обзор:
  • Усовершенствования в BitLocker
  • Получение и установка BitLocker
  • Использование BitLocker на сервере
  • Соображения по полной защите данных

В прошлогоднем выпуске журнала TechNet Magazine, посвященном безопасности, я предоставил читателям краткий обзор некоторых функций шифрования диска Windows BitLocker, чтобы показать, как оно было применено в первоначальном выпуске Windows Vista. Теперь, с выходом пакета обновления 1 для
Windows Vista® и новой операционной системы Windows Server® 2008, настало время вновь рассмотреть BitLocker®.
В этой статье я расскажу о некоторых изменениях в последней версии, дам обзор установки и использования BitLocker на сервере и коснусь ряда недавно замеченных тем, которые стоит иметь в виду. (Кстати, для прочтения прошлогодней статьи «Защита данных с помощью шифрования диска BitLocker» посетите страницу technet.microsoft.com/magazine/cc138009.aspx.)

Новые возможности
Изменения, представленные в этом выпуске BitLocker, приносят повышенную гибкость, не изменяя основных возможностей. Изменения, которые я рассмотрю – это поддержка томов данных; внедрение трехфакторной проверки подлинности для доступа к компьютеру; поддержка объединенного расширяемого интерфейса микропрограмм (Unified Extensible Firmware Interface – UEFI), нового, соответствующего стандартам отрасли, микропрограммного обеспечения для 64-разрядных систем; лучшая защита от криптографических атак на метаданные томов и более активное использование модуля доверенной платформы (Trusted Platform Module – TPM).

Тома данных
После первоначального выпуска Windows Vista панель управления BitLocker позволяла включить шифрование только для тома операционной системы Windows® (обычно это диск С:). Для многих клиентов этого было достаточно, поскольку в домашних компьютерах все данные и программы пользователя обычно хранятся на том же томе, что и операционная система. Однако на предприятиях и тем более на серверах дело часто обстоит иначе. Как следствие, одним из самых частых запросов пользователей была способность шифровать тома данных – иные тома, чем том ОС, установленной на компьютере (обратите внимание, что средство BitLocker не предназначено для шифрования съемных носителей).
Как видно на рис. 1, на этом компьютере есть три полезных тома. (На самом деле я насчитал четыре с учетом маленького активного раздела, используемого для запуска.) Моя операционная система установлена на диске C: (который в действительности отмечен «флагом» Windows на значке), есть также два тома данных, E: и P:. Том Р: уже зашифрован с помощью BitLocker и в настоящий момент заблокирован. Том Е: еще не зашифрован. В Windows Vista с пакетом обновления 1 (SP1) и Windows Server 2008 я могу зашифровать и разблокировать эти тома данных из апплета панели управления BitLocker.
Рис. 1 Интерфейс Bitlocker
Рис. 1 Интерфейс Bitlocker (Щелкните изображение, чтобы увеличить его)
Если том операционной системы зашифрован с помощью BitLocker, поведением по умолчанию будет разблокирование зашифрованных томов данных при каждом разблокировании тома операционной системы. Если использовать для разблокирования тома данных панель управления, то этот вариант будет представлен как флажок по образцу рис. 2.
Рис. 2 Сохранение ключей для автоматического разблокирования
Рис. 2 Сохранение ключей для автоматического разблокирования (Щелкните изображение, чтобы увеличить его)
Чтобы включить или отключить автоматическое разблокирование тома данных, используйте средство командной строки manage-bde.wsf. Manage-bde.wsf – это сценарий с широкими возможностями, входящий в состав Windows, который использует базовые поставщики инструментария управления Windows (WMI), установленные вместе с BitLocker.
Например, чтобы отметить том данных P: так, чтобы его потребовалось разблокировать вручную, используйте следующую команду:
manage-bde.wsf –autounlock –disable P:
Чтобы снова включить автоматическое разблокирование диска P:, используйте:
manage-bde.wsf –autounlock –enable P:
В панель управления BitLocker не входит все, что можно делать с BitLocker и томами данных, так что следует использовать параметр -? для изучения команд manage-bde.wsf. Синтаксис manage-bde.wsf также рассмотрен в руководствах «Windows BitLocker Drive Encryption Design Guide» («Руководство по проекту шифрования диска с помощью Windows BitLocker») и "Windows BitLocker Deployment Guide" («Руководство по развертыванию Windows BitLocker»), доступных в центре загрузок Майкрософт по адресу go.microsoft.com/fwlink/?LinkId=115215.

TPM+USB+ПИН
Клиентам также требовалась возможность использовать дополнительные факторы проверки подлинности с помощью BitLocker. BitLocker использует микросхему TPM в компьютере, чтобы проверять целостность платформы – иными словами, чтобы убедиться, что ранние компоненты запуска, включая BIOS, не подверглись подмене или повреждению. С выходом же Windows Vista появилась возможность также потребовать либо ПИН-код, либо присутствие флэш-накопителя в порте USB, содержащего ключ, созданный при включении BitLocker.
В Windows Server 2008 и Windows Vista с пакетом обновления 1 можно сочетать все три метода. TPM продолжает подтверждать целостность платформы, ключ для USB представляет «что-то, что есть у пользователя», а ПИН-код – «что-то, что знает пользователь». Такое сочетание предоставляет очень мощную защиту против неавторизованных пользователей, пытающихся запустить компьютер и разблокировать защищенные средством BitLocker диски.
Однако, как и часто в безопасности, у этого есть своя цена. Очевидно, что когда BitLocker настроен таким образом, компьютер не может автоматически перезапуститься. В случае, например, сервера, необходимо решить, что важнее: гладкий перезапуск или более высокий уровень защиты.

Поддержка UEFI
С появлением Windows Server 2008 и Windows Vista с пакетом обновления 1 (SP1) была также добавлена поддержка компьютеров, оснащенных объединенным расширяемым интерфейсом микропрограмм (UEFI). UEFI – это спецификация, представляющая модернизацию традиционного BIOS, используемого большинством компьютеров при запуске. Для получения дополнительной информации о спецификации UEFI, пожалуйста, посетите www.uefi.org.

Повышенная защищенность
Когда BitLocker обнаруживает, что система была изменена, или что требуемый ПИН-код, либо ключ для USB недоступны при запуске, BitLocker входит в режим восстановления. При восстановлении, тома зашифрованные BitLocker остаются заблокированными, а пользователю предлагается диалог в текстовом режиме, именуемый консолью восстановления.
Чтобы разблокировать диск, пользователю необходимо ввести пароль восстановления (48-значное число) либо напрямую с клавиатуры, либо с флэш-накопителя для порта USB. (При хранении на флэш-накопителе для порта USB пароль порой называется ключом восстановления, поскольку он находится в двоичном, а не текстовом формате.)
BitLocker использует пароль восстановления для расшифрования ключей, хранящихся в метаданных тома, – основного ключа тома (Volume Master Key – VMK) и полного ключа шифрования тома (Full Volume Encryption Key – FVEK), чтобы затем разблокировать диск. Чтобы восстановление было успешным, должна быть доступна копия пароля восстановления
В силу этого, я настоятельно рекомендую использовать централизованное хранение пароля восстановления вдобавок к хранению пользователем (скажем, на флэш-накопителе для порта USB). В операционной системе имеется функция хранения паролей восстановления в доменных службах Active Directory® (ADDS).
Секреты, хранящиеся в метаданных тома, такие как VMK, шифруются, и целостность метаданных всего тома защищается криптографически. Если средство BitLocker обнаруживает, что метаданные тома были подменены, оно откажется использовать метаданные и не разблокирует ни одного из защищенных томов. Обратите внимание, что одного пароля восстановления недостаточно для разблокировки диска в таком состоянии.
Важно подчеркнуть, что такая ситуация может возникнуть лишь при намеренной атаке на безопасность компьютера. Если это произошло, с хорошей вероятностью компьютер уже находится в руках злодея, а не под вашим контролем. Она не возникнет, если внести простое незапланированное изменение в платформу или забыть свой ПИН-код.
Для разблокировки тома понадобятся три следующих вещи:
  • Пароль восстановления (как текст, который следует ввести, или флэш-накопитель для порта USB)
  • Двоичный пакет ключей, включающий зашифрованные версии FVEK и VMK
  • Средство восстановления BitLocker
Говоря кратко, необходимо гарантировать постоянное наличие у своего предприятия или организации доступа ко всем этим вещам.
Резервное копирование пароля восстановления можно выполнить вручную или автоматически. Я рекомендую использовать параметр групповой политики, чтобы автоматически сохранить резервную копию пароля в доменных службах Active Directory.
При настройке этого параметра, как показано на рис. 3, включите возможность создания резервной копии двоичного пакета ключей. В двоичный пакет ключей входят зашифрованные версии VMK и FVEK, позволяя при необходимости использовать средство восстановления BitLocker.
Рис. 3 Настройка групповой политики на включение пакетов ключей в информацию для восстановления
Рис. 3 Настройка групповой политики на включение пакетов ключей в информацию для восстановления (Щелкните изображение, чтобы увеличить его)
Средство восстановления BitLocker было разработано, чтобы помочь в восстановлении данных с поврежденных дисков, использующих BitLocker. Учтите, что это усовершентсованное средство, предназначенное для использования опытными администраторами. Дополнительные сведения о средстве восстановления BitLocker можно найти в статье базы знаний Майкрософт по адресу support.microsoft.com/kb/928201, или в моей веб-трансляции «Microsoft BitLocker in the Enterprise: BitLocker Tools to Make Your Life Easier» («Microsoft BitLocker на предприятии: средства BitLocker, упрощающие жизнь» (включающей практическую демонстрацию) по адресу go.microsoft.com/fwlink/?LinkId=114985.
Здесь стоит указать, что BitLocker не устраняет потребность в резервном копировании данных. Если диск был поврежден или подвергся намеренной атаке, нет гарантии, что средство восстановления BitLocker сможет восставить хоть что-то из данных, не говоря уж про все.

Более широкое использование TPM
Технически, это не изменение BitLocker, но оно достаточно интересно, чтобы его стоило упомянуть. До пакета обновления 1 единственной частью ОС Windows, использовавшей TPM, был BitLocker, но теперь TPM используется и для некоторых других функций. Скажем, когда Windows видит, что TPM доступен, она использует TPM как источник увеличенной энтропии при генерации случайных чисел. Это повышает качество всех видов шифрования (и может даже заставить игру работать лучше).
Однако, это значит, что не все относящиеся к TPM события, показываемые в обозревателе событий, обязательно относятся к BitLocker. Специалисту по ИТ следует знать, что другие системные компоненты и, потенциально, программы от других поставщиков могут и будут использовать TPM, приводя тем самым к записи событий в журнал.

BitLocker в Windows Server 2008
Благодаря общей базе кода Windows Vista и Windows Server 2008, изменения BitLocker, появившиеся в пакете обновления 1, являются неотъемлемой частью Windows Server 2008. Но зачем средство BitLocker нужно на сервере? В конце концов, BitLocker, по своему замыслу, защищает от атак против автономного компьютера. Другими словами, BitLocker не защищает работающие системы, а серверы, само собой, обычно должны работать все время.
Как оказывается, бывают случаи, когда сервер или жесткий диск с сервера могут подвергнуться атаке в автономном состоянии. Даже если такого и не произойдет, мы скоро покажем, что BitLocker может сильно помочь, когда наступает время списать жесткий диск. Для начала, взглянем, как BitLocker устанавливается и работает на сервере.

Получение и установка BitLocker
BitLocker включен во все версии Windows Server 2008, но является необязательным компонентом или функцией, которая должна быть установлена из диспетчера серверов или командной строки. BitLocker реализован отчасти как драйвер фильтра NTFS. Установка этого драйвера фильтра требует перезапуска компьютера, так что имейте в виду, что активация BitLocker на сервере потребует перезагрузки. Также, как и в случае с Windows Vista, BitLocker требует настройки отдельной нагрузки, где активный раздел, используемый для запуска компьютера, остается незашифрованным. Для помощи в верной настройке жестких дисков на поддержку BitLocker в случае, если сервер не поставляется уже настроенным, доступно средство подготовки дисков BitLocker. Но те, кто не боится самостоятельного разделения жестких дисков на разделы, определенно могут настроить жесткие диски вручную.
Для установки BitLocker в Windows Server 2008 можно использовать графический интерфейс диспетчера серверов, чтобы выбрать BitLocker из списка компонентов, как показано на рис. 4, либо можно использовать интерфейс командной строки диспетчера серверов, выдав следующую команду:
Рис. 4 Выбор BitLocker в диспетчере серверов
Рис. 4 Выбор BitLocker в диспетчере серверов (Щелкните изображение, чтобы увеличить его)
ServerManagerCmd –install BitLocker –restart
При использовании диспетчера серверов он устанавливает BitLocker и средства управления для BitLocker. Компоненты управления можно также установить, не устанавливая само средство BitLocker. Это позволяет избежать потребность в перезапуске, поскольку не включает драйвер фильтра. Имя этого компонента - "RSAT-BitLocker".
BitLocker нормально работает на компьютерах, использующих вариант установки Server Core, но диспетчер серверов нельзя использовать для установки BitLocker на Server Core, также нельзя использовать графический интерфейс для управления BitLocker на Server Core. Вместо этого используйте средства командной строки pkgmgr или ocsetup для установки компонентов.
После того, как двоичные файлы BitLocker установлены, а диски настроены требуемым образом для раздельной нагрузки, средство BitLocker можно включить на томе ОС. Апплет панели управе BitLocker имеет те же значки и параметры в Windows Server 2008, что и в Windows Vista с пакетом обновления 1. Чтобы включить расширенные режимы BitLocker, необходимо подправить параметры по умолчанию, используя редактор локальных политик или объект групповой политики, применимый к серверу.
На Server Core или в случае нежелательности использования панели управления можно использовать manage-bde.wsf для включения BitLocker. Чтобы включить BitLocker на диске C:, введите
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
где C: – диск, который следует зашифровать, а F:\ – это ключ для порта USB или другой том, где будет храниться копия ключа восстановления (в двоичном формате). Также можно использовать путь в формате UNC, чтобы сохранить ключ восстановления на сетевом диске. Также будет создан и отображен пароль восстановления (в формате цифрового текста). Можно также добавить параметр skiphardwaretest, если не приходится сомневаться, что оборудование отвечает всем требованиям BitLocker. Это сэкономит одну перезагрузку.

Ситуации использования на сервере
Давайте теперь рассмотрим некоторые конкретные ситуации, в которых средство BitLocker полезно для серверов. Не забывайте, что, как я упоминал, средство BitLocker разработано для помощи в защите против атак на автономное оборудование – рода атак, которые происходят, когда Windows не работает.
Филиалы Один из первых и наиболее очевидных способов использовать средство BitLocker на сервере – как часть стратегии филиалов Windows Server 2008. Где-то между четвертью и третью всех серверов установлены в офисах филиалов – то есть в офисах, где физическая безопасность, доступ к поддержке со стороны отдела ИТ и, возможно, связь с центрами данных могут быть меньше обычного. Филиалы также являются привлекательной целью для атак. В сочетании с такими компонентами, как контролеры доменов только для чтения (read-only domain controller – RODC), средство BitLocker помогает в защите конфиденциальных данных, которые должны храниться в филиале, чтобы быть полезными, и не могут быть так же надежно физически защищены, как в центре данных.
Это хороший шанс продумать нужный уровень защиты. Что важнее – предотвратить несанкционированный доступ к данным или потребовать от сервера возможности возвращаться к работе немедленно и без вмешательства? По моему мнению, во многих филиалах было бы приемлемо требовать ПИН-кода для перезапуска сервера, но каждая компания должна сама решить для себя этот вопрос.
Диски при перевозке Часто возникает необходимость отправки в удаленное место данных на жестком диске. Это может быть отправка одного диска или предварительная настройка и отправка целого сервера. В ходе пересылки данные на этих дисках находятся вне досягаемость владельца и могут быть скопированы, утеряны или украдены.
Чтобы уменьшить этот риск, включите средство BitLocker на томах в компьютере перед отправкой, затем удалите всю защиту ключами, кроме ключа восстановления или пароля восстановления. Этот ключ или пароль затем можно перевезти вручную, отдельно от сервера, или даже передать по телефону либо по зашифрованной электронной почте получающему персоналу. После получения компьютера или диска для разблокирования диска используется пароль восстановления. Диск может быть оставлен зашифрованным (добавьте обратно все прочие формы защиты ключами) или, при желании, полностью дешифрован после доставки.
Это особо эффективная форма предварительной подготовки контроллеров домена или серверов для филиалов.
Кража сервера Как отмечалось в предыдущем разделе, угроза кражи сервера (особенно контроллера домена) весьма реальна. Воры могут прихватить переносной ПК при возможности, но сервер может быть тщательно выбранной целью. Если средство BitLocker настроено на требование только проверки целостности TPM, украденный сервер может быть просто включен и загружен. По контрасту с этим, если диски в сервере защищены с помощью средства BitLocker, и оно настроено в расширенном режиме (требуя ключа для порта USB, ПИН-кода или того и другого), ворам будет очень тяжело извлечь какую-либо полезную информацию за разумный промежуток времени.
Кража диска Но, напротив, если украден только диск, TPM по-прежнему будет серьезной защитой. Только TPM с изначального сервера может быть использован для разблокировки диска, защищенного средством BitLocker, так что диск нельзя будет просто вставить в другой компьютер и прочитать.
Пониженная открытость атакам Заказав оборудование сервера, в которое входит микросхема TPM, и используя проверку целостности платформы BitLocker, можно повысить защиту от некоторых форм вредоносных программ. В частности, средство BitLocker будет обнаруживать изменения, внесенные, когда Windows не работает, или изменения, внесенные в компоненты раннего запуска, особенно если вредоносная программа, такая как комплект для захвата прав администратора, требует перезагрузки для установки. Это не всеобъемлющее решение, но в сочетании с такими функциями, как целостность кода Windows, и продуктами вроде Microsoft® ForefrontTM Client Security, оно становится еще одним эффективным уровнем глубокой защиты.
Безопасное списание Один из случаев, когда средство BitLocker наиболее полезно, возникает в конце жизненного цикла сервера или диска. Как часто вы слышали о дисках или серверах, выкинутых без правильного списания? Знаете ли вы, что использованные жесткие диски порой продаются на аукционе дороже новых, поскольку неразборчивые в средствах покупатели надеются вытянуть с них полезную информацию?
К счастью, средство BitLocker предоставляет альтернативу затратному и требующему массу времени процессу очистки диска от полезных данных. Суть ее в том, что на диск не записывается информации в полезном формате. Зашифрованные данные бесполезны, а удаление всей информации о ключе является быстрым и простым действием. После этого не имеет значения, что произойдет с самим жестким диском – его можно продать, переработать, использовать в другом месте, в общем, сделать что угодно, не опасаясь, что он попадет не в те руки.
В Windows Vista и Windows Server 2008 команда форматирования была обновлена, чтобы уничтожать ключи BitLocker, включая множественные перезаписи. Так что теперь существует простой и эффективный способ списать диск.

Последние новости
В момент написания мною этой статьи, надо признать, за несколько недель до того, как читатели увидят ее опубликованной, ряд недавних статей, документов и новостных сообщений обсуждают некоторые интересные характеристики оборудования и то, как они влияют на BitLocker, другие компоненты безопасности Windows и прочие средства шифрования от различных поставщиков. Я хотел бы уделить немного времени рассмотрению некоторых находок.
Одна из них была опубликована исследователями из Принстонского университета, продемонстрировавшими (и весьма убедительно!) «осадок DRAM» (информация доступна на citp.princeton.edu/pub/coldboot.pdf). Попросту говоря, доступ к содержимому памяти компьютера возможен в течении некоторого периода времени после отключения памяти от питания. Средство BitLocker, само собой, держит ключи в памяти во время работы Windows, и есть опасение, что ключи могут быть добыты неавторизованными пользователями.
Другая демонстрация, от Адама Буало (Adam Boileau) (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) показывает, как интерфейс IEEE 1394 (часто именуемый FireWire) делает возможным прямой доступ к памяти (direct memory access – DMA), который можно использовать для извлечения из Windows секретов, таких как пароли или ключи дешифрования. Интересно здесь то, что DMA практически является смыслом 1394; это не ошибка, а то, для чего интерфейс Firewire был разработан.
Общая черта этих атак – необходимость доступа к работающему (или очень недавно работавшему) компьютеру. Средство BitLocker не предназначено для защиты от таких атак и не устраняет необходимость в физической безопасности. Адекватная глубокая защита требует использования ряда функций и средств, создания среды физической безопасности, выделения ключевых корпоративных политик и постоянного обучения пользователей.
Эти открытия не так уж новы. Они были известны в течении некоторого времени и даже обсуждаются в наборе средств шифрования данных от Microsoft® (DET). Анализ рисков, предоставляемый в DET, имеет своей основной целью помочь пользователям сбалансировать безопасность с полезностью, а также со стоимостью применения и управления. Это далеко не тривиальный вопрос. Мы верим, что грамотные клиенты наилучшим образом подходят для принятия решений о компромиссах между безопасностью, полезностью и ценой.
Вдобавок к DET, некоторые из моих коллег предоставили превосходные комментарии и руководства. Во-первых, Расс Хамфрис (Russ Humphries) рассказывает о компромиссах в области безопасности, в свете осадка DRAM в своем блоге по адресу go.microsoft.com/fwlink/?LinkId=115217. Далее, Дуглас МакАйвер (Douglas MacIver) написал о дополнительных специальных действиях по настройке и контрмерах, которые можно принять сейчас в блоке группы целостности систем (SI) по адресу go.microsoft.com/fwlink/?LinkId=115218. Я очень рекомендую уделить время чтению обеих этих полезных записей. Стоит также прочесть DET.
Ключевая среди этих рекомендаций заключается в использовании расширенного режима (то есть, требующего ключа для порта USB или ПИН-кода) и предотвращении оставления компьютера без присмотра в режиме сна (используйте вместо этого гибернацию).

Заключение.
Средство BitLocker остается одним из наиболее полезных компонентов Windows Vista. С выходом пакета обновления 1 (SP1) оно было усовершенствовано в порядке прямого ответа на желание пользователей увидеть больше возможных ситуаций использования и соответствие более широкому спектру потребностей защиты данных. Распространение этой защиты статических данных Windows Server 2008 дает больше способов защищать данные и обеспечивать соответствие нормативным требованиям независимо от того, хранятся ли эти данные на серверах или рабочих станциях клиентов, в центре данных, филиале или у мобильного сотрудника.

Байрон Хайнз (Byron Hynes) – специалист по разработке стратегий в области корпоративных технологий в группе по работе с партнерами и корпоративными клиентами корпорации Майкрософт, в основном занимающийся функциями и продуктами безопасности. До присоединения к этой группе он работал в отделе Windows Server и вплотную занимался BitLocker (целостностью системы) с 2005 г. Вопросы и комментарии приветствуются. Привлеките его внимание на Tech•Ed 2008 или отправьте электронное письмо по адресу bhynes@microsoft.com.


Безопасность
Блокировка приложений с помощью политик ограниченного использования программ
Крис Корио (Chris Corio) and Durga Prasad Sayana
Краткий обзор:
  • Как работают политики ограниченного использования программ
  • Инвентаризация приложений в своей среде
  • Создание и применение политик

Когда специалисты по ИТ ищут способы уменьшить совокупную стоимость владения настольных машин, в голову обычно приходят две стратегии. Первый – это устранить
учетные записи пользователей настольных компьютеров из группы администраторов. А второй – ограничить круг приложений, которые пользователи могут запускать. Решение таких проблем в корпоративной среде может быть непростым, но Windows Vista® предлагает некоторые технологии, которые могут помочь в достижении этих целей.
Windows Vista и ее функция контроля учетных записей пользователей (UAC) – это гигантский шаг вперед в плане помощи специалистам по ИТ в переводе их корпоративных пользователей в группу пользователей («Обычные пользователи»). UAC переориентировал контекст безопасности по умолчанию для всех приложений с администраторов на пользователей. Этот перенос в группу пользователей все еще является нешуточной задачей, но по мере того, как отрасль приспосабливается к новой парадигме, задача со временем станет легче.
После анализа проблем переноса пользователей в группу пользователей (или порой в ходе этого процесса) многие администраторы составляют каталог приложений, необходимых их пользователям, и обдумывают действия по допуску лишь этих приложений. Функция политики ограниченного использования программ разработана, чтобы помочь специалистам по ИТ именно в этом.
Она позволяет просто указать, запуск каких приложений допустим, и затем развернуть политику с помощью групповой политики. Внедрение такой политики на всем предприятии может уменьшить совокупную стоимость владения (TCO), поскольку такая блокировка уменьшит проблемы, связанные с неподдерживаемыми приложениями. (Политики ограниченного использования программ также можно использовать рядом интересных и весьма радикальных способов, о которых мы рассказываем в боковой врезке «Минималистическая политика ограниченного использования программ».)

Как работают политики ограниченного использования программ
Политика ограниченного использования программ имеет своей целью контроль за тем, какой именно код может исполнять пользователь на компьютере, работающем под управлением Windows Vista. Администратор создает политику, определяющую, что может (или не может) выполняться в его среде. Эта политика затем вычисляется каждый раз и в каждом месте, где возникает возможность исполнения кода. В число этих моментов входят создание процесса, вызов ShellExecute и запуск сценария. (Мы подробнее рассмотрим все это чуть позже.)
Если определено, что приложению позволено исполняться, то приложение запустится. Однако если определено, что приложению не позволено исполняться, то приложение будет заблокировано, а пользователь уведомлен. Например, при попытке запустить недозволенный пасьянс «Косынка» из меню «Пуск» будет получен диалог, подобный показанному на рис. 1.
Рис. 1 При блокировании приложения появляется диалог
Рис. 1 При блокировании приложения появляется диалог (Щелкните изображение, чтобы увеличить его)
Интерфейсом пользователя для определения политик ограниченного использования программ является редактор объектов групповой политики (GPOE), и именно там создается политика блокировки. Существует широкий набор методов для определения того, какой код может или не может выполняться. После завершения и тестирования политики ее можно развернуть.

Определение политик ограниченного использования программ
Первое значимое решение, которое будет принято, решение, которое существенно повлияет на работу политик ограниченного использования программ в среде, – это выбор типа правила по умолчанию. Политики ограниченного использования программ могут быть развернуты в одном из двух режимов: списка разрешений или списка запретов. По сути выбирается, следует ли создать политику, описывающую каждое приложение, выполнение которого дозволено, или политику, определяющую каждое приложение, которое не может выполняться.
В режиме списка разрешений правилом по умолчанию внутри политики является ограничение, и все приложения, выполнение которых не дозволено прямо, блокируются. В режиме списка запретов правилом по умолчанию является отсутствие ограничений, и блокируются только прямо указанные приложения.
Как несложно догадаться, режим списка запретов является нереалистичным подходом, если необходимо широкое уменьшение TCO и преимущества безопасности, вытекающие из блокировки приложений. Создание и поддерживание широкого списка, который блокирует все вредоносные программы и иные проблемные приложения, будет практически невозможным; в силу этого мы рекомендуем применять политики ограниченного использования программ в режиме списка разрешений, а это значит, что правилом по умолчанию будет ограничение.

Инвентаризация приложений в своей среде
Если требуется разработать политику, которая укажет, какие приложения могут выполняться, необходимо определить, какие именно приложения требуются пользователям. Функция политики ограниченного использования программ предлагает функцию расширенного ведения журнала с очень простой политикой, помогающую понять, какие именно приложения работают в среде.
На тестовом наборе компьютеров внутри среды разверните политики ограниченного использования программ с отсутствием ограничений в качестве правила по умолчанию и удалите все прочие дополнительные правила. План состоит в том, чтобы включить политику ограниченного использования программ, но не позволить ей ограничивать приложения, а вместо этого использовать ее для простого отслеживания того, что работает.
Далее создайте следующий параметр реестра, чтобы включить функцию расширенного ведения журнала и указать путь к месту, в которое следует записывать файл журнала:
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>
Теперь, когда запускается приложение и проверяется политика ограниченного использования программ (она проверятся, несмотря на то, что сейчас позволяет работать всему), в файле журнала появляется запись.
В каждую запись в журнале входит сторона, вызывающая политику ограниченного использования программ, и идентификационный номер вызывающего процесса (PID), проверяемая цель, тип правила политики ограниченного использования, который был затронут, и идентификатор для правила. Вот пример записи, созданной при двойном щелчке пользователя программы notepad.exe:
explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}
Этот файл журнала представляет весь исполняемый код, который политика ограниченного использования программ будет проверять, когда она включена и установлена на блокировку приложений. Это значит, что для каждой записи в файле журнала необходимо решить, должна ли она быть учтена в разрешенном списке. Обратите внимание, что можно будет увидеть несколько проверяемых двоичных файлов, являющихся частью Windows® и требуемых системой для работы.
Описываемый нами здесь прием ведения журнала предоставляет четкий способ понять, какие именно приложения политика ограниченного использования программ встретит в определенной среде. Но это не единственное возможное решение задачи.
Инвентаризатор, входящий в набор средств обеспечения совместимости приложений Майкрософт версии 5.0, дает возможность проведения инвентаризации приложений в среде. Это средство предлагает набор различных способов обнаружения установленных приложений и сводит результаты в центральную базу данных.

Создание дополнительных правил
Теперь, когда имеется список приложений, которым должно быть позволено работать в среде, можно приступать к созданию самих правил, которые позволят им работать. Функция политики ограниченного использования программ использует два способа определения политики – один основан на криптографических свойствах приложения (таких как хэш-код), а второй определяет доверенный путь или папку, в которых должны находиться доверенные приложения.
На рис. 2 показано, где следует добавить правила в узле политик ограниченного использования программ GPOE (gpedit.msc), чтобы позволить приложениям работать. Самым прямолинейным способом определения приложений в среде является создание правила хэширования для каждого двоичного файла, встреченного в фазе ведения журнала.
Рис. 2 Использование gpedit.msc для создания политик ограниченного использования программ
Рис. 2 Использование gpedit.msc для создания политик ограниченного использования программ (Щелкните изображение, чтобы увеличить его)
Поскольку хэш-код является уникальным значением, которое возвращает определенный набор файлов, каждый двоичный файл в политике должен иметь особый хэш-код. Этот подход особенно безопасен и позволяет выполняться только конкретным двоичным файлам в политике.
Само собой, у него есть свои недостатки. Например, в среде может запросто находиться несколько тысяч двоичных файлов. Создание всех этих правил в интерфейсе пользователя политик ограниченного использования программ может быть сложным, а по мере того, как число правил становится особенно большим, производительность может пострадать. Вдобавок, при каждом обновлении приложений в среде будет требоваться развертывание в среде одного или нескольких новых правил хэширования. Обновление настолько крупной политики по мере обновления приложений может стать тяжкой ношей.
К счастью, этой ноши можно избежать, поскольку существуют два других пути определения правил, упрощающие использование политик ограниченного использования программ в среде. Продвигаясь далее по пути криптографической безопасности, можно создать правило, допускающее выполнение любого двоичного файла, подписанного определенным сертификатом.
Это помогает упростить обслуживание списка политик, поскольку при обновлении приложения новые двоичные файлы обычно будут подписываться тем же сертификатом, что и предыдущие. Однако, если предыдущая версия двоичного файла не должна выполняться в среде, необходимо добавить ограничивающее правило хэширования, чтобы предотвратить его допуск.
По умолчанию, для политик ограниченного использования программ отключена проверка правил сертификатов. Это необходимо по двум причинам.
Во-первых, правила сертификатов в политиках ограниченного использования программ определены тем, что находится в хранилище доверенных издателей системы. Поскольку хранилище доверенных издателей используется не только для правил политик ограниченного использования программ, использование его для компонента политик ограниченного использования программ требует дополнительного времени и умственных усилий.
Вторая причина состоит в том, что для определения, верна ли подпись файла, необходимо взять хэш-код файла и сравнить его с информацией подписи. Хэширование файла – весьма трудозатратная операция, поскольку весь файл необходимо считать с диска и обработать для вычисления этого хэш-кода.
Чтобы включить правила сертификатов, перейдите к узлу политик ограниченного использования программ и выберите «Объект принудительного применения» в области результатов. Далее дважды щелкните для открытия его диалога свойств и выберите обеспечение выполнения правил сертификатов с помощью переключателя.
Другим обычным способом определения кода является использование пути кода на локальном компьютере. Это эффективная и экономичная методика, но имеющая один недостаток – необходимость удостовериться, что параметры безопасности установлены на папке верно.
Если добавлено определенное правило пути, и это правило позволяет пользователям записывать там файлы (на рабочий стол, к примеру), то они смогут запускать что хотят, просто помещая исполняемый файл в эту папку. Однако если пользователи не входят в группу администраторов, обычно у них нет возможности изменять что-либо в каталогах Program Files или Windows. Это значит, что если все приложения помещены в каталог Program Files, а пользователи не являются администраторами, то следует воспользоваться правилами путей для получения простой и эффективной политики.
Правила путей предлагают некоторые другие функции, делающие их более подходящими для некоторых сред. Они допускают подстановочные символы и позволяют использовать переменные среды для упрощения правил, которые являются переносимыми в среде, – в конце концов, %systemdrive% может и не быть c:\ для некоторых пользователей.
Что касается производительности и обслуживания, то это, вероятно, самый беспроблемный путь определения кода. О правилах путей определенно следует подумать, но необходимо помнить о дополнительных соображениях безопасности.

Правила зон сетей
В политику ограниченного использования программ входит также тип правил, именуемых правилами зон сетей. Первоначальное предназначение этих правил было основано на идее, что источники определенного исполняемого кода могут быть найдены и наделены доверием, и что в силу этого код может быть допущен к выполнению. Увы, это особенно сложная задача, и в результате они никогда не работали особенно хорошо. Сейчас эти правила не соблюдаются в большинстве точек входа политики ограниченного использования программ.
В случаях, когда большинство приложений устанавливаются в каталог %Program Files%, но существуют другие исполняемые файлы, установленные в других местах и подписанные определенным сертификатом, имеет смысл использовать правила различных типов. Немного правил хэширования, несколько правил путей – и подходящая политика готова.
Но помните, что эти правила обрабатываются в определенном порядке (как показано на рис. 3). Наиболее конкретными являются правила сертификатов, далее следуют правила хэширования, затем правила путей и, наконец, правила путей с подстановочными символами в них. Так что если код части обнаружен правилом хэширования и правилом пути, приоритетным будет уровень безопасности правила хэширования.
Рис. 3 Порядок обработки правил
Рис. 3 Порядок обработки правил (Щелкните изображение, чтобы увеличить его)

Применение политик
Политики ограниченного использования программ обеспечивают широту охвата на защищаемой системе. Идея состоит в том, что любое место, из которого может быть исполнен код, должно быть интегрировано с политикой ограниченного использования программ и, в свою очередь, проверять политику, чтобы увидеть, допустим ли запуск исполняемого кода.
Хотя имеется много мест, проверяющих политику ограниченного использования программ, наиболее прямолинейной точкой входа является CreateProcess. При работе CreateProcess политика проверяется, чтобы определить, допустимо ли исполнение двоичного файла, представляющего приложение. Проверка политики выполняется интерфейсом API SaferIdentifyLevel, документация по которому общедоступна. Общая процедура проиллюстрирован на рис. 4. (Мы расскажем о SaferIdentifyLevel подробнее чуть погодя.)
Рис. 4 Использование SaferIdentifyLevel для определения возможнсти исполнения двоичного файла
Рис. 4 Использование SaferIdentifyLevel для определения возможнсти исполнения двоичного файла (Щелкните изображение, чтобы увеличить его)
Следующим наиболее часто (после CreateProcess) используемым интерфейсом API, в котором применяется политика ограниченного использования программ, является ShellExecute. Это интерфейс API, который вызывается, когда пользователь щелкает приложение в меню «Пуск» или дважды щелкает что-нибудь на рабочем столе.
ShellExecute может быть вызван на широком наборе форматов файлов. В таких случаях, как файл TXT, вызов ShellExecute на файле не приводит к реальному исполнению файла – само собой, технически файл открывается. По этой причине политика ограниченного использования программ содержит список типов исполняемых файлов, позволяющий ей контролировать, какие типы файлов проверяются при вызове ShellExecute. Настроить этот список типов исполняемых файлов можно в интерфейсе пользователя политики ограниченного использования программ.
Помимо CreateProcess и ShellExecute, имеются две другие ключевые точки интеграции: LoadLibrary и серверы сценариев. Важность LoadLibrary как места для проверки исполняемого кода очевидна, но, увы, LoadLibrary представляет некоторые особые ограничения.
У большинства приложений имеется один исполняемый файл и несколько загружаемых библиотек DLL. При этом в системе обычно работает масса приложений. Это значит, что LoadLibrary потребует массы проверок политики. В зависимости от существующей политики определения кода использование этой точки входа может оказаться очень ресурсоемким – представьте себе проверку хэш-кода каждой библиотеки DLL, загружаемой на системе, что включает в себя хэширование двоичного файла и сравнение его со списком из, возможно, тысяч хэш-кодов.
По умолчанию эта функция отключена, но ее можно включить вручную. Чтобы сделать это, перейдите к узлу политик ограниченного использования программ в gpedit.msc и дважды щелкните «Применение». После этого выберите переключатель «Все файлы программ».
Как мы уже упоминали, политика ограниченного использования программ интегрирована с большинством серверов сценариев в системе. В их число входят cmd, VBScript, Cscript и JScript®. Эти, а также другие точки входа используют основной интерфейс API применения политики ограниченного использования программ: SaferIdentifyLevel.
SaferIdentifyLevel определяет, допустимо ли выполнение определенного исполняемого файла, рассматривая информацию о идентификации в соответствующих политиках ограниченного использования программ. Это интерфейс API, документация по которому общедоступна. Серверы сценариев и исполняемые среды сторонних разработчиков могут и должны использовать его в целях интеграции с политикой ограниченного использования программ, чтобы политика могла определить, следует ли допустить выполнение элемента исполняемого кода.

Работа в качестве обычного пользователя
Не столь известной возможностью политики ограниченного использования программ является возможность фильтрации полномочий определенных приложений после их запуска. Эта функция появилась в Windows XP, но не была представлена в интерфейсе пользователя политики ограниченного использования программ до выхода Windows Vista.
В этом роде она была предшественником контроля учетных записей Windows Vista, поскольку ее можно было использовать для запуска приложения в качестве обычного пользователя, даже если пользователь был членом группы администраторов. Именно это происходит при создании правила и установки уровня безопасности на «Обычный пользователь» в пользовательском интерфейсе дополнительных правил.
Как функция фильтрации маркеров контроля учетных записей, так и правила для обычных пользователей политик ограниченного использования программ пользуются нижележащим интерфейсом API, реализующим то же поведение, что и интерфейс API CreateRestrictedToken. Однако общие архитектурные различия в технологиях очень значительны. Но контроль учетных записей отличается от политики ограниченного использования программ в ряде ключевых аспектов.
Во-первых, в Windows Vista со включенным контролем учетных записей каждое приложение запускается с маркером безопасности, подобным члену по умолчанию группы «Пользователи», даже если пользователь является администратором. Это достижимо с помощью политики ограниченного использования программ, но при этом нет никакой возможности запустить приложение с помощью реального маркера администратора – например, когда пользователю нужно установить приложение Изменение в контексте безопасности по умолчанию и простота доступа к принадлежащему пользователю маркеру полного администратора являются ключевыми преимуществами контроля учетных записей.
Второе различие состоит в том, что в случае исполняемых файлов сам код выражается с уровнем прав, необходимых для его функционирования. Это ключевое различие, поскольку независимые поставщики программного обеспечения (ISV) и разработчики понимают потребности своего кода. Например, если приложению панели управления необходимо изменить что-либо, требующее для этого прав администратора, оно может указать это в своем манифесте. Таким образом, поставщик ПО может описать права, необходимые приложению, вместо того, чтобы навязывать ему определенный уровень прав без возможности этот уровень изменить.
Пока стоит избегать правил обычных пользователей, если нет настоящего знакомства с их работой. Контроль учетных записей является отличным способом вывести пользователей настольных систем из группы администраторов, так что стоит серьезно обдумать простое оставление контроля учетных записей в корпоративной среде.

Нынешнее применение политик ограниченного использования программ
При использовании политики ограниченного использования программ следует учитывать немало движущихся частей. Но это выглядит не так, как можно подумать, и на самом деле читатели уже могут использовать политики ограниченного использования программ, не осознавая этого. Например, при установке родительского контроля в системе Windows Vista политики ограниченного использования программ используются для контроля над исполнением приложений.
Политика ограниченного использования программ была важным технологически усовершенствованием, когда она впервые появилась в Windows XP. Но на самом деле блокировка приложений лишь сейчас начинает привлекать внимание специалистов по ИТ.
У функции политики ограниченного использования программ в Windows Vista еще есть свои шероховатости, которые нужно отполировать, но очевидно, что администраторы желают иметь этот повышенный контроль над тем, что исполняется в их средах. К счастью для всех нас, эта технология продолжит развиваться, упростит для специалистов по ИТ управление их системами и понизит затраты на поддержание среды Microsoft Windows.
Минималистическая политика ограниченного использования программ
Одним из применений политики ограниченного использования программ является создание политики, фиксирующей Windows в режиме интерактивного терминала. Майкрософт даже производит набор средств, именуемый SteadyState™, для создания такого терминала. Однако если необходимо только блокировать приложения, которые могут выполняться, это можно сделать проще.
Чтобы допустить минимальный набор приложений, требующихся для входа в Windows Vista, создайте политику, позволяющую logonui.exe и userinit.exe запускаться из %windir%\system32. Большинству пользователей, вероятно, также потребуется допустить запуск следующих приложений:
dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....
Если необходима оболочка Windows по умолчанию, следует добавить также %windir%\explorer.exe.
В качестве альтернативы можно выбрать загрузку прямо в приложение, такое как Internet Explorer®. В таком случае будет необходимо вписать iexplore.exe вместо explorer.exe.
Другим аспектов этой минималистической политики является отказ от помещения пользователей в группу администраторов. Это важно, поскольку иначе они могут обойти политику. Однако поскольку они будут иметь возможность запускать лишь самый базовый набор приложений и не будут иметь прав администратора, у них не будет прав для установки приложений или обслуживания системы.
Для таких машин необходим какой-то способ делать это. Если предстоит обновлять и обслуживать эти компьютеры путем локального входа в систему через учетную запись администратора, следует также выбрать переключатель, применяющий политику ограниченного использования программ ко всем пользователям, кроме локальных администраторов. В политику должны также входить consent.exe и cmd.exe. Это позволит администратору запускать любые варианты администрирования из командной строки администратора.
Обратите внимание, что контроль учетных записей ограничивает права маркера безопасности по умолчанию пользователя, чтобы он не выглядел членом группы администраторов. Даже если вышеуказанный параметр установлен на неприменение политики к администраторам, она все же будет применена к пользователям. Только после прохода через повышение уровня прав в контроле учетных записей, администратор действительно получает полные права администратора, и политика ограниченного использования программ перестает применяться к нему.

Крис Корио (Chris Corio)Крис Корио (Chris Corio) проработал в группе безопасности Windows корпорации Майкрософт более пяти лет. Его основными занятиями в Майкрософт были технологии безопасности приложений и методы управления, обеспечивающие безопасность Windows. С Крисом можно связаться по адресу winsecurity@chriscorio.com.
Durga Prasad Sayana﻿Дурга Прасад Саяна (Durga Prasad Sayana) – специалист по разработке и тестированию программного обеспечения в группе базовой безопасности Windows. Его основными интересами являются технологии безопасности и тестирование программного обеспечения. Связаться с ним можно по адресу durgas@microsoft.com.


Безопасность
Управление брандмауэром Windows Vista
Йеспер М. Йоханссон (Jesper M. Johansson)
Краткий обзор:
  • Типы правил и ситуации
  • Профили брандмауэра
  • Правила изоляции доменов
  • Проблема фильтрации исходящего трафика

Недавно в своем блоге я разместил статью о брандмауэре Windows Vista. В ней просто указываются некоторые привлекательные функции, но не приведены подробные указания по развертыванию.
В данной статье я более подробно рассматриваю некоторые функции брандмауэра Windows Vista®, разработанные специально для упрощения управлением предприятием. Я также даю советы по их использованию для упрощения вашей работы и повышения безопасности пользователей.
Недавний выпуск пакета обновления 1 (SP1) для Windows Vista дает основания ожидать начала процесса развертывания Windows Vista на предприятиях. (Обычно предприятия переходят на новую ОС после выпуска первого пакета обновления для этой ОС.) Если вы являетесь одним из специалистов по ИТ и теперь более серьезно рассматриваете вопрос о развертывании Windows Vista в среде вашего предприятия, вам следует обратить внимание на брандмауэр. После изучения возможностей брандмауэра Windows Vista вы можете захотеть пересмотреть соглашение по пакету безопасности стороннего производителя, чтобы исключить из него брандмауэр.

Будущее и настоящее брандмауэров Windows
В брандмауэре в исходном выпуске Windows® XP многое оставляло желать лучшего. Хотя он в полной мере соответствовал функциональным возможностям обеспечения безопасности коммерческих отдельных брандмауэров того времени, в нем не было ничего нового или новаторского.
Версия, включенная в пакет обновления 2 (SP2) для Windows XP, была полностью изменена. Она была специально разработана для упрощения управляемости предприятия. Брандмауэр, входящий в состав Windows XP с пакетом обновления 2 (SP2), является очень привлекательным с точки зрения небольшого размера, централизованного управления, эффективности и отсутствия вмешательства в работу системы. Но что, возможно, самое важное, брандмауэр, входящий в состав Windows XP с пакетом обновления 2 (SP2), предоставляет крайне важную возможность: защита системы при загрузке.
Последнее является исключительно важным. В прошлом я видел множество систем, зараженных во время загрузки даже при включенном брандмауэре. Фактически, во время пика эпидемии вируса Blaster фиксировалась одна атака каждые четыре минуты. Другими словами, если компьютер, подключенный к Интернету, оставался в незащищенном состоянии, он мог быть заражен в среднем через четыре минуты. А если использовался брандмауэр, не защищающий систему при загрузке, 1 система из 12 заражалась при загрузке. Эти цифры и вынудили корпорацию Майкрософт включить в брандмауэр Windows XP с пакетом обновления 2 (SP2) возможность защиты системы при загрузке.
В Windows Vista брандмауэр был снова полностью реконструирован. Наиболее очевидным изменением с точки зрения управления является объединение интерфейсов управления протокола IPsec и брандмауэра. Это очень логичное изменение. Протокол IPsec и брандмауэр предназначены для блокирования неразрешенных действий. Отличие заключается в том, что параметры брандмауэра, определяющие разрешенные действия, не детализированы, а блокирование или разрешение адресного пространства большого объема в IPsec является громоздким.
Благодаря наличию двух функций в одном интерфейсе управления администраторы могут беспрепятственно использовать обе технологии, меньше беспокоясь о том, что для чего-то необходимо правило IPsec, а для другого – фильтр брандмауэра. По существу, доступно единое представление поверхности сетевой атаки системы, позволяющее свести к минимуму опасность возникновения ошибок.
В пакете обновления 1 (SP1) для Windows Vista к функциям брандмауэра был добавлен ряд улучшений надежности. Также были добавлены новые алгоритмы, прежде всего алгоритмы набора B, для использования в IPsec. Это набор алгоритмов шифрования, включающий алгоритмы Advanced Encryption System (AES), Elliptic Curve Cryptography (ECC) и Secure Hash Algorithm (SHA) 256 и 384.
Однако, что самое главное, в пакете обновления 1 (SP1) добавлена поддержка защиты доступа к сети (NAP). NAP – это средство применения политики, обеспечивающее установку для управляемых и нескомпрометированных клиентов последних политик безопасности, обновлений и определений защиты от вредоносных программ до разрешения подключения клиентов к сети. NAP не может предотвратить подключение к сети вредоносных узлов, однако он гарантирует полное соответствие всех подобных узлов, если они не скомпрометированы активно.
Брандмауэр Windows, называемый брандмауэром Windows в режиме повышенной безопасности, также входит в состав Windows Server® 2008. Кроме того, все функции могут управляться удаленно и настраиваться по сети с помощью групповой политики.

Типы правил и ситуации
Сочетание возможностей брандмауэра и IPsec в интерфейсе управления означает появление двух различных типов правил: правил направления и правил подключения. Правила направления – это стандартные правила брандмауэра, определяющие разрешенный трафик в соответствующем направлении. Правила подключения определяют параметры защиты для подключений между компьютерами. Если проводить аналогию, правила направления схожи с правилами брандмауэра, известными из предыдущих версий брандмауэров, а правила подключения сходны с правилами IPsec, используемыми вместе с брандмауэром в Windows XP с пакетом обновления 2 (SP2).
Совмещение брандмауэра и IPsec в одном интерфейсе делает доступными несколько очень интересных ситуаций. Например, изоляция систем в сети – одна из наиболее ценных из доступных сегодня концепций безопасности. Корпорация Майкрософт называет это «изоляцией серверов и доменов».
При изоляции серверов и доменов используются как возможности IPsec, так и возможности брандмауэра. В соответствие с этим в новый интерфейс управления брандмауэра входят специальные функции для правил изоляции. Они используются, например, при необходимости ограничения подключения на основе атрибутов исходной системы или системы назначения, например, на основе членства в домене.
Как показано на рис. 1, при запуске мастера создания правила для нового безопасного подключения появляется запрос на указание типа создаваемого правила. При выборе «Изоляция» мастер настраивает определенные параметры, соответствующие правилу изоляции.
Рис. 1 Использование мастера создания правила для нового безопасного подключения для создания правила изоляции
Рис. 1 Использование мастера создания правила для нового безопасного подключения для создания правила изоляции (Щелкните изображение, чтобы увеличить его)
На рис. 1 также можно заметить, что в правиле изоляции упоминается состояние работоспособности. Правила, используемые для изоляции серверов и доменов и для защиты доступа к сети (NAP), одинаковы.
Для некоторых типов трафика невозможно применить проверку подлинности. Например, проверка подлинности для механизма разрешения имен через DNS, скорее всего, не требуется. Для конечных точек этого типа трафика необходимо правило освобождения от проверки подлинности. Правило освобождения от проверки подлинности в точности соответствует своему названию – оно освобождает трафик от требований IPsec.
Правило сервер-сервер названо не совсем верно. Хотя оно в основном используется для серверов, оно также может использоваться с клиентами. Правило сервер-сервер просто настраивает подключение на необходимость проверки подлинности. Оно отличается от правила изоляции не только тем, что для правила изоляции необходима проверка подлинности, также необходимо выполнение определенного дополнительного критерия, такого как членство в домене или состояние работоспособности.
Правило туннеля фактически определяет виртуальную частную сеть (VPN) типа «сеть-сеть» и туннель между шлюзами. Правила туннеля редко используются в Windows Vista, поскольку маловероятно, чтобы в Windows Vista использовались ее возможностями шлюза. Можно создавать полностью настраиваемые правила. Это позволяет настраивать все параметры правила.

Порядок правил
Порядок правил на первый взгляд может показаться довольно сложным. Для ознакомления с порядком правил необходимо сначала забыть о порядке. Смысл заключается не столько в порядке, сколько в выборе соответствия. Рассмотрим в качестве примера входящий трафик. Входящий трафик, не соответствующий правилам, разрешающим его, блокируется по умолчанию. Это можно рассматривать как порядок «разрешающие правила учитываются в первую очередь», но это предположение будет неверным. Если определенный пакет соответствует как разрешающему правилу, так и правилу блокировки, приоритет имеет блокирующее правило. Это означает, что соответствие, говоря простым языком, это следующее:
  1. Правила блокировки. Если пакет или подключение соответствует одному из них, оно отвергается.
  2. Разрешающие правила. Если пакет или подключение соответствует одному из них, оно разрешается.
  3. Поведение правила направления по умолчанию. Если отсутствуют соответствующие разрешающие правила или правила блокировки, трафик обрабатывается в соответствие с поведением, указанным в качестве поведения по умолчанию для трафика данного направления данного профиля. Для входящего трафика всех профилей это означает блокирование трафика в настройке по умолчанию. Для исходящего правила по умолчанию это означает разрешение трафика в настройке по умолчанию.
Процесс сопоставления управляется правилами обхода для проверенной подлинности (IPsec). При использовании этого типа правил разрешается весь трафик, прошедший проверку подлинности и соответствующий другим параметрам правила, независимо от его соответствия другим правилам. Правила обхода для проверенной подлинности – это правила направления, для которых установлен флажок «Переопределить правила блокировки», как показано на рис. 2. Они учитываются в первую очередь, чтобы трафик, прошедший проверку подлинности, всегда достигал системы. Это ключ к простому разрешению трафика от узлов, прошедших проверку подлинности, и блокировании трафика от остальных узлов. Это правило можно рассматривать в качестве 0 в порядке. Таким образом, полный список порядка правил выглядит следующим образом.
Рис. 2 Установка флажка «Переопределить правила блокировки» для настройки правила обхода для проверенной подлинности
Рис. 2 Установка флажка «Переопределить правила блокировки» для настройки правила обхода для проверенной подлинности (Щелкните изображение, чтобы увеличить его)

0. Правила обхода для проверенной подлинности
1. Правила блокировки
2. Разрешающие правила
3. Поведение правила направления по умолчанию

Наличие нескольких правил в каждом классе, соответствующем шаблону трафика, не имеет значения. Если устанавливается соответствие трафика какому-либо правилу, обработка правила прекращается.

Общий, частный и доменный
Материалы о сетях
  • Центр безопасности TechNet Security Center
  • Использование программы командной строки Netsh Advfirewall
  • Правила безопасности для брандмауэра Windows и подключения на основе IPsec в Windows Vista и Windows Server 2008
  • Наблюдение за безопасностью с помощью мастера настройки безопасности в Windows Server 2008

Новый брандмауэр имеет три профиля: общий, частный и доменный. С другой стороны, брандмауэр Windows XP с пакетом обновления 2 (SP2) имел два сетевых профиля: стандартный и доменный. Доменный профиль запускается автоматически при обнаружении компьютером контроллера домена. В противном случае в Windows XP использовался стандартный профиль. Благодаря этому для администратора безопасности предоставлялись многосторонние функции, с помощью которых он мог полностью заблокировать компьютер при его перемещении, сохраняя возможности удаленного управления, необходимого в сети организации. Но этот подход создавал определенные проблемы для некоторых пользователей, в частности, пользователей с личными домашними сетями. Поскольку в случаях, когда контроллер домена был недоступен для системы, всегда использовался стандартный профиль, доступ пользователя к системе был заблокирован.
Новый частный профиль, входящий в состав Windows Vista, помогает решить эту проблему. Теперь при подключении системы к новой сети необходимо указать, является ли сеть общедоступной (это просто новое название прежнего стандартного профиля) или частной, и настроить систему соответствующим образом. Система использует настроенные параметры при каждом подключении к этой сети на основе сетевых параметров, предоставленных серверами инфраструктуры сети. Это ни коим образом не стопроцентно надежное решение, но оно помогает лучше защищать большее количество сетей.
Также улучшена логика определения нахождения системы в домене. Результатом является более быстрый и надежный переход, а также меньшее количество систем, полагающих, что необходимо использовать общедоступный или частный профиль, в то время как система в действительности находится в домене.
Можно привязать правила к определенному типу сети, устраняя предоставление излишней информации и попытки подключения к системам в недоверенных сетях. Это одна из областей, в которых интеграция брандмауэра и IPsec начинает оправдывать себя.
Используя эти новые правила, можно указать некоторые ограничения, которые ранее были недоступны. Например, в течение многих лет злоумышленники использовали атаки с приманкой, направленные на то, чтобы пользователи выполнили подключения SMB (для сетей Windows) к недоверенным узлам, тем самым вызывая последовательность проверки подлинности, предоставляющую им пару вызов/ответ, которая может использоваться для взлома паролей. Более старые версии подобной атаки также использовались для снижения до обычной проверки подлинности или для повторного отображения пары вызов/ответ пользователя на исходном компьютере. Возможность использования первого приема была устранена несколько лет назад. Второй прием был устранен в Windows XP с пакетом обновления 2 (SP2), но необходимо иметь в виду, что предоставление пар вызов/ответ все равно является неразумным.
Во избежание этого можно использовать другую новую функцию брандмауэра Windows Vista— фильтрацию исходящего трафика. Например, администратор может заблокировать все исходящие подключения SMB (завершающиеся на портах TCP 135, 139, 445 и UDP 137, 138, 445) в общем профиле. Это усложняет использование системы в атаке с приманкой для получения пар вызов/ответ и предотвращает доступ к недоверенным общим файловым ресурсам Windows в Интернете.
Это опять же не является стопроцентно надежным решением. Например, если система уже скомпрометирована, это правило не прекратит передачу данных системой, поскольку злоумышленник может просто отключить его. Однако это может быть полезным в качестве меры защиты стабильных, но потенциально уязвимых систем.
В данном контексте необходимо упомянуть, что так же, как и в Windows XP с пакетом обновления 2 (SP2), в Windows Vista и Windows Server 2008 одновременно может быть активным только один профиль. Если в системе существуют два сетевых интерфейса, один из которых находится в домене, в другой – в общедоступной сети, к обоим интерфейсам будет применяться общедоступный профиль брандмауэра. Всегда будет использоваться наиболее ограничивающий профиль. Как вы можете догадаться, общедоступный профиль является более ограничивающим, чем частный, а частный профиль – более ограничивающим, чем доменный профиль. Так что имейте в виду, что правило блокировки исходящего трафика SMB может заблокировать много трафика через подключения VPN.
Для разрешения трафика через подключения VPN, если компьютер находится в частной или общедоступной сети, создаются правила направления, применяемые только к интерфейсам VPN. Чтобы это работало, интерфейсы VPN должны распознаваться Windows. Если не используется сервер VPN служб маршрутизации и удаленного доступа Microsoft®, перед широким развертыванием эту функцию необходимо проверить. В основном это проблема входящего трафика на клиент и любых создаваемых настраиваемых правил для исходящих подключений.

Создание правил брандмауэра
Создание правил в новом брандмауэре осуществляется гораздо проще. Мастер создания нового правила, показанный на рис. 3, позволяет определить правила всех обычных типов. Также включены предопределенные правила для определенных служб.
Рис. 3 Предопределенные правила в мастере создания нового правила
Рис. 3 Предопределенные правила в мастере создания нового правила (Щелкните изображение, чтобы увеличить его)
Предопределенные правила особенно важны. Изоляция серверов – это, по сути, такое ограничение служб, при котором они доступны только системам, для которых они необходимы. В серверных продуктах для упрощения этого может использоваться мастер настройки безопасности Windows, хотя при этом все-таки возникают определенные трудности. (Мастер настройки безопасности Windows рассматривался в выпуске журнала TechNet Magazine за март 2008 г.)
Но до настоящего времени подобные функции отсутствовали в клиентских версиях Windows. При использовании предопределенного правила большая часть тяжелой работы выполняется за вас — задача определения конечных точек, используемых службой. Брандмауэру известно, какую программу представляет «служба iSCSI» не только на уровне приложений; он также содержит предопределенные правила, описывающие определенные функции. Это позволяет обратить основное внимание на компьютеры, на которые должно распространяться правило. Это все еще трудная и требующая больше времени задача, но по крайней мере она уникальная для вашей среды.
Также присутствует настраиваемое правило (доступно в раскрывающемся списке на рис. 3), предоставляющее всю гибкость, ожидаемую от брандмауэра с проверкой подлинности. Например, при необходимости правила, разрешающего только трафик, зашифрованный с помощью IPsec, на странице «Действие» мастера, показанной на рис. 2, следует установить флажок для разрешения только безопасных подключений.
При установке этого флажка также можно включить шифрование. Если не включать шифрование, трафик будет использовать ESP-NULL (ESP с ключом NULL). Для проверки подлинности рекомендуется использовать IPsec. Это позволяет работать большинству средств управления сетями, поскольку трафик проходит через сеть в открытом виде, при возникновении же необходимости в шифровании необходимо просто установить флажок.
Во многих случаях шифрование сетевого трафика не настолько важно, как непринятие трафика от вредоносных узлов. Шифрование трафика в сети предотвращает просмотр содержимого пакета злоумышленником, получившим доступ к самой сети. Необходимость проверки подлинности в первую очередь может помешать отправке пакета и доступу злоумышленника. Конечно, во многих случаях шифрование на уровне сети имеет большое значение, но также существует множество случаев, когда необходима только проверка подлинности.

Создание правил изоляции доменов
В большинстве сред возможность отправки трафика рабочей станции должно иметь ограниченное количество компьютеров. По крайней мере, правила изоляции доменов должны быть настроены для всех рабочих станций. Это сложно выполняется в Windows XP, но просто в Windows Vista.
Сначала откройте используемое средство управления и выберите узел «Правила безопасности подключения». Затем щелкните узел правой кнопкой мыши и выберите «Новое правило», появится диалоговое окно, показанное на рис. 1. Выберите узел «Изоляция» и щелкните «Далее». Теперь следует выбрать необходимость принудительного выполнения правила. В большинстве случаев на рабочих станциях не требуется проверка подлинности для входящего трафика. Благодаря рабочей станции могут отправлять трафик только компьютеры, входящие в домен. Однако для запроса служб от служб инфраструктуры система должна разрешать передачу определенного исходящего трафика в открытом виде. Поэтому наилучшим вариантом является необходимость проверки подлинности для входящих подключений и запрос проверки подлинности для исходящих подключений.
Затем выберите метод проверки подлинности. Метод по умолчанию называется «По умолчанию» - определенно не очень полезное название. Метод проверки подлинности по умолчанию можно настроить для всех компьютеров по отдельности в свойствах IPsec (для доступа к ним необходимо щелкнуть узел «Брандмауэр Windows в режиме повышенной безопасности» правой кнопкой мыши и выбрать свойства). Методом проверки подлинности по умолчанию всегда является Kerberos, поскольку это наиболее простой и безопасный метод. Однако в целях ясности я рекомендую выбирать его при создании собственных правил. Обычно необходима проверка подлинности компьютера, а не пользователя. При необходимости проверки подлинности как компьютера, так и пользователя может быть невозможным получение некоторых видов трафика управления, например, анонимно передаваемого трафика SNMP.
После выбора метода проверки подлинности все, что необходимо сделать, это просто выбрать профили, в которых будет доступно это правило. Поскольку это правило применяется к присоединенным к домену компьютерам, которые могут предоставлять билет Kerberos, нет смысла открывать эту брешь в частных или общих профилях. Сохраните правило, и все готово.
Основные правила изоляции больше не являются сложными. Однако, чтобы использовать для изоляции возможности IPsec, необходимо реализовать изоляцию серверов даже на рабочих станциях. Это позволяет ограничить рабочие станции от прослушивания других клиентов. Вместо этого они будут отвечать только соответствующим станциям управления. Представьте, насколько меньше воздействие различных вредоносных проникновений на клиентские системы, не прослушивающие другие клиенты.

Создание сценариев для брандмауэра
В состав нового брандмауэра входит важный интерфейс API, позволяющий создавать сценарии для развертывания и оценки. В идеале для развертывания необходимо использовать групповую политику, но поскольку она не всегда доступна, важно именно верный набор интерфейсов API для настройки брандмауэра. Интерфейсы API сгруппированы в набор INetFWPolicy2. В пакете SDK и библиотеке MSDN® содержатся более подробные сведения об их использовании, но главную идею можно проиллюстрировать с помощью всего нескольких примеров.
Один общий пример необходим для определения включения группы правил. Например, приложению или администратору необходимо определить, разрешен ли для системы общий доступ к файлам и принтерам. Это можно сделать с помощью INetFWPolicy2::IsRuleGroupCurrentlyEnabled. На рис. 4 приведен пример сценария VBScript, демонстрирующего эту функцию.
Figure 4 Использование INetFWPolicy2::IsRuleGroupCurrentlyEnabled
' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if
Теперь, если общий доступ к файлам и принтерам выключен, и его необходимо разрешить, сначала необходимо убедиться, что это может быть выполнено и не будет переопределяться групповой политикой. Это выполняется с помощью интерфейса API INetFWPolicy2::LocalPolicyModifyState. Основа, которую можно заполнить фактическим кодом, показана ниже:
Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Командная строка и типы интерфейсов
Ни один брандмауэр не был бы полным без верной командной строки для управления. В командах netsh существует подконтекст advfirewall. Контекст advfirewall предоставляет доступ командной строки ко всем возможностям графического пользовательского интерфейса. Например, при необходимости реализации блокировки исходящего трафика для порта 445 можно выполнить следующую команду в командной строке с повышенными правами:
netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any
Затем необходимо выполнить эту же команду, заменив TCP на UDP для выполнения блокировки. На этом реализация правила завершена.
Замечательной функцией брандмауэра является возможность настройки правил на основе типа сетевого интерфейса. Напомним, что некоторые правила могут влиять на подключения VPN. До тех пор, пока Windows распознает интерфейс как интерфейс VPN, можно использовать этот тип правила для исключения трафика через этот интерфейс:
netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS
Это также можно выполнить с помощью графического интерфейса пользователя, но только после создания правила. После этого необходимо щелкнуть правило правой кнопкой мыши, выбрать «Свойства», затем выбрать вкладку «Дополнительно». В разделе «Типы интерфейса» можно выбрать верные типы интерфейса.

Фильтрация исходящего трафика
Отсутствие фильтрации исходящего трафика в брандмауэре Windows XP с пакетом обновления 2 (SP2) было главным обоснованием того, что брандмауэр был недостаточным с точки зрения безопасности. О том, насколько небезопасным является брандмауэр Windows XP с пакетом обновления (SP2) из-за отсутствия фильтрации исходящей связи, написаны тысячи статей. И все это несмотря на то, что ни один брандмауэр для Windows XP не мог предоставить безопасную фильтрацию исходящей связи.
Фундаментальная функциональность, преобразующая фильтрацию исходящей связи в полезную функцию безопасности из средства ограничения скорости — или средства применения политики, как использовалось ранее — просто отсутствует в Windows XP. Однако ее не существует и в Windows Vista. Поэтому вполне логично, что в новом брандмауэре используется эта функция. По умолчанию большая часть входящего трафика блокируется, а большая часть исходящего – разрешается.
По умолчанию фильтрация исходящего трафика в новом брандмауэре Windows Vista блокирует только ненужный трафик от служб. По существу, это все, что может быть сделано для обеспечения защиты от компрометации на узле, предоставляющем фильтры исходящего трафика, и осуществление этого в Windows XP было бессмысленным.
Службы в Windows Vista могут работать с маркером с высоким уровнем ограничений. По существу, каждая служба имеет собственный уникальный идентификатор безопасности (SID). Этот идентификатор безопасности службы может использоваться для ограничения доступа к ресурсам, таким как сетевые порты. Это та же функциональность, которую мы видели ранее при рассмотрении ограничения трафика пользователям. Это означает, что даже хотя две службы могут работать от имени учетной записи NetworkService, они не могут управлять процессами друг друга, а брандмауэр может быть настроен на разрешение исходящей связи только одной из них. При компрометации одной из заблокированных служб она не может подменить разрешенную службу и использовать ее разрешенный порт для связи, поскольку он ограничен идентификатором безопасности службы.
Эта функциональность – еще одна полезная функция, добавленная в Windows Vista и используемая новым брандмауэром для обеспечения действительной безопасности с помощью фильтрации исходящего трафика.
Фактически, в новом брандмауэре фильтрация по идентификаторам безопасности служб включена по умолчанию. Однако отсутствует графический интерфейс пользователя для ее настройки. Правила предопределены в разделе реестра HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Однако при изменении этого раздела вручную следует быть очень осторожным, поскольку это не поддерживается.

Насколько фильтрация исходящего трафика повышает уровень безопасности?
Сообщество обеспечения безопасности сильно недооценивает значение для безопасности, предоставляемое фильтрацией исходящего трафика. До сих пор я упомянул только два случая обеспечения безопасности посредством фильтрации исходящего трафика, оба из которых основываются на новой функции Windows Vista, которая ранее не была доступна. Несмотря на это, существует общее мнение о том, что фильтрация исходящего трафика полезна в принципе и должна быть ключевым фактором при принятии решений о приобретении брандмауэра.
По иронии множество организации принимают подобные решения о приобретении на основе возможностей фильтрации исходящей связи, а после реализации брандмауэра эти возможности не используются. Это неверно и ведет к трате денег и усилий группы безопасности информации. По-видимому, причина такого решения – стремление выполнить что-то, относящееся к безопасности, а не анализ действительной угрозы. Нередко важные решения основаны не на фактах, а вызваны стремлением к этому типу «театра безопасности».
С фильтрацией исходящего трафика связан один простой факт, не учитываемый сторонниками этого типа фильтрации. Обычный аргумент поставщиков индивидуальных брандмауэров – при нарушении работы системы червем или текущим злоумышленным пользователем фильтрация исходящего трафика предотвратит заражение других систем и передачу данных злоумышленником. Это не так.
В действительности при прочих равных условиях фильтрация исходящего трафика препятствует работе некоторых старых вредоносных программ. Однако если в Windows XP была включена фильтрация исходящего трафика, известные на данный момент черви чаще всего отключали или иным образом обходили ее.
В Windows XP (или более ранних версиях Windows) все черви, запускающиеся в качестве службы (в качестве службы запускались все распространенные черви), могли выполнять подобное. Единственная причина того, что они этого не делали, – практически отсутствовали среды, использующие фильтрацию исходящего трафика, поэтому ее отключение не требовалось. При интерактивной атаке злоумышленник при желании может обойти фильтры исходящего трафика. Если злоумышленник может выполнить произвольный код, это осуществляется очень просто. Но при необходимости злоумышленник может обманным образом вынудить пользователя обойти фильтры.
Обход фильтров индивидуальных брандмауэров исходящего трафика также может быть осуществлен несколькими способами в зависимости от варианта фактической атаки. Проще всего «попросить» пользователя с большими правами сделать это для вас. В слишком многих средах пользователи по-прежнему работают в качестве администраторов. Эти пользователи при желании могут обходить политики безопасности. Все, что требуется злоумышленнику, это предоставить пользователю выбор между неясным и не сразу реализующимся преимуществом с точки зрения безопасности и тем, что нравится пользователю гораздо больше — вошедшими в пословицу танцующими голыми свинками.
Довольно часто пользователю открывается так много диалоговых окон подобного типа, что он быстро щелкает мышью, полностью не осознавая произошедшее. Это главная проблема фильтрации исходящего трафика. При выборе между безопасностью и довольно заманчивыми обещаниями, такими как танцующие голые свинки, всегда выбираются танцующие свинки, поскольку в большинстве диалоговых окон с запросом пользователей на принятие решений относительно безопасности отсутствует какая-либо информация, позволяющая принять такие решения.
Представление диалоговых окон с запросом на принятие решений относительно безопасности с достаточными сведениями, необходимыми для принятия таких решений, гораздо сложнее, чем кажется, поскольку для этого необходимо, чтобы продукт обеспечения безопасности, например, брандмауэр, не только понял порты, протоколы и приложение, осуществляющее запрос, но также и действительную цель запроса и ее значение для пользователя. Эти сведения очень трудно получить программно. Например, тот факт, что Microsoft Word пытается установить исходящее подключение, не так интересен, как точная цель такого подключения.
Необходимо уменьшить, а не увеличить количество бессмысленных диалоговых окон, и брандмауэры фильтрации исходящего трафика не помогают в выполнении этой задачи. Чтобы понять современный уровень предоставления пользователям ценной информации, я изучил документацию по продажам крупного поставщика индивидуальных брандмауэров. Глянцевые журналы расхваливают возможности фильтрации исходящего трафика брандмауэра и доступность рекомендаций. Выполняется определение того, что пытается сделать пользователь, и предоставляются соответствующие рекомендации. Теория выглядит приблизительно так. Текст брошюры сопровождался снимком экрана со следующим текстом: «Advice is not yet available for this program. Choose below or click More Info for assistance.» (Для данной программы пока недоступны рекомендации. Выберите вариант из приведенных ниже или нажмите кнопку «More Info» (Подробнее) для получения справки.) По-видимому, поставщики не могут создать информативные диалоговые окна даже в маркетинговых материалах.
Поскольку у пользователей нет достаточной информации для принятия верных решений относительно безопасности, ответственность за настройку всей исходящей фильтрации несет администратор, так как конечный пользователь не может выполнить это. Это до бесконечности увеличивает задачи по администрированию.
Даже при выборе пользователем варианта «No. Bug me again later» (Нет. Напомнить позже) при появлении запроса брандмауэра обычно вредоносная программа может обойти брандмауэр. До тех пор, пока пользователь, чей вредоносный код выполняется, может открывать исходящие подключения для этого же порта, вредоносный код может просто использовать этот порт. Таким образом, любой процесс может использовать существующий процесс для проникновения. Это разрешается в операционных системах нижнего уровня. Начиная с Windows Vista, процессы могут быть удобным образом ограничены; потому ограниченные по умолчанию службы блокируются фильтрами исходящего трафика по умолчанию.
К сожалению, большинство людей считает, что фильтрация индивидуальных брандмауэров для исходящего трафика предотвращает атаку скомпрометированным активом других активов. Это невозможно. Применять меры защиты для скомпрометированного актива и просить его не компрометировать другие активы просто невозможно. Защита относится к ресурсу, который вы пытаетесь защитить, а не к тому, от которого вы защищаетесь! Обращение к злоумышленникам с просьбой ничего не воровать после того, как они уже проникли в ваш дом, вряд ли будет такой же эффективной, как изначальная защита от их проникновения в дом.

Йеспер М. Йоханссон (Jesper M. Johansson) является архитектором программного обеспечения, который работает над программами безопасности, и пишущим редактором журнала TechNet Magazine. Он имеет докторскую степень по информационным системам управления, обладает более чем 20-летним опытом в области безопасности и статусом наиболее ценного специалиста (MVP) Майкрософт по безопасности предприятий. Его последняя книга – Windows Server 2008 Security Resource Kit.


Безопасность
Защита электронной почты с помощью цифровых сертификатов
Мэтт Клэпэм (Matt Clapham) and Блейк Хатчинсон (Blake Hutchinson)
Краткий обзор:
  • Создание проверяемого удостоверения
  • Обновление состояния сертификата
  • Получение сертификатов и обмен ими
  • Устранение неполадок в системе S/MIME

В течение тысячелетий люди использовали различные методы для сокрытия передаваемой информации, а также проверки отправителя и сообщения. По мере развития цивилизации был создан и получает теперь широкое распространение единый метод для выполнения всех этих трех задач. Протокол
S/MIME – это система безопасной отправки электронной почты с использованием шифрования и цифровых подписей.
Текущие технологии шифрования (закрытия) делятся на два основных типа: алгоритмы с симметричными (секретными) ключами, такие как стандарт DES или AES, и алгоритмы с асимметричными (открытыми/закрытыми) ключами, такие как RSA или ECC. Современные средства проверки отправителя – это математические односторонние функции, именуемые хэш-кодами, которые создают уникальные подписи. Два часто используемых метода хэширования - это алгоритмы MD5 и SHA. Компьютеры могут использовать их для создания уникального хэш-кода или номера, соответствующего индивидуальному исходному тексту (идентичные исходные тексты имеют одно значение хэш-кода). Эти простые средства используются и сочетаются для создания инфраструктуры открытого ключа (PKI).

Проверяемое удостоверение
Материалы по центрам сертификации
  • Использование центра сертификации для службы шифрования файлов
  • Серверы центра сертификации нельзя переименовывать или удалять из сети
  • Как удалить доверенный центр сертификации с компьютеров домена
  • Как списать центр сертификации Windows Enterprise и как удалить все связанные с ним объекты из Windows Server 2003 и Windows 2000 Server
  • Как переместить центр сертификации на новый сервер, работающий на контроллере домена

Удостоверения внутри системы PKI управляются с использованием цифровых сертификатов, которые не сильно отличаются от выданных государством удостоверений личности, которые большинство людей переносят через международные границы, – паспортов. Стандарт паспортов в мире цифровых сертификатов – это формат X.509, который широко используется для подписывания и шифрования в таких технологиях как S/MIME, IPsec, SSH, а также в безопасности беспроводных сетей, виртуальных частных сетях (VPN) и даже в безопасных сообщениях сервера (таких как веб-узлы SSL).
Сертификаты строятся на основе асимметричной криптографии и хэш-кодов. Для создания сертификата запрашивающий (тот, кому нужен ключ, подписанный более высоким центром сертификации), создает секретный ключ. Ключ держится запертым, чтобы его подлинность не подвергалась сомнению. Вместе с секретным ключом создается соответствующий открытый ключ. Как и предполагает его имя, открытая часть пары не секретна и свободно распространяется, хотя все же таким способом, который гарантирует ее подлинность.
Эта пара ключей делает возможной две основные операции. Во-первых, кто угодно может использовать открытый ключ для шифрования чего-либо, что может расшифровать только секретный ключ; во-вторых, открытый ключ можно использовать для расшифровки зашифрованного секретным ключом. Это имеет значение при проверке подписи, которую мог создать только секретный ключ.
Запрос к центру сертификации включает такие подробности, как то, какому лицу или компьютеру предназначается ключ, тип и надежность алгоритма, а также открытую часть пары ключей. Центр сертификации (CA) получает и проверяет информацию в запросе, после чего, используя алгоритм хэширования, создает уникальный идентификатор, соответствующий информации.
Используя свой закрытый ключ, центр сертификации шифрует хэш-код информации и собирает его в стандартный формат (такой как X.509), создавая сертификат, соответствующий первоначальному запросу. Сертификат X.509 будет содержать список заявок, включая удостоверение сертификата (субъект), период действительности, открытый ключ и операции, для которых может быть использован сертификат. После этого сертификат возвращается запрашивающему; это маркер, который по сути заявляет: «Я, центр сертификации (CA), ручаюсь за этот открытый ключ и секретную часть, соответствующую ему, для всех описанных здесь способов использования».
У корневых центров сертификации (находящихся на наивысшем уровне цепи доверия) сертификаты самоподписанные. Большинство приемлемых корневых центров сертификации поставляются встроенными в базовую операционную систему или приложение, но могут быть обновлены или изменены через пакеты либо корпоративную настройку. Между корневым центром сертификации и оконечным узлом дерева (который обычно описывает отдельную личность или систему) могут находиться один или несколько корневых центров сертификации.
Цепь состоит из всех узлов и всех предшествующих сертификатов, внедренных в них, подписанных центром сертификации на этом уровне. Стороннее лицо, пытающееся проверить сертификат, может сверить локально вычисляемый хэш-код с дешифрованным из самого сертификата, используя сопровождающий общий ключ для данного конкретного центра сертификации или личности. Таким образом и создается полностью проверенная цепь от корня к оконечному узлу дерева – предполагая, само собой, что корень пользуется доверием.

Обновление состояния сертификата
У каждого хорошего центра сертификации имеются способы распространения списка сертификатов, которым больше не следует доверять. Этот список отзыва сертификатов (CRL) описывает, какие выпущенные элементы центр сертификации прямо сделал недействительными. Что удобно, местоположение списка отзыва сертификатов обычно является свойством сертификата центра сертификации.
Центры сертификации регулярно выпускают списки отзыва сертификатов на двух основаниях: по расписанию (скажем, каждые две недели) или в случае событий (происшествий, указывающих, что выпущенный сертификат более не заслуживает доверия). Центр сертификации подписывает выпущенные списки отзыва сертификатов при их публикации. Когда получающая система оценивает действительность цепи, она обычно пытается получить список отзыва сертификатов для каждого выпускающего центра сертификации в цепи (через подробности, внедренные в сами сертификаты, или через некий заранее определенный доверенный механизм распределения). Если какой-то из список отзыва сертификатов недоступен, клиент может прибегнуть к недавней, успешно кэшированной копии, пока она не старше указанного периода обновления списка отзыва сертификатов. Но если и это уже невозможно, клиентские системы обычно демонстрируют какую-либо ошибку, указывая, что сертификат является допустимым, но состояние отмены невозможно определить.
Многие приложения тратят гораздо больше времени на загрузку сертификата, если они не могут проверить цепь или список отзыва сертификатов для каждого узла в цепи. В зависимости от того, что защищал сертификат, пользователь может пожелать или не пожелать доверять ему. Регулярно обновляемая, широко доступная точка распространения списков отзыва сертификатов совершенно необходима для каждого центра сертификации, а особенно для общедоступных корней.
Корни являются основанием цепи сертификатов, а на соединении в цепи основаны все иерархии сертификатов. Большинство клиентских систем и приложений предполагают, что сертификат оконечного узла дерева допустим, только если от него ведет цепь к доверенному корню. Это может быть корпоративный центра сертификации, находящийся во владении и под управлением данной конкретной компании, либо общедоступный корневой центр сертификации (такой как VeriSign).
Считается, что общедоступные корневые центры сертификации эксплуатируются строго надлежащим образом, позволяющим гарантировать целостность. Компании должны стремиться к такому же уровню в своих внутренних организациях, поскольку неприкосновенность корневых центров сертификации настолько же важна в этом контексте. Для оптимальной защиты корневые центры сертификации следует держать отключенными от сети, используя только для выдачи сертификатов и обновления списков отзывов о сертификатов. Дополнительную информацию по лучшим методам эксплуатации центра сертификации можно найти в статьях, перечисленных на врезке «Материалы по центрам сертификации».
Одним из важных аспектов, о которых следует подумать, является восстановление ключа. Чтобы поспособствовать расследованиям и гарантировать, что данные не будут невозвратимо заперты пользователем, компании следует создавать резервные копии всех выпущенных пользователями ключей. Вдобавок, эти резервные копии следует хранить в безопасном хранилище. Это позволяет при утрате ключа пользователя (скажем, если смарт-карта забыта в такси) сохранить доступ к любому содержимому, защищенному ключом.
Наконец, в каждую хорошую криптографическую систему входит концепция управления жизненным циклом. Чем компьютеры быстрее, тем менее стойки алгоритмы. Любой хорошей криптосистеме необходима способность обновлять себя и переходить на новые алгоритмы и размеры ключей с течением времени. Центры сертификации следует обновлять соответствующим образом, когда определяются криптографические нестойкости и определенные функции вводятся в эксплуатацию или выводятся из нее.

Реализация S/MIME
Начальная загрузка, составление, отправка и получение подписанных или зашифрованных сообщений электронной почты с использованием S/MIME состоит из нескольких стадий. Мы осветим подробности, проблемы и потенциальные решения по мере разбора типичного случая использования S/MIME: двух пользователей, отправляющих подписанные и/или зашифрованные сообщения друг другу из двух различных лесов Active Directory® и различных цепей центров сертификации (то есть из операционно различных объектов независимо от того, находятся они внутри одной компании или нет), используя Microsoft® Office Outlook® 2007.
Мы предположим, что уже существует необходимая инфраструктура, допускающая операции, которые мы опишем. В нашем случае мы используем интегрированный с Active Directory корпоративный сервер сертификации.

Получение сертификатов
Первая задача – это получить соответствующие сертификаты. Чтобы сделать это, откройте консоль управления MMC диспетчера сертификатов (certmgr.msc), щелкните правой кнопкой мыши папку Personal («Личные»), выберите All Tasks («Все задачи») во всплывающем списке и выберите Request New («Запросить новый») из списка.
В результате запустится мастер установки сертификатов, как показано на рис. 1. По умолчанию будут показаны несколько предназначенных для компаний вариантов, важен из них User certificate («Сертификат пользователя»). Позже он будет использован, чтобы сделать возможными процессы подписывания и шифрования. Сертификат должен быть пригоден для следующего.
Рис. 1 Запрос сертификата
Рис. 1 Запрос сертификата (Щелкните изображение, чтобы увеличить его)
  • Цифровых подписей (создания сообщений с печатью подлинности от их создателя)
  • Криптографической защиты ключа (защиты одного ключа другим для таких технологий, как шифрующая файловая система)
  • Безопасного обмена электронной почтой (зашифрованных сообщений, которые могут быть прочтены только их предполагаемым получателем, владеющим соответствующим секретным ключом)
Для отправки подписанной S/MIME электронной почты свойства криптографической защиты ключа не требуется. Но для отправки или получения зашифрованной почты это свойство необходимо, тогда как свойство подписи – нет. По умолчанию, шаблоны в службе сертификатов Windows® включают эти три свойства. Если пользователю не разрешено запрашивать новые сертификаты, они не будут показываться при запуске мастера. Если корпоративный центр сертификации недоступен, пользователю будет представлена «ошибка установки», указывающая, что с доменом или с центром сертификации невозможно связаться. Для целей этого руководства мы предположим, что один сертификат допускает и подпись, и криптографическую защиту.

Обмен сертификатами
Простейшим способом начать обмен зашифрованными сообщениями электронной почты между двумя пользователями является отправка друг другу подписанных сообщений. После составления сообщения пользователь нажимает кнопку «Подписать». (Порой кнопка скрыта по умолчанию в Outlook, пока ее не использовали хоть раз. Ее можно найти, выбрав «Параметры для новых сообщений», затем нажав кнопку «Параметры безопасности» и установив флажок «Добавить цифровую подпись к этому сообщению» в диалоговом окне свойств безопасности.) Кнопка подписывания (маленький желтый конверт с красной лентой на нем с надписью «Подписать») добавляет цифровую подпись к сообщению, чтобы установить подлинность его источника.
При нажатии кнопки «Отправить» от пользователя могут быть запрошено предоставление дополнительных маркеров владения ключом, такое как вставление смарт-карты или ввод ПИН-кода. Это зависит от конкретных методов защиты ключа, используемых организацией.
Пользователю, получающему подписанное с помощью S/MIME сообщение электронной почты, потребуется просмотреть и щелкнуть правой кнопкой мыши имя отправителя (после «От:») и выбрать «Добавить к контактам Outlook» из контекстного меню, которое либо добавляет новую запись контакта, либо обновляет существующую. После этого сертификат связывается с данной конкретной записью контакта. Обратите внимание, что в обычной среде Active Directory (два пользователя в одном лесу или компании) распространение открытых сертификатов пользователя выполняется автоматически через атрибуты в объекте пользователя в Active Directory.
Другой способ обмена сертификатами – отправить друг другу свой(-и) сертификат(-ы) S/MIME в качестве вложений. Чтобы сделать это, сертификаты нужно экспортировать в файлы CER. Пользователям потребуется просмотреть сертификат и выполнить процедуру экспорта, о которой мы скоро расскажем, постаравшись при этом не экспортировать заодно секретный ключ, как показано на рис. 2.
Рис. 2 При обмене сертификатами не экспортируйте секретный ключ
Рис. 2 При обмене сертификатами не экспортируйте секретный ключ (Щелкните изображение, чтобы увеличить его)
Каждый получатель затем вручную создает запись контакта в Outlook и добавляет сертификат к записи отправителя. После того, как двое пользователей обменялись сертификатами, у них будет возможность обменяться друг с другом зашифрованными сообщениями электронной почты.

Устранение неполадок
Порой у получателя возникают сложности в открытии зашифрованного сообщения. Наиболее вероятными источниками проблем здесь являются недоверенные корневые центры сертификации, промежуточные центры сертификации, которые невозможно проверить, и недоступные списки отзыва сертификатов.
Недоверенный корневой центр сертификации обычно появляется в Outlook как сообщение об ошибке, связанное с подписью: «Имеются затруднения, относящиеся к подписи. Для получения дополнительных сведений нажмите кнопку подписи». Для решения проблемы откройте сертификат изнутри Outlook и нажмите кнопку «О центре сертификации...» из всплывающего диалога. Взгляните на сообщение на вкладке «Общие» или в диалоге свойств сертификата. Если оно указывает, что корневой сертификат центра сертификации не пользуется доверием, и его нужно установить, перейдите на вкладку сведений. Нажмите кнопку «Копировать в файл...» и выполните указания мастера, принимая все параметры по умолчанию и предоставляя имя и папку файла по запросу.
Затем откройте новую консоль управления Майкрософт (MMC) как администратор компьютера. Перейдите к оснастке Файл|Добавить/Удалить (Ctrl+M), выберите «Сертификаты» и добавьте ее к учетной записи компьютера, выбрав «Локальный компьютер», когда последует запрос. Далее разверните узел сертификатов в левом дереве, затем сделайте то же самое с узлом «Доверенные корневые центры сертификации». Щелкните правой кнопкой мыши панель и выберите Все задачи|Импорт из всплывающего меню. Импортируйте ранее упоминавшийся экспортированный файл сертификата в «Доверенные корневые центры сертификации» и нажмите кнопку «Готово». Затем попросите пользователя, для которого это выполнялось, перезапустить Outlook.
Эти указания следует использовать только для добавления корневого центра сертификации, который точно заслуживает доверия. Не все корни созданы равными. Хорошо подумайте о том, кто владеет корневым центром сертификации и управляет им, перед использованием этого метода, чтобы добавить корень к хранилищу для всей системы. Если компания контролирует список доверенных корней через групповую политику, настройка будет спущена клиентским системам. В этом случае указания могут не сработать. Если они не срабатывают, может возникнуть необходимость исследовать альтернативные варианты, такие как защищенные веб-узлы или серверы для обмена данными, поскольку электронная почта не предоставит безупречное и защищенное обслуживание.
Вторая проблема отмеченная выше, невозможность проверить промежуточные центры сертификации, обычно возникает в двух случаях: когда клиент, пытающийся проверить сертификат, не может получить доступ к местоположению информации о центре сертификации (AIA), определенному в сертификате, или у клиента имеется версия сертификата промежуточного центра сертификации, которая не совпадает с тем, что выпускает центр сертификации (клиент часто отстает на версию или две). Эти условия представляются очень похожими в интерфейсе пользователя Outlook. Мы видели это только в очень специальных обстоятельствах, когда срок действия сертификата промежуточного центра сертификации в цепи истекал, и сертификат выдавался заново, прежде чем истекал срок действия выпущенных центром сертификации подчиненных сертификатов.
По сути, эта проблема возникает, когда в цепи есть пробелы. Некоторые родительские сертификаты могут быть не слишком детализированными или не внедренными в оконечный узел дерева должным образом, что еще более усложняет ситуацию.
Чтобы решить эту проблему, отправителю нужно открыть новое сообщение и щелкнуть параметры нового сообщения, затем нажать кнопку параметров безопасности и кнопку изменения параметров. Далее нажмите кнопку «Выбрать» для сертификата подписи, затем кнопку просмотра сертификата во всплывающем диалоговом окне. Перейдите на вкладку пути сертификата, выберите поставщика оконечного узла дерева (то есть, на один уровень вверх в цепи) и нажмите кнопку просмотра сертификата. Выберите вкладку подробностей, затем нажмите кнопку «Копировать в файл...» и завершите работу мастера экспорта, выбрав PKCS #7 (.P7B). Убедитесь, что установлен флажок «Включить в путь все сертификаты», как показано на рис. 3. Наконец, отправьте экспортированный файл цепи желаемому получателю.
Рис. 3 Заполнение пробелов в цепи сертификатов
Рис. 3 Заполнение пробелов в цепи сертификатов (Щелкните изображение, чтобы увеличить его)
После получения экспортированной цепи сертификатов получателю понадобится открыть и импортировать цепь примерно так же, как мы ранее импортировали корень. Единственная разница состоит в том, что выбранной папкой хранения должны быть «Промежуточные центры сертификации». Если сообщение открывается, и сертификат показан как допустимый в Outlook, то все работает верно.
Что касается третьей проблемы, недоступности списка отзыва сертификатов, то исправление относительно просто. Первоначальный ответ от Outlook будет выглядеть весьма похожим на предыдущую проблему. Однако ошибка будет показана, даже если корневые или промежуточные подписывающие центры сертификации пользуются доверием. Для каждого уровня цепи сертификатов выше конечного откройте свойства сертификата, затем вкладку сведений и взгляните на поле, именуемое «Точки распространения списков отзыва (CRL)».
Для каждой перечисленной точки распространения списков отзыва сертификатов (особенно для доступных из Интернета) проверьте возможность открыть URL-адрес файла списка отзыва сертификатов. После проверки каждого уровня перемещайтесь на один уровень в цепи вверх. Если какой-либо из списков отзыва сертификатов не может быть получен, он, вероятно, является источником проблемы. Для разрешения проблемы следует убедиться, что локальная политика сети не блокирует доступ. В ином случае, попробуйте связаться с компанией, владеющей центром сертификации, или ждите, пока принадлежащая центру сертификации точка распространения списков отзыва сертификатов не вернется в рабочее состояние.

Распространение сертификатов
Распространение – это простая часть. По сути, подписанное сообщение передается серверу электронной почты, который затем отсылает его из одного места в другое проверенным способом – через SMTP. Единственная виденная нами проблема при передаче подписанной или зашифрованной почты состоит в том, что некоторые почтовые системы отвергают или разбивают подписанные или зашифрованные сообщения, проходящие через них. Способ исправления заключается в работе с руководителем ИТ-системы для получения допустимых типов сообщений. Само собой, возможно, придется смириться с фактом, что некоторые типы сообщений блокируются. У получателя могут быть веские причины не допускать зашифрованные сообщения в определенной рабочей среде.

Шифрование ответов.
Для создания зашифрованного ответа (предполагая, что вышеупомянутый процесс начальной загрузки уже завершен) отправителю необходимо лишь создать сообщение и затем нажать кнопку «Зашифровать» (маленький желтый конверт с синим замком на нем с надписью «Зашифровать») в окне составления сообщений. Если эта кнопка недоступна, выполните все действия по отправке подписанного сообщения, кроме последнего, вместо которого установите флажок «Шифровать содержимое сообщения и вложения».
Подпись S/MIME не требуется для отправки получателю зашифрованного сообщения, но то и другое отлично работают вместе, поскольку подпись позволяет читателю проверить сервер (функция шифрования не удостоверяет отправителя). Процесс шифрования попытается зашифровать сообщение с помощью известных открытых ключей всех получателей. Если система не может найти сертификаты для некоторых предполагаемых получателей, они будут помечены во всплывающем диалоге, предлагающем отправить сообщение незашифрованным, как показывает рис. 4.
Рис. 4 Можно решить отправить незашифрованное сообщение при наличии проблемы с сертификатом
Рис. 4 Можно решить отправить незашифрованное сообщение при наличии проблемы с сертификатом (Щелкните изображение, чтобы увеличить его)
По умолчанию подписывание и шифрование должны работать с другими сравнимо настроенными клиентскими системами, но порой обмен подписанными или зашифрованными сообщениями между несколькими версиями может привести к проблемам, если алгоритм хэширования или шифрования не поддерживается на предыдущем уровне. Мы столкнулись с такой проблемой при отправке подписанных сообщений электронной почты (используя SHA-512 как алгоритм хэширования) пользователю, использующему Windows XP с пакетом обновления 2. Поскольку получающая система не поддерживала хэширование, пользователю не удавалось проверить подпись или прочитать сообщение. Однако если параметры Outlook по умолчанию не изменялись, пользователи вряд ли встретят много проблем на этом этапе.
По получении сообщения предполагаемый получатель должен быть способен открыть его, если доступен открытый ключ, связанный с общедоступным сертификатом. Кроме того, от пользователя может потребоваться предоставление дополнительного маркера, подтверждающего владение секретным ключом, в зависимости от того, как он был развернут. Другие пользователи, выполнившие подобную процедуру инициализации, могут принять участие в подобной подписанной и зашифрованной переписке с получателем. Если пользователь изменил свой секретный ключ (скажем, из-за потери компьютера), ему нужно повторно запросить сертификаты и заново распространить подписанное сообщение или файл сертификата между теми, с кем он желает обмениваться зашифрованными сообщениями.

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

Мэтт Клэпэм (Matt Clapham) обладает сертификатом CISSP и является специалистом по безопасности в отделе ИТ корпорации Майкрософт. Он выполняет обзоры безопасности бизнес-приложений днем и понемногу занимается технологиями, играми, компьютерной музыкой и безопасностью по ночам. Порой он общается с сообществом по информационной безопасности Puget Sound. Связаться с ним можно по адресу matt.clapham@microsoft.com.
Блейк Хатчинсон (Blake Hutchinson) работает экспертом по поддержке в группе сетевых бизнес-служб (Business Online Services Group – BOSG) компании Майкрософт. В его роль входит поддержка в ходе работы и рецензирование бизнес-средств, разработанных самими клиентами, для корпоративных клиентов BOSG. Блэйк увлекается фотографией, катанием на лыжах и компьютерными играми. Связаться с ним можно по адресу blakeh@microsoft.com.


Письмо редактора Великий спор
Джошуа Хоффман (Joshua Hoffman)

Я люблю великие споры. Я говорю не о заурядных раздорах, в которых различные мнения и сильные личности приводят к бессмысленным конфликтам. Какая напрасная трата времени. Но по-настоящему великий спор, в котором сходятся интеллектуалы с противоположными точками зрения, предоставляя на рассмотрение свои аргументы — вот великолепное зрелище. Представьте Просвещение. Или Сократа.
В этом месяце мы представляем вам один из по-настоящему великих споров в ИТ-индустрии — безопасность через маскировку. Я бы объяснил концепцию, но меня терзает смутное подозрение, что после прочтения этих трех слов большинство из вас уже выразили свое мнение по этой теме, и, скорее всего, вслух. Также хочу поспорить, что большинство из вас ясно разделяется на два лагеря: «безопасность через маскировку абсолютно бесполезна» и «в плане безопасности полезно все возможное».
Ну что ж, в этом месяце мы сводим вместе двух известных экспертов по безопасности Джеспера Йоханссона и Роджера Граймса, представляющих обе стороны спора. Для каждой из сторон мы также включили специальные вспомогательные комментарии двух других знаменитостей, Аарона Маргосиса и Стива Райли. Хотя я определенно горд каждой опубликованной страницей, должен признать, что эта одна из моих самых любимых статей за долгое время. Надеюсь, что, независимо от того, какую сторону этого великого спора вы примете, вы прочитаете статью без предубеждений. Уверен, что вам она понравится.
В этот ежегодный выпуск по вопросам безопасности, конечно же, включено и многое другое. Мы возвращаемся к некоторым темам прошлогоднего выпуска. Одной из самых интересных обсуждавшихся в прошлом году тем, был набор средств PowerToy для запуска сценариев пишущего редактора Майкла Мерголо, который рассматривал выполнение сценариев VBScript и Windows PowerShell с повышенными правами совместно с функцией управления учетными записями пользователей Windows Vista. Майкл получил множество положительных отзывов об этом материале, и в этом году он возвращается с совершенно новым набором служебных программ для расширения исходного кода. Советую опробовать эти мощные средства.
Байрон Хайнз также был с нами год назад, представив введение в шифрование диска BitLocker в Windows Vista. Байрон повторно играет свою роль, рассматривая изменения BitLocker после выпуска пакета обновления 1 (SP1) для Windows Vista и Windows Server 2008. Кроме того, включены статьи о политиках ограниченного использования программ, управлении брандмауэром Windows Vista, устранении неисправностей S/MIME, второй выпуск новой рубрики «SharePoint изнутри», деловые идеи для популяризации надежных вычислений ... можно продолжать долго. Удачной работы! Джошуа Хоффман (Joshua Hoffman)

Мы бы хотели поблагодарить следующих технических специалистов корпорации Майкрософт: Троя Фанка (Troy Funk), Аарона Маргосиса (Aaron Margosis), Майкла Мерголо (Michael Murgolo), Стива Пешка (Steve Peschka), Стива Райли (Steve Riley), Марка Руссиновича (Mark Russinovich), Джона Шварца (Jon Schwartz) и Джима Трухера (Jim Truher).


Письма в редакцию Мнения читателей

Системы архивации данных Windows
Я с большим интересом прочел ваш обзор Windows Server® 2008 (TechNet Magazine, March 2008, technet.microsoft.com/magazine/cc268370), посетил его представление и добыл копию для своей домашней сети. Установка прошла успешно. Однако архивация данных озадачила меня.
Система архивации данных NT была удалена, а новая система Windows Server не поддерживает ленточные накопители – хотя их поддерживает ОС. (Я архивирую мои личные данные, включая Active Directory® и Exchange Server 2007, на ленточный накопитель.)
Я попытался загрузить Microsoft® Data Protection Manager (DPM), следуя советам из Интернета, хотя DPM и может быть избыточен для моей установки. Однако DPM не устанавливается на Windows Server 2008, а их указания по установке вручную мне не помогли. Что нужно делать в маленьких установках для архивации данных?
—Рави С. (Ravi S).

DPM действительно является решением для ленточных накопителей, поскольку новое решение в Windows Server 2008 оптимизировано для хранения на дисках. DPM начнет официально поддерживать Windows Server 2008 в течении ближайших месяцев.
—Карандип Ананд (Karandeep Anand), старший руководитель программы, корпорация Майкрософт

Потоки работ опросов
В статье за февраль 2008 «Создание эффективной инфраструктуры опросов» (technet.microsoft.com/magazine/cc194407) в разделе «Работа с отдельно взятыми WSS» есть следующее утверждение: «Имеется возможность выделить опросу поток работ».
Насколько я знаю, Windows® SharePoint® Services 3.0 (WSS) и Microsoft Office SharePoint Server 2007 (MOSS) не поддерживают потоки работ, связанные с ответами на опросы. Я пытался связать поток работ с ответом на опрос и, хотя конструктор SharePoint допускает связь, поток работ процесс всегда выдает ошибку «Сбой при запуске». В базе знаний (support.microsoft.com/kb/926370) имеется статья, прямо указывающая, что потоки работ, связанные с ответами опросов, не поддерживаются.
Я знаю, что можно связать с опросом получатель ответов и затем запустить какой-либо еще процесс, но на самом деле это отнюдь не поток работ в понимании SharePoint. Было ли это утверждение сделано по ошибке, или я чего-то здесь не понимаю?
—Мэтт Б (Matt B).

Указанный абзац говорит о том, как WSS предоставляет мастер для поэтапного процесса создания опросов. В нем также имеется рассказ о различных вариантах (ветвящейся логике, открытых/закрытых вопросах и так далее).
Одним из действительно предоставляемых мастером вариантов является выделение потока работ, так что утверждение «имеется возможность выделить опросу поток работ» верно буквально. Его можно выделить. Однако, как вы указали, потоки работ в опросах просто не работают, хотя по какой-то причине этот вариант включен. Позвольте мне объяснить, почему это так.
После привязки рабочего процесса к опросу и попытки запустить его будет получена ошибка «Сбой при запуске». Журналы для этого действия показывают следующее:
RunWorkflow: System.ArgumentException: Invalid field name.
{<<< GUID>>>} at ...
Данный идентификатор GUID представляет экземпляр рабочего процесса. Это кажется отличным способом гарантировать запуск верного потока работ – если не считать того, что тип списка «опрос» не поддерживает атрибут потока работ. Это просто не внесено в код. Так что когда поток работ пытается активироваться с помощью метода MakeActivation и делает что-то вроде этого:
internal static void MakeActivation(SPWorkflow workflow, SPWorkflowEvent e)
{e.EventData = new object[ ] { workflow.InstanceId, new SPWorkflowActivation
Properties(workflow, e.RunAsUserId, associationData, initiationData) };
...
}
, он вызывает SPWorkflowActivationProperties, которые выглядят следующим образом:
internal SPWorkflowActivationProperties(SPWorkflow workflow,
int runAsUserId, string associationData, string initiationData)
{
...
this.m_itemGuid = new Guid((string)
this.Item[SPBuiltInFieldId.GUID]);
...
}
Так что если он ожидает строку идентификатора GUID как атрибут в обзоре (которая, очевидно, предполагается встроенной),а обзор не имеет атрибута для GUID рабочего процесса, он не сможет работать.
Существует возможный обход проблемы, так что вы правы, думая в этом направлении. В него входит создание специального списка, запускающего поток работ и привязывающего получатель событий к опросу с помощью ItemEventReceiver. Получатель событий создает элемент в этом списке, который затем запускает поток работ. Но вы правы, это отнюдь не то же самое. Короче говоря – да, вы подметили верно, потоки работ здесь не работают.
— Пав Черни (Pav Cherny), ведущий рубрики «Внутри SharePoint» журнала TechNet Magazine


Инструментарий Новые продукты для специалистов по информационным технологиям
Грег Стин (Greg Steen)

Делайте объявления через сеть
NetSupport Notify
www.netsupportnotify.com
Основанные на ПК рабочие среды в современных офисах практически вездесущи. Большинство пользователей проводят день перед мониторами и подключены к сети, которой вы помогаете управлять. Помимо предоставления каналов транспорта для общих ресурсов, приложений и Интернета, сеть компании также можно использовать как часть стратегии организации по доведению важных сообщений до пользователей. Одно из средств, помогающих доставлять сообщения пользователям через локальные и глобальные сети, – это NetSupport Notify от компании NetSupport Limited.
Этот небольшой сервер приложений дает поддержку быстрой и надежной вещательной рассылки сообщений. С его помощью можно, например, легко предупредить пользователей о неожиданном отказе в обслуживании для общего ресурса, сообщить всем, что сигнал тревоги включился случайно, или предупредить сотрудников о создающейся аварийной ситуации.
Некоторые простые средства вещательной рассылки сообщений ограничены сетью, на которой установлены. В отличие от них, средство NetSupport Notify основано на агентах, а благодаря компоненту шлюза уведомлений может легко пересекать топологию сети, чтобы донести информацию до клиентов Windows® и Mac независимо от того, подключены ли они напрямую, по беспроводному подключению или через виртуальную частную сеть.
Служба уведомлений работает как служба Windows, и подключение к службе выполняется через административную консоль уведомлений, которую можно установить на том же или на другом компьютере. Уведомления от службы разделяются на три уровня серьезности: сообщение, предупреждение и критические предупреждения. После получения сообщения клиентом создается запись в журнале событий, и сервер получает уведомление о доставке сообщения. В число связанных с сообщениями возможностей входит также подача звукового сигнала в дополнение к отображению окна, постоянная видимость уведомлений и установка периода времени, по истечении которого сообщение автоматически закрывается.
Можно также выбрать отправку уведомление только определенным группам уведомлений. Консоль уведомлений можно подключить к нескольким серверам уведомлений, так что одна консоль может стать центром вещательной рассылки сообщения.
В состав средства NetSupport Notify входят не только сервер и консоль, но и средство развертывания, которое позволяет удаленно развернуть агент на компьютерах конечных пользователей, что избавляет от необходимости посещать их лично. Целевые компьютеры можно указать через диапазон IP-адресов или через обнаружение сетевых доменов и рабочих групп Windows.
Консоль развертывания также дает быстрый обзор сети, так как отображает версию установленного агента вместе с важной информацией, такой как доменное имя, MAC-адрес, IP-адрес, платформа и наличие у консоли доступа к удаленному компьютеру. Если используется Active Directory®, настройкой и развертыванием можно управлять через групповую политику.
Для защиты от недозволенных сообщений (вроде «Привет, в 4:00 в моем офисе будет гулянка!») агенты и консоли применяют код безопасности, подобный ключевой строке инструментария управления Windows (WMI). Кроме того, возможность отправлять предупреждения можно контролировать через политику Active Directory.
Цена: от 180 долларов США за лицензию для 75 пользователей.
Доставляйте объявления своим сотрудникам через NetSupport Notify
Доставляйте объявления своим сотрудникам через NetSupport Notify (Щелкните изображение, чтобы увеличить его)

Наблюдайте за своей сетью
NetOptics: Teeny Tap
www.netoptics.com
При использовании в сочетании с хорошим приложением наблюдения пассивные устройства прослушивания сети могут стать ценным средством для устранения неполадок капризных сетей, исправления неадекватно себя ведущих приложений и ослабления потенциальных угроз для инфраструктуры. Одно из хороших устройств прослушивания, которое мне советовали для сетей 10/100, – это чрезвычайно портативное средство Teeny Tap от компании NetOptics.
Это устройство, которое можно смело назвать крохотным (7,938 на 3,81 см), предоставляет полнодуплексное наблюдение трафика от уровня 1 и выше, позволяя легко делать выборочную проверку трафика или наблюдать за ним в сети 10/100. Система достигает полнодуплексного наблюдения с помощью двух портов наблюдения RJ45, дающих глубокое представление трафика, текущего на обеих сторонах его двух сетевых портов, когда оба подключены к сетевому монитору, анализатору протоколов, IDS/IPS или другому средству проверки.
Teeny Tap не требует IP-адреса. Путем изоляции наблюдателя от сети оно позволяет ему оставаться невидимым для тех, кто прекратил бы копаться в сети, заметив его присутствие. В то же время функция нулевой задержки гарантирует, что потеря питания устройством прослушивания не отразится на потоке трафика через него – от этого не возникнет задержек или потери пакетов.
Устройство прослушивания может питаться от USB или от входящего в набор источника питания, либо, для дублирования, можно использовать то и другое – выдающаяся возможность для такого малого устройства. Устройство Teeny Tap также совместимо со службами на основе питания через Ethernet, включая сетевые камеры и IP-телефоны. Таким образом оно позволяет отслеживать трафик и там, обеспечивая безопасность связи.
В состав набора Teeny Tap входит устройство прослушивания, универсальный источник питания, два прямых и два кросс-кабеля RJ45, а также футляр для их переноса. Тем, кому необходимо более мощное средство для своей среды, стоит ознакомиться с другими продуктами для прослушивания сетей, предлагаемых NetOptics. Линия продуктов охватывает широкий спектр от маленьких офисных сетей к большим корпоративным средам для электронных и оптических сетей от 10 МБ до 10 ГБ.
Цена: 325 долларов США (прямая загрузка).
Наблюдайте за своей сетью с помощью Teeny Tap
Наблюдайте за своей сетью с помощью Teeny Tap (Щелкните изображение, чтобы увеличить его)

Оптимизируйте свой компьютер
DTweak Pro
www.daoisoft.com
Всякий специалист по ИТ (и вообще любитель техники) без сомнения испытывал желание подправить свою систему и выжать максимальную производительность системы, а также добиться как можно более индивидуализированного интерфейса для своих повседневных действий. Существует множество средств, помогающих в оптимизации и индивидуализации интерфейса системы пользователя на компьютере, использующем Windows Vista®. Один из недорогих вариантов – это DTweak Pro от компании Daoisoft (его версия также доступна для Windows® XP и Windows Server® 2003).
Приложение предлагает ряд представлений быстрого доступа для различных средств и настроек Windows Vista. Например, в разделе повседневных средств можно найти средство очистки реестра, служебную программу очистки файлов, средства дефрагментации реестра и жесткого диска, а также монитор производительности жесткого диска.
С помощью DTweak можно также легко видеть и настраивать элементы автозапуска, получать информацию о ЦП (включая идентификатор процессора, скорость шины и тактовую частоту) и собирать информацию о компьютере, в том числе о поставщике состоянии запуска, конфигурации памяти и типе системы. Можно даже подправить свою память кэша ввода/вывода и время, которое приходится ждать до завершения потерпевших сбой программ и служб, которые перестали отвечать на запросы.
Раздел средств графического интерфейса пользователя предоставляет ссылки на встроенные средства Windows Vista, включая diskpart и восстановление системы, а также ссылки на удобные средства сети, такие как finger, ping, netstat и nslookup. В число других возможностей подстройки для сети входят корректировка максимального размера передаваемых данных, TTL для TCP/IP и параметров времени ожидания DNS, а также ограничение пропускной способности с помощью службы планировщика пакетов QoS.
Цена: 29,95 долларов США (прямая загрузка).
Настраивайте и оптимизируйте свою систему с помощью DTweak
Настраивайте и оптимизируйте свою систему с помощью DTweak (Щелкните изображение, чтобы увеличить его)

Обзор книги
Спутник администратора Microsoft Exchange Server 2007
www.microsoft.com/mspress
Электронная почта может быть очень капризной. Например, пользователь не контролирует поток входящих сообщений. При попытке остановить входящий поток путем приостановки сервера SMTP до тех пор, пока не уменьшатся его очереди, отправитель рискует получить уведомление о невозможности доставить сообщение. Сравнение с водопроводом здесь очень верно – вода течет постоянно, и перекрыв кран в одном месте, рискуешь получить разорванную трубу в другом. Хорошо спланированная, хорошо настроенная и гибкая инфраструктура электронной почты крайне важна для обеспечения ровной работы бизнеса в широком смысле.
Microsoft Exchange Server® 2007, разумеется, создан для обработки огромных объемов электронной почты и разработан, чтобы сделать возможной подгонку инфраструктуры под нужды организации – и сегодняшние, и завтрашние. Но при развертывании Exchange 2007 необходимо принять массу решений. Вдобавок, Exchange "умеет" больше, чем просто отправка электронную почты, что еще более усложняет задачу.
Пользователю действительно нужен хороший справочник, а иногда и не один, чтобы принимать верные решения по архитектуре и управлению. Одним из справочников, который может стать незаменимым, является Microsoft Exchange Server 2007 Administrator's Companion («Спутник администратора Microsoft Exchange Server 2007»).
Эта книга охватывает жизненный цикл развертывания продукта от планирования и развертывания до обслуживания и безопасности. В ней также рассказывается о различных клиентах и вариантах подключения клиентов, доступных для Exchange 2007. Она начинает с обзора различий между версиями и рассмотрения новинок в Exchange 2007. В нее также входит полный обзор архитектурных компонентов Exchange Server 2007.
В следующем разделе рассказано, как планировать развертывание Exchange и показано, как вычислять требования к хранилищу, серверу и процессору, а также добавлять отказоустойчивость. Далее книга охватывает собственно установку и развертывание, показывая, как приготовить сервер для Exchange и как установить различные компоненты ПО. В нее входит даже подробная справка по кластеризации служб Exchange для повышения уровня доступности.
Далее книга охватывает многочисленные доступные средства управления, такие как панель MMC в Exchange и новая оболочка управления Exchange на основе Windows PowerShell™. Здесь также рассказывается обо всем, от создания почтовых ящиков и групп хранения до операций резервного копирования и восстановления. Еще одно достоинство этого раздела – в нем показано, как выполнять все эти операции и с помощью графического интерфейса пользователя, и через командную строку с помощью Windows PowerShell.
У Exchange 2007 имеется ряд функций единой системы обмена сообщениями, которые позволяют управлять передачей данных и голосовых сообщений с помощью одной системы. В книге показано, в частности, как установить и использовать обмен голосовыми сообщениями, сообщениями по факсу, а также доступ к папке «Входящие» на голосовой основе.
Углубляясь в обслуживание, книга охватывает базовые методики и средства устранения неполадок, восстановление после повреждений и аварийных ситуаций, а также настройку производительности. Безопасность, разумеется, должна быть первоочередной заботой любой единой системы обмена сообщениями – в книге имеется подробная информация по защите развертывания. Из нее можно узнать о политике безопасности и рекомендациях, функциях по борьбе с вирусами и нежелательной почтой, а также инфраструктуре открытого ключа.
Наконец, в книге рассмотрены клиенты Exchangе и то, как поддерживать другие клиенты POP3 и IMAP в вашей организации. В целом, она является хорошим общим справочником для любого администратора, которые планирует развертывание, обслуживает или просто заинтересован в единой платформе обмена сообщениями Exchange Server 2007.
Цена: 49,99 долларов США (список).
(Щелкните изображение, чтобы увеличить его)

Грег Стин (Greg Steen) — специалист по информационным технологиям, предприниматель и энтузиаст. Он постоянно ищет новые средства, которые помогут специалистам по информационным технологиям упростить обеспечение качества, а также процессы разработки и эксплуатации.


Вопросы и ответы по SQL Ошибки ввода/вывода, зеркалирование баз данных и другое
Пол С. Рэндал (Paul S. Randal)

Вопрос: я начал применять постоянные проверки согласованности на управляемых мною базах данных и даже добавил некоторое число предупреждений агента SQL для отлова любых ошибок ввода/вывода, с которыми сталкиваются запросы пользователей. Я не знаю, будет ли работать примененная мною логика проверок и предупреждений, поскольку у моих баз данных нет проблем с повреждениями данных. Как можно создать некоторый объем повреждений в тестовой базе данных, чтобы я мог убедиться, что все работает правильно? Кроме того, следует ли мне предпринять что-либо еще для обнаружения ошибок ввода/вывода?
Ответ: старым фокусом для создания поврежденной базы данных в SQL Server® 2000 было ручное удаление строки из таблицы sysindexes тестовой базы данных. Но в случае SQL Server 2005 системную таблицу очень сложно повредить подобным образом. Лучшим способом собственноручного повреждения тестовой базы данных является использование шестнадцатеричного редактора для изменения файла данных, пока база данных закрыта. Вот что следует сделать:
  • Закройте базу данных, так чтобы файлы данных не были заблокированы. (Но постарайтесь не отсоединять базу данных, поскольку в случае повреждения не той страницы ее может оказаться невозможным присоединить снова.)
  • Выберите смещение в файле, скажем, более чем на 100 страниц в файл (как минимум 819200 байтов), но убедитесь, что оно выровнено по 8192-байтовой границе (границе страницы). Это позволяет избежать критических страниц метаданных и битовых матриц размещения, позволяя запустить базу данных и выполнить для нее DBCC CHECKDB.
  • Впишите в файл несколько байтов нулей на выбранном смещении. Использование этого приема практические гарантирует появление ошибок, связанных с повреждением заголовков страниц.
Но вообще, самый быстрый способ создать поврежденную тестовую базу данных – использовать базу, уже созданную другими. Примеры поврежденных баз данных SQL Server 2000 и SQL Server 2005 (с объяснениями) можно найти в моем блоге (по адресу go.microsoft.com/fwlink/?LinkId=115151).
Что же касается вашего второго вопроса, касающегося того, что следует сделать для обнаружения ошибок ввода/вывода, – следует включить контрольные суммы страниц. Эта функция сперва появилась в SQL Server 2005 как способ защиты всей страницы базы данных от ошибок, вносимых подсистемой ввода/вывода.
По сути, когда страница записывается на диск, в последнюю очередь SQL Server осуществляет вычисление контрольной суммы по всей восьмикилобайтной странице и отмечает контрольную сумму на странице. Когда страница читается с диска, то если у нее есть контрольная сумма, контрольная сумма высчитывается заново и сравнивается с хранящейся на странице. Если они не совпадают, то что-то вне SQL Server повредило страницу, и создается ошибка 824. Ошибка отображается подключению, которое привело к прочтению страницы, а также записывается в журнале ошибок SQL Server и журнале событий приложений Windows®.
Контрольные суммы страниц включены по умолчанию на всех базах данных, созданных на SQL Server 2005 и SQL Server 2008. Однако они должны быть включены вручную для баз данных, обновленных с предыдущих версий SQL Server. Включить контрольные суммы страниц можно с помощью следующего кода:
ALTER DATABASE mydb SET PAGE_VERIFY CHECKSUM;

Совет. Измените порт SQL Server по умолчанию
По умолчанию настроенный порт экземпляров SQL Server – 1433. После того, как этот порт использован экземпляром, он не может быть занят другим экземпляром. Следовательно, если необходимо установить второй (именованный) экземпляр порта в сети с использованием tcp, ему понадобится другой порт. А в некоторых случаях администратор может пожелать изменить порт по соображениям намеренного усложнения (хотя такая форма усложнения незначительна и легко взламывается сканером портов). Само собой, после этого понадобиться настроить клиент на использование другого порта. Существуют три распространенных подхода к этому.
Во-первых, предполагая, что администратор сменил порт экземпляра на 5555, можно просто указать номер порта экземпляра внутри имени машины, к которой следует подключиться, используя синтаксис MyServername,5555. Если порт изменится снова, клиентам придется снова изменить свои строки подключения.
Другой вариант – использовать псевдонимы SQL Server, настраиваемые на клиенте. Помимо указания имени псевдонима, также следует указать имена сервера, порта и протокола. После настройки псевдоним можно использовать подобно имени сервера для подключения к экземпляру базы данных. Преимущество этого варианта состоит в том, что изменения в настройке могут быть развернуты администратором домена, поскольку параметры хранятся в реестре.
Третий вариант для именованных экземпляров, где пользователь знает лишь имя экземпляра и указывает имя используя MachineName\InstanceName внутри строки подключения, – это использование службы обозревателя SQL Server. Это уже применено в SQL Server 2000 как часть работающей службы. Однако в SQL Server 2005 служба обозревателя SQL Server была построена как отдельная служба. Помимо обнаружения экземпляров для компьютера, она также отвечает на входящие запросы протокола пользовательских датаграмм (User Datagram Protocol – UDP) на порте 1434, выдавая соответствующий номер порта для запрошенного экземпляра, что делает возможным перенаправление для клиента и поддерживает прозрачное подключение.
— Дженс К. Сьюссмейер (Jens K. Suessmeyer), консультант корпорации Майкрософт по базам данных

Вопрос: для устранения всякой фрагментации из моей базы данных я установил план еженощного обслуживания, который восстанавливает все индексы в производственной базе данных, которая работает на SQL Server 2005 Enterprise Edition с пакетом обновления 2. Я обратил внимание на то, что это вызывает избыточный рост базы данных, так что я добавил действие по сжатию всего дополнительного занятого пространства, поскольку на диске не так уж много места. Похоже, что этап восстановления теперь не работает. Что происходит?
Ответ: вы столкнулись с распространенной проблемой людей, устанавливающих планы обслуживания. Вы попались в цикл сжатия-роста.
Когда индекс восстанавливается, перед удалением существующего индекса создается новая копия индекса. Эта процедура требует дополнительного места в файлах базы данных – обычно примерного такого же, что используется текущим индексом. В SQL Server 2000 дополнительное место также требовалось для сортировки строк индекса (примерно 20% размера индекса), но это требование было устранено для упрощения восстановления индекса в SQL Server 2005.
Администраторы порой желают удалить дополнительное пространство, возникшее во время восстановления индекса, и добавляют к плану обслуживания этап сжатия после этапа восстановления. Что не так хорошо известно, так это то, что такое сжатие вызывает фрагментацию индекса из-за природы его алгоритма. Это значит, что свежевосстановленный и дефрагментированный индекс немедленно становится фрагментированным вновь – ликвидируя результаты восстановления.
Учитывая, что файл базы данных просто вырастет снова при следующем восстановлении индекса, лучше позволить базе данных иметь в себе это дополнительное пространство и полностью избежать выполнения операции сжатия. (Вдобавок постоянный рост и сжатие файлов базы данных вызовет фрагментацию файлов на уровне ОС – что может поспособствовать плохой производительности точно так же, как и фрагментация индекса.)
Наконец, можно подумать о сокращении частоты восстановления индексов. Можно даже попробовать использовать альтернативный метод, такой как старый DBCC INDEXDEFRAG, написанный мною для SQL Server 2000, или новый синтаксис ALTER INDEX REORGANIZE в SQL Server 2005 и SQL Server 2008.
Существует полезный технический документ, рассказывающий о фрагментации индекса и дающий рекомендации, когда следует удалять фрагментацию (его можно найти на go.microsoft.com/fwlink/?LinkId=115154). Хотя этот документ был написан для SQL Server 2000, концепции остаются прежними.

Вопрос: мы в моей организации оценивали возможные стратегии аварийного восстановления и я думаю, что зеркалирование баз данных является правильным путем в нашей ситуации. Сервер, который я пытаюсь защитить, содержит массу не относящихся друг к другу баз данных (результат предыдущего проекта консолидации серверов), и я хотел бы использовать зеркалирование для них всех. Вопрос, над которым я бьюсь, состоит в следующем: сколько баз данных я смогу зеркалировать, прежде чем производительность начнет падать?
Ответ: ответом на этот вопрос я пользуюсь очень часто. И это – зависит от ситуации! Опубликованные руководства говорят, что не следует зеркалировать более чем 10 баз данных на экземпляр, но 10 – это не более чем грубая прикидка возможного максимума для большинства пользователей. Следует оценить следующие факторы для своей комплектации оборудования:
  • Сколько памяти имеется у основных и зеркальных экземпляров? (В идеале цифры должны быть одинаковы.)
  • Сколько вычислительной мощности выделено основным и зеркальным экземплярам? (Здесь цифры также должны быть одинаковы.)
  • Какова пропускная способность подсистемы ввода/вывода на зеркальном экземпляре? (И она должна быть такой же, как на основном.)
  • Какой объем журнала транзакций создается рабочей нагрузкой на каждой из баз данных?
  • Какова пропускная способность сети между основными и зеркальными экземплярами?
Два последних фактора наиболее важны. Если пропусканная способность между двумя экземплярами недостаточна, чтобы справиться с совместной скоростью заполнения журнала транзакций всех зеркалируемых баз данных, то производительность на основных базах данных упадет. SQL Server 2008 помогает частично облегчить эту нагрузку с помощью сжатия потока журнала.
Следующим наиболее важным вопросом являются требования к памяти и потокам исполнения для зеркалирования. Каждая отображенная база данных занимает один поток исполнения и некоторый объем памяти. На маломощных серверах множество зеркалируемых баз данных может перегрузить сервер при сочетании с обычной рабочей нагрузкой.
Также следует подумать о том, как будет выполняться зеркалирование. В синхронном режиме транзакции на основной базе данных не могут выполниться, пока все записи журнала транзакций не скопированы в журнал транзакций зеркальной базы данных. Следовательно, любая задержка, вызванная перегрузкой сети, может вызвать проблему с производительностью рабочей нагрузки на основной базе.
В асинхронном режиме транзакциям на основной базе не нужно ждать, но задержка сети может вызвать рост размера журнала транзакций, ждущего отправки на зеркальную базу. Это может вызвать проблемы с размером журнала транзакций. Что еще хуже, любые неотправленные транзакции будут потеряны в случае сбоя – так что чем больше журнал транзакций, тем выше потенциал для потери данных в ситуации восстановления.
Варианты могут значительно различаться, и я видел некоторые интересные примеры в реальных производственных средах. Например, мне довелось видеть среду со 150 базами данных, на каждой из которых выполнялось очень немного действий, причем не всех из них они выполнялись одновременно. Все 150 баз данных зеркалировались без проблем.
С другой стороны, я видал и установку всего лишь с тремя серьезно загруженными базами данных, но без хорошего сетевого подключения. В этом случае им едва удавалось зеркалировать одну базу данных, прежде чем недостаток пропускной способности сети начинал вызывать падение рабочей нагрузки.
Ключ к успеху – в первую очередь произвести вычисление скорости создания журнала. Если кажется, что доступная пропускная способность сети поддержит число баз данных, которые следует зеркалировать, то все может быть в порядке. Протестируйте свою комплектацию перед помещением ее в производственную среду и не забудьте включить все операции, способные создавать содержимое журнала транзакций, – особенно любое возможное обслуживание базы данных.

Пол С. Рэндал (Paul S. Randal) является руководящим директором SQLskills.com и обладателем звания MVP по SQL Server. Он работал в группе разработчиков обработчика хранилищ SQL Server в Майкрософт с 1999 по 2007 год. Пол написал DBCC CHECKDB/repair для SQL Server 2005 и был ответственным за разработку базового механизма хранилищ при разработке SQL Server 2008. Пол, будучи специалистом по аварийному восстановлению, высокой доступности и обслуживанию баз данных, регулярно делает презентации на конференциях. Он ведет блог по адресу SQLskills.com/blogs/paul.


Обзор служебных программ Советник по переходу на Windows Vista
Лэнс Уитни (Lance Whitney)

Наконец пришло время начать планирование перехода организации на Windows Vista®, что, как и любое другое обновление, вызывает ряд вопросов. Соответствуют ли сетевые клиенты требованиям к программному и аппаратному обеспечению? Какие проблемы совместимости возникнут? Для ответа на эти и другие вопросы корпорация Майкрософт предоставляет бесплатный советник по переходу на Windows Vista. Данная служебная программа выполняет поиск всего установленного на компьютере программного и аппаратного обеспечения для определения возможности обновления. Если обновление возможно, советник рекомендует оптимальную версию Windows Vista и указывает все проблемы, которые должны быть разрешены до обновления.
Поиск советника по переходу обычно занимает несколько минут. При выполнении поиска отображается таблица с различными версиями Windows Vista и сравнением их функций. Также можно выбрать определенный выпуск, Ultimate, Home Premium, Business или Home Basic, чтобы просмотреть краткое описание и список отличительных функций. После завершения выполнения поиска на экране «Report Details» (Данные отчета) будет указано, совместим ли ваш компьютер с Windows Vista, а также рекомендуемая версия. Данные включают следующие сведения.
System Requirements (Требования к системе) Указывается достаточность аппаратного обеспечения, процессора, ОЗУ, видеопамяти и устройства записи компакт-дисков или DVD. При недостаточности оборудования будут отображены сведения о необходимых обновлениях компьютера, например, объем памяти, который необходимо добавить.
Devices (Устройства) Проверка всех внешних устройств и драйверов, включая модем, принтер, сканер, звуковую карту и видеоадаптер. Если устройство не проходит проверку совместимости, в отчете указываются необходимые действия, например, загрузка последних драйверов с веб-узла производителя. Для удобства работы предоставляется ссылка на веб-узел.
Советник по переходу сообщает об известных проблемах совместимости и рекомендует способы их разрешения
Советник по переходу сообщает об известных проблемах совместимости и рекомендует способы их разрешения (Щелкните изображение, чтобы увеличить его)
Programs (Программы) Анализ установленного программного обеспечения. Получение сведений о приложениях, которые могут работать в Windows Vista, и приложениях, которые являются несовместимыми или должны быть обновлены для прохождения проверки.
Если какой-либо компонент не проходит проверку на совместимость с версий Windows Vista с большими возможностями, например, Ultimate, можно вернуться к начальному экрану и выбрать другую версию, например, Business. После этого можно будет узнать о соответствии компьютера всем требованиям для этой версии.
Наконец, на экране «Task List» (Список задач) приводится описание конфигурации аппаратного обеспечения, и перечисляются задачи, которые необходимо выполнить до установки Windows Vista и после этого. Указываются элементы предыдущих экранов и дополнительные рекомендации, как показано на снимке экрана. Экран «Task List» (Список задач) можно напечатать или сохранить как HTML-файл.
Советник по переходу предназначен для 32-разрядных версий Windows Vista или Windows® XP с пакетом обновления 2 (SP2), также необходимо программное обеспечение Microsoft® .NET Framework 2.0 и MSXML 6.0. Получить дополнительные сведения и загрузить средство можно на веб-узле microsoft.com/windows/products/windowsvista/buyorupgrade/upgradeadvisor.mspx.

Лэнс Уитни (Lance Whitney) — консультант по информационным технологиям, преподаватель и разработчик технической документации. Он провел бессчетные часы за настройкой рабочих станций и серверов Windows. Журналист по профессии, 15 лет назад он занялся изучением информационных технологий.


Sharepoint изнутри Децентрализованное администрирование узла
Пав Черны (Pav Cherny)

Загрузить исходный код для этой статьи: SharePoint2008_06.exe (1160KB)

Службы Microsoft Windows SharePoint Services (WSS) 3.0 и Microsoft Office SharePoint Server (MOSS) 2007 поддерживают гибкое администрирование и модель безопасности, которая позволяет организациям информационных технологий централизовать контроль над компонентами инфраструктуры, такими как веб-серверы и серверы баз данных, а также децентрализовать контроль над
семействами веб-узлов и узлами. Централизация инфраструктуры SharePoint® позволяет сократить издержки по поддержанию, консолидировать бизнес-логику, предоставить единую точку доступа к ресурсам SharePoint и избежать лишних затрат на развитие технологии.
В то же время децентрализованное администрирование узла позволяет гарантировать, что отдельные подразделения сохраняют автономный контроль над своими наборами веб-узлов SharePoint, узлами, библиотеками документов, списками, решениями по управлению и прочими ресурсами SharePoint. Однако побочным эффектом делегирования администрирования узлов отделам будет усложнение задач обслуживания для отдела информационных технологий. Например, как вы собираетесь отслеживать использование ресурсов, утратившие срок действия узлы SharePoint и устаревшие данные в централизованной инфраструктуре, если у вас нет доступа к семействам веб-узлов и узлам через вашу среду?
В этой статье я расскажу о модели безопасности WSS 3.0, включая ее преимущества и недостатки вследствие делегирования административного управления отдельными подразделениями через узлы SharePoint, при поддержании централизованного административного контроля над инфраструктурой SharePoint. Я покажу, как работает делегированное администрирование узла, как полномочия на доступ и ограничение безопасности на уровне узла, списка и элемента позволяют организовать безопасную и удобную для пользователя рабочую среду, и то, как веб-администраторы ферм могут получить доступ к необходимым статистическим данным узла, не нарушая ограничений SharePoint по уровню доступа.
Если вы хотите проследить мои объяснения на практических примерах, загрузите сопроводительный материал к этой статье, расположенный по адресу technetmagazine.com. В состав этого материала входят подробные инструкции по развертыванию веб-фермы на базе Windows Server® 2008, которая представляет собой наглядный пример производственной среды компании, имеющей множество подразделений.

Инфраструктура SharePoint и администрирование семейства узлов
Можно построить инфраструктуру SharePoint, основанную на развертывании одиночного сервера либо фермы веб-узлов. На деле компании используют обе структуры. Развертывание на одиночном сервере удобно для отдельных подразделений, которым необходимо быстрое и простое решение для совместной работы. Требования к производительности и надежности минимальны. Обычно пользователи должны понимать, что если сервер SharePoint их подразделения, зачастую развертываемый на оборудовании рабочей станции, оказывается недоступным вследствие проведения работ по обслуживанию, то это является заботой самого подразделения, и что пользователи, работающие в этом подразделении, не являются администраторами отдела ИТ.
Картина меняется полностью, если серверные ресурсы обслуживаются отделом ИТ. Производительность и надежность становятся важнейшими факторами, зачастую требующими развертывания сверхнадежных решений, которые гарантируют соответствие соглашению об уровне обслуживания (SLA). Сбалансированные по загрузке веб-фермы, кластеры SQL Server®, переключаемые при сбое, и базы данных, хранящиеся в сетях областей хранения (SAN), могут помочь обеспечить соответствие требованиям вашей компании по производительности и надежности. См. рис. 1, на котором показана такая архитектура.
Рис. 1 Инфраструктура SharePoint с переключаемым при сбое кластером SQL Server и SAN
Рис. 1 Инфраструктура SharePoint с переключаемым при сбое кластером SQL Server и SAN (Щелкните изображение, чтобы увеличить его)
Как видно на рис. 1, для обслуживания ресурсов в централизованной инфраструктуре SharePoint должны работать несколько администраторов, при этом каждый из них видит рабочую среду под своим углом зрения. Например, серверы в инфраструктуре прозрачны для администраторов семейств узлов. Администраторы семейств узлов работают со стандартным пользовательским интерфейсом SharePoint. Этот интерфейс не меняется в зависимости от того, расположены ли ваши узлы на компьютере, работающем под WSS 3.0 в вашем офисе, или на веб-ферме в центре данных.
Инфраструктура SharePoint также прозрачна для администраторов баз данных и инженеров хранения данных в SAN. Для этих администраторов базы данных SharePoint не отличаются от других бах данных SQL Server, а логические номера устройств (LUN) для кластера SQL Server, переключаемого при сбое, не отличаются от любых других номеров LUN. Администратор, который наиболее тесно работает с инфраструктурой SharePoint, – это администратор веб-фермы, при этом он не может управлять ни семействами веб-узлов, ни базами данных, ни номерами LUN.
Удивительно, но администраторы семейств веб-узлов отделов совершенно несведущи в деталях инфраструктуры. В конце концов, чтобы проводить обеспечение узлов и делегировать полномочия на доступ командам и группам внутри подразделения, нет никакой необходимости знать эти детали. Достаточно создать новый узел и начать работу, и такие проблемы, как высокая стоимость хранения информации, связанные с технологией SAN, вряд ли придут на ум.
С каждым проектом и работой появляются новые узлы групп, утратившие срок действия веб-узлы отмирают, просроченное содержимое не удаляется, и среда SharePoint стремительно разрастается, подобно грибам, пока не достигнет пределов, которые системный администратор не в силах терпеть. Например, внутренняя среда SharePoint в корпорации Майкрософт однажды состояла более чем из 180 000 веб-узлов, пока специалисты по ИТ компании не начали в 2006 году процедуру упрощения.
Обучение администраторов семейств веб-узлов может помочь держать ситуацию в централизованной инфраструктуре SharePoint под контролем. Установка квот и блокировок для семейств веб-узлов также является полезным делом, но все же эти методы не очень эффективны, если мы имеем дело с просроченными узлами групп и содержимым, которое впустую занимает драгоценное место хранения информации и ресурсы резервного копирования.
Просроченное содержимое не обязательно станет причиной превышения семейством веб-узлов установленной квоты. Конечно, вы можете настроить SharePoint таким образом, чтобы он отправлял уведомления по электронной почте владельцам семейств веб-узлов и автоматически удалял неиспользуемые семейства веб-узлов по истечении установленного периода с помощью функции подтверждения использования и удаления узла с административного узла SharePoint 3.0 Central Administration, но эти функции неработоспособны на уровне отдельного узла. Семейство веб-узлов может содержать как рабочие, так и вышедшие из употребления узлы, но функции подтверждения использования и удаления узла не будут работать при таком уровне детализации.
Позднее я покажу, как распознавать неиспользуемые узлы и просроченные данные путем проверки даты последнего изменения документов и элементов списка, даже не имея полномочий на доступ к семейству веб-узлов. Эта функция недоступна среди встроенных функций, но, к счастью, реализовать ее не столь трудно.

Децентрализованное администрирование веб-узла SharePoint
Делегирование привилегий администратора веб-узла SharePoint очень эффективно. Используя веб-узел SharePoint 3.0 Central Administration, средство командной строки Stsadm.exe или специально написанную программу, можно создавать внутри инфраструктуры веб-приложения, управляемые пути и семейства веб-узлов. В качестве администратора веб-фермы при создании семейства веб-узлов вы можете назначать основного и вспомогательного администраторов. Эти администраторы могут быть простыми пользователями домена. Предоставлять им полномочия администратора для веб-фермы или других серверов инфраструктуры не требуется. Для выполнения задач администрирования веб-узлов они пользуются своим веб-обозревателем непосредственно в интерфейсе пользователя SharePoint.
На рис. 2 показано администрирование делегированного веб-узла в соответствии с поэтапными указаниями, которые вы получаете в сопровождающих справочных материалах. В данном примере администратор веб-фермы обеспечивал отдельные семейства веб-узлов отдела кадров (http://sharepoint/hr) и отдела ИТ (http://sharepoint/it).
Рис. 2 Администрирование делегированного веб-узла SharePoint
Рис. 2 Администрирование делегированного веб-узла SharePoint (Щелкните изображение, чтобы увеличить его)
Администраторы отдела кадров (HR) и ИТ (IT) могли использовать функции Sites и Workspaces, доступные через меню Site Actions в пользовательском интерфейсе SharePoint, и создавать с их помощью веб-узлы подчиненного уровня, а также предоставлять полномочия на доступ из родительского узла или определять новые полномочия администратора и пользователя для узлов подуровней. Обратите внимание, что если это не настроено явно, то у администратора веб-фермы не будет доступа к веб-узлам верхнего и нижнего уровней; администратор отдела кадров не будет иметь доступа к веб-узлам отдела ИТ, а администратор ИТ не будет иметь доступа к веб-узлам отдела кадров, несмотря на то, что они находятся в одной среде SharePoint.
Устройство семейств веб-узлов и иерархии веб-узлов зависит от организационных требований. В примере, показанном на рис. 2, я не смог создать основной узел над http://sharepoint/hr и http://sharepoint/it. Другими словами, по пути http://sharepoint нет семейства веб-узлов. Но вы сможете просто создать семейство веб-узлов по этому пути или использовать другие управляемые пути, например http://sharepoint/sites/hr и http://sharepoint/sites/it.
Вы также можете создать отдельные веб-приложения для отдела кадров и отдела ИТ, чтобы установить более интуитивно понятные базовые адреса URL, такие как http://hr и http://it, представляющие собой веб-порталы общего назначения указанных отделов, а затем использовать веб-компоненты типа списков для отображения на этих главных узлах информации о веб-узлах нижних подуровней. Отдельные семейства веб-узлов облегчают задачу автономного администрирования; помогают ограничить доступ к информации отдела; предоставляют возможность выполнять настройку Главных страниц, разметки страниц, шаблонов, веб-компонентов и органов управления; а также могут быть использованы для размещения конфиденциальных данных в выделенных базах данных содержимого, отдельно от других семейств веб-узлов и баз данных содержимого.

Роли, полномочия для веб-узлов и ограничение безопасности
После того как семейство веб-узлов создано и назначены полномочия администраторов, администратор семейства веб-узлов может открыть узел верхнего уровня и использовать для управления семейством веб-узлов функцию Site Settings, которая находится в меню Site Actions. Сюда входят добавление (или удаление) других администраторов семейства веб-узлов с полными полномочиями для всех узлов в семействе, создание групп, назначение этим группам ролей, а также добавление в группы пользователей с делегированием им прав чтения или участника групп. В перечень задач входит также создание групповых узлов нижних подуровней и узлов групп.
Хотя вы можете назначать полномочия SharePoint каждому пользователю индивидуально, лучшим решением будет создание групп SharePoint с определенными ролями. Например, SharePoint имеет три группы с ролями по умолчанию Visitors (посетители), Contributors (участники) и Owners (владельцы). Посетители имеют доступ только для чтения; участники могут добавлять элементы в списки и лаборатории документов, а также персонализировать веб-страницы; владельцам предоставляется полное управление.
Одна замечательная особенность состоит в том, что SharePoint производит ограничение безопасности, основываясь на роли пользователя: это означает, что пользователи видят в пользовательском интерфейсе только те связи и элементы, на доступ к которым у них фактически имеются полномочия. Если вы запретите пользователю доступ к ресурсу, такому как список (путем настройки явных полномочий на доступ с помощью параметров List Settings) или отдельный элемент списка (с помощью команды Manage Permissions в контекстном меню элемента), этот список или элемент списка исчезнет у этого пользователя. Если пользователь укажет в обозревателе непосредственно URL-адрес этого элемента, то он получит сообщение об ошибке: Отказ в доступе.
На рис. 3 показана работа фильтра безопасности. Администратор узла отдела кадров (HR) имеет полный доступ и может использовать меню Site Actions для выполнения административных задач. Посетитель узла HR, с другой стороны, имеет полномочия только на чтение семейства улов и не может видеть это меню.
Рис. 3 Ограничения безопасности, основанные на ролях пользователей, в интерфейсе SharePoint
Рис. 3 Ограничения безопасности, основанные на ролях пользователей, в интерфейсе SharePoint (Щелкните изображение, чтобы увеличить его)
Ограничение безопасности используется для сокрытия недоступных функций, ссылок и элементов, но оно также подразумевает, что администраторы ферм веб-узлов не смогут просматривать веб-узлы и ресурсы узлов с помощью пользовательского интерфейса SharePoint, не имея доступа к ним. Вы не сможете просматривать эти ресурсы в веб-страницах или веб-компонентах. Более того, недоступные ресурсы не будут отображаться в результатах поиска, поскольку SharePoint Enterprise Search осуществляет фильтрацию ограничения безопасности во время обработки запроса, основываясь на сведениях о правах пользователя, делающего это запрос.

А что там с командной строкой?
Если графический интерфейс пользователя не обеспечивает доступа к требуемой информации без повышения прав доступа к данному уровню семейства веб-узлов, возможно, вас сможет выручить средство командной строки Stsadm.exe. Например, вы полагаете, что можно использовать следующую команду
Stsadm -o enumsites -url http://sharepoint
, чтобы вывести список всех семейств веб-узлов и владельцев по адресу http://sharepoint Web app. Теперь вы должны вывести список все дочерних узлов с помощью команды:
Stsadm -o enumsubwebs -url <site collection>
Но в среде веб-фермы программа Stsadm.exe выдаст сообщение об ошибке, указав, что разрешение на доступ к базе данных отсутствует. Stsadm.exe не сможет вывести последовательно все семейства веб-узлов, даже если вы администратор фермы и можете управлять коллекциями веб-узлов в SharePoint 3.0 Central Administration. Если вы использовали программу Stsadm.exe на ферме веб-узлов, не имея полномочий на доступ к SQL Server, будет выведено следующее сообщение об ошибке:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o enumsites -url http://sharepoint
<Sites Count="2">
<Site Error="Невозможно открыть базу данных &quot;WSS_Content&quot; запрошенную при загрузке в систему. Вход в систему отменен.&#xD;&#xA;Вход в систему пользователя 'CONTOSO\SPAdmin'.">
<Site Error="Невозможно открыть базу данных &quot;WSS_Content&quot; запрошенную при загрузке в систему. Вход в систему отменен.&#xD;&#xA;Вход в систему пользователя 'CONTOSO\SPAdmin'."> />
Администратор фермы веб-узлов получит это сообщение об ошибке, потому что программа Stsadm.exe работает с учетом того, что в системе зарегистрирован пользователь, например, CONTOSO\SPAdmin; в то время как узел SharePoint 3.0 Central Administration получает доступ к базам данных SharePoint в контексте того, что системная учетная запись связана с пулом приложений SharePoint Central Administration v3, то есть CONTOSO\WssConfigAdmin. Хотя предоставление вашей учетной записи полномочий db_owner для базы данных содержимого SQL Server позволяет вам использовать команду Stsadm -o enumsites -url http://sharepoint, вы по-прежнему не имеете возможности просматривать списки веб-узлов подуровней внутри семейств веб-узлов. Команда Stsadm -o enumsubwebs -url <site collection> выдаст сообщение «Отказано в доступе. (Исключение от HRESULT: 0x80070005 (E_ACCESSDENIED))», и вы возвращаетесь на начало. Однако есть лучший, более успешный путь, который не требует повышенного уровня полномочий для SQL Server.

Информация о веб-узлах в базах данных содержимого
Если вы не можете получить требуемую информацию с помощью стандартных интерфейсов и средств SharePoint, вам необходимо обратиться напрямую к базам данных содержимого SharePoint. Но вначале предупреждение: это должна быть крайняя мера! Базы данных основаны на собственных схемах и структурах баз данных, которые документированы компанией Майкрософт в WSS 3.0 SDK лишь частично, что сделано с целью убедить пользователей отказаться от работы с базами данных напрямую. Там, где это возможно, следует использовать для доступа к требуемой информации интерфейс пользователя SharePoint, средства командной строки, объектные модели или веб-службы.
Если все средства исчерпаны, и необходимо прямое обращение к базе данных, следует хотя бы ограничить свое вмешательство режимом «только чтение». Изменение схемы базы данных или структуры базы данных не поддерживается и может вызвать серьезные неполадки, которые потребуют восстановления семейств веб-узлов из резервных копий или переустановки веб-фермы SharePoint.
Возможной альтернативой решения рассматриваемой проблемы прямого доступа к базам данных содержимого является создание учетной записи администратора фермы веб-узлов с указанием его в настройке семейства веб-узлов в качестве второго владельца. Администраторы фермы веб-узлов могут выполнять это действие на узле SharePoint 3.0 Central Administration. Вы можете найти соответствующую ссылку на Site Collection Administrators в разделе SharePoint Site Management на странице Application Management.
В качестве второго администратора семейства узлов вы можете открыть семейство веб-узлов в веб-обозревателе, отобразить параметры узла Site Settings, а затем щелкнуть ссылку Site Usage Report в разделе Site Administration, если вы включили действия Usage Analysis Processing в разделе SharePoint 3.0 Central Administration. Если нужно проследить использование данных по файлам журналов на серверах SharePoint, загляните в раздел Logging and Reporting на странице Operations. По умолчанию функция Site Usage Report отключена.
Однако создание вручную отчетов об использовании веб-узлов для отдельного семейства веб-узлов не практикуется в системах с большим количеством семейств узлов или в случае строгих требований, которые препятствуют предоставлению администраторам ферм веб-узлов необходимых прав доступа. Более практичным решением является использование приложения составления отчетов ASP.NET, которое составляет списки всех семейств и веб-узлов из базы данных содержимого, выводя их вместе с основными статистическими данными, такими как количество элементов, суммарный размер всех элементов, а также дата последнего изменения элемента, как это показано на рис. 4.
рис. 4 Получение статистических данных непосредственно из базы данных содержимого
рис. 4 Получение статистических данных непосредственно из базы данных содержимого (Щелкните изображение, чтобы увеличить его)
Если вы запустите это приложение под учетной записью пула приложений SharePoint Central Administration версии 3, вы получите доступ к базе данных содержимого без необходимости получения расширенных прав доступа к SQL Server. Как говорилось ранее, учетная запись Central Administration имеет необходимые права доступа к SQL Server.
В сопроводительных материалах содержится простой пример отчета, который использует запросы SELECT к базе данных содержимого на сервере SQL, а также поэтапные указания по выполнению на веб-сервере. Необходимо заметить, что я не выполнял проверок безопасности. Это решение работает с анонимной проверкой подлинности.
Нет необходимости проверять подлинность пользователя, поскольку учетная запись Central Administration обеспечивает необходимый уровень безопасности при доступе к базам данных содержимого. Я использовал порт веб-узла, блокируемый с помощью брандмауэра Windows® на сервере Windows Server 2008, так что только локальный пользователь мог открыть это веб-приложение. Это гарантировало выполнение требований безопасности в моем примере, но в реальном производстве следует еще более ужесточить требования безопасности, например, включив проверку подлинности Windows и настроив жесткие ограничения доступа к виртуальной папке, содержащей приложение ASP.NET.

Заключение
SharePoint предоставляет гибкие возможности администрирования семейств веб-узлов и самих веб-узлов, которые позволяют централизовать инфраструктуру SharePoint при децентрализованном администрировании узлов в соответствии с определенными требованиями вашей компании. Централизованная инфраструктура может оказаться выгодна компаниям любого размера, поскольку консолидированная среда позволяет снизить затраты; облегчает совместный доступ к информации как внутри, так и между подразделениями; предоставляет основу для применения экспертных знаний в заданном направлении с целью эксплуатации системы в условиях высокой безопасности, надежности и масштабируемости; предоставляет пользователям единственную точку доступа к веб-узлам и ресурсам SharePoint в сети компании.
В то же время отдельные подразделения и бизнес-единицы могут самостоятельно управлять своими ресурсами SharePoint. Администраторы ферм веб-узлов могут назначать администраторов семейств веб-узлов, которые затем будут выполнять задачи администрирования в своих зонах ответственности без увеличения численности работников отдела ИТ.
Однако с передачей управления в подразделения администраторы ферм веб-узлов утрачивают возможность контролировать использование ресурсов в инфраструктуре, используя стандартные функции и инструменты SharePoint. Применение квотирования к базам данных содержимого, отправка уведомлений по электронной почте администраторам семейств веб-узлов, а также отслеживание использования данных с целью составления отчетов может помочь выявить проблемы, но с целью более эффективного управления инфраструктурой SharePoint администратор ферм веб-узлов должен иметь средства, которые позволяют извлекать требуемые метаданные о веб-узлах непосредственно из баз данных содержимого в режиме «только для чтения».
В число возможных вариантов решения входят использование служб отчетов SQL Server 2005 или аналогичных решений для создания отчетов уровня предприятия. Как показано в примере, содержащемся в прилагаемых материалах, для получения требуемой информации можно также использовать запросы SELECT программы SQL Server.

Пав Черны (Pav Cherny) – специалист по информационным технологиям и автор, специализирующийся на технологиях совместной работы и единой среды связи от Майкрософт. В числе его публикаций статьи, руководства по продуктам и книги по эксплуатации информационных систем и системному администрированию. Пав является президентом корпорации Biblioso —компании, которая занимается услугами по управлению документооборотом и локализации.


Язык сценариев Windows PowerShell Отличный внешний вид
Don Jones

Довольно распространено желание того, чтобы сценарии выводили данные в приятном для чтения виде, и меня часто спрашивают, как лучше всего создавать такие штуки, как таблицы. Существует пара способов это сделать. Первый из них – написать сценарий, который помещает данные – то есть любые данные, которые мне нужно отобразить в отформатированном виде, – в переменные, названные
$data1, $data2, and $data3. Теперь можно приступить к форматированию данных.

Текстовый способ
В интернете
Ищете быстрой демонстрации методов, которые обсуждались в этом месяце в статье, посвященной Windows PowerShell? Обратитесь по ссылке technetmagazine.com/video, чтобы посмотреть, как Дон Джонс работает с командлетами.

Наиболее распространенный способ подхода к подобной задаче – такой же, как и при работе на таком языке, как VBScript, Perl, KiXtart или любом другом ориентированном на текст языке. Я начну с того, что напишу несколько заголовков столбцов на экране:
Write-Host "ColumnA'tColumnB'tColumnC"
Обратите внимание на то, что `t – это особая отделенная последовательность в Windows PowerShellTM которая вставляет символ табуляции. Для того, чтобы выписать каждую из строк в таблице – помните, что данные находятся в $data1, $data2 и $data3, – я могу поступить по-разному. Один из способов – просто написать переменные, полагаясь на способность консоли заменять переменные их содержимым в двойных кавычках:
Write-Host "$data1't$data2't$data3"
Есть чуть более привлекательный способ сделать это – оператор f. Эта методика отделяет форматирование от данных и создает строку кода, которую я считаю наиболее удобной для прочтения и более простой в поддержке:
Write-Host "{0}'t{1}'t{3}" –f $data1,$data2,$data3
Несмотря на это, данных подход имеет несколько значительных недостатков. Прежде всего, полагаясь на фиксированные остановки по табуляции в окне консоли, я создаю довольно странное форматирование. Например, если определенная строка таблицы имеет в первом столбце 20-символьное значение, я отправляю все форматирование в эту строку. Кроме того, поскольку я вывожу весь текст с помощью Write-Host, мои действия двольно сильно ограничены отображением консоли.
Не существует простого способа отправки выводных данных в файл или преобразования их в другие форматы, даже если мне очень этого захочется. Что важнее всего, этот подход, ориентированный на текст, полностью игнорирует основанную на объекте консоль, в которой я работаю, и не испольует преимуществ невероятных возможностей и технологий Windows PowerShell.

Путь Windows PowerShell
Windows PowerShell – объектно-ориентированный. А это в идеале означает, что все, над чем работает программист, должно быть в объектах, позволяя консоли превращать все при необходимости в текстовые отображения. Но как создать объекты для случайных обрывков данных?
Я, продолжая свой пример, начинаю с создания пустого пользовательского объекта и сохранения его в переменной:
$obj = New-Object PSObject
Благодаря этому у меня есть свежий пустой объект для работы. Затем я добавляю данные к объекту в виде свойств. Для этого я просто направляю свой объект по каналу в командлет Add-Member. Я добавляю нечто, называемое NoteProperty, даю свойству имя (хорошая идея – использовать заголовки столбцов как имена свойств), а затем вставляю данные как значения свойств:
$obj | Add-Member NotePropertyColumnA $data1
$obj | Add-Member NotePropertyColumnB $data2
$obj | Add-Member NotePropertyColumnC $data3
Теперь я просто вывожу этот объект – не в консоль, а в конвейер:
Write-Output $obj
Затем можно повторить эти действия для каждой строки таблицы, которую нужно вывести. Ниже приведена короткая функция, принимающая строку и выводящая ее версии в верхнем и нижнем регистре, а также ее первоначальный вариант:
functionStringVersions {
param([string]$inputString)
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty Original($inputString)
  $obj | Add-Member NoteProperty Uppercase($inputString.ToUpper())
  $obj | Add-Member NoteProperty Lowercase($inputString.ToLower())
  Write-Output $obj
}
$strings = @("one","two","three")
foreach ($item in $strings) {
StringVersions $item
}
Я начиная с массива строковых переменных, работаю с одной за раз, и отправляю их в функцию. А выводные данные функции записываются в конвеер.
Следует отметить, что существуют более короткие способы написания этого кода, но я выбрал именно этот, поскольку он четко иллюстрирует то, что я хочу сказать. Результатом является идеально отформатированная таблица, как показано на рис. 1. А все потому, что консоль уже знает, как форматировать объекты в таблице.
Рис. 1 Выводные данные Windows PowerShell, отображенные в таблице
Рис. 1 Выводные данные Windows PowerShell, отображенные в таблице (Щелкните изображение, чтобы увеличить его)
Еси объект имеет четыре свойства или менее, Windows PowerShell автоматически выбирает таблицу. Поэтому у меня есть отличная таблица без каких-либо усилий с моей стороны.

Но это еще не все.
Командлет месяца: Get-Command
Я уверен, что вы использовали Get-Command или его полезный псевдоним (gcm) раз или другой для просмотра списка доступных командлетов Windows PowerShell. Но, возможно, вам неизвестно, насколько гибок gcm в действительности. Например, если вы хотите увидеть все, что Windows PowerShell может сделать со службой, запустите службу gcm -noun. Или же, если вы хотите увидеть все возможности экспорта Windows PowerShell, попробуйте выполнить экспорт gcm -verb. Если вам просто нужно увидеть, какие командлеты были добавлены той или иной оснасткой, например PowerShell Community Extensions, воспользуйтесь gcm -pssnapin pscx. (Можно заменить «pscx» именем любой оснастки, чтобы увидеть ее командлеты.)
Как можно видеть, Get-Command – основной игрок на поле изучения Windows PowerShell. Он позволяет узнать, какая функция доступна, не заглядывая в руководство. Следует отметить, что gcm – более точный способ обнаружения функциональности, нежели использование команды, например Help *. Функция Help только перечисляет темы справки. Любые командлеты, которые не были включены в изначальную версию справки, не отображаются в этом списке – даже если они находятся в нужном вам месте.

Преимущества этой методики распространяются далеко за пределы таблиц. При работе с объектами Windows PowerShell знает, как выполнить огромный диапазон задач. Нужно, чтобы данные содержались в CSV-файле? Используйте Export-CSV. Больше нравится HTML-таблица? Передайте объекты по конвейеру в ConvertTo-HTML. Данные нужны в формате списка? Передайте их в Format-List. Используя объекты, можно использовать все, что консоль уже умеет делать. Вот пересмотренный пример.
functionStringVersions {
  PROCESS {
   $obj = New-Object PSObject
   $obj | Add-Member NoteProperty Original($_)
   $obj | Add-Member NoteProperty Uppercase($_.ToUpper())
   $obj | Add-Member NoteProperty Lowercase($_.ToLower())
   Write-Output $obj
}
}
На этот раз я изменил функцию таким образом, чтобы она принимала выводные данные конвейера – это всегда хорошая идея при работе с объектами – и передавала выводные данные по конвейеру.
Функция поместила свой код в блок сценария PROCESS. Это значит, что функция примет вводные данные конвейера и выполнит блок сценария PROCESS по разу для каждого переданного объекта.
В блоке сценария PROCESS есть специальная переменная $_. Это ссылка на текущий объект конвейера,который обрабатывается. Практический результат заключается в том, что я могу передавать через конвейер массив строк:
@("one","two","three") | StringVersions
Я получаю таблицу, поскольку функция помещает свои выводные данные в конвейер. В конце конвейера консоль вызывает подсистему форматирования, которая принимает решение использовать таблице, поскольку объекты в конвейере имеют менее пяти свойств (если свойств больше, по умолчанию будет использован список).
Но мне не обязательно полагаться на поведение по умолчанию. Я просто могу передать эти объекты в другой командлет, чтобы сделать с ними что-нибудь другое:
@("one","two","three") | StringVersions | Format-List
@("one","two","three") | StringVersions | ConvertTo-HTML | Out-File "strings.html"
@("one","two","three") | StringVersions | Export-CSV "strings.csv"
@("one","two","three") | StringVersions | Select Uppercase,Lowercase -unique
На Рис. 2 показан полученный в результате выполнения второго примера HTML, отображаемый в веб-обозревателе. Просто представив выводные данные в виде объектов, а не в виде простого текста, я вдруг получил полный доступ ко всему многообразию функций, встроенных в консоль, – набор шаблонов форматирования, преобразование в HTML, параметры экспорта, возможность сортировки, фильтрации, группировки и многие другие.
Рис. 2 Выводные данные Windows PowerShell в формате HTML
Рис. 2 Выводные данные Windows PowerShell в формате HTML (Щелкните изображение, чтобы увеличить его)
Это очень мощная штука. В действительности я даже предложу вам сделать так, чтобы каждый написанный вами сценарий создавал объект как свои выводные данные, чтобы их можно было использовать максимальным количеством возможных способов – и при этом не придется написать ни единой строки кода.

Don Jones специалист по административной автоматизации Windows, автор книг, таких как Windows PowerShell: TFM и VBScript, WMI, and ADSI Unleashed. С ним можно связаться через форумы по адресу ScriptingAnswers.com.


Эй, сценарист! Работа с прохладцей тоже бывает вознаграждена!
Программисты корпорации Майкрософт

Загрузить исходный код для этой статьи: HeyScriptingGuy2008_06.exe (150KB)

В течение сотен лет люди считали, что тяжкий труд уже сам по себе является наградой; что истинное удовлетворение получается в результате каждодневного честного труда; что истинное счастье приходит от достижения, а не от движения; ну, в общем, вы поняли! Трудись упорно, не покладая рук (вспомните Золушку!), и когда-нибудь ты будешь вознагражден.
Заметим: правда ли, что если ты упорно трудишься, то не только станешь счастливей, но и будешь однажды вознагражден за свои старания? Почему вы задаете подобные вопросы?
Действительно, Золушке крупно повезло: в конце концов, если ты живешь со сварливой мачехой и парочкой ее отвратительных дочерей, у тебя будут все причины трудиться в поте лица. Но что если вы не столь удачливы? Что если у вас нет сварливой мачехи и двух отвратительных сводных сестер? Как вы предполагаете прожить долгие дни в изнурительной, неблагодарной работе? Каким еще образом сможете вы найти истинное счастье?
Ладно, если вы всерьез решили стереть пальцы до костей, программисты корпорации Майкрософт предлагают вам попробовать написать сценарий, который выводит данные в красивом ясном табличном формате, как показано на рис. 1.
Рис. 1 Табличный вывод
Рис. 1 Табличный вывод (Щелкните изображение, чтобы увеличить его)
Как мы уже сказали, Золушка очень повезло: ей приходилось убирать весь дом снизу доверху и, закончив уборку, забираться в очаг, чтобы возиться там в золе и саже. Но даже Золушка задумалась бы о том, стоит ли писать сценарий, который мог бы отображать данные в табличном формате. Сидеть в золе и саже — это одно. Писать сценарий, который выводил бы данные в табличном формате, — это совсем другое дело.
Заметим: если вы не должны писать этот сценарий, сидя в очаге, это — в значительной степени одно и то же.
Почему же Золушка раздумала бы делать эту работу? Потому что это чертовски трудно. Единственным способом представить данные в табличном формате в VBScript — сделать примерно так.
  • Начните с определения максимального размера каждого столбца. Например, вы захотите отображать название, используя для этого 52 знакоместа.
  • Затем вычислите количество символов во фрагменте данных. Например, отображаемое имя «Adobe LM Service» имеет 16 символов.
  • Если отображаемое имя превосходит 52-знаковый предел, определите количество символов, которое необходимо отрезать от конца строки, чтобы вместить его в отведенное место. Если отображаемое имя не превышает 52 символа, определите, сколько пробелов необходимо добавить к концу строки, чтобы длина строки составила бы точно 52 знака.
  • Повторите эти действия со следующей порцией данных. И со следующей. Ну и так далее.
Если вы помните историю с Золушкой, то, вероятно, знаете, что ваша добрая крестная-фея заявится незванной, превратит мышь в системного администратора (не комментируем, каких трудов это стоит), а затем эта мышь напишет вам этот сценарий. Но, вероятно, вам не следует рассчитывать на это. Скорее всего, вы будете в одиночестве.
Посмотрите на это оптимистично: что ж, вы будете самым удовлетворенным человеком в мире. Это потому, что вы — самый большой труженик на земле. Самый-самый.
Разумеется, некоторые, возможно, захотят выторговать себе возможность не работать столь упорно. Если вы принадлежите к таким людям, возможно, вы подумаете: «Слава Богу, что есть на свеье Сценаристы; они расскажут мне, как превратить мышь в системного администратора, а затем — как заставить эту мышь отформатировать мои выходные данные в табличном виде». Да, но, увы, у нас есть дурные новости: ребята из группы Сценаристов не имеют ни малейшего представления о том, как превратить мышь в системного администратора. (Хотя мы можем превратить системного администратора в мышь, если вам это хоть как-нибудь поможет). Мы не знаем, как вы сможете заставить кого-нибудь писать для вас сценарии, не говоря уже о тех, которые выводят данные в табличной форме.
Но это не важно. Коль скоро вы работаете под Windows® XP или Windows Server® 2003 (а среди вас таких много), вам не нужно иметь мышь, которая писала бы за вас сценарии. (Увы, нам очень жаль, но это не относится к Windows Vista®). Взамен этого, вы можете сделать это сами, особенно не утруждая себя, благодаря объекту Microsoft.CmdLib. Взгляните на пример сценария, показанный на рис. 2.
Figure 2 Создание табличного отображения
Dim arrResultsArray()
i = 0

Set objCmdLib = _
  CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = _
  WScript.Application

arrHeader = Array("Display Name", _
  "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" _
  & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery _
  ("Select * FROM Win32_Service")

For Each objService In colServices
  ReDim Preserve arrResultsArray(i)
  arrResultsArray(i) = _
  Array(objService.DisplayName, _
    objService.State,objService.StartMode)
  i = i + 1
Next
objCmdLib.ShowResults arrHeader, _
  arrResultsArray, arrMaxLength, _
  strFormat, blnPrintHeader, arrBlnHide
Если вы заинтересовались, Microsoft.CmdLib – это объект COM, который поставляется в составе Windows XP и Windows Server 2003. Этот объект имеет целый ряд свойств; чтобы получить дополнительные сведения о них, наберите в командной строке cmdlib.wsc /? и прочтите комментарии в файле сценария, который появится на экране. Сейчас нас интересует только одно свойство Microsoft.CmdLib: возможность выводить данные в табличном формате.
Это приводит к очевидному вопросу: как вы отображаете данные в табличном виде? Давайте посмотрим, сможем ли мы объяснить это. Как видно, пример нашего сценария начинается с определения динамического массива, который называется arrResultsArray:
Dim arrResultsArray()
В типовом сценарии данные данные отображаются на экране сразу же после их выборки. Но почему вы считаете, что Сценаристы делают все обычным образом? В этом сценарии мы не собираемся выводить данные сразу после их выборки. Напротив, мы собираемся поместить все извлеченные данные в массив, а затем дать команду, чтобы Microsoft.CmdLib отформатировал и вывел эти данные.
Другими словами, поэтому-то мы и начали с создания динамического массива (то есть массива, размер которого может быть изменен в ходе выполнения сценария). После определения массива мы присваиваем переменной-счетчику i значение 0; мы будем использовать эту переменную для отслеживания текущего размера массива.
Если вам интересно, мы присваиваем переменной i значение 0, потому что первый элемент массива всегда имеет порядковый номер 0. Соответственно, после того как мы добавляем в массив первый элемент, это будет элемент 0, а не элемент 1.
Затем нам нужно инициализировать экземпляр объекта Microsoft.CmdLib; для этого используем вот эти две строки кода:
Set objCmdLib = _
CreateObject("Microsoft.CmdLib")
Set objCmdLib.ScriptingHost = WScript.Application
И это приводит нас к следующему небольшому фрагменту программного кода:
arrHeader = Array("Display Name", "State", "Start Mode")
arrMaxLength = Array(52, 12, 12)
strFormat = "Table"
blnPrintHeader = True
arrBlnHide = Array(False, False, False)
Здесь мы устанавливаем несколько параметров настройки вывода. В первой строке мы указываем значения для массива с именем arrHeader; как вы догадались, это заголовки столбцов нашей таблицы выходных данных. В данном примере сценария мы собираемся извлечь данные о службах, запущенных на компьютере, а также отобразить значения свойств DisplayName, State и Start Mode для каждой службы.
Неудивительно, что мы указали для нашего массива имена столбцов Display Name, State и Start Mode (хотя мы могли бы просто назвать наши столбцы A, B и C; Ларри, Мо и Кудряшка или еще как. Имена столбцов не обязательно должны совпадать с именами свойств).
Заметим: существует множество вариаций истории Золушки, включая такую, в которой названы имена ее сводных сестер. У диснеевской Золушки сводных сестер звали Дризелла и Анастасия, а это — первое и второе имена нашего редактора!
Во второй строке программного кода мы присваиваем значения другому массиву, называемому arrMaxLength. Этот массив содержит размер каждого столбца таблицы. В нашем примере мы хотим использовать 52 знака для столбца 1 (отображаемое имя службы); затем мы хотим отвести по 12 знаков для отображения состояния службы и режима запуска. (Microsoft.CmdLib будет вставлять пробелы между столбцами автоматически). Если нам нужно, чтобы наши столбцы имели размер 52, 12 и 12 символов (а именно это мы и делаем), мы используем код, который выглядит так:
arrMaxLength = Array(52, 12, 12)
Третья строка указывает формат вывода данных. Мы хотим, чтобы данные отображались в виде таблицы; поэтому мы устанавливаем значение strFormat (переменной, которая определяет тип вывода), разумеется, Table. Предположим, что вместо этого мы захотели бы отображать данные в виде списка данных, разделенных запятыми. В этом случае мы бы указали формат как CSV, то есть:
strFormat = "CSV"
В сою очередь, мы могли бы получить выходные данные примерно в таком виде, как показано здесь:
"Display Name","State","Start Mode"
"Adobe LM Service","Stopped","Manual"
"Adobe Active File Monitor V4","Stopped","Manual"
"Alerter","Stopped","Manual"
"Application Layer Gateway Service","Running","Manual"
"Apple Mobile Device","Running","Auto"
"Application Management","Stopped","Manual"
Заметим, что Microsoft.CmdLib не только ставит запятые между выводимыми значениями, но также заключает каждый элемент списка вывода в кавычки. Эта функция гораздо лучше, чем мы могли думать вначале. В конце концов, чтобы проделать это вручную, вам необходимо было бы использовать программу, подобную приведенной ниже:
Wscript.Echo Chr(34) & objService.DisplayName & Chr(34) & "," & Chr(34) & objService.State & Chr(34) & "," & Chr(34) & objService.StartMode & Chr(34)
Ужас.
Что, простите? Вам не нравятся таблицы, но вам также не нравится и формат CSV? Ладно, в таком случае попробуйте установить формат вывода как List, и вы получите на выходе примерно следующее:
Display Name: Adobe LM Service
State:        Stopped
Start Mode:   Manual
Display Name: Adobe Active File Monitor V4
State:        Stopped
Start Mode:   Manual
Но мы отвлеклись. (Что мы склонны делать при малейшей возможности). После определения выходного формата мы присваиваем значение True переменной blnPrintHeader:
blnPrintHeader = True
Мы собираемся использовать blnPrintHeader, чтобы дать указание объекту Microsoft.CmdLib напечатать заголовки столбцов. А что если нам не надо печатать заголовки столбцов? Прекрасно; в этом случае присвойте переменной blnPrintHeader значение False:
blnPrintHeader = False
Наконец, у нас есть эта строка кода:
arrBlnHide = Array(False, False, False)
Когда придет время отображения данных, объект Microsoft.CmdLib даст вам возможность показать или скрыть столбец. Чтобы скрыть столбец (то есть чтобы подавить вывод значений определенного свойства), установите значение True; чтобы отобразить столбец, установите значение False.
В нашем примере вывода мы собираемся отображать значения для свойств DisplayName, State и StartMode, поэтому мы должны указать в нашем массиве значения False, False, False. Что если мы хотим отображать DisplayName, скрыть State и отобразить StartMode? В этом случае мы должны использовать следующую строку кода:
arrBlnHide = Array(False, True, False)
Помните: False используется для отображения столбца, а True — для того, чтобы скрыть его.
С этого места мы готовы выводить данные — или были бы готовы, если бы они у нас были. (Стали бы Сценаристы писать сценарий, который прерывал бы вывод данных, чтобы затем потратить кучу времени, отлаживая этот сценарий, лишь для того, чтобы обнаружить, что они не побеспокоились о том, чтобы сначала извлечь хоть какие-нибудь данные? Ну конечно же нет; и вообще, почему вы это сказали?)
Помня об этом, выполним следующее действие, которое будет заключаться в привязке к службе WMI (Windows Management Instrumentation) на локальном компьютере; а затем используем метод ExecQuery для извлечения сведений обо всех службах, установленных на этом компьютере:
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

Set colServices = objWMIService.ExecQuery ("Select * FROM Win32_Service")
Наверное, мы должны упомянуть о том, что вы не ограничены работой только с данными WMI. Как вы могли предположить, Microsoft.CmdLib может работать со всеми типами данных. WMI — это лишь удобный способ получения получения наборов данных.
После получения набора данных о службах мы определяем цикл For Each, который последовательно обрабатывает все службы набора. Тем не менее, вместо вывода значений свойств каждой службы мы используем следующий код:
ReDim Preserve arrResultsArray(i)
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
i = i + 1
Что делается в этой части программы? Итак, в строке 1 мы изменяем размер нашего массива, используя команду ReDim Preserve не только для изменения размера массива, но также для предохранения всех существующих данных в этом массиве. (Без ключевого слова Preserve размер массива изменится, но при этом все данные, находящиеся в этом массиве, будут стерты).
Какого размера массив создается? Во время первого выполнения цикла мы создаем массив размера 0; другими словами, мы создаем массив, содержащий один элемент. А как мы будем знать наверняка, что мы создаем массив размером 0? Потому что мы использовали переменнную счетчика i, и значение этой переменной равно 0.
Итак, если мы используем переменную i для отображения размера массива, не значит ли это, что мы всегда будем устанавливать размер, равный 0? Да, это так, за исключением того, что всякий раз, проходя по циклу, мы увеличиваем значение i на 1; как вы видите, это происходит в строке 3 нашего фрагмента кода.
Это заставляет нас беспокоиться только о единственной строке кода:
arrResultsArray(i) = Array(objService.DisplayName, objService.State,objService.StartMode)
Здесь мы просто берем значения интересующих нас свойств – DisplayName, State и StartMode – и добавляем их в массив arrResultsArray. Заметим, что мы не добавляем значения свойств по отдельности; напротив, мы добавляем их как массив значений. Согласитесь, это немного необычно: это означает, что каждый элемент массива arrResultsArray представляет собой другой массив; именно так работает Microsoft.CmdLib.
Конечно, это может заставить вас волноваться снова. «Массив массивов? Как же я смогу получить доступ к отдельной величине в массиве, состоящем из массивов?» Не паникуйте. Это просто: позвольте Microsoft.CmdLib позаботиться об этом за вас.
Обратите внимание: нам очень жаль, но доступ ко всем отдельным данным в массиве массивов — это почти единственное, что Microsoft.CmdLib может сделать для вас. Однако уборка комнаты злой мачехи, стряпня, а также шитье одежды для злобных сводных сестр будут предусмотрены в следующей версии объекта.
Фактически, мы можем выводить наши данные — в ясном табличном формате — просто вызывая метод ShowResults и передавая ему все массивы и переменные, которые мы ранее настроили в этом сценарии:
objCmdLib.ShowResults arrHeader, arrResultsArray, arrMaxLength, strFormat, blnPrintHeader, arrBlnHide
Как все это будет выглядеть? Это будет выглядеть как красиво отформатированный вывод, который мы хотели получить, когда рассматривали рисунок 1.
Неплохо, а? Вы сделали прекрасно смотрящийся вывод данных и при этом почти не затратили усилий. (А ваш следующий сценарий будет еще проще, потому что все, что вам нужно сделать, — это внести самые незначительные изменения в первый сценарий).
Теперь следует признать, вы не будете получать того же удовлетворения, что получала Золушка, трудясь, как раб, день и ночь только затем, чтобы представить сценарий вывода данных в табличной форме. И, честно говоря, вам не придется выходить замуж за принца, хотя это и не относится к делу. Но это кажется малой ценой, которую платишь для того, чтобы получить столь хороший вывод сценария VBScript, особенно когда вы решите, какими бывают принцы в наши дни.
И кто знает: может быть, вы так или иначе сами станете принцем. В конце концов, даже августейшие особы нуждаются в информации обо всех службах, установленных на их компьютерах, не так ли?

Головоломка-сценарий доктора Скрипто.
Задача на этот месяц потребует не только умения решать головоломки, но и навыков создания сценариев.

Июнь 2008 г. PowerShell Pathway
Во всех этих головоломках соедините буквы по горизонтали, вертикали и диагонали, чтобы сложить имя командлета Windows PowerShell. Каждая буква должна использоваться только один раз. Приведем пример.
Командлет, составленный в этой головоломке, — New-Alias. Теперь ваша очередь. Вот еще три головоломки:

ANSWER:
Головоломка-сценарий доктора Скрипто.
Ответы: PowerShell Pathway, июнь 2008 г.

Read-Host

Set-AuthenticodeSignature

Программисты корпорации Майкрософт работают... ну хорошо, получают зарплату в корпорации Майкрософт. Когда они не играют в бейсбол, не тренируют бейсбольную команду, не смотрят бейсбол и не занимаются другими делами, они ведут проект Script Center в журнале TechNet Magazine. Веб-узел проекта находится по адресу www.scriptingguys.com..


Документы о рабочей среде Безопасность и соответствие требованиям
Уэс Миллер (Wes Miller)

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

Безопасность — не флаг
Материалы по SDL
  • The Security Development Lifecycle, авторы Майкл Говард (Michael Howard) и Стив Липнер (Steve Lipner), издательство Microsoft Press®, 2006
  • Блог по Security Development Lifecycle
  • Взгляните изнутри на применение Security Development Lifecycle в корпорации Майкрософт
  • Центр разработчика систем безопасности
  • Security Development Lifecycle защищенных информационных систем

Соответствие требованиям обычно включает требования (люди, процесс, инфраструктуру, технологию и так далее), налагаемые извне на организацию, индустрию, компанию или продукт. Иногда соответствие требованиям означает соответствие принятым в индустрии стандартам (например, Payment Card Industry Data Security Standards или PCI-DSS). В идеале это такие начинания, которые хотя бы до некоторой степени совпадают с тем, как работает ваша организация. С распространением стандарта становится невозможным его игнорировать; и если деятельность предприятия предполагается продолжить, нужно присоединиться к стандарту и наилучшим образом использовать его.
Но больше всех проблем вызывает соответствие требованиям другого рода. Я имею в виду требования, проводимые в жизнь правительством, например акт о передаче и защите данных учреждений здравоохранения (HIPAA) или закон Сарбэйнса-Оксли. В этом случае редко можно выбирать характер и сроки реализации требований.
Ключевой момент в понимании соответствия нормативным требованиям в том, что эти требования обычно применяются «сверху вниз». Для таких требований обычно есть какой-то шаблон, с помощью которого можно определить, соответствуют процессы на предприятии или производимая продукция этим требованиям или нет. Задача заключается в том, чтобы как-то привести в соответствие работу предприятия с этим спущенным сверху странной формы шаблоном. Нужно понимать не только причину того, почему данному требованию нужно соответствовать; зачастую более важно знать, какие юридические и финансовые последствия могут возникнуть из-за несоблюдения этого требования или безуспешных попыток его соблюдения (если такие последствия вообще есть).
И хотя исходные намерениями введения тех или иных требований соответствия не вызывают возражений, требований обычно тяжело внедрять и результат их внедрения может не соответствовать желаемой цели. И, к сожалению, многие из таких требований беззубы (то есть за неудачу их внедрения не наступает юридической или финансовой ответственности).
Как терапевтический больной я не могу полностью описать преимущества, которые дало мне внедрение HIPAA. Но я могу сказать, что его внедрение заставило меня проделывать гораздо больший объем работы с бумагами при каждом визите к врачу. Еще хуже могут оказаться непредвиденные последствия. Вы пытались когда-нибудь передать важную медицинскую информацию от одного врача или агентства к другому? Без письменного разрешения такую информацию передать нельзя, как бы срочно ни была она нужна.
Таким образом, некоторые требования соответствия становятся «флаговыми» требованиями. Тогда процессы на предприятии приходится разрабатывать или менять, пытаясь достигнуть единственной цели: соответствия нормативному требованию. «А хорошо ли это?» – как я частенько спрашиваю моего трехлетнего ребенка.
С другой стороны, безопасность правильно строить «снизу вверх». Разрабатывается ли программный продукт, создается ли архитектура новой сети организации, ключевое правило всегда одно: «семь раз отмерь, один раз отрежь». Например, разрабатывая архитектуру нового продукта неплохо на начальном этапе описать его взаимодействия, локализацию, версии и так далее, в том числе и элементы безопасности, которые необходимо встроить в приложение с самого первого дня (а потом продолжить исследовать и улучшать по мере разработки).
Если вы, как и большинство программистов, имеете дело с унаследованным приложением или архитектурой, то тем более необходимо проводить детальную проверку системы безопасности, что я часто отмечал в своих статьях. Если вы не понимаете, как что-то работает, как вы можете судить, безопасно оно или нет? Дальнейшая информация по Microsoft® Security Development Lifecycle (SDL) находится в боковом примечании "ресурсы SDL".

Общее осмысление
Я помню, как меня учили, что безопасность не сводится к простому внедрению шифрования, спискам управления доступом (ACLs, TLS) или инфраструктуре открытого ключа. Настоящая безопасность начинается с общего осмысления: понимание, почему данная версия данного протокола никем не используется или никогда не поддерживалась; почему новый фрагмент взаимодействия между процессами предотвращает атаку «злоумышленник в середине»; почему реализация программы в версии v2 намного безопаснее, чем в версии v1, хотя v1 гораздо быстрее. Также необходимо знать, как взаимодействуют друг с другом все части инфраструктуры.
Соответствие требованиям, с другой стороны, предполагает взять вашу технологию и добиться того, чтобы построенная инфраструктура соответствовала некоторым критериям. Некоторые требования, такие как Payment Card Industry Data Security Standards (PCI-DSS) или North American Electric Reliability Council (NERC), хорошо продуманы и могут привести в итоге к повышению самой безопасности. Однако, получив, в конце концов, «шведский стол» требований соответствия, которые нужно как-то вплести в существующий проект, и имея только ограниченные ресурсы, требования безопасности отходят на второй план.
Безопасность долгое время была падчерицей разработки программных продуктов. Многие из вас наверняка работали в организациях, где к безопасности относились как к «мы сделаем это позже». Как раз из-за того, что такое поведение «безопасность подождет» не работает и никогда не работало, нам приходится иметь дело с нормативными требованиями.

Достаточно хорошо
Недавно я поменял работу. Теперь я работаю в новой компании в Остине, Техас, которая разрабатывает технологию внесения приложений в список разрешенных, чем-то похожую на ту, что мы разрабатывали в Winternals для продукта Protection Manager. Оказывается, что очень интересно разговаривать с заказчиками о том, насколько безопасными кажутся им используемые технологии — или, конкретнее, насколько безопасным, по их представлениям, делает их инфраструктуру используемый ими технологический набор. Хотя большинство из них почти наверняка работают в надежно защищенной среде и не открыты настежь различным уязвимостям, я часто слегка отшатывался в страже от их оценки безопасности системы как «достаточно безопасной».
Нормативные требования — веселая штука: вы им либо соответствуете, либо нет. Ответственность лежит на вас. Ценой несоответствия может быть штраф, наказание по закону или удаление из организации. Часто этого недостаточно, чтобы что-нибудь действительно изменилось.
В случае с федеральными нормативными требованиями я часто встречался с отношением «достаточно хорошо, чтобы отвязались аудиторы» или с желанием работать без создания некоторой инфраструктуры соблюдения требований, обычно потому, что принимающая закон организация (в данном случае HIPAA) не выделяет достаточно денег для контроля за исполнением закона — в результате гораздо дешевле становится просто работать без страховки, а последствия расхлебывать потом.
Безопасность часто налетает на тот же дорожный блок, но, по-моему, он хотя бы более конкретен. Если в качестве разработчика вы активно указываете менеджеру на то, что удаление раздела «foo» из спецификации оставит продукт заметно более уязвимым к атакам извне, вы по крайней мере можете сказать после того, как работа вашего участка над продуктом завершена: "А я вам говорил". С нормативными требованиями мой опыт говорит о том, что выполнение их обычно определено нечетко, а бюджет на их внедрение максимально урезан.. Менеджеров стремятся привести все в соответствие с наименьшим уровнем требований — таким образом соответствуя букве требования, но точно не его духу.

Определение текущего уровня
Ресурсы по безопасности и соответствию требованиям.
  • Руководство по решениям проблем безопасности и соответствия требованиям.
  • Руководство по безопасности
  • Руководство по планированию и внедрению Payment Card Industry Data Security Standard Compliance Planning.
  • Соответствие требованиям регулирующих организаций и обновления безопасности
  • Достижение совместимости
  • Отдел гражданских прав — HIPAA
  • Совет стандартов безопасности PCI
  • Совет надежности поставок электричества Северной Америке.

Хотя призыв делать программный продукт и организацию как можно более безопасной звучит идеалистично, на самом деле большинство требований к соответствию появляется как компромисс в ответ на плохую работу инженеров или, еще чаще, самодовольство. Мы живем в мире где «достаточно хорошо», к сожалению, достаточно хорошо. Однако в мире обеспечения безопасности «достаточно хорошо» обычно не лучший выбор. Мы, ИТ-специалисты мира, можем всерьез принять требования соответствия и пытаться выполнить и букву, и дух, тем не менее мы должны быть уверены, что инфраструктура на местах не просто так безопасна, как она может быть, но так безопасна, как она должна быть. Другими словами, соответствуйте требованиям с помощью настоящей безопасности, не пытаясь просто удовлетворить им.
Важно сделать шаг назад и посмотреть на технологию, которую вы стремитесь построить, будь то некоторое коммерческое программное обеспечение или набор средств, интегрируемых в большую систему. Нельзя переоценить важность понимания взаимосвязанных частей системы, совместной работы всех частей и наибольших угроз, стоящих перед системой.
В зависимости от того, в какой индустрии работать, разные требования соответствия могут играть определенную роль в вашей работе. ВЫ можете столкнуться с ними в повседневной жизни или только при проектировании чего-то нового. А может оказаться так, что требования соответствия будут только частью вашей работы во время специально организованных обзоров и аудита. Не важно. Я не думаю, что требования соответствия можно игнорировать, но я бы советовал вам присмотреться к текущему состоянию и вместо того, чтобы работать только над выполнением определенных требований, провести полный обзор безопасности, разобраться с работающими технологиями сверху донизу и запланировать это на то же время, что и обзор соответствия требованиям.

Что можно потерять?
В конце концов, наказания за несоответствие требованиям могут показаться двойственными. Несоответствие требованиям ставит вас под угрозу развития как раз такого варианта событий, от которого ограждает нормативное требование. Последствия могут быть слабыми и отдаленными, но они есть. Кроме того, последствий (индивидуальных) может и не быть. Будьте практичны, но все время помните о наихудшем варианте развития событий.
Если посмотреть на то же самое с позиций строгой безопасности, угроза должна быть очевидна — и, что важнее, должен быть очевиден возможный объем потерь, если уязвимость останется открытой.
Многие из тех, с кем я обсуждал эту тему, говорили, что требования соответствия иногда можно спрятать — поскольку сами требования обычно оставляют немалый простор для интерпретаций. Однако после проведения анализа безопасности пробелы в защите и непосредственные угрозы должны быть четко видны. Если это не так, может оказаться полезным поручить проверку системы безопасности кому-то другому. Может, вы пропускаете важных членов команды, которые могли бы найти недостатки вашего решения.

Гоняясь за хвостом
В прошлогодней статье, посвященной безопасности, я обсуждал тему «Как не потерять ваши данные» (technet.microsoft.com/magazine/cc162325). Год прошел, и появились новые скомпрометированные системы, потерялись очередные незашифрованные переносные компьютеры и новый объем личных данных попали в чьи-то подозрительные руки. Трудно сказать, есть ли в этом хоть какой-то прогресс. Почему мы все время топчемся на одном месте? Проекты опаздывают, работают на крохотных бюджетах, с нелепо растянутыми ресурсами, пытаясь поставить слишком много функций за слишком короткое время.
К сожалению, такой тип окружения ведет к тому, что нормой становится минимально возможная работа. Это совершенно точно не метод получить безопасное и соответствующее требованиям решение, которое к тому же не смертельно опасно для сроков и бюджета проекта.
Я твердо верю, что:
  1. не надо реализовывать решение, которое вы не хотите сделать безопасным;
  2. добавляя новую функцию, безопасность ее нужно продумывать перед реализацией;
  3. если ваша организация не собирается строить систему безопасности как часть разработки технологических цепочек обработки данных, вам стоило бы поинтересоваться тем, какие вообще цели преследует компания или организация.
В организациях находится все больше личных данных партнеров и заказчиков, за безопасность которых организация отвечает. Очень жаль, что в том мире, в котором мы живем, слишком часто безопасность не является чем-то существующим по умолчанию, а сотрудники не считают безопасным интересоваться состоянием безопасности в организации.
Настоящий сбой системы безопасности (а не соответствия требованиям) часто служит запускающим механизмом, показывающим что «пришло время подумать о безопасности системы», а «страховка личности вора» стала любимым трюком, успокаивающим клиентов, учеников, пациентов и сотрудников, чьи личные данные и финансовое положение оказались скомпрометированы.
Нас всех просят делать слишком много, за слишком маленькие деньги и обычно за слишком короткое время. Однако наша ответственность как специалистов ИТ позволяет нам ставить вопросы о том, почему безопасность не занимает ключевое место, почему менеджмент слишком часто думает о безопасности только столкнувшись с перспективой нарушение соответствия требованиям или, что более вероятно, с возможностью сбоя безопасности и реальных или потенциальных судебных исков (которые могут повредить репутации, да и самому существованию организации).

Примите мой вызов
Больше чего-нибудь другого я призываю вас проверить текущее состояние в организации. Если вас просят соответствовать требованиям — постарайтесь убедиться, что, выполняя эту задачу вы не тратите зря время, выполняя еще и чьи-то чужие требования к безопасности. Наоборот, сделайте своей целью сделать систему безопасной и вместе с этим определить достаточно процессов или инфраструктуры, чтобы соответствовать требованиям. Дополнительные сведения по этому вопросу в боковом примечании «Ресурсы по безопасности и соответствию требованиям».
Итого, запомните: соответствие требованиям очень часто не совпадает с построением безопасной системы. Однако правильно реализованная безопасность довольно часто ведет и к выполнению нормативных требований.

Уэс Миллер (Wes Miller) –– старший технический руководитель продуктов в CoreTrace (www.CoreTrace.com) в г. Остин, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.


Бизнес информационных технологий 10 ключей к тому, чтобы стать лидером в области охраны окружающей среды
Майкл Уолш (Michael Walsh) and Элиза Уолш (Eliza Walsh)

По-видимому, все компании говорят о своей деятельности по охране окружающей среды. Информационные технологии могут играть в этом ключевую роль, создавая отличную возможность осуществления изменений и становления идейным лидером вашей компании и отрасли. Но с чего начать? В статье представлены 10 ключей к тому, чтобы стать эффективным лидером инициатив по охране окружающей среды и экологической устойчивости.
Ознакомьтесь с проблемами
Первый шаг – получение обширных и глубоких знаний об экологической устойчивости и вычислениях. Вам как ИТ-специалисту следует начать с получения ﻿хорошего понимания способов снижения воздействия вычислительной деятельности на окружающую среду, таких как управление питанием, консолидация аппаратного обеспечения и обращение с отходами.
Вы как лидер в области охраны окружающий среды также должны представлять, как программное и аппаратное обеспечение может уменьшить воздействие деятельности других отделов. Возможно, вам придется тесно сотрудничать с менеджерами отдела кадров, юристами и исполнительными директорами для определения политик, касающихся общего воздействия на окружающую среду компании — всего от политик деловых поездок до мировых норм углеродного следа.
Сотрудники вашей компании и иные лица будут ожидать от вас наличия экспертных знаний в области охраны окружающей среды, компании и отраслях, в которых работает ваша компания. Поэтому необходимо оценить собственное понимание экологической устойчивости и надежных вычислений, а также уникальных потребностей компании в краткосрочном и долгосрочном плане.
Если вы недавно работаете в компании или вступаете в новую должность, скорее всего, вы будете испытывать давление (реальное или предполагаемое) действовать быстро. Это в особенности справедливо для компаний, сравнительно недавно начавших позиционировать себя как компании, осознающие проблемы окружающей среды (и теперь стремятся так и поступать).
Вам не следует поддаваться искушению действовать слишком быстро. Это может поставить под угрозу как ваш авторитет, так и авторитет компании. В ближайшей перспективе сосредоточьтесь на срочных проблемах и отложите стратегические инициативы связи, пока не будете к этому готовы или не войдете в нормальный рабочий режим.

Объективно оцените вашу компанию
Следующий шаг – критическая оценка охраны окружающей среды и устойчивости вашей компании или сферы деятельности. Для этого необходимо привлечь ключевых заинтересованных сторон и иных влиятельных лиц компании и вне ее.
Потребуется разработать сеть внутренних и внешних контактов — лиц, позволяющих определить экосистему заинтересованных сторон. Они помогут в получении понимания критериев экологической устойчивости компании.
В зависимости от ваших обязанностей может потребоваться выяснить, соблюдает ли компания экологические нормы, стандарты и законы. Возможно, будет необходимо оценить состояние дел в компании относительно ваших целей и ожиданий аналитика. Также необходимо знать, как клиенты, партнеры, правительственные организации и адвокаты влиятельных клиентов воспринимают вашу компанию и ее деятельность по охране окружающей среды. Также может потребоваться определить текущие и будущие технологические, финансовые и экологические ограничения, относящиеся к вашей инициативе.
В зависимости от размера и бюджета организации стоит рассмотреть вопрос о проведении дополнительных исследований. Конструктивное мнение может быть получено посредством внутренних опросов, целевых групп и независимых исследований. Оно помогает лучше понять степень удовлетворенности сотрудников предыдущей деятельностью компании по охране окружающей среды, соответствие компании вашим целям и наличие скрытых возможностей рынка. Однако огромную потенциальную ценность здесь имеет возможность подтверждения или опровержения мнений ключевых заинтересованных сторон независимым исследованием.

Определение целей и сроков их достижения
Теперь можно приступить к определению целей компании как в краткосрочном, так и в долгосрочном плане. Для начала можно рассмотреть сроки в один год и пять лет соответственно, а затем изменить эти временные рамки в соответствие с вашими конкретными потребностями. Ключевой момент заключается в том, что охрана окружающей среды определенно не является краткосрочной проблемой, и лица, позиционирующие себя только в ближайшей перспективе, причиняют своей компании, акционерам, партнерам и клиентам серьезный ущерб.
Чтобы определить актуальность для компании однолетнего и пятилетнего периодов, необходимо оценить текущую и будущую ситуацию в сфере деятельности компании. Она включает корпоративную культуру, краткосрочные и долгосрочные цели бизнеса, текущие и будущие бюджетные ограничения, планы географического расширения и меняющуюся правовую среду вашей отрасли.
Например, центр обработки данных предоставляет контекст конфликта принятия тактических решений и стратегического позиционирования. Ранее первоочередным соображением при проектировании центра обработки данных являлось пространство. Однако в течение последних нескольких лет появилась тенденция к тому, что на роль главного ограничивающего фактора роста быстрыми темпами выдвигается электроэнергия, расходы на которую все более увеличиваются. Операторы центров обработки данных, осознавшие долгосрочное значение все более увеличивающейся важности электропитания, предпринимают меры по устранению недостаточности электроэнергии, включающие кардинальные изменения управления центром обработки данных, противоречащие пространству, как преобладающему фактору принятия решений. Иногда инвестиции в электропитание значительно превышают краткосрочные расходы по сравнению с сохранением существующей парадигмы. Однако с большим увеличением стоимости энергии операторы центров обработки данных, изменившие курс управления центрами обработки данных несколько лет назад, теперь считаются провидцами, а их компании более чем возместили первоначальные вложения.

Разработка концепции и стратегии
Теперь необходимо разработать концепцию и стратегию. Очевидно, они должны основываться на вашем понимании состояния и целей бизнеса. При определении концепции и стратегии их не следует воспринимать как неизменные понятия. В то время как обязательства вашей компании по охране окружающей среды могут быть долгосрочными, концепция и стратегия могут такими не быть. Они должны подвергаться серьезными пересмотрам, что обусловлено внутренними и внешними переменными, такими как меняющиеся нормативные требования, изменения восприятия клиентов и развитие задач бизнеса. С развитием инициативы компании по охране окружающей среды важно, чтобы концепция и стратегия ИТ соответствовала всем более широким корпоративным концепциям и стратегиям.
Определяя концепцию вы определяете направление коммерческой деятельности. Необходимо тщательно выбирать слова, чтобы они были обдуманными, конкретными и ясными, но не исчерпывающими. Концепция не должна раскрывать всю деятельность компании по охране окружающей среды. В ней должны упоминаться только задачи, необходимые для правильного ориентирования сотрудников и партнеров. Для сообщения концепции часто используется описание цели (или концепции). Важно начать информировать о своем представлении в течение первых шести месяцев.
Определяя стратегию вы не только определяете направление, но также и устанавливаете ясные цели и задачи бизнеса и указываете инвестиции, которые будут произведены для достижения этих целей и задач. В формулировании стратегического плана могут помочь существующие модели. Две лучшие модели для проблем охраны окружающей среды и экологической устойчивости – SWOT (Strengths (Cильные стороны), Weaknesses (Слабые стороны), Opportunities (Возможности) и Threats (Угрозы)) и PESTLE (Political (политические), Economic (экономические), Social (социальные), Technological (технологические), Legal (правовые) и Environmental (экологические) факторы). Затем можно определить стратегию в документе, например, стратегическом плане.
Имейте в виду, что лидеры, активно запрашивающие отзывы о своей концепции и стратегии от известных последователей и заинтересованных сторон, придерживающихся противоположной точки зрения, до выпуска письменного заявления с большей вероятностью достигнут успеха. Это в особенности справедливо для случаев, когда отзывы противников учитываются в итоговом варианте плана.

Пропаганда бизнес-стратегии
Чтобы приступить к пропаганде, не нужно ждать выпуска концепции и стратегии. Пропаганда должна начаться в день вступления в новую должность. Однако после выпуска концепции и стратегии необходимо, чтобы ваша роль стала более публичной – как внутри компании, так и вне ее. Прежде всего, вам или вашему представителю необходимо сообщить концепцию влиятельным группам, таким как сотрудники, аналитики, средства массовой информации, партнеры, клиенты и адвокаты клиентов. Необходимо воодушевить и убедить их, чтобы они поверили в вашу концепцию и стратегию, и убедительно доказать, что для вашей компании и целевой аудитории наиболее выгодна именно ваша стратегия.
Со временем необходимо перенести внимание на отдельные элементы стратегии. Также необходимо постоянно сообщать этим целевым группам о важных этапах, подтверждающих успешность, изменениях стратегии и честно признавать проблемы вашей компании или отрасли в целом.
Будьте готовы представлять для каждой аудитории различные интересы и потребности. Хотя необходимо говорить о конкретных потребностях и интересах всех целевых групп, исходная концепция и стратегия должны оставаться неизменными. Это позволит более эффективно завоевать доверие различных целевых групп.
Не поддавайтесь стремлению представлять различным аудиториям противоречивые «задачи бизнеса», чтобы успокоить их. Поступающие так лидеры не смогут завоевать доверие, необходимое для разрешения проблем. Как минимум, это может ограничить эффективность осуществления изменений. В худшем случае это может подвергнуть риску авторитет всей компании. На рис. 1 указаны семь ключей к эффективной передаче вашего сообщения.
Рис. 1 Сем﻿ь ключей к передаче вашего сообщения
Рис. 1 Сем﻿ь ключей к передаче вашего сообщения (Щелкните изображение, чтобы увеличить его)

Управление передачей сообщений
При осуществлении пропаганды концепции и стратегии необходимо оценить профессионализм и целостность внутренней и внешней систем передачи сообщений. Охрана окружающей среды и экологическая устойчивость так же связаны с корпоративной социальной ответственностью, как и с разработкой продукции, услугами, продажами и маркетингом. Даже если ваша организация доверила вам руководство в области охраны окружающей среды функционально — без непосредственного предоставления прав на действия граждан в области обеспечения экологической устойчивости — вы должны работать исходя из предположения, что придерживаетесь таких же стандартов, что и гражданский лидер.
Не следует недооценивать отношение внешней аудитории к проблемам окружающей среды и ее знание деловой практики, касающейся охраны окружающей среды. Что более важно, не следует недооценивать ее возможность разрушить вашу связь, если она недостаточно целостна или обещает слишком много или слишком мало. В противном случае компания может быть помечена как «greenwasher».
Поэтому необходима стратегия связи, включающая процесс рецензирования, проводимый специалистами компании, которые могут предоставить отзыв до того, как вы займете государственную должность. Стратегия связи должна содержать ключевые элементы системы передачи сообщений, как, ﻿например, корпоративный информационный бюллетень по охране окружающей среды, платформа передачи сообщений, список утвержденных представителей и темы для ﻿разговора. Стратегия связи, являющаяся ключом к ясной структуре и согласованности, должна быть определена сразу после разработки концепции и стратегии. Вам может быть выгодно установление личной ответственности основных владельцев системы передачи сообщений.

Возможность управления через контроль
Важно, чтобы осуществлялось управление ответственными лицами, находящимся в рамках вашей концепции и стратегии. Будь то эксплуатация, разработка продуктов или продажи и маркетинг, необходимо определить факторы, влияющие на возможность достижения целей и задач. Эти факторы должны быть занесены в точный список и связаны с общим стратегическим планом. После этого необходимо количественно и/или качественно скомпоновать эти факторы и установить показатели отслеживания для будущего анализа. Эти показатели должны быть активно управляемыми.
Лица, ответственные за предоставление этих показателей отслеживания, должны быть ясно определены; также необходимо регулярно проводить собрания с участием всех заинтересованных сторон. Заинтересованные стороны могут обсудить влияние отслеживаемых показателей на состояние стратегического плана, что становится возможным благодаря сопоставлению показателей с факторами, а факторов с отдельными элементами стратегического плана.
К сожалению, для многих руководителей в области охраны окружающей среды окажется, что их организации не подготовлены к поддержке этих показателей отслеживания с помощью средств оценки. Однако эти средства необходимы для предоставления качественных и количественных данных, необходимых для должного анализа и составления отчетов по деятельности в области охраны окружающей среды и экологической устойчивости. Поэтому необходимо разработать специальные средства оценки путем переработки бизнес-процесса, применения технологии совместной работы и оценки или разработки специальных внутренних средств.
Без поддержки инвестиций компании в средства оценки руководством более высокого уровня вы, вероятно, столкнетесь с необходимостью принятия серьезных решений «затраты-выгоды» относительно установления приоритета верных средств оценки за счет увеличения количества сотрудников.

Анализ и отчеты о воздействии на окружающую среду
Сбор количественных и качественных данных позволяет осуществить глубокий анализ. Такой анализ очень важен для руководителей, стремящихся выяснить, насколько успешны их инициативы и каково воздействие их действий на компанию или в﻿иды деятельности.
Меняющиеся нормативные требования, стандарты, требования закона и добровольная отчетность корпораций, касающиеся охраны окружающей среды, ужесточают требования к предоставлению подробных сведений о масштабе воздействия на окружающую среду. Применение необходимых средств и процессов для поддержки управления, оценки и анализа упрощает сбор сведений, необходимых для обязательных годовых отчетов, учета и добровольных отчетов об экологической устойчивости. Поэтому важно понимать требования к отчетности и знать об их изменениях в будущем, чтобы можно было осуществлять инвестиции в интегрированную инфраструктуру управления, оценки, анализа и отчетности, увеличивающуюся в соответствие с потребностями бизнеса.
Технологии для анализа и отчетности очень важны для компаний, стремящихся создать репутацию идейных лидеров. Ключевую роль в этой области играет программное обеспечение — в особенности программное обеспечения для управления состоянием окружающей среды, проектирования процессов, сбора и обработки данных, дистанционного исследования, совместной работы, визуализации и представления.
Доступное на рынке программное обеспечение иногда должно быть настроено для конкретных применений в области охраны окружающей среды. Поэтому могут потребоваться значительные инвестиции в технологии для создания интегрированной инфраструктуры управления, оценки, анализа и отчетности.

Идейное лидерство
Идейное лидерство – это цель всех руководителей в области охраны окружающей среды. Хотя существуют различные уровни идейных лидеров (некоторые примеры указаны на рис. 2), все они имеют общую черту: их квалификация основана не на должности, а от репутации целостного и отрытого принятия мер и осуществления изменений.
Рис. 2 Типы идейных лидеров
Рис. 2 Типы идейных лидеров (Щелкните изображение, чтобы увеличить его)
Мировая экосистема экологической устойчивости при осуществлении изменений опирается на идейных лидеров. Благодаря обширной сети контактов в правительственных, неправительственных, отраслевых организациях и органах защиты прав потребителей идейный лидер может объединять влиятельные стороны для разрешения проблем, требующих тесного сотрудничества. Идейный лидер также знаком с множеством новых экологических проблем, представляющих интерес для мирового сообщества, и может представлять эти проблемы всему миру.
Наконец, идейный лидер может представить решения важных проблем, которые все еще должны попасть во внимание отрасли в целом. Для разработки этих решений может быть необходима совместная работа и влияние на другие стороны — включая конкурентов — и вы можете вывести свою компанию на новые рынки , но результатом является то, что идейные лидеры могут осуществлять глобальные изменения.

Сохранение актуальности
Это новая дисциплина, и основные знания регулярно изменяются. Для сохранения доверия необходимо глубокое понимание различных научных, политических, правовых, экономических, технологических и коммерческих перспектив, предлагаемых другими лидерами в области охраны окружающей среды. Также требуется не обязательное соответствие современным взглядам, а, скорее, предложение уникальных перспектив на основе экспертного понимания экологической устойчивости и вычислений. Эта ﻿целостность будет основным дифференциатором в условиях увеличения числа лидеров в области окружающей среды (или лиц, претендующих на то, чтобы стать идейными лидерами) в ﻿отрасли.
Признанный лидер также должен быть уверен в делегировании полномочий для субординации экспертов в определенных важных областях и привлечения в компанию большего числа авторитетных представителей экологической политики, если это необходимо. Хотя регулярные собрания с руководителями более высокого уровня и система отчетов обеспечат сохранение исчерпывающих знаний о деятельности компании по обеспечению экологической устойчивости, ключом является понимание того, когда необходимо говорить от имени компании. Для этого необходимо ясное понимание основных обязательств и является чертой, отражающей искреннюю подтверждаемую обязанность для отстаивания взглядов по отношению к окружающей среде, ожидаемых внутренней и внешней аудиторией.

Майкл Уолш (Michael Walsh) – старший менеджер продуктов в области окружающей среды корпорации Майкрософт.
Элиза Уолш (Eliza Walsh) – консультант по стратегии связи и бывший специалист по связи корпорации Майкрософт в Китае.


Заметки разъездного инженера Совместная работа с разделенным экраном
Кентаро Тояма (Kentaro Toyama)

Расширение доступа к ПК для как можно большего количества людей — это достойная цель подразделения Microsoft Research India, которое наблюдало успех программы MultiPoint (обсуждавшийся в майском номере TechNet Magazine за 2008 год) — программы, позволяющей нескольким пользователям взаимодействовать с одним ПК при помощи нескольких мышей.
Split Screen — это еще один вариант одновременной совместной работы с компьютером, задуманный в Microsoft Research India. Программа устанавливается на один ПК с двумя клавиатурами и мышами, а затем использует средства службы терминалов, чтобы разделить монитор на две равные части. Затем два человека могут одновременно работать за одним монитором, запустив разные экземпляры ОС и независимо друг от друга выбирая для себя программное обеспечение (﻿research.microsoft.com/users/udaip/splitscreen.htm). Например, один может заниматься набором текстов, а другой работать в электронной таблице.
Чтобы реализовать технологию Split Screen, использовались три разных экземпляра службы терминалов, запущенных на Windows Server® 2003 (который теперь обновляется до Windows Server 2008). Первый терминал служит контейнером, который перехватывает и перераспределяет все события клавиатур и мышей. Этот уровень использует ту же хитрость, которая применялась в MultiPoint, в котором перехватывались все события мышей и клавиатур вместе с идентификаторами устройств (Windows® автоматически присваивает уникальные идентификаторы устройствам USB, когда их подключают к машине; эти идентификаторы не уникальны для данного устройства, но уникальны в пределах работающего экземпляра ОС — как раз то, что надо, чтобы понять, пришли ли два щелчка мышью от одной и той же или от двух разных мышей). Контейнер также рисует курсоры мышей.
Внутри контейнера открываются два дополнительных экземпляра службы терминалов, каждый их которых получает события, относящиеся только к одному экрану. Например, в режиме по умолчанию все события мыши с идентификатором x будут направлены в левую часть разделенного экрана, а мыши с идентификатором y — в правую.
Технология Split Screen использует службы терминалов, чтобы разделить монитор ПК пополам
Технология Split Screen использует службы терминалов, чтобы разделить монитор ПК пополам (Щелкните изображение, чтобы увеличить его)
Важно использовать один экземпляр службы терминалов как контейнер, что дает полный контроль над тем, какие события куда направлять, а также делает возможным более сложные функции. Например, можно разрешить курсору правого пользователя переходить на левую половину экрана и просто показывать (возможно, обучая) или даже взаимодействовать с другим окном.
В этом случае некоторая часть событий мыши правого пользователя будет передана в левую часть экрана. Мы думали о применении технологии виртуализации для получения того же результата; так можно было бы сделать, однако это заняло бы больше ресурсов.
Исследователи задались вопросом: не будут ли люди разочарованы, имея только половину экрана? Мы провели исследования в Бангалоре (Индия) совместно с организацией Hope Foundation, которая обучает основам работы с компьютером городскую молодежь с низким доходам. Учащиеся, кажется, усваивали столько же материала с применением технологии Split Screen, как и без нее, по крайней мере в рамках ограниченного набора учебных задач. Мы также исследовали проблемы эргономики, но они не возникли даже при работе за 14-дюймовыми экранами. И что самое важное, в центре обучения остались очень довольны возможностью работать со вдвое большим количеством учащихся на том же количестве компьютеров.
Microsoft Research India обсуждает со подразделением служб терминалов и другими командами корпорации Майкрософт перспективу вынесения этой технологии на рынок. Если вы хотите применить технологию Split Screen, дайте нам знать, какие варианты использования вы имеете в виду. Обратитесь по электронной почте по адресу splitscr@microsoft.com.

Кентаро Тояма (Kentaro Toyama) – помощник директора по управлению в отделении Microsoft Research в Индии (research.microsoft.com/india) и руководитель группы исследований технологий в отделе растущих рынков (research.microsoft.com/research/tem), которая занимается разработкой технологий для экономически бедных сообществ по всему миру.


О Windows из первых рук Два наихудших компьютера, которые когда-либо существовали
Рэймонд Чен (Raymond Chen)

В марте 2007 года , когда журнал PC World опубликовал список из 10 самых плохих персональных компьютеров всех времен, мое внимание привлекли две верхние строчки списка, поскольку оба этих компьютера мы использовали в работе. Хотя «использовали» - сильно сказано. Наверное, лучше сказать, что я видел эти компьютеры, поскольку большую частью своих периодов эксплуатации они провели в офисах сотрудников Майкрософт.
Компьютер Barbie компании Mattel находится на втором месте в списке PC World's. Этот компьютер был значительным усовершенствованием дешевых компьютеров скучных цветов. Он был дешевым компьютером скучного цвета, корпус, монитор и динамики которого можно было украсить розовыми наклейками — в общем, вы поняли. На нем также было предварительно установлено программное обеспечение с темой оформления Barbie.
Мы получили один такой компьютер в качестве тестового, а бедный специалист по тестированию, которому пришлось работать с этим компьютером, хотя бы имел чувство юмора и приступил к работе с притворным энтузиазмом, прикрепив все прилагаемые наклейки и украшения и установив компьютер так, как и было задумано. Компьютер стоял на столе, который был хорошо виден из коридора, и все проходящие мимо и замечающие ярко-розовую вычислительную беду, приглашались зайти и поиграть с ним.
Компьютер Barbie был источником постоянного веселья. Если с ним возникали проблемы и разработчикам требовалось посетить офис, чтобы устранить их, всегда можно было быть уверенным во внимательном осмотре или возгласе «здорово!», когда они понимали, с каким компьютером придется иметь дело. Как мне рассказали, однажды мой коллега, молодой специалист, установил на компьютер Barbie копию Windows Server® Datacenter Edition, просто чтобы развлечься.
Первый приз — или, что, возможно, более точно, последний — достался компьютеру Packard Bell. Ах, воспоминания... Всего один пример того, насколько хорошо был спроектирован данный компьютер: в стандартной конфигурации во всех гнездах расширения были установлены карты. Наверное, создатели думали: «наш компьютер настолько идеален, что вам никогда не понадобится обновлять его!»
Еще во времена проекта Windows® 95 один руководитель старшего уровня приобрел такой компьютер в качестве домашнего и постоянно устанавливал на нем последние сборки Windows 95, соблюдая корпоративный принцип «ешь еду своей собаки» (dogfooding). Как вы могли предположить, на компьютере возникали всевозможные проблемы, и его постоянно приходилось возвращать для устранения неисправностей.
Менеджер по разработкам проекта Windows 95 был мудрым человеком и отважился применить прямой подход к разрешению проблем. Например, чтобы убедиться в том, что система Windows 95 поставлялась с широким охватом совместимых приложений, он приехал на своем пикапе в местный компьютерный магазин и приобрел там по одному экземпляру всех компьютерных программ. Затем он выложил программное обеспечение на столы в кафе и пригласил участников команды разработки Windows 95, которые должны быть выбрать по два экземпляра программного обеспечения — с условием, что необходимо установить и запустить обе программы, а также зарегистрировать все ошибки, даже самые незначительные. Взамен они оставляли программное обеспечение себе. Кафе напоминало блошиный рынок, люди изучали столы в поисках простых программ и взволнованно спрашивали друг друга «Что выбрал?»
Обеспокоенный тем, насколько часто руководителю старшего уровня приходилось возвращать свой домашний компьютер для ремонта, менеджер по разработкам проекта Windows 95 снова применил прямой подход. Он отправился в местный компьютерный магазин и приобрел такой же компьютер Packard Bell, что и был у старшего руководителя.
Факт, что два таких компьютера существовали, уже достаточно плохой; но еще хуже то, что второй компьютер был отдан мне, чтобы я устанавливал на нем все новые сборки Windows 95 и устранял все возникавшие неисправности. Таким образом, когда руководитель старшего уровня устанавливал на своем домашнем компьютере последнюю сборку, не возникало бы никаких сбоев.
Если вы следили за рассказом и связали факты, вы, наверное, заметили помеху такому плану. Поскольку в компьютере Packard Bell отсутствовали незанятые гнезда расширения, подключить сетевой адаптер было невозможно. Мне пришлось прибегнуть к другим обходным путям получения возможностей сетевого подключения. Я ненавидел этот компьютер.

Рэймонд Чен (Raymond Chen)на своем веб-узле The Old New Thing (Хорошо забытое старое) и в одноименной книге (издательство Addison-Wesley, 2007 г.) рассказывает об истории развития Windows и касается вопросов программирования в среде Win32. Предметы в его зеркале кажутся более близкими, чем они есть на самом деле.