Model AAA – Rozliczanie (część 1)

Napisane przez Igor Brzeżek on 23 października 2025
Napisane w: Model AAA.

Contents
  1. AAA: Rozliczanie (Accounting)
  2. Dlaczego Rozliczanie jest tak kluczowe? Główne cele
  3. Anatomia logu: Co tak naprawdę zapisujemy?
  4. Wyzwania i dobre praktyki: Syslog, NTP i Centralizacja
  5. Problem: Logi lokalne są bezużyteczne w razie włamania
  6. Rozwiązanie: Centralny serwer logów (Syslog)
  7. Problem: Niespójny czas uniemożliwia korelację zdarzeń
  8. Rozwiązanie: Synchronizacja czasu (NTP)
  9. Koncepcje Rozliczania w Cisco, Linux i RouterOS
  10. Podsumowanie

AAA: Rozliczanie (Accounting)

Dotarliśmy do ostatniego etapu naszej podróży po fundamentalnym modelu bezpieczeństwa AAA. W poprzednich częściach nauczyliśmy się weryfikować tożsamość za pomocą Uwierzytelniania („Kim jesteś?”) oraz nadawać uprawnienia dzięki Autoryzacji („Co wolno Ci zrobić?”). Ale co, jeśli coś pójdzie nie tak? Skąd będziemy wiedzieć, kto i kiedy dokonał krytycznej zmiany w konfiguracji firewalla tuż przed awarią? Jak udowodnić audytorowi, że nasze polityki bezpieczeństwa działają? Odpowiedzi na te pytania dostarcza trzeci filar: Rozliczanie (Accounting).

Rozliczanie, często nazywane również Audytem (Auditing), odpowiada na kluczowe pytanie: „Co zrobiłeś?”. To proces systematycznego zbierania, rejestrowania i analizowania zdarzeń w systemie. Jeśli Uwierzytelnianie jest strażnikiem przy bramie, a Autoryzacja systemem kart dostępu, to Rozliczanie jest wszechobecną siecią kamer przemysłowych i skrupulatnie prowadzoną księgą gości. Bez niego działamy po omacku, niezdolni do wyciągania wniosków z przeszłości i reagowania na incydenty.

Dlaczego Rozliczanie jest tak kluczowe? Główne cele

Skuteczny system rozliczania to znacznie więcej niż tylko zbieranie logów „na wszelki wypadek”. To aktywne narzędzie, które służy wielu krytycznym celom w każdej organizacji:

  • Analiza powłamaniowa (Forensics): To podstawowy cel. Gdy dojdzie do incydentu bezpieczeństwa, logi są cyfrowymi śladami, które pozwalają odtworzyć przebieg ataku: jak włamywacz dostał się do systemu, jakie komendy wykonał, jakie dane wykradł i jakie ślady po sobie zostawił.
  • Wykrywanie incydentów: Analiza logów w czasie rzeczywistym przez systemy takie jak SIEM (Security Information and Event Management) pozwala na wykrywanie anomalii i wzorców wskazujących na trwający atak, np. setki nieudanych prób logowania z jednego adresu IP.
  • Zgodność z regulacjami (Compliance): Wiele regulacji prawnych i standardów branżowych (np. RODO/GDPR, PCI-DSS, ISO 27001) wprost wymaga posiadania i przechowywania szczegółowych dzienników zdarzeń jako dowodu na stosowanie odpowiednich kontroli bezpieczeństwa.
  • Rozwiązywanie problemów (Troubleshooting): Kiedy usługa przestaje działać, często to właśnie logi pozwalają zdiagnozować problem. Pokazują błędy aplikacji, zmiany w konfiguracji czy problemy sprzętowe, które doprowadziły do awarii.
  • Planowanie i rozliczanie zasobów: W środowiskach komercyjnych logi pozwalają śledzić zużycie zasobów (czasu CPU, transferu danych, liczby zapytań API) w celu naliczania opłat klientom lub planowania rozbudowy infrastruktury.
