- AAA: Autoryzacja w Praktyce – Cisco, Linux, RouterOS
- Cisco IOS: Hierarchia władzy, czyli Privilege Levels
- Przykład praktyczny: Tworzenie roli „Helpdesk” i „Junior Admin”
- Krok 1: Definiowanie uprawnień dla roli Helpdesk (Poziom 5)
- Krok 2: Definiowanie uprawnień dla roli Junior Admin (Poziom 10)
- Krok 3: Tworzenie użytkowników i przypisywanie ich do ról (poziomów)
- Krok 4: Weryfikacja
- Linux: Potęga uprawnień DAC i elastyczność `sudo`
- Część A: Model DAC w praktyce – `chmod` i `chown`
- Część B: Model RBAC z `sudo` – finezyjna kontrola administracyjna
- Przykład praktyczny: Rola „Operator Bazy Danych” i „Webmaster”
- Weryfikacja
- MikroTik RouterOS: Zarządzanie przez Grupy Użytkowników
- Przykład praktyczny: Rola „Monitoring” i „Guest WiFi Admin”
- Krok 1: Tworzenie grupy i użytkownika „Monitoring”
- Krok 2: Tworzenie grupy i użytkownika „Guest WiFi Admin”
- Weryfikacja
- Podsumowanie
AAA: Autoryzacja w Praktyce – Cisco, Linux, RouterOS
W poprzednim artykule zbudowaliśmy solidny fundament teoretyczny pod pojęcie Autoryzacji. Zrozumieliśmy jej kluczową rolę w egzekwowaniu Zasady Minimalnych Uprawnień i poznaliśmy najważniejsze modele kontroli dostępu, takie jak DAC, MAC i RBAC. Teraz nadszedł czas, aby porzucić teorię i ubrudzić sobie ręce w konsoli. Zobaczymy, jak te koncepcje ożywają w trzech różnych, niezwykle popularnych środowiskach: na urządzeniach sieciowych Cisco, w sercu data center – systemie Linux, oraz na wszechstronnych routerach MikroTik z RouterOS.
Ten artykuł to czysta praktyka. Krok po kroku, na konkretnych przykładach, stworzymy role użytkowników z precyzyjnie zdefiniowanymi uprawnieniami. Zbudujemy hierarchię dostępu dla personelu IT, od techników pierwszej linii po administratorów baz danych. Celem jest pokazanie, jak za pomocą wbudowanych narzędzi skutecznie odpowiedzieć na pytanie: „Co ten użytkownik może zrobić w moim systemie?”.
Cisco IOS: Hierarchia władzy, czyli Privilege Levels
System operacyjny Cisco IOS wykorzystuje prostą, ale bardzo skuteczną implementację modelu RBAC (Role-Based Access Control). Rolą jest tutaj poziom uprawnień (Privilege Level), czyli liczba od 0 do 15. Każda komenda w systemie IOS ma przypisany minimalny poziom uprawnień wymagany do jej wykonania. Daje to administratorom potężne narzędzie do tworzenia wielopoziomowej hierarchii dostępu.
Krótkie przypomnienie poziomów:
- Poziom 0: Minimalny, zawiera kilka podstawowych poleceń jak `logout` czy `help`.
- Poziom 1 (User EXEC Mode): Domyślny poziom po zalogowaniu. Umożliwia podstawową diagnostykę (`ping`, `traceroute`, niektóre polecenia `show`).
- Poziomy 2-14: Poziomy do dowolnego zdefiniowania przez administratora. To tutaj tworzymy niestandardowe role.
- Poziom 15 (Privileged EXEC Mode): Absolutny superużytkownik, „root”. Dostęp do wszystkiego, łącznie z trybem konfiguracji globalnej.
Poziom 15: Super-Admin (pełna kontrola, tryb 'enable') ^ | Poziomy 2-14: Role niestandardowe (np. Junior Admin, Helpdesk) ^ | Poziom 1: Użytkownik (podstawowa diagnostyka) ^ | Poziom 0: Gość (bardzo ograniczony)
Przykład praktyczny: Tworzenie roli „Helpdesk” i „Junior Admin”
Naszym celem jest stworzenie dwóch ról:
- Helpdesk (Poziom 5): Pracownik pierwszej linii wsparcia. Musi mieć możliwość weryfikacji statusu interfejsów i logów, ale absolutnie żadnej możliwości zmiany konfiguracji.
- Junior Admin (Poziom 10): Młodszy administrator. Może wchodzić w tryb konfiguracji i zarządzać interfejsami (np. zmienić opis, wyłączyć/włączyć port), ale nie może modyfikować krytycznych elementów, jak routing czy listy ACL.
Krok 1: Definiowanie uprawnień dla roli Helpdesk (Poziom 5)
Logujemy się na router w trybie pełnych uprawnień (Poziom 15) i przypisujemy konkretne polecenia do Poziomu 5.
Router# configure terminal
Router(config)# # Przypisujemy polecenia 'show' do poziomu 5
Router(config)# privilege exec level 5 show ip interface brief
Router(config)# privilege exec level 5 show interfaces
Router(config)# privilege exec level 5 show logging
Router(config)# privilege exec level 5 ping
Router(config)# privilege exec level 5 traceroute
Krok 2: Definiowanie uprawnień dla roli Junior Admin (Poziom 10)
Teraz rozszerzamy uprawnienia. Chcemy, aby Junior Admin mógł robić wszystko to co Helpdesk, a dodatkowo wchodzić w tryb konfiguracji i zarządzać interfejsami.
Router(config)# # Junior Admin dziedziczy wszystkie polecenia z niższych poziomów
Router(config)# # Dajemy dostęp do trybu konfiguracji
Router(config)# privilege exec level 10 configure terminal
Router(config)# # Dajemy dostęp do komendy 'interface' w trybie config
Router(config)# privilege configure level 10 interface
Router(config)# # Dajemy dostęp do konkretnych komend w trybie config-if
Router(config)# privilege interface level 10 shutdown
Router(config)# privilege interface level 10 description
Krok 3: Tworzenie użytkowników i przypisywanie ich do ról (poziomów)
Router(config)# username hdesk01 privilege 5 secret SuperTajneHasloHelpdesku
Router(config)# username jadmin01 privilege 10 secret InneSuperTajneHasloAdmina
Router(config)# line vty 0 4
Router(config-line)# login local
Router(config-line)# end
Krok 4: Weryfikacja
Teraz zalogujmy się jako `hdesk01`.
Router> show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.1.1 YES NVRAM up up
Router> configure terminal
% Error: "configure" is not a recognized command.
Działa idealnie! A teraz jako `jadmin01`:
Router> configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface GigabitEthernet0/0
Router(config-if)# description Port dla serwera WWW
Router(config-if)# ip access-group 101 in
Command authorization failed.
Użytkownik `jadmin01` mógł wejść w tryb konfiguracji interfejsu i zmienić opis, ale próba przypisania listy ACL (do której nie daliśmy mu uprawnień) zakończyła się niepowodzeniem. Stworzyliśmy w ten sposób skuteczną, warstwową autoryzację.
Linux: Potęga uprawnień DAC i elastyczność `sudo`
W systemie Linux autoryzacja to temat rzeka. Mamy tu do czynienia z dwoma głównymi mechanizmami, które doskonale się uzupełniają: klasycznym modelem DAC (Discretionary Access Control) na poziomie systemu plików oraz potężnym narzędziem `sudo`, które pozwala na implementację modelu RBAC.
Część A: Model DAC w praktyce – `chmod` i `chown`
To absolutna podstawa. Każdy plik i katalog w Linuksie ma właściciela, grupę oraz zestaw uprawnień `rwx` (odczyt, zapis, wykonanie) dla trzech kategorii: właściciela (user), grupy (group) i pozostałych (others).
$ ls -l /var/log/syslog
-rw-r----- 1 syslog adm 12345 Oct 16 20:55 /var/log/syslog
| | | | | | | | | |
| | | | | | | | | +--> Nazwa pliku
| | | | | | | | +----------------> Czas modyfikacji
| | | | | | | +-------------------------> Rozmiar
| | | | | | +--------------------------------> Grupa
| | | | | +--------------------------------------> Właściciel
| | | | +------------------------------------------> Uprawnienia "Inni" (brak)
| | | +--------------------------------------------> Uprawnienia "Grupa" (odczyt)
| | +----------------------------------------------> Uprawnienia "Właściciel" (odczyt/zapis)
| +------------------------------------------------> Liczba dowiązań
+--------------------------------------------------> Typ pliku (- = plik, d = katalog)
Załóżmy, że mamy zespół deweloperów pracujących nad projektem w katalogu /var/www/projekt_x. Chcemy, aby wszyscy członkowie grupy `developers` mogli czytać i modyfikować pliki, ale tylko użytkownik `kierownik` mógł je usuwać i tworzyć nowe (czyli miał prawo zapisu do katalogu).
# groupadd developers
# usermod -aG developers jan
# usermod -aG developers anna
# chown -R kierownik:developers /var/www/projekt_x
# Ustawiamy właściciela i grupę dla całego katalogu.
# find /var/www/projekt_x -type d -exec chmod 775 {} \;
# Dla wszystkich katalogów (d): właściciel i grupa rwx, inni r-x.
# 775 -> (rwx)(rwx)(r-x)
# find /var/www/projekt_x -type f -exec chmod 664 {} \;
# Dla wszystkich plików (f): właściciel i grupa rw-, inni r--.
# 664 -> (rw-)(rw-)(r--)
Dzięki temu prostemu zabiegowi wdrożyliśmy politykę DAC: kierownik jako właściciel ma pełną kontrolę, deweloperzy mogą współpracować na plikach, a reszta użytkowników systemu może je co najwyżej podejrzeć.
Część B: Model RBAC z `sudo` – finezyjna kontrola administracyjna
Dawanie programistom czy operatorom pełnego dostępu do konta `root` to proszenie się o katastrofę. Tu z pomocą przychodzi `sudo`, które pozwala na delegowanie konkretnych poleceń administracyjnych. Konfiguracja odbywa się w pliku /etc/sudoers (ZAWSZE edytuj go poleceniem `visudo`!).
Przykład praktyczny: Rola „Operator Bazy Danych” i „Webmaster”
Stworzymy dwie role:
- DB Operator: Użytkownik `maria`, która może jedynie zarządzać usługą bazy danych PostgreSQL (start, stop, restart), ale niczym innym.
- Webmaster: Użytkownik `piotr`, który może edytować pliki w
/var/www/htmli restartować serwer Apache.
# visudo
# Otwiera edytor pliku /etc/sudoers. Dodajemy poniższe linie:
# ----- Aliasy poleceń (Cmnd_Alias) -----
Cmnd_Alias DB_COMMANDS = /bin/systemctl start postgresql, /bin/systemctl stop postgresql, /bin/systemctl restart postgresql
Cmnd_Alias WEB_COMMANDS = /bin/systemctl restart apache2, /usr/bin/nano /var/www/html/*
# ----- Przypisanie uprawnień do użytkowników -----
maria ALL = (ALL) DB_COMMANDS
piotr ALL = (ALL) WEB_COMMANDS
+-----------+ Wykonuje +-----------------+ Sprawdza +---------------+
| Użytkownik | ---------------> | `sudo ` | -------------> | /etc/sudoers |
| (np. maria) | +-----------------+ |---------------|
+-----------+ | Cmnd_Alias ...|
| maria ALL=... |
+---------------+
|
TAK (jeśli pasuje) / NIE (jeśli nie) |
V
+---------------+
| Wykonanie z |
| uprawnieniami |
| roota |
+---------------+
Weryfikacja
Logujemy się jako `maria`:
maria@server:~$ sudo systemctl restart postgresql
[sudo] password for maria: ********
# Usługa została zrestartowana.
maria@server:~$ sudo systemctl restart apache2
Sorry, user maria is not allowed to execute '/bin/systemctl restart apache2' as root on server.
Odmowa dostępu. Idealnie. `sudo` pozwala nam wdrożyć Zasadę Minimalnych Uprawnień w chirurgiczną precyzją.
MikroTik RouterOS: Zarządzanie przez Grupy Użytkowników
RouterOS, podobnie jak Cisco, implementuje model RBAC, ale w jeszcze bardziej czytelny sposób. Nie operujemy na numerach, lecz na grupach, a każdej grupie przypisujemy zestaw predefiniowanych polityk (uprawnień). To bardzo elastyczny system.
Najważniejsze polityki w RouterOS:
- read: Odczyt konfiguracji (ale nie np. haseł użytkowników).
- write: Zapis konfiguracji.
- full: Pełne uprawnienia, łącznie z zarządzaniem użytkownikami i resetem konfiguracji.
- ssh, winbox, web, ftp, api: Zezwolenie na logowanie za pomocą danej usługi.
- test: Dostęp do narzędzi diagnostycznych, jak `ping`, `traceroute`.
- policy: Możliwość edycji polityk bezpieczeństwa (firewall, очередности, etc.).
- sniff: Używanie packet sniffera.
Przykład praktyczny: Rola „Monitoring” i „Guest WiFi Admin”
Stworzymy dwie nowe grupy z niestandardowymi uprawnieniami:
- Monitoring: Grupa dla systemów monitorujących (np. Zabbix). Potrzebuje dostępu przez API tylko do odczytu podstawowych parametrów.
- Guest WiFi Admin: Użytkownik (np. recepcjonista), który może jedynie dodawać i usuwać tymczasowe vouchery do sieci gościnnej Hotspot, ale nie może dotykać niczego innego w konfiguracji.
Krok 1: Tworzenie grupy i użytkownika „Monitoring”
[admin@MikroTik] > user group add name=monitoring policy=api,read,test
[admin@MikroTik] > user add name=zabbix_user group=monitoring password=HasloDlaMonitoringu
Ta konfiguracja pozwala użytkownikowi `zabbix_user` zalogować się przez API, odczytać status interfejsów, obciążenie CPU, ale nie pozwala na żadne zmiany.
+-----------+ Należy do +------------+ Posiada polityki +---------------------+
| Użytkownik| -----------------> | Grupa | ----------------------> | Uprawnienia systemowe |
|-----------| |------------| |---------------------|
| zabbix_user | | monitoring | | - Dostęp API |
+-----------+ +------------+ | - Odczyt konfiguracji |
| - Narzędzia testowe |
+---------------------+
Krok 2: Tworzenie grupy i użytkownika „Guest WiFi Admin”
To bardziej zaawansowany przykład. Domyślne polityki (`read`, `write`) są zbyt szerokie. Aby dać dostęp tylko do jednego menu w Winbox/WebFig, musimy użyć mechanizmu skórek (Skins) dostępnego w nowszych wersjach RouterOS (v7+).
1. Stworzenie skórki: W menu `System -> Skins` tworzymy nową skórkę, np. `hotspot_only`. W edytorze tej skórki dosłownie „wyklikujemy” (ukrywamy) wszystkie menu z wyjątkiem `IP -> Hotspot`. Zapisujemy.
2. Stworzenie grupy i przypisanie jej skórki:
[admin@MikroTik] > user group add name="Guest Admins" skin=hotspot_only policy=read,write,winbox,web
# Dajemy prawa read/write, ale skórka ograniczy je tylko do widocznych menu.
3. Stworzenie użytkownika:
[admin@MikroTik] > user add name=recepcja group="Guest Admins" password=HasloDlaRecepcji
Weryfikacja
Gdy użytkownik `recepcja` zaloguje się teraz do Winboxa, zamiast pełnego, rozbudowanego menu, zobaczy tylko jedną pozycję: „IP”, a w niej „Hotspot”. Będzie mógł zarządzać użytkownikami Hotspota, ale cała reszta konfiguracji routera będzie dla niego niewidoczna i niedostępna. To jest właśnie granularna autoryzacja w najlepszym wydaniu.
Podsumowanie
Przeszliśmy przez trzy zupełnie różne światy, ale cel był ten sam: świadome i precyzyjne zarządzanie uprawnieniami. W Cisco IOS zbudowaliśmy hierarchię dostępu za pomocą poziomów uprawnień. W Linuksie wykorzystaliśmy fundamentalne mechanizmy DAC do zabezpieczenia plików oraz potęgę sudo do delegowania zadań administracyjnych. W RouterOS stworzyliśmy niestandardowe role przy użyciu grup, polityk, a nawet skórek interfejsu.
Pamiętaj, że autoryzacja nie jest jednorazowym zadaniem, lecz ciągłym procesem. Regularnie przeglądaj uprawnienia, usuwaj niepotrzebne dostępy i zawsze, absolutnie zawsze, kieruj się Zasadą Minimalnych Uprawnień. To ona stanowi granicę między kontrolowanym, bezpiecznym środowiskiem a chaosem, który tylko czeka na wykorzystanie przez atakującego. W kolejnym, ostatnim już artykule z serii o AAA, zajmiemy się Rozliczaniem (Accounting).
