ITBlog

IT Blog w tematach różnych...

  • O blogu…
  • Edukacja
    • Moodle – stare
    • Moodle2
    • Testy
  • Firma

Model AAA – wprowadzenie

Napisane przez Igor Brzeżek on 16 października 2025
Napisane w: Bezpieczeństwo.

Contents
  1. Cyberbezpieczeństwo: Fundamenty – Model AAA
  2. Model AAA: Twój cyfrowy strażnik
  3. AAA jak Authentication (Uwierzytelnianie): „Udowodnij, kim jesteś”
  4. AAA jak Authorization (Autoryzacja): „Sprawdzam, co Ci wolno”
  5. AAA jak Accounting (Rozliczanie): „Zapisuję, co zrobiłeś”
  6. Nieporozumienia co do AAA
  7. Podsumowanie

Cyberbezpieczeństwo: Fundamenty – Model AAA

Witaj w pierwszym artykule z serii poświęconej cyberbezpieczeństwu! Zanim zanurzymy się w zaawansowane techniki obrony i ataku, musimy zbudować solidny fundament. W świecie IT tym fundamentem są modele bezpieczeństwa – sprawdzone schematy, które pomagają nam myśleć o ochronie danych w sposób ustrukturyzowany. To nie są tylko akademickie teorie, ale praktyczne narzędzia, które leżą u podstaw każdego bezpiecznego systemu.

Prawdopodobnie słyszałeś o triadzie CIA (Confidentiality, Integrity, Availability), czyli Poufności, Integralności i Dostępności. To absolutna podstawa, która definiuje cele bezpieczeństwa.

Mówi nam, co chcemy chronić. Istnieją też jej rozszerzenia, jak heksada Parkera, która dodaje Posiadanie, Użyteczność i Uwierzytelnienie. Dziś jednak skupimy się na modelu, który odpowiada na pytanie „jak?”. Poznaj model AAA – strażnika dostępu do Twoich cyfrowych zasobów.


Model AAA: Twój cyfrowy strażnik

AAA to skrót od Authentication, Authorization, Accounting (Uwierzytelnianie, Autoryzacja, Rozliczanie). To szkielet kontroli dostępu w niemal każdej sieci i systemie. Wyobraź sobie, że próbujesz wejść do strzeżonego budynku. Najpierw ochroniarz prosi Cię o dowód tożsamości (Uwierzytelnienie). Następnie, po weryfikacji, sprawdza na liście, do których pomieszczeń masz dostęp (Autoryzacja). Na koniec, w księdze gości odnotowuje, kiedy wszedłeś i wyszedłeś (Rozliczanie). Dokładnie tak samo działa model AAA.

Model AAA jest mechanizmem implementującym politykę bezpieczeństwa. Podczas gdy triada CIA definiuje ogólne cele, AAA dostarcza konkretnych kroków do ich realizacji. Uwierzytelnienie chroni poufność, autoryzacja zapewnia integralność (tylko uprawnieni mogą modyfikować dane), a rozliczanie pomaga monitorować i zapewniać dostępność oraz stanowi podstawę do analizy po incydentach. Przyjrzyjmy się każdemu z tych filarów z bliska.


AAA jak Authentication (Uwierzytelnianie): „Udowodnij, kim jesteś”

Uwierzytelnianie to proces weryfikacji tożsamości. To pierwszy i najważniejszy krok, od którego zależy całe dalsze bezpieczeństwo. System musi mieć pewność, że użytkownik, usługa czy urządzenie jest tym, za kogo się podaje. Błędne uwierzytelnienie otwiera drzwi do systemu każdemu, kto potrafi podać prawidłową nazwę użytkownika, co czyni resztę zabezpieczeń bezużyteczną. Jest to fundament, na którym opierają się autoryzacja i rozliczanie. Jeśli ten fundament jest słaby, cała konstrukcja bezpieczeństwa runie.

W praktyce opieramy się na trzech głównych czynnikach uwierzytelniania. Pierwszy to „coś, co wiesz”, czyli hasła, kody PIN czy odpowiedzi na pytania bezpieczeństwa. Drugi to „coś, co masz”, a więc fizyczny token, karta inteligentna, klucz U2F czy telefon z aplikacją generującą kody. Trzeci czynnik to „coś, czym jesteś”, czyli dane biometryczne, takie jak odcisk palca, skan siatkówki czy rozpoznawanie twarzy. Najbezpieczniejsze systemy wykorzystują Multi-Factor Authentication (MFA), łącząc co najmniej dwa z tych czynników, co drastycznie podnosi poziom bezpieczeństwa.

