☰

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

tag-icon • tag-icon security elasticsearch
Обеспечение безопасности elasticsearch

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

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

Может ли кто-нибудь объяснить мне метод блокировки Elasticsearch, чтобы я мог выполнять следующие действия в безопасной среде:

  • Несколько индексов на пользователя. Предположим, я могу создать это для них заранее, пользователь не должен иметь возможности выполнять операции с индексами других пользователей, за исключением, возможно, запросов к ним, если предоставлено разрешение. (Возможно, какая-то форма секретного ключа в URL для каждого пользователя?)

  • Пользователи могут добавлять и удалять объекты из своих индексов по своему усмотрению, но не могут удалять свои индексы.

  • Некая форма ограничения размера памяти для пользователя, чтобы в случае возникновения неполадок он не мог перегрузить службу.

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

решение1

По моему мнению, единственный способ защитить ES так, как вы предлагаете, — это запереть его за другим прикладным уровнем и поручить этому уровню управлять транспортом https/ssl, аутентификацией и контролем авторизации.

Что касается ES, то был разработан плагин безопасности Jetty ES. Не знаю, был ли он успешным. Когда я впервые развертывал ES, плагин был готов к выпуску, так что посмотрите на него:

ПЛАГИН ES JETTY

решение2

Думаю, вам нужно будет создать промежуточный HTTP-прокси со всей этой "бизнес-логикой" и разрешить доступ ElasticSearch только с локального хоста. Таким образом, прямой доступ к ES блокируется, и вы можете определять и применять любые политики, которые захотите (ура! ;)

«даже если я предоставлю для этого пользовательский уровень API, кто-то сможет легко обойти его»: они не смогут этого сделать, если ES принимает соединения только с локального хоста.

Я не думаю, что ограничения по использованию памяти возможны. Может быть, вы могли бы предварительно одобрять запросы в рамках прокси-слоя?

решение3

Я сделал что-то похожее, используя Nginx, запущенный перед ES. В Nginx можно настроить «авторизацию» на основе ключевых слов в URL. Обратитесь к варианту использования, определенному в этом документе:http://www.elasticsearch.org/blog/playing-http-tricks-nginx/

решение4

Я привязал elasticsearch к туннелю openvpn:

В /etc/elasticsearch/elasticsearch.yml:

network.host: 172.16.xxx.xxx

Где 172.16.xxx.xxx — это IP-адреса, назначенные openvpn.

Связанный контент