Как сделать Elasticsearch безопасным: защищаем Big Data от утечек

Автор Категория , ,
Как сделать Elasticsearch безопасным: защищаем Big Data от утечек

Вчера мы рассказывали про самые известные утечки Big Data с открытых серверов Elasticsearch (ES). Сегодня рассмотрим, как предупредить подобные инциденты и надежно защитить свои большие данные. Читайте в нашей статье про основные security-функции ELK-стека: какую безопасность они обеспечивают и в чем здесь подвох.

Несколько cybersecurity-решений для ES под разными лицензиями

Чуть больше года назад, 20 мая 2019, компания Elastic сообщила, что базовые функции обеспечения информационной безопасности ELK-стека, будут теперь бесплатными для всех пользователей, а не только тех, кто подписан на коммерческой основе. Под этим имелись ввиду следующие возможности [1]:

  • криптографический протокол транспортного уровня TLS для шифрованной связи;
  • инструментарий для создания и управления пользовательскими записями (file и native-realm);
  • управление доступом пользователей к API и кластеру на основе ролей (RBAC, Role Based Access Control);
  • многопользовательский доступ к Kibana с использованием Kibana Spaces.

Однако, эти новости не встретили ответного энтузиазма со стороны профессионального сообщества [2]. В частности, потому, что преобладающее число компонентов ELK-стека (Elasticsearch, LogStash, Kibana, FileBeats, Grafana) и так были бесплатными и открытыми, распространяясь по лицензии Apache 2.0. А X-Pack, коммерческий продукт компании Elastic, расширяющий возможности ELK, включая обеспечение cybersecurity, был не бесплатным и распространялся по лицензии Elastic License. Он стал открытым с 2018 года, но не перестал быть коммерческим. Возмущение пользователей вызвал факт путаницы с лицензиями: с версии 6.3 ELK и X-Pack интегрированы в один репозиторий на Github, из-за чего невозможно понять, какое решение бесплатное, а за что нужно платить [3].

ELK, Elastic Stack, Elasticsearch
Изменения в схеме лицензирования продуктов Elastic Stack

В свете этого события компания Amazon выступила с собственным продуктом на основе ELK Stack: Open Distro for Elasticsearh. С точки зрения cybersecurity наиболее интересны следующие возможности Open Distro [4]:

  • средства защиты кластера – аутентификация через Active Directory, Kerberos, SAML и OpenID, единая точка входа (SSO), поддержка шифрования трафика, RBAC-модель избирательного разграничения доступа, детальное логгирование и инструменты для обеспечения соблюдения требований (compliance);
  • система отслеживания событий и генерации предупреждений для мониторинга за состоянием данных с автоматической отправкой уведомлений при возникновении внештатных ситуаций и нарушении безопасности. Определить условия подобных событий можно через язык запросов Elasticsearch и средства написания скриптов. Визаулизация мониторинга осуществляется через web-интерфейс Kibana.

Подробнее об Open Distro мы рассказываем здесь. Впрочем, этот продукт от Amazon – не единственное коммерческое cybersecurity-решение для Elasticsearch. Еще один пример – Search Guard, модуль комплексного обеспечения безопасности, включая аутентификацию через Active Directory, LDAP, Kerberos, веб-токены JSON, SAML, OpenID и многие другие. Также он поддерживает детальный RBSC-доступ к индексам, документам и полям, многопользовательский режим в Kibana и требования GDPR, HIPAA, PCI, SOX и ISO с помощью аудита изменений и ведения журнала соответствия [5].

Как обеспечить безопасность бесплатного Elasticsearch: алгоритм действий Big Data администратора

При использовании бесплатной версии Elasticsearch следует вручную обеспечить ее безопасность. Для того администратор Big Data должен выполнить ряд мероприятий [6]:

  • защитить подключение к СУБД, настроив аутентификацию с помощью Open Distro от Amazon. Например, на Debian-подобных операционных системах, в частности, Ubuntu, для этого в консоли следует прописать команду установки плагина из репозитория:

