Андрей Смирнов
Время чтения: ~13 мин.
Просмотров: 0

Обновление и модернизация информационных систем

Материал данной статьи основан на опыте установки более 5 000 обновлений для продуктов Microsoft и Adobe.Patch Management – это процесс управления обновлениями программного обеспечения (ПО), без которого вряд ли обходится хоть одна современная компания, думающая о безопасности своей ИТ-инфраструктуры.Обновления или патчи — это дополнительное программное средство, которое применяется для исправления обнаруженных дефектов в программном обеспечении или изменения его функционала. Существуют 2 типа обновлений:

  1. для операционных систем и серверного ПО, которые применяются для поддержки надлежащего уровня безопасности и устранения дыр в защите;
  2. для прикладного ПО (например, Microsoft Office, Adobe Acrobat или клиентские части бизнес-приложений), которые необходимы для решения возникших проблем с часто используемыми или важными библиотеками и другими частями исходного кода.

Помимо прочего очевидна важность обновлений и их своевременной установки для поддержания надлежащего уровня информационной безопасности. Однако в истории были печально известные случаи, когда «заплатки» уязвимостей одного приложения вызывали критические неисправности в других приложениях. Вот несколько таких примеров:

  1. Ежемесячное обновление Microsoft вызвало сбои в работе VMWare (8 февраля 2011 года);
  2. Обновление для браузера Internet Explorer, выпущенное Microsoft, содержало сразу две уязвимости: сбой в работе браузера, а так же переполнение буфера, которое позволяет хакеру с помощью специального сайта запускать на уязвимой машине код с привилегиями пользователя браузера (8 августа 2006 года);
  3. Декабрьские обновления от Microsoft были предназначены для исправления серьезной бреши безопасности в применении шрифта OpenType. Обновление затрагивало пользователей PowerPoint, Quark Xpress and Coreldraw. Выпущенные обновления не позволяли программам распознавать символы шрифта OpenType размером больше 15 пикселей (12 декабря 2012 года);
  4. Установка обновлений Microsoft для драйверов режима ядра (kernel mode drivers) привела к появлению синего экрана смерти (BSOD) на компьютерах пользователей в августе 2014;
  5. Обновление для офисного приложения PowerPoint 2013 привело к невозможности запуска приложения (10 февраля 2015 года).

Подобные неприятные последствия применения обновлений приводили к простоям бизнеса и потере денег, и этот риск никуда не делся. Однако неприятностей можно было бы избежать при помощи тщательного тестирования обновлений компанией-разработчиком перед их развёртыванием. Компания Microsoft не раз сталкивалась с критикой в свой адрес по поводу недостаточного тестирования ежемесячных обновлений безопасности. В ответ на это представители корпорации дали понять, что в их планах переход на новую схему тестирования путем передачи услуги по тестированию обновлений «внешним» пользователям, то есть не сотрудникам Microsoft. И, действительно, если взглянуть на данную проблему глазами компании-разработчика, то становится понятно, что тестирование обновлений на стороне разработчика довольно емкий по времени процесс. Каждое обновление должно быть протестировано в условиях максимально приближенных к тем, которые эксплуатируются на рабочих станциях и серверах потребителей продукта. Так, к примеру, компания Adobe тратит на тестирование обновлений (updates) до 6000 человеко-часов в месяц. Но как показывает жизнь, тестирования компанией разработчиком никогда не будет достаточно для 100% пользователей в мире. Соответственно, риск того, что очередное обновление ПО остановит бизнес-процессы компании, остаётся. С другой стороны, не обновляться также нельзя, так как можно оказаться уязвимыми перед хакерами, которые могут нанести вред компании. В качестве способа существенного снижения этих рисков крупные компании выбирают регулярную установку обновлений пакетами (релизами) с обязательным тестированием обновлений перед их развёртыванием в масштабе всей компании.Методы управления обновлениями Метод управления обновлениями является комбинацией подхода к тестированию обновлений и подхода к развёртыванию релизов с обновлениями. О них мы и расскажем далее. Два самых распространенных подхода к тестированию обновлений — это:

  1. тестирование на локальных виртуальных машинах;
  2. тестирование в полноценной тестовой среде.

