Универсальный план управления исправлениями

Всего несколько лет назад единственным вспомогательным средством для управления обновлениями Windows был список исправлений на Web-узле Microsoft. Сегодня у администраторов имеется разнообразный инструментарий управления исправлениями — от бесплатных продуктов Microsoft, таких как Windows Server Update Services (WSUS), до полнофункциональных решений управления модернизацией. Но, несмотря на широкий выбор, многим малым и средним компаниям (SMB) не удается внедрить систему управления обновлениями.

В 2000 г. было трудно даже определить, какие исправления необходимо устанавливать. Поиск в списке бюллетеней безопасности был возможен только по году и продукту, но даже в этом случае было легко пропустить исправления. Сейчас пользователи могут не задумываться над процессом управления исправлениями: достаточно просто активизировать Automatic Updates, и служба выполнит за них почти все операции. Но Automatic Updates ограничивает возможности сетевых администраторов, неэффективно использует каналы связи, а иногда и нарушает функционирование важнейших серверов, от которых требуется бесперебойная работа.

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

Как правило, Microsoft выпускает исправления во второй вторник каждого месяца, и план построен с учетом этого расписания.

Готовим сервер

Для реализации этого плана необходимо установить сервер WSUS. Он может работать на серверах различной конфигурации (подробнее об этом рассказано в статье Microsoft по адресу http://www.microsoft.com/windowsserversystem/ updateservices/evaluation/sysreqs.mspx), но предпочтительна чистая выделенная установка Windows Server 2003 на системе, имеющей оперативную память объемом не менее 512 Мбайт и 10Гбайт свободного места на жестком диске (или больше, в зависимости от применяемых исправлений). Наличие Active Directory (AD) необязательно, но за счет AD упрощается управление и развертывание. Прежде чем продолжить работу, следует установить Microsoft IIS и новейший пакет обновлений и исправления для системы безопасности. Если возможно, желательно получить для сервера сертификат Secure Sockets Layer (SSL). Затем нужно установить WSUS, например, как описано в статье «WSUS решает проблемы», опубликованной в журнале Windows IT Pro/RE № 6 за 2005 год.

Группы развертывания

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

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

  • Тестовая. В группу Testing входят типовые системы, на которых выполняются конкретные процедуры тестирования.
  • Критическая. В группу Critical входят системы, исправления на которых должны применяться быстро, но при этом системы должны сохранять работоспособность.
  • Пилотная. Малая группа Pilot типовых систем, на которой исправления будут развернуты раньше, чем во всей компании.
  • Общая. В группу General входят все системы, не вошедшие в перечисленные выше группы.

В зависимости от размеров организации и изменений в политиках управления, может потребоваться больше групп, отражающих специфические роли компьютеров. Чтобы организовать каждую группу, следует щелкнуть на Computers в инструментальной панели консоли WSUS, а затем щелкнуть на Tasks и выбрать пункт Create a computer group. Затем нужно ввести имя в поле Group и щелкнуть на кнопке OK.

После того как будут организованы группы развертывания, следует открыть редактор Group Policy Editor (GPE) в домене и перейти к разделу Computer ConfigurationAdministrativeTemplates Windows Components Windows Update. Если при этом не видны раздел Windows Update и все параметры, показанные на экране 1, необходимо установить административный шаблон для WSUS. Для этого следует скопировать файл C:WindowsInfwuau.adm с сервера, на котором установлены службы WSUS, в каталог WindowsInf на локальной машине. Затем файл следует импортировать — щелкнуть правой кнопкой мыши на папке Administrative Templates в GPE, выбрать Add/Remove Templates и дважды щелкнуть на шаблоне wuau.adm.

Чтобы настроить членов домена на прием обновлений из WSUS, следует активизировать политику Configure Automatic Updates и политику Specify intranet Microsoft update service location. Для последней политики в полях Set the intranet update service for detecting updates и Set the intranet statistics server следует ввести адрес URL сервера, на котором развернута WSUS (например, http://MSUpdates).

Может пройти несколько часов, прежде чем все клиентские системы появятся на странице Computers сервера WSUS после завершения подготовки политик. Один из недостатков WSUS заключается в том, что служба полностью базируется на клиентах. Способа «протолкнуть» обновления от сервера к клиентам не существует. Однако можно настроить клиентов на проверку обновлений, запуская следующие команды на каждой клиентской машине:

gpupdate /force
wuauclt /detectnow

Если все клиентские компьютеры не появились в списке в течение часа после выполнения этих команд, следует проверить журналы событий на отсутствующих системах. Если система не обменивается сообщениями с сервером WSUS, то можно вручную устанавливать агента, загрузив его из узла с адресом http://go.microsoft.com/fwlink/?LinkId=43264.

Первая неделя: идентификация и доступ

В первую неделю месяца следует подготовиться к предстоящим обновлениям. В начале недели необходимо выполнить с помощью WSUS поиск новых систем, которые не отнесены ни к одной из групп или не располагают некоторыми исправлениями. Для этого нужно открыть окно WSUS, щелкнуть на кнопке Reports в инструментальной панели и щелкнуть на кнопке Status of Computers на странице Reports. Затем следует щелкнуть на View; отнести Computer Group к Unassigned Computers; установить флажки Needed, Unknown и Failed и щелкнуть на кнопке Apply, чтобы сгенерировать отчет. Просмотрев отчет, необходимо применить все исправления и устранить все неполадки, чтобы привести системы в соответствие с текущим базовым уровнем.

В первый четверг месяца компания Microsoft публикует сводку месячных бюллетеней по адресу http://www.microsoft.com/technet/security/ bulletin/summary.mspx. Следует уделить время изучению новых исправлений. Они не особенно детализированы, но дают представление о количестве бюллетеней, степени опасности угроз и уязвимых продуктах. Иногда Microsoft просто объявляет, что бюллетеней нет, и у администратора появляется свободный месяц, если только Microsoft не выпустит внеплановую критическую программу коррекции.

С помощью информации из сводного бюллетеня можно инициировать запрос изменений, чтобы формально документировать предстоящие операции. Контроль качества в каждой организации проводится по-разному — это может быть формальная процедура запроса или совсем простая форма, как на экране 2. Полезно посетить http://www.securityfocus.com/bid и просмотреть недавние извещения об уязвимых местах, по которым можно составить представление о будущих исправлениях.

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

Вторая неделя: планирование и развертывание

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

Компания Microsoft публикует бюллетени примерно в 10:00 (по времени на Тихоокеанском побережье США). Лучше не ждать, когда бюллетень безопасности попадет в почтовый ящик «Входящие», а посетить страницу бюллетеня по адресу http://www.microsoft.com/technet/security/current.aspx или щелкнуть на кнопке Get Security Bulletin Notifications в правой панели страницы, чтобы подписаться на рассылку по протоколу Really Simple Syndication (RSS).

Уделите время изучению каждого бюллетеня, применимого к организации. Затем нужно заполнить и утвердить любые обязательные формы запроса изменений. В частности, следует обратить внимание на смягчающие обстоятельства и обходные приемы, с помощью которых можно уменьшить угрозы, пока не будут применены исправления. Изучение смягчающих факторов и обходных приемов поможет также выбрать необходимые параметры для брандмауэра или системы обнаружения несанкционированного доступа IDS (Intrusion Detection System). По адресу http://www.securityfocus.com/bid многие компании публикуют собственные подробные рекомендации, соответствующие бюллетеням Microsoft, поэтому стоит посетить и этот сайт.

Первоначальное развертывание выполняется в тестовой группе, а все остальные группы настраиваются на работу в режиме Detect only (только обнаружение). Крайний срок применения исправлений в группе Test следует установить на дату в прошлом (экран 3), чтобы выполнить развертывание немедленно.

Экран 3. Настройка первоначального развертывания исправлений

В последнее время качество обновлений, выпускаемых Microsoft, значительно повысилось, но тестирование по-прежнему важно, особенно перед установкой на критичных серверах. Одни компании вводят тестовую процедуру с формальным письменным оформлением, другим достаточно простой перезагрузки. По крайней мере, следует убедиться в работоспособности затронутых продуктов и функций. Большинство обновлений оказывает минимальное влияние на систему и не требует исчерпывающего тестирования. Если исправление затрагивает важные компоненты ИТ-инфраструктуры, необходимо уделить время его тщательному тестированию. Для большинства малых и средних предприятий обычно достаточно тестирования в течение одного или двух дней. После периода тестирования каждое исправление следует устанавливать в группе Critical к крайнему сроку, указанному в запросе на изменение. Убедившись, что все критические системы функционируют нормально (обычно спустя один день), нужно устанавливать исправления в пилотной группе. Pilot — небольшая репрезентативная группа, с помощью которой можно выявить любые не замеченные ранее проблемы перед глобальным развертыванием обновления. Тестирование для пилотной группы необязательно должно быть таким же тщательным, как для других групп, но члены группы Pilot должны сообщать администратору, если исправление вызывает неполадки.

В оставшиеся дни второй недели следует устранить обнаруженные неполадки. Например, может оказаться, что некоторые приложения независимых поставщиков потеряли работоспособность или возникли более серьезные проблемы, в частности стали появляться «голубые экраны». В конце недели полезно посетить дискуссионные группы Microsoft по проблемам безопасности по адресу http://www.microsoft.com/technet/community/ newsgroups/security/default.mspx, чтобы выяснить, не встречались ли другие ИТ-специалисты с неполадками, которые могут возникнуть на вашем предприятии.

Третья неделя: окончательное развертывание

К третьей неделе администратор ясно представляет себе, может ли данное исправление вызвать неполадки. Если существуют опасения, можно обратиться в службу Microsoft Product Support Services, которая предоставляет бесплатные консультации по проблемам безопасности. Другой хороший ресурс — список рассылки WSUS по адресу http://www.patchmanagement.org. После устранения всех неисправностей можно развернуть исправления в группе General. В течение недели следует проверять отчеты о статусе WSUS на странице Reports сервера WSUS и устранять любые вновь выявленные проблемы.

К концу третьей недели должно быть завершено обновление большинства систем. После того как будет достигнут приемлемый уровень развертывания, следует установить новый базовый уровень безопасности для организации с помощью инструмента Microsoft Baseline Security Analyzer 2.0 (MBSA 2.0). MBSA 2.0 не только проверяет статус обновлений, но и отыскивает конкретные уязвимые места и ошибки в конфигурации, например ненадежные пароли, которые повышают вероятность взлома.

Функциональность нового анализатора интегрирована со службой WSUS. Например, MBSA 2.0 использует сервер WSUS для загрузки каталога новейших исправлений и снижает приоритет пока не одобренных исправлений. В анализаторе используется тот же агент Windows Update Agent и каталог обновлений, что и во WSUS. MBSA 2.0 помогает идентифицировать системы, пока не привязанные к серверу WSUS, и ведет поиск по имени домена или диапазону IP-адресов, обеспечивая полный охват сети.

MBSA 2.0 — несколько более гибкий инструмент, чем WSUS; он может быть полезен, если WSUS не может установить исправление в системе или правильно идентифицировать необходимые обновления. MBSA дает более подробные сведения о версиях файлов и более точные объяснения неполадок, вызванных применением исправлений. Имеется версия инструмента, запускаемая из командной строки, которую можно автоматизировать с помощью сценариев. Администраторам крупных сетей полезно ежемесячно сканировать различные группы систем, однако необходимо регулярно запускать MBSA, чтобы обеспечить единообразный базовый уровень безопасности в организации.

Четвертая неделя: подготовка к следующему месяцу

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

Марк Барнетт - Независимый консультант и автор, специализирующийся на проблемах безопасности Windows, имеет сертификат IIS MVP. Его книга Hacking the Code вышла в издательстве Syngress. mburnett@xato.net