Shared Responsibility Model и зачем он нужен
Приветствую, дорогой читатель!
Сегодня на повестке дня тема, без которой разговор про облачную безопасность обычно превращается в спор “кто виноват”: Shared Responsibility Model — модель разделения ответственности между облачным провайдером и клиентом.
Сразу начнём с главного. В облаке безопасность — это не кнопка “сделай безопасно”. Это договорённость: какую часть защиты обеспечивает провайдер, а какую — вы сами. И Shared Responsibility Model нужна ровно для того, чтобы эту границу обозначить. Без неё у компаний часто возникают две опасные иллюзии:
- “Раз это облако, провайдер отвечает за всё.”
- “Раз мы храним данные в облаке, значит это почти то же самое, что наш сервер — мы отвечаем за всё сами.”
Обе крайности приводят к проблемам — просто разным. В первом случае остаются дырки на стороне клиента (например, открытый доступ к данным, слабые пароли, неправильные политики доступа). Во втором — команда тратит силы на то, что уже закрыто на стороне платформы, и всё равно упускает то, что действительно важно.
Зачем всё это нужно на практике? Чтобы вы не строили безопасность на догадках. Когда происходит инцидент, почти всегда всплывают вопросы вроде: “почему это оказалось публичным?”, “кто должен был закрыть порт?”, “почему ключи утекли?”, “почему никто не заметил?”. Shared Responsibility Model заранее задаёт рамки: какие риски закрываются платформой по умолчанию, а где начинается зона ответственности клиента.
В следующей главе как раз подробнее разберём механику “провайдер vs клиент” по слоям и на понятных примерах.
Как модель разделяет ответственность: провайдер vs клиент
Что всегда на стороне провайдера (security of the cloud)
Security of the cloud — это безопасность самой облачной платформы. То, что клиент не может потрогать руками и обычно даже не видит, но на чём держится всё остальное.
Если упростить, провайдер отвечает за то, чтобы “здание” было прочным, охраняемым и обслуживаемым. А вот что вы делаете внутри помещения — об этом поговорим немного позже.
Что обычно всегда на стороне провайдера:
- Физическая безопасность дата-центров. Доступ в помещения, охрана, видеонаблюдение, контроль зон, процедуры для персонала, защита от краж и несанкционированного доступа.
- Инженерная инфраструктура. Электропитание, резервирование, генераторы, охлаждение, пожаротушение, физические каналы связи. Да, это тоже безопасность: если питание “прыгает” или охлаждение работает плохо — это риск для доступности и целостности систем.
- Базовая сеть и периметр платформы. Уровень, на котором строится backbone, сегментация, защита от типовых сетевых атак на инфраструктуру провайдера, устойчивость к DDoS на стороне платформы (в рамках того, что провайдер предоставляет как часть сервиса).
- Аппаратный слой. Серверы, дисковые массивы, сетевое оборудование, их жизненный цикл, замены, диагностика, утилизация носителей по процедурам.
- Виртуализация и “база” вычислений. Хостовая ОС, гипервизор, контроль изоляции между арендаторами (multi-tenancy), обновления и патчи того слоя, который разделяют все клиенты.
- Безопасность управляемых сервисов на уровне платформы. Если провайдер предлагает managed-сервисы (например, managed database), он отвечает за их базовую защищённость как сервиса: обновления платформенного слоя, устойчивость, внутренние процедуры реагирования на уязвимости.
И вот здесь есть неочевидный момент, на котором многие ошибаются.
Когда провайдер говорит “мы отвечаем за безопасность платформы”, это не означает, что всё, что работает на платформе, автоматически безопасно. Это означает, что провайдер отвечает за “основание”: чтобы изоляция работала, железо было под контролем, гипервизор патчился, дата-центр был защищён, а сервисы платформы не были дырявыми по умолчанию.
Но если вы, например, разворачиваете приложение и открываете его миру без нормальных правил доступа — это уже не “security of the cloud”. Платформа может быть идеально защищена, а ваша конфигурация — нет. Именно поэтому Shared Responsibility Model так важна: она не про магию, а про границы контроля.
Что всегда на стороне клиента (security in the cloud)
Security in the cloud — это всё, что вы сами создаёте, подключаете, храните и настраиваете в облаке. Даже если платформа максимально безопасна, она не может угадать вашу бизнес-логику, вашу модель доступа и то, какие данные для вас критичны. Вспоминая наш пример, это как раз таки то, что происходит внутри здания.
Чтобы было проще, мы составили таблицу о том что обычно относится к ответственности клиента и какие “типовые ошибки” встречаются чаще всего:
| Зона ответственности клиента | Что это означает на практике | Типовая ошибка (то, что ломает безопасность чаще всего) |
| Данные и их защита | Классификация данных, политика хранения, шифрование там, где нужно, резервное копирование, ретенция, правила удаления | Данные хранятся “как получилось”: без классификации, без политики удержания, без понимания, что критично |
| Доступы и роли (IAM) | Кто и что может делать, роли, least privilege, MFA, выдача/отзыв доступов, доступ подрядчиков | “Админ всем”, отсутствие MFA, доступы не отзываются после ухода сотрудников |
| Конфигурация сетей | Security groups/firewall rules, приватные/публичные подсети, открытые порты, доступ к админ-панелям | Открыли доступ “на весь интернет”, забыли закрыть админку/порт/endpoint |
| Конфигурация хранилищ | Права на бакеты/контейнеры, публичность объектов, политики доступа, lifecycle | Публичный доступ к объектам или “случайно” открытый бакет |
| Секреты и ключи | API keys, токены, сертификаты, хранение в secret manager, rotation, минимизация прав ключей | Секреты в коде/репозитории, ключи без ротации, один ключ “на всё”, ключ с административными правами для автоматизации |
| Безопасность приложений | Уязвимости в коде, зависимости, авторизация, обработка входных данных, защита API | “Облако должно защитить”, а в итоге инъекции, слабая авторизация, дырявые эндпоинты |
| Гостевые ОС и middleware (если IaaS) | Патчи внутри VM, конфиги ОС, агенты, hardening, контроль пакетов | Не обновляли систему месяцами, дефолтные настройки, лишние сервисы наружу |
| Логи, мониторинг, реагирование | Сбор логов, алерты, расследование, runbooks, доступ к журналам, аудит действий | “Логи не включали”, узнают об инциденте слишком поздно или не могут расследовать, логи не хранятся централизованно и отдельно |
| Комплаенс и политики | Внутренние требования, контроль доступа к PII, регламенты, соблюдение стандартов | Политики существуют “в документе”, но не внедрены технически |
После таблицы становится видно главное: в облаке безопасность редко ломается из-за “дырявой платформы”. Чаще она ломается из-за того, что кто-то (обычно случайно) настроил доступ слишком широко. Платформа может быть защищена идеально, но один публичный бакет, один открытый endpoint или роль “Admin для всех” — и вы сами превращаете внутренний ресурс в публичную витрину.
Отсюда второй важный вывод, который часто недооценивают: managed-сервисы не означают managed-безопасность “под ключ”. Да, провайдер берёт на себя обслуживание платформенного слоя: базовую устойчивость, часть обновлений, работу самой службы. Но решения “кто имеет доступ”, “какие данные там лежат”, “как настроены политики”, “где хранятся ключи” и “что считается нормой для вашей компании” всё равно остаются на стороне клиента. Управляемый сервис снимает рутину — но не снимает ответственность.
Именно поэтому Shared Responsibility Model работает как трезвый ориентир: провайдер отвечает за то, чтобы облако как платформа было защищено, а клиент — за то, чтобы его доступы, данные, настройки и приложения были настроены безопасно.
Как ответственность меняется по модели сервиса (IaaS / PaaS / SaaS)
Теперь самое интересное: Shared Responsibility Model — это не одна фиксированная линия. Она “ездит” в зависимости от того, какой уровень облачного сервиса вы покупаете. Чем выше уровень (чем больше “готового” даёт платформа), тем больше задач по безопасности уходит провайдеру… и тем сильнее ответственность клиента смещается в сторону доступов, данных и настроек.
IaaS: максимум свободы — максимум ответственности
IaaS (Infrastructure as a Service) — это когда облако даёт вам базовые строительные блоки: виртуальные машины, сеть, диски, иногда балансировщики и фаерволы. Дальше вы строите всё сами.
Из-за этого в IaaS ваша зона ответственности обычно самая широкая. Провайдер обеспечивает фундамент (дата-центры, железо, гипервизор, базовую платформенную сеть), а вы отвечаете почти за всё, что выше: гостевую ОС, патчи, конфигурации, приложения, секреты, правила доступа.
Если сказать ещё проще: IaaS — это “мы дали вам квартиру без мебели”. Стены прочные, подъезд охраняется, электричество работает. Но как вы поставите двери внутри, кому дадите ключи и что будете хранить — уже ваше дело.
PaaS: меньше рутины, но меньше иллюзий
PaaS (Platform as a Service) — это шаг вверх: вы получаете не только инфраструктуру, но и платформу для запуска приложений. Например, managed runtime, managed database, managed queue, managed container platform. Платформа берёт на себя больше операционной рутины: обновления уровня сервиса, часть отказоустойчивости, иногда автоматическое масштабирование.
Здесь часто рождается опасная ошибка: “раз PaaS управляемый, значит он безопасный сам по себе”. Но правильнее думать так: PaaS снимает с вас часть эксплуатации, но не снимает с вас решения.
Вы всё ещё отвечаете за:
- Кто имеет доступ (IAM, роли, MFA, least privilege),
- Какие данные лежат внутри и как они защищены,
- Какие политики доступа и сетевые правила включены,
- Как настроена конфигурация сервиса (публичность, endpoints, параметры шифрования, бэкапы),
- Что делает ваше приложение и какие у него уязвимости.
То есть PaaS делает безопасность “проще в реализации”, но не делает её автоматической.
SaaS: ответственности меньше, но ошибок по-прежнему хватает
SaaS (Software as a Service) — это когда вы покупаете готовый продукт: почта, CRM, сервис аналитики, helpdesk, документооборот и т.д. В таком формате провайдер отвечает почти за всё техническое: инфраструктуру, платформу, приложение, обновления, исправления уязвимостей.
На стороне клиента остаётся то, что ни один SaaS-провайдер не может сделать за вас:
- Управление пользователями и доступом (кто, куда и с какими правами),
- Политики безопасности (MFA, SSO, требования к паролям, условный доступ),
- Работа с данными (что загружаете, как делитесь, где храните экспорт, как удаляете),
- Процессы (как выдаёте доступ, как отзываете, как реагируете на инциденты).
И вот здесь есть неочевидная вещь: в SaaS техническая ответственность меньше, но цена ошибки доступа часто выше, потому что один скомпрометированный аккаунт может открыть доступ сразу ко всему рабочему пространству.
Если подвести микроитог главы, то стоит запомнить простое правило: чем выше уровень сервиса, тем меньше вы отвечаете за инфраструктуру и патчи — и тем больше ответственность концентрируется в IAM, данных и конфигурациях.
Типовые зоны ошибок и “серые зоны” ответственности
Вот мы и подошли к самому болезненному месту. На бумаге Shared Responsibility Model выглядит логично и красиво: тут провайдер, тут клиент, граница понятная. А в жизни большинство инцидентов рождается не в “чёрных” зонах, а в серых — там, где вроде бы “платформа же безопасная”, но один нюанс в настройке превращает это в проблему.
Давайте пройдёмся по типовым сценариям, которые встречаются чаще всего.
Первый классический провал — неправильная публичность ресурсов. Особенно хранилища и сервисы, которые “по умолчанию должны быть приватными”, но становятся публичными из-за политики доступа, ACL или случайного параметра. Это почти всегда выглядит одинаково: “мы ничего не открывали”, но по факту открыли — просто не заметили. И тут как раз работает модель ответственности: провайдер обеспечивает механизмы доступа, но решение “публично или нет” принимает клиент.
Вторая большая зона — IAM и права доступа. В облаке доступ — это новый периметр. Если раньше периметр был “сетевой” (внутри сети можно, снаружи нельзя), то теперь периметр часто “логический”: кто залогинен, какие у него роли, какие токены, какие политики. Поэтому типовые ошибки здесь банальны, но очень дорогие: чрезмерные права, отсутствие MFA, один общий аккаунт “на команду”, ключи без ротации, забытые пользователи, подрядчики с вечным доступом. Особенно опасно, когда всё это скрыто за логикой “ну это же временно”.
Третья зона — управляемые сервисы и иллюзия “managed = безопасно”. Например, managed database. Многие воспринимают её как “ну это же база, провайдер отвечает”. Провайдер действительно отвечает за платформенный слой сервиса. Но если вы сделали базу доступной из публичной сети, не включили нормальную аутентификацию, не ограничили security group, не настроили аудит — это уже не “ошибка провайдера”, это ваша конфигурация.
Четвёртая ошибка — секреты. Почти у каждой истории утечки есть скучное начало: токен в репозитории, ключ в чате, секрет в переменных окружения на ноутбуке, один “универсальный” ключ для всех сервисов. В облаке секреты живут дольше, чем кажется, и всплывают в самых неожиданных местах: в логах, в дампах, в CI/CD, в конфиг-файлах. И тут серость в том, что платформа может давать отличный secret manager, но она не может заставить команду им пользоваться.
Пятая зона — наблюдаемость и реагирование. Многие “делают безопасно” на уровне настроек, но забывают про простую вещь: безопасность — это процесс. Нужно видеть, что происходит. Кто куда входил, какие права менялись, какие ресурсы становились публичными, какие ключи использовались. В серой зоне здесь то, что провайдер часто даёт инструменты логирования и аудита, но клиент их не включает, не настраивает алерты и не знает, какие события вообще считать подозрительными.
Шестая, очень неочевидная — граница между “ответственностью” и “возможностью”. Иногда клиент думает: “раз мы не можем починить гипервизор, значит это не наше”. Да, не ваше. Но ваша ответственность — выстроить защиту так, чтобы даже при проблеме ниже уровнем ущерб был ограничен: сегментация, минимальные права, шифрование, изоляция окружений, отдельные аккаунты/проекты для dev и prod. То есть вы не чините платформу — но вы проектируете так, чтобы платформа не была единственной линией обороны.
И наконец — любимая “серая зона” всех команд: “а кто должен был это проверить?”
Провайдер часто отвечает за то, что сервис “в принципе безопасен” и имеет механизмы защиты. Клиент отвечает за то, что он эти механизмы включил и использует правильно. На стыке и рождается конфликт: одна сторона ожидает “secure by default”, другая — “secure by design со стороны клиента”.
Практический минимум: как закрыть серые зоны
Чтобы серые зоны не превращались в инциденты, нужен минимальный baseline: несколько правил, которые проверяются регулярно и не зависят от того, IaaS у вас или PaaS. Проще всего держать это в виде короткого чек-листа и прогонять его по расписанию (или хотя бы перед релизами).
| Серая зона | Минимальная защита, которая реально помогает |
| Публичность ресурсов (storage / endpoints / админки) | Запрет “public by default”, отдельные правила на публикацию, регулярный аудит публичных ресурсов |
| IAM и роли | MFA везде, least privilege, отдельные роли под задачи, регулярная ревизия доступов и быстрый offboarding |
| Managed-сервисы | Чек: ограничение сетевого доступа, включённый аудит и логирование на уровне сервиса |
| Секреты и ключи | Secret manager, rotation, запрет секретов в репозитории/чатах, отдельные ключи на окружения и сервисы |
| Логи и реагирование | Включить аудит действий, алерты на опасные события (публичность/изменение ролей/создание ключей), понятный runbook “что делать” |
| Сегментация и изоляция окружений | Раздельные окружения dev/stage/prod, раздельные аккаунты/проекты, минимальные сетевые маршруты между ними |
Проще говоря, облако не ломается само — его обычно ломают настройками. Провайдер обеспечивает платформу, но безопасность получается (или не получается) на уровне ваших прав, конфигураций и процессов. А теперь давайте подведём итог.
Заключение
Shared Responsibility Model — это про простую вещь: в облаке безопасность делится по слоям контроля. Провайдер защищает платформу и инфраструктуру, а клиент отвечает за то, как настроены доступы, данные и сервисы внутри облака.
Главная ловушка — думать, что “облако = автоматически безопасно”. На практике большинство инцидентов рождается из базовых ошибок: слишком широкие права, случайно открытые ресурсы, плохая работа с секретами, выключенный аудит.
Поэтому относитесь к Shared Responsibility Model как к рабочей карте: она помогает быстро понимать, кто за что отвечает, что нужно проверять в первую очередь и почему с переходом от IaaS к PaaS/SaaS ваша ответственность всё больше концентрируется вокруг IAM и данных.
Спасибо за внимание!
