Elastic Stack — znane narzędzie na rynku systemów SIEM (ogólnie mówiąc, nie tylko ich). Może zbierać wiele danych różnego rodzaju, zarówno wrażliwych, jak i mniej. Nie jest całkowicie właściwe, aby dostęp do elementów Elastic Stack nie był zabezpieczony. Domyślnie wszystkie standardowe elementy Elastic (Elasticsearch, Logstash, Kibana oraz zbieracze Beats) działają na otwartych protokołach. W samej Kibanie wyłączona jest autoryzacja. Wszystkie te interakcje można zabezpieczyć, a w tym artykule opowiemy, jak to zrobić. Dla wygody podzieliliśmy narrację na 3 bloki tematyczne:
- Model dostępu oparty na rolach
- Bezpieczeństwo danych wewnątrz klastra Elasticsearch
- Bezpieczeństwo danych na zewnątrz klastra Elasticsearch
Szczegóły poniżej.
Model dostępu oparty na rolach
Jeśli zainstalujesz Elasticsearch i nie skonfigurujesz go, dostęp do wszystkich indeksów będzie otwarty dla wszystkich chętnych. Cóż, lub tych, którzy potrafią korzystać z curl. Aby temu zapobiec, w Elasticsearch dostępny jest model oparty na rolach, który jest dostępny od subskrypcji na poziomie Basic (jest darmowy). Schematycznie wygląda to mniej więcej tak:
Co na obrazku
- Użytkownicy – to wszyscy, którzy mogą się logować przy użyciu swoich danych uwierzytelniających.
- Rola – to zbiór praw.
- Prawa – to zestaw przywilejów.
- Przywileje – to zezwolenia na zapis, odczyt, usuwanie itd. ()
- Zasoby – to indeksy, dokumenty, pola, użytkownicy i inne podmioty magazynu (model ról dla niektórych zasobów dostępny jest tylko w płatnych subskrypcjach).
W Elasticsearch domyślnie znajdują się , do których przypisane są . Po włączeniu ustawień bezpieczeństwa można je natychmiast zacząć używać.
Aby aktywować bezpieczeństwo w ustawieniach Elasticsearch, należy dodać do pliku konfiguracyjnego (domyślnie jest to elasticsearch/config/elasticsearch.yml) nowy wiersz:
xpack.security.enabled: truePo zmianie pliku konfiguracyjnego uruchamiamy lub restartujemy Elasticsearch, aby zmiany zaczęły obowiązywać. Następnym krokiem jest przypisanie haseł wbudowanym użytkownikom. Zrobimy to interaktywnie za pomocą poniższej komendy:
[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-setup-passwords interactive
Inicjowanie konfiguracji haseł dla zarezerwowanych użytkowników elastic, apm_system, kibana, logstash_system, beats_system, remote_monitoring_user.
Zostaniesz poproszony o wprowadzenie haseł w miarę postępu procesu.
Proszę potwierdzić, że chcesz kontynuować [y/N]y
Wprowadź hasło dla [elastic]:
Ponownie wprowadź hasło dla [elastic]:
Wprowadź hasło dla [apm_system]:
Ponownie wprowadź hasło dla [apm_system]:
Wprowadź hasło dla [kibana]:
Ponownie wprowadź hasło dla [kibana]:
Wprowadź hasło dla [logstash_system]:
Ponownie wprowadź hasło dla [logstash_system]:
Wprowadź hasło dla [beats_system]:
Ponownie wprowadź hasło dla [beats_system]:
Wprowadź hasło dla [remote_monitoring_user]:
Ponownie wprowadź 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]
Sprawdzanie:
[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żna się pochwalić — konfiguracja po stronie Elasticsearch została zakończona. Teraz czas na konfigurację Kibana. 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 podane podczas 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 w porządku, Kibana zacznie prosić o login i hasło. W subskrypcji poziomu Basic dostępny jest model ról oparty na użytkownikach wewnętrznych. Od poziomu Gold można podłączać zewnętrzne systemy uwierzytelniania — LDAP, PKI, Active Directory oraz systemy Single sign-on.
Uprawnienia do obiektów wewnątrz Elasticsearch również można ograniczyć. Jednak aby zrobić to samo dla dokumentów lub pól, wymagana jest płatna subskrypcja (ta przyjemność zaczyna się od poziomu Platinum). Te ustawienia są dostępne w interfejsie Kibana lub przez . Można to sprawdzić przez znane już 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
Gdy Elasticsearch działa w klastrze (co jest powszechne), kluczowe stają się ustawienia bezpieczeństwa wewnątrz klastra. Aby zapewnić bezpieczną komunikację między węzłami, Elasticsearch korzysta z 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ższego polecenia w katalogu /../elasticsearch pojawi się archiwum elastic-stack-ca.zip. W jego wnętrzu znajdą się certyfikat i klucz prywatny z rozszerzeniami crt и key odpowiednio. Warto je umieścić w zasobie współdzielonym, do którego powinien być dostęp ze wszystkich węzłów klastra.
Dla każdego węzła potrzebne są teraz własne certyfikaty i klucze prywatne na podstawie tych, które znajdują się w współdzielonym katalogu. Podczas wykonania polecenia poproszą o podanie hasła. Można dodać dodatkowe opcje —ip i —dns dla pełnej weryfikacji współpracujących węzłów.
[elastic@node1 ~]$ ./elasticsearch/bin/elasticsearch-certutil cert --ca-cert /shared_folder/ca/ca.crt --ca-key /shared_folder/ca/ca.keyW wyniku wykonania polecenia uzyskamy certyfikat i 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/configDodajemy 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_passwordDo już znanego 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 zrobione poprawnie, otrzymamy odpowiedź z kilkoma nodami:
[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 - node1Jest 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 dozwolony jest dostęp do nod.
Bezpieczeństwo danych na zewnątrz klastra Elasticsearch
Poza klastrem oznacza podłączenie zewnętrznych narzędzi: Kibana, Logstash, Beats lub innych klientów zewnętrznych.
Aby skonfigurować wsparcie dla https (zamiast http), dodamy nowe linie do 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.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 połączenia przez https. Można je teraz uruchomić.
Następny krok — 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 na razie 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 rozpakować utworzone klucze do folderu z konfiguracją Kibana:
[elastic@node1 ~]$ unzip elasticsearch/certificate-bundle.zip -d kibana/configSkoro klucze są, musimy tylko zmienić konfigurację Kibana, aby zaczęła je wykorzystywać. W pliku konfiguracyjnym kibana.yml zmieniamy http na https i dodajemy linie z ustawieniami połączenia SSL. Ostatnie trzy linie konfigurują 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 są skonfigurowane, 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, zapytania dotyczące monitorowania lub tworzenia systemu SIEM, zostaw wiadomość w na naszej stronie.
Oto nasze artykuły na temat Elastic Stack na Habrze:
Źródło: habr.com
