Elastic Stack — znane narzędzie na rynku systemów SIEM (w rzeczywistości nie tylko ich). Może zbierać wiele różnych danych, zarówno wrażliwych, jak i mniej. Nie do końca prawidłowe jest, jeśli dostęp do samych elementów Elastic Stack nie będzie zabezpieczony. Domyślnie wszystkie elementy pakietu Elastic (Elasticsearch, Logstash, Kibana oraz zbieracze Beats) działają na otwartych protokołach. A w samej Kibanie wyłączono uwierzytelnianie. Te wszystkie interakcje można zabezpieczyć, a w tym artykule opowiemy, jak to zrobić. Dla wygody podzieliliśmy narrację na 3 sensowne bloki:
- Model ról dostępu do danych
- Bezpieczeństwo danych wewnątrz klastra Elasticsearch
- Bezpieczeństwo danych poza klastrem Elasticsearch
Szczegóły poniżej.
Model ról dostępu do danych
Jeśli zainstalujesz Elasticsearch i nie będziesz go konfiguracja — dostęp do wszystkich indeksów będzie otwarty dla wszystkich chętnych. Cóż, albo dla tych, którzy potrafią korzystać z curl. Aby temu zapobiec, w Elasticsearch istnieje model ról, który jest dostępny od subskrypcji poziomu Basic (jest on bezpłatny). Schematycznie wygląda to mniej więcej tak:
Co na obrazku
- Użytkownicy — to wszyscy, którzy mogą się autoryzować za pomocą danych uwierzytelniających.
- Rola — to zbiór uprawnień.
- Uprawnienia — to zbiór przywilejów.
- Przywileje — to zezwolenia na zapis, odczyt, usuwanie itd. ()
- Zasoby — to indeksy, dokumenty, pola, użytkownicy oraz inne podmioty magazynu (model ról dla niektórych zasobów jest dostępny tylko w płatnych subskrypcjach).
W Elasticsearch domyślnie istnieje , do których przypisane są . Po włączeniu ustawień bezpieczeństwa można je od razu zacząć używać.
Aby aktywować bezpieczeństwo w ustawieniach Elasticsearch, musisz dodać do pliku konfiguracyjnego (domyślnie jest to elasticsearch/config/elasticsearch.yml) nowy wiersz:
xpack.security.enabled: truePo zmianie pliku konfiguracyjnego uruchamiamy lub ponownie uruchamiamy Elasticsearch, aby zmiany weszły w życie. Następny krok to przypisanie haseł użytkownikom pakietowym. Zrobimy to interaktywnie za pomocą poniższej komendy:
[elastic@node1 ~]$ .\/elasticsearch\/bin\/elasticsearch-setup-passwords interactive
Rozpoczynanie konfiguracji haseł dla zarezerwowanych użytkowników elastic,apm_system,kibana,logstash_system,beats_system,remote_monitoring_user.
Zostaniesz poproszony o podanie haseł w miarę postępu procesu.
Proszę potwierdzić, że chcesz kontynuować [y\/N]y
Wprowadź hasło dla [elastic]:
Wprowadź ponownie hasło dla [elastic]:
Wprowadź hasło dla [apm_system]:
Wprowadź ponownie hasło dla [apm_system]:
Wprowadź hasło dla [kibana]:
Wprowadź ponownie hasło dla [kibana]:
Wprowadź hasło dla [logstash_system]:
Wprowadź ponownie hasło dla [logstash_system]:
Wprowadź hasło dla [beats_system]:
Wprowadź ponownie hasło dla [beats_system]:
Wprowadź hasło dla [remote_monitoring_user]:
Wprowadź ponownie hasło dla [remote_monitoring_user]:
Zmieniono hasło dla użytkownika [apm_system]
Zmieniono hasło dla użytkownika [kibana]
Zmieniono hasło dla użytkownika [logstash_system]
Zmieniono hasło dla użytkownika [beats_system]
Zmieniono hasło dla użytkownika [remote_monitoring_user]
Zmieniono hasło dla użytkownika [elastic]
Sprawdzamy:
[elastic@node1 ~]$ curl -u elastic 'node1:9200\/cat\/nodes?pretty'
Wprowadź hasło hosta dla użytkownika 'elastic':
192.168.0.2 23 46 14 0.28 0.32 0.18 dim * node1
Możesz się poklepać po plecach — konfiguracja po stronie Elasticsearch została zakończona. Teraz czas na konfigurację Kibany. Jeśli uruchomisz ją teraz, pojawią się błędy, dlatego ważne jest, aby stworzyć magazyn kluczy. Robi się to w dwóch poleceniach (użytkownik kibana i hasło wprowadzone w kroku tworzenia haseł w Elasticsearch):
[elastic@node1 ~]$ .\/kibana\/bin\/kibana-keystore add elasticsearch.username
[elastic@node1 ~]$ .\/kibana\/bin\/kibana-keystore add elasticsearch.passwordJeśli wszystko jest poprawnie — Kibana zacznie prosić o login i hasło. W subskrypcji poziomu Basic dostępny jest model ról oparty na wewnętrznych użytkownikach. Począwszy od poziomu Gold można łączyć zewnętrzne systemy autoryzacji — LDAP, PKI, Active Directory i systemy Single sign-on.
Uprawnienia do obiektów w obrębie Elasticsearch można również ograniczyć. Jednak aby zrobić to samo dla dokumentów lub pól, wymagana jest płatna subskrypcja (ta luksus zaczyna się od poziomu Platinum). Te ustawienia są dostępne w interfejsie Kibana lub przez . Możesz to sprawdzić za pomocą znanego menu Dev Tools:
Tworzenie roli
PUT \/_security\/role\/ruslan_i_ludmila_role
{
"cluster": [],
"indices": [
{
"names": [ "ruslan_i_ludmila" ],
"privileges": ["read", "view_index_metadata"]
}
]
}Tworzenie użytkownika
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"
}
}Bezpieczeństwo danych wewnątrz klastra Elasticsearch
Kiedy Elasticsearch działa w klastrze (co jest dość powszechne), ważne stają się ustawienia bezpieczeństwa w obrębie klastra. Aby zapewnić bezpieczną komunikację między węzłami, Elasticsearch używa protokołu TLS. Aby skonfigurować bezpieczną komunikację między nimi, potrzebny jest certyfikat. Generujemy certyfikat i klucz prywatny w formacie PEM:
[elastic@node1 ~]$ .\/elasticsearch\/bin\/elasticsearch-certutil ca --pemPo wykonaniu powyższej komendy w katalogu /../elasticsearch pojawi się archiwum elastic-stack-ca.zip. Wewnątrz znajdą się certyfikat oraz klucz prywatny z rozszerzeniami crt i key odpowiednio. Wskazane jest umieszczenie ich w zasobach współdzielonych, do których dostęp powinien mieć cały klaster.
Dla każdej nody są teraz potrzebne własne certyfikaty i klucze prywatne na podstawie tych, które znajdują się w współdzielonym katalogu. Przy wykonaniu komendy będzie wymagane podanie hasła. Można dodać dodatkowe opcje —ip i —dns dla pełnej weryfikacji współpracujących nod.
[elastic@node1 ~]$ . /elasticsearch/bin/elasticsearch-certutil cert --ca-cert /shared_folder/ca/ca.crt --ca-key /shared_folder/ca/ca.keyW wyniku wykonania komendy otrzymamy certyfikat oraz klucz prywatny w formacie PKCS#12, zabezpieczony hasłem. Pozostaje przenieść wygenerowany plik p12 do katalogu z konfiguracją:
[elastic@node1 ~]$ mv elasticsearch/elastic-certificates.p12 elasticsearch/configDodamy hasło do certyfikatu w formacie p12 do keystore i truststore na każdej nodzie:
[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_passwordW już znanym elasticsearch.yml pozostaje dodać linie z danymi o certyfikacie:
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.p12Uruchamiamy wszystkie nody Elasticsearch i wykonujemy curl. Jeśli wszystko zostało wykonane poprawnie, otrzymamy odpowiedź zawierającą kilka nodów:
[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 - node1Istnieje jeszcze jedna opcja dotycząca bezpieczeństwa — filtrowanie adresów IP (dostępne w subskrypcjach od poziomu Gold). Umożliwia tworzenie białych list adresów IP, z których dozwolone jest łączenie się z nodami.
Bezpieczeństwo danych poza klastrem Elasticsearch
Poza klastrem oznacza łączenie zewnętrznych narzędzi: Kibana, Logstash, Beats lub innych zewnętrznych klientów.
Aby skonfigurować wsparcie dla https (zamiast http), dodajemy w elasticsearch.yml nowe linie:
xpack.security.http.ssl.enabled: true
xpack.security.http.ssl.keystore.path: elastic-certificates.p12
xpack.security.http.ssl.truststore.path: elastic-certificates.p12Ponieważ certyfikat jest zabezpieczony hasłem, dodamy je do keystore i truststore na każdej nodzie:
[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_passwordPo dodaniu kluczy, węzły Elasticsearch są gotowe do podłączenia przez https. Można je teraz uruchomić.
Następny krok to utworzenie klucza do połączenia z Kibana i dodanie go do konfiguracji. Na podstawie certyfikatu, który już znajduje się w wspólnym katalogu, wygenerujemy certyfikat w formacie PEM (PKCS#12 Kibana, Logstash i Beats jeszcze tego nie obsługują):
[elastic@node1 ~]$ .\/elasticsearch\/bin\/elasticsearch-certutil cert --ca-cert \/shared_folder\/ca\/ca.crt --ca-key \/shared_folder\/ca\/ca.key --pemPozostało wypakować utworzone klucze do folderu z konfiguracją Kibana:
[elastic@node1 ~]$ unzip elasticsearch\/certificate-bundle.zip -d kibana\/configKlucze są, więc teraz trzeba zmienić konfigurację Kibana, aby zaczęła ich używać. W pliku konfiguracyjnym kibana.yml zmieniamy http na https i dodajemy linie z ustawieniami połączenia SSL. Ostatnie trzy linie konfiguracyjne ustalają bezpieczną komunikację między przeglądarką użytkownika a 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.crtW ten sposób ustawienia zostały dokonane, a dostęp do danych w klastrze Elasticsearch jest szyfrowany.
Jeśli masz pytania dotyczące możliwości Elastic Stack w bezpłatnych lub płatnych subskrypcjach, problemy z monitorowaniem lub tworzeniem systemów SIEM, zostaw zapytanie w na naszej stronie.
Nasze inne artykuły o Elastic Stack na Habra:
Źródło: habr.com
