Elastyczny system uprawnień w bazie danych PostgreSQL

Rozdział 40 Elastyczny system uprawnień w bazie danych PostgreSQL Streszczenie. W niniejszym rozdziale zostanie przedstawiony dynamiczny system obsługi uprawnień do obiektów bazodanowych zrealizowany w całości na poziomie bazy danych. System ten zapewnia dużą przeźroczystość uprawnień dla aplikacji przy zachowaniu akceptowalnej wydajności. System ten umożliwia kontrolę uprawnień na poziomie pojedynczych wierszy oraz zapewnia mechanizmy kontroli wywołań funkcji oraz procedur wbudowanych. Uprawnienia w tym systemie są definiowane za pomocą predykatów. 1 Wstęp Na Uniwersytecie Łódzkim jest tworzony zintegrowanego system zarządzania rektoratem. W celu zapewnienia odpowiedniego poziomu bezpieczeństwa był potrzebny system uprawnień, który pozwoliłby na określenie dla każdego użytkownika systemu oddzielnych podzbiorów dostępnych danych. Podzbiór taki może obejmować dowolną część rekordów z poszczególnych tabel. Zdecydowano, że uprawnienia będą sprawdzane po stronie bazy danych. Pozwala to na zapewnienie spójności danych, chroni przed przypadkowym nieuwzględnieniem uprawnień przez programistę oraz stanowi dodatkowy poziom ochrony. Do realizacji projektu został wybrany system zarządzania bazą danych(szbd) PostgreSQL [2]. Jest to zaawansowany system zarządzania bazą danych, oferujący wszystkie podstawowe funkcje, takie jak widoki, wyzwalacze, transakcje i podzapytania. Ten SZBD ma także kilka unikalnych cech, takich jak możliwość modyfikacji zapytań przed ich wykonaniem oraz obsługę wielu języków proceduralnych. Dialekt SQL obsługiwany przez system zarządzania bazą danych PostgreSQL jest w dużym stopniu zgodny z dialektem Oracle oraz ze standardem języka SQL. 2 Rozwiązania obsługi uprawnień Zarządzanie prawami dostępu do danych jest niezwykle istotną, niepomijalną częścią każdej aplikacji. umożliwiającej dostęp do danych przez wielu użytkowników o różnym zakresie uprawnień. W zależności od lokalizacji procedur zarządzających kontrola Jarosław Pychowski Uniwersytet Łódzki, Wydział Matematyki, ul. S. Banacha 22, 90-238 Łódź email:jpp@math.uni.lodz.pl

