ProtLog

1. System ProtLog

Bezpieczeństwo zapewniane przez system ProtLog

Unikalna konstrukcja systemu ProtLog umożliwia bezpieczne logowanie zdarzeń, zachowując materiał kryptograficzny umożliwiający weryfikację integralności zapisanego dziennika. ProtLog wykorzystuje mechanizm podpisu elektronicznego, znaczniki czasu oraz kod uwierzytelniania wiadomości do zapewnienia, że każda modyfikacja już zalogowanych danych może zostać wykryta i zidentyfikowana.

Prawidłowo wdrożony system ProtLog umożliwia:

• wykrycie modyfikacji jakiegokolwiek zalogowanego już zdarzenia/zdarzeń
• wykrycie usunięcia zdarzenia/zdarzeń, w tym usunięcia ostatnich zalogowanych zapisów
• wykrycie “ręcznego” dodania zdarzenia/zdarzeń do bazy z pominięciem mechanizmów ProtLog
• wysoką odporność na sabotaż (np. odcięcie zasilania, zabicie serwera ProtLog)
• możliwość weryfikacji spójności przez upoważnionego inspektora bezpieczeństwa teleinformatycznego posiadającego własny klucz prywatny
• wykorzystanie znaczników czasu aby zagwarantować poprawność logowanych dat

Większość wymienionych wcześniej cech jest zachowana nawet, jeśli nie zakłada się, że serwer, na którym działa ProtLog jest odporny na włamania. Ściśle rzecz biorąc, ProtLog gwarantuje spójność danych zalogowanych przez kompromitacją serwera, na którym działa. Włamywacz dysponujący bardzo wysokimi kwalifikacjami jest w stanie po przejęciu pełnej kontroli nad serwerem dodawać lub modyfikować NOWE zdarzenia w sposób niezauważony. Nie może jednak modyfikować ani usuwać zdarzeń zalogowanych przed kompromitacją serwera. Należy podkreślić, że opisany powyżej atak wymaga specjalistycznej wiedzy i uzyskania uprawnień administratora systemu (z możliwością bezpośredniego czytania pamięci procesów).

1.2. Weryfikacja spójności logów

System ProtLog zawiera narzędzie służące inspektorowi bezpieczeństwa teleinformatycznego do weryfikacji spójności zalogowanych zdarzeń. Do działania, aplikacja wymaga karty mikroprocesorowej zawierającej klucz prywatny inspektora. Po podaniu PINu, aplikacja łączy się z bazą danych ProtLog i dokonuje weryfikacji spójności. Jeśli zostanie wykryte naruszenie spójności, aplikacja informuje inspektora i podaje identyfikator ostatniego zdarzenia, które nie zostało naruszone.

Należy podkreślić, że bezpieczeństwo karty inspektora jest kluczowym elementem bezpieczeństwa systemu. Jeśli dostanie się ona w niepowołane ręce, bezpieczeństwo ProtLog będzie poważnie naruszone.

1.3. Interfejs ProtLog

System ProtLog udostępnia interfejs, umożliwiający zewnętrznym aplikacjom przesyłanie do niego zdarzeń. Protokół oparty jest na TCP/IP; poufność i integralność zapewniana jest przez użycie protokołu TLS. Dzięki wykorzystaniu dwustronnego uwierzytelniania klienta i serwera weryfikowana jest tożsamość obu stron. Możliwe jest również wyłączenie mechanizmów uwierzytelniania; to rozwiązanie zostanie zastosowane w CEPiK ze względu na fizyczną kontrolę dostępu do serwerów.

Zdarzenia opisywane są w formacie XML. Struktura wiadomości nie jest narzucona z góry; postać prawidłowego komunikatu zależy od konfiguracji serwera ProtLog, określonej w czasie wdrożenia. Maksymalny rozmiar komunikatu XML to 232 bajtów.

ProtLog może obsługiwać dowolną ilość źródeł; w ramach każdego źródła można definiować różne rodzaje zdarzeń (np. zalogowanie/wylogowanie użytkownika, dokonanie transakcji). Każde zdarzenie może mieć inną postać (zakres informacyjny).

Wraz z ProtLog dostarczana jest biblioteka kliencka, umożliwiająca aplikacjom logowanie w sposób przezroczysty. Biblioteka dba o właściwe uwierzytelnianie oraz zawiera mechanizmy buforowania zdarzeń – wykorzystywane, jeśli serwer ProtLog jest czasowo niedostępny.