W systemie MikroTik RouterOS uwierzytelnianie użytkowników administracyjnych jest proste, ale kluczowe. Możemy tworzyć lokalne konta z hasłami, przypisując je do grup z określonymi uprawnieniami. Przykładowo, tworząc nowego użytkownika, musimy podać jego nazwę, przypisać go do grupy i, co najważniejsze, ustawić silne hasło. Zaniedbanie tego etapu to proszenie się o kłopoty. Poniżej przykład tworzenia użytkownika „admin-readonly” z ograniczonymi prawami, który może się zalogować i tylko odczytywać konfigurację, bez możliwości jej zmiany.

[admin@MikroTik] > user add name=admin-readonly group=read password=TwojeBardzoSilneHaslo!
[admin@MikroTik] > user print
Flags: X - disabled, * - active
 #   NAME                 GROUP                  LAST-LOGGED-IN
 0 * admin                full                   oct/16/2025 19:45:21
 1 * admin-readonly       read

W świecie urządzeń sieciowych Cisco IOS uwierzytelnianie dostępu do linii konsoli (VTY) przez Telnet lub SSH jest jednym z pierwszych kroków konfiguracyjnych. Możemy stworzyć lokalną bazę danych użytkowników bezpośrednio na urządzeniu. Każdy użytkownik ma przypisaną nazwę, hasło oraz opcjonalnie poziom uprawnień (privilege level). Konfiguracja ta jest niezbędna, aby uniemożliwić nieautoryzowany dostęp do trybu konfiguracyjnego routera czy przełącznika. Poniżej pokazano, jak stworzyć lokalnego użytkownika i wymusić jego użycie podczas logowania przez SSH.

Router> enable
Router# configure terminal
Router(config)# username auditor privilege 5 secret SuperTajneHasloCisco
Router(config)# line vty 0 4
Router(config-line)# login local
Router(config-line)# transport input ssh
Router(config-line)# exit

Systemy Linux oferują bardzo dojrzałe mechanizmy uwierzytelniania. Podstawą są pliki /etc/passwd (przechowujący informacje o kontach) i /etc/shadow (przechowujący hashe haseł), co jest kluczowe dla bezpieczeństwa. Jednak uwierzytelnianie oparte o hasła jest dziś niewystarczające. Dlatego standardem w dostępie zdalnym przez SSH jest uwierzytelnianie za pomocą kluczy kryptograficznych (publiczny i prywatny). Użytkownik przechowuje klucz prywatny na swoim komputerze, a klucz publiczny wgrywa na serwer do pliku ~/.ssh/authorized_keys. Jest to znacznie bezpieczniejsza metoda niż hasła, które mogą być słabe lub wyciec.

user@local:~$ ssh-keygen -t rsa -b 4096 -C "moj-klucz-dla-serwera"
# Generuje nową parę kluczy SSH

user@local:~$ ssh-copy-id admin@adres-serwera.com
# Kopiuje klucz publiczny na serwer, umożliwiając logowanie bez hasła

user@local:~$ ssh admin@adres-serwera.com
# Logowanie przy użyciu klucza SSH

AAA jak Authorization (Autoryzacja): „Sprawdzam, co Ci wolno”

Autoryzacja następuje tuż po pomyślnym uwierzytelnieniu. System już wie, kim jesteś, teraz musi zdecydować, co możesz zrobić. Jest to proces nadawania lub odmawiania uprawnień do konkretnych zasobów lub wykonywania określonych operacji. Autoryzacja jest kluczowa dla wdrożenia zasady minimalnych uprawnień (Principle of Least Privilege), która mówi, że użytkownik powinien mieć dostęp tylko do tych zasobów, które są mu absolutnie niezbędne do wykonywania jego zadań. Dzięki temu, nawet jeśli konto zostanie skompromitowane, szkody będą ograniczone.

Istnieje kilka modeli autoryzacji, z których najpopularniejszym jest RBAC (Role-Based Access Control). W tym modelu uprawnienia nie są przypisywane bezpośrednio do użytkowników, ale do ról (np. administrator, audytor, użytkownik standardowy), a użytkownikom przypisuje się odpowiednie role. Upraszcza to zarządzanie w dużych organizacjach. Inne modele to DAC (Discretionary Access Control), gdzie właściciel zasobu decyduje o prawach dostępu (standard w systemach Linux/Windows), oraz MAC (Mandatory Access Control), gdzie system operacyjny egzekwuje politykę bezpieczeństwa opartą na etykietach (stosowany w środowiskach o najwyższych wymaganiach bezpieczeństwa, np. wojskowych).

W RouterOS autoryzacja jest realizowana poprzez grupy użytkowników. Domyślnie istnieją trzy grupy: full (pełny dostęp do zapisu i odczytu), read (tylko odczyt konfiguracji) i write (odczyt i zapis, ale bez niektórych wrażliwych uprawnień, jak zarządzanie użytkownikami). Możemy również tworzyć własne, niestandardowe grupy, precyzyjnie definiując, do których polityk bezpieczeństwa (np. ftp, ssh, winbox, api) i komend dany użytkownik będzie miał dostęp. Daje to ogromną elastyczność w zarządzaniu uprawnieniami administracyjnymi na urządzeniu.

