Форс-мажорные обстоятельства вроде внезапного отключения электричества в офисном здании или пожара на соседнем этаже, увы, не такая уж и редкость сегодня. Это может привести (и приводит) к сбоям в работе информационных систем, как локальных, так и интегрированных в рамках распределенных ИС и взаимодействующих по телекоммуникационным каналам. И, как известно, форс-мажор - не единственная угроза. Существуют еще и скрытые возможности ИТ-продуктов, вредоносное ПО и множество других рисков, которые могут привести к недоступности ИТ-сервисов корпоративной ИС. В условиях же, когда критичные бизнес-процессы большинства компаний уже давно и плотно завязаны на четкое функционирование ИТ-систем, это может привести к длительным простоям и прямым убыткам. С целью разрешения проблем поддержки непрерывности бизнеса международными институтами выработано множество стандартов, регулярно проводятся конференции. Одно из таких специализированных мероприятий - семинар "Управление непрерывностью бизнеса (BCM). Теория и практика в современных условиях" - недавно было проведено компанией "АйТи".

Стандарты, инциденты и здравый смысл - что общего?

Сергей Петренко, ведущий консультант службы профессионального сервиса "АйТи", обозначил три фактора, определяющие актуальность корпоративных программ управления непрерывностью бизнеса (ECM, Enterprise Continuity Program) и методологии BCM (Business Continuity Management).

На первое место докладчик поставил необходимость выполнения законодательных норм и требований, в том числе стандартов. Существует множество международных институтов, выпускающих стандарты в сфере информационной безопасности - и в том числе в области поддержания непрерывности бизнеса. Кроме наиболее известной международной организации ISO (International Standard Organization), не менее авторитетен, например, американский Национальный институт стандартов и технологий NIST (The National Institute of Standards and Technology). Специализированный британский BCI (Business Continuity Institute) занимается в основном вопросами стандартов в сфере обеспечения непрерывности бизнеса, а другой британский институт, BSI (British Standard Institution), разрабатывает стандарты по более широкому кругу вопросов: информационные технологии, промышленная безопасность, информационная безопасность. Общее количество международных стандартов превышает тысячу документов, даже в головах специалистов порождая порой хаос, отметил Сергей Петренко.

По уровням управления существующая методическая база распределена неравномерно. Порядка 70% имеет отношение к стратегическому уровню управления бизнесом, 20% - к операционному. На тактический уровень, самый близкий к практике, приходится не более 10% методической базы. Таким образом, безопасность и непрерывность тактического уровня управления фактически отдана на откуп вендорам. Поставщики решений выпускают для клиентов специализированные рекомендации, которые, естественно, сделаны под конкретную конфигурацию конкретного производителя, поэтому, когда решения от различных поставщиков начинают работать в гетерогенных информационных средах, возникают проблемы с их взаимной корреляцией.

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

Третье обстоятельство, обуславливающее возрастающий интерес к BCM, - здравый смысл. Большинство корпоративных информационных систем, констатировал Сергей Петренко, по-прежнему строятся по методологии двадцатилетней давности - сначала строим, а потом обеспечиваем отказоустойчивость и живучесть путем дублирования и резервирования. Даже если взять решения ведущих мировых вендоров (Oracle, SAP, EMC, HP, IBM и др.), подчеркнул докладчик, то и у них безопасность, обеспечение непрерывности декларируется на базе двух-трехкратного резервирования. Здравый же смысл подсказывает, что в современном мире, при возросших рисках и угрозах, для устойчивой работы КИС или АСУТП этого уже явно недостаточно. Ведь если первая копия системы уязвима, то и следующие копии уязвимы точно так же. При таком подходе весь контур ИС, включая резервированный, легко может быть выведен из строя.

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

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

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

Практика обеспечения непрерывности ИТ-сервисов: крупный розничный банк

Алексей Евтушенко, ИТ-директор "Хоум Кредит энд Финанс Банка" (ХКФБ), поделился опытом крупного розничного банка в реализации программ поддержки непрерывности бизнеса. ХКФБ, начинавший деятельность на российском рынке десять лет назад как компания, специализировавшаяся исключительно на выдаче потребительских кредитов в магазинах, сегодня является одним из крупнейших розничных банков, работающих на российском банковском рынке (собственный капитал чуть меньше 1 млрд. долл.; по размеру портфеля кредитов, выданных физическим лицам, - 5-е место, по объему депозитов - 30-е; 25% всех кредитов под покупку товара в России выдается ХКФБ; более 1 тыс. офисов и 20 тыс. сотрудников; размер клиентской базы - 26 млн., в том числе 6 млн. - активные клиенты).

Но чем больше бизнес, его клиентская база и чем выше финансовые показатели, тем дороже стоят простои, отметил Алексей Евтушенко. Серьезным аргументом в пользу реализации специальных программ по поддержке непрерывности бизнеса стал именно расчет потерь от простоев, выполненный в банке. Согласно выполненным внутри банка расчетам, в будни один час простоя обходится ХКФБ в сотни тысяч долларов, а одни сутки - в несколько миллионов. Статистика потерь простоев в выходные более скромная, но тоже не радует: десятки тысяч и сотни соответственно (потери были посчитаны намного точнее, но, как пояснил докладчик, из соображений конфиденциальности можно говорить только об их порядке). При этом Алексей Евтушенко подчеркнул, что приводит не теоретические цифры, а действительно расчетные данные, согласованные с финансовой службой банка и всеми заинтересованными подразделениями. И отметил также, что это первое, что нужно сделать, - посчитать цифры, представить их руководству и показать тем самым, во имя чего необходимы инвестиции в программы поддержки непрерывности бизнеса.