wget -qO ‐ https://d3g5vo6xdbdb9a.cloudfront.net/GPG-KEY-opendistroforelasticsearch | sudo apt-key add –

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

Также стоит помнить про открытые по умолчанию порты: ES использует порт 9200 для HTTP-трафика и 9300 – для сообщения между узлами кластера. Их рекомендуется заменить другими, отредактировав файл elasticsearch.yml на каждом сервере. Это позволит ограничить внешний доступ к ES-СУБД, чтобы посторонние не могли получить доступ к данным или отключить весь кластер Elasticsearch через REST API [7].

В качестве альтернативы можно включить в ELK-кластер обратный прокси-сервер (reverse proxy), например, Nginx, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. Для клиента это будет выглядеть, как будто запрашиваемые ресурсы находятся непосредственно на самом прокси-сервере. В отличие от классического прокси, который перенаправляет запросы клиентов к любым серверам в сети и возвращает им результат, reverse proxy взаимодействует напрямую лишь с ассоциированными узлами и возвращает ответ только от них [8]. Таким образом, Nginx в качестве обратного прокси-сервера позволит обеспечить защиту Elasticsearch и Kibana от доступа неавторизованных пользователей. Для этого потребуется включить протокол HTTPS с использованием корректного сертификата SSL [9].

Здесь стоит отметить возможность применения Cilium – open-source продукта для прозрачной защиты сетевого подключения между службами приложений, развернутыми на платформах управления контейнерами Linux, таких как Docker и Kubernetes. Cilium основан на BPF – технологии ядра Linux, которая обеспечивает видимость и безопасность сети по API без изменений в коде приложения или контейнерах. Cilium полностью распределяется на узлах Linux, где выполняются рабочие нагрузки, избегая централизованных точек. Интеграция с Kubernetes позволяет Cilium объединять видимость трафика с идентификацией модуля и применять правильные политики безопасности, даже при работе на разных узлах кластера. Cilium может фильтровать отдельные вызовы API и применять политики, которые разрешают доступ с наименьшими привилегиями для Elasticsearch и любых других API-служб на основе протоколов HTTP, gRPC и Kafka. Политики видимости и безопасности эффективно реализуются в виде потоков сетевых данных через ядро в контейнер и из него без обходных путей к централизованному межсетевому экрану или прокси [10].

Cillium, Elasticsearch, утечки данных, cybersecurity
Использование Cillium для защиты Elasticsearch от утечек

В следующей статье мы рассмотрим, как использовать ELK Stack для аналитики больших данных и работать с алгоритмами машинного обучения (Machine Learning) в Elasticsearch и Kibana. А как на практике обеспечить информационную безопасность кластера Elasticsearch и других систем сбора и анализа больших данных в своих проектах цифровизации, вы узнаете на практических курсах по администрированию и эксплуатации Big Data систем в нашем лицензированном учебном центре повышения квалификации и обучения руководителей и ИТ-специалистов (разработчиков, архитекторов, инженеров и аналитиков) в Москве.

Источники

  1. https://www.elastic.co/blog/security-for-elasticsearch-is-now-free
  2. https://habr.com/ru/company/itsumma/blog/453110/
  3. https://habr.com/ru/post/443528/
  4. https://www.opennet.ru/opennews/art.shtml?num=50322
  5. https://www.fgts.ru/collection/search-guard
  6. https://habr.com/ru/company/dataline/blog/487210/
  7. https://www.digitalocean.com/community/tutorials/how-to-install-elasticsearch-logstash-and-kibana-elastic-stack-on-ubuntu-18-04-ru
  8. https://ru.wikipedia.org/wiki/Обратный_прокси
  9. https://netpoint-dc.com/blog/elk-authentication-nginx/
  10. https://cilium.io/blog/2018/07/10/cilium-security-elasticsearch/