image

Elastic Stack — известный инструмент на рынке SIEM-систем (вообще-то, не только их). Может собирать в себя много разнокалиберных данных, как чувствительных, так и не очень. Не совсем правильно, если доступ к самим элементам Elastic Stack не будет защищён. По умолчанию все коробочные элементы Elastic (Elasticsearch, Logstash, Kibana и коллекторы Beats) работают по открытым протоколам. А в самой Kibana отключена аутентификация. Все эти взаимодействия можно обезопасить и в этой статье мы расскажем как это сделать. Для удобства разделили повествование на 3 смысловых блока:

  • Ролевая модель доступа к данным
  • Безопасность данных внутри кластера Elasticsearch
  • Безопасность данных вне кластера Elasticsearch

Подробности под катом.

Ролевая модель доступа к данным


Если установить Elasticsearch и никак его тюнить — доступ ко всем индексам будет открыт для всех желающих. Ну, или тех, кто может пользоваться curl. Чтобы этого избежать, в Elasticsearch есть ролевая модель, которая доступна начиная с подписки уровня Basic (она бесплатна). Схематически выглядит примерно так:



Что на картинке
  • Пользователи — это все кто может авторизоваться с использованием учётных данных.
  • Роль — это набор прав.
  • Права — это набор привилегий.
  • Привилегии — это разрешения на запись, чтение, удаление и т.д. (Полный список привилегий)
  • Ресурсы — это индексы, документы, поля, пользователи и другие субъекты хранилища (ролевая модель для некоторых ресурсы доступна только в платных подписках).


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

Чтобы активировать безопасность в настройках Elasticsearch, нужно добавить в конфигурационный файл (по умолчанию это elasticsearch/config/elasticsearch.yml) новую строку:

xpack.security.enabled: true

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

