Введение

Безопасность облачных вычислений изначально вызывала опасения: можно ли доверять облаку настолько, чтобы разместить в нем корпоративную инфраструктуру? Особенно остро этот вопрос встает в гибридной или мультиоблачной архитектуре, где используется одно или несколько публичных облаков наряду с частным облаком или локальной средой.

Организации все чаще переносят рабочие нагрузки в облако для повышения эффективности, при этом облачные среды должны соответствовать строгим требованиям безопасности и комплаенса. Чаще всего организации начинают задумываться об этом слишком поздно, уже при реализации и развертывании OpenStack. Здесь их ждут неприятные сюрпризы, ведь оказывается, что развертывание не соответствует необходимым стандартам безопасности. Хотя OpenStack известен как очень надежное и защищенное решение, которое хорошо подходит для отраслей со строгим регулированием, таких как здравоохранение, правительство, банковские услуги и телекоммуникации, следует уделить особое внимание вопросу безопасности еще на этапе проектирования.

Некоторые дистрибутивы OpenStack обеспечивают больше безопасности, чем другие. Например, Charmed OpenStack не ограничивается базовыми встроенными средствами и по умолчанию применяет рекомендации, задокументированные в руководстве по безопасности OpenStack.

Ubuntu, которая может быть базовой операционной системой для OpenStack, также оснащена уже готовой конфигурацией безопасности. Конкретные меры, принимаемые в каждом поддерживаемом релизе, можно изучить на вики-странице Ubuntu. Более полную информацию о том, как Canonical обеспечивает безопасность, см. на странице https://www.ubuntu.com/security.

Содержание

Здесь рассматриваются расширенные возможности безопасности, которыми Canonical дополняет облака OpenStack, чтобы они отвечали высочайшим стандартам наших клиентов. Мы поговорим о сценариях применения, которые выходят за пределы простого развертывания безопасного OpenStack, и покажем, как мы ежедневно решаем задачи организаций в реальных условиях. Самые распространенные из требований безопасности — шифрование данных при хранении и управление жизненным циклом сертификатов. Эти вопросы не решаются в самом OpenStack и требуют современных сторонних приложений с открытым исходным кодом.

OpenStack — шифрование данных при хранении

Задача

Что будет с данными, если кто-то украдет из ЦОД один диск? А если сервер? Или даже целую стойку? Сможет ли злоумышленник получить доступ к чувствительным данным? Какой штраф придется заплатить компании, если это произойдет?

Компании часто задают себе эти вопросы, особенно после появления регламента GDPR.

В облаке Ubuntu OpenStack чувствительные и персональные данные могут храниться в разных местах:

Эфемерное хранилище в инстансе. Данные помещаются на виртуальный диск, управляемый Nova и связанный с инстансом, который находится прямо на сервере гипервизора.
Блочное хранилище. Данные помещаются на управляемое Cinder блочное устройство, которое предоставлено решением для хранения, например Ceph, и связано с инстансом в облаке.
Объектное хранилище. Данные помещаются в Swift (или Ceph RADOS Gateway) через REST API.

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

Решение

Как снизить риски кражи данных при использовании облака Ubuntu OpenStack?

Шифровать данные в Linux очень просто — dm-crypt + LUKS (формат для управления ключами шифрования на дисках) предоставляют оптимизированную поддержку шифрования блочных устройств на уровне ядра. Но это лишь часть решения, ведь необходимо также защитить ключи, используемые для шифрования блочных устройств. Для этого требуется решение по управлению ключами со строгим контролем доступа на основе ролей (RBAC) и надежной семантикой распечатывания для защиты от любых сценариев физической потери. Ключи шифрования должны быть доступны для повседневных операций, чтобы поддерживать автоматическую разблокировку зашифрованных блочных устройств без сохранения на локальных дисках, например, при установке патчей безопасности с перезагрузкой сервера.

В Ubuntu OpenStack для этой цели используется Hashicorp Vault. Vault предоставляет семантически стойкую безопасность для мастер-ключа шифрования при запуске в виде нескольких ключей с настраиваемыми уровнями кворума. Ключи распечатывания (unseal key) для Vault никогда не хранятся в системах, где размещено облако OpenStack. Они всегда находятся за пределами инсталляции, в нескольких сторонних системах. Если на сервере, где размещен Vault, отключить питание, Vault не будет обслуживать запросы до распечатывания, а эта операция выполняется не в рамках загрузки сервера и сервиса Vault.

Vault также предоставляет детализированный контроль, позволяя открывать доступ к хранящимся ключам шифрования только для систем, где размещено физическое блочное устройство. Например, серверы, где размещены инстансы OpenStack на зашифрованных блочных устройствах, не могут получить доступ к ключам, с помощью которых зашифрованы блочные устройства, используемые для поддержки Ceph на другом сервере.