J. Pychowski uprawnień może być zrealizowana na poziomie aplikacji lub być wbudowana w bazę danych. Umieszczenie systemu uprawień po stronie aplikacji, pomimo wielu zalet, takich jak umożliwienie pewnej niezależności od bazy danych oraz łatwość implementacji (system w całości jest zbudowany w jednej technologii) ma kilka zasadniczych wad: nie wykorzystuje możliwości oferowanych przez konkretne systemy zarządzania bazą danych, uprawnienia są zależne od stosowanego interfejsu dostępowego, duplikuje część funkcjonalności bazy danych na poziomie aplikacji, podatne na błędy w aplikacji. Zależność od stosowanego interfejsu dostępowego objawia się niedziałaniem uprawnień np. w przypadku połączenia się do bazy za pomocą aplikacji dostarczonej przez producenta systemu zarządzania bazą danych. Szczególnie istotna jest podatność na błędy w aplikacji. Błąd w pozornie niezwiązanej części aplikacji może prowadzić do złamania zabezpieczeń. Próbą rozwiązania tych problemów jest wydzielenie w ramach aplikacji warstwy pośredniczącej w realizacji zapytań do bazy danych. Niestety nie zabezpiecza to przed wykorzystaniem narzędzi, które nie korzystają z tej warstwy. Przykładem takiego narzędzia może być aplikacja raportująca. Umieszczenie uprawnień po stronie systemu zarządzania bazą danych pozwala na uniknięcie wszystkich wcześniej wymienionych niedogodności. Istnieją cztery główne metody implementacji systemu uprawnień po stronie bazy danych: wykorzystanie funkcji wbudowanych, proste wykorzystanie statycznych widoków, etykietowanie wierszy (ang. security labels), wykorzystanie predykatów. Mechanizmy potrzebne do zaimplementowania trzech pierwszych metod są dostępne praktycznie w każdym systemie zarządzania bazą danych, który oferuje obsługę procedur wbudowanych oraz widoków. Jako przykłady takich baz danych można wymienić: Firebird [4], IBM DB2 [5], Microsoft SQL Server [6], Oracle [7], PostgreSQL[2], Sybase ASE[8]. Część z powyższych baz danych ma wbudowaną funkcjonalność definiowania uprawnień na poziomie wierszy za pomocą etykiet bez potrzeby pisania własnych rozwiązań. 2.1 Uprawnienia zaimplementowane w bazie danych realizowane za pomocą funkcji Rozwiązanie to polega na udostępnieniu interfejsu programistycznego złożonego tylko i wyłącznie z procedur oraz funkcji wbudowanych. Bezpośredni dostęp do tabel jest zabroniony. Do zalet takiego rozwiązania można zaliczyć pełną kontrolę nad wykonywanymi zapytaniami, dużą wydajność oraz możliwość dokładnego definiowania uprawnień użytkowników bazy. Aby zmienić uprawnienia wystarczy nadać lub odebrać uprawnienia do wykonywania konkretnej procedury. Jako wady można wymienić umieszczenie znaczącej części logiki aplikacji po stronie systemu zarządzania bazą danych (groźba zbytnego uzależnienia się od producenta) oraz nieprzezroczystość rozwiązania. 412

Elastyczny system uprawnień w bazie danych PostgreSQL Każde zapytanie musi być opakowane w odpowiednią procedurę, co prowadzi do braku elastyczności. 2.2 Uprawnienia zaimplementowane jako proste widoki Rozwiązanie to polega na umieszczeniu w bazie danych widoków ograniczających dostęp do danych, do których są przydzielane uprawnienie. Uprawnienia działają w sposób przezroczysty dla aplikacji. Nie wymaga od użytkownika ustawiania kontekstu. Pozwala, podobnie jak poprzednia metoda, definiowanie ograniczeń na widoku będącym złączeniem dwóch lub więcej tabel lub zwracającego tylko część kolumn tabeli. Dzięki zastosowaniu widoków istnieje także możliwość tworzenia na podstawie kilku widoków wydajnych zapytań do bazy danych. Niestety rozwiązanie takie jest statyczne, z poziomu aplikacji nie ma możliwości łatwej zmiany uprawnień po stworzeniu widoków. 2.3 Uprawnienia zaimplementowane za pomocą etykiet Rozwiązanie to jest znaczącym uogólnieniem poprzednich dwu metod. Pozwala ono na przydzielanie uprawnień do pojedynczych wierszy bez konieczności konstruowania skomplikowanych warunków. Polega ono na zmodyfikowaniu schematu bazy danych poprzez: dodanie do każdej tabeli dodatkowej kolumny zawierającej listę etykiet określających uprawnienia, dodanie do bazy danych tabel mapujących etykiety na odpowiednie role, dodanie do bazy danych widoków ograniczających dostęp do danych. Widoki rozpatrywane w tej metodzie są to widoki na jedną tabelę, które w klauzuli WHERE zawierają tylko i wyłącznie warunek wyboru wierszy na podstawie przydzielonych im etykiet oraz uprawnień użytkownika. Zazwyczaj zapytanie w definicji widoku jest postaci: SELECT * FROM tabela WHERE daj_etykiete_uzytkownika()=any(etykiety) Rozwiązanie to w sposób przezroczysty dla użytkownika pozwala na ograniczenie jego uprawnień. Istotną jego wadą jest konieczność sprawdzania dla każdego wiersza, czy w liście etykiet występują etykiety związane z bieżącym użytkownikiem, co prowadzi do problemów wydajnościowych w przypadku duże ilości etykiet lub dużego rozmiaru danych. Rozwiązanie tego typu zostało dokładnie opisane w [3] oraz [9]. Niektóre rozwiązania bazujące na etykietach wymagają od użytkownika ustalania kontekstu, w którym pracuje. 2.4 Uprawnienia zaimplementowane za pomocą predykatów Rozwiązanie to uzupełnia się z uprawnieniami zaimplementowanymi za pomocą etykiet. Pola na wprowadzeniu mechanizmów umożliwiających dodanie do zapytań dodatkowych warunków określających, które wiersze z tabeli może wybrać dane. Przykładowo, jeśli użytkownik wykona zapytane: SELECT * FROM tabela WHERE k1 IN (1, 3, 5) 413

