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

Если вам есть, что рассказать – пишите, еще есть пара свободных слотов.

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

1. Коллеги довольно четко отработали ситуацию со своими клиентами, объяснив суть проблем и вместе приняв решение об управляемом выключении части оборудования.
2. На сайте появилась весьма подробная информация о произошедшем, что позволило избежать ненужных слухов.
3. Наконец, сами последствия аварии были ликвидированы вполне оперативно и профессионально.

Коллегам – респект, тем, кого пока не затронуло – хороший кейс.

На этот раз мне понравилось подавляющее большинство докладов. Хорошо и по делу выступил Николай Пучков из Сити Банка с рассказом о том, как строить оптимальную стратегию непрерывности бизнеса. Виктория Голубева из МегаФона системно прошлась по рискам, связанным с непрерывностью бизнеса.

Очень ярким и запоминающимся получился доклад Антона Жбанкова, человека, широко известного в мире виртуализации, который прошелся по основным «достоинствам» облачных технологий, немного приземлив их на грешную землю

Я в своем докладе постарался  сфокусироваться на основных способах повышения эффективности системы обеспечения непрерывности бизнеса, и вот, что получилось.

Спасибо всем участникам и организаторам за отличное мероприятие!

Из Российского регулирования  в документ попала инструкция Банка России 242-П, но не попал стандарт СТО БС ИББР-1.0-2010, о чем я уже написал автору документа Кстати, 22 июня Банк России официально опубликовал информацию о вводе в действие новых версий документов комплекта БР ИББС.

Кстати,

Из наиболее ярких изменений – 13-кратный рост количества сбоев в части коммуникаций (в результате чего была достигнута беспрецедентная доля в 17%), 2-кратный рост проблем, связанных с энергоснабжением, и 6-кратный рост проблем, связанных с доступом в помещения.

Итак, немного истории. То извержение вулкана, после которого начались серьезные перебои с авиасообщением, случилось 14 апреля.  Утром 15 апреля начали закрываться европейские аэропорты (историю развития событий можно освежить в памяти здесь). Через какое-то время люди начали понимать, что помимо неожиданно исчезнувшего  способа перемещаться в пространстве, они начали  сталкиваться с такими проблемами, как задержки грузов, и т.п.

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

1. Признали наличие проблемы, ее серьезность, и подтвердили, что занимаются снижением последствий путем перестройки логистических цепочек.
2. Обозначили локализацию проблемы – отправки в, из и внутри Европы.
3. Проинформировали, что сбор отправлений по прежнему продолжается.
4. Четко обозначили, что гарантийные обязательства UPS не распространяются на ситуации, вызванные подобными чрезвычайными обстоятельствами – неприятно, но честно.

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

1. Трезво оценивать ситуацию.
2. Управлять ситуацией и предпринимать шаги для уменьшения негативных последствий происшедшего.
3. Говорить правду.

По мере изменения ситуации, компания также держала своих клиентов в курсе, и, на момент публикации данного сообщения, утверждала, что все в порядке.

P.S. Тема данного поста была осознанно ограничена только вопросами коммуникации во время чрезвычайной ситуации, чтобы не мешать все в одну кучу.

Часть 1. Резервные копии

Что происходит с резервными копиями после того, как вы их сделали? Существует несколько вариантов – носитель лежит под замком в том же офисе,  носитель регулярно выносится за пределы помещения, либо отчуждаемого носителя как такового нет, потому что резервное копирование делается на СХД внешнего провайдера, либо на СХД на другой площадке организации, т.н. cross-site backup. В большинстве случае, надо исходить из того,  что уровень защиты этих данных на «периметре» практически нулевой.  Чтобы не быть голословным – несколько заметных примеров хищения лент с резервными копиями.

Итак, правило №1 – обязательное шифрование резервных копий, предназначенных для хранения на отчуждаемых носителях.

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