[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-setup-passwords interactive
Initiating the setup of passwords for reserved users elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user.
You will be prompted to enter passwords as the process progresses.
Please confirm that you would like to continue [y/N]y


Enter password for [elastic]:
Reenter password for [elastic]:
Enter password for [apm_system]:
Reenter password for [apm_system]:
Enter password for [kibana]:
Reenter password for [kibana]:
Enter password for [logstash_system]:
Reenter password for [logstash_system]:
Enter password for [beats_system]:
Reenter password for [beats_system]:
Enter password for [remote_monitoring_user]:
Reenter password for [remote_monitoring_user]:
Changed password for user [apm_system]
Changed password for user [kibana]
Changed password for user [logstash_system]
Changed password for user [beats_system]
Changed password for user [remote_monitoring_user]
Changed password for user [elastic]

Проверяем:

[elastic@node1 ~]$ curl -u elastic 'node1:9200/_cat/nodes?pretty'
Enter host password for user 'elastic':
192.168.0.2 23 46 14 0.28 0.32 0.18 dim * node1

Можно хлопнуть себя по плечу — настройки на стороне Elasticsearch выполнены. Теперь пришла очередь настроить Kibana. Если запустить её сейчас, посыплются ошибки, поэтому важно создать хранилище ключей. Делается, это в две команды (пользователь kibana и пароль, введённый на шаге создания паролей в Elasticsearch):

[elastic@node1 ~]$ ./kibana/bin/kibana-keystore add elasticsearch.username
[elastic@node1 ~]$ ./kibana/bin/kibana-keystore add elasticsearch.password

Если всё правильно — Kibana начнёт просить логин и пароль. В подписке уровня Basic доступна ролевая модель на основе внутренних пользователей. Начиная с Gold можно подключать внешние системы аутентификации — LDAP, PKI, Active Directory и системы Single sign-on.



Права доступа к объектам внутри Elasticsearch тоже можно ограничить. Правда, чтобы то же самое сделать для документов или полей, потребуется платная подписка (эта роскошь начинается с уровня Platinum). Эти настройки доступны в интерфейсе Kibana или через Security API. Можно проверить через уже знакомое меню Dev Tools:

Создание роли
PUT /_security/role/ruslan_i_ludmila_role
{
  "cluster": [],
  "indices": [
    {
      "names": [ "ruslan_i_ludmila" ],
      "privileges": ["read", "view_index_metadata"]
    }
  ]
}


Создание пользователя
POST /_security/user/pushkin
{
  "password" : "nataliaonelove",
  "roles" : [ "ruslan_i_ludmila_role", "kibana_user" ],
  "full_name" : "Alexander Pushkin",
  "email" : "pushkin@lyceum.edu",
  "metadata" : {
    "hometown" : "Saint-Petersburg"
  }
}


Безопасность данных внутри кластера Elasticsearch


Когда Elasticsearch работает в кластере (а это обычное дело), важными становятся настройки безопасности внутри кластера. Для безопасного взаимодействия между нодами, Elasticsearch использует протокол TLS. Чтобы настроить безопасное взаимодействие между ними, нужен сертификат. Генерируем сертификат и приватный ключ в PEM-формате:

[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-certutil ca --pem

После выполнения команды выше, в директории /../elasticsearch появится архив elastic-stack-ca.zip. Внутри него обнаружатся сертификат и приватный ключ с раширениями crt и key соответственно. Их желательно выложить на shared ресурс, к которому должен быть доступ со всех нод кластера.

Для каждой ноды теперь нужны свои сертификаты и приватные ключи на основе тех, что лежат в shared директории. При выполнении команды попросят задать пароль. Можно добавить дополнительные опции --ip и --dns для полной верификации взаимодействующих нод.

[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-certutil cert --ca-cert /shared_folder/ca/ca.crt --ca-key /shared_folder/ca/ca.key

По итогам выполнения команды получим сертификат и приватный ключ в формате PKCS#12, защищённый паролем. Осталось переместить сгенерированный файл p12 в директорию с конфигурацией:

[elastic@node1 ~]$ mv elasticsearch/elastic-certificates.p12 elasticsearch/config

Добавим пароль к сертификату в формате p12 в keystore и truststore на каждой ноде:

[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-keystore add xpack.security.transport.ssl.keystore.secure_password
[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-keystore add xpack.security.transport.ssl.truststore.secure_password

В уже известный elasticsearch.yml осталось добавить строки с данными о сертификате:

xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

Запускаем все ноды Elasticsearch и выполняем curl. Если всё было выполнено верно, вернётся ответ с несколькими нодами:

[elastic@node1 ~]$ curl node1:9200/_cat/nodes -u elastic:password                                                                                    
172.18.0.3 43 75 4 0.00 0.05 0.05 dim * node2                                                                                                                     
172.18.0.4 21 75 3 0.00 0.05 0.05 dim - node3                                                                                                                     
172.18.0.2 39 75 4 0.00 0.05 0.05 dim - node1

Есть ещё одна опция по безопасности — фильтрация IP-адресов (доступна в подписках от уровня Gold). Позволяет создавать белые списки IP-адресов, с которых разрешено обращаться к нодам.

Безопасность данных вне кластера Elasticsearch


Вне кластера означает подключение внешних инструментов: Kibana, Logstash, Beats или другие внешние клиенты.



Чтобы настроить поддержку https (вместо http), добавим в elasticsearch.yml новые строки:

xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: elastic-certificates.p12
xpack.security.http.ssl.truststore.path: elastic-certificates.p12

Т.к. сертификат защищён паролем, добавим его в keystore и truststore на каждой ноде:

[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-keystore add xpack.security.http.ssl.keystore.secure_password
[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-keystore add xpack.security.http.ssl.truststore.secure_password

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

Следующий шаг — создание ключа для подключение Kibana и его добавление в конфигурацию. На основе сертификата, который уже размещён в shared директории, сгенерируем сертификат в PEM-формате (PKCS#12 Kibana, Logstash и Beats пока не поддерживают):

[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-certutil cert --ca-cert /shared_folder/ca/ca.crt --ca-key /shared_folder/ca/ca.key --pem

Осталось распаковать созданные ключи в папку с конфигурацией Kibana:

[elastic@node1 ~]$ unzip elasticsearch/certificate-bundle.zip -d kibana/config

Ключи есть, значит осталось изменить конфигурацию Kibana, чтобы она начала их использовать. В конфигурационном файле kibana.yml меняем http на https и добавляем строки с настройками SSL-подключения. Последние три строки настраивают безопасное взаимодействие между браузером пользователя и Kibana.

elasticsearch.hosts: ["https://${HOSTNAME}:9200"]
elasticsearch.ssl.certificateAuthorities: /shared_folder/ca/ca.crt
elasticsearch.ssl.verificationMode: certificate
server.ssl.enabled: true
server.ssl.key: /../kibana/config/instance/instance.key
server.ssl.certificate: /../kibana/config/instance/instance.crt

Таким образом, настройки выполнены и доступ к данным в кластере Elasticsearch зашифрован.

Если у вас есть вопросы по возможностям Elastic Stack на бесплатных или платных подписках, задачи по мониторингу или созданию SIEM-системы оставьте запрос в форме обратной связи на нашем сайте. А ещё можно подписаться на наш Фейсбук.

Ещё наши статьи об Elastic Stack на Хабре:

Разбираемся с Machine Learning в Elastic Stack (он же Elasticsearch, он же ELK)

Сайзинг Elasticsearch