1.4. Konfiguracja źródeł

Na potrzeby niniejszego dokumentu przyjmijmy, że ProtLog jest wykorzystywany do logowania zdarzeń zachodzących w systemie bankowym. Będziemy logować jeden rodzaj zdarzeń: fakt usunięcia jednego lub wielu kont z systemu. Interesuje nas informacja o dacie zdarzenia, użytkowniku, który dokonał operacji, stacji, na której ją wykonano oraz lista usuniętych kont.

Aby skonfigurować źródło ProtLog, należy, administrator określa:
1.zasady uwierzytelniania aplikacji klienckiej – poprzez zdefiniowanie punktów zaufania i określenie wymagań na pola certyfikatu klienta. Certyfikat jest sprawdzany podczas nawiązywania przez aplikację połączenia z serwerem ProtLog. W przykładowym systemie system bankowy (klient ProtLog) zostałby wyposażony w certyfikat i klucz prywatny umożliwiający logowanie w ProtLog, a serwer skonfigurowany zostałby tak, aby umożliwiać logowanie wyłącznie temu klientowi.

2.strukturę bazy danych, w której przechowywane będą zdarzenia. Struktura musi zostać zaprojektowana tak, aby odpowiadała zakresowi informacyjnemu logowanych zdarzeń. ProtLog wymaga jedynie, aby każdy wiersz w głównej tabeli zdarzeń posiadał unikalny identyfikator (jest od wykorzystywany przy generowaniu podpisów zdarzeń). W przykładowym systemie mogłyby zostać stworzone dwie tabele – główna ZDARZENIA, zawierająca kolumny identyfikator, data, użytkownik, stacja oraz dodatkowa KONTA, przechowująca numery kont (usuniętych w poszczególnych operacjach (kolumny identyfikator-zdarzenia i numer-konta).

3.relacje między elementami zdarzeń – w najprostszym przypadku logowane zdarzenia mają strukturę płaską i mogą być zapisywane w jednej tabeli. Jeśli jednak zdarzenie zawiera np. zbiór obiektów (np. zdarzenie polegające na usunięciu kont z systemu bankowego), możliwe jest określenie odpowiedniej relacji. ProtLog wykorzystuje tę informację przy zapisywaniu zdarzeń w bazie.

4.reguły mapowania elementów zdarzenia na kolumny bazy danych. W przykładowym systemie należy określić, w jaki sposób zapisywać dane ze zdarzenia w tabelach ZDARZENIA i KONTA.

Dodatkowo, na potrzeby systemu ProtLog należy dodać dodatkową tabelę, w której przechowywany jest materiał kryptograficzny. Jej struktura jest ściśle określona i wykorzystywana wyłącznie przez serwer ProtLog i aplikację inspektora bezpieczeństwa.

1.5. Współpraca z bazą danych

Architektura ProtLog umożliwia korzystanie z różnych sposobów zapisywania zdarzeń – od płaskich plików tekstowych aż po złożone bazy danych. Obecnie dostępna wersja współpracuje z bazami Oracle (od wersji 9 wzwyż), PostgreSQL, mySQL oraz SQLite.

Interfejsy do poszczególnych mediów przechowywania danych dystrybuowane są w postaci tzw. wtyczek. Taka architektura umożliwia ukrycie specyficznych cech – np. dialektów SQL – w sposób przezroczysty dla administratora. Definiowanie źródeł ProtLog nie wymaga w ogóle znajomości SQL, a jedynie struktury wykorzystywanej bazy danych.

1.6. Niezawodność

ProtLog jest systemem przewidzianym do zastosowań mission-critical. Poszczególne komponenty systemu zostały skonstruowane tak, aby zapewniać maksymalny poziom dostępności oraz wspierać istniejące technologie podwyższania niezawodności.

Serwer ProtLog zawiera mechanizmy umożliwiające mu działanie w klastrze; migracja między węzłami klastra nie zaburza spójności logowanych zdarzeń.
Biblioteka klienta ProtLog zawiera mechanizmy monitorowania dostępności serwera. Jeśli połączenie zostanie zerwane, biblioteka automatycznie buforuje zdarzenia (aż do zadanego poziomu), okresowo próbując nawiązać połączenie ponownie.