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

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

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

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

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

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

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

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

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

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

Вебинар на русском, бесплатно, докладчик – я

Регистрация на Вебинар здесь.

В программе Вебинара:

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

Вебинар пройдет в абсолютно комфортное время – 22:00 по Москве, когда никакие рабочие дела не помешают вам насладиться общением с Дороном

Ссылка для регистрации тут.

До конца 1 квартала Continuity Software (а в России и СНГ – Алмитек) предлагает специальные условия лицензирования для той части ИТ-инфраструктуры, которая обеспечивает высокую доступность, т.е. на локальные кластеры. На эти лицензии до конца Q1 предлагается скидка 50%. Кроме того, по прежнему действует акция по пилотному сканированию с обучением на родине продукта – в Израиле.

Мы тоже решили не отставать, и в первом квартале запустили акцию, направленную на то, чтобы те из вас, кто отвечает за непрерывность ИТ-сервисов, начали год с внешнего [инструментального] аудита своих HA/DR решений, чтобы получить дополнительную информацию о том, что необходимо сделать в текущем году, где есть проблемы, о которых вы, возможно, не подозреваете, а где есть возможности для повышения эффектвности, или даже снижения затрат. В качестве инструмента для проведения аудита было выбрано решение RecoverGuard нашего партнера Continuity Software.

А в качестве бонуса тем, кто начнет свой год с повышения отказоустойчивости своей инфраструктуры достанется поездка в Израиль - короткий курс по принципам работы системы в учебном центре Continuity Software в Тель-Авиве, reference visit в одну из компаний-пользователей RecoverGuard, ну и возможность немного отдохнуть и поплавать под ласковым израильским солнцем – март-апрель самое подходящее время для визита в эту страну.

Более подробную информацию о нашей акции можно посмотреть здесь.

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

VMware High Availability (HA)

VMware HA позволяет в случае выхода из строя одного из серверов кластера ESX перезапустить все гостевые машины на оставшихся серверах. Решение является аналогом Active-Passive кластера из мира «железных» серверов, за исключением того, что не возникает проблем расхождения конфигураций, которая серьезно осложняет жизнь администраторов, обслуживающих большой парк серверов. Незначительным недостатком данного решения является определенное, хотя и небольшое, время восстановления (RTO), необходимое на перезапуск вирутальной машины.

 VMware Fault Tolerance (FT)

VMware FT отчасти напоминает Active-Active кластер, но при ближайшем рассмотрении фунционирует принципиально по другому. Целью использования FT является обеспечение практически нулевого RTO в случае выхода из строя сервера ESX. Достигается это параллельным выполнением виртуальных машин на двух соседних серверах на уровне параллельного выполнения команд процессора. При этом весь вывод на дублирующей виртуальной машине подавляется на уровне гипервизора. Основным ограничением данной технологии на сегодняшний момент является невозможность использования FT для виртуальных машин с числом процессоров больше одного, а также невозможность создания FT кластера из машин, построенных на процессорах различной архитектуры. Кроме того, естественным ограничением является требование хранения виртуальных машин на разделяемой СХД.

VMware Site Recovery Manager (SRM)

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

• Поддержка vSphere;
• Возможность работать с shared DR сайтами, что позволяет использовать один DR сайт для резервирования нескольких основных сайтов;
• Поддержка переноса машин, работающих в режиме Fault Tolerance;
• Расширенная поддержка СХД – NFS, iSCSI, Fiber Channel.