Безопасность в OpenStack: шаг за шагом

08.08.2016

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

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

Рассматривая последние из обнаруженных уязвимостей систем безопасности OpenStack, вы можете обнаружить, что многие из них «привязаны» к конкретному компоненту OpenStack – таким, как Nova, Glance или Neutron. К примеру, несколько версий Swift перед релизами Kilo и Liberty содержали «дыру», позволявшую хакерам удаленно запускать Denial of Service (DoS)-атаку. Также одна из версий Nova до релиза Kilo позволяла хакерам получать доступ к важной информации через чтение лог-файлов.

Безопасность OpenStack CLI

Использование инструментов OpenStack CLI требует применения имени пользователя и пароля. Многие руководства по OpenStack рекомендуют использовать переменные окружения OS_USERNAME и OS_PASSWORD, установленные в файле OpenStack RC. Тем не менее, напомним, что хранение в обычном, незашифрованном файле реквизитов для идентификации противоречит зарекомендовавшим себя практикам обеспечения безопасности.

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

Здесь важны три шага:

  1. удостоверьтесь, что все ненужные сервисы отключены;
  2. разрешите доступ только по SSH (secure shell protocol, протокол безопасной оболочки) и из проверенной сети;
  3. отключите Bash history и храните все логи в изолированном, удаленном, защищенном и высокодоступном репозитории хранения.

Безопасность Nova

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

  • Прежде всего, администратор прав файлов конфигурации Nova должен быть в категории root, а группа файлов конфигурации должна быть определена как nova. Также должны быть установлены права доступа «640» (чтение/перезапись для владельца, чтение для группы).
  • Отключите PCI-транзитный шлюз на вашем гипервизоре для ограничения прямого доступа с ВМ к аппаратной части ИТ-инфраструктуры – такой, как DMA.
  • Используйте sVirt или SELinux/AppArmor для помещения вашего гипервизора в отдельный контекст безопасности.
  • Некоторые гипервизоры обладают техниками оптимизации памяти для дедупликации страниц виртуальной памяти ВМ на хосте. К примеру, у Xen это Transparent Page Sharing (TPS), а у KVM – Kernel Samepage Merging (KSM). Для снижения уровня угроз в адрес облачных тенантов используйте строгое разделение по доступному им объему вычислительных мощностей. Для этого отключите все механизмы оптимизации памяти гипервизора для таких мощностей.
  • Храните логи гипервизора в защищенном и удаленном хранилище.
  • Отслеживайте целостность исполняемых файлов для вашего гипервизора. К примеру, вы можете использовать пакеты для проверки контрольных сумм MD5 у установленных файлов пакетов debsums для ОС на основе Debian или rpm-V для Red Hat.
  • Используйте рандомизацию распределения адресного пространства (Address Space Layout Randomization, ASLR) и непозиционный исполняемый модуль (Position Independent Executable, PIE) для исполняемых файлов гипервизора; этот подход поддерживается гипервизором Qemu-KVM.
  • Используйте TLS для VNC- или SPICE-сессий.
  • Убедитесь, что Nova безопасно соединяется (через TLS) с другими OpenStack-сервисами – такими, как Keystone или Glance. Это также является общей рекомендацией для всех сервисов OpenStack.

Безопасность Glance

Glance позволяет хранить образы, которые используются для запуска новых ВМ. Для избежания покушений на целостность этих образов важно поддерживать безопасность данного сервиса.

  • Не используйте встроенные образы или контейнеры Docker из непроверенных источников, поскольку они могут содержать уязвимости или вредоносное ПО. 
  • Используйте подписывание образов Glance (доступно на Mitaka).

Безопасность Neutron

Neutron обеспечивает связность сети и IP-адресов для ВМ в облаке. Архитектура Neutron основана на плагинах. Таким образом, важно понимать, какие именно плагины требуются для выполнений этих задач, а какие используются для сторонних решений; после этого отключите все ненужные плагины. 

  • Используйте изолированную сеть управления для сервисов OpenStack
  • Используйте изоляцию L2 с сегментацией VLAN или GRE-тоннели
  • Задействуйте опцию групп безопасности в Neutron и отключите группы безопасности в Nova (все API-запросы групп безопасности Nova должны перенаправляться в Neutron)
  • Защитите оконечные точки API в Neutron с помощью TLS
  • Используйте утилиты командной строки iptables и правила использования средств фильтрации пакетов для программных мостов Linux - ebtables, чтобы предотвратить атаки типа MAC- и ARP-спуфинг (подмена идентификатора пользователя)
  • Используйте сетевые квоты для смягчения воздействия DoS-атак

