Мы как провайдер IT-инфраструктуры работаем с компаниями из разных отраслей и часто сталкиваемся с одним вопросом, когда речь заходит о безопасности: кто именно отвечает за безопасность в облаке — провайдер или клиент?
За последние годы компании массово переходят на использование облачных услуг в формате IaaS-, PaaS- и SaaS-моделей. Облако упрощает запуск и масштабирование сервисов, но вместе с этим резко возрастает значимость корректного разграничения зон ответственности в области ИБ. Это уже не формальная строка в договоре, а полноценный фактор риска — юридического, финансового и репутационного.
Если модель ответственности не зафиксирована или определена неверно, при инциденте возникают споры: кто должен был настроить защиту, установить обновления, ограничить доступ или уведомить регулятора. В итоге компания может столкнуться со штрафами, судебными разбирательствами и потерей доверия клиентов, даже если технически «виновата» не только она.
Модель разграничения ответственности
Классический подход к разграничению ответственности в облаке выглядит так: поставщик облачных услуг отвечает за безопасность облачной инфраструктуры, а клиент — за то, как он ее использует, какие сервисы разворачивает и какие данные хранит. Конкретное распределение зависит от сервисной модели и должно быть корректно задокументировано.
Важно понимать, что набор обязанностей меняется в зависимости от того, по какой модели предоставляется сервис — IaaS, PaaS или SaaS. Рассмотрим их по порядку.
IaaS
В модели Infrastructure as a Service провайдер предоставляет и защищает:
- физическую инфраструктуру ЦОД (помещения, оборудование, инженерные системы);
- виртуальный слой (гипервизор);
- базовую сетевую инфраструктуру;
- соответствие общепринятым стандартам безопасности.
Клиент в свою очередь берет на себя ответственность за следующие аспекты:
- операционные системы и виртуальные машины;
- прикладное программное обеспечение;
- конфигурацию сети;
- управление учетными записями, доступами и прочими процессами ИБ.
PaaS
В модели Platform as a Service провайдер, помимо перечисленного для IaaS, обеспечивает:
- платформу и сервисы для разработки и запуска приложений;
- часть middleware (СУБД как сервис, брокеры сообщений, веб‑платформы и т. д.);
- управление и обновление платформенного ПО.
Клиент, в свою очередь, отвечает за:
- разработку и безопасность собственных приложений;
- конфигурацию параметров платформы в пределах доступных настроек;
- управление доступами и ролями пользователей;
- защиту и корректную обработку данных.
SaaS
В модели Software as a Service провайдер закрывает почти все уровни:
- инфраструктуру и виртуализацию;
- платформу и middleware;
- само приложение, его обновления и эксплуатацию.
При этом клиент остается ответственным за часть аспектов:
- управление доступом пользователей (роль, права, MFA);
- политику паролей и идентификацию;
- корректную настройку параметров безопасности в интерфейсе SaaS‑сервиса;
- защиту и законность обработки собственных данных внутри сервиса.
Миф о том, что при использовании SaaS «за всю безопасность отвечает провайдер», опасен: ошибки в настройках доступа или некорректное предоставление прав пользователям остаются целиком на стороне клиента.
Подробнее о разнице между моделями — в отдельном тексте. Рекомендую ознакомиться, если чувствуете, что не хватает контекста о преимуществах и особенностях IaaS, PaaS, SaaS.
Почему важно закрепить модель документально
Как я упоминал ранее, если модель разделения ответственности не закреплена в официальном документе (договор, SLA, приложение, матрица ответственности), при инциденте неизбежно возникает коллизия: каждая сторона будет пытаться переложить ответственность на другую.
Для примера можно взглянуть, как документированная модель разграничения используется в сервисах Selectel. Она оформлена в виде матрицы по продуктам и уровням, где по каждому пункту (патчи, шифрование, сетевые настройки, мониторинг и т. д.) однозначно указано, кто отвечает: клиент, Selectel или обе стороны.
Примеры типичных инцидентов
Чтобы увидеть, как это работает на практике, рассмотрим несколько типичных ситуаций.
Первый случай. Компрометация серверов поставщика услуг S3, которая повлекла за собой доступ к S3-хранилищу банка. В этом случае будет явно виноват поставщик, однако разбирательства могут затянуться, если зоны ответственности клиента и поставщика не будут сформулированы.
Второй случай. Несвоевременное обновление ОС на облачных серверах, которые предоставляются в рамках IaaS, повлекли за собой компрометацию клиента облачных услуг. Здесь уже явно должна быть проведена черта, где заканчивается ответственность клиента, а где — поставщика.
Во всех этих случаях правильно оформленная матрица ответственности априори сняла бы многие вопросы и позволила быстрее перейти к расследованию и устранению последствий, а не к «взаимным обвинениям».
Разграничение с юридической точки зрения
С юридической точки зрения разграничение зон ответственности нужно как минимум по трем основным причинам.
Доказательная база при инциденте
В случае инцидента клиент должен показать, что выполнил все возложенные на него меры защиты, а поставщик — что обеспечил заявленный договором уровень безопасности своей инфраструктуры и не видит проблемы на своей стороне. Корректно описанная модель ответственности становится частью доказательной базы.
Снижение договорных рисков
Без ясного распределения обязанностей договор об облачных услугах фактически содержит отложенный конфликт интересов, который проявится при первом серьезном инциденте. Никто не хочет остаться единственным ответственным за штрафы и потери из‑за того, что меры защиты были реализованы не в полном объеме или не теми, кто должен был их реализовать.
Соответствие требованиям регуляторов и стандартов
Документированное разграничение зон ответственности помогает выполнять требования регуляторов и отраслевых стандартов (например, PCI DSS, ISO/IEC 27001, ГОСТ 57580.1), которые допускают аутсорсинг, но не допускают «переноса ответственности на облако» в целом.
Стандарты и требования регуляторов в аутсорсинге
Разные регуляторы и стандарты по‑разному формулируют требования к использованию облачных сервисов и аутсорсингу, но общий смысл похож.
PCI DSS допускает использование облачных сервисов, но не снимает ответственность с организации, обрабатывающей данные держателей платежных карт.
ГОСТ 57580.1, применяемый в финансовом секторе, изначально ориентирован на владельца информационной инфраструктуры и, как уже говорили ранее, не содержит понятия «переноса ответственности на облако». Даже если часть функций передана внешнему провайдеру, ответственность за соблюдение требований остается у владельца.
Требования ФСТЭК и стандарт ISO/IEC 27001 также допускают привлечение внешних поставщиков, но при этом требуют:
- оценки поставщика с точки зрения безопасности;
- фиксации распределения обязанностей в договоре;
- контроля выполнения переданных функций.
Ключевой принцип всех этих документов одинаков: аутсорсинг и использование облака не освобождают от ответственности. Выбирая облачного провайдера важно убедиться, что он может подтвердить соответствие своих услуг необходимым требованиям (сертификаты, аттестаты, отчеты о проверках) и предоставить прозрачную модель распределения обязанностей.
Частые ошибки
Рассмотрим несколько типичных ошибок при оформлении и работе с моделью ответственности.
Общая или неактуальная матрица ответственности по всем предоставляемым услугам. Необходимо всегда понимать и держать в голове: что изменилось в услуге и применимы ли пункты из этой матрицы к действительной схеме предоставления.
Недостаточные формулировки. Общие формулировки могут сбить с толку или вызвать затруднения при разборе инцидента ИБ. При возможности нужно максимально исчерпывающе описать ту зону ответственности, за которую, извиняюсь за тавтологию, отвечаете вы. Особенно это важно, когда вы разделяете ответственность между собой и клиентом.
Помимо матрицы ответственности, необходимо иметь сформулированное понимание внутри: какие работники и отделы отвечают за отдельные процессы. Так вам будет проще координировать работу в случае инцидента.
Как правильно зафиксировать зоны ответственности
Чтобы модель ответственности работала, ее недостаточно проговорить на словах — она должна быть оформлена и поддерживаться в актуальном состоянии. Несколько ключевых рекомендаций:
- Изучите свои услуги внимательно как с точки зрения поставщика, так и клиента.
- Соберите типовое понимание услуги (IaaS, PaaS, SaaS и т. д.) и требования ИБ, которым вы соответствуете. Это станет основой для матрицы разделения ответственности.
- Согласуйте матрицу с ИБ-отделом на предмет того, за что вы действительно отвечаете, а также с юристами — на предмет исчерпывающих формулировок.
- Доступ к этому документу должен быть у клиентов и у ответственных команд, которые отвечают за определенные зоны ответственности.
- Регулярно обновляйте готовый документ. Делать это нужно для поддержания его актуальности, чтобы при изменении услуги не создалась коллизия, когда ответственность была переложена на клиента или наоборот, а ответственные не осведомлены.
Заключение
Разграничение зон ответственности в сфере информационной безопасности между поставщиком облачных услуг и клиентом — это, с одной стороны, юридический вопрос, а с другой — важный инструмент управления рисками. Корректно и документально закрепленная модель ответственности:
- снижает вероятность спорных ситуаций при инциденте;
- помогает выполнить требования регуляторов и стандартов;
- делает процессы информационной безопасности более прозрачными и управляемыми;
- позволяет эффективнее использовать аутсорсинг, не теряя контроля над рисками.
Облако не освобождает от ответственности за безопасность, но при грамотном выборе провайдера и корректно оформленной модели shared responsibility помогает перераспределить ее так, чтобы каждая сторона занималась тем, что умеет лучше всего.
