Я подписан на список рассылки CentOS-announce, и я прочитал определения различных тегов важности, таких как Critical, Important, Moderate, Low, BugFix и т. Д., Но я все еще не понимаю, что действительно нужно сделать. и что может подождать (поскольку мне нужно обосновать прерывание нашей обычной работы, чтобы получить обновления).
До сих пор я старался как можно быстрее применить критические обновления в нашей производственной среде.
Каков обычный график применения этих обновлений? Они случаются так часто, что очевидно, что мы не можем применить их все быстро, потому что их нужно протестировать, чтобы убедиться, что они не сломали наши системы.
Для контекста, мы в основном управляем веб-сайтом, и в системе нет дополнительных пользователей, поэтому я обычно не беспокоюсь о «локальных эксплойтах» так сильно, как меня беспокоят удаленные эксплойты. Но я чувствую, что все еще не понимаю, как лучше всего применить эти обновления.
Спасибо,
Я управляю множеством различных веб-сайтов для разных клиентов, и обычно я этим занимаюсь.
Во-первых, высший приоритет обновлений безопасности должен быть само веб-приложение. Подавляющее большинство атак будут нацелены на ваш веб-сайт и код, который его запускает, и это должно быть защищено. Если вы используете готовые веб-приложения, это то место, где я бы даже подумал автоматический обновления, но я ни в коем случае не позволю обновить систему безопасности для чего-то вроде WordPress или Drupal более чем за 24 часа до его тестирования и, скорее всего, развертывания.
Если ваше веб-приложение создано на заказ, убедитесь, что ваши разработчики следят за проблемами безопасности, насколько это возможно. Это сценарий, в котором ваша организация должна использовать DevOps, чтобы гарантировать, что веб-разработчики и ИТ-специалисты хорошо работают вместе и что проблемы решаются своевременно.
После этого следующие критические обновления, которые я считаю, - это те, которые «становятся вирусными» и о которых вы слышите в национальных новостях, таких как Heartbleed, POODLE и т. Д., А также обновления всего, что находится на критическом пути, например nginx и PHP для Сайты Drupal и WordPress. Я применяю обновления для них, как только они становятся доступными. Я тоже в списках рассылки для восходящих пакетов (например, я подписан на openssl-announce), чтобы как можно скорее получать уведомления о действительно важных вещах.
Затем я применяю обновления для каждого общедоступного сервера (веб-интерфейсы, балансировщики нагрузки и т. Д.) И каждого поддерживающего сервера (базы данных и т. Д.) Один раз в месяц. Сюда входят любые оставшиеся обновления безопасности и исправления ошибок. Во многих организациях это делается ежеквартально по всем направлениям, но я считаю, что общедоступные веб-сайты, особенно те, которые занимаются электронной коммерцией, не следует оставлять гнить так долго. Я почти всегда делаю это на выходных после вторника патча Microsoft, что почти всегда достаточно времени, чтобы услышать о плохих обновлениях Microsoft (хотя я в основном использую системы Linux, проще иметь один уик-энд, чтобы обновить все).
Наконец, я сажусь, расслабляюсь и жду, чтобы посмотреть, что сломается. Несмотря на все ваши усилия по тестированию обновлений, что-то в конечном итоге пойдет не так. Следите за своей системой мониторинга. Если что-то сломается, что не отслеживается, исправьте это, а затем начните мониторинг. Будьте готовы к откату (yum history undo полезно).
Для очень большой части это зависит.
Очевидно, что обычно лучше всего устанавливать критические обновления безопасности. Как можно скорее, но только вы знаете свою инфраструктуру и платформу. Что такое как можно скорее, зависит от вас. Если вы используете веб-сервер, что-нибудь недавнее, например:
"CESA-2014: 1919 критических обновлений безопасности для CentOS 7 firefox"
для вас не проблема. Не надо спешить. Если вы используете 500 рабочих станций CentOS, эта Erratum действительно может иметь решающее значение, и вы должны выпустить такое обновление без какого-либо или минимального тестирования.
Такое решение должно быть принято в результате оценки воздействия / риска, возможно, с помощью вашего сотрудника службы безопасности.
С другой стороны, для вас риск может быть уменьшен, потому что все рабочие станции вынуждены использовать веб-прокси, который уже блокирует такой вредоносный контент, и 500 высокооплачиваемых пользователей этих рабочих станций, которые не смогут нормально работать утром, могут оказаться недопустимый риск тоже. Тогда как можно скорее означает после тщательного тестирования.
Напротив, часто исправления ошибок не важны и могут подождать, если только ваша среда не страдает от этих ошибок, тогда вы можете решить их как можно скорее.
Это было то, что сервер Red Hat Satellite или проект Spacewalk упростили: для каждой зарегистрированной системы вы можете видеть, какие исправления и обновления применимы, а также наоборот, для каждой ошибки вы видите, сколько систем затронуто. Это намного лучше, чем просто список пакетов, ожидающих возможных обновлений.
В некоторых организациях, в которых я работал, были очень простые приложения, позволяющие автоматически устанавливать исправления на серверах. «Мы верим в Red Hat».
У других было два внутренних выпуска, в которых собирались все исправления, и только очень конкретные, удаленно используемые критические обновления выходили за пределы этого расписания. И один или два, которые были сочтены важными для нашей установки. В непроизводственной среде обновления следует размещать до начала рабочего дня, обязательное тестирование утром, в производственной среде не позднее, чем через 24 часа после выпуска обновления.