Canonical создала vaultlocker, чтобы интегрировать этот подход к управлению ключами на базе Vault в три варианта хранилища в облаке OpenStack.

Что касается применения RBAC, каждый сервер, который должен обеспечить шифрование блочных устройств, получает уникальный Vault AppRole и секрет. Этот AppRole с помощью метода CIDR связан с IP-адресом сервера. Доступ разрешен только для конкретного пути имени хоста сервера в бэкенде секретов, где хранятся ключи шифрования для каждого блочного устройства.

В типичном развертывании облака Ubuntu OpenStack настройка AppRole и связанного секрета управляется через Juju и чармы (charm) OpenStack с помощью ответа от Vault, поэтому только сервис-потребитель получает прямой доступ к секрету, то есть чарм Vault и Juju не видят секрет. Vaultlocker гарантирует, что ключи шифрования не хранятся на локальном диске. Ключ создается в памяти, а затем переносится напрямую в Vault. При последующем разблокировании ключ считывается из Vault в память, а затем используется для открытия блочного устройства на основе LUKS.

Для каждого варианта хранения (Nova, Cinder+Ceph и Swift) vaultlocker шифрует (при настройке) и разблокирует (при загрузке) соответствующее блочное устройство, которое затем можно присоединить и использовать как файловую систему, управляемую через /etc/fstab (для Nova и Swift), или просто представить системе для других инструментов, например ceph-volume для начальной загрузки Ceph OSD на кластер Ceph.

Заключение

С помощью Vault и vaultlocker облака Charmed OpenStack предоставляют единый согласованный подход к шифрованию блочных устройств и управление ключами для всех сценариев применения. Это гарантирует безопасность данных в хранилищах почти в любых ситуациях физической потери устройств в ЦОД. Эта возможность предоставляется в рамках BootStack, управляемого сервиса от Canonical для Ubuntu OpenStack, или в составе набора функций для облака Charmed OpenStack. Более подробно это описывается в разделах руководства по развертыванию OpenStack, посвященных Vault и шифрованию данных при хранении.

OpenStack — управление жизненным циклом сертификатов

Сегодня сложно представить ситуацию, когда конфиденциальные данные отправляются по сети в открытом виде. Это относится и к инсталляции OpenStack. При использовании CLI вы можете даже не знать, что ваши учетные данные передаются в незашифрованном виде. OpenStack не требует обмениваться данными только с защищенными конечными точками и даже не предупреждает об отсутствии защиты.

На ранних этапах внедрения OpenStack возникает искушение оставить плоскость управления без защиты. Например, первые перенесенные рабочие нагрузки не содержат чувствительных данных или развертывание используется только для экспериментов. Проекты развиваются, требования меняются, и имеющиеся конфигурации уже не подходят. Следует всегда защищать развертывания и ни при каких обстоятельствах не передавать учетные данные в отрытом виде.

Задача

Допустим, вы хотите создать собственный центр сертификации (ЦС), чтобы генерировать и подписывать сертификаты. Любой опытный системный администратор может выполнить эту задачу, чтобы затем использовать созданные ключи и сертификаты для шифрования конечных точек OpenStack.

У такого подхода есть свои трудности.

Клиент (пользователь или другой сервис OpenStack) не будет доверять самоподписанному сертификату по умолчанию. Чтобы настроить доверие, нужно установить соответствующий файл ЦС. Его нужно распространить среди всех пользовательских компьютеров и установить почти на всех серверах, поддерживающих облако OpenStack.

Возможно, у вашей компании уже есть ЦС и у всех пользователей уже установлен соответствующий сертификат ЦС. Значит, вопрос доверия решен, и вам остается только управлять сертификатами внутри облака Openstack.

Но это не так-то просто:

В развертывании OpenStack обычно не меньше десяти сервисов. Каждый из сервисов предоставляет конечные точки, каждой конечной точке нужен сертификат. В целях отказоустойчивости каждый сервис может выполняться на трех и более машинах. В итоге вы получаете десять сертификатов на тридцати машинах или контейнерах, и всем этим нужно управлять. Обычно необходимо защитить следующие сервисы:

- Glance — управление образами виртуальных машин;

- Keystone — управление идентификаторами;

- Nova — вычисления;

- Neutron — сети;

- Placement — размещение VM на вычислительных ресурсах;

- Swift — объектное хранилище;

- Cinder — блочное хранилище;

- Ceilometer — сбор данных;

- Gnocchi — база данных временных рядов;

- Aodh — оповещения.

Срок действия сертификатов истекает, их нужно заново создавать и устанавливать. Управление жизненным циклом отнимает много времени, а если этого не делать, происходит сбой сервиса, как это случилось у телеком-компании O2.
Управлять сертификатами значит не только отслеживать их срок действия. При изменении IP-адреса или доменного имени конечной точки, например, сертификат становится недействительным, и его нужно выдать повторно. Администратор потратит очень много времени на выполнение этих задач вручную.