J. Pychowski oraz ma uprawnienie tylko i wyłącznie do wierszy o wartościach w kolumnie k1 większych od 3 to zapytanie przed wykonaniem zostanie przekształcone do postaci: SELECT * FROM tabela WHERE k1 IN (1, 3, 5) AND k1>3 Metoda ta cechuję się dużą wydajnością przy dużych zbiorach danych oraz jest przezroczysta dla aplikacji. Dużą zaletą, jak i wadą tego rozwiązania jest ustalanie dostępu na podstawie predykatów. Z jednej strony pozwala na rezygnację z definiowania uprawnień dla każdego wiersza osobno, a z drugiej często prowadzi do konieczności budowania bardzo skomplikowanych warunków występujących w uprawnień (często z podzapytaniami). Rozwiązanie bazujące na funkcji, która generuje dodatkowe fragmenty zapytań jest zaimplementowane w bazie danych Oracle w pakiecie DBMS_RLS, którego dokładny opis można znaleźć w dokumentacji bazy danych Oracle. Istotne jest, że w celu uaktywnienia obsługi uprawnień albo użytkownik musi wywołać odpowiednią funkcję ustalającą tzw. kontekst albo funkcja ta musi być wywołana w wyzwalaczu na zdarzeniu LOGIN. 3 Założenia systemu zarządzania uprawnieniami Podczas projektowania zintegrowanego systemu zarządzania rektoratem dużo uwagi poświęcono kontroli dostępu do danych, który musiał zapewnić: możliwie dużą elastyczność przy definiowaniu uprawnień, możliwość zmiany uprawnień w zależności od używanej w danym momencie funkcjonalności aplikacji, system uprawnień powinien działać w sposób przezroczysty dla aplikacji, spadek wydajności powinien być możliwie najmniejszy. Szczegółowy opis stworzonego systemu znajduje się w [1]. Warto nadmienić, że zdecydowano się skorzystać z widoków na tabele oraz przyjąć jako warunek ograniczający (predykat) kompletną zawartość klauzuli WHERE. Jako kompletną definicję uprawnień dla konkretnej tabeli przyjęto jej nazwę oraz predykat. Rozwiązanie takie, pomimo obaw zespołu, okazało się wystarczająco wydajne w większości przypadków. System ten zawodził w właściwie tylko w jednej sytuacji: warunki występujące w uprawnieniach lub zapytanie SQL były skomplikowane. Na szczęście zarówno w systemie zarządzania rektoratem, na potrzeby którego powstał system uprawnień, jak i większości projektów tak skomplikowane zapytania podczas normalnej pracy systemu (pomijając podsystemy raportujące) są stosunkowo rzadko używane. Problemy z wydajnością wynikały ze definiowania warunków uprawnień tylko w zakresie definiowania warunku ograniczającego dostęp do wierszy konkretnej tabeli (klauzula WHERE). Rozwiązanie takie, pomimo swojej prostoty wymaga stosowania podzapytań, co często prowadziło do sytuacji, w której optymalizator bazy danych traktował podzapytanie jako czarną skrzynkę. Podczas planowania wykonania podzapytanie nie było przesuwane do listy tabel (FROM), tylko pozostawało w klauzuli WHERE. Było to związane z przekroczeniem dopuszczalnego stopnia zagnieżdżenia podzapytań, do którego zapytanie jest spłaszczane oraz wielokrotne wykonanie podzapytania w czasie realizacji jednego zapytania do bazy. Przykładowo zapytanie: SELECT * FROM widok; Wykonane na widoku systemu uprawnień zdefiniowanego następującym poleceniem: 414