[admin@MikroTik] > user group add name=audytor policy=ssh,readonly,test
[admin@MikroTik] > user add name=jan.kowalski group=audytor password=InneSilneHaslo123
# Tworzymy grupę "audytor" z określonymi uprawnieniami i przypisujemy do niej nowego użytkownika.

Cisco IOS wykorzystuje system poziomów uprawnień (privilege levels) od 0 do 15. Poziom 1 to domyślny, bardzo ograniczony tryb użytkownika, a poziom 15 to pełny dostęp administracyjny (odpowiednik trybu enable). Możemy tworzyć użytkowników i przypisywać im dowolny poziom pośredni, a następnie precyzyjnie określać, które komendy są dostępne na danym poziomie. Pozwala to na stworzenie kont z bardzo granularnymi uprawnieniami, na przykład dla personelu helpdesku, który potrzebuje dostępu tylko do komend diagnostycznych, takich jak ping czy show interface.

Router(config)# privilege exec level 5 show ip interface brief
Router(config)# privilege exec level 5 show version
Router(config)# username helpdesk privilege 5 secret HasloDlaHelpdesku
# Użytkownik "helpdesk" po zalogowaniu będzie na poziomie 5 i będzie mógł wykonać tylko te dwie komendy.

Autoryzacja w systemach Linux jest nierozerwalnie związana z modelem uprawnień do plików i katalogów. Każdy plik ma właściciela, grupę oraz zdefiniowane prawa dostępu (odczyt, zapis, wykonanie) dla właściciela, grupy i pozostałych użytkowników (model DAC). Narzędzia takie jak chmod i chown pozwalają na precyzyjną kontrolę. Jednak dla zadań administracyjnych kluczowym mechanizmem jest sudo. Pozwala ono zwykłemu użytkownikowi na wykonanie określonych poleceń z uprawnieniami roota, bez konieczności udostępniania mu hasła do konta superużytkownika, co jest fundamentalną zasadą bezpieczeństwa.

root@server:~# visudo
# Edytuje plik /etc/sudoers
# Dodajemy poniższą linię, aby pozwolić użytkownikowi 'admin' restartować usługę apache
admin ALL=(ALL) /usr/sbin/service apache2 restart

admin@server:~$ sudo /usr/sbin/service apache2 restart
[sudo] password for admin: ********
# Użytkownik wykonuje polecenie po podaniu swojego hasła.

AAA jak Accounting (Rozliczanie): „Zapisuję, co zrobiłeś”

Rozliczanie (często nazywane też Auditingiem) to ostatni, ale nie mniej ważny element modelu AAA. Polega na systematycznym zbieraniu i rejestrowaniu informacji o działaniach użytkowników i zdarzeniach w systemie. System śledzi, kto, co, kiedy i skąd robił. Te informacje, zwane logami, są bezcenne. Służą do monitorowania bezpieczeństwa w czasie rzeczywistym, analizy powłamaniowej (forensics), wykrywania anomalii, a także do celów rozliczeniowych (np. naliczania opłat za zużyte zasoby) czy rozwiązywania problemów technicznych.

Efektywne rozliczanie wymaga centralizacji logów. Zbieranie logów z dziesiątek czy setek urządzeń w jednym, bezpiecznym miejscu (np. na serwerze Syslog lub w systemie SIEM) jest standardem. Umożliwia to korelowanie zdarzeń z różnych systemów, co pozwala wykryć złożone ataki, które na pojedynczym urządzeniu mogłyby wyglądać jak normalna aktywność. Kluczowe jest również zapewnienie integralności logów – muszą być one chronione przed modyfikacją, aby mogły stanowić wiarygodny materiał dowodowy.

W RouterOS mamy rozbudowany system logowania. Możemy logować niemal każde zdarzenie – od prób logowania, przez zmiany w konfiguracji, po zdarzenia firewalla. Domyślnie logi są przechowywane w pamięci urządzenia, co jest nietrwałe. Dlatego kluczową czynnością jest skonfigurowanie wysyłania logów na zewnętrzny serwer Syslog. Pozwala to na ich długoterminowe przechowywanie i analizę, niezależnie od stanu samego routera. Poniżej przykład konfiguracji wysyłania wszystkich logów na zdalny serwer.

[admin@MikroTik] > system logging action add name=remote-syslog target=remote remote=192.168.1.100
[admin@MikroTik] > system logging add topics=info,!debug action=remote-syslog
[admin@MikroTik] > system logging add topics=critical action=remote-syslog
# Konfiguruje wysyłanie logów oznaczonych jako 'info' i 'critical' na serwer Syslog 192.168.1.100