Современные технологии позволяют без задействования лишних единиц техники проводить тестирование обновлений, используя виртуализацию. Наиболее часто используемые и доступные продукты для создания виртуальных машин и сетей: VMware либо Oracle VirtualBox. Преимущества виртуализации в том, что:

  • создание самой виртуальной машины не требует больших затрат по времени;
  • виртуальных машин на одной физической платформе может быть несколько;
  • каждая виртуальная машина имеет свои собственные виртуальные аппаратные компоненты: память, процессор, жесткий диск, сетевые адаптеры;
  • и самое главное – это возможность сделать «снимок» текущего состояния системы и содержимого дисков одним кликом мыши, а затем в течение очень короткого промежутка времени вернуться в исходное состояние, что может быть очень полезным при условии обнаружения обновления, установка которого вызывает критические неисправности в системе.

Как правило, технология виртуализации используется для небольших сетей с количеством рабочих станций не более 45-70. Также процесс управления изменениями можно упростить, используя всего пару корпоративных компьютеров или, так называемых, тестовых клиентов. Установив необходимые обновления на такие клиенты и протестировав систему после установки, можно увидеть последствия изменений и убедиться в результате применения обновления, оказывая при этом минимальное влияние на ИТ-инфраструктуру. Тестирование с использованием полноценной тестовой среды применимо для больших промышленных сетей и гарантирует высокую чистоту тестирования. При тестировании в полноценной тестовой среде используются те же подходы к установке обновлений и инструменты для управления обновлениями, что и в промышленной среде. И сейчас мы перейдём к ним и заодно рассмотрим подходы к развёртыванию релизов с обновлениями.Инструменты для управления обновлениями Как правило, все широко используемые программные решения для удаленного управления ИТ-инфраструктурой предоставляют возможность управления обновлениями, например:

  1. System Center Configuration Manager (SCCM) – программный продукт Microsoft;
  2. Unicenter Software Delivery – программный продукт компании Computer Associates;
  3. OpenView – программный продукт компании Hewlett-Packard.

Лидером по востребованности и использованию в условиях крупных промышленных сетей является SCCM. Поэтому приведём подробности реализации управления обновлениями на его примере. Принцип управления обновлениями с помощью Configuration Manager достаточно прост. Все управляемые системы SCCM объединяются в сайты. Сайты содержат в себе:

  • серверы сайта;
  • системы сайта, выполняющие определенные роли по управлению инфраструктурой;
  • собственно управляемые клиенты.

Каждый из серверов сайта должен иметь доступ к базе данных Microsoft SQL Server. В качестве сервера обновлений используется Windows Server Update Services (WSUS).Он синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Это экономит внешний трафик компании и позволяет быстрее устанавливать исправления ошибок и уязвимостей в операционных системах Windows на рабочих местах, а также централизованно управлять обновлениями серверов и рабочих станций.be8ebec423634d5e9c5fbebb5501e7d4.jpg Здесь следует особо отметить, что сервер WSUS предназначен только для обновлений, выпущенных компанией Microsoft. Однако существует еще один сервер обновлений – System Center Updates Publisher (SCUP) от Microsoft, который позволяет управлять обновлениями стороннего ПО и затем импортировать его на сервер WSUS, с последующим развертыванием на клиентах с помощью SCCM.Стадии процесса Patch Management07112c1f5f16409f9db6cff7f3495203.jpg Процесс управления обновлениями состоит из нескольких стадий:

  1. Создание листов обновлений После того как тестовая среда подготовлена к установке новых обновлений, начинается создание листов обновлений, или, как это называется в SCCM, патч-листов. Патч-лист включает обновления, вышедшие в этом месяце и подходящие под определение «требуемые». Необходимость в обновлении для клиента определяет сам SCCM. Логика проста: если на клиенте установлено приложение Visio и в этом месяце вышло обновление для Visio, то подобный патч будет «требуемым» для данного клиента. Что же касается обновлений для операционных систем и серверов, то здесь необходимость определяется в зависимости от их разрядности и пакета Windows Service Pack. После того, как патч-лист создан, формируется новый пакет, включающий в себя все выбранные обновления, и пакет назначается на коллекцию, в которую добавлены тестовые клиенты.
  2. Развертывание на пилотных пользователях (стадия PRE Deployment) На этапе PRE Deployment готовится список протестированнных обновлений, который отправляется с помощью SCCM на клиенты пилотных пользователей. Принцип тот же: пакет с обновлениями добавляется к коллекции, включающей в себя только пилотных клиентов, SCCM получает информацию о том, что для клиентов данной коллекции назначено новое задание и начинается развертывание. Как правило, в качестве пилотных клиентов, выбираются те пользователи, которые хорошо разбираются в ПО, за которое отвечают, и проверяют нормально ли работает приложение после установки обновлений. Количество пользователей, которые участвуют в пилоте, обычно варьируется в зависимости от числа рабочих станций сети. Стадия PRE Deployment продолжается в течение 4-х дней, по истечении которых пилотные пользователи дают свою обратную связь (feedback). При возникновении конфликтов ПО с установленными обновлениями, последние исключаются из списка. Таким образом, формируется окончательный список обновлений, которые будут установлены на все рабочие станции промышленной сети.
  3. Развертывание протестированных обновлений в производственной информационной среде (PRO Deployment) Происходит на стадии PRO Deployment, с помощью SCCM, по тому же принципу, что и на тестовые и пилотные клиенты. В данном случае устанавливается время начала развертывания и дата завершения.

