| Слушать на Google Podcasts | Слушать на Mave | Слушать на Яндекс Музыке |
Руслан Рахметов, Security Vision
Вычислительные системы 40-50 лет назад представляли из себя мейнфреймы (высокопроизводительные на то время серверы), доступ к которым осуществлялся с терминалов (тонкие клиенты в терминологии сегодняшнего дня). Затем, с увеличением быстродействия и снижением стоимости конечных устройств, приоритет начал отдаваться использованию персональных компьютеров, при этом все высоконагруженные системы по-прежнему работали на серверах (как правило, под управлением ОС на базе UNIX). Однако уже в середине 2000-х стало очевидным, что рост цифровизации и переход бизнес-процессов в онлайн требуют гибкости при масштабировании вычислительных мощностей, снижения стоимости владения и обслуживания, а также упрощения администрирования.
Выход был найден: крупные компании стали постепенно внедрять облачные системы вычислений, что вкупе с применением технологий виртуализации и контейнеризации давало возможность уйти от привязки к физическому «железу», перейдя на новый вид абстракции при работе ИТ-систем. Затем такие облачные решения стали отдельным и достаточно прибыльным бизнесом: крупные ИТ-гиганты стали сдавать в аренду свои вычислительные мощности компаниям-арендаторам («тенантам»), которые стремились снизить свои капитальные затраты на оборудование (CAPEX) и перейти на более гибкую и прогнозируемую модель операционных расходов (OPEX) с возможностью переложить часть задач по обслуживанию инфраструктуры на специалистов Cloud-провайдеров. Публикация NIST SP 800-210 "General Access Control Guidance for Cloud Systems" («Общие рекомендации по контролю доступа к облачным системам») описывает принципы контроля доступа к облачным инфраструктурам с указанием специфики для каждой из сервисных моделей предоставления вычислительных услуг.
Итак, облачные инфраструктуры можно разделить по принципу работы на следующие типы:
- Public cloud (публичные облака) - провайдер облачных услуг предоставляет заказчику свою инфраструктуру и сервисы на коммерческой основе, как правило, по подписке.
- Private cloud (частные облака) - организация размещает часть своей инфраструктуры в некотором своем или арендуемом ЦОД (центре обработки данных) и полностью контролирует все аппаратные и программные компоненты.
- Hybrid cloud (гибридные облака) - организация совмещает работу с публичным и частным облаком, размещая свои приложения и данные в зависимости от удобства и потребностей в той или иной инфраструктуре.
- Multi-cloud (мультиоблако) - организация пользуется услугами нескольких провайдеров облачных сервисов для надежности и повышения отказоустойчивости, например, размещая основную инфраструктуру в одном публичном облаке, а бекапы и резервные сервисы - в другом.
Для работы с облачными инфраструктурами, как правило, предоставляются следующие варианты:
- IaaS (infrastructure as a service) - предоставление услуги по модели «инфраструктура как сервис», когда облачный провайдер предоставляет только своё аппаратное обеспечение, сетевой доступ и гипервизор системы виртуализации, а заказчикам дается возможность установить свои операционные системы, прикладное и системное ПО, бизнес-приложения.
- PaaS (platform as a service) - предоставление услуги по модели «платформа как сервис», когда облачный провайдер предоставляет установленную операционную систему (как правило, давая на выбор несколько вариантов ОС на базе Winows и Linux), а заказчики уже устанавливают только свое программное обеспечение.
- SaaS (software as a service) - предоставление услуги по модели «программное обеспечение как сервис», когда облачный провайдер предоставляет конечному заказчику предварительно установленное бизнес-приложение с некоторыми возможностями по его настройке и модификации.
В документе NIST SP 800-210 указывается на ряд факторов, определяющих особенности контроля доступа к облачным системам:
1. Широкий сетевой доступ: облачные платформы по умолчанию доступны из интернет для всех пользователей и типов клиентов (ПК, смартфоны, тонкие клиенты и т.д.), что увеличивает потенциальную поверхность сетевых атак.
2. Выделение разделяемых ресурсов: облачные системы разделяют свои вычислительные ресурсы между пользователями, что приводит к потенциальному киберриску несанкционированного доступа одного клиента к данным другого клиента. Кроме того, принцип работы и архитектура облачных решений таковы, что клиенты не могут точно знать, в каком именно дата-центре, на каком именно сервере и даже в какой именно стране обрабатываются их данные, что может привести к юридическим сложностям.
3. Гибкое масштабирование вычислительных ресурсов: в случае, когда клиенту облачного сервиса требуется получить новые вычислительные мощности, облачный провайдер предоставляет ему новые виртуальные машины, которые необходимо безопасно настраивать и проактивно контролировать доступ к ним.
4. Служба мониторинга потребляемых ресурсов: оплата за облачные сервисы зависит в том числе и от объема потребляемых вычислительных мощностей. Данные о потребляемых ресурсах не должны несанкционированно модифицироваться клиентами, но при этом должны быть доступны им на чтение.
5. Защита доступа к данным: клиенты должны обеспечить защиту своих данных самостоятельно, а провайдер облачных услуг может лишь предоставить некоторые инструменты для этого. В случае отсутствия шифрования клиентских данных доступ к ним может получить администратор облачного сервиса.
В публикации NIST SP 800-210 приводятся рекомендации по обеспечению контроля доступа для каждой из сервисных моделей (IaaS, PaaS, SaaS).
1. Рекомендации по обеспечению контроля доступа для IaaS-модели.
1.1. Защита сетевого доступа: на уровне инфраструктуры злоумышленники могут получить несанкционированный доступ к сетевому трафику, поэтому клиентам следует применять шифрование трафика, сегментацию виртуальных сетей с помощью VLAN, разграничение сетевого доступа на основе списков ACL.
1.2. Защита доступа к гипервизору: доступ к гипервизору позволяет выполнять операции с гостевыми виртуальными машинами и операционными системами, включая получение доступа к данным и повышение привилегий, поэтому только авторизованным облачным администраторам следует давать права администрирования гипервизора.
1.3. Защита гостевых виртуальных машин: следует блокировать взаимодействие между гостевыми виртуальными машинами и операционными системами, поскольку такое взаимодействие может привести к утечке данных или выполнению вредоносного кода. Изоляция виртуальных машин также требуется для предотвращения потребления избыточного количества вычислительных ресурсов сбойной гостевой ОС. Кроме того, неактивные гостевые машины могут по-прежнему содержать конфиденциальную информацию, что также требует контроля доступа к ним.
1.4. Защита доступа по API: облачные платформы могут предоставлять своим клиентам доступ к API для управления гостевыми виртуальными машинами, что требует контроля доступа к таким API.
1.5. Защита с помощью системы управления виртуализацией: защита облачной платформы с помощью системы управления виртуализацией позволяет защитить данные гипервизора и гостевых систем от несанкционированного доступа и предоставляет механизмы изоляции систем.
2. Рекомендации по обеспечению контроля доступа для PaaS-модели.
2.1. Защита данных: данные, разделяемые между PaaS-приложениями, следует защищать от несанкционированного доступа с помощью встроенных функций безопасности гостевых ОС (например, с помощью PaaS-контейнеризации), а также путем контроля доступа к памяти на уровне гипервизора.
2.2. Защита доступа по API: облачные PaaS-провайдеры могут предоставлять доступ к API для управления микросервисами и приложениями внутри платформы, что требует контроля доступа к таким API, например, с помощью сервера авторизации.
2.3. Контроль доступа к данным в PaaS: защита памяти PaaS-сервисов может реализовываться путем очистки кэша данных процессора при переключении контекстов, а также путем применения централизованной системы контроля доступа на основе политик, которые применяются ко всем применяемым клиентом PaaS-сервисам.
3. Рекомендации по обеспечению контроля доступа для SaaS-модели.
3.1. Обеспечение защиты данных владельцем: провайдер данных управляет доступом к обрабатываемым данным, определяет политики хранения данных и назначает ответственных.
3.2. Конфиденциальность данных: применение шифрования и различных моделей контроля доступа аутентифицированных пользователей обеспечивают конфиденциальность данных пользователей SaaS-приложений.
3.3. Управление полномочиями доступа: гибкий и оперативный механизм назначения и отзыва прав доступа обеспечивает безопасность работы SaaS.
3.4. Управление реплицированными данными: множественные копии данных (реплики) должны управляться синхронизируемой политикой контроля доступа.
3.5. Управление мульти-арендностью (multi-tenancy): обработка данных разных пользователей в одном SaaS-приложении требует применения строгих правил контроля доступа на основе моделей ABAC (атрибутная модель), RBAC (ролевая модель), CBAC (контекстная модель). Кроме того, следует учитывать киберриски эксплуатации уязвимостей самого SaaS-приложения в целях получения несанкционированного доступа.
3.6. Управление атрибутами и ролями: выбор типов атрибутов доступа и ролей на этапе проектирования SaaS-систем определяет надежность контроля доступа. Малое количество атрибутов может привести к недостаточной гибкости политик контроля доступа, а большое - к чрезмерной сложности модели доступа.
3.7. Управление политиками доступа: передача управления политиками доступа от SaaS-провайдера к клиенту без предоставления провайдеру конфиденциальных подробностей требований проверки политик является залогом обеспечения надежного контроля доступа к данным в SaaS-приложении.
3.8. Защита доступа по API: контроль доступа можно реализовать через API-вызовы, при этом разрешая только определенные виды действий аутентифицированным API-подключениям. Например, при работе через протоколы REST и SOAP, API-вызовы должны проходить авторизацию для проверки прав доступа и дальнейшего контролируемого выполнения действий.
3.9. Контроль доступа к данным в SaaS: системы авторизации в мульти-арендной среде могут быть централизованными (одна база авторизаций для всех клиентов), децентрализованными или гибридными (каждый тенант отвечает за своих клиентов в выделенных базах авторизации). Для эффективного использования политик контроля доступа можно использовать службу федерации авторизации (англ. authorization federation), которая представляет собой брокер авторизации между SaaS-провайдером и клиентом.
