В эфире программы «Деловой Гамбит» на радио MediaMetrics Юрий СЕМЕНЮКОВ, директор центра инфраструктурных решений «Инфосистемы Джет», и Антон ШИПУЛИН, руководитель направления непрерывности ИТ, обсудили с ведущей Екатериной ЯРЦЕВОЙ, почему наличие резервного ЦОДа и бэкапов ещё не гарантирует, что компания переживёт серьёзную атаку. Поговорили о физических угрозах для дата-центров, новых принципах резервирования и о том, что бизнесу стоит проверить уже сегодня. Материал подготовлен по итогам эфира. Полную запись программы можно посмотреть по ссылке.

Е. ЯРЦЕВА: Гарантия, что компанию будут атаковать, — 100%. Гарантии, что она переживёт атаку, — нет. Что изменилось в ландшафте угроз?

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

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

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

И здесь возникает уже не просто технический вопрос «А за какое время мы сможем восстановиться?». Вопрос в том, сможет ли компания после такого вообще восстановиться и продолжить существование как бизнес.

А. ШИПУЛИН: Причём физическая атака необязательно должна быть направлена непосредственно на ЦОД. Есть ещё одна зависимость, о которой часто забывают, — энергетика.

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

Е. ЯРЦЕВА: Что это меняет в проектировании ЦОДов?

А. ШИПУЛИН: Меняется прежде всего подход к размещению резервных мощностей. Раньше два ЦОДа вполне могли строить рядом, чтобы обеспечить хорошую связанность, минимальные задержки и быстрое переключение. Для защиты от локальных отказов это логичная архитектура. Но теперь приходится учитывать ситуации, когда одновременно недоступными могут оказаться обе площадки. Поэтому заказчики всё чаще рассматривают географически распределённую инфраструктуру — с выносом резервных мощностей на значительное расстояние от основного контура.

Вторая история — изоляция. Можно построить несколько ЦОДов, объединить их в конфигурацию active-active, настроить постоянную репликацию. С точки зрения отказоустойчивости всё будет прекрасно, восстановление после локальных отказов возможно в минимальные сроки. Но если злоумышленник получил доступ к инфраструктуре и скомпрометировал или удалил данные, высокая связанность сыграет против нас.

Поэтому мы предлагаем разделять две задачи. Первая — сохранить данные, даже если основной контур полностью скомпрометирован. Для этого у нас есть концепция «Бункер»*: изолированная среда, в которой резервные копии хранятся, защищаются и проверяются. Вторая — обеспечить быстрое продолжение работы самых критичных для бизнеса систем. Здесь уже нужна «Цитадель»** — отдельный изолированный контур с подготовленным горячим резервом.

Ю. СЕМЕНЮКОВ: По сути, изменился сам вопрос, который мы задаём при проектировании инфраструктуры. Раньше мы думали, как максимально быстро восстановиться после какого-нибудь техногенного сбоя. Отключилось электричество, отказало охлаждение, трактор перекопал кабель — неприятно, но понятно, что делать. Основная задача — как можно быстрее вернуть сервисы в строй. А теперь представим, что мы потеряли не отдельный компонент и даже не серверную. Мы потеряли всю ИТ-инфраструктуру и саму площадку. Физически. И вопрос уже не в том, сколько минут потребуется на переключение. Сможем ли мы вообще восстановиться?

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

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

Е. ЯРЦЕВА: То есть правило «3-2-1» вы расширяете?

А. ШИПУЛИН: Да, речь о подходе «3-2-1-1-0». Базовое правило никто не отменяет: три копии данных, два типа носителей, одна копия за пределами основной площадки. Но сегодня принципиально важно добавить ещё два условия. Первое — наличие изолированной копии, недоступной из основного контура. Второе — ноль ошибок при проверках восстановления. Потому что сама по себе резервная копия ничего не гарантирует. Допустим, система резервного копирования исправно работает, задания выполняются, отчёты «зелёные». Но пробовали ли вы из этих копий восстановить не отдельный сервер или базу данных, а полноценную информационную систему? Может оказаться, что каких-то данных недостаточно. Или что компоненты восстановились, а сама система не запускается. Или что DR-план, который прекрасно выглядел на бумаге, уже не соответствует реальной инфраструктуре.

И ещё важный вопрос: команда вообще умеет работать по вашему DR-плану? Одно дело — иметь инструкции и инструменты, другое — суметь воспользоваться ими в условиях реальной аварии. Поэтому проверять нужно не просто наличие копий, а возможность восстановить работоспособность системы целиком в условиях аварийной ситуации.

Ю. СЕМЕНЮКОВ: Причём мы не утверждаем, что изобрели какое-то новое правило. Подход «3-2-1-1-0» существовал и раньше. Просто долгое время многие считали, что достаточно выполнить хотя бы базовое «3-2-1». По нашим исследованиям, даже его соблюдают не более 49% компаний. Или, по крайней мере, думают, что соблюдают. А теперь выясняется, что дополнительные требования к изоляции и проверкам становятся критически важными.