Безопасность очереди сообщений Message Queue (RabbitMQ)

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

  • Удалите гостевого пользователя RabbitMQ
  • Используйте отдельный виртуальный хост RabbitMQ для каждого OpenStack-сервиса; используйте уникальные †идентификаторы полномочий и соответствующие права доступа для каждого виртуального хоста RabbitMQ
  • Защитите RabbitMQ API с помощью TLS
  • Храните логи RabbitMQ в защищенном и удаленном хранилище.

Безопасность Keystone

Keystone обеспечивает идентификацию для других OpenStack-сервисов и должен защищаться соответствующим образом от спуффинга и других атак.

Keystone не предоставляет методик по реализации политики надежности паролей, их сроков действия или неудачных попыток аутентификации в соответствии с рекомендациями NIST. Тем не менее, Keystone может использовать внешнюю систему аутентификации, которая поддерживает все соответствующие рекомендации.

  • Мультифакторная аутентификация должна задействоваться через систему внешней аутентификации, такую, как Apache HTTP Server.
  • По умолчанию, время истечения токена – 1 час. Рекомендуемое значение этого показателя должно быть установлено на минимально допустимом значении, позволяющем OpenStack-сервисам завершить свои запросы в установленные временные рамки, иначе операция (в случае прекращения действия токена до завершения запроса со стороны сервиса) будет прервана. Отметим, что некоторые операции особенно длительны по времени, например, когда Nova передает образ диска на хост.
  • Используйте токены Fernet , которые разработаны специально для API REST, так как они являются более защищенными по сравнению с обычными токенами, а также требуют меньше ресурсов.
  • Используйте домены Keystone для более точного разграничения прав доступа для тенантов. Владелец домена может создавать дополнительных пользователей, группы, а также роли внутри домена.

Безопасность Cinder

Cinder обеспечивает высокий уровень API для управления блочными устройствами хранения данных и активно используется сервисом Nova. Его следует защищать от DoS-атак, утечек информации, несанкционированного доступа и других угроз.

  •  Администратор прав файлов конфигурации Cinder должен отноститься к категории root, а группа файлов конфигурации должна быть определена как cinder. Также должны быть установлены права доступа «640» (чтение/перезапись для владельца, чтение для группы). 
  • Установите размер макимального запроса. Этот параметр не определяется по умолчанию, и хакер может отправлять массивный по объему запрос с целью выведения Cinder из строя (DoS-атака). 
  • Для безопасного удаления томов Cinder используйте полную очистку томов.

 Безопасность Swift

 Swift обеспечивает длительное хранение объектов для OpenStack, преимущественно образов Glance, таким образом, он должен быть хорошо защищен.

  •  Администратор прав файлов конфигурации Swift должен относиться к категории root, а группа файлов конфигурации должна быть определена как swift. Также должны быть установлены права доступа «640» (чтение/перезапись для владельца, чтение для группы).
  • Используйте выделенную сеть для нод хранения.
  • Используйте файерволл для защиты публичных интерфейсов на proxy-нодах.

 Дополнительные данные

 Связанные с OpenStack проекты в области безопасности:

  •  OpenStack Barbican – представляет собой PKI- и криптографический сервис для облаков OpenStack. Доступен с релиза Havana. Barbican поддерживает подтвержденные CA для TLS-сертификатов, прозрачное шифрование и распределение ключей для томов Cinder LVM, KDS-сервисы для подписывания сообщений и шифрование объектов Swift. 
  • Anchor является облегченным PKI-сервисом для создания надежных шифровальных инструментов в сервисах OpenStack. Anchor использует краткосрочные сертификаты, которые обычно действуют в течение 12-24 часов. 
  • Quality of Service as a Service (QoSaaS) – в настоящий момент находится на стадии разработки. Планируется, что услуга сможет предоставлять управление пропускной способностью, ограничение скорости передачи на порт/сеть/тенант, а также анализ потока данных. 
  • Firewall as a Service (FWaaS) – также в стадии разработки. Своей целью имеет обеспечить унифицированный API для традиционных L2/L3-фаейрволлов, а также файерволлов следующего поколения для использования в облаках OpenStack. 
  • Load Balancer as a service (LBaaS) – существующие реализации LBaaS основано на HAProxy, однако целью этого проекта является обеспечение инструмента повышения эффективности технологий балансировки проприетарной и open-source компоненты при осуществлении распределения нагрузки при обработке запросов.

 В заключение

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

Перевод статьи Tighten the Security of Your OpenStack Cloud выполнен компанией "Сервионика". 

Назад к разделу "Публикации"