Jak bezpiecznie wysyłać logi urządzenia do zdalnego kolektora

Urządzenie może emitować logi, kolektor stoi po drugiej stronie internetu, a pierwsze pytanie, jakie wszyscy zadają, brzmi: który tunel zbudować. Ta rama zaczyna się w złym miejscu. O transporcie decydują format, który urządzenie może wytworzyć, uwierzytelnienie, które zaakceptuje kolektor, oraz to, co ma znaczyć „dostarczono”, gdy łącze padnie. Zapisz te trzy odpowiedzi, a transport zwykle sam się wybiera.

Zacznij od tego, co urządzenie może emitować

W praktyce istnieją tylko trzy formy. Pojedyncze zdarzenia syslog przez UDP lub TCP, uwierzytelnione wysyłanie HTTPS wbudowane w produkt albo całe pliki zapisywane na dysku, które trzeba przenieść. Zapora, która potrafi wysyłać tylko syslog UDP, nie stanie się nadawcą TLS dlatego, że dodano tunel; nadal będzie wysyłać niepotwierdzone datagramy, teraz w zaszyfrowanej kopercie.

Zacznij więc od inwentaryzacji nadawcy: protokół, obsługa TLS i która biblioteka TLS, czy potrafi zweryfikować certyfikat kolektora, czy potrafi przedstawić certyfikat klienta i czy bufor wysyłania przetrwa restart. Wszystko, czego urządzenie nie potrafi, musi zrobić coś innego na ścieżce, a to coś innego staje się częścią projektu.

Syslog TLS: najkrótsza droga, gdy oba końce go znają

Jeśli urządzenie obsługuje syslog przez TLS, a kolektor go terminuje, użyj tego i przestań. Protokół aplikacji chroni sam siebie, kolektor uwierzytelnia nadawcę i nie ma dodatkowego skoku, którego dostępność teraz posiadasz. Haczyk polega na tym, że „syslog TLS” obejmuje szeroki zakres implementacji, a obecne wytyczne dotyczące bezpiecznego syslogu wyszły poza listy szyfrów ze starszych poradników, i dlatego działający forwarder psuje się po aktualizacji biblioteki.

W rsyslogu już sama nazwa modułu transportowego mówi, w której epoce jesteś: lmnsd_gtls opakowuje GnuTLS, a lmnsd_ossl opakowuje OpenSSL i to dostarczają obecne pakiety 8.x. Akcja przekazywania z weryfikacją certyfikatu wygląda mniej więcej tak, a dokładne nazwy parametrów warto sprawdzić w zainstalowanej wersji:

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")

Zweryfikuj punkt końcowy, zanim zaczniesz debugować nadawcę. openssl s_client -connect collector.example:6514 -servername collector.example -CAfile /etc/pki/ca.pem -verify_return_error albo kończy uzgadnianie z prawidłowym łańcuchem, albo mówi dokładnie, która kontrola nie powiodła się. Testuj z urządzenia, nie z laptopa, bo liczy się magazyn zaufania urządzenia.

SFTP: dobry do plików, zły do strumieni

Dostawa oparta na plikach pasuje do urządzeń, które zapisują rotowane logi i nic więcej. Transfer przez SSH daje klucze hosta, klucze na konto i system plików, który możesz audytować, co jest rozsądną historią zaufania dla urządzenia, które w ogóle nie potrafi TLS. To zły wybór dla strumieni zdarzeń, gdzie „plik jest zapisywany co godzinę” oznacza, że awaria kosztuje cię ogon bieżącej godziny.

Zostaw włączoną weryfikację hosta. Wywołanie wsadowe, które ją wyłącza, by uniknąć monitu, niszczy jedyne uwierzytelnienie, jakie ma transport:

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

Przypnij klucz hosta w known_hosts konta podczas przygotowania, ogranicz konto do katalogu docelowego i preferuj podsystem internal-sftp z chroot. Zaplanuj też historię ponownego wysłania: jeśli plik zostanie wysłany ponownie po częściowym niepowodzeniu, kolektor musi odróżnić duplikat od nowego pliku, zwykle po nazwie i sumie kontrolnej, a nie po czasie przybycia.

Kiedy lokalna brama lub tunel to uczciwa odpowiedź

Niektóre urządzenia potrafią mówić tylko formatem, którego nikt nie chce ujawniać. W takim przypadku upoważniony kolektor w sieci samego urządzenia odbiera format natywny i przekazuje go dalej przez TLS. To legalny projekt, ale bądź precyzyjny co do tego, co kupuje: szyfrowanie zaczynające się na bramie nie chroni wstecznie segmentu między urządzeniem a bramą, więc ten skok nadal potrzebuje własnej granicy zaufania i kontroli dostępu.

Routowany tunel lokacji lub urządzenia to najcięższa opcja i właściwa, gdy kolektor musi zachować prywatny adres i przenosić kilka usług, nie tylko logi. Wnosi planowanie adresów, reguły dostępu, ścieżki powrotne i cykl życia punktu końcowego tunelu. Nie poprawia też protokołu wewnętrznego: syslog UDP w tunelu IPsec nadal jest usługą datagramową bez potwierdzenia dostawy.

Cokolwiek wybierzesz, trzymaj autoryzację kolektora węższą niż transport. Tożsamość tunelu należy do punktu końcowego i nie mówi nic o tym, które urządzenie niższego szczebla wytworzyło dane pole nazwy hosta w komunikacie.

Spisz umowę dostawy, zanim wyślesz

Szyfrowanie, uwierzytelnianie i retencja odpowiadają na różne pytania, a kolejka nie jest polityką retencji. Zanim pierwszy log opuści urządzenie, zdecyduj, co potwierdzenie naprawdę znaczy na tym kolektorze: odebrane na łączu, przyjęte do przetwarzania czy trwale zapisane w magazynie. To trzy różne gwarancje i tylko ostatnia przeżywa restart kolektora.

Następnie odpowiedz pisemnie na pytania operacyjne. Gdzie czekają niewysłane zdarzenia i czy ten bufor przetrwa przerwę w zasilaniu? Co się dzieje, gdy się zapełni, i kto jest powiadamiany? Jak ograniczane są ponowienia i jak identyfikowane są duplikaty? Które pole dowodzi tożsamości nadawcy, skoro skok przekazywania może przepisać nazwę hosta?

Trzymaj projekt na tyle mały, by dało się go wyjaśnić w jednym akapicie: najmniejszy obsługiwany transport, który niesie wymagane zdarzenia, plus wyraźne oświadczenie o gwarancjach, których nie daje. Jeśli odpowiedź wymaga dwóch skoków, powiedz to w runbooku i daj każdemu skokowi właściciela.