УПРАВЛЕНИЕ РИСКАМИ  ПОТЕРИ ДОСТУПНОСТИ  ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КРИТИЧЕСКИХ  ИНФОРМАЦИОННЫХ СИСТЕМ

*113079*

УДК 004.056.53

УПРаВЛЕНИЕ РИСКАМИ ПОТЕРИ ДОСТУПНОСТИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ КРИТИЧЕСКИХ

ИНФОРМАЦИОННЫХ СИСТЕМ

С.А. Арустамов, М.Г. Генин

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

Ключевые слова: информационные системы, резервирование, доступность, риск потери доступности, обновление, метод декомпозиции, простое обновление.

Введение

В работе рассматриваются риски потери доступности программного обеспечения (ПО), не связанные с вмешательством злоумышленников, на примере критических информационных систем (КИС). Будем называть информационные системы критическими, если они имеют жесткие требования по ресурсной доступности [1]. Под доступностью в этой работе мы будем понимать возможность системы выполнять заявленные функции их легальными пользователями. Риск потери доступности определим как пару, состоящую из вероятности наступления того или иного события, приведшего к потере доступности, и ущерба от наступления этого события:

R_i={P_i, I_i},

где R_i– риск наступления i-го события; P_i– вероятность i-го события; I_i– ущерб от i-го события. Ущерб от i-го события I_i, в свою очередь, может быть представлен в виде составляющих:

I_i={i_ij}, j={1, 2, …, N},

где i_ij– j-я составляющая ущерба. Такими составляющими могут быть как прямой финансовый ущерб, так и другие виды ущерба, наступившие в результате потери клиентов, уменьшения доли контролируемого рынка, штрафа со стороны надзорных органов, отзыва лицензии и т.д.

Объекты рисков потери доступности

Для дальнейшего рассмотрения рисков потери доступности и их влияния на работоспособность системы представим всю систему в виде составляющих, к которым могут применяться риски потери доступности. Будем рассматривать систему как состоящую из статической и динамической частей. К статистической части (СЧ) будем относить то, что воспринимается как «черный ящик», который в случае неполадок можно легко заменить в любой момент без существенного ущерба для работы (каналы связи, сетевое оборудование, серверы, дисковые массивы и т.д.).

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

Как правило [2], вопросы обеспечения доступности ПО, связываются с применением методов резервирования оборудования, ПО и данных. Рассмотрим возможности и ограничения применения традиционного резервирования для снижения риска потери доступности КИС.

Резервирование как метод снижения рисков потери доступности и области его

использования

Для СЧ систем существуют способы добиться такого уровня резервирования, когда система автоматически переключается на работу с резервными ресурсами полностью прозрачно для бизнес-пользователей. Это достигается как на уровне каналов связи [3], когда выполняется автоматическое переключение на резервный канал при потере доступности основного, так и на уровне серверного оборудования [4, 5], когда вместо основного сервера начинает использоваться резервный, будь то сервер приложений или сервер БД.

Что касается возможности и целесообразности использования резервирования для снижения риска потери доступности ДЧ, то здесь ситуация более сложная. Рассмотрим некоторые случаи возможных потерь доступности данных и ПО ДЧ.

Наиболее вероятная причина потери доступности данных – это их физическое повреждение, вызванное аппаратными сбоями. Как показано выше, такая проблема решается наличием так называемого «горячего» резерва оборудования. Более сложный случай – это логическое повреждение данных. В этом случае наличие «горячего» резерва может оказаться недостаточным, так как на «горячей» копии произошли те же самые изменения. Потребуется возврат к состоянию данных до сбоя путем восстановления данных из так называемого «холодного» резерва. При этом данные, введенные после создания последней «холодной» копии, будут утеряны.

В табл. 1 приведена информация об описанных выше типах сбоя данных с точки зрения возможности восстановления работоспособности системы с помощью резервирования.

Виды сбоя данных

Решение

Степень потери

доступности

Возможный ущерб

Физическое повреждение

данных

Наличие «горячей» резервной

копии

С незначительными потерями

Минимальный

Логическое повреждение

данных (пример: удаление

небольшого количества

записей из таблицы, удаление небольшой таблицы)

Возврат к

Состоянию до сбоя на текущей версии БД,

частичное восстановление

данных из резервной копии

С частичными

потерями

Минимальный – Средний

Серьезное логическое

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

некорректное изменение структуры при обновлении)

Полное восстановление из

резервной копии

С существенной

потерей

Средний–существенный