+---------------------+
| Zdarzenie w systemie|
| (np. login admina)  |
+---------------------+
           |
           V
+---------------------+      +-----------------------------+
|    Mechanizm        |      |      Analiza i Reakcja      |
|    logowania        |      |-----------------------------|
| (Accounting)        |----->| - Wykrywanie włamań (SIEM)  |
+---------------------+      | - Analiza po fakcie         |
                             | - Raporty dla audytora      |
                             | - Diagnoza awarii           |
                             +-----------------------------+

Anatomia logu: Co tak naprawdę zapisujemy?

Aby logi były użyteczne, muszą zawierać odpowiedni zestaw informacji. Dobry wpis w dzienniku zdarzeń powinien odpowiadać na kilka podstawowych pytań, które można podsumować jako „5W” (lub więcej):

  • Kto (Who): Identyfikator podmiotu, który wykonał akcję. Najczęściej jest to nazwa użytkownika (`admin`, `jkowalski`), ale może to być też nazwa procesu systemowego (`cron`) lub usługa.
  • Co (What): Opis wykonanej czynności. Może to być nazwa wykonanego polecenia (`configure terminal`), typ zdarzenia (`successful login`, `failed password`) lub zasób, do którego uzyskano dostęp (`/etc/shadow`).
  • Kiedy (When): Precyzyjny znacznik czasu (timestamp) wystąpienia zdarzenia. Bez tego logi są niemal bezużyteczne.
  • Gdzie (Where): Kontekst źródłowy zdarzenia. Zazwyczaj jest to adres IP, z którego przyszło połączenie, nazwa hosta, czy terminal, na którym pracował użytkownik (`tty1`, `pts/0`).
  • Jak (How): Wynik operacji – czy zakończyła się sukcesem, czy porażką. Jest to kluczowe dla wykrywania np. prób odgadnięcia hasła.

Przykład wpisu z logu SSH w systemie Linux:

Oct 16 21:15:30 server01 sshd[2150]: Failed password for invalid user hacker from 203.0.113.55 port 48212 ssh2
  • Kiedy: Oct 16 21:15:30
  • Gdzie (Host logujący): server01
  • Kto (Proces): sshd[2150]
  • Co: Nieudana próba logowania hasłem
  • Kto (Próbujący): Nieistniejący użytkownik ‚hacker’
  • Gdzie (Źródło): IP 203.0.113.55, port 48212
  • Jak: Porażka

Wyzwania i dobre praktyki: Syslog, NTP i Centralizacja

Samo włączenie logowania na urządzeniu to dopiero początek. Aby system audytu był skuteczny i odporny na manipulacje, musimy sprostać kilku wyzwaniom.

Problem: Logi lokalne są bezużyteczne w razie włamania

Pierwszą rzeczą, jaką zrobi doświadczony atakujący po uzyskaniu dostępu do systemu, jest zatarcie swoich śladów. Oznacza to usunięcie lub zmodyfikowanie lokalnych plików z logami. Co więcej, jeśli urządzenie ulegnie awarii, wszystkie logi przechowywane w jego pamięci RAM przepadną na zawsze.

Rozwiązanie: Centralny serwer logów (Syslog)

Standardowym rozwiązaniem tego problemu jest centralizacja logów. Wszystkie urządzenia w sieci (routery, przełączniki, serwery, firewalle) są konfigurowane tak, aby wysyłały kopie swoich logów w czasie rzeczywistym na jeden, dedykowany i specjalnie zabezpieczony serwer. Najczęściej używanym do tego protokołem jest Syslog.

+--------------+
| Serwer Linux | --
+--------------+   \
                    \
+--------------+    /`
| Router Cisco | --+----[ Logi Syslog (UDP/514) ]---> +---------------------+
+--------------+   \                                  | Centralny Serwer    |
                    /`                                | Logów (Syslog/SIEM) |
