Пост-статус Beget, где они, фактически, признают полное унитожение своей облачной инфраструктуры, во вторник разошёлся весьма широко в цитатах и пересказах. Кто-то сочувствовал, кто-то злился, кто-то злорадствовал.
Но мало кто пишет, а что, собственно, делать остальным? Тем более, что за последний месяц инфраструктуру рунета весьма сильно шатало:
- атаки на ЦОДы Яндекса, когда меньше чем за неделю из чата вышло сразу две зоны доступности
- взлом FirstVDS (и пачки хостеров поменьше) с угоном клиентских данных
- взлом Beget с полным уничтожением клиентских данных и инфраструктуры провайдера
Для начала, давайте договоримся о базе:
1. Сохранность данных - задача клиента. У какого-бы самого-самого лучшего облачного или хостинг-провайдера вы не хранили свои данные (файлы, сайты, вм, куберы и т.д.), будьте готовы к тому, что вы можете лишиться доступа к этим данным в любой момент - сотрудник удалил проект, отказало железо, порвали оптику и т.д. На этот случай у вас всегда должен быть план Б - резервный провайдер, флешка с актуальным бэкапом базы в сейфе и план действий, как всё вернуть "как было". Подробнее можно почитать тут по тэгу #drp, а ещё лучше - послушать умных людей, вроде Володи Федоркова из @downtime_bar
2. Не существует "серебряной пули". Нет в природе какого-то "самого лучшего ЦОДа", "самого надёжного провайдера" и т.д. И стопроцентной защиты от хакерских атак тоже не существует. Поэтому для обеспечения необходимого уровня доступности придётся поднапрячься и научиться комбинировать сразу несколько решений.
3. В любой стрессовой ситуации вы не поднимаетесь до уровня своих ожиданий, а падаете до уровня своих реальных возможностей. Нужные системы окажутся недоступны. Дежурный инженер будет тусить в ночном клубе пьяным. Все будут тупить, бегать в панике и вообще, восстановление займёт сильно больше времени, чем вы могли бы ожидать. Увы, это правда жизни.
А теперь попробуем прикинуть, что же делать?
1. Бэкапить нужно всё, от чего зависит ваш бизнес. Причём бэкап - это не обязательно копия. Резервный домен, на который можно переключить трафик. Второй провайдер, альтернативный инструмент. Да, он может быть дешевле/хуже, но лучше так, чем совсем ничего.
2. Бэкапы должны быть не только гео-резервированными, но и изолированы по сети от прода. Варианты могут быть разные: ленточка/диск/флешка в сейфе, write-only S3-бакет у внешнего провайдера или полностью изолированная по управлению сеть СРК. Тут многое будет зависеть от требований регуляций и бизнеса, а так же бюджета и квалификации команды. Но случаев, когда в результате атаки удалялись/шифровались в первую очередь бэкапы, было не один и не два.
3. Бэкапы должны проверяться в сценарии "всё разворачивается вообще с нуля". Т.е. считаем что нет домена, нет гитлаба, нет волта/битвардена. И конфлюэнса с документом DRP тоже нет. И вот с этой точки нужно восстановить прод за понятное время.
4. Регулярно проводите инвентаризацию того, что вы, собственно, бэкапите. А то может легко получиться так, что вон ту важную базу забыли поставить на бэкап, зато какая-нибудь выведенная из работы подсистема исправно копируется раз в сутки, занимая место на диске и ресурсы сети.
Продолжение следует
#thereisnoclouds @snakeslair
В этом посте были ссылки, но мы их удалили по правилам Сетки
