Архив метки: YandexCloud

Напишу несколько слов по поводу атак вражеских беспилотников на дата-центры Яндекса

Напишу несколько слов по поводу атак вражеских беспилотников на дата-центры Яндекса

Напишу несколько слов по поводу атак вражеских беспилотников на дата-центры Яндекса. В ночь с 7 на 8 октября в результате атаки БПЛА был серьёзно повреждён дата-центр Яндекса в Сасово Рязанской области. Утром 9 октября атаке подвергся дата-центр Яндекса в Калуге, несколько модулей которого были выведены из строя. В ночь на 11 октября был атакован дата-центр Яндекса во Владимире, инфраструктура ЦОДа получила повреждения, его работа была полностью остановлена, а часть сервисов Яндекса стала недоступна пользователям. В такой ситуации я, как и всегда, на стороне пострадавшей российской компании. Считаю злорадство по этому поводу абсолютно неадекватным и неприемлемым.

Также не думаю, что эта история касается исключительно Яндекса. Другие дата-центры тоже могут стать целями атак. При выборе целей враги учитывают как потенциальный ущерб, так и общественный резонанс. Яндекс - одна из крупнейших технологических компаний России, объединяющая десятки сервисов для миллионов пользователей и бизнес-клиентов - от поиска, карт и такси до доставки, электронной коммерции и облачной инфраструктуры Yandex Cloud. По оценкам iKS-Consulting, Yandex Cloud входит в тройку крупнейших российских провайдеров облачной инфраструктуры IaaS и PaaS. Поэтому атаки на инфраструктуру Яндекса затрагивают не только пользователей его собственных сервисов, но и множество компаний, которые размещают в его облаке свои системы и данные.

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

Провайдерам услуг обработки данных следует:

🔹 Учитывать физические атаки при проектировании и модернизации ЦОДов, усиливать защиту зданий и инженерных систем. Помимо пассивной защиты, следует рассматривать меры активной защиты от беспилотников, согласованные с уполномоченными органами и соответствующие требованиям законодательства. При этом стоит учитывать Указ Президента РФ № 604, предусматривающий возможность введения временного управления в отношении имущества хозяйствующих субъектов, не обеспечивающих безопасность объектов критической инфраструктуры.

🔹 Развивать географическое резервирование, чтобы потеря одной площадки не приводила к длительной недоступности критичных сервисов.

🔹 Регулярно проверять готовность к полной потере ЦОДа: отрабатывать перенос нагрузки и восстановление сервисов в приемлемые сроки.

Потребителям услуг обработки данных следует:

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

🔸 Для критичных сервисов рассмотреть географическое резервирование в удалённых регионах или, если это допустимо с учётом требований к данным и безопасности, за рубежом.

🔸 Уточнить у провайдера сроки и условия восстановления после потери площадки.

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

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках"

В начале сентября коллеги из Cloud Advisor выпустили исследование Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках

В начале сентября коллеги из Cloud Advisor выпустили исследование "Состояние облачной безопасности в России. Анализ защищённости инфраструктур, развёрнутых в российских публичных облаках". Cloud Advisor - это вендор отечественного CNAPP (Cloud-Native Application Protection Platform) решения, позволяющего искать на облачных активах (виртуальных машинах и Kubernetes) уязвимости, вредоносный код, секреты и мисконфигурации. Отчёт о состоянии облачной безопасности в России опирается на реальные данные десятков организаций, имеющих не менее 80 виртуальных машин в публичном облаке (Cloud Ru и Yandex Cloud). Всего было проанализировано более 40 000 виртуальных машин. Период исследования - первое полугодие 2026 года.

По уязвимостям результаты следующие:

🔻 83% виртуальных машин имеют уязвимости с CVSS выше 9,0;
🔻 88% организаций имеют на публично доступных машинах уязвимости с CVSS выше 9,0;
🔻 27% организаций до сих пор уязвимы к Log4Shell (CVE-2021-44228);
🔻 42% организаций имеют хотя бы одну виртуальную машину на периметре с ОС, находящейся в статусе EOL (всего EOL-систем в облаках около 9%).

В части Управления Уязвимостями эксперты Cloud Advisor рекомендуют:

🔹 Внедрить регулярное сканирование виртуальных машин и образов контейнеров на уязвимости, используя для этого безагентные cloud native-решения. "Таким образом можно обеспечить 100% покрытие без трудозатрат на установку агентов и настройку SSH-доступов".

🔹 Приоритизировать уязвимости по контексту, а не только по CVSS. Помимо CVSS и наличия эксплойтов рекомендуют учитывать "публичную доступность ресурса, наличие на нём секретов в открытом виде, его права и другие факторы".

🔹 Установить и соблюдать SLA на устранение уязвимостей в зависимости от их критичности. "Без фиксированных сроков CVE накапливаются годами - как это произошло с Log4Shell".

Также эксперты Cloud Advisor обращают внимание, что наибольшую опасность представляют цепочки уязвимостей, ошибок конфигураций и прав доступа, которые в совокупности создают критические пути атаки. Именно такие связки должны стать приоритетом в защите облачной инфраструктуры.

Глянул "Стандарт по защите облачной инфраструктуры" от Yandex Cloud

Глянул Стандарт по защите облачной инфраструктуры от Yandex Cloud
Глянул Стандарт по защите облачной инфраструктуры от Yandex Cloud

Глянул "Стандарт по защите облачной инфраструктуры" от Yandex Cloud. В части Управления Уязвимостями никаких откровений не увидел. Кроме того, что у них есть встроенный сканер для образов, правда непонятно на каком движке он работает. В его описании почему-то только про deb, но rpm дистрибутивы перечислены. Российских дистрибутивов в списке нет.

"При сканировании происходит распаковка Docker-образа и поиск версий установленных пакетов (deb). Затем найденные версии пакетов сверяются с базой данных известных уязвимостей."

Встроенный сканер для хостов тоже напрашивается, но видимо пока нет.

Указанное "решение в маркетплейсе" это ScanFactory Agent — сервис для мониторинга безопасности публичных IP-адресов и доменов, размещенных в Yandex Cloud (периметровый сканер). ScanFactory Agent каждый час выгружает список публичных IP-адресов и доменов и отправляет их в ScanFactory для анализа. Результаты мониторинга доступны в личном кабинете клиента.