Таблица 1. Возможности снижения риска потери доступности путем резервирования (данные)

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

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

В табл. 2 приведена информация об описанных выше типах сбоя ПО с точки зрения возможности восстановления работоспособности системы с помощью резервирования.

Виды сбоя ПО	Решение	Степень потери доступности	Возможный ущерб
Сбой ПО без повреждения данных	Замена оборудования с ПО (текущая версия), замена оборудования с возвратом к предыдущей версии после обновления ПО (возможен, если не менялась структура БД)	С незначительными потерями	Минимальный
Сбой после обновления ПО при измененной во время обновления структуре БД	Возврат к предыдущей версии ПО с частичной потерей данных, введенных после изменения их структуры и обновления ПО (возможен при отсутствии внешних ограничений на структуру данных)	С частичными потерями	Минимальный–средний
Сбой после обновления ПО при измененной во время обновления структуре БД в случае невозможности использовать старое ПО и данные старой структуры (внешние ограничения)	Отсутствует	С полной потерей	Максимальный

Таблица 2. Возможности снижения риска потери доступности путем резервирования (ПО)

Сведем результаты анализа в единую таблицу.

	Без потерь	С частичными потерями	С полной потерей
Аппаратная часть	Возможно
БД	Возможно при физическом повреждении и при наличии «горячего» резерва. Сводится к резерву на уровне аппаратной части. Ущерб: минимальный	Возможно при логическом повреждении. Возврат к предыдущему состоянию на текущей версии БД, частичное/полное восстановление из резервной копии. Ущерб: минимальный–средний	Только при отсутствии резерва. Ущерб: максимальный
ПО	Возможно при сбое без повреждения данных и без изменения их структуры. Возврат к предыдущей версии ПО. Ущерб: минимальный	Возможно при измененной во время обновления ПО структуре БД и при отсутствии внешних ограничений. Возврат к предыдущей версии ПО и структуре БД. Ущерб: средний-существенный	При измененной во время обновления структуре БД в случае невозможности использовать БД старой структуры (внешние ограничения). Возврат к предыдущей версии ПО и БД невозможен. Ущерб: максимальный

Таблица 3. Возможности снижения риска потери доступности путем резервирования

Как видно из табл. 3 (нижний правый угол таблицы), наиболее рискованной с точки зрения возможностей резервирования является ситуация, когда при обновлении ПО одновременно меняется и структура БД, причем возврат к предыдущей версии ПО и БД невозможен из-за внешних ограничений (рис. 1). В этой ситуации резервирование не поможет в принципе, на каком бы уровне оно ни было организовано.

Рис. 1. Ситуация, при которой резервирование не работает

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

Метод декомпозиции функциональных обновлений

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

Вторая по уровню сложности ситуация – это одновременное обновление ПО и структуры БД, но с возможностью возврата к предыдущей конфигурации. Здесь резервирование применимо, но объем необходимого восстановления будет наибольшим.

Наиболее сложный случай – это одновременное выполнение обновления версии ПО и структуры БД при невозможности возврата к предыдущей версии ПО и БД из-за внешних ограничений. В этом случае резервирование не поможет, а ущерб при этом будет наибольшим. Для снижения риска потери доступности в данном, самом сложном случае, предлагается использовать метод декомпозиции. Суть его в том, чтобы свести наиболее рискованную ситуацию к нескольким, но менее рискованным, т.е. разбить планируемое сложное обновление на несколько с тем, чтобы при одном таком простом обновлении менять либо только структуру БД, либо только ПО (рис. 2).

Рис. 2. Разбиение одного общего обновления ПО и БД на несколько отдельных (либо только ПО,

либо только БД)

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

Покажем, что применение метода декомпозиции для такого рода обновлений снижает риски потери доступности. Для этого перейдем к формализации описанной методики. Обозначим U^DB⁺^SW все полное сложное обновление, включающее в себя обновление ПО и структуры БД, u^DB_i и u^SW_i – простые i-е обновления БД и ПО соответственно. Тогда можно записать:

, (1)

где N – четное.

При этом

Можно перейти от этой нотации к более простой. Отметим, что в (1) все нечетные обновления являются обновлениями БД, а четные – обновлениями ПО. Обозначим

где N – четное.

Тогда формула (1) приобретает следующий упрощенный и обобщенный вид:

(2)

Разложение обновления на составляющие в виде (2) полностью[1] соответствует определению полного обновления U как суммы простых обновлений u_i, которое было введено в [5]. Действительно,

1. в определенный момент времени устанавливается только одно обновление u_i,