Е. ЯРЦЕВА: Мобильные ЦОДы — это про что? На прошлом эфире мы сравнивали их с мобильной пасекой.

А. ШИПУЛИН: Сравнение, кстати, вполне подходящее. По сути, речь о готовой инфраструктуре в контейнерном исполнении, которую можно разместить на подготовленной площадке и при необходимости переместить.

Почему на такие решения сейчас обращают внимание? Потому что строительство капитального ЦОДа — это долго. Нужно найти площадку, получить необходимые согласования, спроектировать инженерную инфраструктуру, провести строительные работы. А если у предприятия уже есть территория и доступные энергетические мощности, контейнерный ЦОД позволяет заметно сократить этот путь. Например, завод может разместить резервные мощности в отдельных контейнерах на своей территории. Это не отменяет требований к географическому размещению и защищённости, но даёт дополнительный вариант, когда время становится критичным фактором.

Е. ЯРЦЕВА: Если бы вы были ИТ-директором банка — с чего начать, с чем ждать нельзя?

Ю. СЕМЕНЮКОВ: Я бы начал с вопроса, который на самом деле относится не только к банкам. Какие системы действительно нужны компании, чтобы она могла продолжать работать? Кажется, что ответ очевиден. Но на практике это далеко не всегда так.

У нас был пример со страховой компанией. Казалось бы, что для неё самое важное? Система приёма обращений, колл-центр, обработка страховых случаев? А когда стали разбираться в бизнес-процессах, выяснилось, что одной из критически важных систем была система печати полисов. Физической печати. Без неё оставался незавершённым основной бизнес-процесс.

Поэтому ИТ-директору важно прийти к бизнесу и спросить: а без чего мы действительно не сможем работать?

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

Можно написать прекрасный DR-план на 600 страниц, положить его на полку и считать, что компания готова к аварии. А потом в три часа ночи что-нибудь случится, команда впервые откроет инструкцию и начнёт читать. Где-нибудь на пятисотой странице выяснится, что действовать нужно было совершенно иначе. Только времени на это уже не будет. Поэтому нужны регулярные учения. Причём на таком уровне, чтобы я как технический директор точно знал, кому позвоню в три часа ночи, по какому номеру, что этот человек должен сделать и кто его заменит, если он в отпуске. В момент серьёзного инцидента поздно собирать рабочие группы, знакомиться друг с другом и выяснять, кто за что отвечает. Звучит как будто бы очевидно, но наш опыт общения и работы с разными компаниями показывает, что это действительно так — в практическом плане готовность к отработке аварии достаточно низкая.

А. ШИПУЛИН: И ещё важно не путать наличие плана восстановления с полноценным процессом обеспечения непрерывности бизнеса.

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

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

Сама проверка может занять, например, выходные, но её подготовка — отдельная работа. И проводить такие учения нужно регулярно, а не один раз для галочки.

Е. ЯРЦЕВА: Насколько банки готовы к новым угрозам?

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

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

А. ШИПУЛИН: При этом даже хорошо защищённый банк может столкнуться с другой проблемой. Допустим, резервные копии сохранились, и мы действительно можем восстановить системы. Но сколько это займёт времени?

Для некоторых организаций восстановление из бэкапов может продолжаться слишком долго. Бизнес просто не может позволить себе такой простой. Поэтому мы и говорим о «Цитадели». Это отдельный изолированный контур, в котором заранее подготовлены экземпляры наиболее критичных систем, готовые принять нагрузку при серьёзном инциденте.

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

Е. ЯРЦЕВА: Что делать тем, кто ещё не выстроил защиту? Есть ли быстрые шаги?

Ю. СЕМЕНЮКОВ: Есть. И я бы вообще не сводил этот вопрос исключительно к ИТ. Это уже задача собственника бизнеса, генерального директора, руководства компании. Необязательно начинать со строительства нового ЦОДа. Есть вещи, которые можно сделать с существующей инфраструктурой и которые уже заметно повысят шансы на восстановление.

Для начала нужно понять, какие процессы для компании действительно критичны и в какой последовательности их придётся восстанавливать.

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

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

Е. ЯРЦЕВА: Как быстро всё это можно сделать?

Ю. СЕМЕНЮКОВ: За одну ночь — точно нет. Можно ускорить отдельные этапы. Например, использовать мобильные контейнерные ЦОДы, о которых говорил Антон. Это позволяет сократить время на капитальное строительство и подготовку инфраструктуры. Но самое важное — не ждать момента, когда всё уже произошло.

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

И если ответ пока неизвестен, это уже достаточная причина заняться вопросом. Начинать, конечно, стоило ещё вчера.

* «Бункер» - изолированный контур резервного копирования, не имеющий прямого сетевого доступа из продуктивной среды и интернета. Его задача — сохранить доверенные резервные копии, регулярно проверять их пригодность и обеспечить возможность восстановления даже после компрометации основной инфраструктуры.

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