«Работает — не трогай». Практически каждый IT-специалист в начале своего пути сталкивался с этой прекрасной фразой. Кто-то просто слышал. До кого-то пытались ее донести (настойчиво или не очень). Кто-то воспринял эти слова как догму и с тех пор проносит через всю свою карьеру (и жизнь), попутно передавая сию истину в молодые неокрепшие головы.

Проработав системным администратором 10 лет и занимаясь последние 2 года тестированием на проникновение, я только недавно окончательно осознал, что эта фраза — самый вредный совет, который мы только можем дать младшим специалистам.

Львиная доля этого утверждения в мире системных администраторов приходится на установку (вернее, неустановку) обновлений программного обеспечения. Кстати, речь идет не только о Microsoft. Для любого (в смысле, ЛЮБОГО) ПО, которое есть на белом свете, выпускаются или выпускались обновления.

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

Сразу хочу заметить, что здесь я говорю:

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

• про обновления в корпоративной инфраструктуре организации, где работает IT- специалист. Сюда относятся как корпоративные, так и личные устройства сотрудников, которые работают с них удаленно (в последнее время количество коих увеличилось в десятки раз).
  Если ваше личное устройство НИКАК не взаимодействует с рабочей инфраструктурой, то обновлять его или нет — решать только вам самим.

А что, собственно, не так?

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

1. IT-инфраструктура воспринимается как статичный элемент. Как квартира-музей, где трогать и передвигать ничего не надо, только изредка пыль смахивай. В итоге получаем красивую (хаха, нет) антикварную вещицу, которую любой незрелый ум может случайно сломать.
   Между тем, инфраструктура — живой организм, который постоянно меняется (даже при максимальном уровне лени системного администратора). А любой живой организм становится сильнее при небольших, но постоянных и контролируемых стрессовых ситуациях (да-да, антихрупкость собственной персоной).

2. Установка обновлений считается ненужным процессом. Процессом, который не несет ничего, кроме траты времени, новых заявок от сотрудников, боли и унижения.
   Несмотря на то, что обновления — это основа безопасной инфраструктуры (об этом ниже), это еще и идеальный стресс-тест для живого организма. Хоть что-то будет заставлять вас перезагружать ваши сервера.

Ну не ставлю обновления, тебе-то какое дело?

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

Думаю, что рассказывать в сотый раз о том же WannaCry нет смысла (о нем, наверное, слышали почти все, кто хоть как-то относится к поддержке IT). Просто отмечу, что уязвимость, которая использовалась для распространения (MS17-010), по-прежнему достаточно часто встречается в дикой природе. Через 5 лет после выпуска обновления.

Лично меня, как системного администратора, зацепило уязвимостью Smart Install в оборудовании Cisco через 6 дней после публикации информации о ней. Это вылилось в то, что в теплый пятничный вечер, прямиком с пробежки, мне пришлось вернуться на работу и уехать домой только в 1:30 ночи (спасибо коллеге, который довез меня до дома). Самое интересное, что атака проводилась на «старую дверь» — т.е. бот просто искал среди публичных адресов уязвимости и стирал конфиг оборудования. Благо были резервные копии.

Последним ярким примером, который показал, что ситуация не меняется, был ProxyShell. Напомню, что обновления, которые закрывают данную уязвимость вышли в апреле и мае 2021 года, а информация о деталях уязвимости на просторах сети появилась в начале августа того же года. Будучи уже в информационных потоках о новых уязвимостях, я узнал о ней быстрее своих бывших коллег системных администраторов. Практически все, кому я разослал информацию, подтвердили, что срочно надо ставить обновление.
Кстати, в одной из родительских контор коллеги, старший администратор целую неделю пытался найти (!) и установить обновление на Exchange. Успеха он не достиг (уязвимость в итоге была успешно закрыта, но уже другими людьми).

Минутка рекламы: системным администраторам, которые преимущественно управляют инфраструктурой Microsoft, я очень советую данный ежемесячный вебинар, где рассказывается о выпущенных обновлениях Microsoft: что они закрывают и как их лучше ставить. Час в месяц — и вы в теме (на момент публикации видео по новым обновлениям не выходили несколько месяцев. Но я не теряю надежды, что они вернутся).

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

Оно ставится вечно и все сломает.

Что касается времени установки, то Microsoft и сами прекрасно знают, что это одна из самых больших ям на пути к светлому будущему. Начиная с Windows 10 и Windows Server 2016 разработчики стараются оптимизировать процесс установки, чтобы минимизировать простой как клиентских, так и серверных ОС (не выключайте компьютер, все дела...).

В клиентских ОС стало все совсем хорошо, так как основная работа происходит на заднем плане и пользователь может увидеть только сообщение о перезагрузке (без этого никуда). Если мы возьмем клиентское устройство, где ежемесячно устанавливаются обновления, то установка очередного пакета не должна заниматься более 10 минут времени сотрудника.

