Вопросы кибербезопасности при использовании публичных облачных сервисов остаются одними из наиболее актуальных для корпоративных заказчиков. Ведущие эксперты обсудили критерии выбора провайдера, распределение зон ответственности и перспективы развития рынка облачной безопасности.
- 1. Введение
- 2. Публичное облако как объект защиты
- 3. Реальные провалы в защите облаков
- 4. Как оценить зрелость кибербезопасности облачного провайдера?
- 5. Безопасное облако по умолчанию — это миф?
- 6. Какие экспертные услуги по кибербезопасности покупать у провайдера?
- 7. Как будет меняться спектр услуг кибербезопасности облачных провайдеров?
- 8. Выводы
Введение
Публичные облака стали повседневной реальностью для бизнеса любого масштаба. Сегодня на них работают целые отрасли: от ритейла до финансового сектора, от государственных сервисов до ИИ-платформ. Вместе с гибкостью, масштабируемостью и скоростью развёртывания облака принесли и новый класс рисков. Привычные границы ответственности размываются. Старые модели защиты перестают работать, а ошибки конфигурации могут стоить миллионов.
Можно ли построить безопасное облако по умолчанию? Где проходит грань между зоной ответственности провайдера и клиента? Какие сервисы безопасности действительно нужны, а без каких можно обойтись? И главное — как выбрать облачного провайдера, которому можно доверять? Эти вопросы обсудили в эфире AM Live ведущие эксперты рынка.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Андрей Семенюченко, руководитель управления решений для корпоративных заказчиков, «Лаборатория Касперского».
- Демид Балашов, руководитель по развитию продуктов кибербезопасности, «МегаФон ПроБизнес».
- Денис Полянский, директор по клиентской безопасности, Selectel.
- Максим Долгинин, руководитель направления развития продуктов кибербезопасности, Cloud.ru.
- Рами Мулейс, руководитель продукта Security Deck, Yandex.Cloud.
- Михаил Захряпин, генеральный директор, Cloud Advisor.
- Станислав Погоржельский, технологический евангелист VK Cloud&Data, VK Tech.
Ведущий и модератор эфира — Михаил Кадер, архитектор ИБ, UserGate.
Публичное облако как объект защиты
Михаил Кадер напомнил, что облака уже стали стандартной частью ИТ-инфраструктуры любой компании. Сегодня они находятся на переднем крае развития технологий и задач по обеспечению информационной безопасности.
Михаил Кадер, архитектор ИБ, UserGate
Станислав Погоржельский пояснил, что облачные инфраструктуры делятся на IaaS, PaaS и SaaS — от этого зависят зоны ответственности провайдера и клиента. IaaS (инфраструктура как сервис) — это, например, виртуальные машины, VPS или VDS. PaaS — платформа как сервис, классические примеры: база данных или Kubernetes, где управление средой берёт на себя провайдер. SaaS (программное обеспечение как сервис) — это готовые сервисы вроде почты, где клиент не управляет инфраструктурой, а просто пользуется конечным решением.
Максим Долгинин уверен, что в облаке удобство часто перевешивает осторожность, а главные угрозы — это мисконфигурации (ошибочные настройки), небезопасные образы, простые пароли, случайно открытый доступ и избыточные права. Всё это делает облачную инфраструктуру лёгкой добычей для атакующих.
Рами Мулейс добавил, что облачную инфраструктуру так же легко захватить, как и обычную локальную, если ею целенаправленно не заниматься. Сегодня достаточно простой ошибки в настройках или украденных учётных данных, чтобы проникнуть внутрь.
Андрей Семенюченко обратил внимание: модель угроз и риски в облаке напрямую зависят от того, какие данные и приложения туда помещаются. Одно дело — хранить в облаке резервную копию, и совсем другое — запустить там полноценный ИИ-сервис, интегрированный с нативными облачными сервисами. Риски в этих двух сценариях сильно различаются, и это необходимо тщательно анализировать.
Андрей Семенюченко, руководитель управления решений для корпоративных заказчиков, «Лаборатория Касперского»
Реальные провалы в защите облаков
Андрей Семенюченко привёл примеры из 2024–2025 годов. Всё началось с Amazon Web Services: злоумышленники просканировали большое количество облачных сред и нашли много файлов .env (в них хранятся переменные окружения) на веб-серверах. Там оказалось много чувствительных данных, в том числе IAM-ключи. С помощью этих ключей создавали IAM-роли, затем запускали лямбда-функции и сканировали облачную инфраструктуру на предмет других, ещё более чувствительных переменных. В итоге похитили большое количество данных, а злоумышленники требовали выкуп. В 2025 году то же самое произошло с GitHub.
Демид Балашов рассказал о случае из своей практики: в компании создали файловую шару для регламентных и безобидных задач. Она быстро распространилась как удобный способ обмена данными. А через полгода, когда запустили процесс инвентаризации данных, выяснилось, что там уже лежали коммерческие документы и договоры с подрядчиками. Хорошо, что это не успело выйти за контур.
Демид Балашов, руководитель по развитию продуктов кибербезопасности, «МегаФон ПроБизнес»
Максим Долгинин поделился кейсом из криптоиндустрии. Одна компания, торгующая NFT, мигрировала в облако, но не подключила к проекту DevOps-инженеров, отвечающих за безопасность. Решили сделать это через полгода. А через три месяца — минус миллион долларов в криптовалюте. Не пропатчили уязвимость на фронтенде, через неё злоумышленники проникли внутрь, получили широкие права, вышли из контейнеров и вывели деньги.
Рами Мулейс коротко описал типичную проблему: выходящий наружу OpenSearch и рядом с ним сервисный аккаунт с административным доступом в облако.
Михаил Захряпин отметил, что часто облака взламывают не из-за одной простой мисконфигурации, а из-за совокупности факторов. Он привёл случай из практики: была виртуальная машина, на которой до сих пор оставалась уязвимость Log4j. Машина имела доступ к интернету через балансировщик нагрузки, публичного IP-адреса у неё не было. На этой машине хранился секрет в открытом виде — токен от всего облака. Получался путь атаки, при котором можно получить доступ к машине, проэксплуатировать уязвимость и выполнить боковое движение (переход на другие ресурсы). Часто атаки в облаке состоят из нескольких шагов — это не одна ошибка в настройках.
Михаил Захряпин, генеральный директор, Cloud Advisor
Станислав Погоржельский добавил, что заказчики часто пытаются работать с облачной инфраструктурой и могут не знать о возможностях, заложенных на уровне API. Стоит внимательно относиться к регуляторным требованиям: были случаи, когда компании планировали строить облачную инфраструктуру на базе зарубежного решения, но регулятор разрешал только отечественные решения.
В первом опросе зрители ответили, какая зона риска в публичном облаке для них сейчас самая критичная:
- Утечки данных и незащищённые хранилища — 28 %.
- Незащищённые API и внешние интеграции — 23 %.
- Избыточные права, IAM и сервисные аккаунты — 21 %.
- Shadow Cloud: неучтённые ресурсы и личные аккаунты — 11 %.
- ИИ-агенты и автоматизация с доступом к облаку — 7 %.
- Ошибки конфигурации облачных ресурсов — 6 %.
- Kubernetes, контейнеры и cloud-native-инфраструктура — 4 %.
Рисунок 2. Какая зона риска в публичном облаке для вас сейчас самая критичная?
Как оценить зрелость кибербезопасности облачного провайдера?
Денис Полянский считает, что заказчики приходят за решением своей задачи, и часто им неинтересно, из чего состоят сервисы. Один из критериев выбора — насколько провайдер готов открыто помогать, делиться экспертизой и участвовать в построении сервисов, а также его договороспособность: что он готов гарантировать и что — нет.
Сертификаты по безопасности — важный критерий, но не стоит рассматривать их как гарантию безопасности. Это один из уровней зрелости провайдера: он готов процессно подтверждать соответствие требованиям, и у него есть артефакты, которые подтверждают, что эти процессы работают. Полянский советует оценивать открытость и экспертизу провайдера, а также наличие уже реализованных похожих проектов.
Денис Полянский, директор по клиентской безопасности, Selectel
Станислав Погоржельский добавил, что стоит смотреть публичные СМИ, где выступают представители провайдера, делятся инсайтами и рассказывают, как они обеспечивают работу SOC (центра мониторинга безопасности) и какие решения используют.
Также он рекомендует изучить технологии, на которых базируется облачная среда: оркестратор, операционную систему на уровне гипервизора, виртуализацию. Эту информацию стоит запросить, чтобы понять, кто является вендором решения. Изучив всё комплексно, можно понять, какую часть облачный провайдер поддерживает сам, что поддерживают третьи стороны, а какую часть клиент может закрывать самостоятельно.
Андрей Семенюченко считает, что на сервис-провайдера нужно смотреть не только в моменте, но и в динамике. Кто-то может один раз вложиться и получить сертификаты, а дальше работать без изменений. Он советует проверить, есть ли на будущее план внешних аудитов и контрольных мероприятий для подтверждения аттестатов/сертификаций. Также важно погружаться в тему, изучать технологический стек, какие инструменты и политики используются, и сопоставлять их со своими внутренними политиками и стандартами.
Рами Муйлес уверен, что главное при выборе облачной платформы — это прозрачность: насколько провайдер открыто рассказывает о своих процессах, ограничениях, ИБ-инцидентах и внутренней архитектуре безопасности. Второй ключевой фактор — количество и качество инструментов, которые получает команда заказчика. Чем больше у неё возможностей, тем выше шансы построить действительно защищённую инфраструктуру.
Рами Мулейс, руководитель продукта Security Deck, Yandex.Cloud
Максим Долгинин отметил, что важна готовность провайдера делиться результатами аудитов. Хорошо, если провайдер использует Bug Bounty. Также он советует клиенту рассматривать не одного, а двух–трёх провайдеров.
Во втором опросе зрители ответили, какую роль ИБ играет при выборе облачного провайдера в их компании:
- ИБ проверяет провайдера перед финальным решением — 32 %.
- ИБ участвует с самого начала и влияет на выбор — 23 %.
- Решение принимает ИТ или бизнес, ИБ только фиксирует риски — 21 %.
- Нет отдельной процедуры оценки облачного провайдера — 12 %.
- ИБ может заблокировать использование облака при высоких рисках — 8 %.
- ИБ подключается уже после выбора провайдера — 4 %.
Рисунок 3. Какую роль ИБ играет при выборе облачного провайдера в вашей компании?
Безопасное облако по умолчанию — это миф?
Андрей Семенюченко привёл в пример крупнейшую утечку данных, которая произошла в марте 2019 года и затронула более 100 миллионов американских и 6 миллионов канадских клиентов банка Capital One. Хакер использовал уязвимость, связанную с неправильно настроенным межсетевым экраном в облачной среде Amazon Web Services (AWS), где банк хранил свои данные. Вывод из этой истории: нужно не только использовать инструменты из облака, но и правильно их настраивать.
Демид Балашов считает, что безопасность по умолчанию — это миф, потому что практически нет такой пары «клиент — провайдер», когда по умолчанию всех всё устраивает. Это всегда процесс настройки и конфигурации. Безопасность — предмет договорённости.
Денис Полянский пояснил, что публичное облако — это набор сервисов с разным разграничением зон ответственности, и нельзя сказать, что все они одинаково безопасны. Он советует обратить внимание на набор дополнительных сервисов безопасности, которые предоставляет провайдер, чтобы закрывать клиентский гэп.
Максим Долгинин отметил, что дефолтное облако удобно тем, что позволяет быстро развернуться. Но обеспечить безопасность по умолчанию сложно, потому что у всех разная инфраструктура, требования, пожелания и бизнес-задачи. Облако должно предоставлять инструменты, чтобы заказчик мог обеспечить безопасность сервисов, которые он использует.
Максим Долгинин, руководитель направления развития продуктов кибербезопасности, Cloud.ru
Рами Муйлес уверен, что дефолтное безопасное облако — это облако, которым будет очень сложно пользоваться. Он упомянул отдельный проект «Яндекса», который постоянно отслеживает UX и смежные сервисы. Подход Secure Cloud by Design внедряют так, чтобы не ухудшать пользовательский опыт. Это кропотливая работа, но ей нужно заниматься.
Михаил Захряпин различает безопасность провайдера и безопасность пользователя. Если смотреть на статистику мировых ИБ-инцидентов, 99 % происходят в зоне ответственности пользователя. Провайдеры по уровню защиты примерно одинаковы — все предоставляют достаточно защищённую инфраструктуру. Основная проблема при использовании публичного облака обычно находится в зоне ответственности пользователя. Там нужно проводить соответствующие работы — тогда безопасное облако перестанет быть мифом и станет реальностью.
Станислав Погоржельский добавил, что безопасное облако по умолчанию — это миф. На старте отношений провайдер ничего не знает о заказчике: ни о его данных, ни о задачах, ни о требованиях к безопасности.
В третьем опросе зрители ответили, какие меры защиты облака у них уже внедрены или планируются в первую очередь (мультивыбор):
- MFA, IAM и контроль привилегированных доступов — 62 %.
- Инвентаризация ресурсов и контроль конфигураций — 28 %.
- CSPM/CNAPP для поиска рисков и ошибок конфигурации — 28 %.
- Защита API и внешних интеграций — 19 %.
- Централизованный сбор логов, SOC и реагирование — 13 %.
- DLP/шифрование и контроль данных в облаке — 7 %.
Рисунок 4. Какие меры защиты облака у вас уже внедрены или планируются в первую очередь?
Какие экспертные услуги по кибербезопасности покупать у провайдера?
Андрей Семенюченко: «В облаке традиционно покупают IAM, WAF и сетевой экран уровня L4. Остальные сервисы — CSPM, CNAPP — приобретают по желанию заказчика».
Демид Балашов: «Анти-DDoS однозначно должен быть на стороне провайдера. Кроме того, клиенту нужна экспертиза по архитектуре, выстраивание процессов, определение границ ответственности и риск-менеджмент. Всё это необходимо объяснять заказчику, если он не сталкивался с облаками и у него нет внутренней экспертизы».
Денис Полянский: «В первую очередь стоит использовать сервисы, связанные непосредственно с облаком: IAM, средства мониторинга и инвентаризации. Анти-DDoS можно подключать опционально — если требуется повышенная отказоустойчивость».
Максим Долгинин: «Важно понять, что именно нужно защищать прямо сейчас и с помощью каких средств. Поэтому CNAPP для публичного облака — ключевой сервис, который даёт ответы на эти вопросы».
Рами Муйлес: «Нужно попросить облачного провайдера провести чек-ап и составить список задач, с которых стоит начать. Для зрелого клиента, у которого есть ресурсы и понимание своих потребностей, подойдёт YCDR (Yandex Cloud Detection and Response). Для защиты приложений — Smart Web Security. Для управления учётными записями — Identity Hub. И не забывайте про базовые вещи: шифрование и аудит-трейлы».
Михаил Захряпин: «Мы выпустили карту облачных рисков — документ, где перечислены все основные угрозы. CISO может использовать её, чтобы выявить дефициты в решениях. У провайдера есть как собственные средства, так и вендорские продукты. Стоит сравнить их и выбрать, у кого лучше приобрести — модели тарификации могут различаться».
Станислав Погоржельский: «На месте заказчика мне была бы интересна модель Zero Trust, обогащённая данными из облака: когда провайдер передаёт все логи событий о действиях пользователя в личном кабинете. Это позволяет заказчику в рамках своего SOC обогатить модель Zero Trust и оперативно реагировать на такие события».
Станислав Погоржельский, технологический евангелист VK Cloud&Data, VK Tech
Как будет меняться спектр услуг кибербезопасности облачных провайдеров?
Максим Долгинин: «Задача безопасности — стать прозрачной для клиента, чтобы он касался её по минимуму. При этом безопасность должна быть обеспечена на всех уровнях взаимодействия с облаком».
Денис Полянский: «Роль провайдера в обеспечении безопасности клиента будет расти. Когда клиенты увидят, что провайдер готов помогать и делиться экспертизой, это позволит увеличить использование облачных сервисов. Спрос на защищённые инфраструктуры будет расти».
Рами Муйлес: «Нужен инструмент на основе ИИ, который ускорит принятие решений и поможет пользователю действовать быстрее».
Михаил Захряпин: «Рынок движется к постепенной адаптации CNAPP-решений — они будут появляться у вендоров и облачных провайдеров. Необходим единый центр безопасности облака: панель, где можно увидеть риски, уязвимости и инструкции по их устранению. Этот продукт будет смещаться в сторону кода, чтобы охватить весь цикл — от написания кода до работы в облаке».
Станислав Погоржельский: «Облачные провайдеры уже взяли на себя роль гипервизора. В дальнейшем они возьмут на себя следующий уровень ответственности: будут передавать заказчику меньше функций и снижать вероятность взлома. Провайдер может объяснять, как это работает, но сам механизм остаётся закрытым от клиента. Это центр компетенций: он занимается информационной безопасностью, защитой каналов связи, разрабатывает решение, поддерживает его и берёт на себя замкнутый контур. Только так можно снизить количество уязвимостей в будущем».
Андрей Семенюченко: «Мы попробовали натравить LLM-модель на Kali Linux — она перебирает все возможные способы взлома любой инфраструктуры. Концепции Shift-Left и Shift-Down набирают обороты: уязвимости нужно находить и устранять на самом раннем этапе, встраивая безопасность прямо в платформу.
У нас есть кибериммунная операционная система на собственном микроядре с нулевым доверием: все компоненты изолированы, любые неавторизованные действия блокируются, поэтому компрометация одного компонента не ведёт к компрометации всей системы. Всем стоит двигаться в эту сторону».
Демид Балашов: «Клиенту нужны не отдельные сервисы — он хочет решить задачу, совершить цепочку действий. На примере телекома: им нужен не просто канал, а непрерывный, надёжный и безопасный доступ к сервису. С точки зрения облачных ресурсов, клиенту должно быть всё равно, уязвима машина или нет, потому что уязвимость закроется на одном из циклов. За счёт этой цепочки работы провайдера можно попытаться закрыть разрыв на границе ответственности клиента и провайдера, вытащив часть экспертизы на свою сторону».
Финальный опрос показал, планируют ли зрители усиливать безопасность своих сервисов в публичном облаке после эфира:
- Учтут требования ИБ при запуске новых облачных проектов — 36 %.
- Будут усиливать текущую защиту — 29 %.
- Возможно, но пока это не приоритет — 17 %.
- Пока не используют публичное облако — 11 %.
- Нет, текущий уровень защиты устраивает — 7 %.
Рисунок 5. Планируете ли вы усиливать безопасность ваших сервисов в публичном облаке после эфира?
Выводы
Публичные облака — это зрелая и во многом безопасная среда, но только при условии, что клиент не перекладывает всю ответственность на провайдера. Конечная безопасность всегда остаётся общей ответственностью. Главные уязвимости, как показывает практика, возникают не из-за слабостей облачных платформ, а из-за ошибок конфигурации, избыточных прав доступа, утёкших учётных данных и невнимательности при развёртывании сервисов.
Выбор облачного провайдера не должен сводиться к сравнению цен или списка доступных сервисов. Ключевые критерии — прозрачность, готовность делиться экспертизой, открытость результатов аудитов и чёткое разграничение зон ответственности. Клиенту стоит смотреть не только на текущие сертификаты, но и на динамику: есть ли у провайдера план внешних аудитов, как развиваются его собственные инструменты безопасности, насколько глубоко он позволяет заказчику погружаться в технологический стек.
Эксперты сходятся во мнении, что рынок будет двигаться в сторону CNAPP-решений, единых панелей управления безопасностью и встраивания защиты на всех этапах — от написания кода до эксплуатации в облаке. Роль провайдера в обеспечении безопасности клиента будет расти, а искусственный интеллект постепенно станет инструментом, который ускоряет принятие решений и поиск уязвимостей. При этом сами провайдеры будут брать на себя всё больше функций, чтобы снизить нагрузку на клиента и уменьшить количество человеческих ошибок.
Облака, как любая другая среда, требуют вдумчивого подхода, регулярного аудита и постоянного обучения. Те, кто выстраивает системную работу с безопасностью с самого начала, получают гибкость, масштаб и конкурентное преимущество.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
