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. Калі запусціць яе зараз, пасыплюцца памылкі, таму важна стварыць сховішча ключоў. Робіцца, гэта ў дзве каманды (карыстальнік кібана і пароль, уведзены на этапе стварэння пароляў у 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 або праз . Можна праверыць праз ужо знаёмае меню 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" : "[email protected]",
"metadata" : {
"hometown" : "Saint-Petersburg"
}
}Бяспека дадзеных унутры кластара Elasticsearch
Калі Elasticsearch працуе ў кластары (а гэта звычайная справа), важнымі становяцца налады бяспекі ўсярэдзіне кластара. Для бяспечнага ўзаемадзеяння паміж нодамі, Elasticsearch выкарыстоўвае пратакол TLS. Каб наладзіць бяспечнае ўзаемадзеянне паміж імі, патрэбен сертыфікат. Які генеруецца сертыфікат і прыватны ключ у PEM-фармаце:
[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-certutil ca --pemПасля выканання каманды вышэй, у дырэкторыі /../elasticsearch з'явіцца архіў elastic-stack-ca.zip. Унутры яго выявяцца сертыфікат і прыватны ключ з пашырэннямі. крэст и ключ адпаведна. Іх пажадана выкласці на 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 і выконваем завітак. Калі ўсё было выканана дакладна, вернецца адказ з некалькімі нодамі:
[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 на Хабры:
Крыніца: habr.com