ლოგების ცენტრალიზაცია — Elasticsearch, Logstash, Kibana და Graylog

ინციდენტის დროს ყველაზე ძვირი წუთები ის წუთებია, როცა ინჟინერი SSH-ით შედის მეხუთე სერვერზე იმის გასარკვევად, რაც პირველ ოთხზე ვერ იპოვა. ლოგები არსად არ დაკარგულა — ისინი უბრალოდ ორმოც სხვადასხვა ადგილას წერია, სხვადასხვა ფორმატით, სხვადასხვა დროის ზონაში, და ნაწილი მათგანი უკვე გადაბრუნდა როტაციით.

ლოგების ცენტრალიზაცია სწორედ ამ პრობლემას წყვეტს და არა „მონიტორინგს“. მონიტორინგი გეუბნებათ, რომ რაღაც გატყდა; ლოგები გეუბნებათ, რატომ.

ოთხი კომპონენტი და მათი ნამდვილი როლი#

Elasticsearch — საცავი და საძიებო ძრავა. ეს არის ინვერსიულ ინდექსზე აგებული განაწილებული ბაზა: ტექსტს ინდექსავს ისე, რომ „მოძებნე ეს სტრიქონი ორ მილიარდ ჩანაწერში“ წამებში და არა საათებში სრულდებოდეს. მონაცემი იყოფა შარდებად, თითოეულს აქვს რეპლიკა, და სწორედ აქ იბადება პროექტის მთავარი ხარჯი — ინდექსი თავად ლოგზე დიდია.

Logstash — დამუშავების მილსადენი. სამი საფეხური: input (საიდან მოდის), filter (როგორ იშლება) და output (სად მიდის). სწორედ filter-ში იქცევა ტექსტის ხაზი ველებად — grok-ით ან, სადაც ფორმატი ფიქსირებულია, გაცილებით სწრაფი dissect-ით.

Logstash JVM-ზე მუშაობს და მძიმეა. ამიტომ პრაქტიკაში მას აგენტად არ დგამენ: მოწყობილობებზე მსუბუქი გამგზავნი დგება (Filebeat და მისი ოჯახი, ან უბრალოდ syslog), ხოლო Logstash ცენტრში დგას, სადაც პარსინგი ერთხელ კეთდება.

Kibana — კითხვის ფენა. მოთხოვნები, დაფები, ველების კვლევა. Kibana თავად არაფერს ინახავს — ის Elasticsearch-ის ინტერფეისია.

Graylog — მზა პროდუქტი ამ ყველაფრის ზემოთ. Graylog იყენებს Elasticsearch-ს ან OpenSearch-ს საცავად და MongoDB-ს საკუთარი კონფიგურაციისთვის, მაგრამ თავად აწვდის იმას, რაც სუფთა ELK-ში ხელით უნდა აწყოთ: stream-ები (შემომავალი ნაკადის მარშრუტიზაცია), pipeline-ები (წესებით დამუშავება), alert-ები, როლებზე დაფუძნებული წვდომა და მზა ძებნის ინტერფეისი.

ELK თუ Graylog#

განსხვავება არა ხარისხშია, არამედ იმაში, რამდენს აწყობთ თავად:

• Graylog უფრო სწრაფად გაშვებადია, როცა ამოცანა კლასიკურია — syslog მოწყობილობებიდან, აპლიკაციის ლოგები, ძებნა, alert-ები, წვდომის გამიჯვნა გუნდებს შორის. RBAC და stream-ები კოლოფშივეა.
• ELK უფრო შორს მიდის, როცა ლოგი მხოლოდ ლოგი აღარაა — მეტრიკებთან შერევა, საკუთარი ვიზუალიზაცია, მანქანური დამუშავება, ან როცა Elasticsearch უკვე გიდგათ სხვა ამოცანისთვის.

არჩევანი, ჩვენი გამოცდილებით, თითქმის არასდროს წყდება ფუნქციების სიით. ის წყდება იმით, ვინ მოუვლის სისტემას მესამე თვეს.

რაც პროექტს მართლა წყვეტს#

ინსტრუმენტის არჩევა ყველაზე ნაკლებად საინტერესო გადაწყვეტილებაა. სამი სხვა კი — ყველაზე ძვირი:

1. შენახვის ვადა და დისკი. ეს ერთადერთი რიცხვია, რომელიც პროექტს ან ამართლებს, ან კლავს. ინდექსირებული ლოგი ნედლ ტექსტზე დიდია, რეპლიკა მას ორმაგდება, და „ვინახოთ ერთი წელი, ყოველი შემთხვევისთვის“ ხშირად უფრო ძვირია, ვიდრე თავად ინციდენტი. პასუხი ინდექსის სასიცოცხლო ციკლია: ცხელი მონაცემი სწრაფ დისკზე, თბილი — ნელზე, ცივი — არქივში ან საერთოდ ობიექტურ საცავში.

2. სად იშლება ლოგი — ჩაწერისას თუ ძებნისას. ჩაწერისას პარსინგი ძვირია პროცესორში, მაგრამ ძებნას აჩქარებს და ველებს სტრუქტურირებულს ხდის. ძებნისას პარსინგი პირიქით. არასწორად არჩეული მხარე მესამე თვეს იჩენს თავს, როცა უკან დაბრუნება უკვე რეინდექსაციას ნიშნავს.

3. დროის სინქრონიზაცია. ეს ბანალურად ჟღერს, სანამ ორი მოწყობილობის ლოგს ერთ ღერძზე არ დააწყობთ და არ აღმოაჩენთ, რომ ერთი მათგანი ორი წუთით უკან მიდის. კორელაცია დროზე დგას; NTP ლოგირების პროექტის ნაწილია, არა მისი წინაპირობა.

სად ჩერდება ლოგების სისტემა#

ცენტრალიზებული ლოგირება ჯერ არ არის SIEM. ის აგროვებს, ინახავს და ეძებს. SIEM იწყება იქ, სადაც ჩნდება კორელაციის წესები („ხუთი წარუმატებელი ავტორიზაცია, შემდეგ ერთი წარმატებული, სხვა ქვეყნიდან“), threat intelligence და ინციდენტის სამუშაო პროცესი.

ეს ფენა ცალკე ეწყობა — Wazuh, Graylog-ის security-შესაძლებლობები ან სპეციალიზებული SIEM — და ცალკე ინახება: უსაფრთხოების ლოგს სხვა შენახვის ვადა და ხშირად ცვლილებისგან დაცვის მოთხოვნაც აქვს, რაც საოპერაციო ლოგს არ სჭირდება.

სწორედ ამიტომ არის ჩვენთან ეს ორი სერვისი გამიჯნული: საოპერაციო ლოგირება პასუხობს კითხვას „რა მოხდა“, უსაფრთხოების ლოგირება და SIEM კი — „ვინ და რატომ“.