+--------------+   /                                  | (Bezpieczna Strefa) |
| MikroTik     | --                                   +---------------------+
+--------------+

Centralny serwer logów jest maszyną o zaostrzonych rygorach bezpieczeństwa. Dostęp do niego jest ściśle ograniczony, a same logi są często archiwizowane w niezmienialnej formie (np. na nośnikach WORM – Write Once Read Many), aby zapewnić ich integralność na potrzeby dowodowe.

Problem: Niespójny czas uniemożliwia korelację zdarzeń

Wyobraź sobie, że analizujesz atak, który przeszedł przez firewall, serwer WWW i bazę danych. Log z firewalla mówi, że podejrzany ruch miał miejsce o 21:05:10. Log z serwera WWW pokazuje włamanie o 21:07:30, a z bazy danych wyciek danych o 21:04:00. Chronologia jest zaburzona, bo zegary na urządzeniach nie były zsynchronizowane. Analiza staje się koszmarem.

Rozwiązanie: Synchronizacja czasu (NTP)

Absolutną koniecznością w każdej sieci jest wdrożenie protokołu NTP (Network Time Protocol). Wszystkie urządzenia muszą synchronizować swoje zegary z jednym, wiarygodnym źródłem czasu. Dzięki temu znaczniki czasu we wszystkich logach w całej infrastrukturze są spójne, co pozwala na precyzyjną korelację zdarzeń minuta po minucie, sekunda po sekundzie.

+---------------------+
| Serwer Czasu NTP    |
| (np. z puli publicznej)|
+---------------------+
      ^     ^     ^
      |     |     | [Synchronizacja czasu]
      |     |     |
+-----+-----+-----+-----+
| Firewall    | Serwer WWW    | Baza Danych |
+-------------+---------------+-------------+
      |             |               |
      V             V               V
    [Log z poprawnym czasem] [Log z ... ] [Log z ... ]

Koncepcje Rozliczania w Cisco, Linux i RouterOS

Chociaż cel jest ten sam, każde środowisko ma swoją specyfikę logowania:

  • W Cisco IOS kluczowe jest operowanie na poziomach ważności (severity levels 0-7), które pozwalają filtrować „szum informacyjny” i logować tylko to, co istotne. Unikalną cechą jest możliwość integracji z serwerami TACACS+, które potrafią logować każdą pojedynczą komendę wpisaną przez administratora.
  • W Linux mamy do czynienia z tradycyjnymi plikami tekstowymi w /var/log oraz nowszym, ustrukturyzowanym dziennikiem systemd-journald. Dodatkowo potężne narzędzie auditd pozwala na tworzenie bardzo szczegółowych reguł audytu, np. „loguj każdą próbę odczytu pliku /etc/secret.conf”.
  • W RouterOS logowanie opiera się na elastycznym systemie tematów (topics) i akcji (actions). Możemy bardzo granularnie zdecydować, że np. logi z firewalla (temat) mają być wysyłane na zdalny serwer (akcja), a błędy krytyczne (inny temat) zapisywane lokalnie na dysku (inna akcja).

Podsumowanie

Rozliczanie (Accounting) to cichy bohater modelu AAA. Może nie blokuje ataków w czasie rzeczywistym jak Uwierzytelnianie i Autoryzacja, ale jest naszą cyfrową pamięcią i systemem wczesnego ostrzegania. Zapewnia odpowiedzialność (wiemy, kto co zrobił), widoczność (rozumiemy, co się dzieje w naszej sieci) i zdolność do reakcji (mamy dane, by przeanalizować incydent). Prawidłowo wdrożony system audytu, oparty na centralizacji logów i synchronizacji czasu, jest oznaką dojrzałości każdej organizacji dbającej o bezpieczeństwo.

W ostatnim artykule z tej serii przejdziemy do praktyki: skonfigurujemy centralny serwer Syslog na Linuksie i nauczymy nasze urządzenia Cisco i MikroTik, jak posłusznie raportować mu o każdym swoim kroku.