Материал данной статьи основан на опыте установки более 5 000 обновлений для продуктов Microsoft и Adobe.
Patch Management – это процесс управления обновлениями программного обеспечения (ПО), без которого вряд ли обходится хоть одна современная компания, думающая о безопасности своей ИТ-инфраструктуры.
Обновления или патчи — это дополнительное программное средство, которое применяется для исправления обнаруженных дефектов в программном обеспечении или изменения его функционала.
Существуют 2 типа обновлений:
- для операционных систем и серверного ПО, которые применяются для поддержки надлежащего уровня безопасности и устранения дыр в защите;
- для прикладного ПО (например, Microsoft Office, Adobe Acrobat или клиентские части бизнес-приложений), которые необходимы для решения возникших проблем с часто используемыми или важными библиотеками и другими частями исходного кода.
Помимо прочего очевидна важность обновлений и их своевременной установки для поддержания надлежащего уровня информационной безопасности. Однако в истории были печально известные случаи, когда «заплатки» уязвимостей одного приложения вызывали критические неисправности в других приложениях. Вот несколько таких примеров:
- Ежемесячное обновление Microsoft вызвало сбои в работе VMWare (8 февраля 2011 года);
- Обновление для браузера Internet Explorer, выпущенное Microsoft, содержало сразу две уязвимости: сбой в работе браузера, а так же переполнение буфера, которое позволяет хакеру с помощью специального сайта запускать на уязвимой машине код с привилегиями пользователя браузера (8 августа 2006 года);
- Декабрьские обновления от Microsoft были предназначены для исправления серьезной бреши безопасности в применении шрифта OpenType. Обновление затрагивало пользователей PowerPoint, Quark Xpress and Coreldraw. Выпущенные обновления не позволяли программам распознавать символы шрифта OpenType размером больше 15 пикселей (12 декабря 2012 года);
- Установка обновлений Microsoft для драйверов режима ядра (kernel mode drivers) привела к появлению синего экрана смерти (BSOD) на компьютерах пользователей в августе 2014;
- Обновление для офисного приложения PowerPoint 2013 привело к невозможности запуска приложения (10 февраля 2015 года).
Подобные неприятные последствия применения обновлений приводили к простоям бизнеса и потере денег, и этот риск никуда не делся. Однако неприятностей можно было бы избежать при помощи тщательного тестирования обновлений компанией-разработчиком перед их развёртыванием.
Компания Microsoft не раз сталкивалась с критикой в свой адрес по поводу недостаточного тестирования ежемесячных обновлений безопасности. В ответ на это представители корпорации дали понять, что в их планах переход на новую схему тестирования путем передачи услуги по тестированию обновлений «внешним» пользователям, то есть не сотрудникам Microsoft.
И, действительно, если взглянуть на данную проблему глазами компании-разработчика, то становится понятно, что тестирование обновлений на стороне разработчика довольно емкий по времени процесс. Каждое обновление должно быть протестировано в условиях максимально приближенных к тем, которые эксплуатируются на рабочих станциях и серверах потребителей продукта. Так, к примеру, компания Adobe тратит на тестирование обновлений (updates) до 6000 человеко-часов в месяц.
Но как показывает жизнь, тестирования компанией разработчиком никогда не будет достаточно для 100% пользователей в мире. Соответственно, риск того, что очередное обновление ПО остановит бизнес-процессы компании, остаётся. С другой стороны, не обновляться также нельзя, так как можно оказаться уязвимыми перед хакерами, которые могут нанести вред компании.
В качестве способа существенного снижения этих рисков крупные компании выбирают регулярную установку обновлений пакетами (релизами) с обязательным тестированием обновлений перед их развёртыванием в масштабе всей компании.
Методы управления обновлениями
Метод управления обновлениями является комбинацией подхода к тестированию обновлений и подхода к развёртыванию релизов с обновлениями. О них мы и расскажем далее.
Два самых распространенных подхода к тестированию обновлений — это:
- тестирование на локальных виртуальных машинах;
- тестирование в полноценной тестовой среде.
Современные технологии позволяют без задействования лишних единиц техники проводить тестирование обновлений, используя виртуализацию. Наиболее часто используемые и доступные продукты для создания виртуальных машин и сетей: VMware либо Oracle VirtualBox. Преимущества виртуализации в том, что:
- создание самой виртуальной машины не требует больших затрат по времени;
- виртуальных машин на одной физической платформе может быть несколько;
- каждая виртуальная машина имеет свои собственные виртуальные аппаратные компоненты: память, процессор, жесткий диск, сетевые адаптеры;
- и самое главное – это возможность сделать «снимок» текущего состояния системы и содержимого дисков одним кликом мыши, а затем в течение очень короткого промежутка времени вернуться в исходное состояние, что может быть очень полезным при условии обнаружения обновления, установка которого вызывает критические неисправности в системе.
Как правило, технология виртуализации используется для небольших сетей с количеством рабочих станций не более 45-70.
Также процесс управления изменениями можно упростить, используя всего пару корпоративных компьютеров или, так называемых, тестовых клиентов. Установив необходимые обновления на такие клиенты и протестировав систему после установки, можно увидеть последствия изменений и убедиться в результате применения обновления, оказывая при этом минимальное влияние на ИТ-инфраструктуру. Тестирование с использованием полноценной тестовой среды применимо для больших промышленных сетей и гарантирует высокую чистоту тестирования. При тестировании в полноценной тестовой среде используются те же подходы к установке обновлений и инструменты для управления обновлениями, что и в промышленной среде. И сейчас мы перейдём к ним и заодно рассмотрим подходы к развёртыванию релизов с обновлениями.
Инструменты для управления обновлениями
Как правило, все широко используемые программные решения для удаленного управления ИТ-инфраструктурой предоставляют возможность управления обновлениями, например:
- System Center Configuration Manager (SCCM) – программный продукт Microsoft;
- Unicenter Software Delivery – программный продукт компании Computer Associates;
- OpenView – программный продукт компании Hewlett-Packard.
Лидером по востребованности и использованию в условиях крупных промышленных сетей является SCCM. Поэтому приведём подробности реализации управления обновлениями на его примере.
Принцип управления обновлениями с помощью Configuration Manager достаточно прост. Все управляемые системы SCCM объединяются в сайты. Сайты содержат в себе:
- серверы сайта;
- системы сайта, выполняющие определенные роли по управлению инфраструктурой;
- собственно управляемые клиенты.
Каждый из серверов сайта должен иметь доступ к базе данных Microsoft SQL Server.
В качестве сервера обновлений используется Windows Server Update Services (WSUS).Он синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Это экономит внешний трафик компании и позволяет быстрее устанавливать исправления ошибок и уязвимостей в операционных системах Windows на рабочих местах, а также централизованно управлять обновлениями серверов и рабочих станций.
Здесь следует особо отметить, что сервер WSUS предназначен только для обновлений, выпущенных компанией Microsoft.
Однако существует еще один сервер обновлений – System Center Updates Publisher (SCUP) от Microsoft, который позволяет управлять обновлениями стороннего ПО и затем импортировать его на сервер WSUS, с последующим развертыванием на клиентах с помощью SCCM.
Стадии процесса Patch Management
Процесс управления обновлениями состоит из нескольких стадий:
- Подготовка тестовых клиентов
На машину для тестирования обновлений накатывается образ операционной системы, включающий приложения, а также утвержденные ранее протестированные обновления. При последующей загрузке операционной системы происходит автоматическая установка данных утвержденных обновлений. - Создание листов обновлений
После того как тестовая среда подготовлена к установке новых обновлений, начинается создание листов обновлений, или, как это называется в SCCM, патч-листов.
Патч-лист включает обновления, вышедшие в этом месяце и подходящие под определение «требуемые». Необходимость в обновлении для клиента определяет сам SCCM. Логика проста: если на клиенте установлено приложение Visio и в этом месяце вышло обновление для Visio, то подобный патч будет «требуемым» для данного клиента.
Что же касается обновлений для операционных систем и серверов, то здесь необходимость определяется в зависимости от их разрядности и пакета Windows Service Pack.
После того, как патч-лист создан, формируется новый пакет, включающий в себя все выбранные обновления, и пакет назначается на коллекцию, в которую добавлены тестовые клиенты. - Развертывание в тестовой среде (LAB Deployment)
При добавлении пакета к коллекции SCCM получает информацию о том, что для клиентов данной коллекции назначено новое задание, синхронизируется с SCCM-клиентом на тестовой машине и начинается развертывание (deployment). Процедура занимает всего несколько минут, по истечении которых, в области уведомлений панели задач появляется соответствующий значок. После двойного нажатия на значок, открывается Configuration Manager, где после выбора обновлений, начинается установка. Как правило, установка заканчивается запросом на перезагрузку системы. После нее начинается тестирование с задачей: найти патч, ломающий систему/компоненты системы, либо убедиться в отсутствии такового.
По своей сути вход в систему после перезагрузки уже является одним из пунктов проверки. Важно, чтобы при входе в систему не возникало никаких предупреждений/ошибок. Далее тестирование проводится по определенной тест-матрице. Проверки, входящие в тест-матрицу, зависят, в основном, от программного обеспечения тестируемой ИТ-инфраструктуры. Подробнее о проводимых проверках будет рассказано в разделе — «Этапы тестирования» ниже. - Развертывание на пилотных пользователях (стадия PRE Deployment)
На этапе PRE Deployment готовится список протестированнных обновлений, который отправляется с помощью SCCM на клиенты пилотных пользователей. Принцип тот же: пакет с обновлениями добавляется к коллекции, включающей в себя только пилотных клиентов, SCCM получает информацию о том, что для клиентов данной коллекции назначено новое задание и начинается развертывание.
Как правило, в качестве пилотных клиентов, выбираются те пользователи, которые
хорошо разбираются в ПО, за которое отвечают, и проверяют нормально ли работает приложение после установки обновлений. Количество пользователей, которые участвуют в пилоте, обычно варьируется в зависимости от числа рабочих станций сети.
Стадия PRE Deployment продолжается в течение 4-х дней, по истечении которых пилотные пользователи дают свою обратную связь (feedback). При возникновении конфликтов ПО с установленными обновлениями, последние исключаются из списка. Таким образом, формируется окончательный список обновлений, которые будут установлены на все рабочие станции промышленной сети. - Развертывание протестированных обновлений в производственной информационной среде (PRO Deployment)
Происходит на стадии PRO Deployment, с помощью SCCM, по тому же принципу, что и на тестовые и пилотные клиенты. В данном случае устанавливается время начала развертывания и дата завершения.
Шаги тестирования
Как уже упоминалось ранее, тестирование происходит на основании тест-матрицы. Ниже мы представим описание базовых проверок, которые обычно включаются в такие матрицы.
Тестирование установки. Установка обновлений на тестовый клиент инициируется SCCM. Как правило, после установки обновлений система требует перезагрузки. Соответственно, первая проверка: перезагрузить систему, войти в систему после перезагрузки под тестовой учетной записью, убедиться в отсутствии сообщений об ошибках/предупреждений системы.
Следующий шаг – проверка системной переменной PATH. Убеждаемся в том, что PATH не содержит символов и знаков, которые могут привести к проблемам.
Третий шаг – проверка журнала системных событий (Event Viewer). Информация об установке обновлений пишется в журнал под ID 19. Проверка позволяет убедиться в успешности установки всех обновлений и отсутствии ошибок.
Далее на очереди проверка офисных приложений. Проверкой Office, как правило, пересекаются все тест-матрицы процесса Patch Management.
Простые примеры проверок Office:
- Запустить Word, Excel, Power Point, Publisher, Access.
- Убедиться, что приложения открываются без возникновения ошибок.
- Внести изменения в документ, убедиться, что при закрытии появляется вопрос о сохранении и сохранение документа происходит по умолчанию в папку «Документы» (если не предусмотрено другое хранилище по умолчанию (by default)).
Данный пример проверки Office является базовым и общим. Матрица может включать в себя и более сложные детальные проверки. Например, кроме открытия MS Word и сохранения документа нужно проверить, что во вкладке «Орфография и грамматика» проставлена галочка «Проверка Орфографии и Грамматики» и т.д.
Одной из наиболее распространенных проверок так же является проверка приложений Adobe, которые подвергаются обновлению. Минимальная проверка для Adobe Flash Player заключается в проверке версии данного ПО на сайте. Если же обновление для Adobe Reader, то проверяется версия и производится проверка работоспособности приложения.
Проверка работоспособности браузера также в ходит в список базовых. Патчи не должны вносить изменения в настройки прокси и ActiveX, и это также проверяется при тестировании.
Кроме того стоит обратить внимание на общее влияние обновлений на систему. На этапе подготовки тестового клиента, который уже содержит ранее протестированные обновления, проводятся тесты, описанные выше, и результаты такого тестирования принимаются за эталон.
Любое отклонение системы от состояния, предшествующего вновь установленным патчам, анализируется и, в некоторых случаях, может быть принято решение об исключении патчей, ведущих к нежелательным изменениям в системе.
Стоит заметить, что для экономии полезного времени, некоторые проверки могут быть автоматизированы с помощью VBScript, например:
- создание объектов офисных приложений, открытие файлов программ, внесение изменений, сохранение;
- запуск браузера и переход на веб-страницы;
- выгрузка логов Event Viewer в таблицу «Excel».
Подводя итоги, хотим ещё раз подчеркнуть, что налаженный процесс управления обновлениями позволит заблаговременно убедиться в успехе применения обновлений и сохранить надежность и работоспособность инфраструктуры при постоянной установке обновлений, обеспечивающих необходимый уровень информационной безопасности.
Автор: Алиса Халиуллина
Автор: ICLServices
