Przemysław Piechota Artur Filbier 07.06.10 Wrocław Internetowe bazy danych i hurtownie danych Projekt System obsługujący rejestracje klientów do kancelarii prawniczej Spis treści: 1 Ogólny koncept systemu 1.1 Diagram ERD 1.2 Model funkcjonalny DFD 2 Architektura systemu 2.1 Serwer bazy danych 2.2 Serwer HTTP 2.3 Technologia Apex 2.4 System operacyjny 2.5 Platforma sprzętowa 3 Analiza bezpieczeństwa systemu
1 Ogólny koncept systemu Zaprojektowany system jest aplikacją webową obsługującą rejestracje klientów do kancelarii prawniczej. Mimo to staraliśmy się podejść ogólnie do problemu rejestracji, dlatego można go wykorzystać również w innych placówkach, które chcą oferować swoim klientom możliwość internetowej rezerwacji terminów swoich usług. System podzielony został na dwa moduły: panel klienta oraz panel administratora. Zarówno do pierwszego jak i do drugiego można się połączyć za pomocą przeglądarki internetowej przy wykorzystaniu protokołu HTTP. Moduł klienta umożliwia rejestrację klienta na wizytę w określonym terminie do określonego pracownika. Program umozliwia podgląd i anulowanie zamówionych wizyt. Moduł administratora umożliwia szerokopojętą administrację systemem, w tym: zarządzanie, tworzenie i usuwanie kont, pracowników i harmonogramów. 1.1 Diagram ERD
Opis tabel: Accounts: Informacje o kontach zawartych w systemie. Zbierane są podstawowe dane osobowe: e-mail, hasło, imię i nazwisko, data urodzenia, telefon, adres, miasto. Konta pracownicze są odróżniane od kont klientów na podstawie kolumnu ROLE. Jest to klucz obcy odwołujący się do istniejących ról w systemie, w tym też specjalizacji pracowników. Roles: Tabela zawiera nazwy ról zawartych w systemie. Możliwe role to między innymi "klient", a także role oznaczające specjalizacje zawodowe. Do klucza głownego ROLE_ID odwołuje się klucz obcy ROLE z tabeli Accounts. Schedules: Wierszami tej tabeli są harmonogramy pracowników i ich zakresy. Każdy z pracowników może posiadać kilka harmonogramów, lecz ich zakresy nie mogą się pokrywać. Podczas insertu nowego wiersza do tabeli, za pomocą ograniczenia (constraint) CHECK, baza danych sprawdza czy data zakończenia harmonogramu DATE2 jest późniejsza od daty rozpoczęcia, a także czy daty nie są wcześniejsze od aktualnego czasu. Nie ma sensu przecież tworzyć harmonogramu w przeszłości. To aby zakresy harmonogramów jednego pracownika nie nachodziły na siebie jest pilnowane na poziomie aplikacji za pomocą odpowiednich walidacji wprowadzanych danych. Kolumna HOST symbolizuje pracownika, dla którego został stworzony harmonogram o identyfikatorze ID. HOST jest kluczem obcym i odwołuje się do istniejącego konta pracownika w tabeli Accounts. Na obrazku nie jest to oznaczon. Kolumna STATUS określa stan harmonogramu, który może być włączony (0) lub wyłączony/usunięty (1).
Schedule_days Każdy harmonogram zawarty w tabeli Schedules ma przypisane zakresy pracy w poszczególne dni tygodnia, znajdujące się w tabeli Schedule_days. Można ustalić tylko jeden zakres pracy dla określonego dnia w danym harmonogramie. Aby tego dopilnować, nałożylismy ograniczenie (constraint) UNIQUE na kolumny SCHEDULE_ID oraz DAY. Kolumny DAY_START i DAY_END określają godzinę rozpoczęcia i zakończenia pracy przez pracownika w danym dniu w danym harmonogramie. Na kolumnę DAY_END zostało nałożone ograniczenie (constraint) CHECK pilnujące aby ta godzina była późniejsza od DAY_START. Zatem podsumowując do tej pory, mamy pracowników, którzy mają przypisane harmonogramy pracy. Każdy pracownik może mieć zero lub kilka harmonogramów, ale które na siebie nie nachodzą. Każdy harmonogram może mieć przypisane zero lub maksymalnie 5 unikalnych dni roboczych z ustalonymi zakresami pracy. Timetable Jest to najważniesza tabela w całym schemacie. Na podstawie danych zawartych w Schedules i Schedule_days zostaje wygenerowany grafik, którego elementami są terminy wizyt. Wizyta posiada konkretny termin (data i godzina w kolumnie WHEN o typie DATE) mieszczący się w zakresie pracy w danym dniu danego harmonogramu (SCHEDULE_ID klucz obcy) danego pracownika (HOST). Do jednej wizyty może być przypisany zero lub jeden klient (GUEST klucz obcy do ACCOUNT_ID w tabeli Accounts). W tabeli Timetable są wygenerowane wizyty dla wszystkich włączonych harmonogramów. Klient po zalogowaniu do systemu może się zarejestrować na określoną wizytę do dowolnego pracownika. Do wyboru ma oczywiście tylko wizyty wolne. Kolumna STATUS określa czy wizyta jest włączona czy została usunięta. Kolumna CHECKPOINT jest wykorzystywana przez system do pilnowania spójności wiztyt w obrębie jednego harmonogramu. Im wyższy
CHECKPOINT tym świeższa zmiana dokonana na harmonogramie. Pomocne jest to podczas działania niektórych procedur, które modyfikują harmonogram. Można dzięki temu na przykład wyłączyć wizyty, które po dokonanej modyfikacji harmonogramu, nie mieszczą się w zakresie harmonogramu lub zakresie dnia pracy. 1.2 Diagram DFD Diagram ogólny: 2 Architektura systemu Punktem wyjścia dla zaprojektowania naszego systemu był wybór bazy danych. Uznaliśmy, że jest to najważniejszy element ze względu na to, że przechowywane są w niej informacje, bez których żaden system nie mógłby istnieć. Pozostałe komponenty dobieraliśmy tak, aby zapewnić jej bezpieczne i optymalne funkcjonowanie. Postanowiliśmy wybrać markę Oracle z trzech powodów. Po pierwsze jest to uznany producent systemów bazodanowych, który tworzy produkty najwyższej jakości. Po drugie Oracle udostępniło darmową dystrybucję swojej sprawdzonej bazy danych o nazwie 10g XE. Silnik
tej bazy jest w całości oparty na swoim komercyjnym odpowiedniku. Niemniej jednak Oracle nałożyło na nią pewne ograniczenia. Działa ona na jednym procesorze, wykorzystuje maksymalnie do 1 Gb RAMu, a przestrzeń dyskowa nie może przekraczać 4 Gb. Mimo to wymagania naszej aplikacji mieszczą się w tych limitach. Po trzecie jej komercyjna wersja 10gR1 jest obecna na rynku od 2004 roku i od tamtego czasu zostało wydanych wiele patchy poprawiających jej bezpieczeństwo, w które domyślnie wyposażona jest wersja XE. Na początku zastanawialiśmy się nad wyborem Sun MySQLa, ale w związku z przejęciem firmy Sun przez Oracle doszliśmy do wniosku, że jest to produkt o niepewnej przyszłości. Oracle najprawdopodobniej będzie degradowało znaczenie MySQla na rzecz XE. Kolejnym krokiem był dobór systemu operacyjnego. Zdecydowana wiekszość baz Oracle działa na systemach unixowych (HP-UX, AIX, Oracle Solaris) w tym 60% na Solarisie. My również postanowiliśmy pójść w tym kierunku. Przy całym uznaniu dla Windowsa, nie interesowały nas płatne systemy Microsoftu. Wybór padł na Solarisa. System ten jest najlepiej supportowany przez Oracle, ponieważ od niedawna jest to również produkt tej firmy. Niestety odkąd Sun został kupiony, Solaris przestał być systemem open-source i konieczne byłoby wykupienie licencji po 30 dniach użytkowania. Na szczęście rownolegle rozwijany jest system OpenSolaris, będący darmowym odpowiednikiem Solarisa. Dystrybucje Solarisa od niedawna wspierają bardzo ciekawy system plików ZFS, a także wbudowaną technologie wirtualizacji systemu o nazwie Zones. Oba te komponenty przyczynią się zarówno do ułatwionej administracji, optymalizacji, czy też bezpieczeństwa. Wybór technologii do napisania aplikacji był podyktowany bazodanowym charakterem docelowego produktu. Nasza aplikacja w sposób intensywny korzysta z zasobów bazy danych, dlatego chcieliśmy się przede wszystkim skupić na dopracowaniu warstwy biznesowej, bez kładzenia nacisku na warstwę prezentacyjną. W związku z tym zależało nam na środowisku, które ułatwiałoby życie programisty przy tworzeniu interfejsów webowych. Takim
środowiskiem jest technologia Oracle Application Express (Apex). Apex wprowadza ujednoliconą metodologię pracy nad programem. Instaluje się bezpośrednio w bazie danych za pomocą skryptów sql. Gotowe środowisko składa się z danych w tabelach oraz kodu napisanego w PL/SQL, a korzysta się z niego za pomocą przeglądarki internetowej, która łączy się z bazą za pomocą protokołu HTTP na odpowiednio skonfigurowanym porcie. Serwer HTTP wykorzystywany w naszym systemie to wbudowany w bazę danych serwer XML DB HTTP. Wybraliśmy to rozwiązanie ze względu na jego dobrą współpracę z technologią Apex. 2.1 Serwer bazy danych Wykorzystywana baza to Oracle 10g XE. Posiada ona jedną instancję o nazwie XE, której parametry wykorzystania pamięci RAM są ustawione na automatyczne. W ten sposób baza danych sama dostosowuje wykorzystanie pamięci zgodnie z aktualnym przeciążeniem bazy. Połączenie z bazą jest możliwe za pomocą protokołu HTTP dzięki odpowiednio skonfigurowanemu Listenerowi. W pliku listener.ora obecne są informacje o hoście, protokole i porcie na którym listener ma nasłuchiwać połączeń. Wbudowany w bazę serwer http jest automatycznie rejestrowany do listenera bazy danych, dzieki czemu listener może przekazywać połączenia do serwera http. Przeciążenie bazy w ciągu dnia szacowane jest na 50-70 połączeń. Nie jest to dużo. Baza jest skonfigurowana na tworzenie procesów typu shared-server. Powoduje to, współdzielenie pamięci przez wiele sesji użytkowników, przez co możliwe jest zwiekszenie ilości możliwych sesji jdnocześnie połączonych do bazy danych. W innym wypadku każda sesja zajmowałaby pamięć, co prowadziłoby do jej wyczerpania. Parametry bazy zostały tak skonfigurowane aby możliwe było obsłużenie do 70 sesji w puli. Zastosowany tu został mechanizm Connection Pooling. Gdy jedna z sesji jest nieaktywna, to jej połączenie z bazą danych jest wykorzystane przez nową sesję. Gdy stara sesja znowu chce stać się aktywna to
czeka na zwolnienie połączenia. Pozwala to na zwiększenie ilości jednoczesnych sesji ponad ilość sesji w puli. 2.2 Serwer HTTP Oracle 10g XE pozwala na użycie takich serwerów HTTP jak Apache, Oracle Application Server, oraz wbudowany w bazę XE serwer XML DB HTTP. Wybraliśmy trzecią opcję ze względu na uproszczoną architekturę systemu. Dzięki temu uzyskujemy model dwuwarstwowy zamiast trójwarstwowego, bez konieczności dodatkowej instalacji serwera http. Serwer XML DB HTTP posiada bramkę PL/SQL, która umożliwia komunikację z bazą danych, wyposaża ją w serwer webowy z niezbędną infrastrukturą do tworzenia dynamicznych aplikacji. Jej działanie jest bardzo podobne do modułu mod_plsql zawartego w serwerze Apache. Istotą tego mechanizmu jest mapowanie zapytań URL przesłanych protokołem HTTP przez klientów webowych na odpowiednie procedury PL/SQL. Oto jak przedstawia się przetwarzanie zapytań klientów za pomocą bramki PL/SQL: - Serwer XML DB HTTP otrzymuje zapytanie z przegladarki klienta, - Serwer XML DB HTTP przekazuje zapytanie do wbudowanej bramki PL/SQL, - Bramka korzysta z informacji zawartych w zapytaniu HTTP oraz własnych plikach konfiguracyjnych w celu określenia, którego
bazodanowego konta użyć do połączenia z bazą danych, - Bramka przygotowuje parametry i wywołuje procedury PL/SQL zawarte w aplikacji, - Procedura PL/SQL generuje kod strony HTML korzystając z danych zawartych w bazie danych, - Odpowiedź skierowana jest spowrotem do bramki PL/SQL, - Serwer XML DB HTTP przekazuje odpowiedź do przeglądarki klienta. 2.3 Technologia Apex Apex jest technologią wytwarzania aplikacji webowych opartych na bazie danych Oracle i języku PL/SQL. Zasada jego działania jest taka sama niezależnie od tego czy pracujemy w środowisku developerskim, czy używamy stworzonej aplikacji. Przeglądarka wysyła zapytanie URL, które jest tłumaczone na odpowiednią apexową procedurę napisaną w pl/sql. Po przetworzeniu przez bazę tego zapytania, wynik jest wysyłany spowrotem do przegladarki w postaci
HTML. Ten cykl powtarza się za każdym razem, gdy następuje żądanie bądź submitowanie strony. Stan sesji jest zarządzany w tabelach apexa. Żądania nie tworzą odrębnego dedykowanego połączenia z bazą danych. Zamiast tego tworzona jest kolejna sesja, co powoduje, że maleje zużycie CPU. 2.4 System operacyjny Opensolaris został skonfigurowany aby działał na zonach. Są to kontenery wirtualizacyjne pozwalające na wydzielenie aplikacji, tak jakby funkcjonowała na odrębnym hoście. Pozwala to zachować bezpieczeństwo danych aplikacji, do którrych nie będą miały dostępu aplikacje z innych zon. Zona działa na systemie plików ZFS. Jest to nowy system o usprawnionej konfiguracji. Dzieki jego zastosowaniu możliwa jest między innymi kompresja przechowywanych danych. W przypadku bazy Oracle jest to bardzo pomocne gdyż kiedy baza przydziela plikom miejsce na dysku, zabiera cały przydzielony im obszar, nawet gdy pliki zajmują tylko fragment przydzielonego miejsca. ZFS powoduje, że zajęty jest rzeczywisty wykorzystywany obszar. Dzięki Zonie możliwa jest łatwa migracja zony z aplikacją na inny system Solaris. 2.5 Platforma sprzętowa Wykorzystany sprzęt podyktowany jest wymaganiom bazy, w obrębie których mieszczą się wymagania aplikacji. Wystarczy jeden procesor Intel Pentium IV 2,4 Ghz, 1 Gb RAMu oraz do 4 Gb wolnego miejsca na dysku twardym. 3 Analiza bezpieczeństwa systemu Bezpieczeństwo na poziomie bazy danych: Postępowanie według zasady "least privilege", wg której użytkownik bazy ma przypisane tylko potrzebne przywileje. Zablokowanie lub usunięcie
nieużywanych kont. Używanie różnych haseł do kont administracyjnych SYS i SYSTEM. Baza danych została uruchomiona w stanie Archivelog, który powoduje archiwizowanie plików Redo Logs odpowiedzialnych za rejestrowanie zmian w bazie danych. Dzięki temu możliwe jest odtworzenie stanu bazy po korupcji instancji. Archiwizowane pliki kierowane są do obszaru Flash Recovery Area umieszczonym na odrębnym dysku. W tym samym obszarze są umieszczone kopie pliku konfiguracyjnego Control File, a także backupy zarządzane programem RMAN. RMAN skonfigurowany został na tworzenie backupów co 3 dni. W przypadku awarii możliwe jest odtworzenie danych w najgorszym wypadku do trzech dni wstecz. Przeciwdziałanie atakom XSS: Ataki XSS (Cross-site scripting) najczęściej utożsamia się z umieszczeniem przez intruza kodu JavaScript w aplikacji, który następnie jest uruchamiany w momencie pojawienia się w systemie nowego użytkownika. Nasz system przeciwdziała takim zagrożeniom przez filtrowanie danych z formularzy. Filtrowanie to polega na akceptowaniu łańcuchów znaków pozbawionych znaków specjalnych, które mogą tworzyć szkodliwy kod. Możliwe jest to dzięki odpowiednim wyrażeniom regularnym. Przykład: ^([1-zA-Z]{1,50} [a-za-z]{1,50})$ To wyrażenie regularne nałożone jest w formularzu na pole "Imię i nazwisko" jako walidacja na poziomie aplikacji. Przepuszcza tylko litery alfabetu. Przeciwdziałanie atakom SQL Injection: Ataki te są niebezpieczne gdy użytkownicy zewnętrzni mogą wprowadzać dane wykorzystywane w zapytaniach DML, które modyfikują dane. Przeciwdziałamy temu na poziomie aplikacji poprzez walidacje wprowadzanych danych. Sprawdzamy długość łańcuchów, format danych oraz obecnosć znaków
niedozwolonych. Przykladem może być strona Zapisu do systemu, w której klient tworzy nowe konto. SSL: Można zaszyfrować dane przesyłane przez przeglądarkę do serwera HTTP. Dzięki temu można utajnić hasła i loginy podczas logowania. Niestety nie udało nam sie tego dokonać ze względu na problemy z dostawcą usługi SaaS, na której obecnie działa nasza aplikacja.