Главная Security, Без рубрики, Новое Security, Update, Windows 7
  • Обеспечение своевременной установки обновлений в рабочих группах

    2398697_f520 Решая проблемы безопасности вычислительной системы, приходится учитывать целый комплекс проблем, одна из которых – своевременное обновление операционных систем и программного обеспечения.

    • SCCM SUP. Журнал WUAHandler.log

      TroubleОписание журнала WUAHandler.log в TechNet весьма краткое «Содержит информацию о том, когда Windows Update Agent ищет обновления программного обеспечения на клиентах».

      Предлагаю вам более полное описание.

      • Развертывание и использование WSUS сервера

        WSUS Установка обновлений и патчей является очень важной составной частью обеспечения безопасности. Для всех специалистов по информационной безопасности основной необходимостью является мониторинг, анализ и устранение уязвимостей программного обеспечения. Компания Microsoft предоставляет бесплатную возможность использования сервиса обновлений своих программных продуктов в течение всего времени поддержки программного продукта. Необходимые обновления доступны через сеть интернет всем пользователям программных продуктов.

      • Главная Security, Windows, Без рубрики, Новое Security, Update, Windows 7, Конкурс
        • Почему важно обновлять Windows и установленные в ней программы

          image006 Это вторая статья из цикла «Безопасность в Windows, не прилагая усилий». В первой статье мы разобрались с тем, где спрятаны рекомендации Microsoft, поговорили о роли кнопки «Да» в обеспечении безопасности системы и определили преимущества лицензионного  программного обеспечения. Данный материал целиком посвящен одной из самых важных тем безопасной работы в Windows – своевременному обновлению операционной системы и приложений, которые в ней установлены.

        • Главная System Center, Новое SCCM, Update
          • Установка SCCM SP1 на Windows Server 2003 без проблем.

            updatesB ожидании Service Pack 2 для System Center Configuration Manager 2007, можно в очередной раз развернуть его в тестовой среде (а может и в промышленной). Наверняка все, кто хоть раз сам устанавливал SCCM на Windows Server 2003 замечал нужную и полезную вещь – Prerequisite Checker. Запустив его перед установкой SCCM можно заранее узнать, насколько ваш сервер подходит для установки. Что более приятно, если сервер не соответствует необходимым требованиям – вы получите сообщение об этом. Сообщение будет либо предупреждением, после которого можно продолжить установку, либо ошибкой, которую нельзя игнорировать. И, конечно же, аналогично предупреждениям, есть два типа администраторов: те, кто игнорирует все предупреждения, и те, кто обязан добиться идеальных условий. Для второго  типа администраторов и предназначен этот пост.

          • Главная System Center, Новое SCCM, Update, WSUS
            • Удаление обновлений

              • Рубрика: System Center,Новое
              • Автор: Алексей Тараненко
              • Дата: Sunday 26 Apr 2009

              editdelete Обновления программного обеспечения один из краеугольных камней компьютерной безопасности. Очень важно правильно подходить к процессу управления обновлениями. К сожалению, иногда установка того или иного обновления может приводить к ошибкам в работе системы или в работе сторонних программ. Если это произошло, необходимо удалить обновление вызывающее ошибку. При удалении обновлений очень важно соблюдать правильную последовательность. При откате обновления, обновленные файлы заменяются на архивные копии. Таким образом, мы можем нарушить работоспособность системы, если проведем удаление обновлений в неправильном порядке.

              Пример:

              Update1 (KB 100001) – обновляет файл targed.dll с версии 5.25 до версии 5.77. Файл targed.dll (5.25) будет сохранен в %systemdrive%\Windows\$NTUninstallKB100001$\

              Update2 (KB100002) – обновляет файл targed.dll (5.77) до targed.dll (6.0), оригинальный файл сохраняется в архиве. Также это обновление обновляет файл bad.dll с версии 0.1 до версии .02

              Update3 (KB100003) – обновляет файл targed.dll с версии 6.0 до версии 6.5.

              Допустим, мы выяснили, что обновленный файл bad.dll (0.2) вызывает ошибки в работе бизнес-приложения. При этом bad.dll(0.1) таких ошибок не вызывал. Мы принимаем решение об откате обновления Update2, чтобы восстановить нормальную работу. Но при этом удаление обновления update2 вызовет замену рабочего файла targed.dll (6.5) на архивную версию targed.dll(5.77). Соответственно мы потеряем изменения сделанные обновлением Update3. Естественно такая ситуация может вызвать трудно диагностируемые сбои в работе системы.

              Подробнее в статье «Removing Windows software updates in the wrong order may cause the operating system to stop functioning»

              Поэтому в данной ситуации правильным будет следующий сценарий:

              · удаление обновления Update3;

              · удаление обновления Update2;

              · установка обновления Update3.

              Для того чтобы узнать какие файлы исправляет обновление, или какие версии обновлений оно заменяет, обратитесь к описанию обновления на сайте Microsoft

              Например: http://www.microsoft.com/technet/security/Bulletin/MS08-065.mspx

              System Center Configuration Manager не может самостоятельно удалять обновления. Для удаления обновлений вы можете воспользоваться одним из вариантов:

              1)ручное удаление обновление с каждого компьютера, через оснастку «Установка и удаление программ» – имеет смысл, если проблемных компьютеров один-два;

              clip_image002

              Рисунок 1 Установка и удаление программ – действия на обновлениями

              2)удаление обновления через WSUS. Для этого в консоли администрирования WSUS найдите необходимое обновление и одобрите его для удаления

              clip_image004

              Рисунок 2 Одобрение для удаления обновления во WSUS

              3)Использование программы установки обновлений. Для удаления обновления запустите %systemdrive%\Windows\$NTUninstallKBnumber$\spuninst\spuninst.exe

              Подробнее: http://support.microsoft.com/default.aspx/kb/832475/ru

              Если у вас проблемное обновление установлено на несколько компьютеров, то проблем с его поиском и удалением быть не должно. Как быть если обновление установлено на несколько десятков или даже сотен компьютеров? Использовать SCCM для удаления обновления.

              Для начала давайте определимся со списком компьютеров, на которых установлено это обновление. Список компьютеров с установленным обновлением вы можете получить через отчет: Software Updates – A. Compliance – Compliance 9 – Computers in a specific compliance state for an update

              Отчет это очень красиво, но он не поможет нам удалить обновления. Для удаления обновления создадим коллекцию UninstallUpdate. На странице правил членства в коллекции выбираем «Query rule». Задаем имя правила и нажимаем кнопку «Edit Query Statement».

              clip_image005

              Рисунок 3 Создание запроса членства компьютеров

              В появившемся окне выбираем «Attribute class – Add\Remove programs» и «Attribute – Display Name»

              clip_image006

              Рисунок 4 Указание, что выборка производится из установленных программ

              Теперь нажимаем кнопку «Value».

              clip_image007

              Рисунок 5 Задание удаляемой программы

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

              clip_image008

              Рисунок 6 Список установленных программ в сайте

              Несколько нажатий кнопок OK и мы получаем сформированный критерий членства в коллекции.

              clip_image009

              Рисунок 7 Критерий членства в коллекции

              Хочу заметить, что вы можете создавать несколько критериев одновременно. Равно как и искать обновления с помощью подстановочных знаков. Например, запись вида %KB95% сформирует вам коллекцию из машин, на которых установлено любое из обновлений, номер статьи которого начинается с 95.

              clip_image010

              Рисунок 8 Итоговое окно

              После создания коллекции – распространяем на нее через Software Distribution скрипт, который удалит наши обновления. В данном случае скриптом будет обычный bat-файл, в который будет последовательно удалять обновления с помощью spuninst.exe.

              Помните, что правильную последовательность удаления обновлений вы должны задать самостоятельно!

              Алексей Тараненко

              MCP/MCTS: SCCM 2007

              altaranenco@gmail.com

            • Главная System Center, Новое SCCM, Update, WSUS
              • Управление обновлениями в System Center Configuration Manager 2007 (Часть 3)

                • Рубрика: System Center,Новое
                • Автор: Алексей Тараненко
                • Дата: Sunday 19 Apr 2009

                Green_Atom В предыдущих статья мы поговорили об общем подходе к управлению обновлениями и о механизме взаимодействия Windows Software Update Services (WSUS) и System Center Configuration Manager (SCCM). Пришла пора рассказать о том, «как и какие кнопки нажимать» в Configuration Manager  для распространения обновлений.

              • Главная System Center, Новое SCCM, Update, WSUS
                • Управление обновлениями в System Center Configuration Manager 2007 (Часть 2)

                  • Рубрика: System Center,Новое
                  • Автор: Алексей Тараненко
                  • Дата: Monday 13 Apr 2009

                  AlienAqua windows update В первой части статьи я постарался рассказать о процессе управления обновлениями. Пора переходить к практике. В это статье я постараюсь описать механизм  взаимодействия Windows Software Update Services и Configuration Manager 2007.

                  Для работы с обновлениями корпорация Microosft предлагает бесплатное решение Windows Software Update Services (WSUS). На момент написания статьи последней актуальной версией был WSUS 3 SP1.

                  WSUS полностью самодостаточное решение, которое может удовлетворить потребности большинства организаций. Помимо прочего WSUS поддерживает иерархические отношений, таким образом можно централизованно управлять обновлениями, как в главном офисе, так и на филиалах.
                  Развертывание и использование WSUS на предприятии очень хорошо описано и в официальной документации? и во многих статьях в интернете, поэтому я не буду заострять на нем внимание, а сразу же перейду к рассмотрению взаимодействия WSUS и Software Update в System Center Configuration Manager (SCCM).

                  Подробнее о WSUS можно узнать:

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

                  Для работы с обновлениями в SCCM нам необходимо:

                  • • WSUS сервер, собственно обновления с сайта Microsoft Update закачивает именно он;
                    • Software Update Point – роль Configuration Manager’а;
                    • свободное дисковое пространство под обновления (в зависимости от количества обновляемых продуктов).

                  Теперь о каждом пункте поподробнее.

                  WSUS сервер – отвечает за синхронизацию обновлений в вашей локальной базе с базой на серверах Microsoft Updates. Кроме этого именно с сервером WSUS клиенты сверяют необходимый список обновлений.
                  Software Update Point  – роль SCCM, отвечающая за то, какие именно обновления будут загружены с сайтов Microsoft, за передачу обновлений на клиенты и их запуск на установку.
                  Дисковое пространство – Microsoft рекомендует использовать как минимум 20Гб том для обновлений. Размер тома будет очень сильно зависеть от количества обновляемых продуктов. Так, обновления безопасности Windows  XP, Vista, Server 2003, Server 2008 (All x32)  занимают у меня порядка 4Гб. Однако SCCM дублирует все обновления, закаченные WSUS. Таким образом, нам нужно резервировать  двухкратное место на диске. Файлы обновлений будут храниться как в базе WSUS, так и в базе SCCM.

                  Основная ошибка людей, которые только начинают работать с обновлениями через SCCM, это попытка использования консоли администрирования WSUS для каких либо действий. Главное что следует запомнить: либо мы используем для установки обновлений WSUS и тогда любые действия по управлению обновлениями мы осуществляем через консоль WSUS и соответственно напрочь забываем о существовании SCCM, либо мы используем SCCM, и тогда консоль администрирования WSUS после установки мы не трогаем вообще никогда.

                  Общие моменты мы вроде бы прояснили. Давайте рассмотрим два самых распространенных сценария:
                  1) у нас никогда не стояло никакой системы обновлений, мы решили установить SCCM;
                  2) у нас успешно использовался WSUS, но мы хотим расширить его функционал за счет SCCM.

                  Сценарий 1 – чистая установка

                  Воспользуйтесь пошаговым руководством по установке WSUS и установите базовый сервер WSUS. При этом Microsoft рекомендует не проводить настройку свежеустановленного WSUS сервера – поскольку его настройки все равно будут затерты настройками из SCCM. Однако, я все предпочитают провести первоначальную синхронизацию WSUS с серверами Microsoft. Но только синхронизацию! Таким образом, мы можем удостовериться, что установка WSUS прошла успешно, что настройки связи не препятствуют работе механизма обновлений. Следует отметить, что если в вашей организации применяется прокси-сервер производства не Microsoft (например Squid), то при определенных сценариях, у вас могут возникнут проблемы с аутентификацией WSUS-сервера на вашем прокси-сервере. Во WSUS такую проблему можно решить, установкой галочки «Разрешить обычную проверку подлинности (пароль передается открытым текстом)». В SCCM произвести такую аутентификацию невозможно, поэтому вам придется изменить настройки прокси-сервера так, чтобы он пропускал запросы от сервера WSUS+SUP SCCM без аутентификации.

                  В SQUID это можно сделать, внеся в конфигурационный файл следующую запись:

                  acl wsus scr ip_adress_wsus_server

                  http_access allow wsus

                  Очень важно! Не одобряйте для установки обновления, ни настраивайте групповую политику, не предпринимайте никаких действий по настройке WSUS окружения, кроме установки сервера и первоначальной синхронизации. Иначе вы  рискуете получить нерабочее решение, ошибки в работе которого будет очень сложно отследить. SCCM для настройки использует локальную политику компьютеров, настраиваемую агентом SCCM автоматически.  Поэтому все упоминания о WSUS из групповой политики (Group Policy) необходимо удалить.

                  Сценарий 2 – модернизация уже работающего WSUS сервера

                  Если у вас уже существует WSUS инфраструктура, и вы просто решили ее расширить за счет SCCM, то выполните следующие действия:

                  • • снимите все выставленные вами одобрения для обновлений;
                    • удалите из групповой политики все настройки WSUS.

                  Если вы используете иерархическую структуру WSUS, и возможности центрального сервера будут расширены за счет установки Configuration Manager, убедитесь что все зависимые сервера WSUS, переведены из режима «реплики» в режим  «синхронизации с Microsoft Update». Иначе после снятия одобрений на центральном сервере, эти настройки будут переданы на подчиненные сервера.

                  Теперь оба наших сценария приведены к общему знаменателю – у нас есть рабочий, не настроенный сервер WSUS. Пора расширить его возможности за счет установки Software Update Point SCCM.

                  Установка Software Update Point

                  Запустите консоль SCCM. Выберите:
                  Site Management – Site Code – Site Settings – Site Systems – New Server или Server-New Role
                  в зависимости от того, установлен WSUS сервер на сервер SCCM или находится на отдельном сервере.

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

                  Введите короткое и FQDN имя сервера. Если установка производится на отдельный сервер, и при этом учетная запись сервера SCCM не внесена на WSUS-сервере в группу локальных администраторов, то укажите учетную запись для установки «Use another account for install this site system».

                  capture_04132009_161414 Рисунок 1 Выбор сервера для установки роли

                  Указываем для установки роль “Software update point

                  capture_04132009_161425 Рисунок 2 Выбор роли Software Update Point (SUP)

                  Задаем используемые порты. Должны быть выбраны порты,  указанные при установке WSUS сервера.

                  capture_04132009_161529 Рисунок 3 Используемые порты WSUS

                  Выбираем иерархию. Поскольку наш сервер, высший в локальной иерархии, – указываем синхронизацию с серверами Microsoft. Так же указываем, будут ли наши клиенты посылать оповещения на WSUS сервер. Я обычно ставлю пересылку всех событий “Create all wsus reporting events”. Хотя "отчеты в SCCM даюn более полное представление о судьбе обновлений, иногда бывает полезным получить эту же информации из консоли WSUS.

                  capture_04132009_161537 Рисунок 4 Выбор иерархии обновлений

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

                  capture_04132009_161549 Рисунок 5 Расписание синхронизации

                  Выбираем необходимые нам типы обновлений. Подробнее о классификации обновлений.

                  Критические обновления: Указывает на широко распространяемое обновление для решения отдельной проблемы, связанной с критической ошибкой, не касающейся вопросов безопасности.
                  Обновления определений: Указывает на обновление, связанное с вирусными или иными файлами определения.
                  Драйверы: Указывает на обновление компонентов программного обеспечения, разработанного для поддержки аппаратных ресурсов.
                  Пакеты дополнительных компонентов: Указывает на дополнительные компоненты новых продуктов, которые распространяются вне данной версии продукта и, как правило, включаются в следующую полную версию продукта.
                  Обновления для системы безопасности: Указывает на широко распространяемое обновление для проблемы в конкретном продукте, касающейся вопросов безопасности.
                  Пакеты обновления: Указывает на накопительный пакет исправлений, применимых к приложению. Эти исправления могут включать обновления для систем безопасности, критические обновления, обновления программного обеспечения и т.д.
                  Средства: Указывает на программу или функцию, помогающую выполнять одну или несколько задач.
                  Накопительные пакеты обновления: Указывает на накопительный пакет исправлений, упакованных вместе для упрощения развертывания. Эти исправления могут включать обновления для систем безопасности, критические обновления, обновления и т.д. Накопительный пакет обновлений обычно относится к определенной области, например, к системам безопасности или к компоненту продукта.
                  Обновления: Указывает на обновление приложения или файла, установленного в настоящий момент.

                  capture_04132009_161557 Рисунок 6 Выбор загружаемых классов обновлений

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

                  capture_04132009_161611 Рисунок 7 Выбор обновляемых продуктов

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

                  capture_04132009_161621 Рисунок 8 Выбор языка обновлений

                  Проверяем страницу summary, Next-Finish.

                  capture_04132009_161628 Рисунок 9 Итоговая страница

                  После этого проверяем настройки агента
                  Site Management – Site Code – Site Settings-Client Afents – Software Updates Client Agents
                  Главное для нас это галочка «Enable software updates on clients”, и интервал сканирования.

                  capture_04132009_164707 Рисунок 10 Настройки агента SCCM

                  На этом настройку Software update point можно считать законченной. Следует дождаться синхронизации с серверами обновлений Microsoft и после этого назначать обновления для клиентов.
                  Кстати, рекомендую настроить  в WSUS отправку оповещений о новых обновлениях на e-mail. В консоли WSUs выбираем Параметры – Уведомления на e-mail
                  В следующей статье я расскажу, о том, как работать с обновлениями, назначать их на коллекции, а пока рассмотрим механизм взаимодействия WSUS и SCCM.

                  Механизм взаимодействия WSUS-SCCM

                  За загрузку обновлений отвечает WSUS. Именно он связывается с серверами Microsoft, производит закачку необходимых файлов в папку WSUSContent. Именно из этой папки обновления будут скопированы в каталоги распространения (Deployment Packeg) SCCM. Следует отметить, что если одно и тоже обновление будет входить в несколько таких пакетов, то физически оно будет скопировано один раз, в остальных папках будет храниться ссылка на него.  Именно файлы обновлений из папок Deployment Packeg будут передаваться на клиентов.

                  схема обновлений Рисунок 11 Схема взаимодействия WSUS и SCCM

                  В SCCM, в отличии от WSUS, нет возможности автоматического ободрения обновлений. Процесс распространения обновлений должен происходить под руководством системного администратора (описанию процесса управления обновлениями посвящена первая статья). Администратор, просматривает новые обновления, выносит свое решение о необходимости применения тех или иных обновлений, и в ручную добавляет их к пакетам распространения.

                  Установка обновлений происходит примерно по следующему сценарию:

                  • • получение информации об  обновления на сервере WSUS и передача это информации в базу SCCM;
                    • одобрение, загрузка и назначение на установку Администратором;
                    • информирование пользователя о выходе обновления;
                    • период, когда пользователь может установить или не установить обновление по своему выбору;
                    • обязательная установка обновления, по наступлению времени принудительной установки(deadline).

                  Два последних пункта могут отсутствовать, в зависимости от настроек распространения обновления.

                  И так,  что делает WSUS:

                  • • получает обновления от сайтов Microsoft Update;
                    • по запросу клиента проводит выдачу информации о применимых к клиенту обновлениях;
                    • запускает и устанавливает полученные от агента SCCM файлы обновлений.

                  Что  делает SCCM:

                  • • запускает процесс синхронизации WSUS с серверами Windows Update в интернете, при этом определяет какие классы обновлений и для каких продуктов необходимы;
                    • предоставляет Администратору возможность управлять обновлениями: загрузка, одобрение, расписание установки;
                    • запускает процесс синхронизации клиентского компьютера с базой WSUS, таким образом мы получаем сведения о необходимых для клиента обновлениях;
                    • передает файлы обновлений на клиентские компьютеры, в зависимости от настроек распространения обновления (по запросу\принудительно);
                    • запускает Update Agent на клиентских машинах для установки обновлений;
                    • строит все отчеты относящиеся к Software Update (необходимые обновления, процесс установки, отчет об установке).

                  Заключение

                  Механизм взаимодействия WSUS и Configuration Manager почти не описана ни в документации, ни в статьях. Данная статья выжимка личного опыта, книг и статей об SCCM и дискуссий на форумах. Надеюсь, что она поможет вам лучше ориентироваться в процессах, происходящих при работе с обновлениями в SCCM. В следующей статье я наконец расскажу о том, как одобрять обновления для клиентов, устанавливать и удалять обновления, работать с отчетами.

                  Алексей Тараненко

                  MCP/MCTS: SCCM 2007

                  altaranenco@gmail.com

                • Главная System Center, Новое SCCM, Update, WSUS
                  • Управление обновлениями в System Center Configuration Manager 2007 (Часть 1)

                    • Рубрика: System Center,Новое
                    • Автор: Алексей Тараненко
                    • Дата: Tuesday 07 Apr 2009

                    appwiz.cpl_I05e3_0409 Кажется, о необходимости обновления не говорил только ленивый. Удручающей стала ситуация с массовыми вирусными эпидемиями, которые использовали уязвимости, уже давно закрытые соответствующими обновлениями. Не смотря на все это, многие системные администраторы просто не понимают важность своевременных обновлений и уж тем более не умеют управлять процессом обновлений. И если о необходимости обновлений говориться во многих статья по безопасности, и на многих форумах, то процесс управления обновлениями почему-то остается обделен вниманием. В этой статье я постараюсь восполнить данный пробел.

                    В первой части статьи мы с вами рассмотрим непосредственно процесс управления обновлениями. Этот процесс одинаков для любых систем. Во второй части мы рассмотрим механизм взаимодействия Windows Software Update Services и System Center Configuration Manager, а также управление распостранением обновлений в Configuration Manager 2007.

                    Я постараюсь  своими словами описать процесс управления исправлениями рекомендованный компаний Microsoft. Мой рассказ будет базироваться на Microsoft Operations Framework 4.0 (MOF) и Microsoft Solutions for Managment 2.5 (MSM).

                    Подробнее о процессе изменения вы можете узнать, ознакомившись со следующими документами:
                    Microsoft Solutions for Managment 2.5 (
                    http://www.microsoft.com/technet/itsolutions/msf/ )
                    Microsoft Operations Framework 4.0 (
                    http://technet.microsoft.com/en-us/library/cc506049.aspx)
                    Введение в MOF на русском (
                    http://www.itsmonline.ru/itsm/dictionary/mof.php)

                    Процесс управления обновлениями (исправлениями), который рекомендует применять Microsoft, был представлен в Microsoft Solutions for Managment 2.5 и основан на функциях управления MOF-службами:

                    • • Change Management (управление изменениями);
                      • Release Management (управление выпуском);
                      • Configuration Management (управление конфигурацией).

                    Данный процесс основан на моделях MOF и состоит из 4х стадий управления обновлениями ПО:

                    • • оценки (Assess);
                      • идентификации (identify);
                      • оценки и планирования (evaluatr & plan);
                      • развертывания (deploy).

                    mofРисунок 1. 4 стадии процесса управления изменениями

                    Процесс начинается со стадии оценки. Событием, вызывающим переход на стадию идентификации, является уведомление о том, что появилось новое обновление. Событием, вызывающим переход к оценке и планированию, является подача формального запроса на изменение (Request for change – RFC). Получение ободрение на развертывание обновления ПО в промышленной среде вызывает переход на стадию развертывание. Завершение выпуска обновления ПО и начало нового циклического процесса вызывает переход на стадию оценки.

                    Мы с вами будем рассматривать централизованное управление только для обновлений от компании Microsoft. Процесс управления обновлениями программного обеспечения других производителей принципиально ничем не отличается. Как не отличается и способ установки обновлений: централизованно или вручную.

                    Предварительная подготовка к управлению исправлениями

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

                    Для начала нам необходимо определиться с тем, какие компьютеры мы будем обновлять. Например, необходимо ли обновлять компьютеры, которые предназначены для списания или которые выведены в резерв и лежат на складе? Необходимо составить реестр ПО, для которого необходимы исправления. Если у нас не используется BizTalk сервер, то, соответственно, обновления для него должны быть исключены из процесса управления обновлениями.

                    Большинство необходимых данных мы можем получить с помощью SCCM, но, как и говорил – технические подробности будут в следующей части статьи.

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

                    Почему важно знать именно все программы установленные на компьютерах? Иногда, редко, но все же случаются ситуации, когда обновление какого-нибудь компонента ОС или другой программы нарушало нормальную работу третьих программ. И такие моменты очень трудно отследить.

                    Для всех компьютеров мы проверяем саму возможность установки исправлений. В нашем случае это будет развернутая инфраструктура WSUS+SCCM. С другой стороны это может быть просто и возможность ручной установки обновлений.

                    Задача создания хорошо функционирующей системы обновлений является одной из самых сложных. Поскольку ошибки при проектировании этой структуры в дальнейшем могут вызвать не только необходимость ее переделки, но и неправильное применение обновлений, и как следствие возможную неработоспособность обновляемых компьютеров. При развертывании системы управления обновлениями, желательно предварительно максимально привести все системы к некоему базовому показателю. Например, если в вашей организации никогда раньше не устанавливались обновления, то желательно провести предварительную установку пакетов обновлений (service pack). Это позволит вам более-менее «выровнять» требования к необходимым обновления, а кроме того покажет узкие места. Например, установка Windows XP SP3 покажет, использовались ли у вас нелицензионные копии программ, а установка Windows Server 2003 SP2, на некоторых серверах вызывала проблемы с сетевыми картами.

                    структура обновлений

                    Рисунок 2. Инфраструктура обновлений

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

                    Четырех фазный подход к управлению обновлениями

                    Напомню, что процесс управления обновлениями ПО состоит из 4х стадий:

                    • • оценки (Assess);
                      • идентификации (identify);
                      • оценки и планирования (evaluatr & plan);
                      • развертывания (deploy).

                    Внутри каждой стадии можно выделить этапы, которые характеризуют процесс управления исправлениями:

                    Оценка(assess) – во многом схожа со стадией оценки выполняемой при подготовке к запуску процесса управления обновлениями.

                    • • Инвентаризация/обнаружение существующих вычислительных активов

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

                    • • Оценка угрозы безопасности и уязвимости

                    Важно помнить, что применяя то или иное обновление, которое устраняет уязвимость, всегда будет существовать шанс, что это изменение принесет с собой новую «дыру». Это может быть изменение каких-либо настроек, на настройки по умолчанию, или действительно проблема в безопасности. Поэтому всегда тестируйте обновления перед применением. И никогда не ставьте обновления «просто так». Если обновление не требуется для вашей организации – не ставьте его. Чем больше новых не обязательных обновлений вы устанавливаете – тем больше поверхность атаки на ваши компьютеры.

                    • • Определение наилучшего источника информации о новых обновлениях ПО

                    Определитесь с источниками информации об обновлениях и угрозах безопасности. Это могут быть различные сайты посвященные проблемам информационной безопасности, либо рассылка от производителя ПО. Например для Microsoft это может быть сайт http://technet.microsoft.com/ru-ru/security/default.aspx

                    • • Оценка существующей инфраструктуры распространения обновлений

                    Со временем ваша организация может изменять свою структуру. Структура системы обновления так же должна претерпевать изменения.

                    • • Оценка эффективности работы

                    Работа вашей команды так же должна изменяться со временем. Вы должны периодически проводить переоценку своих сил и знаний.

                    Идентификация(Identify) – стадия, на который вы стараетесь получить максимум информации о выпушенном обновлении.

                    • • Обнаружение обновлений ПО надежным способом

                    Используйте только доверенные источники для получения информации об обновлении. Отчет о новых обновлениях правильно настроенного сервера WSUS– это доверенный источник, а письмо с адреса security@microsoftupdate.com с прикрепленным файлом обновления – нет.

                    • • Определение применимости данного обновления к вашему ПО

                    Определитесь, нужно вам это обновление. Далеко не каждое обновление обязательно для установки в промышленной среде. Например, не нужно устанавливать обновление, которое исправляет какие-либо дополнительные функции, которыми вы сейчас не пользуетесь, поскольку при этом вы рискуете работой бизнес-приложений. И пусть этот риск мал, но он есть. Кроме того, вы повышаете плоскость атаки на вашу Ит-структуру.

                    • • Получение и проверка исходных файлов обновлений

                    Ни при каких случаях не пользуйтесь недоверенными источниками обновлений. Да, сервер вашего регионального провайдера – это недоверенный источник. Доверенным источником обновления может быть только производитель обновления. Для обновлений Microsoft это сайт update.microsoft.com. И даже при использовании доверенных источников обновления – всегда проверяйте происхождение файла. Это можно сделать, например, проверив цифровые подписи файла.

                    • • Определение характера обновления и задача запроса на изменение

                    Для каждого обновления можно определить его критичность и область применения. С классификацией компании Microsoft можно ознакомиться по следующей ссылке. Команда, управляющая изменениями, должна принимать во внимание серьезность обновления, а так же структуру сети. И вот почему это важно делать: допустим, выпушено некое критическое обновление – исправляющее уязвимость которую использует червь для рассылки спама через 25 порт. Казалось бы, это очень важное исправление и его необходимо установить немедленно. Но если в вашей организации используются персональные и корпоративные фаерволы, которые запрещают трафик через 25 порт для всех компьютеров, кроме почтового сервера (а этот сервер построен на другой ОС, которая не подвержена данной угрозе), то конкретно для вас это исправление превращается из критического просто в необходимое. Соответственно его можно установить во время штатной установки обновлений, а не немедленно.

                    Оценка и планирование (Evaluate & Plan) – после того как вами получена и обработана информация о новом обновлении, вы должны решить – применимо оно к вам или нет. Если вы готовы применить обновление, то вы переходите на стадию «Оценки и планирования»

                    • • Планирование реагирования

                    Когда вы принимаете решение о применимости того или иного обновления, вы должны рассмотреть какие ИТ-системы затронет это обновление, насколько критичными для вас они являются. Должны определиться временные рамки установки обновления на защищаемые системы.

                    Приоритет

                    Рекомендуется, в течение

                    Максимально допустимый

                    Критический 24 часов Неделя
                    Высокий Неделя Месяц
                    Средний Месяц Полгода
                    Низкий Полгода В течение года, или при выходе очередного пакета исправлений, либо не внедряйте

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

                    • • Планирование выпуска обновлений

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

                    • • Создание выпуска

                    Как только выпуск подготовлен, создан график внедрения, вы можете приступить к созданию пакета выпуска. Форма выпуска будет сильно зависеть от используемой системы обновлений. В случае SCCM это будут пакеты и задания на установку обновлений.

                    • • Проведение приемо-сдаточных испытаний

                    После подготовки пакета исправлений, вы должны применить его на тестовой среде, чтобы убедиться, что обновления устанавливаются именно так, как вы задумали. Возможно, в вашей организации нет возможности выделить тестовую среду, идентичную вашей реальной ИТ-структуре. Тогда вы можете провести эксперимент над «белыми мышами» – выделите часть не критичных компьютеров вашей организации и тестируйте пакет обновления на них. Однако помните, что такой подход создает серьезную угрозу нормальной работе таких пользователей.

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

                    • Подготовка развертывания

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

                    • Развертывание обновления ПО на целевых компьютерах

                    Этот шаг почти полностью зависит от системы управления обновлениями. Вы начитаете процесс установки обновлений на ваших компьютерах, а затем отслеживаете процесс развертывания и при необходимости производите восстановление или корректировку работоспособности. Важно постоянно следить за работой критических компонентов ИТ-инфраструктуры в процессе обновления. Если что-то пойдет не так, вы должны узнать об этом первым. Возможно, проблема будет только на одном или нескольких серверах – и тогда вы можете ее исправить, если же проблема проявляется на большинстве компьютеров, это означает что вы на этапе планирования обновления не учли какой-либо фактор. Вам нужно будет прервать процесс развертывания и вернуться к планированию, для проверки исходных данных. Возможно откат придется провести и в случае полностью успешного релиза обновления, из-за того что какая-либо программа начнет конфликтовать с этим обновлением.

                    • Анализ результатов внедрения

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

                     

                    Сегодня я постарался описать процесс управления обновлениями. К сожалению его нельзя упростить до одного абзаца, слишком много проблем может принести вам неправильная схема работы. Данная статья ни в коем случае не может быть инструкцией к применению. Если вы решите взять ее за шаблон – очень важно подогнать ее под свои потребности.
                    В следующей статье я расскажу о том, как управлять обновлениями в Configuration Manager, а так же о том, как SCCM взаимодействует с WSUS.

                    При подготовке статьи использовались:

                    1. Steven D. Kaczmarek – Administrator’s Companion SCCM 2007
                    2. Microsoft System Management Server 2003 – Качмарек С.Д. – пер. с англ. Microsoft Corporations

                    Алексей Тараненко

                    MCP/MCTS: SCCM 2007

                    altaranenco@gmail.com