1. Ключи должны храниться отдельно от самих резервных копий
2. Ключи не должны быть бесконтрольно доступны людям, имеющим физический доступ к резервным копиям, в противном случае все данные могут легко покинуть организацию в обход любых DLP-систем, а обнаружить факт такой утечки будет крайне сложно.
3. Паранойя должна быть под контролем. В час X ключи должны оказаться доступны на той площадке, на которой будет выполняться восстановление данных, и время их доставки туда не должно [существенно] увеличивать целевое время восстановления RTO.
4. ЧС любого масштаба (в разумных пределах, естественно), затрагивающая основную площадку, не должна приводить к безвозвратной потере ключей шифрования.

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

Часть 2. Средства шифрования.

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

1. При шифровании данных всегда делайте резервные копии ключевой информации, и храните их в надежном месте, вдали от основной площадки. Схемы, в которых нельзя сделать резервную копию ключа для шифрования данных (или, как вариант, мастер-ключа), вам не подходят. Это замечание относится к сценарию, когда вам надо впоследствии расшифровывать данные с использованием  своего закрытого ключа. Для сценария, например, подписи платежных поручений, потеря ключа приведет к некоторому простою, но не приведет к потере информации.
2. Убедитесь (опытным путем) в том, что вы знаете, как восстановить всю необходимую ключевую информацию из резервных копий
3. Кроме собственно ключевой информации, важно иметь дистрибутивы/серийные номера/лицензии для используемых программных средств шифрования данных.
4. При использовании ЭЦП – разработайте четкий регламент, как в случае утери ключевой информации вы будете восстанавливать ключи. Как правило, в этих регламентах нет ничего сложного, важно только, чтобы вы смогли выполнить эти действия в разумные сроки. Иногда, впрочем, технически вполне реально сделать копии контейнера с ключами, и если потеря ключей не привела к их компрометации, то можно просто восстановить их из резервной копии.
5. Для аппаратных решений типа HSM – прислушайтесь к рекомендациям производителя по резервированию.

Очевидно, сегодня мы рассмотрели не весь спектр проблем, но даже следование этим рекомендациям поможет вам избежать ряда проблем, связанных с обеспечением сохранности информации.

С декабря прошлого года линейка SunGard CMS заметно расширилась, и про все решения  в комплексе мы  еще ни разу не рассказывали.

Из новых решений речь пройдет про три  продукта, дополнивших BIA Professional:

• Risk Assessment
• Vendor Assessment
• Work Force Assesment

Кроме того, будет рассказано и про функциональность, появившуюся в новых версиях продуктов LDRPS и BIA Professional.

Как всегда, Вебинар проходит на русском языке и абсолютно бесплатен

Update 1: Запись Вебинара доступна здесь.

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

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

Сценариев ЧС, при которых может понадобиться экстренное восстановление рабочих мест, несколько.

1. Самый простой сценарий – сотрудники целы, офис цел, но сотрудники не могут попасть в офис. Например, в городе случился теракт и метро не работает.  Или наводнение. Или эпидемия.
2. Более сложный сценарий – люди целы, а вот офис – не совсем.  Если ИТ-инфраструктура и связь сохранилась, то задача сводится к п.1. Если же офис [частично] разрушен/обесточен/аппаратура конфискована, но – есть резервный ЦОД, задача тоже имеет решение.
3. Совсем тяжелый случай – когда часть людей по тем или иным причинам не может выполнять свои функции или участвовать в восстановительных работах. Это может быть вызвано как непосредственно проблемами (болезнь, повреждения или даже смерть), так и проблемами родных и близких, которые требуют неотложного участия.

Итак, как же быть?

На самом деле, задача (на верхнем уровне) сводится к двум подзадачам:

1. Тем, кто есть – дать возможность работать либо удаленно, либо на рабочих местах других сотрудников [в других,  не попавших под воздействие ЧС офисах].
2. Тех, кто не может выполнять свои функции – заменить другими, либо перераспределить их обязанности между теми, кто остался «в строю».

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

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

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

Ну и наконец, планирование и учения – пока переход на альтернативные способы работы не будет четко спланирован и протестирован, вряд ли вы сможете полагаться на это в критических ситуациях.