О том, как необходимо защищать облака, написано довольно много различных публикаций. В этой статье мы начнем рассматривать рекомендации по обеспечению кибербезопасности облаков, которые предлагает документ Security Guidance. For Critical Areas of Focus In Cloud Computing v.4.0. В этом документе предоставляются рекомендации по обеспечению безопасности облачных вычислений и снижению рисков.
Данный гайд был разработан альянсом по облачной безопасности (Cloud Security Alliance), который продвигает внедрение передовых методов обеспечения безопасности в области облачных вычислений и подготовил практическую дорожную карту для организаций, работающих с облачными средами.
Я думаю, с определением и принципами работы облака все понятно, но прежде чем переходить к вопросам кибербезопасности, нужно еще разобраться с основными характеристиками облачных сред.
Прежде всего, основной характеристикой облака является объединение вычислительных ресурсов в единый пул. Поставщик выделяет ресурсы и собирает их в пул, части которого могут быть распределены между различными потребителями (как правило, на основе политик и запросов клиентов, соответствующих данным политикам).
Потребителям предоставляют ресурсы из этого пула, используя запросы по требованию. Они управляют своими ресурсами самостоятельно, не обращаясь к администратору. Например, при работе с любой облачной средой мы используем личный кабинет, в котором с помощью веб интерфейса можем запрашивать нужные ресурсы (виртуальные машины, сети, хранилища и т.д.)
Еще один важный признак облака - это наличие широкополосного сетевого доступа, то есть все ресурсы доступны по сети без необходимости прямого физического доступа. При этом, сеть не обязательно является частью сервиса и может предоставляться сторонним провайдером.
Гибкие возможности для масштабирования являются еще одной важной характеристикой облака. Потребители могут достаточно оперативно расширять или сокращать ресурсы, которые они используют, из пула, часто полностью автоматически. Это позволяет им более точно соотносить потребление ресурсов со спросом (например, добавляя виртуальные серверы, когда спрос увеличивается, а затем отключая, когда спрос падает).
Оплата облачных услуг ведется по принципу аренды. То есть, пока виртуальные машины работают, вы за них платите, когда вы их выключаете, счетчик не капает. То есть, клиент платит только за то, что он использует.
Программное обеспечение как услуга (SaaS) - это полноценное приложение, управляемое и размещаемое поставщиком. Пользователи получают к нему доступ с помощью веб-браузера, мобильного приложения или простого клиентского приложения. Например, мессенджеры, файловые хранилища и т.д.
Платформа как услуга (PaaS) предоставляет платформы разработки или приложения, такие как базы данных, прикладные платформы (например, место для запуска Python, PHP или другого кода), хранение файлов и совместную работу или даже обработку собственных приложений (например, машинных обучение, обработка больших объемов данных или прямой доступ через интерфейсы прикладного программирования (API) к функциям полноценного SaaS-приложения). Ключевым отличием является то, что при использовании PaaS вы не управляете базовыми серверами, сетями или другой инфраструктурой.
Инфраструктура как услуга (IaaS) предоставляет доступ к пулу ресурсов фундаментальной вычислительной инфраструктуры, такой как компьютер, сеть или хранилище. Здесь мы сами создаем виртуалку, устанавливаем на нее ОС и все необходимое ПО.
Говоря о моделях развертывания обычно используют четыре модели развертывания в облаке.
Общедоступное облако. Облачная инфраструктура доступна для пользователей из интернет, и принадлежит организации, продающей облачные сервисы.
Частное облако. Облачная инфраструктура используется исключительно для одной организации. Оно может управляться организацией или третьей стороной и может располагаться как на территории компании, так и за ее пределами.
Облако сообщества. Облачная инфраструктура используется несколькими организациями совместно и поддерживает конкретное сообщество, у которого есть общие интересы (например, миссия, требования безопасности, политика или соображения соответствия требованиям). ИТ-инфраструктура может управляться организациями или третьей стороной и может быть расположена локально или за пределами предприятия.
Гибридное облако. Облачная инфраструктура - это совокупность двух или более облаков (частных, общественных или общедоступных), которые остаются уникальными объектами, но связаны стандартизированными или запатентованная технология, обеспечивающая переносимость данных и приложений (например, облачная интеграция для балансировки нагрузки между облаками). Термин Hybrid также часто используется для описания не облачного центра обработки данных, подключенного напрямую к облачному провайдеру.
Подытожим все вышеизложенное описание облачных сред с помощью следующей иллюстрации:
Хотя общий уровень безопасности и соответствия требованиям остается неизменным, те части, за которые отвечает каждый конкретный участник облачных технологий, безусловно, меняются. Облачные вычисления - это модель общей технологии, в которой разные организации часто отвечают за внедрение и управление различными частями стека. В результате обязанности по обеспечению безопасности также распределяются по всему стеку и, следовательно, по задействованным организациям.
Это можно представить, как матрицу ответственности, элементы которой зависят от конкретного поставщика облачных услуг и его функции/продукта, модели обслуживания и модели развертывания. В зависимости от выбранной модели обслуживания, может изменяться уровень ответственности за безопасность.
Так, если мы говорим о модели SaaS, то поставщик облачных услуг отвечает практически за все вопросы безопасности, поскольку пользователь облачных услуг может только получать доступ к приложению и управлять его использованием и не может изменять его работу. Например, поставщик SaaS отвечает за безопасность периметра, ведение журнала/мониторинг/аудит и безопасность приложений, в то время как пользователь может иметь возможность управлять только авторизацией и правами доступа.
В случае с PaaS поставщик облачных услуг отвечает за безопасность платформы, в то время как пользователь несет ответственность за все, что он реализует на платформе, включая настройку любых предлагаемых функций безопасности. Таким образом, обязанности распределяются более равномерно.
Например, при использовании базы данных в качестве сервиса поставщик управляет фундаментальной безопасностью, установкой исправлений и базовой конфигурацией, в то время как пользователь облака отвечает за все остальное, включая то, какие функции безопасности базы данных использовать, управление учетными записями или даже методы аутентификации.
И, наконец, IaaS, как и в случае с PaaS, поставщик отвечает за базовую безопасность, в то время как пользователь облака отвечает за все, что он создает в инфраструктуре. В отличие от PaaS, здесь гораздо больше ответственности возлагается на клиента. Например, поставщик услуг IaaS, скорее всего, будет отслеживать свой периметр на предмет атак, но потребитель несет полную ответственность за то, как он определяет и реализует безопасность своей виртуальной сети, основываясь на инструментах, доступных в сервисе.
Концептуальные модели или фреймворки включают визуализации и описания, используемые для объяснения концепций и принципов облачной безопасности.
Модели или фреймворки элементов управления классифицируют и детализируют конкретные элементы управления облачной безопасностью или категории элементов управления. Эталонные архитектуры - это шаблоны для реализации облачной безопасности, как правило, обобщенные (например, эталонная архитектура безопасности IaaS). Они могут быть очень абстрактными, граничащими с концептуальными, или довольно подробными, вплоть до конкретных элементов управления и функций.
Шаблоны проектирования - это в свою очередь, многократно используемые решения конкретных проблем. В области безопасности примером может служить управление журналами IaaS. Как и в случае с эталонными архитектурами, они могут быть более или менее абстрактными или конкретными, вплоть до общих шаблонов реализации на конкретных облачных платформах.
Границы между этими моделями часто размываются и накладываются друг на друга в зависимости от целей разработчика облачной платформы.
Ключевым моментом является определение требований, разработка архитектуры, а затем выявление пробелов на основе возможности базовой облачной платформы. Вот почему нам необходимо знать поставщика облачных услуг и его архитектуру, прежде чем мы начнем воплощать требования безопасности в элементы управления.
habr.com
Данный гайд был разработан альянсом по облачной безопасности (Cloud Security Alliance), который продвигает внедрение передовых методов обеспечения безопасности в области облачных вычислений и подготовил практическую дорожную карту для организаций, работающих с облачными средами.
Понимание облачных вычислений
В идеальной среде облачная модель предполагает мир, в котором компоненты могут быть быстро организованы, подготовлены, внедрены и выведены из эксплуатации, а также отмасштабированы по требованию. Пользователь может запросить из пула ресурсов то, что ему нужно, например, 8 процессоров и 16 ГБ оперативной памяти, и облако назначает эти ресурсы клиенту, который затем подключается к ним и использует их, подключаясь к облаку по сети. Когда клиент закончит, он может передать ресурсы обратно в пул для использования кем-то другим.Я думаю, с определением и принципами работы облака все понятно, но прежде чем переходить к вопросам кибербезопасности, нужно еще разобраться с основными характеристиками облачных сред.
Основные характеристики облаков
Это характеристики, которые делают облако собственно облаком. Если что-то обладает этими характеристиками, мы считаем, что это облачные вычисления. Если у него нет ни одной из них, это, скорее всего, не облако.Прежде всего, основной характеристикой облака является объединение вычислительных ресурсов в единый пул. Поставщик выделяет ресурсы и собирает их в пул, части которого могут быть распределены между различными потребителями (как правило, на основе политик и запросов клиентов, соответствующих данным политикам).
Потребителям предоставляют ресурсы из этого пула, используя запросы по требованию. Они управляют своими ресурсами самостоятельно, не обращаясь к администратору. Например, при работе с любой облачной средой мы используем личный кабинет, в котором с помощью веб интерфейса можем запрашивать нужные ресурсы (виртуальные машины, сети, хранилища и т.д.)
Еще один важный признак облака - это наличие широкополосного сетевого доступа, то есть все ресурсы доступны по сети без необходимости прямого физического доступа. При этом, сеть не обязательно является частью сервиса и может предоставляться сторонним провайдером.
Гибкие возможности для масштабирования являются еще одной важной характеристикой облака. Потребители могут достаточно оперативно расширять или сокращать ресурсы, которые они используют, из пула, часто полностью автоматически. Это позволяет им более точно соотносить потребление ресурсов со спросом (например, добавляя виртуальные серверы, когда спрос увеличивается, а затем отключая, когда спрос падает).
Оплата облачных услуг ведется по принципу аренды. То есть, пока виртуальные машины работают, вы за них платите, когда вы их выключаете, счетчик не капает. То есть, клиент платит только за то, что он использует.
Модели обслуживания и развертывания
Национальный институт стандартов и технологий (NIST) определяет три модели обслуживания, которые описывают различные базовые категории облачных сервисов:Программное обеспечение как услуга (SaaS) - это полноценное приложение, управляемое и размещаемое поставщиком. Пользователи получают к нему доступ с помощью веб-браузера, мобильного приложения или простого клиентского приложения. Например, мессенджеры, файловые хранилища и т.д.
Платформа как услуга (PaaS) предоставляет платформы разработки или приложения, такие как базы данных, прикладные платформы (например, место для запуска Python, PHP или другого кода), хранение файлов и совместную работу или даже обработку собственных приложений (например, машинных обучение, обработка больших объемов данных или прямой доступ через интерфейсы прикладного программирования (API) к функциям полноценного SaaS-приложения). Ключевым отличием является то, что при использовании PaaS вы не управляете базовыми серверами, сетями или другой инфраструктурой.
Инфраструктура как услуга (IaaS) предоставляет доступ к пулу ресурсов фундаментальной вычислительной инфраструктуры, такой как компьютер, сеть или хранилище. Здесь мы сами создаем виртуалку, устанавливаем на нее ОС и все необходимое ПО.
Говоря о моделях развертывания обычно используют четыре модели развертывания в облаке.
Общедоступное облако. Облачная инфраструктура доступна для пользователей из интернет, и принадлежит организации, продающей облачные сервисы.
Частное облако. Облачная инфраструктура используется исключительно для одной организации. Оно может управляться организацией или третьей стороной и может располагаться как на территории компании, так и за ее пределами.
Облако сообщества. Облачная инфраструктура используется несколькими организациями совместно и поддерживает конкретное сообщество, у которого есть общие интересы (например, миссия, требования безопасности, политика или соображения соответствия требованиям). ИТ-инфраструктура может управляться организациями или третьей стороной и может быть расположена локально или за пределами предприятия.
Гибридное облако. Облачная инфраструктура - это совокупность двух или более облаков (частных, общественных или общедоступных), которые остаются уникальными объектами, но связаны стандартизированными или запатентованная технология, обеспечивающая переносимость данных и приложений (например, облачная интеграция для балансировки нагрузки между облаками). Термин Hybrid также часто используется для описания не облачного центра обработки данных, подключенного напрямую к облачному провайдеру.
Подытожим все вышеизложенное описание облачных сред с помощью следующей иллюстрации:
![c077f546b75304635c428af0c69822b3.png](https://habrastorage.org/r/w1560/getpro/habr/upload_files/c07/7f5/46b/c077f546b75304635c428af0c69822b3.png)
Распределяем ответственность
Это может показаться несколько упрощенным, но облачная безопасность и соответствие требованиям включают в себя все, за что сегодня отвечает команда безопасности, только в облаке. Все традиционные области безопасности также сохраняются, но характер рисков, роли и обязанности, а также внедрение средств контроля меняются, часто кардинально.Хотя общий уровень безопасности и соответствия требованиям остается неизменным, те части, за которые отвечает каждый конкретный участник облачных технологий, безусловно, меняются. Облачные вычисления - это модель общей технологии, в которой разные организации часто отвечают за внедрение и управление различными частями стека. В результате обязанности по обеспечению безопасности также распределяются по всему стеку и, следовательно, по задействованным организациям.
Это можно представить, как матрицу ответственности, элементы которой зависят от конкретного поставщика облачных услуг и его функции/продукта, модели обслуживания и модели развертывания. В зависимости от выбранной модели обслуживания, может изменяться уровень ответственности за безопасность.
Так, если мы говорим о модели SaaS, то поставщик облачных услуг отвечает практически за все вопросы безопасности, поскольку пользователь облачных услуг может только получать доступ к приложению и управлять его использованием и не может изменять его работу. Например, поставщик SaaS отвечает за безопасность периметра, ведение журнала/мониторинг/аудит и безопасность приложений, в то время как пользователь может иметь возможность управлять только авторизацией и правами доступа.
В случае с PaaS поставщик облачных услуг отвечает за безопасность платформы, в то время как пользователь несет ответственность за все, что он реализует на платформе, включая настройку любых предлагаемых функций безопасности. Таким образом, обязанности распределяются более равномерно.
Например, при использовании базы данных в качестве сервиса поставщик управляет фундаментальной безопасностью, установкой исправлений и базовой конфигурацией, в то время как пользователь облака отвечает за все остальное, включая то, какие функции безопасности базы данных использовать, управление учетными записями или даже методы аутентификации.
И, наконец, IaaS, как и в случае с PaaS, поставщик отвечает за базовую безопасность, в то время как пользователь облака отвечает за все, что он создает в инфраструктуре. В отличие от PaaS, здесь гораздо больше ответственности возлагается на клиента. Например, поставщик услуг IaaS, скорее всего, будет отслеживать свой периметр на предмет атак, но потребитель несет полную ответственность за то, как он определяет и реализует безопасность своей виртуальной сети, основываясь на инструментах, доступных в сервисе.
![01cc0968f75404bebf4cc05da924c1da.png](https://habrastorage.org/r/w1560/getpro/habr/upload_files/01c/c09/68f/01cc0968f75404bebf4cc05da924c1da.png)
Модели безопасности
Следующим немаловажным моментом в обеспечении безопасности облачных сред является использование моделей безопасности. Термин “модель” может быть использован несколько расплывчато, поэтому для наших целей мы выделяем следующие типы:Концептуальные модели или фреймворки включают визуализации и описания, используемые для объяснения концепций и принципов облачной безопасности.
Модели или фреймворки элементов управления классифицируют и детализируют конкретные элементы управления облачной безопасностью или категории элементов управления. Эталонные архитектуры - это шаблоны для реализации облачной безопасности, как правило, обобщенные (например, эталонная архитектура безопасности IaaS). Они могут быть очень абстрактными, граничащими с концептуальными, или довольно подробными, вплоть до конкретных элементов управления и функций.
Шаблоны проектирования - это в свою очередь, многократно используемые решения конкретных проблем. В области безопасности примером может служить управление журналами IaaS. Как и в случае с эталонными архитектурами, они могут быть более или менее абстрактными или конкретными, вплоть до общих шаблонов реализации на конкретных облачных платформах.
Границы между этими моделями часто размываются и накладываются друг на друга в зависимости от целей разработчика облачной платформы.
Простая модель процесса обеспечения облачной безопасности
Хотя детали реализации, необходимые элементы управления, конкретные процессы и различные эталонные архитектуры и модели проектирования сильно различаются в зависимости от конкретного облачного проекта, существует относительно простой высокоуровневый процесс управления облачной безопасностью:- Определите необходимые требования к безопасности и соответствию требованиям, а также все существующие средства контроля.
- Выберите поставщика облачных услуг, сервис и модели развертывания.
- Определите архитектуру.
- Оцените средства контроля безопасности.
- Выявите пробелы в средствах контроля.
- Разработайте и внедрите средства управления, чтобы заполнить пробелы.
- Управляйте изменениями с течением времени.
Ключевым моментом является определение требований, разработка архитектуры, а затем выявление пробелов на основе возможности базовой облачной платформы. Вот почему нам необходимо знать поставщика облачных услуг и его архитектуру, прежде чем мы начнем воплощать требования безопасности в элементы управления.
![9a5be4e976242e4088af5a7b1996ebba.png](https://habrastorage.org/r/w1560/getpro/habr/upload_files/9a5/be4/e97/9a5be4e976242e4088af5a7b1996ebba.png)
Заключение
В этой статье мы начали рассматривать рекомендации по обеспечению безопасности облачных сред. Важно понимать, что в зависимости от выбираемой модели облачных услуг ответственность за безопасность различных элементов облачной среды может оказаться как на стороне поставщика услуг, так и на стороне клиента.![habr.com](https://habrastorage.org/getpro/habr/upload_files/c07/7f5/46b/c077f546b75304635c428af0c69822b3.png)
И снова о безопасности облачных сред
О том, как необходимо защищать облака, написано довольно много различных публикаций. В этой статье мы начнем рассматривать рекомендации по обеспечению кибербезопасности облаков, которые...
![habr.com](https://assets.habr.com/habr-web/img/favicons/favicon-16.png)