Атаки БПЛА на ИТ-инфраструктуру

В последнее время участились попытки атак на гражданскую инфраструктуру России со стороны Киевского режима. В прошлые месяцы под ударом были склады WB и Озон, на этой неделе заложником лидерства стал инфраструктурный гигант Яндекс.Облако. Е-поселок использует аттестованную инфраструктуру Яндекс.облака для развертывания своих серверов, мы храним данные и контейнеры с защищенными материалами наших поселков именно в инфраструктуре Яндекса, что до недавнего времени было залогом в общем-то высокого уровня качества и безопасности.  Технической и физической, но что могут сделать ИТшники против БПЛА?

Действительно, современные дата центры уже на уровне Iaas (аппаратной и базово-программной) обеспечивают высокую отказоустойчивость. Вся инфраструктура Яндекса поделена на независимые зоны доступности, которые связаны физически с разными дата-центрами - ЦОДами. У Яндекса своих таких ЦОДов 4, плюс, возможно партнерские. Между дата-центрами налажена высокая скорость обмена данными, допускающая некоторую миграцию или резервирование, но в целом они независимы друг от друга. Внутри дата-центров пропускная способность и локальное резервирование еще выше. При обычном облачном сценарии инфраструктура виртуализирована и не связана с конкретным сервером, стойкой или этажом: говоря по-простому, данные и виртуальные машины "летают" между оборудованием и выполняются одновременно на нескольких устройствах. Таким образом,  выход из строя одного сервера, даже стойки серверов и, возможно,  этажного блока проходит для потребителей незаметно. Все это было сделано для того, чтобы в случае отказа оборудования, пожаров, злонамеренных действий, обслуживание не прекращалось. Но у резервирования есть пределы, а чудес не бывает: одновременное выпадание большого количества устройств неизбежно ставит под вопрос выживание системы в целом. Disaster-проектирование все-таки не учитывает военные риски и целенаправленные попытки выведения оборудования из строя, поэтому атаки БПЛА пишут новую главу и новую историю в учебники по ИТ-безопасности, а мы наблюдаем за этим процессом из партера.

За последние сутки пользователей е-поселок последствия атаки 8 октября на ЦОД в Рязанской области (Сасово) коснулись лишь косвенно: на 3 часа е-поселок был недоступен, потому как наши инженеры и инженеры Яндекса стали проводить по сути схожие действия по резервированию данных причем в одно и то же время. Это стечение обстоятельств привело к тому, что отключив инфраструктуру на 2 минуты для создания полной копии, мы не смогли ее запустить, поскольку севера Яндекса "заняли" нашу "освободившуюся" вычислительную мощность для решения своих задач по созданию глобальных копий. Это не очень профессионально со стороны яндекса, занимать гарантированную и выкупленную вычислительную мощность, но overbooking у нас теперь даже на билеты на самолеты разрешен, а Яндекс действует в аварийных условиях, потеряв кусок своего дата-центра. Мы, конечно, недовольны, но ситуацию понять можно. Е-поселок вернулся в строй в 2 часа ночи, через 3 часа.

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