Comments 5
UFO just landed and posted this here
Статья важная, нужная, но лично мне хотелось бы большего.
Почти каждый раз, когда я читаю очередную статью о том, что надо обязательно ставить обновления, я вспоминаю песенку со словами «Гладко было на бумаге, но забыли про овраги — а по ним ходить». Потому что в жизни все не так просто, как это обычно пишут в таких статьях.
В частности, одна из наиболее серьезных, на мой взгляд, проблем с организацией процесса управления обновлениями — это как проверить, что обновления сами по себе не нарушают функционирование инфраструктуры (ну, и что делать, если они его все-таки нарушили). Потому что, если просто развернуть WSUS и настроить инфраструктуру на бездумную (а тем более — автоматическую) установку обновлений сразу по их получении, то это рано или поздно приведет к проблеме с функционированием какой-нибудь важной системы, развернутой на предприятии. И скорее — довольно рано: примеров обновлений, вызывающих весьма серьезные проблемы, на моей памяти было достаточно. Взять хотя бы июльское (ЕМНИП) прошлого года обновление Windows Server, после установки которого через несколько часов работы переставала функционировать служба транспорта Exchange Server, и для её восстановления приходилось перегружать сервер.
Поэтому реальный процесс управления обновлениями, на мой взгляд, обязательно должен включать в той или иной форме тестовое развертывание на ограниченном числе компьютеров. А развертывание обновления на основной массе компьютеров должно производиться только после успешного тестирования. Это создает дополнительно ещё ряд сложностей: как создать тестовую группу, как сделать её репрезентативной (чтобы критически важные системы обязательно попадали под тестирование), как отслеживать актуальность репрезентативности. И как не затянуть тестирование до того момента, когда исправление уязвимости реально понадобится.
Вот про такую, реальную, реализованную на практике организацию процесса управления обновлениями мне было бы очень интересно почитать. Сравнить используемые методы — технические и организационные — с теми, что использовались в моей практике, узнать о подводных камнях, с которыми сталкивались другие.
Почти каждый раз, когда я читаю очередную статью о том, что надо обязательно ставить обновления, я вспоминаю песенку со словами «Гладко было на бумаге, но забыли про овраги — а по ним ходить». Потому что в жизни все не так просто, как это обычно пишут в таких статьях.
В частности, одна из наиболее серьезных, на мой взгляд, проблем с организацией процесса управления обновлениями — это как проверить, что обновления сами по себе не нарушают функционирование инфраструктуры (ну, и что делать, если они его все-таки нарушили). Потому что, если просто развернуть WSUS и настроить инфраструктуру на бездумную (а тем более — автоматическую) установку обновлений сразу по их получении, то это рано или поздно приведет к проблеме с функционированием какой-нибудь важной системы, развернутой на предприятии. И скорее — довольно рано: примеров обновлений, вызывающих весьма серьезные проблемы, на моей памяти было достаточно. Взять хотя бы июльское (ЕМНИП) прошлого года обновление Windows Server, после установки которого через несколько часов работы переставала функционировать служба транспорта Exchange Server, и для её восстановления приходилось перегружать сервер.
Поэтому реальный процесс управления обновлениями, на мой взгляд, обязательно должен включать в той или иной форме тестовое развертывание на ограниченном числе компьютеров. А развертывание обновления на основной массе компьютеров должно производиться только после успешного тестирования. Это создает дополнительно ещё ряд сложностей: как создать тестовую группу, как сделать её репрезентативной (чтобы критически важные системы обязательно попадали под тестирование), как отслеживать актуальность репрезентативности. И как не затянуть тестирование до того момента, когда исправление уязвимости реально понадобится.
Вот про такую, реальную, реализованную на практике организацию процесса управления обновлениями мне было бы очень интересно почитать. Сравнить используемые методы — технические и организационные — с теми, что использовались в моей практике, узнать о подводных камнях, с которыми сталкивались другие.
Спасибо за ваш комментарий. Полностью разделяем вашу точку зрения: тема тестирования обновлений действительно заслуживает отдельного внимания и мы планируем поделиться своим опытом в нескольких дальнейших постах. В данном конкретном материале речь о кейсе расследования, а есть множество клиентов, для которых мы реализуем именно патч-менеджмент — вот про этот опыт обязательно расскажем.
Я создал таблицу-матрицу, где наглядно видно, какое ПО и ОС на каких системах тестируется, чтобы ничего не пропустить. docs.google.com/spreadsheets/d/16iREU_vCVSClTzkLPjmb_rFmY9iztH6IMtrtetTIXSU/edit?usp=sharing
Как правило, тестирование длится до 2-х недель (фиксируются заявки от пользователей + ручное тестирование), а затем раскатывается на оставшиеся хосты и сервера
Как правило, тестирование длится до 2-х недель (фиксируются заявки от пользователей + ручное тестирование), а затем раскатывается на оставшиеся хосты и сервера
Для централизованного управления патчами существуют специализированные решения.
Например, модуль Panda Patch Management позволяет управлять патчами, обновлениями и уязвимостями для Windows и более 300 приложений, работающих на этой операционной системе. Модуль позволяет практически полностью автоматизировать данный процесс с автоматической настройкой приоритетов, включая и управление нескачиваемыми патчами.
Например, модуль Panda Patch Management позволяет управлять патчами, обновлениями и уязвимостями для Windows и более 300 приложений, работающих на этой операционной системе. Модуль позволяет практически полностью автоматизировать данный процесс с автоматической настройкой приоритетов, включая и управление нескачиваемыми патчами.
Sign up to leave a comment.
Patch’ти — не считается: сказ о патч-менеджменте в лицах и красках