В серверных ОС не так все радужно, хотя бы потому, что установка инициируется в ручном режиме (согласно нашей схеме работы, которая описана ниже) и магии background`а не происходило. Поэтому установка может занять немного времени. Но если сравнивать с ушедшими от нас серверными ОС (Windows 2003/2008), то процесс явно стал быстрее (в качестве измерительных приборов использовались мои личные ощущения и ощущения моих коллег. В минутах не скажу, не сравнивал).

Может ли что-то сломаться при установке обновлений? Реальность такова, что при любых изменениях сложных систем, в т.ч. инфраструктуры, всегда присутствует риск, что какой-то механизм перестанет работать. Обновления можно считать яркими представителями таких изменений. Однако, если отвечать на данный вопрос коротко, то МОЖЕТ. И я вам советую просто быть к этому готовыми. Примите это. Без нытья, слез и соплей про криворуких разработчиков.

В моей карьере системного администратора падение сервисов из-за обновлений происходили достаточно редко. За 4 года регулярных обновлений я могу припомнить лишь 2-3 ситуации, когда ломалось действительно что-то большое. Но даже в этих случаях у нас были плюсы:

• ломался какой-то отдельный сервис, а не вся инфраструктура. Больше всего времени (около 1.5 часов) было потрачено на восстановление Sharepoint после обновления агента SCOM;

• сервис не работал в специально отведенные часы, о которых пользователи заранее оповещались (об этом ниже). Т.е. никто из сотрудников не разводил панику, что прилегший сервис срочно нужен.

ДИСКЛЕЙМЕР: Я прекрасно понимаю, что мой опыт по количеству поломок от обновлений привязан только к конкретному временному отрезку и к конкретной инфраструктуре и следовательно не может гарантировать, что у других этих поломок будет столько же или меньше. Но если бы я откладывал установку обновлений, то я бы не просто закрывал глаза на текущие проблемы, которые УЖЕ СУЩЕСТВОВАЛИ, но и позволял им вырасти в прекрасного (со стороны) и страшного Черного Лебедя.

Хочу отметить, что отказ от установки любых обновлений — это крайность. Однако, противоположной крайностью будет автоматическая, бесконтрольная установка обновлений в день их выхода, без тестирования. Такая ситуация может сильно уменьшить количество нервных клеток системных администраторов. Например, после январских обновлений Microsoft, я, по «просьбам» знакомых, учувствовал в откате, восстановлении и настройке процесса установки обновлений. Бывших сисадминов не бывает.

Т.е. если ваша инфраструктура не обновлялась уже давно, то у вас есть несколько вариантов:

1. Ждать, пока придут господа пентестеры, заберут вашу инфраструктуру себе и напишут в отчете, что вам надо обновляться.

   

2. Ждать, пока к вам придут пентестеры с темной стороны и заберут вашу инфраструктуру себе. Ну а дальше, как карта ляжет (платить, расшифровывать, что выберете вы?).

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

Предположим, я заинтересовался. Что дальше?

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

1. Выбрали день и время, в которые будем ставить обновления. Такой отрезок времени мы назвали «технологическое окно». Мы использовали промежуток в несколько часов, которого должно было сполна хватить на установку и настройку обновлений (с запасом на решение проблем), по субботним вечерам. Суббота была выбрана по следующим причинам:

   • минимальная возможность того, что кто-то будет работать в это время. По этой причине легко было убедить бизнес дать нам этот отрезок времени для наших работ;

   • если в процессе работ что-то шло не по плану (какие-то сервисы не поднимались после установки обновлений/перезагрузки), то у нас было не только время не решение этих проблем, но и время, чтобы выспаться. Если бы мы выбрали, скажем, среду, то в четверг, после бессонной ночи, соображали бы мы, мягко говоря, туго. А я считаю сон не обидным рудиментом от предков, а прекрасным механизмом для свежести и здоровья.
     

2. Установка обновлений проводилась через 2 недели после их выхода. У нас не было времени, места и людей для тестирования всех обновлений, так как в инфраструктуре было очень много разных сервисов. К тому же, без клиентского взаимодействия не всегда получается понять, все ли работает корректно. По этой причине мы решили просто выжидать пару недель после выхода обновлений. Аргумент простой — за пару недель какие-то серьезные проблемы с обновлениями должны обнаружиться (в пример — январские и майские обновления Microsoft 2022 г.). Стоит отметить, что для этой возможности у нас был сервер обновлений (WSUS, SCCM), с помощью которого мы могли контролировать распространение обновлений. Если у вас такого нет, то очень советую его внедрить.

   Кстати, можно не мониторить новостные ленты, а просто смотреть на сайте Microsoft информацию по известным проблемам (например, для Windows 10 1809 и Windows Server 2019). Конечно, бывают обновления, которые закрывают критические уязвимости и их надо ставить срочно. Информацию о них мы получали из ежемесячного вебинара или Security Update Guide.

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

4. В пятницу перед работами, до 12 часов дня, мы отправляли письмо всем сотрудникам о том, какие сервисы будут недоступны в ближайшее технологическое окно. Пользователей всегда надо предупреждать о сервисах, которые будут недоступны. Иначе будете получать письма/звонки/сообщения о том, что что-то не работает. Конечно, есть люди, которые эти письма не читают. Но большая часть будет осведомлена.
   Иногда, в пылу рабочих баталий, мы забывали написать это письмо. В итоге мы откладывали работы на следующую неделю. Чтобы этого избежать, стали ставить себе напоминания.

5. В письме обязательно указывали, что если кому-то срочно надо работать во время технологического окна, то пишите нам, и мы скорректируем сроки работ. Все-таки мы (системные администраторы) работаем для бизнеса. И если бизнесу в это время надо работать, мы пересмотрим свой график установки обновлений. К слову, за несколько лет работ, никто этой возможностью не воспользовался. Но возможность-то должна быть :)
   

   

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

7. После завершения работ мы информировали всех о том, что работы завершены и все сервисы доступны. Это письмо помогает сотрудникам быть в курсе, что все хорошо и все работает.
   

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