Modele autoryzacji: RBAC, MAC i DAC
Porównają Państwo modele kontroli dostępu opartej na rolach, obowiązkowej i uznaniowej oraz dowiedzą się, kiedy każdy z nich sprawdza się w środowiskach korporacyjnych i rządowych.
Modele autoryzacji: RBAC, MAC i DAC to bezpłatna lekcja Security+ Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Security+ Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Security+ Academy zawiera 4 lekcji w sumie.
Przegląd modeli kontroli dostępu
Modele kontroli dostępu definiują reguły i zasady określające, które podmioty (użytkownicy, procesy) mogą uzyskiwać dostęp do poszczególnych obiektów (plików, systemów, danych). Wybrany model określa, kto może przyznawać dostęp, jak przypisywane są uprawnienia oraz jak działa ich egzekwowanie. Egzamin Security+ obejmuje cztery podstawowe modele: uznaniową kontrolę dostępu (DAC), obowiązkową kontrolę dostępu (MAC), kontrolę dostępu opartą na rolach (RBAC) oraz kontrolę dostępu opartą na regułach. Zrozumienie zalet każdego modelu i właściwych dla niego zastosowań jest niezbędne do projektowania skutecznych systemów autoryzacji.
Uznaniowa kontrola dostępu (DAC)
W przypadku uznaniowej kontroli dostępu (DAC) właściciel zasobu decyduje, kto może uzyskać dostęp do jego zasobów, i może przyznawać innym użytkownikom dostęp lub go odbierać. Określenie „uznaniowa” oznacza, że decyzje podejmują właściciele — system egzekwuje ich decyzje, ale ich nie narzuca. Jest to model stosowany w większości środowisk komputerów osobistych (uprawnienia do plików NTFS w Windows oraz uprawnienia do plików w systemach Linux/Unix). Ograniczenie bezpieczeństwa DAC polega na tym, że każdy właściciel zasobu musi podejmować właściwe decyzje dotyczące dostępu — użytkownik, który uzyskał dostęp do pliku, może przyznać go innym bez udziału administratora, co może doprowadzić do rozpowszechnienia poufnych danych poza zamierzonym gronem odbiorców.
# DAC example: Linux file permissions (owner controls access)
# Create a file and check default permissions
touch confidential_data.txt
ls -la confidential_data.txt
# -rw-rw-r-- 1 alice users (owner=alice, can read/write; group can read/write; others read)
# Owner (Alice) discretionarily removes all access for others
chmod 600 confidential_data.txt
# -rw------- 1 alice users (only Alice can read/write)
# Alice grants read to a specific user via ACL
setfacl -m u:bob:r confidential_data.txtRyzyka DAC: problem zdezorientowanego zastępcy
DAC wiąże się z dwoma nieodłącznymi zagrożeniami bezpieczeństwa. Dostęp tranzytywny: użytkownik A przyznaje dostęp użytkownikowi B, a użytkownik B przyznaje go użytkownikowi C — pierwotny właściciel może nawet nie wiedzieć, że użytkownik C ma dostęp do jego zasobu. Problem zdezorientowanego zastępcy: uprzywilejowany program działający w imieniu użytkownika o mniejszych uprawnieniach może przypadkowo wykorzystać swoje uprawnienia w sposób niedostępny bezpośrednio temu użytkownikowi. W środowiskach DAC pojedyncze przejęte konto może potencjalnie uzyskać dostęp do wszystkich zasobów, do których przyznano uprawnienia temu użytkownikowi, a przed wykryciem przejęcia może także przyznać dostęp innym osobom. DAC jest wygodny, ale utrudnia ścisłe ograniczanie przepływu informacji.
Obowiązkowa kontrola dostępu (MAC)
W przypadku obowiązkowej kontroli dostępu (MAC) system operacyjny egzekwuje zasady dostępu na podstawie etykiet bezpieczeństwa przypisanych zarówno podmiotom (użytkownikom), jak i obiektom (danym). Użytkownicy nie mogą omijać ani zmieniać tych zasad — może je modyfikować wyłącznie administrator systemu lub zasady bezpieczeństwa. MAC stosuje się w utajnionych środowiskach rządowych i wojskowych, w których dane muszą być ściśle rozdzielone. Użytkownik z poświadczeniem „Poufne” nie może uzyskać dostępu do danych oznaczonych jako „Ściśle tajne”, nawet jeśli właściciel danych chciałby mu go przyznać. Model Bell-LaPadula (bez odczytu w górę, bez zapisu w dół) oraz model Biba (bez zapisu w górę, bez odczytu w dół) to formalne implementacje MAC.
# SELinux is a MAC implementation for Linux
# Check SELinux mode and policy
getenforce # Enforcing / Permissive / Disabled
sestatus # Detailed SELinux status
# View SELinux security context labels on files
ls -Z /etc/passwd
# system_u:object_r:passwd_file_t:s0 /etc/passwd
# Security context: user:role:type:level
# A process can only access files where its type has explicit permission
sudo ausearch -m avc -ts recent # View MAC policy denialsModele MAC Bell-LaPadula i Biba
Dwa formalne modele MAC ujmują cele bezpieczeństwa w postaci reguł matematycznych. Bell-LaPadula koncentruje się na poufności: podmioty nie mogą odczytywać danych o wyższym poziomie klasyfikacji (bez odczytu w górę) ani zapisywać danych na niższym poziomie klasyfikacji (bez zapisu w dół). Zapobiega to przepływowi poufnych informacji do nieuprawnionych użytkowników. Biba koncentruje się na integralności: podmioty nie mogą zapisywać danych na wyższym poziomie integralności (bez zapisu w górę) ani odczytywać danych z niższego poziomu integralności (bez odczytu w dół). Biba zapobiega skażeniu danych o wysokiej integralności przez dane wejściowe o niskiej integralności. Rzeczywiste systemy MAC (takie jak SELinux) łączą elementy obu modeli.
Kontrola dostępu oparta na rolach (RBAC)
Kontrola dostępu oparta na rolach (RBAC) przypisuje uprawnienia do ról, a nie bezpośrednio do poszczególnych użytkowników, a następnie przypisuje użytkowników do ról. Rozwiązuje to problem zarządzania polegający na przypisywaniu pojedynczych uprawnień na dużą skalę. Typowe role w środowiskach korporacyjnych to: admin, auditor, developer, HR_manager, finance_analyst. Gdy do firmy dołącza nowy pracownik, zostaje dodany do odpowiedniej roli i natychmiast dziedziczy wszystkie wymagane przez nią uprawnienia. Gdy pracownik zmienia stanowisko, zmienia się jego rola, a uprawnienia są automatycznie dostosowywane. RBAC jest dominującym modelem w systemach IAM przedsiębiorstw.
# RBAC example (database permissions)
# Create roles and assign permissions
CREATE ROLE readonly_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_analyst;
CREATE ROLE data_engineer;
GRANT SELECT, INSERT, UPDATE ON customer_data TO data_engineer;
# Assign users to roles
GRANT readonly_analyst TO alice;
GRANT data_engineer TO bob;
# When Alice is promoted: revoke old role, grant new one
REVOKE readonly_analyst FROM alice;
GRANT data_engineer TO alice;Zalety RBAC: skalowalność i rozdzielenie obowiązków
Najważniejszą zaletą RBAC jest skalowalność administracyjna. Zmiana uprawnień roli natychmiast wpływa na wszystkich użytkowników przypisanych do tej roli — nie trzeba aktualizować rekordów poszczególnych użytkowników w setkach systemów. RBAC naturalnie wspiera rozdzielenie obowiązków, ponieważ gwarantuje, że żadna pojedyncza rola nie będzie mieć sprzecznych uprawnień (np. rola, która może zarówno tworzyć, jak i zatwierdzać transakcje finansowe). RBAC upraszcza również zapewnienie zgodności: audytorzy mogą przeglądać role i ich uprawnienia zamiast kontrolować tysiące indywidualnych przypisań użytkowników. Ograniczeniem jest eksplozja ról — organizacje czasami tworzą zbyt wiele szczegółowych ról, powodując złożoność zarządzania, która niweluje korzyść wynikającą ze skalowalności.
Kontrola dostępu oparta na regułach
Kontrola dostępu oparta na regułach (której nie należy mylić z RBAC) przyznaje lub odmawia dostępu na podstawie zestawu reguł warunkowych, a nie wyłącznie tożsamości lub roli. Klasycznym przykładem są reguły zapory sieciowej: „Zezwól na TCP z 192.168.1.0/24 do dowolnego celu na porcie 443. Odrzuć cały pozostały ruch”. Dostęp jest oceniany względem reguł w określonej kolejności aż do znalezienia dopasowania. Kontrolę opartą na regułach często łączy się z innymi modelami: MAC używa etykiet bezpieczeństwa jako reguł, a kontrola dostępu oparta na atrybutach (ABAC) rozszerza logikę opartą na regułach, umożliwiając jednoczesną ocenę wielu atrybutów (dział użytkownika, typ urządzenia, pora dnia, klasyfikacja zasobu) w celu podejmowania szczegółowych decyzji.
# Rule-based access control: iptables firewall rules
# Rules are evaluated in order; first match wins
# Allow established/related connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow specific source IP to SSH
iptables -A INPUT -s 10.0.0.100 -p tcp --dport 22 -j ACCEPT
# Allow HTTPS from anywhere
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# Default deny all other inbound
iptables -A INPUT -j DROPKontrola dostępu oparta na atrybutach (ABAC)
ABAC (kontrola dostępu oparta na atrybutach) to najbardziej elastyczny i szczegółowy model kontroli dostępu. Decyzje dotyczące dostępu uwzględniają jednocześnie wiele atrybutów: atrybuty podmiotu (dział użytkownika, poziom poświadczenia, lokalizacja), atrybuty obiektu (klasyfikacja danych, dział właściciela, etykieta przechowywania), atrybuty środowiskowe (pora dnia, typ urządzenia, lokalizacja sieciowa) oraz atrybuty działania (odczyt, zapis, usunięcie). Zasada może brzmieć: „Zezwól na dostęp, jeśli user.department = Finance ORAZ resource.classification = Internal ORAZ device.type = corporate ORAZ time.hour BETWEEN 8 AND 18”. ABAC umożliwia podejmowanie decyzji zgodnych z zasadą zero trust i jest implementowany przez produkty takie jak XACML oraz silniki zasad IAM w chmurze.
Wybór właściwego modelu
Właściwy model kontroli dostępu zależy od wymagań bezpieczeństwa i kontekstu organizacyjnego. DAC: odpowiedni dla komputerów osobistych i małych zespołów, w których wygoda ma większe znaczenie niż ścisła kontrola. MAC: wymagany w utajnionych środowiskach rządowych i wojskowych, w których konieczne jest ścisłe rozdzielenie informacji. RBAC: idealny dla przedsiębiorstw, w których kluczowe znaczenie ma skalowalność administracyjna, a role można łatwo powiązać z funkcjami stanowisk. ABAC: odpowiedni dla środowisk chmurowych i architektur zero trust, w których potrzebne są szczegółowe zasady uwzględniające kontekst. W praktyce większość organizacji stosuje połączenie modeli: RBAC jako podstawę oraz ABAC do podejmowania decyzji dotyczących dostępu zależnych od kontekstu.
Listy kontroli dostępu (ACL)
Niezależnie od modelu kontroli dostępu listy kontroli dostępu (ACL) są najczęściej stosowanym technicznym mechanizmem implementacji. Lista ACL przypisana do zasobu określa, które podmioty mogą wykonywać jakie działania. Listy ACL systemu plików (Windows NTFS, Linux POSIX ACL) kontrolują dostęp do plików i katalogów. Sieciowe listy ACL kontrolują przepływ ruchu na poziomie routera lub sieci chmurowej. Listy ACL baz danych kontrolują dostęp do tabel i poszczególnych wierszy. Listy ACL mogą implementować dowolny z omawianych modeli: lista ACL pliku implementuje DAC, gdy zarządza nią właściciel; lista ACL systemu zabezpieczeń implementuje MAC, gdy wpisy są określane przez etykiety; lista ACL aplikacji implementuje RBAC, gdy wpisy odwołują się do ról.
# Windows NTFS ACL example using icacls
# View current ACL on a folder
icacls 'C:\Sensitive\HR_Data'
# BUILTIN\Administrators:(OI)(CI)(F) <- Full control
# CONTOSO\HR_Team:(OI)(CI)(RX) <- Read and Execute
# Grant specific permissions to HR Managers group
icacls 'C:\Sensitive\HR_Data' /grant 'CONTOSO\HR_Managers:(OI)(CI)(M)'
# (OI)=Object Inherit, (CI)=Container Inherit, (M)=Modify
# Remove access for a former contractor
icacls 'C:\Sensitive\HR_Data' /remove 'CONTOSO\contractors'Szybkie sprawdzenie
Sprawdź swoją znajomość zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.
Podsumowanie lekcji
W tej lekcji poznali Państwo: DAC pozwala właścicielom zasobów kontrolować dostęp (jest elastyczny, ale ryzykowny); MAC wykorzystuje wymuszane przez system etykiety bezpieczeństwa (jest restrykcyjny i stosowany w środowiskach z informacjami niejawnymi); RBAC przypisuje uprawnienia do ról, co ułatwia skalowanie w przedsiębiorstwach; natomiast ABAC ocenia wiele atrybutów, aby podejmować precyzyjne decyzje zgodne z zasadą zero trust. Następnie omówimy tożsamość federacyjną: SAML, OAuth i OpenID Connect.
Często zadawane pytania
Czy lekcja „Modele autoryzacji: RBAC, MAC i DAC” jest bezpłatna?
Tak — pełny tekst „Modele autoryzacji: RBAC, MAC i DAC” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Security+ Academy, przejdź na CoddyKit PRO. Kurs Security+ Academy zawiera 4 lekcji w sumie.
Co nauczysz się w „Modele autoryzacji: RBAC, MAC i DAC”?
Porównają Państwo modele kontroli dostępu opartej na rolach, obowiązkowej i uznaniowej oraz dowiedzą się, kiedy każdy z nich sprawdza się w środowiskach korporacyjnych i rządowych. Ćwiczysz Security+ Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Security+ Academy?
Nie wymagamy żadnego doświadczenia. Security+ Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.
Ile czasu zajmuje lekcja „Modele autoryzacji: RBAC, MAC i DAC”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Security+ Academy?
Tak. Każda lekcja Security+ Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Zasady haseł i uwierzytelnianie wieloskładnikowe
- Biometria i uwierzytelnianie oparte na tokenach
- Modele autoryzacji: RBAC, MAC i DAC
- Federacyjna tożsamość: SAML, OAuth i OpenID Connect