Co powinien zapewniać system logowania?

Zgodnie z przedstawionymi podstawowymi zasadami funkcjonowania SYSLOG, sprawa wygląda dość prosto. Klient generuje informacje, ubiera w pakiet uzupełniając o odpowiednie parametry i nagłówki, aby następnie wysłać całość do serwera. Serwer na podstawie parametrów zawartych w pakiecie, odpowiednio klasyfikuje informacje i zapisuje na lokalnych zasobach. W realnych wdrożeniach tak prosta konfiguracja, występuje wyłącznie w stosunkowo niewielkich wdrożeniach. Przy dużym natłoku informacji oraz dodatkowych wymaganiach dotyczących wydajności i bezpieczeństwa konieczna będzie analiza całego procesu przepływu informacji oraz samego serwera SYSLOG.

System logowania należy postrzegać w całej relacji, od klienta poprzez kolektory do serwera. Efektywne logowanie musi dostarczać szczegółowych informacji niezbędnych do analizy problemów z aplikacjami, siecią czy bezpieczeństwem. Oznacza to także, że w powyższych danych mogą znaleźć się także dane wrażliwe, takie jak nazwy użytkowników, adresy IP czy dane aplikacji. W celu zabezpieczenia wrażliwych danych, systemy logujące muszą wspierać szyfrowanie danych w sieci pomiędzy klientem a centralnym serwerem logującym. Najczęściej wykorzystywaną metodą szyfrowania będzie bezpieczna komunikacja SSL/TLS TCP. Technologia SSL/TLS bazuje na otwartych standardach i jest jedną z popularniejszych metod szyfrowanej transmisji. Do zabezpieczenia danych przed niepowołanym dostępem, rozwiązanie logowania ruchu powinno umożliwiać obustronne uwierzytelnianie, zarówno klienta, jak i serwera. TLS dostarcza metod do uwierzytelniania punktów końcowych. Można wykorzystać do tego celu standardowe certyfikaty X509.

W celu zapobiegania stratom informacji najlepszym rozwiązaniem jest wykorzystanie protokołu TCP do przesyłania informacji. W celu ograniczenia utraty danych konieczne okaże się zapewnienie buforów dyskowych. Gdy połączenie sieciowe ulegnie uszkodzeniu, logi systemowe są zapisywane do bufora systemu klienta. Gdy połączenie sieciowe zostanie odzyskane, logi są przywracane z bufora i wysyłane na serwer SYSLOG. Jeżeli przesyłamy logi z serwerów aplikacji, zazwyczaj nie będzie problemem ustanowienie bezpiecznego połączenia do serwera logującego. Gorzej sprawa wygląda w przypadku urządzeń sprzętowych, które nie zawsze pozwolą na ustanowienie bezpiecznego połączenia. W takim przypadku rozsądne wydaje się wykorzystanie serwera pośredniczącego (RELAY), który zagreguje zdarzenia z wewnętrznej infrastruktury, a następnie prześle bezpiecznym połączeniem do serwera centralnego. Serwer pośredniczący realizuje konsolidację logów z określonej lokalizacji, a następnie przekazuje dane poprzez WAN lub internet. Wykrywanie naruszeń bezpieczeństwa często oznacza konieczność korelacji zdarzeń systemowych pochodzących nawet z kilku maszyn. Nie ma możliwości analizy takich czynników, w momencie gdy dzienniki zdarzeń są uszkodzone lub niekompletne. System logowania powinien zapewniać nienaruszalność dzienników zdarzeń w procesie przetwarzania i przechowywania. Podstawą bezpieczeństwa logowanego ruchu jest właśnie zapewnienie jego integralności. Musimy mieć pewność, że dane wysłane od klienta są tymi samymi, które zapisane zostają na serwerze logującym. W większości wdrożeń konieczne więc będzie wykorzystanie transmisji TCP oraz wykorzystanie sumy kontrolnej pakietu. Warto zapoznać się także z mechanizmem "Syslog-Sign Protocol", który dodaje do wiadomości podpis oraz certyfikat, w celu zapewnienia autentyczności.

Niezwykle istotną sprawą jest sposób przechowywania danych na serwerze SYSLOG. Tradycyjną formą przechowywania zdarzeń są pliki tekstowe. Alternatywą dla tego rozwiązania jest wspierane przez część aplikacji SYSLOG połączenie do serwera baz danych, przykładowo MySQL, PostreSQL czy Oracle. Każde z rozwiązań posiada wady i zalety, a wybór definiuje zakres działania i przeznaczenie systemu. Dodatkowo w profesjonalnych rozwiązaniach logujących, koniecznością jest wsparcie mechanizmu odzyskiwania danych po awarii i utracie danych. System po stronie serwerów logujących powinien wspierać redundancję.