Вместе с тем Алексей Евтушенко признал, что первоначальным толчком для российских банков к работе по обеспечению непрерывности бизнеса все-таки стали не экономические расчеты, а нормативные требования регулятора рынка, т. е. Банка России. Еще в 2004 г. ЦБ РФ выпустил стандарт по информационной безопасности СТО/РС БР ИББС (полное название - "Обеспечение информационной безопасности организаций банковской системы Российской Федерации"), который включает несколько стандартов (СТО) и рекомендаций по стандартизации (РС). Стандарты ЦБ стали серьезным аргументом для руководства банка для начала работы в этом направлении, ведь банк, не имеющий утвержденных планов по обеспечению непрерывности своего бизнеса, рискует как минимум попасть на штрафные санкции, как максимум - лишиться лицензии.

Дополнительным аргументом стали данные мировой статистики за последние 15 лет, которые привел в своей презентации Алексей Евтушенко. Характерно, что согласно приведенным им данным (см. таблицу), большая часть реализованных угроз (66%) требует для обеспечения непрерывности бизнеса катастрофоустойчивых решений. Цель обеспечения непрерывности банковского бизнеса, отметил докладчик, с точки зрения лучших практик (ITIL, CoBIT, ISO и др.) можно определить следующим образом: минимизация вероятности и последствий существенных перебоев в предоставлении ИТ-услуг для банковских функций и процессов, быстрое восстановление ИТ-решения в случае сбоев. Основными задачами в русле достижения данной цели являются разработка, поддержка и тестирование планов обеспечения непрерывности предоставления ИТ-услуг в банке, применение адекватных технических решений, специальная подготовка персонала и хранение копий ИТ-решений и данных на сторонних ресурсах. Показателями для оценки результатов деятельности в данном направлении могут служить количество часов, потерянных из-за сбоев в работе ИТ-систем (в месяц), а также число критичных для банка бизнес-процессов, включенных в план обеспечения непрерывности работы банка, относительно к общему количеству бизнес-процессов. Главная же задача ИТ-директора - максимально четко на языке бизнеса сформулировать риски, обсчитать потенциальные угрозы и найти оптимальное решение: каким образом в рамках минимального бюджета и в минимальные сроки максимально уменьшить риски.

На начальном этапе программы обеспечения непрерывности бизнеса в ХКФБ были четко сформулированы риски и обозначены угрозы. В результате проведенной работы выделено пять критических с данной точки зрения ИТ-систем: ядро (система бухгалтерского учета), кредитная система, фронт-офис, клиент-банк и интеграционная шина. На сегодня по этим пяти системам банк находится на третьем уровне обеспечения непрерывности, что означает: доступность систем - 99,99%, допустимое время потери данных в случае сбоев RPO (Recovery Point Objective) - 3 часа, допустимое время простоя сервиса в случае сбоя RTO (Recovery Time Objective) - 24 часа. В ближайших планах банка - переход на более высокий уровень обеспечения непрерывности (сейчас ведется поиск оптимального варианта по соотношению цена/качество).

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

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

О пользе просвещения

"ИТ-решение приобретено, установлено, поддерживается специалистами, и этого достаточно для обеспечения непрерывности бизнеса", - руководство небольших компаний, наверное, еще долго может пребывать в подобном благодушном неведении. Закладки в программах и прочие уязвимости воспринимаются как экзотика, а вероятность срабатывания форс-мажорных факторов оценивается как ничтожная, чисто теоретическая. Но сложность и непредсказуемость современной среды ведения бизнеса, все большая зависимость от корректной и надежной работы ИТ-решений, многообразие и возрастающая сложность ИТ-продуктов - всё это вместе свидетельствует о том, что точка зрения руководства даже небольших компаний будет меняться. А одна из основных миссий ИТ-директора любой компании, помимо умения находить оптимальное решение задач обеспечения доступности ИТ-сервисов по соотношению цена/качество, - просветительская, поскольку понимание руководителем реальности угроз поможет компании избежать реальных убытков.

ТАБЛИЦА. Мировая статистика простоев банков с 1996 г. (по данным МВФ)

Характер угрозы Доля случаев, % Требования с обеспечением непрерывности

Умышленные нападения (теракты) 17 Катастрофоустойчивость/обеспечение непрерывности

Пожары 17 Катастрофоустойчивость/обеспечение непрерывности

Ураганы 14 Катастрофоустойчивость/обеспечение непрерывности

Землетрясения 11 Катастрофоустойчивость/обеспечение непрерывности

Отключение электроэнергии 10 Отказоустойчивость/обеспечение доступности

Выход из строя программ 9 Отказоустойчивость/обеспечение доступности

Наводнения 7 Катастрофоустойчивость/обеспечение непрерывности

Выход из строя техники 5 Отказоустойчивость/обеспечение доступности

Персонал, прочие риски 10 Политика безопасности, борьба с халатностью

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам