როგორ გავაგზავნოთ მოწყობილობის ჟურნალები დისტანციურ შემგროვებელთან უსაფრთხოდ

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

დაიწყეთ იმით, რისი გამოცემაც მოწყობილობას შეუძლია

პრაქტიკაში მხოლოდ სამი ფორმაა. ცალკეული syslog მოვლენები UDP ან TCP-ით, პროდუქტში ჩაშენებული ავთენტიფიცირებული HTTPS ატვირთვა, ან დისკზე ჩაწერილი სრული ფაილები, რომლებიც გადასატანია. ბრენდმაუერი, რომელსაც მხოლოდ UDP syslog-ის გაგზავნა შეუძლია, არ გახდება TLS გამომგზავნი იმის გამო, რომ გვირაბი დაამატეთ; ის კვლავ გაუგზავნის დაუდასტურებელ დატაგრამებს, ახლა დაშიფრულ კონვერტში.

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

TLS syslog: უმოკლესი გზა, როცა ორივე მხარე ლაპარაკობს მასზე

თუ მოწყობილობა მხარს უჭერს syslog-ს TLS-ის მეშვეობით და შემგროვებელი ამთავრებს მას, გამოიყენეთ ეს და გაჩერდით. აპლიკაციის პროტოკოლი თავს იცავს, შემგროვებელი ავთენტიფიცირებს გამომგზავნს, და აღარ არსებობს დამატებითი ნახტომი, რომლის ხელმისაწვდომობაც ახლა თქვენ გაქვთ. ხაფანგი ისაა, რომ „TLS syslog“ მოიცავს განხორციელებების ფართო სპექტრს, და უსაფრთხო syslog-ის მიმდინარე სახელმძღვანელო წინ წავიდა ძველი გაკვეთილების შიფრთა სიებიდან, და ამიტომ მომუშავე გადამცემი ბიბლიოთეკის განახლების შემდეგ ფუჭდება.

rsyslog-ში მხოლოდ სატრანსპორტო მოდულის სახელი გეუბნებათ, რომელ ეპოქაში ხართ: lmnsd_gtls ახვევს GnuTLS-ს, ხოლო lmnsd_ossl ახვევს OpenSSL-ს და ამას აწვდიან მიმდინარე 8.x პაკეტები. სერტიფიკატის შემოწმებით გადაგზავნის ოპერაცია დაახლოებით ასე გამოიყურება, და ზუსტი პარამეტრების სახელები ღირს შეამოწმოთ თქვენს დაინსტალირებულ ვერსიასთან:

action(type="omfwd" target="collector.example" port="6514" protocol="tcp"
       StreamDriver.Name="ossl" StreamDriver.Mode="1" StreamDriver.AuthMode="x509/name"
       StreamDriver.CAFile="/etc/pki/ca.pem"
       queue.type="LinkedList" queue.filename="fwdq" queue.maxDiskSpace="1g"
       queue.saveOnShutdown="on" action.resumeRetryCount="-1")

შეამოწმეთ ბოლო წერტილი გამომგზავნის გამართვამდე. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error ან ასრულებს ხელის ჩამორთმევას სწორი ჯაჭვით, ან ზუსტად გეუბნებათ, რომელი შემოწმება ჩავარდა. სცადეთ მოწყობილობიდან, არა ლეპტოპიდან, რადგან მოწყობილობის ნდობის საცავია მთავარი.

SFTP: კარგია ფაილებისთვის, არასწორია ნაკადებისთვის

ფაილზე დაფუძნებული მიწოდება შეეფერება მოწყობილობებს, რომლებიც ბრუნავ ჟურნალებს წერენ და სხვა არაფერს. SSH-ზე დაფუძნებული გადაცემა გაძლევთ ჰოსტის გასაღებებს, თითოეული ანგარიშის გასაღებებს და ფაილურ სისტემას, რომლის აუდიტიც შეგიძლიათ, რაც გონივრული ნდობის ისტორიაა მოწყობილობისთვის, რომელსაც საერთოდ არ შეუძლია TLS. ცუდი არჩევანია მოვლენათა ნაკადებისთვის, სადაც „ფაილი ყოველ საათში იწერება“ ნიშნავს, რომ შეფერხება მიმდინარე საათის კუდს გაკარგვინებთ.

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

sftp -b /etc/logship/batch -o BatchMode=yes -o StrictHostKeyChecking=yes      -o IdentitiesOnly=yes -i /etc/logship/id_ed25519 [email protected]

დამაგრეთ ჰოსტის გასაღები ანგარიშის known_hosts-ში მომზადების დროს, შეზღუდეთ ანგარიში სამიზნე დირექტორიით და უპირატესობა მიანიჭეთ internal-sftp ქვესისტემას chroot-ით. დაგეგმეთ გადაგზავნის ისტორიაც: თუ ფაილი ნაწილობრივი წარუმატებლობის შემდეგ ხელახლა გაიგზავნა, შემგროვებელმა უნდა გაარჩიოს დუბლიკატი ახალი ფაილისგან, ჩვეულებრივ სახელით და საკონტროლო ჯამით, და არა ჩამოსვლის დროით.

როცა ლოკალური კარიბჭე ან გვირაბი პატიოსანი პასუხია

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

მარშრუტიზებული საიტის ან მოწყობილობის გვირაბი ყველაზე მძიმე ვარიანტია და სწორია, როცა შემგროვებელმა უნდა შეინარჩუნოს კერძო მისამართი და რამდენიმე სერვისი უნდა ატაროს, არა მხოლოდ ჟურნალები. ის მოაქვს მისამართების დაგეგმვა, წვდომის წესები, დაბრუნების გზები და გვირაბის ბოლო წერტილის სიცოცხლის ციკლი. ის არც შიდა პროტოკოლს აუმჯობესებს: UDP syslog IPsec გვირაბში კვლავ დატაგრამის სერვისია მიწოდების დადასტურების გარეშე.

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

დაწერეთ მიწოდების ხელშეკრულება გაგზავნამდე

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

შემდეგ წერილობით უპასუხეთ ოპერატიულ კითხვებს. სად ელოდება გაუგზავნელი მოვლენები და გადაურჩება ეს ბუფერი დენის გათიშვას? რა ხდება, როცა ივსება, და ვის ატყობინებენ? როგორ შეიზღუდება ხელახალი ცდები და როგორ იდენტიფიცირდება დუბლიკატები? რომელი ველი ამტკიცებს გამომგზავნის იდენტობას, იმის გათვალისწინებით, რომ გადაგზავნის ნახტომმა შეიძლება ჰოსტსახელი გადაწეროს?

დიზაინი იმდენად პატარა შეინახეთ, რომ ერთ აბზაცში აიხსნას: უმცირესი მხარდაჭერილი ტრანსპორტი, რომელიც საჭირო მოვლენებს ატარებს, პლუს მკაფიო განცხადება იმ გარანტიებზე, რომლებსაც ის არ იძლევა. თუ პასუხს ორი ნახტომი სჭირდება, თქვით ეს runbook-ში და თითოეულ ნახტომს მიეცით პატრონი.