Количество кибератак на облачные хранилища предприятий продолжает расти. По данным за январь 2026 года, 76% всех атак были направлены именно на облачные сервисы. В таких условиях понимание модели общей ответственности (Shared Responsibility Model) становится критически важным для защиты информации. Модель чётко определяет, где заканчиваются обязательства облачного провайдера и начинается зона ответственности клиента. Ошибка в интерпретации этого разграничения приводит к тому, что компании оставляют свои данные незащищёнными. Ниже разбираются ключевые положения модели, её практическое применение у трёх ведущих провайдеров (AWS, Azure, Yandex Cloud) и чек-лист, который позволит оценить реальный уровень защищённости облачной инфраструктуры
Что такое модель общей ответственности и почему её неправильное понимание критично
Модель общей ответственности — это фундаментальная концепция облачной безопасности, которая определяет, какие элементы защиты находятся в ведении провайдера, а какие — в ведении клиента. Её суть часто формулируют так: провайдер отвечает за безопасность самого облака, а клиент — за безопасность внутри облака.
Провайдер обеспечивает физическую защиту дата-центров, отказоустойчивость оборудования, безопасность гипервизора и базовой сетевой инфраструктуры. Клиент, со своей стороны, отвечает за всё, что он размещает в облаке: данные, приложения, конфигурации, управление доступом и шифрование.
Корень большинства проблем не в отказе провайдера выполнить свои обязательства, а в неверной настройке или недостаточном контроле доступа со стороны клиента. Облачная среда сама по себе не защищает от некорректной конфигурации: открытое для публичного доступа хранилище S3 или незащищённая база данных становятся уязвимостью в зоне ответственности клиента. На практике это означает, что каждая компания должна осознанно управлять своими облачными активами, а не полагаться на то, что провайдер «обо всём позаботится».
Как модель работает у разных провайдеров
Хотя общий принцип един для всех крупных облачных платформ, конкретное распределение обязанностей варьируется в зависимости от сервисной модели (IaaS, PaaS, SaaS) и особенностей конкретного провайдера. Cloud Security Alliance подчёркивает, что чёткое понимание этих различий критически важно для устранения «слепых зон» в безопасности.
AWS (Amazon Web Services). Модель явно разграничивает «безопасность облака» и «безопасность в облаке». Провайдер защищает физическую инфраструктуру, сетевое оборудование, гипервизор и базовые сервисы. Клиент отвечает за гостевые ОС, приложения, конфигурацию групп безопасности, управление доступом (IAM), шифрование данных и резервное копирование. Наиболее частые ошибки — публично доступные S3-бакеты, чрезмерно широкие разрешения IAM и отсутствие мониторинга сетевого трафика внутри VPC.
Azure (Microsoft). Принцип тот же, но есть важные особенности в части интеграции с корпоративной средой. В IaaS-модели ответственность клиента распространяется на те же элементы, что и у AWS. Однако Active Directory, выступающая основой идентификации для многих организаций, требует особенно тщательного контроля: компрометация облачной учётной записи часто становится точкой входа для атакующего. Кроме того, конфигурация сетевых групп безопасности (NSG) и управление привилегированными доступами (PIM) должны быть настроены вручную — по умолчанию эти механизмы не активированы.
Yandex Cloud. В модели IaaS провайдер берёт на себя физическую безопасность, отказоустойчивость платформы и защиту Underlay-сети, а также собирает и анализирует события безопасности гипервизоров и инфраструктурных компонентов. Клиент самостоятельно выполняет резервное копирование виртуальных машин, защищает гостевые операционные системы, настраивает виртуальную сеть (Overlay), контролирует доступ и обеспечивает сохранность учётных записей. При использовании управляемых сервисов (PaaS/SaaS) объём задач на стороне клиента сокращается, поскольку провайдер уже защищает более высокоуровневые слои инфраструктуры.
Selectel, ещё один крупный российский провайдер, описывает аналогичный подход: в IaaS-модели клиент отвечает за операционные системы и виртуальные машины, прикладное ПО, конфигурацию сети, управление учётными записями и доступами; в PaaS-модели зона ответственности клиента смещается в сторону безопасности приложений и настройки параметров платформы в пределах доступных опций.
Ключевой вывод: независимо от провайдера и сервисной модели, ответственность за данные, управление доступом и конфигурацию всегда лежит на клиенте.
Практический пример: инцидент с публичным облачным хранилищем
Средняя по размеру ИТ-компания хранила резервные копии клиентских проектов в облачном объектном хранилище, используя IaaS-модель. Администратор создал бакет для автоматической синхронизации данных и по ошибке оставил его доступным для чтения всем аутентифицированным пользователям облачной платформы. Внутренние политики требовали приватного доступа, но ручная настройка оказалась некорректной — механизм блокировки публичного доступа не был активирован.
Ошибку заметили лишь спустя три месяца в ходе планового аудита. За это время не было зафиксировано несанкционированного доступа, однако сам факт потенциальной уязвимости потребовал полной ревизии конфигураций всех облачных хранилищ компании. Инцидент не привёл к утечке, но послужил триггером для пересмотра внутренних процедур управления облачной инфраструктурой.
После инцидента компания внедрила автоматический мониторинг конфигураций облачных ресурсов, настроила оповещения о публично доступных хранилищах, активировала принудительное шифрование на стороне сервера и ввела ежеквартальный аудит IAM-политик с обязательным отзывом неиспользуемых разрешений. Кейс подтверждает, что безопасность облака — это не статическое состояние, а непрерывный процесс настройки, мониторинга и аудита.
Российская специфика: 152-ФЗ и требования к локализации
Российское законодательство накладывает на облачных клиентов дополнительные обязательства, которые отсутствуют в зарубежных юрисдикциях. Федеральный закон № 152-ФЗ «О персональных данных» требует локализации баз данных российских пользователей на территории РФ и получения явного согласия на обработку персональных данных. Ключевой вывод для бизнеса: сам по себе 152-ФЗ не запрещает использовать облачные сервисы для обработки персональных данных, но требует от оператора обеспечить их защиту и локализацию на территории России.
На практике это означает, что при выборе облачного провайдера необходимо убедиться, что его дата-центры расположены на территории РФ, а в договоре чётко прописаны обязательства по защите данных. При использовании IaaS-модели клиент самостоятельно отвечает за шифрование данных и настройку межсетевых экранов в соответствии с требованиями регуляторов. При использовании SaaS-модели ответственность провайдера возрастает, но клиент обязан проверять наличие у него необходимых сертификатов и лицензий ФСТЭК.
Российский рынок облачных услуг демонстрирует устойчивый рост, по прогнозам на 2026 год он превысит 30%. Среди ключевых драйверов — дефицит оборудования, переход бизнеса на OPEX-модель и усиление требований к кибербезопасности: по данным аналитиков, только за 2025 год количество хакерских группировок, целенаправленно атакующих отечественные компании, выросло более чем в два раза.
Чек-лист для аудита облачной безопасности
Этот перечень поможет оценить текущий уровень защищённости облачной инфраструктуры и выявить типичные проблемы до того, как они превратятся в инциденты.
- Запросить у провайдера актуальную документацию по модели общей ответственности и убедиться, что внутренние команды понимают разграничение.
- Провести инвентаризацию всех облачных ресурсов: какие сервисы используются, в какой модели, где хранятся данные, кто имеет к ним доступ.
- Проверить конфигурацию хранилищ: ни одно объектное хранилище не должно быть публично доступным без явной деловой необходимости.
- Настроить мониторинг конфигураций с оповещениями о публично доступных бакетах, открытых портах и аномальной активности IAM.
- Активировать принудительное шифрование данных на стороне сервера.
- Провести аудит IAM-политик и отозвать неиспользуемые разрешения.
- Проверить актуальность резервных копий и наличие плана восстановления.
- Убедиться, что облачные ресурсы соответствуют требованиям 152-ФЗ: данные российских пользователей локализованы на территории РФ, а в договоре с провайдером прописаны обязательства по защите ПДн.
- Настроить многофакторную аутентификацию для всех учётных записей, имеющих доступ к облачным ресурсам.
- Запланировать регулярный ежеквартальный аудит облачной безопасности и его проведение даже при отсутствии инцидентов.
Материалы канала ориентированы на специалистов по информационной безопасности и IT-руководителей. Подписывайтесь, чтобы получать актуальные методологии и разборы инцидентов.
Вопрос для обсуждения: Проводился ли аудит облачной безопасности в компании в 2026 году и какие неожиданные проблемы были обнаружены в ходе такой проверки?