С тех пор, как я начал работать там, где я работаю сейчас, я постоянно боролся со своим начальником и коллегами за обновление систем.
Я, конечно, полностью согласен с тем, что любое обновление (будь то прошивка, операционная система или приложение) не следует применять по неосторожности сразу после его выхода, но я также твердо уверен, что должно быть как минимум некоторые причина, если продавец выпустил его; и наиболее распространенной причиной обычно является исправление какой-либо ошибки ... которую, возможно, вы сейчас не испытываете, но вы мог скоро почувствуете, если не успеваете.
Это особенно верно для исправлений безопасности; например, если бы кто-нибудь просто применил патч, который уже был доступен для месяцы, печально известный SQL Slammer червь был бы безвреден.
Я полностью за тестирование и оценку обновлений перед их развертыванием; но я категорически не согласен с подходом к управлению системами "если он не сломан, не трогайте его", и он искренне болит когда я нахожу производственные системы Windows 2003 SP1 или ESX 3.5 Update 2, я могу получить только один ответ: «это работает, мы не хотим его ломать».
Что Вы думаете об этом?
Что ваш политика?
А что есть твоя компания политика, если она не соответствует вашей?
А как насчет обновлений прошивки (BIOS, хранилище и т. Д.)?
А как насчет главного О.С. обновления (пакеты обновлений)?
А как насчет несовершеннолетних О.С. обновления?
А как насчет обновлений приложений?
Мой главный интерес, конечно же, заключается в обновлении серверов, поскольку управление клиентскими исправлениями обычно более прямолинейно, и есть хорошо известные инструменты и лучшие практики для этого.
При определении стратегии установки исправлений необходимо сбалансировать безопасность и гибкость со стабильностью и временем безотказной работы. Ваш ответный подход для этого должен быть примерно таким: «Хорошо, но вы должны знать, что теперь мы рискуем, что эти серверы будут скомпрометированы и наши данные будут украдены или серверы станут нефункциональными» и «Хорошо, но вам нужно знать, что это влияет на поддержку этой системы нашим поставщиком и на возможность взаимодействия этой системы с новыми системами в будущем».
Противодействуя долгосрочному менталитету «не сломался, не обновляй», вы должны прояснить, что:
Надеюсь, это даст вам некоторые рычаги воздействия и удачи в том, чтобы убедить вышестоящих серьезно относиться к делу. Как всегда, установите документальный след, подтверждающий, что вы информировали руководство о рисках, на которые они идут.
Это бесконечные дебаты, и разумные люди не согласятся. Если вы говорите о пользовательских ПК, я согласен, что их нужно обновить. Если вы говорите о серверах, рассмотрите отдельную политику для серверов, выходящих в Интернет, и тех, которые не выходят. Я не знаю о ваших серверах, но в моей среде, возможно, 10% наших серверов имеют порты, открытые для Интернета. Когда дело доходит до исправлений безопасности, эти серверы с выходом в Интернет получают высший приоритет. Серверы, которые не выходят в Интернет, имеют более низкий приоритет.
Гуру безопасности будут утверждать, что такой подход проблематичен, потому что, если хакер когда-либо проникнет в вашу сеть, непропатченные серверы позволят эксплойтам бесполезно распространяться по сети, как лесной пожар, и это разумный аргумент. Тем не менее, если вы держите эти серверы, подключенные к Интернету, жестко заблокированными, и правильно настроите свой брандмауэр, чтобы открывать только те порты, которые абсолютно необходимы, я думаю, что этот подход работает и часто может использоваться для успокоения менеджеров, которые боятся исправлений.
Если вы полагаетесь только на Центр обновления Windows для исправлений (вы не упомянули, какую ОС вы используете, но я в основном парень Windows, поэтому это моя ссылка), взгляните на фактические исправления, которые выпускаются каждый месяц. . У меня есть серверы, на которых, если я запустил Центр обновления Windows, мне скажут, что мне нужно более 50 патчей, но если я пролистаю эти патчи и исследую каждый из них, я обнаружу, что 90% элементов, являющихся патчами, не являются безопасностью. связаны, но исправляют ошибки, влияющие на службы, которые я не использую на этом компьютере. В более крупных средах, где вы используете систему управления исправлениями, обычно проверяют все, что выпускается, и беспокоятся только о том, что абсолютно необходимо, и это обычно составляет около 10% от того, что выпускает Microsoft.
Мой аргумент состоит в том, что эти дебаты о том, «патчить или не патчить» предполагают, что вы должны быть той или иной стороной, хотя на самом деле это огромная серая зона.
Я могу говорить только о серверах, но у нас есть режим «Ежеквартального обновления», в четыре заранее определенных и объявленных даты в год мы группируем запросы на обновления, применяем их к нашей эталонной среде, запускаем их в течение месяца, чтобы проверить стабильность и, в случае хорошего развертывания в течение следующих п дни / недели. Вдобавок к этому мы применяем политику экстренного обновления, в которой у нас есть возможность развернуть в качестве эталона, протестировать и развернуть срочные обновления в течение дня или двух, если серьезность такова, хотя это использовалось только 2/3 раза за последнее время. 4 года или около того.
Такой двойной подход гарантирует, что наши серверы в разумных пределах, но не глупо, обновлены, что обновления осуществляются профильными экспертами (например, прошивкой, драйверами, ОС, персоналом приложений), а не поставщиками, но также позволяет быстро исправлять ошибки, если обязательный. Конечно, нам повезло, что у нас очень мало различных моделей оборудования (<10 вариантов серверов), а также масштабные и актуальные эталонные платформы для тестирования.
Я работал в разных фирмах, у которых были политики на всем протяжении континуума от «применяйте исправления как можно скорее, нас не волнует, сломают ли они что-то, что у нас работает - мы поддержим их тогда» до «ничего не применяется без двух недель тестирования ". Обе крайности (и точки между ними) в порядке пока Компания понимает компромиссы.
Это важный момент: на этот вопрос нет конкретного правильного или неправильного ответа; это вопрос баланса стабильности и безопасности или функций в вашей конкретной среде. Если ваша цепочка управления понимает, что задержка исправлений для тестирования может сделать их более уязвимыми для вредоносных программ, это нормально. Точно так же, если они понимают, что применение исправлений, как только они будут доступны, может не сработать или даже нарушить конфигурацию вашей конкретной системы, это тоже нормально. Проблемы возникают, когда эти компромиссы не понимаются.
Я считаю, что лучший курс в значительной степени находится посередине двух ваших крайностей. например Почему вы так отчаянно хотите обновить ESX, если для этого нет очевидных причин, что может привести к поломке рабочих систем в процессе? Конечно, он мог бы быть уязвим, если бы был открыт для публики, но не должно быть никакого способа получить к нему прямой доступ извне вашей сети, так в чем же риск? Есть ли какие-либо ошибки или отсутствие функций, которые на самом деле представляют вам причина усовершенствовать?
Обновление ради этого, и это действительно то, что вы предлагаете ("но вы мог испытать скоро "), даже утверждая, что это не так, - это абсурдный и опасный путь для путешествия. Если вы не представите актуальный причина, в отличие от некоторой теоретически возможной причины, вы никогда не убедите других, если они против обновления.
Если вы считаете, что есть реальная причина для выполнения обновления, вы должны задокументировать как плюсы, так и минусы, и всегда есть минусы, и сообщить об этом тем, кто находится выше по дереву. Правильно задокументированное сопротивление должно быть небольшим. Если вы не можете предоставить убедительный аргумент, расслабьтесь и серьезно подумайте над этим фактом.
редактировать
Я подумал, что должен прояснить, что вижу огромную разницу между применением необходимых исправлений безопасности и стабильности по сравнению с выполнением обновлений программного обеспечения или ОС. Первый внедряю после должного тестирования. Последнее я делаю только в том случае, если есть реальная выгода.
Обновления безопасности отправляются на промежуточный сервер, а затем в производство после того, как они показали, что ничего не взорвали. Если нет настоящего пискing аварийной ситуации (которую я ударил несколько раз :(), и в этом случае ПРОИЗВОДСТВО СЕЙЧАС. Другие обновления только по мере необходимости, после того, как потратили время на постановку.
Я думаю, что первое, что нужно сделать, это «классифицировать» обновления по серьезности и составить расписание исправлений на основе этой классификации. Нет сомнений в том, что исправления безопасности нулевого дня должны применяться немедленно; тогда как Service Pack может подождать после тщательной оценки.