Шаги тестирования Как уже упоминалось ранее, тестирование происходит на основании тест-матрицы. Ниже мы представим описание базовых проверок, которые обычно включаются в такие матрицы.Тестирование установки. Установка обновлений на тестовый клиент инициируется SCCM. Как правило, после установки обновлений система требует перезагрузки. Соответственно, первая проверка: перезагрузить систему, войти в систему после перезагрузки под тестовой учетной записью, убедиться в отсутствии сообщений об ошибках/предупреждений системы. Следующий шаг – проверка системной переменной PATH. Убеждаемся в том, что PATH не содержит символов и знаков, которые могут привести к проблемам. Третий шаг – проверка журнала системных событий (Event Viewer). Информация об установке обновлений пишется в журнал под ID 19. Проверка позволяет убедиться в успешности установки всех обновлений и отсутствии ошибок. Далее на очереди проверка офисных приложений. Проверкой Office, как правило, пересекаются все тест-матрицы процесса Patch Management. Простые примеры проверок Office:

  1. Запустить Word, Excel, Power Point, Publisher, Access.
  2. Убедиться, что приложения открываются без возникновения ошибок.
  3. Внести изменения в документ, убедиться, что при закрытии появляется вопрос о сохранении и сохранение документа происходит по умолчанию в папку «Документы» (если не предусмотрено другое хранилище по умолчанию (by default)).

Данный пример проверки Office является базовым и общим. Матрица может включать в себя и более сложные детальные проверки. Например, кроме открытия MS Word и сохранения документа нужно проверить, что во вкладке «Орфография и грамматика» проставлена галочка «Проверка Орфографии и Грамматики» и т.д. 2c17581a0b9d492e828ed54c4c46d3b1.jpg Одной из наиболее распространенных проверок так же является проверка приложений Adobe, которые подвергаются обновлению. Минимальная проверка для Adobe Flash Player заключается в проверке версии данного ПО на сайте. Если же обновление для Adobe Reader, то проверяется версия и производится проверка работоспособности приложения.Проверка работоспособности браузера также в ходит в список базовых. Патчи не должны вносить изменения в настройки прокси и ActiveX, и это также проверяется при тестировании. Кроме того стоит обратить внимание на общее влияние обновлений на систему. На этапе подготовки тестового клиента, который уже содержит ранее протестированные обновления, проводятся тесты, описанные выше, и результаты такого тестирования принимаются за эталон. Любое отклонение системы от состояния, предшествующего вновь установленным патчам, анализируется и, в некоторых случаях, может быть принято решение об исключении патчей, ведущих к нежелательным изменениям в системе. Стоит заметить, что для экономии полезного времени, некоторые проверки могут быть автоматизированы с помощью VBScript, например:

  1. создание объектов офисных приложений, открытие файлов программ, внесение изменений, сохранение;
  2. запуск браузера и переход на веб-страницы;
  3. выгрузка логов Event Viewer в таблицу «Excel».

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

Проводите ли вы тестирование регулярного обновления ПО?

  • 33,3%Да, тестируем
  • 36,3%Нет, не тестируем
  • 29,4%У нас нет процесса по управлению патчами
  • 1,0%Другое (написать в комментариях)

Проголосовали 102 пользователя. Воздержались 23 пользователя.

insupdate-5b-e1579449984735.jpg

Инструкция по управлению обновлениями программного обеспечения.

1. Общие положения

1.1 Настоящая инструкция устанавливает порядок и правила создания, изменения, блокировки обновлений программного обеспечения (ПО) в информационных системах (ИС) организации.

