Модель общей ответственности: IaaS, PaaS, SaaS

Облачные сервисы предоставляются в трех основных моделях, каждая из которых предлагает свой уровень абстракции. Infrastructure as a Service (IaaS) предоставляет необработанные вычислительные ресурсы, хранилище и сетевую инфраструктуру. Platform as a Service (PaaS) добавляет OS, промежуточное программное обеспечение и среды выполнения. Software as a Service (SaaS) предоставляет полностью функциональные приложения через интернет. Понимание этих моделей необходимо, поскольку обязанности по обеспечению безопасности в них существенно различаются.

Модель разделения ответственности определяет, какие задачи безопасности обязан выполнять поставщик Cloud, а какие относятся к заказчику. Обычно модель кратко описывают так: поставщик отвечает за безопасность самого Cloud (физические центры обработки данных, гипервизоры, сетевую инфраструктуру), а заказчик — за безопасность внутри Cloud (данные, управление доступом, безопасность приложений и конфигурацию). Непонимание этой границы — одна из основных причин инцидентов безопасности в Cloud.

В IaaS заказчик принимает на себя наибольшую ответственность за безопасность. Поставщик Cloud защищает физическую инфраструктуру, гипервизор и сетевую структуру. Заказчик отвечает за: установку OS, установку исправлений и усиление защиты; настройку среды выполнения и промежуточного программного обеспечения; безопасность приложений; правила групп сетевой безопасности; политики IAM и управление пользователями; шифрование данных в состоянии покоя и при передаче; а также настройку соответствия требованиям. IaaS предоставляет максимальный контроль, но требует максимальных усилий по обеспечению безопасности.

В PaaS поставщик берет на себя управление OS и средой выполнения. Заказчику больше не нужно устанавливать исправления для операционной системы или управлять промежуточным программным обеспечением — этим занимается поставщик. Однако заказчик по-прежнему отвечает за: безопасность кода приложения (отсутствие SQLi, XSS и т. д.), классификацию и шифрование данных, управление удостоверениями и доступом, конфигурацию приложения (переменные среды, управление секретами) и безопасность API. PaaS передает поставщику часть обязанностей, позволяя заказчикам сосредоточиться на логике приложения.

В SaaS поставщик управляет почти всем. Основные обязанности заказчика по безопасности: управление доступом (кто имеет учетные записи, обязательное использование MFA, проверка разрешений), управление данными (какие данные загружаются и как долго хранятся), безопасность конфигурации (настройки конфиденциальности, разрешения на совместный доступ, интеграции со сторонними системами) и соблюдение правил допустимого использования. Многие инциденты утечки данных в SaaS происходят из-за неправильно настроенных параметров совместного доступа или чрезмерных разрешений сторонних приложений, а не из-за сбоев поставщика.

Некоторые меры контроля являются совместными и распределяются между провайдером и заказчиком. Например, шифрование: облачный провайдер может предоставлять сервисы шифрования (KMS, шифрование по умолчанию), но заказчик должен включить их, настроить управление ключами и выбрать подходящие алгоритмы. То же относится к управлению удостоверениями: провайдер предоставляет инструменты IAM, но заказчик должен настроить политики минимальных привилегий и обеспечить обязательное использование MFA. Распространённая и опасная ошибка — считать, что провайдер отвечает за совместную меру контроля, и не настраивать её самостоятельно.

Модель совместной ответственности чаще всего даёт сбой из-за неправильной конфигурации со стороны заказчика, а не из-за отказов провайдера. Классические примеры: общедоступные bucket S3 (утечка Capital One в 2019 году, раскрыто 100 млн записей), чрезмерно разрешающие роли IAM, допускающие повышение привилегий, группы безопасности с правилами входящего трафика 0.0.0.0/0 для важных портов и неизменённые учётные данные по умолчанию в базах данных, развёрнутых в облаке. Базовая инфраструктура провайдера была защищена, а конфигурация заказчика — нет.

Одна из ключевых проблем совместной модели — видимость. В локальных средах команды безопасности контролируют все журналы. В облаке журналы инфраструктуры провайдера могут быть недоступны. Заказчики должны включать облачные сервисы ведения журналов: AWS CloudTrail, Azure Monitor и GCP Cloud Audit Logs фиксируют вызовы API и изменения конфигурации. Если эти сервисы не включить, у организации не будет журнала аудита, показывающего, кто и что делал в её облачной среде, — это серьёзный пробел в обеспечении соответствия требованиям и проведении криминалистического анализа.

Когда организации привлекают поставщиков управляемых сервисов (MSP) для эксплуатации облачных сред, ответственность распределяется между тремя сторонами. Заказчик должен убедиться, что в договорах (SLA и DPA) чётко определены обязательства по безопасности. Сторонние облачные приложения, доступ к которым осуществляется через SaaS, вносят дополнительную сложность: согласие OAuth, предоставленное приложению с чрезмерными разрешениями, даёт этому приложению доступ к вашим данным. Проверка и регулярный аудит согласий OAuth для сторонних приложений — часть базовой практики обеспечения безопасности SaaS.

Требования соответствия не исчезают из-за переноса рабочих нагрузок в облако. HIPAA требует заключить соглашение Business Associate Agreement (BAA) с облачными провайдерами, обрабатывающими PHI; AWS, Azure и GCP предоставляют BAA. PCI-DSS требует, чтобы облачная среда входила в область оценки; матрицы совместной ответственности провайдеров документируют, какие меры контроля PCI выполнены. Чтобы пройти аудит, организации должны понимать, что покрывает провайдер, а что им необходимо реализовать самостоятельно.

Модель совместной ответственности имеет юридическую силу. Условия предоставления услуг облачного провайдера и соглашения об уровне обслуживания (SLA) определяют гарантии доступности и исключения. Соглашения об обработке данных (DPA) в соответствии с GDPR определяют обязанности обработчика. Если утечка произошла из-за сбоя на стороне провайдера, заказчик имеет основания требовать предусмотренные SLA меры защиты. Если утечка вызвана неправильной конфигурацией заказчика, провайдер ответственности не несёт. Понимать договоры не менее важно, чем понимать технические меры контроля.

Проверьте понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

В этом уроке Вы узнали, что модель совместной ответственности определяет обязательства провайдера и заказчика по обеспечению безопасности в IaaS, PaaS и SaaS, в IaaS на заказчика возлагается большая часть ответственности за безопасность, а в SaaS — меньшая, но управление доступом и управление данными всегда остаются его задачами, а неправильная конфигурация заказчика, а не сбой провайдера, является основной причиной утечек в облаке. Далее мы рассмотрим безопасность облачного хранилища и риски раскрытия данных.