2. после успешной установки каждого обновления u_i система работоспособна,

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

Поэтому, в соответствии с [6], мы можем сделать вывод о том, что вероятность успешной установки полного обновления U в формуле (2), выполненного методом декомпозиции, будет выше, чем при выполнении всего обновления U сразу. Так как формула (1) является частным случаем формулы (2), то данный вывод справедлив и для исходного разложения U^DB⁺^SWна составляющие u^DB_iиu^SW_i_.Так как возможный ущерб от ошибок и их последующего исправления при выполнении простых обновлений u^DB_iилиu^SW_i_. будет либо минимальным, либо средним, то мы можем сделать вывод о том, что полное обновление U, выполненное методом декомпозиции, менее рискованно, чем выполненное единовременно, когда ущерб может быть максимальным.

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

Тестирование предложенной методики

Проверка предложенной методики проводилась на базе инфраструктуры финансового-кредитного учреждения (ФКУ) с головным отделением в Санкт-Петербурге и филиалом в Москве. В каждом из офисов было созданы тестовые среды, на которых была развернута система дистанционного банковского обслуживания (система «Банк-Клиент», далее БК).

С помощью системы БК удаленным клиентам предоставляется возможность обмена документами с ФКУ двумя способами: в режиме веб-доступа (онлайн-клиенты) или с помощью приложения с БД на стороне клиента с доступом в ФКУ по модему, либо через интернет (оффлайн-клиенты). В ФКУ система состояла из веб-сервера для подключения онлайн-клиентов, транспортной станции для подключения оффлайн-клиентов, общего сервера базы данных (БД) и сервера обмена данными с приложениями ФКУ.

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

При единовременной установке предполагалось одновременное обновление клиентской платформы и платформы ФКУ. Для обновления оффлайн-клиентов новая версия приложения была предварительно разослана клиентам.

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

В табл. 4 приведены данные об ошибках, возникших во время установки обновлений на тестовые платформы в офисах Санкт-Петербурга и Москвы.

Время

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

Всего ошибок

Из них привели

Максимальное время полной

недоступности системы

к частичной

недоступности

к полной

недоступности

Тестовая

среда 1,

единовременная установка

(офис в Санкт-Петербурге)

1 день

Устранены за

15 мин

Устранена за

48 часов

Тестовая

среда 2,

поэтапная

установка

(офис в Москве)

8 дней

Устранены за

15 мин

–

Таблица 4. Данные о потере доступности системы при установке обновлений

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

Заключение

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

Литература

1. Арустамов С.А., Генин М.Г. Минимизация рисков потери доступности программного обеспечения после установки обновлений или изменения функциональности // Научно-технический вестник СПбГУ ИТМО. - Санкт-Петербург: СПбГУ ИТМО, 2011. - Вып. 3 (73) май-июнь 2011. - С. 111-116. - 153 с.

2. Резервное копирование как неотъемлемый элемент обеспечения ИБ. Информационная безопасность [Электронный ресурс] – Режим доступа: http://www.itsec.ru/articles2/control/rezervnoe-kopirovanie-kak-neotemlemyi-element-obespecheniya-ib, свободный. Яз. рус. (дата обращения 26.03.2012).

3. Резервирование сетевых соединений в критически важных приложениях. Network Systems Group [Электронный ресурс]. – Режим доступа: http://www.nsg.ru/doc/whitepapers/wp_nsg_dualuplink.pdf, свободный. Яз. рус. (дата обращения 26.03.2012).

4. High availability. That works. Vision solutions [Электронный ресурс]. – Режим доступа: http://www.visionsolutions.com/Products/High-Availability-Overview.aspx, свободный. Яз. англ. (дата обращения 26.03.2012).

5. Check Point High Availability for IP Appliances. CheckPoint [Электронный ресурс]. – Режим доступа: http://www.checkpoint.com/products/ip-appliances/check-point-high-availability.html, свободный. Яз. англ. (дата обращения 26.03.2012).

6. Генин М.Г. Методика проведения обновлений, снижающая риски доступности информационных ресурсов. Информатика, моделирование, автоматизация проектирования // Сборник научных трудов под ред. Н.Н. Войта. – Ульяновск :УлГТУ, 2011. – С. 125–137.

[1] Запрет на возврат к предыдущему состоянию системы для последнего простого обновления u_N в (2) обусловлен исключительно внешними ограничениями и не является свойством самого обновления u_N. Технически возврат системы от u_Nк u_N_–₁возможен, однако при этом требуемая функциональность будет недоступна.