1.2 Требования настоящей инструкции распространяются на сотрудников Управления Информационных Технологий (УИТ) организации.

1.3 Контроль исполнения требований данной инструкции возлагается на администратора информационной безопасности (АИБ).

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

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

2. Комплекс требований

2.1 Уязвимости безопасности ПО сторонних производителей должны устраняться обновлениями (патчами) безопасности этих производителя не позднее 30 дней со дня их выхода.

2.2 АИБ должен информировать системных администраторов о новых обновлениях безопасности. Информацию о них он должен получать из следующих источников, но не ограничиваясь (возможно использование дополнительных источников информации).

2.3 Ежемесячно АИБ (или заменяющим его лицом) осуществляется сканирование программного обеспечения на предмет выявления неустановленных обновлений. Отчет о сканировании должен включаться в ежемесячный отчет о состоянии информационной безопасности.

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

2.5 На новые средства вычислительной техники перед вводом их в рабочую среду ИС должны устанавливаться все необходимые обновления безопасности на всё установленное ПО.

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

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

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

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

2.10 С целью минимизации рисков возможной несовместимости установленного обновления с установленным программным обеспечением, необходимо:

  • протестировать обновления на определенной заранее группе персональных компьютеров и серверов:
  • в течении 3-5 рабочих дней произвести мониторинг с целью выявления возможной несовместимости установленного обновления безопасности ПО.

3. Ответственность

3.1 Виновные в нарушении условий настоящей Инструкции несут ответственность в соответствии с законодательством Российской Федерации, трудовым договором, должностной инструкцией.

4. Заключительные положения

4.1 Общий текущий контроль исполнения настоящей инструкции осуществляет АИБ.

4.2 АИБ поддерживает настоящую инструкцию в актуальном состоянии.

4.3 Изменения и дополнения в настоящую инструкцию утверждаются директором организации.

4.4 Инструкция вступает в силу с момента утверждения директором организации.

download_doc.png

Скачать ZIP файл (16127)

Пригодились документы — поставь «лайк»:

5+

Модернизация иобновление системы

Своевременное выполнение обновлений поможет избежать следующих негативных последствий:

  • развитие информационной системы под требования бизнеса только за счет собственных разработок;
  • увеличение количества собственных разработок приводит только к установке нот и обновлений, устраняющих ошибки и необходимых для выполнения требований изменения законодательства. Со временем установка таких обновления становится все более трудоемкой;
  • увеличение стоимости поддержки информационных систем;
  • завершение поддержки производителей устаревших баз данных и операционных систем;
  • снижение общего уровня безопасности системы.
  • Обследование. На этом этапе определяется уровень обновлений системы, подключение дополнительных функциональных возможностей. Проводится сбор информации об объеме внедрения бизнес-процессов, операций по ним и определяется объем тестирования. Также осуществляется анализ объема, модифицированного ПО и собственных разработок.
  • Подготовка плана перехода. Производится подготовка тестовой системы (копия продуктивной), ее обновление, анализ и корректировка затронутого модифицированного ПО; тестирование работы системы, регистрация и решение проблем; создание перечня мероприятий для перехода. Затем проводится повторное разворачивание тестовой системы, ее обновление, тестирование и применение плана мероприятий. Производится планирование сроков этапов перехода, оценка рисков и возможность дополнительных мероприятий по их снижению. В итоге определяется период неработоспособности продуктивной системы, разрабатывается и утверждается документ «План перехода»
  • Выполнение плана перехода. Заключается в последовательном выполнении мероприятий, описанных в документе «План перехода».
  • Поддержка пользователей. После переноса обновлений в продуктивную систему заказчика осуществляется оперативная поддержка пользователей и решение оставшихся проблем.

Миграция Процесс миграции систем включает в себя следующие этапы:

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

Следующая лекцияИспользуемые источники:

  • https://habr.com/company/icl_services/blog/251575/
  • https://compnote.ru/otdelit/instruktsiya-po-upravleniyu-obnovleniyami/
  • https://webnvpks.github.io/files/vnedrenie_i_podderzhka_kompyuternyh_sistem/lectures/osnovnye_metody_vnedreniya_i_analiza_funkcionirovaniya_programmnogo_obespecheniya6.html

Рейтинг автора
5
Подборку подготовил
Максим Уваров
Наш эксперт
Написано статей
171
Ссылка на основную публикацию
Похожие публикации