Обеспечение защиты SSH, WEB доступа, наличие и управление требованиями к сложности паролей

AccentOS, базирующийся на OpenStack, отвечает за работоспособность облачной среды, виртуализацию ресурсов при подключении администраторов к системе управления и пользователей к собственным ресурсам (в первую очередь к виртуальным машинам).

Подключение пользователей и особенно администраторов требует соблюдения мер безопасности. Хотя облачная платформа оставляет за владельцем свободу выбора средств безопасности, существуют общие рекомендации, повышающие общий уровень безопасности облачной платформы.

Для администраторов платформы наиболее востребованным является доступ к консоли для выполнения команд через CLI и через WEB UI Horizon.

Защита SSH-доступа

При доступе к консоли наиболее популярным является доступ по протоколу SSH. Данный протокол является чрезвычайно распространённым среди администраторов, и при его использовании рекомендуется руководствоваться следующими правилами:

### Базовые меры защиты SSH

  • Смена порта SSH — базовая процедура, необходимая для защиты инфраструктуры. Доступ по SSH по умолчанию осуществляется через порт 22. Смена номера порта сразу существенно усложнит взлом.
  • Ограничение попыток авторизации — SSH не устанавливает лимит на количество попыток авторизации. Проблема решается путём установки стороннего ПО, например fail2ban.
  • Установка времени жизни пароля — регулярная смена паролей снижает риски компрометации.
  • Ограничение прав — не предоставлять root права, использовать привилегии минимально необходимые для выполнения задач.
  • Двухфакторная аутентификация — если возможно реализовать, значительно повышает уровень безопасности.

### Требования к сложности паролей для SSH

Важно

  • Длина: минимум 14-16 символов и более
  • Состав: обязательное использование комбинации строчных и заглавных букв, цифр и специальных символов (например, !@#$%^&*)
  • Случайность: не использовать слова, даты, имена или предсказуемые фразы
  • Уникальность: не использовать пароль от SSH на других ресурсах

### Использование SSH-ключей вместо паролей

Данные меры приведут к необходимости хранения пароля (его невозможно помнить при частых сменах) и защите места, в котором хранится пароль. Поэтому рекомендуется отказаться от использования паролей в пользу SSH-ключей.

Примечание

Под ключом авторизации понимают особым образом созданный электронный ключ, состоящий из открытой и закрытой части:

  • Открытая (публичная) часть ключа хранится на сервере
  • Закрытая (приватная) часть — на компьютере пользователя

При таком подходе войти в систему смогут только пользователи с действующим SSH-ключом, авторизованным на сервере. Попытка авторизоваться по логину и паролю закончится неудачей.

Предупреждение

Важно создать ключи авторизации и настроить вход по этим ключам перед отключением входа по паролю.

Защита WEB-доступа (Horizon)

При доступе к WEB UI на уровне администратора и пользователя наиболее распространённым является комбинация способов HTTPS + LDAP.

Схема аутентификации:

  1. Пользователь по протоколу HTTPS подключается к Horizon (веб-интерфейс OpenStack)
  2. Horizon передаёт запрос аутентификации в Keystone (сервис идентификации OpenStack)
  3. Keystone выполняет проверку учётных данных через службу LDAP
  4. В случае успешной проверки пользователь попадает в соответствующую группу LDAP
  5. Для этой группы Keystone имеет набор прав, реализуемых в OpenStack механизмами RBAC (Role-Based Access Control)

Рекомендации по комплексной защите

  1. Комбинируйте методы защиты — используйте SSH-ключи для администраторов и HTTPS+LDAP для веб-доступа
  2. Регулярно обновляйте политики паролей и доступа
  3. Внедряйте системы мониторинга попыток несанкционированного доступа (fail2ban, auditd)
  4. Используйте RBAC для чёткого разграничения прав доступа
  5. Ведите журналирование всех попыток доступа к системе управления

См.также