Elastyczny system uprawnień w bazie danych PostgreSQL CREATE VIEW widok AS SELECT * FROM tabela WHERE t2_id IN ( SELECT id FROM t2 WHERE war) Jeśli założymy na potrzeby tego przykładu, że dopuszczalna głębokość podzapytań jest równa 0 to optymalizator zaplanuje wykonanie tego zapytania następująco: Zamiast: SELECT * FROM tabela WHERE t2_id IN ( SELECT id FROM t2 WHERE war) SELECT * FROM tabela t, t2 WHERE t.t2_id = t2.id AND war Rozwiązaniem tego problemu mogłoby być nie tyle definiowanie uprawnień w klauzul WHERE widoku, ale zdefiniowanie całego widoku ręcznie korzystając z wiedzy na temat danych zawartych bazie, zoptymalizowanie zapytania. W przypadku przedstawionego przykładu definicja widoku byłaby następująca (w typowym przypadku): CREATE VIEW widok AS SELECT t.* FROM tabela t, t2 WHERE t.t2_id = t2.id AND war Zmiana taka pozwoliłaby także rozwiązać problem niskiej wydajności skomplikowanych zapytań. Zapytanie takie byłoby zmodyfikowane tak, aby uwzględniało ograniczenia wynikające z uprawnień, zoptymalizowane, a następnie użyte do stworzenia widoku. Oczywiście podejście takie (połączenie zapytania i uprawnień w jedno) jest sensowne tylko w przypadku, gdy zapytanie jest bardzo skomplikowane. W innych sytuacjach poprzez ręczną modyfikację zapytania nie uzyskamy wzrostu wydajności w porównaniu z rozwiązaniem omówionym w [1]. 4 Budowa systemu obsługi uprawnień Omawiany w niniejszym rozdziale system jest innym w stosunku do [1] podejściem do zdefiniowanego powyżej problemu. System ten jest złożony z trzech zasadniczych części: definicje uprawnień, procedury ładowania uprawnień do bazy danych, procedury wbudowane w bazę danych. W dalszej części zastaną one omówione dokładniej. 415

J. Pychowski 4.1 Definicje uprawnień Na definicje uprawnień składa się zestaw plików XML-owych opisujących konkretne obiekty, do których są przydzielane uprawnienia, główny plik konfiguracyjny oraz definicje parametrów globalnych. Wszystkie te dokumenty są opisane przez schematy XML Schema. Zgodność dokumentów ze schematami jest sprawdzana przed rozpoczęciem ładowania uprawnień do bazy danych. Dokument definiujący uprawnienia od obiektu zawiera następujące informacje: typ obiektu, nazwę, nazwę skróconą (nazwę obiektu w bazie danych) opcje aplikacji, w których występuje, definicje parametrów definicję treści obiektu (to pole ma różne znaczenie w zależności od rozpatrywanego typu obiektu). System dopuszcza następujące typy obiektów: tabela widok na tabelę zgodny z ideą z pracy [1], widok widok realizujący propozycję opisaną wcześniej, funkcja uprawnienia są definiowane do funkcji wbudowanej. Niezwykle istotna jest możliwość parametryzacji wszystkich obiektów definiowanych przez uprawnienia. Parametry można podzielić na dwie grupy. Pierwszą stanowią parametry generowane przez system na podstawie pewnego wyrażenia, które jest wykonywane w momencie tworzenia obiektu w bazie danych. Drugą są parametry przydzielane przez administratora aplikacji z puli dopuszczalnych parametrów (mogą one być wypisane w pliku opisu obiektu lub wynikiem działania zapytania SQL-owego). Umożliwia to łatwą modyfikację uprawnień pojedynczego użytkownika z poziomu aplikacji bez konieczności nadawania bardzo szerokich uprawnień bazodanowych administratorowi aplikacji. Poniżej znajduje się przykładowy plik definicji obiektu: <?xml version="1.0" encoding="utf-8"?> <obiekt> <typ>widok</typ> <nazwa>testowy obiekt</nazwa> <nazwa_skrocona>test</nazwa_skrocona> <opcje> <opcja> <modul>a</modul> <pakiet>p</pakiet> <opcja>o2</opcja> </opcja> </opcje> <parametry> <parametr> <nazwa>param</nazwa> <generator>current_user</generator> </parametr> <parametr> <nazwa>param2</nazwa> <wartosci> <wartosc>1</wartosc> <wartosc>2</wartosc> <wartosci> </parametr> </parametry> 416

