Опора на одного облачного провайдера несет серьезные риски, что подтверждают недавние сбои и атаки. Более устойчивый подход — модель резервного копирования «3-2-1-1-0» и использование решений вроде вендорского облака «Группы Астра», обеспечивающих защиту и восстановление данных. Подробнее — в материале IT-World.
Консолидация ИТ-инфраструктуры у одного облачного провайдера кажется логичной, особенно с точки зрения экономии: единая точка управления, предсказуемые затраты, меньшие интеграционные сложности. Но у этого есть обратная сторона. Когда бизнес полностью полагается на одну компанию, он автоматически принимает ее операционные риски как свои.
Вопрос в том, насколько этот подход осознан. Часто решение сконцентрировать ресурсы принимается без оценки сценариев, при которых провайдер может стать недоступен. Недавние события на Ближнем Востоке заставляют взглянуть на это очень внимательно. То, что раньше обсуждали в теоретической плоскости, стало реальностью для тех, кто разместил свои нагрузки в регионе ME-CENTRAL-1.
Облако AWS атаковали в ОАЭ и Бахрейне
3 марта 2026 года два дата-центра Amazon Web Services в Объединенных Арабских Эмиратах получили прямые физические повреждения в результате ударов беспилотников. Еще один объект был атакован в Бахрейне, и сервисы, включая фундаментальные S3, DynamoDB, EC2, Lambda, вошли в режим деградации.
AWS, конечно, не стал скрывать масштаб проблемы и выпустил официальную рекомендацию. Правда, звучит она не слишком обнадеживающе. Сроки восстановления поврежденных объектов остаются неопределенными, так как внешние факторы Amazon не контролирует. Клиентам советуют по возможности перенаправлять трафик из пострадавших зон, желательно в Европу или США.
Иными словами, провайдер, которому доверили свои данные сотни организаций, предложил всем спасаться самостоятельно. Можно ли после этого обвинять AWS? Нет, ведь абсолютно у всех, в том числе у самого крупного провайдера, может произойти форс-мажор.
Пожалуй, сейчас впервые причиной масштабного сбоя стала геополитика в ее самом прямом проявлении. Но даже если от нее отвлечься, сама по себе авария — история далеко не новая, просто раньше облака «падали» по другим причинам.
Краткий экскурс в историю облачных сбоев
Май 2024, Google Cloud. Ошибка сотрудника привела к удалению всей учетной записи австралийского пенсионного фонда UniSuper. Данные дублировались в двух регионах, но это не помогло — проблема затронула оба. Восстановление заняло неделю и стало возможным только благодаря бэкапам у другого провайдера. Все это время 620 тысяч пользователей оставались без доступа к своим счетам.
Октябрь 2025, Microsoft Azure. Сбой в Azure Front Door парализовал работу Microsoft 365, Teams, сервисов крупных клиентов Starbucks, Capital One, Alaska Airlines. Компании, полностью зависящие от Microsoft, столкнулись с прямыми операционными потерями. Заказы не принимались, платежи не проходили, рейсы не регистрировались.
Тот же октябрь 2025 — и снова AWS, но гео US-EAST-1. Ошибка отключила Snapchat, Roblox, Robinhood, McDonald's и даже Amazon Prime в США, то есть в самом загруженном регионе AWS. Мало того, многие из тех, кто напрямую не использовал AWS, тоже потеряли работоспособность, потому что их SaaS-вендоры, платежные шлюзы и сервисы аутентификации оказались завязаны на «упавшем» регионе. Иными словами, пострадала вся цепочка поставщиков.
Технические сбои — это одно. С ними глобальные игроки рынка и зарекомендовавшие себя облачные вендоры всегда разбираются и восстанавливают работу, пусть и не без последствий. Но бывает, что провайдер может просто исчезнуть. Не временно потерять доступность, а закрыться навсегда — по рыночным причинам, из-за смены стратегии или банкротства. И тогда счет идет на дни, оставшиеся до полного удаления данных.
- В 2013 один из крупных облачных провайдеров своего времени Nirvanix объявил о закрытии. Клиентам дали две недели на миграцию. Петабайты данных нужно было физически перенести через обычные интернет-каналы, и для многих это оказалось невыполнимо.
- Bitcasa в 2016 решил уйти из сегмента потребительских облачных хранилищ. У пользователей был месяц на выгрузку информации, а после этого все аккаунты и файлы подлежали безвозвратному удалению. Те, кто не успел или не придал значения уведомлению, потеряли данные навсегда.
Ситуация с AWS в ОАЭ просто добавила значимости уже существующей проблеме. Монопольная модель облачной инфраструктуры — всегда риск, вопрос только в том, когда и в какой форме он может стать реальностью.
Мы все знаем про «3-2-1»: бэкапы хранятся отдельно от основных данных, три копии, два носителя, одна копия вне офиса — это не просто «модный» ИТ-лозунг. Кроме того, современные угрозы, особенно вирусы-шифровальщики и целевые атаки на инфраструктуру, заставляют двигаться еще дальше.
Эволюция правила «3-2-1»
Сегодня все чаще говорят о модели «3-2-1-1-0». Она добавляет к классике два новых элемента.
- Неизменяемая копия (immutable или air-gapped). Это значит, что одна из резервных копий хранится в среде, куда нельзя просто так записать изменения: на LTO-ленте, в NAS без постоянного сетевого доступа или в специальном immutable-облаке. Смысл в том, что если вирус-шифровальщик доберется до основных систем, перезаписать или зашифровать эту копию он не сможет.
- Ноль ошибок при восстановлении. Мало просто сделать бэкап, нужно регулярно проверять, действительно ли из этих копий можно развернуть работающую систему, чисты ли они от вредоносного ПО. Без тестирования бэкапы превращаются в очередную неопределенность в тот самый момент, когда они по-настоящему нужны.
Важность этих дополнений подтверждают громкие ИБ-инциденты последних лет в России. В 2022 году атака на Rutube привела к длительному простою платформы. По открытым данным, злоумышленникам удалось уничтожить как основную инфраструктуру, так и значительную часть резервных копий. Похожие вещи произошли при атаках на СДЭК и другие крупные компании. В апреле 2023 хакеры выгрузили более 24 Тбайт данных с сайта интегратора «Первый Бит» и ресурс был недоступен несколько часов, а на его странице появилось требование выкупа.
Во всех этих случаях у компаний были бэкапы, но они хранились в той же логической или физической среде, что и основные данные, и это позволило их перезаписать или зашифровать вместе с «продуктивом». Если бы у организаций была «золотая копия», неизменяемая и изолированная от сети, восстановление заняло бы пару часов вместо нескольких дней и даже недель простоев.
Таким образом, модель «3-2-1-1-0» нивелирует те риски, что не учитывала классика. Защищая от вирусов-шифровальщиков, которые сегодня атакуют не только рабочие системы, но и сетевые хранилища с бэкапами, она также гарантирует, что в критической ситуации не окажется сюрпризов с битыми или зараженными копиями. Это укладывается в логику российских регуляторов: должны быть не просто бэкапы, а подтвержденная возможность восстановить систему.
От теории к бизнес-практике
По сути, «3-2-1-1-0» является стандартом для инфраструктур с критическими данными в финансовом секторе, промышленности, госструктурах и других отраслях — везде, где ошибки при восстановлении приводят к рискам федерального масштаба.
Важно понимать, что для системы резервного копирования нужен ИТ-ландшафт, где ее можно развернуть. Именно такую возможность дает вендорское облако «Группы Астра». Astra Cloud включает встроенные средства резервного копирования, позволяет создавать неизменяемые копии на физически изолированных носителях и поддерживает гибкие модели размещения: от готового сервиса в ЦОДе вендора до развертывания на своем оборудовании в закрытом контуре компании.
Все компоненты решения (ОС, система резервного копирования, средства виртуализации, служба каталога, инструменты автоматизации и мониторинга) изначально спроектированы так, что работают как единое целое. Это создает изолированную и безопасную среду с возможностью дальнейшей аттестации, где защита данных заложена на уровне архитектуры, а не добавляется потом.
Примеры AWS, Google и Microsoft показывают, что даже глобальные лидеры не застрахованы от сбоев. Они действуют в первую очередь в рамках своего законодательства и ориентированы в большей степени на выполнение контрактных обязательств и SLA.
В российской практике регуляторные требования создают другую систему координат. Вендоры изначально живут в парадигме, где фундаментальное значение имеет ответственность перед государством и клиентами. И если уж бизнесу опираться на внешнюю инфраструктуру, разумно выбирать того, кто не только предоставляет ресурсы, но и отвечает за них 24×7. В случае с Astra Cloud это означает поддержку от разработчика, гибридные облачные сценарии и соответствие всем актуальным нормам.