Краткий обзор
Самое опасное предположение в проектах облачной миграции — что вместе с инфраструктурой провайдеру передаётся и ответственность за безопасность. Широко цитируемый прогноз Gartner — «к 2025 году 99% сбоев облачной безопасности будут происходить по вине клиента» — подтвердился на практике: инфраструктура крупных облачных провайдеров взламывается редко; взламываются пробелы, которые клиент оставил в собственной зоне ответственности.[1]
Стоимостная сторона указывает в том же направлении. По данным отчёта IBM Cost of a Data Breach 2025, средняя мировая стоимость утечки составляет 4,44 миллиона долларов; утечки, затрагивающие данные в нескольких средах, держатся выше среднего.[2] Яркая находка отчёта IBM 2023 года проясняет картину: 82% исследованных утечек включали данные, хранившиеся в облаке.[3] По исследованию Flexera, около 89% организаций используют больше одного облака — то есть эта поверхность риска является проблемой не отдельного провайдера, а несогласованности между средами.[4]
Этот отчёт исследует самый неправильно понимаемый уровень модели разделения ответственности: доставку и защиту приложений. Он раскладывает матрицу ответственности слой за слоем, перечисляет самые частые ошибки конфигурации уровня приложений, которые мы видим на практике, и анализирует, почему дрейф политик в гибридных средах — самый незаметный пробел.
Облачный пробел безопасности в цифрах
Доля клиента в сбоях облачной безопасности (прогноз Gartner)
Мировое среднее (IBM 2025)
Доля среди исследованных утечек (IBM 2023)
Организации, использующие больше одного облака (Flexera)
Модель проста — её интерпретация нет
Сама модель разделения ответственности не сложна: провайдер отвечает за безопасность облака, клиент — за безопасность того, что находится в облаке. Сложность рождается из того, что с изменением сервисной модели граница сдвигается, а организации считают её выше, чем она есть. В IaaS всё, начиная с операционной системы, принадлежит клиенту; в PaaS платформа переходит к провайдеру, но конфигурация приложения — нет; даже в SaaS классификация данных, политики доступа и конфигурация идентификации остаются за клиентом.
Критический момент таков: в какой бы модели вы ни находились, контроль трафика, идущего к вашему приложению, — кто получает доступ, какой запрос легитимен, какие данные уходят наружу — никогда не переходит к провайдеру. Провайдер может предложить вам инструменты; ответственность он не забирает.
Матрица ответственности: слой за слоем
| Уровень | IaaS | PaaS | SaaS |
|---|---|---|---|
| Физическая инфраструктура и гипервизор | Провайдер | Провайдер | Провайдер |
| Сетевые контроли | Совместно | Совместно | Провайдер |
| Операционная система и middleware | Клиент | Провайдер | Провайдер |
| Политики приложений и трафика | Клиент | Клиент | Совместно |
| Данные, идентификация и конфигурация доступа | Клиент | Клиент | Клиент |
Самые частые ошибки уровня приложений на практике
Ошибки, питающие облачные инциденты, не экзотичны; одни и те же шаблоны повторяются. В рейтингах угроз Cloud Security Alliance неправильная конфигурация и недостаточный контроль изменений годами занимают верхние строки.[5] Чаще всего на практике мы видим:
WAF, забытый в режиме обнаружения
Политики WAF, переведённые на время миграции в режим обнаружения — «сначала понаблюдаем», — в спешке запуска так и не переключаются в режим защиты. Организация считает себя защищённой; WAF лишь пишет логи.
Чрезмерно широкие сетевые правила
Широкие правила NSG/групп безопасности, открытые для отладки, становятся постоянными. «Временные» исключения 0.0.0.0/0 оставляют неинвентаризированные интерфейсы управления открытыми в интернет.
Нешифрованный трафик после терминирования
TLS терминируется на балансировщике нагрузки, а во внутренней сети трафик идёт открытым текстом. Понятие «внутренняя сеть» в облаке проницаемее, чем в дата-центре; нешифрованный east-west трафик — самый тихий пробел в вашей зоне ответственности.
API-эндпоинты вне инвентаря
Каждый перенесённый в облако микросервис порождает новые API-эндпоинты. Необнаруженные эндпоинты без схемы остаются вне покрытия WAF; атакующие любят недокументированные эндпоинты больше документированных.
Дрейф правил между средами
Набор правил, годами тонко настраивавшийся on-prem, «приблизительно» транслируется в другой движок в облаке. Два движка принимают разные решения по одному и тому же запросу; какая из сред права — не знает никто.
Конфигурация идентификации по умолчанию
Условный доступ, принудительная MFA и политики сессий оставляются в значениях по умолчанию «до последующего ужесточения». Идентификация в облаке заняла место сетевого периметра; настройки идентификации по умолчанию — это периметр по умолчанию.
Самый распространённый гибридный пробел безопасности — не CVE, а ошибка процесса: зрелость в дата-центре, значения по умолчанию в облаке. Пока on-prem копия приложения стоит за строгой политикой WAF, облачная копия месяцами работает с базовым набором сигнатур. Атакующие сканируют обе копии и заходят через слабую. Дрейф политик со временем не исправляется сам; пока его не измеряют, он растёт.
Реальная цена гибридной сложности
Эксплуатация двух разных движков WAF — это не просто две лицензии. Это два языка правил, два списка исключений, два процесса тестирования, два набора аудиторских доказательств и две отдельные экспертизы. Команда безопасности проектирует каждое изменение дважды, дважды тестирует и дважды документирует. Эта когнитивная нагрузка проявляется в самый критический момент — во время реагирования на инцидент: ответ на вопрос «какое правило было активно в какой среде» занимает не минуты, а часы.
На стороне аудита цена ещё заметнее. PCI DSS, KVKK/GDPR и отраслевые регуляции требуют аудиторских доказательств для каждой среды в периметре аудита. Доказывать одну и ту же защиту в двух разных продуктах двумя разными способами кратно увеличивает время подготовки к аудиту; находки о несогласованности чаще всего рождаются из различий интерпретации между двумя продуктами.
Мультиоблако увеличивает эту картину не линейно, а мультипликативно. Данные Flexera показывают, что подавляющее большинство организаций использует больше одного облака;[4] каждая новая среда приносит новый набор встроенных сервисов безопасности и новый язык конфигурации. С ростом числа сред утверждение «одинаковая защита в каждой среде» становится неотстаиваемым, если оно построено на уровне инструментов, а не на уровне политик.
Выводы для защиты
Составьте инвентарь потоков данных
Какое приложение в какой среде к каким данным обращается и кто контролирует его трафик? Без инвентаря матрица ответственности остаётся на бумаге.
Зафиксируйте матрицу ответственности письменно
Явно задокументируйте границу провайдер/клиент для каждой сервисной модели и не оставляйте бесхозных уровней. Предположение «этим занимается провайдер» подтверждайте письменным обязательством.
Постройте единую плоскость политик
Запускайте один и тот же набор контролей — тот же движок WAF, тот же язык правил, тот же процесс исключений — в каждой среде. Когда трансляция правил исчезает, policy drift блокируется структурно.
Обеспечьте сквозное шифрование и видимость
Принуждайте к TLS не только на границе, но и в east-west трафике; инспектируйте шифрованный трафик, не оставляя слепых зон.
Проверяйте непрерывно
Тестируйте эквивалентность политик не раз в год на аудите, а постоянно: один и тот же запрос должен получать одно и то же решение в каждой среде. Расхождение должно быть не находкой аудита, а сигналом тревоги.
Подход TR7: одинаковая защита в каждой среде
Ответ TR7 на эту картину — работа одной и той же платформы в каждой среде:
Тот же образ в Azure Marketplace
Виртуальная платформа TR7 доступна в Azure Marketplace как готовый образ; в облаке работает тот же движок, что и на оборудовании.
Переносимость политик
Правила WAF, профили SSL/TLS и политики доступа переносятся между средами без трансляции правил; единый список исключений, единый набор аудиторских доказательств.
Переносимость лицензий
Лицензии привязаны не к платформе, а к организации; они перемещаются вместе с рабочей нагрузкой между Azure, GCP и поддерживаемыми гипервизорами.
Гибридное управление трафиком
GTM маршрутизирует трафик между on-prem и облачными плечами по состоянию, географии и задержке; выстраивает костяк поэтапной миграции.
Ссылки и источники
Источник прогноза «к 2025 году 99% сбоев облачной безопасности будут происходить по вине клиента». https://www.gartner.com/smarterwithgartner/is-the-cloud-secure
Первоисточник по средней мировой стоимости утечки (4,44 миллиона долларов) и разбивке затрат по средам. https://www.ibm.com/reports/data-breach
Находка о том, что 82% исследованных утечек включали данные, хранившиеся в облаке.
Ежегодное исследование по уровню принятия мультиоблака и корпоративным облачным стратегиям. https://www.flexera.com/blog/cloud/cloud-computing-trends-flexera-state-of-the-cloud-report/
Рейтинг угроз, в котором неправильная конфигурация и недостаточный контроль изменений занимают верхние строки. https://cloudsecurityalliance.org/research/top-threats
Официальная документация по границам ответственности провайдера и клиента для разных сервисных моделей. https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility
Одинаковая защита в каждой среде
При миграции в облако не обязательно заново выстраивать уровень безопасности. TR7 переносит политики защиты и доставки из вашего дата-центра в Azure на том же движке; обеспечивает единую плоскость политик, единое управление и единый набор аудиторских доказательств.
Изучить решение WAAP