Решение

Облако Ubuntu OpenStack обеспечивает безопасность и при этом избавляет организацию от необходимости вручную администрировать сертификаты. Это возможно благодаря чармам (charm). Чармы — это наборы скриптов для развертывания и эксплуатации программного обеспечения. Благодаря встроенной обработке событий они могут объявлять интерфейсы, соответствующие чармам других сервисов, образуя связи. Эти связи представляют собой сложные механизмы передачи данных между приложениями. С помощью связи приложение может запросить сертификат, чтобы защитить конечную точку. В этом случае необходимо будет только приложение, которое может отвечать на такие запросы.

В Ubuntu OpenStack для этой цели используется Hashicorp Vault. Vault предоставляет инфраструктуру открытых ключей (PKI), которая позволяет создавать сертификаты по требованию. Чарм Vault, созданный Canonical, принимает запросы на сертификаты от сервисов OpenStack, преобразует их в вызовы API для интерфейса Vault PKI, а затем передает обратно запрашивающему приложению через связи. Чарм для каждого сервиса OpenStack знает, как установить сертификат и цепочку, полученные от Vault, и как обновить каталог сервисов, чтобы защитить все будущие запросы.

Проблема доверия сертификатам от сервисов OpenStack также решается. Vault поддерживает создание промежуточного ЦС, который был подписан другим доверенным ЦС и может использоваться для подписания сертификатов. Это означает, что имеющийся ЦС организации (например, Active Directory), может подписать промежуточный ЦС, а Vault затем использует его для подписания запросов на сертификат от приложений. Когда пользователь взаимодействует с OpenStack, он получает файл сертификата и цепочки приложений, который показывает, что если клиент доверяет ЦС организации, он должен доверять и этому сертификату.

Использовать промежуточный сертификат необязательно. Vault может выступать в качестве корневого ЦС. В этом случае все приложения OpenStack будут доверять друг другу, потому что у них установлен корневой сертификат, полученный в результате связи с Vault, но пользователям необходимо будет получить сертификат от Vault и установить его локально.

Использование Vault в развертывании OpenStack упрощает не только начальную установку, но и дальнейшее обслуживание. Рассмотрим несколько типичных сценариев.

Увеличение горизонтального масштаба имеющегося сервиса. Предположим, для обработки нагрузки необходим новый сервер Glance. Используйте Juju, чтобы добавить еще одну единицу в приложении Glance. После подготовки эта единица запросит новый сертификат у Vault, и сертификат будет установлен и готов к использованию.

Добавление отказоустойчивости. Сейчас используется только одна единица сервиса, но для отказоустойчивости их должно быть несколько. В качестве конечной точки сервиса используется виртуальный IP (VIP). При добавлении конфигурации VIP имеющиеся и новые единицы запросят и установят новый сертификат, который включает альтернативное имя субъекта (SAN) для VIP.

Срок действия сертификатов OpenStack истекает, их необходимо выдавать повторно. Чарм Vault предоставляет действие reissue-certificates, которое приводит к перевыпуску сертификатов и обновлению связей. Чармы OpenStack обнаруживают новые сертификаты и устанавливают их.

Изменение центра сертификации. Предположим, в тестовом облаке для удобства использовался корневой ЦС Vault, а сейчас облако развертывается для широкого круга пользователей и нужно использовать промежуточный ЦС, подписываемый основным ЦС компании. Чарм Vault предоставляет действия для замены ЦС и выдачи новых сертификатов.

Заключение

Облако Ubuntu OpenStack бесшовно интегрируется с Vault, чтобы предоставлять защищенные конечные точки при минимальных усилиях со стороны администраторов. Автоматизация перевыпуска и создания сертификатов для новых сервисов и машин упрощает управление облаком. Организации могут использовать TLS без административных издержек, связанных с управлением большим числом сертификатов.

Учетные данные нельзя передавать по сети открытым текстом. Пользователи должны быть уверены в надежности сервиса, с которым взаимодействуют. TLS решает эти задачи, а Ubuntu OpenStack позволяет легко реализовать этот протокол. Chrome и Firefox уже предупреждают пользователей о каждом HTTP-соединении, и мы поддерживаем это начинание, гарантируя, что в управляемых нами развертываниях OpenStack не будет конечных точек HTTP.

Свяжитесь с нами, чтобы узнать больше о безопасности и комплаенсе в OpenStack.

Примечание. OpenStack CLI предоставляет параметр -insecure, который можно использовать, чтобы игнорировать цепочки доверия, но это все равно что советовать пользователям игнорировать ошибки недопустимого сертификата в браузере. Это очень плохая привычка, от которой нужно избавиться.

Присоединяйтесь к Telegram каналу UBUNTU Community, чтобы быть в курсе последних новостей!

Обеспечение безопасности в OpenStack