Elastyczny system uprawnień w bazie danych PostgreSQL <definicja> SELECT * FROM t WHERE pole=<parametr>param</parametr> </definicja> </obiekt> Istnieje możliwość wydzielenia definicji parametrów występujących w dużej ilości obiektów do osobnych plików (parametry globalne). Istotne jest, że wszystkie parametry muszą być jawnie zdefiniowane. Podejście takie uniezależnia definicje uprawnień od wersji oprogramowania obsługującego uprawnienia. Jest to szczególnie istotne w środowisku, gdzie uprawnienia mogą definiować programiści podczas tworzenia aplikacji. Ostatnim plikiem, który jest istotny dla działania systemu uprawnień jest plik konfiguracyjny (także napisany w XML-u). Plik ten zawiera kilka opcji konfiguracyjnych (istotnych dla implementacji np. sposób pobierania klucza głównego z tabeli zawierającej oraz polecenia ładujące pliki z parametrami globalnymi oraz obiektami. Pliki, które nie zostaną wymienione nie zostaną przetworzone. Rozwiązanie takie umożliwia przygotowanie w łatwy sposób kilku profili uprawnień dzielących ze sobą część definicji obiektów. co jest istotne na przykład w procesie testowania aplikacji. 4.2 Procedury ładowania uprawnień do bazy danych Procedury ładowania działają zgodnie z następującym schematem: 1) Załadowanie pliku konfiguracyjnego oraz jego przetworzenie 2) Załadowanie opisów parametrów globalnych 3) Zweryfikowanie dokumentów z definicjami obiektów 4) Załadowanie do tabel systemu uprawnień definicji obiektów (utworzenie lub uaktualnienie wpisów) 5) Sprawdzenie, czy wcześniej przydzielone przez administratora wartości parametrów dla obiektów są dopuszczalne (spełniają warunki z definicji parametru). Jeśli nie, to wygenerowanie odpowiedniego raportu, 6) Usunięcie definicji starych (nie przetworzonych podczas bieżącego ładowania) obiektów uprawnień z bazy danych Jak widać system uwzględnia konieczność aktualizacji uprawnień przy przechodzeniu do nowej wersji aplikacji. Wbudowane mechanizmy ułatwiają pracę administratora systemu. 4.3 Procedury wbudowane w bazę danych Część aplikacji działająca po stronie bazy danych wykorzystuje kilka szczególnych cech bazy danych PostgreSQL. Pierwszą silnie wykorzystywaną cechą jest możliwości zdefiniowania dla jednego użytkownika kilku schematów, które na dodatek są dość luźno z nim powiązane (np. użytkownik nie musi być właścicielem schematu, właścicielem schematu domyślnego użytkownika może być inny użytkownik). Pozwala to na bardzo łatwe zdefiniowanie kilku profili uprawnień dla jednego konta. Użytkownik loguje się do bazy i wybiera profil, w którym chce pracować (np. wywołując funkcję wbudowaną). System ustawia jako schemat domyślny schemat odpowiadający danemu profilowi. Jest to szerzej opisane w [1]. Drugą cechą jest możliwość definicji funkcji w kilku językach (m.in. PL/pgsql, PL/java, SQL). Szczególnie istotna jest możliwość definiowania funkcji w języku SQL, których kod może być wstawiony do zawierającego je zapytania. Jest wykorzystane w przypadku definiowania uprawnień do zwracanych przez funkcję wierszy (gdy funkcja zwraca zbiór). 417

