Odkąd powstała pierwsza aplikacja, z której mógł korzystać więcej niż jeden użytkownik, powstał problem w ich rozróżnianiu. Zadawano pytania, dlaczego należałoby różnicować użytkowników, w jakich przypadkach i według jakich kryteriów oraz w jaki jak sposób trzeba by zarządzać ich uprawnieniami? Wszystkie te pytania sprowadzały się tak naprawdę do jednego – w jaki sposób należy kontrolować dostęp do systemów teleinformatycznych i zarządzać nim.
Pierwsze aplikacje były dostarczane z wbudowanymi kontami dla użytkowników, którzy w zależności od podanej nazwy mieli dostęp do konkretnych, zdefiniowanych funkcjonalności. Było to bardzo uciążliwe, ponieważ każda zmiana w aplikacji niosła za sobą konieczność modyfikacji modułu odpowiedzialnego za dostęp do aplikacji. Z biegiem czasu i wraz z postępem informatyzacji, kiedy to komputery opuściły pojedyncze pomieszczenia, najczęściej uniwersyteckie, i wkroczyły do licznych gałęzi gospodarki, aplikacje stawały się coraz potężniejsze i musiały obsługiwać rosnącą liczbę użytkowników. Wymusiło to na projektantach tworzenie architektur pozwalających na łatwy przyrost liczby użytkowników.
Szybko zaczęto wykorzystywać zewnętrzne bazy danych i drzewa katalogowe, które przechowywały informacje o użytkownikach. Powstawały również standardy przechowywania uprawnień użytkowników oraz modele zarządzania dostępem. Chciałbym pokrótce przedstawić podstawowe modele z perspektywy użytkownika i administratora oraz wyjaśnić konieczność stosowania mechanizmów zarządzania tożsamością w dużych systemach IT.
Zarządzanie dostępem – autoryzacja
W zarządzaniu dostępem mówimy zawsze o dostępie czegoś do czegoś. Coś, co żąda dostępu, nazywamy podmiotem, zaś coś, do czego dostęp jest żądany, obiektem. Między podmiotem a obiektem musi istnieć mechanizm, który na podstawie pewnych zapisów (reguł) określi, czy dany podmiot może uzyskać dostęp do obiektu, czy też nie. Z punktu widzenia tych reguł w zarządzaniu dostępem można wyróżnić trzy modele.
Pierwszym modelem jest Mandatory Access Control (MAC), co w wolnym tłumaczeniu oznacza obligatoryjną bądź narzuconą kontrolę dostępu. Każdy obiekt posiada etykietkę związaną z jego klasyfikacją na poziom bezpieczeństwa lub oznaczeniem wrażliwości danych, które dany obiekt przechowuje. Każdy podmiot, który chce uzyskać dostęp do takiego obiektu również musi posiadać odpowiednią etykietkę, tzw. poświadczenie bezpieczeństwa dla danego poziomu.
Klasyfikacje mogą być różne. Instytucje rządowe są na przykład zobligowane ustawą o informacjach niejawnych do stosowania następującej nomenklatury: informacje jawne, zastrzeżone, tajne i ściśle tajne. Podmiot mający poświadczenie bezpieczeństwa na poziom „tajne” może uzyskać dostęp do poziomu o tej samej klasyfikacji lub niższych. Dostęp w tym modelu jest często związany z dodatkowymi restrykcjami. Z reguły restrykcją jest paradygmat bezpieczeństwa need-to-know. Polega on na tym, iż podmiot niezależnie od posiadanego poświadczenia bezpieczeństwa musi mieć uzasadnioną potrzebę do korzystania z zasobów danego obiektu, wynikającą na przykład z jego obowiązków służbowych. Przykładem modelu MAC jest mechanizm rule-based access control, czyli zarządzania dostępem przez reguły, które determinują dostęp podmiotu do obiektu.
Jak działa ten model z punktu widzenia użytkownika i administratora? Administratorem w tym przypadku jest właściciel obiektu, czyli właściciel informacji, ponieważ to on klasyfikuje własne obiekty, nadając im odpowiedni poziom bezpieczeństwa. Może być pewny, że nikt o niższym poświadczeniu bezpieczeństwa nie będzie miał dostępu do jego danych. Należy jednak podkreślić, iż nie steruje on bezpośrednio dostępem do obiektów, jedynie je klasyfikuje. Użytkownik musi zaś zdobyć odpowiednie poświadczenie i dodatkowo posiadać potrzebę dostępu do danego obiektu. W przeciwnym razie dostęp nie zostanie mu przyznany.
Drugim modelem jest Discretionary Access Control (DAC), czyli swobodna kontrola dostępu. W tym przypadku właściciel informacji ma możliwość swobodnego zarządzania dostępem do swoich obiektów dla konkretnych użytkowników. Przykładem implementacji tego modelu jest tworzenie list kontroli dostępu (ang. ACL), które zawierają powiązanie uprawnionego użytkownika z obiektem, często konkretnym plikiem. Z jednej strony, model ten daje dużą swobodę i precyzję nadawania uprawnień do plików, ale z drugiej wymaga starannego zarządzania. Najczęściej o dostępie decyduje jedynie sama tożsamość danego podmiotu – mówimy wtedy o Identity-based Discretionary Access control. Niekiedy kontrola dostępu do obiektów może zostać przyznana użytkownikom bezpośrednio. Mamy wtedy do czynienia z User-direct Discretionary Access Control.
Kolejny model to Non-Discretionary Access Control (N-DAC), czyli narzucona kontrola dostępu. W tym przypadku decyzja o dostępie jest podejmowana centralnie, autorytatywnie, często w nawiązaniu do polityki bezpieczeństwa danej organizacji. Zarządzanie dostępem może bazować na przynależności użytkownika do tzw. roli. Role mogą być tworzone w oparciu o funkcje, z którymi związane są określone akcje użytkowników, czyli zakres ich obowiązków w organizacji. Przynależność użytkownika do roli determinuje jego zestaw uprawnień do obiektów. Taki model nazywamy Role-based Access Control. Nazwa ta stosowana jest często wymiennie z nazwą samego modelu N-DAC.
W tym modelu można również wyróżnić szeregowanie użytkowników względem powierzonych im obowiązków. Mówimy wtedy o Task-Based Access Control. Model N-DAC jest bardzo wygodny dla dużych systemów, w którym mamy do czynienia ze znaczną rotacją użytkowników. Poprzez szybkie dodanie użytkownika do odpowiedniej roli, wynikającej z jego służbowych obowiązków, można mu nadać wszelkie niezbędne w jego pracy uprawnienia. Codzienna administracja takiego systemu jest więc bardzo prosta. Skupienia i uwagi wymaga natomiast same tworzenie takiego systemu, kiedy to projektant aplikacji musi odpowiednio skonstruować system ról powiązany z określonymi funkcjonalnościami.
Zarządzanie tożsamością
Powyżej przedstawione zostały modele zarządzania dostępem podmiotów do obiektów, czyli innymi słowy modele autoryzacji. W pojęciu zarządzania dostępem kryje się jeszcze jeden element – uwierzytelnienie. Każdy podmiot przed przystąpieniem do fazy autoryzacyjnej musi zostać zidentyfikowany, a jego tożsamość potwierdzona. Istnieje wiele metod uwierzytelniania, którymi nie będziemy się tu zajmować. Niezwykle ważne jest natomiast to, aby system wymagał uwierzytelnienia. Problem zaczyna się pojawiać w chwili, gdy w środowisku IT pracuje wiele systemów, zależnych lub niezależnych od siebie.
Pojedynczy użytkownik w danej organizacji może posiadać nawet kilka kont, czyli w najgorszym przypadku kilka różnych nazw użytkownika i metod uwierzytelnienia. Do takich środowisk niezbędne jest wprowadzenie systemu zarządzania tożsamością użytkownika, który najczęściej jest powiązany z funkcjonalnością jednokrotnego logowania się (Single Sign-On). Jakie są korzyści wynikające z zastosowania tej funkcjonalności?
Z punktu widzenia użytkownika:
- użytkownik posiada dostęp do różnych systemów, jednak identyfikuje się tą samą nazwą użytkownika,
- użytkownik uwierzytelniając się raz uzyskuje dostęp do wszystkich systemów wewnątrz środowiska IT.
Z punktu widzenia administratora:
- administrator posiada dokładną informację o ilości kont poszczególnych osób fizycznych w całym środowisku IT,
- zarządzanie wszystkimi kontami w różnych systemach odbywa się z jednego, centralnego miejsca,
- zarządzanie dostępem użytkowników do obiektów, w zależności od wybranego modelu, odbywa się z jednego, centralnego miejsca,
- administrator ma możliwość generowania zbiorczego raportu o działalności użytkownika w całym środowisku IT,
- administrator może zablokować/usunąć wszystkie konta użytkownika z jednego, centralnego miejsca, za pomocą jednego przycisku, w całym środowisku IT,
- wprowadzenie systemu zarządzania tożsamością wpływa przede wszystkim na zmniejszenie kosztów utrzymania systemów, co wiąże się z uproszczoną administracją.
Tomasz Śnieżyński, Dyrektor Konsultingu Bezpieczeństwa IT, Comarch SA
