«Это катастрофа, шеф!» — как облако помогает организовать Disaster Recovery
Привет, Хабр!
Рассказываем, на что обратить внимание при планировании аварийного восстановления: что может сделать сама компания, а где поможет облачный провайдер. А также обсуждаем, какие установки мешают компаниям грамотно организовать катастрофоустойчивую инфраструктуру и прислушаться к мнению ИТ-специалистов на местах.
Не [всегда] очевидные управленцам факты о DR
Прежде чем переходить к советам — вот пара моментов, которые порой ускользают от тех, кто не занимается аварийным восстановлением непосредственно:
1. Disaster Recovery не то, чем кажется
У читателей англоязычных материалов о DR может сложиться впечатление, что главным источником критических сбоев в ИТ-инфраструктуре являются землетрясения, ураганы, снежные бури и прочие стихийные бедствия. Это неудивительно — в каждой второй американской статье по теме упоминается очередной ураган или супершторм.
На фоне всех этих катастроф возникает ощущение, что если ваша компания не арендует офис по соседству с Элли из Канзаса, то стратегия DR для вас, в общем-то, не актуальна. Но мать-природа порой преподносит сюрпризы и в России. Буквально в этом году от сильных паводков пострадали предприятия в Оренбургской, Курганской и Тюменской областях. Тогда у многих под воду ушли целые офисы со всей техникой.
И все же критический сбой в инфраструктуре — необязательно следствие масштабного природного бедствия. Помимо геологических и экологических, в число рисков может входить и банальное бытовое затопление или пожар. Например, еще в 2014 крупный пожар в дата-центре корейского производителя электроники привел к потере большей части корпоративных данных.
Не менее опасны бывают и другие проявления человеческого фактора. Начиная с разнообразных «случайностей» вроде удаления таблиц из базы данных или же целых кластеров из облака. И заканчивая хакерскими атаками на инфраструктуру с использованием вирусов-шифровальщиков.
2. DR — это коллективная ответственность
Еще одно заблуждение, которое встречается среди управленцев, состоит в том, что DR — целиком и полностью прерогатива системных администраторов. Учитывая, что обрушить инфраструктуру могут происшествия разной природы (многие из которых относятся к компетенции безопасников), разграничивать «ИТ-проблемы» и «ИБ-проблемы» в ряде случаев как минимум неэффективно. Если между подразделениями нет диалога, не выстроена схема совместной работы и не продуманы стратегии коллективного реагирования, при наступлении соответствующего риска может начаться перекидывание ответственности — «это не наше дело».
3. Перспектива восстановления «вручную» — сильнейший демотиватор
Хуже отсутствия диалога по поводу DR между подразделениями может быть полное отсутствие DR. Конечно, чаще всего это касается малого и (много реже) среднего бизнеса. Тем не менее, уверенность менеджмента в том, что, в случае чего, базы, кластеры и поды можно «починить руками», резко уменьшает желание ИТ-специалистов продолжать работать в компании.
В качестве иллюстрации можно привести историю одного из пользователей Reddit. Компания, в которой он работал (кстати, не такая уж и маленькая — в несколько сотен сотрудников), отказывалась хранить резервные копии на удалённой площадке. В итоге сисадмин самостоятельно реализовал «единственно возможный» в этом случае план аварийного восстановления: отложил немного денег из зарплаты и уволился, когда офис, в котором располагалась серверная, накрыл ураган Иэн. Вероятно, этот вариант Disaster Recovery не приходил в голову его руководству и обошелся бизнесу много дороже, чем бэкапы в облаке, которые предлагал им специалист.
4. Если у вас все хорошо, это не значит, что так будет всегда
Пожалуй, это заблуждение объединяет в себе все предыдущие: «раз ничего не происходило, значит, нечего об этом думать и тратить ресурсы неизвестно на что». Психологи называют такую установку предвзятостью оптимизма: в отношении себя человек склонен преувеличивать вероятность наступления позитивных событий («в нашей компании все организовано лучше, чем у других») и преуменьшать вероятность наступления негативных событий («такого с нами никогда не случится»).
Предвзятость оптимизма активно изучается еще с 80-х гг. прошлого века и, похоже, в той или иной мере присуща всем людям вне зависимости от национальности, страны проживания, пола или возраста: её называют одним из наиболее распространенных и устойчивых когнитивных искажений. Другими словами, мы все в той или иной мере подвержены предвзятости оптимизма, однако это крайне плохой советчик в деле адекватной оценки рисков.
В противовес излишнему оптимизму ученые выдвигают стратегию «защитного пессимизма»: она помогает более точно оценить степень риска, предпринять меры по его минимизации, а в случае наступления негативного события действовать более собранно и добиваться лучших результатов. Пожалуй, одним из ярких примеров такого поведения является кейс Intel. В 70-х компания производила плашки оперативной памяти и занимала 80% мирового рынка. Но уже в 1980-х она начала стремительно уступать японским конкурентам. CEO предвидел худший сценарий — полную потерю рынка, поэтому принял грамотное решение переориентироваться на производство микропроцессоров.
Те, кто не принимает ситуацию как должное, критически оценивает собственные возможности и уделяет внимание негативным сценариям («вдруг что-то пойдет не так — что мы будем делать?»), оказывается в выигрыше. Иначе говоря, «защитный пессимизм» — пожалуй, лучшая предпосылка к планированию DR.
Как все-таки повысить катастрофоустойчивость
1. Начать с простых шагов
В первую очередь аварийное восстановление призвано нейтрализовать последствия крупных происшествий, способных нанести бизнесу серьезный ущерб. Прежде чем заниматься этими вопросами, стоит отточить стандартные процедуры восстановления, предназначенные для устранения инцидентов меньшего масштаба. Их основу составляет базовая корпоративная гигиена — необходимо следить за исполнением политик безопасности, актуальностью резервных копий и регулярно тестировать возможность восстановления данных из бэкапов.
Очень важно системно проводить тестирование резервных копий, которые вы сделали. Об этом, кстати, часто забывают. К примеру, ваша резервная копия может быть не совсем консистентной — в итоге она окажется бесполезной. Мероприятия по тестированию имеет смысл вписывать во все планы аварийного восстановления.
— Павел Брагин, руководитель Центра Вычисление, хранение и кибербезопасность МТС Web Services
2. Подготовить план DR
Только когда правила базовой гигиены сформулированы и соблюдаются, можно переходить к составлению плана DR. Как правило, он включает не только создание бэкапов, но и перенос резервных копий в отдельное хранилище, протоколы коммуникации с сотрудниками компании (и клиентами) во время аварии. В него также входит определение резервных площадок или центров обработки данных, куда можно перенести операции в случае катастрофы.
3. Протестировать его
Очевидно, что составленный план необходимо регулярно тестировать, а затем корректировать на основе полученных данных. Обычная практика — отработка аварийных сценариев с привлечением ключевых сотрудников. Но встречаются и более экзотические варианты. Например, Netflix использует специальный инструмент Chaos Monkey, который следует парадигме хаос-инжиниринга и случайный образом отключает серверы и кластеры в облачной-среде, симулируя крупные аварии.
Важно понимать, каким бы комплексным ни был план disaster recovery, в нем невозможно предусмотреть абсолютно все сценарии — не стоит разрабатывать универсальную стратегию «от всего на свете». Размытые формулировки и отсутствие четких шагов только ухудшат и без того неприятную ситуацию, если инцидент все-таки произойдет. Наоборот, специалисты рекомендуют составлять план DR так, чтобы он покрывал узкие кейсы, не оставляющие места для вольных интерпретаций. Так, в случае потери главной базы данных, должна воспроизводиться одна последовательность шагов, а при падении биллинга — другая.
4. Подумать об увеличении стоимости взлома
В контексте кибербезопасности можно выделить еще один способ повышения катастрофоустойчивости — увеличение стоимости взлома.
Если злоумышленники посчитают, что взлом средней или крупной компании обойдется им в условные 300 тыс. рублей — компанию будут пытаться взломать. Если же компания будет «стоить» 30 или 300 млн рублей — лишний раз подумают, нужно ли с вами связываться. Это не исключает риск полностью, но в таком случае компанией будут заниматься «специалисты» совсем другого уровня.
— Павел Брагин
Идея состоит в том, чтобы сделать взлом настолько дорогим и времязатратным для злоумышленников, насколько это возможно. Добиться этого можно самыми разными способами, начиная с обязательной многофакторной аутентификации для сотрудников, использующих корпоративные аккаунты, до построения полноценной архитектуры нулевого доверия (Zero Trust Architecture). В таком контексте хакерам потребуется регулярно подтверждать свои права доступа, что значительно увеличивает стоимость атаки.
Более экзотичным вариантом может быть построение специальных поддельных окружений — ханипотов, которые мимикрируют под реальные ИТ-ресурсы. Злоумышленники вынуждены взаимодействовать с такими системами и тратить свое время, а безопасники получают возможность следить за их активностью. Правда, здесь, как и в целом в отношении DR, важно грамотно рассчитать точку безубыточности — затраты на поддержание доступности данных и сохранение их в целостности не должны превышать расходы от их потери.
5. Крупным компаниям — обратить внимание на мультиоблако
Наконец, распространённым механизмом повышения катастрофоусточивости становится мультиоблако, когда корпоративная инфраструктура развертывается сразу в облаке нескольких провайдеров. Учитывая, что крупные игроки сами имеют сеть географически распределенных ЦОД, дополнительное резервирование значительно увеличивает способность бизнеса противостоять серьезным неприятностям. Даже если один облачный провайдер потеряет целый регион (что происходит крайне редко), инфраструктура второго сыграет роль запасного аэродрома.
На безопасность и отказоустойчивость влияет множество факторов: где находятся ваши дата-центры, какой объем электроэнергии доступен вам с точки зрения резервирования и продуктивной работы, какие операторы каналов связи проложили туда свои кабели и как вы можете с этим работать.
Если вы используете мультиоблачный подход, то с высокой долей вероятности сможете восстановить систему и не потеряете данные даже в случае заражения инфраструктуры вирусом-шифровальщиком или сбоя у кого-то из провайдеров. Поэтому, на мой взгляд, для крупного бизнеса мультиоблако скоро станет промышленным стандартом.
— Павел Брагин
Концепция мультиоблака действительно набирает обороты в бизнес-среде. Согласно опросу, проведенному компанией Oracle среди полутора тысяч сотрудников крупных компаний (со штатом > 1000 человек), 98% работают как минимум с двумя облачными провайдерами, а 31% — размещает инфраструктуру у четырех игроков. В то же время появляются и open source инструменты для управления несколькими облаками — например, Mist и Cloudforet. Последний входит в состав The Linux Foundation.
Главное помнить, что распределённая природа мультиоблака повышает катастрофоустойчивость, но в то же время расширяет поверхность для кибератак. Подавляющее большинство утечек данных в облаке происходит из-за неправильной настройки окружения.
Бывают ситуации, когда клиент приносит в облако свои ресурсы, не имея компетенций по настройке безопасного окружения. Например, оставляет открытые порты, по которым можно подключиться к его облачной инфраструктуре напрямую через RDP. Бывает, что «наружу торчит» узел с доступом по SSH-протоколу, авторизация к которому настроена не по ключу, а по логину и паролю. Или, например, компания вроде бы защищает ресурсы от DDoS-атак, но админ организовал себе какие-то исключения из правил в целях личного удобства. Если атакующая сторона нащупает этот пробел, то сломает инфраструктуру через него.
В этом случае пострадает инфраструктура конкретного клиента или компании, а не облака в целом. Тем не менее, облачные провайдеры заинтересованы в том, чтобы таких ситуаций было как можно меньше — поэтому многие задумываются об организации консалтинга для клиентов на основе своего опыта и лучших практик. Такой подход, на мой взгляд, в будущем может стать общепринятой практикой повышения катастрофоустойчивости.
— Павел Брагин