J. Pychowski Trzecią cechą jest możliwość modyfikacji budowy zapytania przed jego wykonaniem z wykorzystaniem tzw. reguł przepisywania zapytań. Procedury wbudowane w dużym stopniu korzystają z trzech powyższych mechanizmów oraz realizują następującą funkcjonalność: ustawienie schematu zależnego od wybranego profilu, zbudowanie oraz usunięcie schematu odpowiadającego danemu profilowi, tworzenie odpowiednich obiektów uprawnień dla konkretnego profilu użytkownika, utworzenie oraz usunięcie użytkownika. 5 Wnioski końcowe Opisany system obsługi uprawnień zapewnia praktycznie nieograniczoną swobodę definicji uprawnień do istniejących obiektów. Zastosowane w obecnej wersji rozwiązania pozwalają znacząco obniżyć narzut czasowy opisany w [1] poprzez zdefiniowanie dodatkowych obiektów w bazie, do których może się odwoływać aplikacja. W przeciwieństwie do systemu obsługi uprawnień opisanego w [1] rozpatrywany system jest znacznie bardziej elastyczny, pozwala na definicję większego zakresu obiektów bazodanowych (system opisany w [1] pozwalał tylko na zdefiniowanie widoku na jednej tabeli) oraz wprowadza znacznie silniejsze rozgraniczenie pomiędzy rolami administratora bazy danych/architekta systemu, a administratora aplikacji. Administrator bazy danych lub architekt systemu definiuje szablony uprawnień, które są niezmienne, a administrator aplikacji może tylko ustalać wartości parametrów. Pozwala to zabezpieczyć się przed błędami w aplikacji, które generowałyby potencjalnie niebezpieczne definicje widoków. System ten można wprowadzić do użytku zarówno w nowych projektach, jak i już działających. Wdrożenie tego rozwiązania w wymaga tylko dostosowania interfejsu przydzielania uprawnień z poziomu aplikacji. Pozostałe części systemu pozostaną bez zmian. Opisany system można stosunkowo łatwo dostosować do użycia w innych systemach zarządzania bazą danych niż PostgreSQL. Konieczne zmiany objęłyby tylko procedury wbudowane. Część systemu znajdująca się poza bazą pozostałaby niezmieniona. Stopień złożoności przeniesienie zdefiniowanych uprawnień pomiędzy różnymi systemami zarządzania bazą danych jest trudny do oszacowania ze względu na różny stopień zgodności ze standardem zaimplementowanych w DBMS-ach języków zapytań. Podobnym do omawianego rozwiązania rozwiązaniem jest Oracle Virtual Private Database, który także realizuje obsługę uprawnień za pomocą predykatów. Jako zasadnicze różnice można wymienić następujące zagadnienia: omawiany system jest rozwiązaniem hybrydowym, pozwala na definicję uprawnień zarówno za pomocą predykatów, jak i etykiet (list kontroli dostępu), omawiany system nie jest ściśle zintegrowany z konkretnym systemem zarządzania bazą danych (większość funkcjonalności da się stosunkowo łatwo przenieść na dowolną inną bazę danych wspierającą procedury wbudowane i wyzwalacze na widokach), omawiany system pozwala na definiowanie uprawnień nie tylko na tabelach ale też na widokach i funkcjach. 418

Literatura Elastyczny system uprawnień w bazie danych PostgreSQL 1. Miodek K., Pychowski J.: Elastyczny system uprawnień użytkowników w systemie zarządzania bazą danych PostgreSQL, Bazy danych modele, technologie, narzędzia, tom I, strony309-314 WkiŁ, Warszawa 2005 2. Dokumentacja bazy danych PostgreSQL http://www.postgresql.org 3. Dokumentacja systemu Veil http://pgfoundry.org/projects/veil/ 4. Strona bazy danych Firebird http://www.firebirdsql.org/ 5. Strona bazy danych IBM DB2 http://www-306.ibm.com/software/data/db2/ 6. Strona bazy danych Microsoft SQL Server http://www.microsoft.com/sql/default.mspx 7. Strona firmy Oracle http://www.oracle.com 8. Strona firmy Sybase http://www.sybase.com 9. Rask A., Rubin D., Neumann B.: Implementing Row- and Cell-Level Security in Classified Databases Using SQL Server 2005, http://www.microsoft.com/technet/prodtechnol/sql/2005/ multisec.mspx. 419