Kontrola dostępu - modele

Opis popularnych kontroli dostępu

DAC (Discretionary Access Controll)

definiuje podstawowe metody kontroli dostępu do obiektów w systemie plików. DAC pozwala użytkownikowi na całkowite ustalenie uprawnień dostępu do swoich zasobów, co oznacza że przez przypadek lub złośliwość można dać dostęp niepowołanym osobom. DAC jest aktualnie używany jako podstawowy model bezpieczeństwa w Linuxsie. W modelu DAC naturalnym zjawiskiem jest dzielenie wszelkiego rodzaju zasobów, jako iż użytkownik definiuje prawa dostępu do tworzonych obiektów. Obiekty użytkownika i procesu domyślnie dziedziczą po nim prawa dostępu.

MAC (Mandatory Access Control)

model ochrony i zabezpieczania procesów, danych i urządzeń systemowych przed szkodliwym nadużyciem/wykorzystaniem. MAC rozszerza lub zastępuje DAC. Najważniejszą cechą jest to, iż użytkownik nie może w pełni kontrolować dostępu do zasobów, które tworzy. Sposób działania zabezpieczeń systemu (konfigurowalny przez administratora) całkowicie określa dostęp jaki użytkownik systemu może nadać swoim zasobom. Użytkownik nie może nadać mniej restrykcyjnych ograniczeń niż pozwala mu na to administrator.

RBAC (Role-Based Access Control)

podejście do ograniczania dostępu do zasobów systemowych na podstawie roli, jaką uzytkownik pełni w systemie. Jest to nowsze i inne podejście niż MAC i DAC. RBAC różni się od MAC i DAC. Wcześniej MAC i DAC były jedynymi modelami kontroli dostępu. Jeżeli jakiś nowy model nie było modelem MAC to był kwalifikowany jako DAC i na odwrót, jednak jak pokazały badania RBAC nie należy do żadnego z dwóch modeli. RBAC można przedstawić na przykładzie organizacji, wewnątrz której role są tworzone dla różnych funkcji. Pracownicy i personel mają przypisane szczególne role i przez przypisanie do tych ról, nabywają uprawnień do wykonywania określonych dla roli czynności. Ponieważ użytkownicy nie mają przypisanych uprawnień wprost, lecz zyskują je poprzez swoje role, dlatego zarządzanie indywidualnymi użytkownikami staje się jedynie kwestią przypisania użytkownikowi odpowiedniej roli, co upraszcza powszechne operacje takie jak dodawania użytkownika, czy zmieniania przydziału użytkownika.

TE (Type Enforcement)

każdy obiekt w systemie ma przypisany atrybut bezpieczeństwa. Dla procesów jest to domena, dla pozostałych obiektów jest to typ. TE traktuje wszytkie procesy należące do domeny w taki sam sposób. Identycznie jest z obiektami tego samego typu. Macierze dostępu definiują jaki dostep mają domeny do typów oraz jak domeny mogą wzajemnie oddziaływać z innymi domenami. Natomiast użytkownik ma nadane prawa do operowania w określonych domenach. Model TE wspomaga silną kontrole nad wykonaniem programu i przejściami pomiędzy domenami. Program, tak jak każdy inny obiekt, ma przydzielony typ, a macierz dostępu TE okresla jakie typy mogą być wykonywane w określonej domenie. Ponadto macierz dostępu TE mówi jakie typy mogą być wykonane aby dostać się do domeny, jako iż domena może być skojarzona ze szczególnym programem dostępowym i opcjonalnie ze szczególnymi programami wspomagającymi i/lub dzielonymi bibliotekami. Charakterystyka TE jest użyteczna w kojarzeniu uprawnień z konkretnym zbiorem kodu, bazując na jego funkcji i stopniu zaufania kodu. TE pomaga także w ochronie przed wykonywaniem szkodliwego kodu.

ACL (Access Control List) ::

mechanizm uzupełniający model DAC. ACL polega na dodaniu nowych klas dostepu oraz praw dostępu do danego obiektu, w zależności od pewnych aspektów procesu proszącego o dostęp. Tak jak w DAC definiujemy uprawnienia w schemacie UGO, tak w ACL możemy to rozszerzyć o zdefiniowanie praw dla konkretnych użytkowników lub grup. Lista jest strukturą danych (zazwyczaj tablica) zawierającą wpisy, które określają indywidualne dla użytkownika/grupy prawa do określonego obiektu systemowego (program, proces, plik). Te wpisy są znane jako Access control entries (ACE) w systemach MS Windows i OpenVMS. Każdy dostępny/osiągalny obiekt zawiera identyfikator swojego ACL. Przywileje/uprawnienia określają specyficzne prawa dostępu, takie jak prawa do czytania, pisania, wykonywania. W niektórych implementacjach ACE kontroluje czy użytkownik/grupa może zmieniać ACL obiektu.

MLS (Multi-Level Security)

zdolność systemu do przenoszenia informacji z różnym wyczuleniem (np. klasyfikacja informacji na różnych poziomach bezpieczeństwa), pozwalania na równoległy dostęp przez użytkowników z różnymi uprawnieniami oraz zapobiegania do pozyskiwania informacji, do której użytkownik nie ma autoryzacji. Developerzy systemów interpretują MLS jako mechanizm wymuszający ograniczenia na dzielenie się informacjami. System implementuje MLS, jeżeli implementuje mechanizm, który wymusza restrykcje na dzielenie się poufnymi danymi, niezależnie od tego jak efektywne dzielenie informacjami jest. Na przykładzie firmy możemy to pokazać w taki sposób jakby pracownik na niższym szczeblu mógł przesyłać dokumenty do pracownika na szczeblu wyższym. Natomiast niezależnie od tego co pracownik na wyższym szczeblu chce przekazać pracownikowi na niższym szczeblu, to nie może tego zrobić, nie zależnie od tego co chce przekazać.

FLASK (Flux Advanced Security Kernel)

system operacyjny zbudowany na architekturze FLASK zapewnia elastyczne wsparcie dla MAC. Każdy podmiot (proces) i obiekt w systemie (plik, port etc.) ma przydzielony zbiór atrybutów bezpieczeństwa, znany jako kontekst bezpieczeństwa. Kontekst bezpieczeństwa zawiera wszytkie atrybuty bezpieczeństwa przypisane konkretnemu podmiotowi lub obiektowi, który jest istotny dla polityki. Zawartość i format kontekstu bezpieczeństwa zależy od modelu/implementacji , zatem kontekst bezpieczeństwa jest interpretowany jedynie przez serwer.

Administracja

• audyty bezpieczeństwa
• testy penetracyjne systemów komputerowych i sieci
• hardening (uszczelnianie, zabezpieczanie) systemów operacyjnych i urządzeń teleinfomatycznych
• weryfikacja firmowych procedur bezpieczeństwa
• projektowanie dedykowanych polityk bezpieczeństwa
• analiza powłamaniowa i disaster recovery