Urządzenia Cisco IOS również posiadają zaawansowane możliwości audytu. Logowanie można konfigurować na różnych poziomach szczegółowości (od 0 – emergencies do 7 – debugging). Podobnie jak w RouterOS, standardem jest wysyłanie logów na serwer Syslog. Cisco pozwala również na logowanie wykonanych poleceń, co jest niezwykle przydatne do audytu zmian wprowadzanych przez administratorów. Można skonfigurować system tak, aby każda komenda wpisana w trybie konfiguracyjnym była rejestrowana wraz z informacją o użytkowniku i czasie jej wykonania.

Router(config)# logging host 192.168.1.100
Router(config)# logging trap informational
Router(config)# archive
Router(config-archive)# log config
Router(config-archive-log-cfg)# logging enable
Router(config-archive-log-cfg)# notify syslog
# Ta konfiguracja włącza wysyłanie logów na serwer Syslog i dodatkowo loguje każdą zmianę w konfiguracji.

W systemach Linux za zbieranie logów odpowiadają demony takie jak rsyslog lub systemd-journald. Logi dotyczące uwierzytelniania (próby logowania, sesje sudo) są najczęściej zapisywane w /var/log/auth.log (w systemach bazujących na Debianie) lub /var/log/secure (w systemach Red Hat). Nowoczesne systemy z systemd używają binarnego formatu dziennika, do którego dostęp uzyskujemy za pomocą polecenia journalctl. Dodatkowo, narzędzia takie jak last, who czy w pozwalają w prosty sposób sprawdzić historię i aktualny stan zalogowanych użytkowników, co jest podstawą każdego audytu bezpieczeństwa.

user@server:~$ journalctl -u ssh.service -f
# Wyświetla na żywo logi z usługi SSH, pokazując próby logowania.

user@server:~$ grep "Failed password" /var/log/auth.log
# Przeszukuje plik logów w poszukiwaniu nieudanych prób logowania.

user@server:~$ last
# Wyświetla historię ostatnich logowań do systemu.
admin    pts/0        192.168.1.50   Thu Oct 16 18:30   still logged in
root     tty1                        Thu Oct 16 12:15 - 13:00  (00:45)

Nieporozumienia co do AAA

Często pojawiają się pomyłki typu: „Właśnie się autoryzowałem do systemu”, „Błędne hasło, nie mogę się autoryzować”. To błąd ponieważ najpierw jest autentykacja (login, hasło i inne metody) a potem możemy być lub nie autoryzowani do zasobów. Pamiętać też należy, że model AAA nie musi odnosić się tylko do IT. Można przejść autentykację na bramie u ciecia, a potem być autoryzowany aby wejść np. do serwerowni czy pomieszczenia technicznego.


Podsumowanie

Model AAA to nie tylko teoria, to krwiobieg operacyjnego bezpieczeństwa IT. Uwierzytelnianie, Autoryzacja i Rozliczanie tworzą logiczny i solidny proces, który pozwala kontrolować dostęp do zasobów w sposób świadomy i mierzalny. Zrozumienie i poprawne wdrożenie tych trzech filarów jest absolutnie kluczowe dla budowy bezpiecznej infrastruktury.

W kolejnych artykułach z tej serii przyjrzymy się każdemu z tych elementów znacznie głębiej. Omówimy zaawansowane protokoły takie jak RADIUS i TACACS+, zanurzymy się w świat zarządzania tożsamością i federacji, a także przeanalizujemy narzędzia do centralnego zbierania i analizy logów. To dopiero początek naszej podróży po świecie cyberbezpieczeństwa!

Nawigacja

← Automatyczne pobieranie ścieżek audio z YouTube
  • Szukaj

  • Kategorie

    • IT ogólnie (72)
      • Bezpieczeństwo (10)
      • CCTV (3)
      • Hardware (1)
      • Sieci (9)
        • MikroTik (7)
      • Software (40)
        • Programowanie (2)
        • Systemy operacyjne (15)
          • Linux Debian (14)
        • Windows (7)
      • WiFi (2)
      • Wirtualizacja (26)
    • Różne (1)
  • Ostatnie wpisy

    • Model AAA – wprowadzenie
    • Automatyczne pobieranie ścieżek audio z YouTube
    • Przekierowanie zapytań DNS do lokalnego resolvera
    • Szyfrowanie ruchu DNS za pomocą RouterOS
    • Analiza ruchu DNS na systemie RouterOS
  • Strona odwiedzona

    od 11.01.2013

  • Doskonała platforma e-learningowa Uzyskaj certyfikat IT

Proudly powered by WordPress Theme: Parament by Automattic.
7ads6x98y