Języki definiowania polityki bezpieczeństwa

Transkrypt

1 Program Operacyjny Innowacyjna Gospodarka: Dział anie Projekt: Nowe technologie informacyjne dla elektronicznej gospodarki i społeczeństwa informacyjnego oparte na paradygmacie SOA Raport częściowy z prac wykonanych w ramach zadania OB7 5 Języki definiowania polityki bezpieczeństwa dla SOA Analiza technologii opartych na paradygmacie SOA w kontekście własności i mechanizmów polityki bezpieczeństwa Katarzyna Kozłowska, Marek Chodorowski, Michał Rzepka, Michał Szychowiak Sieć Naukowa Technologii Informacyjnych SOA

2 Informacje o dokumencie Numer raportu: TR ITSOA OB7 5 PR Koordynator: Autorzy: Data: Poziom dostępności: Słowa kluczowe: Michał Szychowiak (PP) Katarzyna Kozłowska, Marek Chodorowski, Michał Rzepka, Michał Szychowiak (PP) (ostatnie zmiany: Michał Szychowiak) wewnętrzny partnera bezpieczeństwo, implementacje SOA Numer raportu: TR-ITSOA-<numer OB>{PU PR}-<rok utworzenia>-<kolejny numer> Poziomy dostępności: Wewnętrzny partnera, wewnętrzny konsorcjum, publiczny Politechnika Poznańska /96

3 Historia zmian w dokumencie 1 Wersja Data modyfikacji Zmodyfikowane przez Opis modyfikacji Michał Szychowiak (PP) Utworzenie dokumentu, struktura treści Michał Szychowiak (PP) Wstępna treść Marek Chodorowski i Michał Rzepka (PP) WCF (Marek Chodorowski) i Oracle (Michał Rzepka) Michał Szychowiak (PP) Rozdział Katarzyna Kozłowska (PP) Rozdział Michał Szychowiak (PP) Scalenie modyfikacji i poprawki redakcyjne Marek Chodorowski (PP) WCF poprawki do uwierzytelniania i autoryzacji Katarzyna Kozłowska (PP) Definiowanie polityki bezpieczeństwa dla WebSphere Application Server Michał Rzepka (PP) Podpunkt 4.3, przykłady, poprawki Michał Szychowiak (PP) Wstęp i zakończenie Michał Szychowiak (PP) Punkt 3.3 przeniesiony na początek Marek Chodorowski (PP) Punkt 5.6 Federacje (WCF) Michał Rzepka (PP) Punkt 2.2 (Apache) Michał Rzepka (PP) Punkt 2.2 (SOA w technologii Java) Katarzyna Kozłowska (PP) Punkt Michał Szychowiak (PP) Poprawki punktów 2.2, 2. 3 Katarzyna Kozłowska (PP) słownik i wykaz skrótów Marek Chodorowski (PP) porównanie WCF Oracle drobne poprawki Michał Rzepka (PP) audyt Oracle Michał Szychowiak (PP) Poprawki redakcyjne Michał Szychowiak (PP) poprawka w logo na stronie tytułowej 1 Tylko do użytku wewnętrznego Politechnika Poznańska /96

4 Spis treści Streszczenie Wstęp...7 Cel i zakres raportu...7 Struktura raportu Problematyka bezpieczeństwa w architekturze SOA...9 Bezpieczeństwo w systemach rozproszonych...9 Polityka bezpieczeństwa...9 Zagrożenia bezpieczeństwa Mechanizmy ochrony Architektura SOA i jej realizacje Web Services SOA w technologii Java Problematyka bezpieczeństwa w architekturze SOA Model przetwarzania polityki bezpieczeństwa Federacje Analiza technologii środowiska IBM WebSphere Uwierzytelnianie Typy tokenów Integralność i poufność Ustanawianie bezpiecznej komunikacji Rozszerzenia WebSphere Application Server Polityka bezpieczeństwa Audyt Analiza technologii środowiska Oracle SOA Suite Oracle Web Services Manager Polityka bezpieczeństwa Oracle Application Server Integracja OracleAS z innymi komponentami Konfiguracja bezpieczeństwa usług internetowych Audyt Analiza technologii środowiska Microsoft WCF...59 Konfiguracja opcji związanych z bezpieczeństwem Zachowania Wiązania Schematy bezpieczeństwa Uwierzytelnianie Autoryzacja Delegacja Federacje Audyt Podsumowanie...88 Politechnika Poznańska /96

5 7. Bibliografia Wykaz skrótów i słowniczek pojęć...94 Politechnika Poznańska /96

6 Streszczenie Raport przedstawia analizę własności mechanizmów bezpieczeństwa w wybranych implementacjach architektury SOA. Analizie poddano najbardziej reprezentatywne środowiska komercyjne, tj. IBM WebSphere, Oracle SOA Suite i Microsoft WCF oraz technologie bazujące na języku Java dostępne również w środowiskach niekomercyjnych i typu open-source. Zakres analizy objął w szczególności cechy istotne dla definicji polityki bezpieczeństwa, co stanowi podstawę opracowania koncepcji i wykonania projektów metod i narzędzi środowiska do przetwarzania języka definicji polityki bezpieczeństwa zgodnego z paradygmatem SOA i zoptymalizowanego pod kątem współoperatywności w heterogenicznym systemie SOA. Politechnika Poznańska /96

7 1. Wstęp Cel i zakres raportu Architektura SOA (ang. Service Oriented Architecture [1]) odwzorowuje koncepcję przetwarzania rozproszonego zorientowanego na usługi, która zyskuje coraz szersze zainteresowanie w środowisku naukowym i, co równie doniosłe, na rynku informatycznym, czego dobitnym wyrazem jest wsparcie niewątpliwych potentatów tego rynku, jak IBM, Oracle, Microsoft oraz wielu innych. Mnogość dostępnych technologii i trudności w ich wzajemnej współpracy rodzą potrzebę wypracowania i rozpropagowania standardowych rozwiązań. Organizacje, które podjęły się tego zadania, w tym W3C (World Wide Web Consortium [2]), OASIS (Organization for the Advancement of Structured Information Standards [3]) czy WS-I (Web Services Interoperability Organization [4]), opracowały już obszerny zbiór standardów łącznie z szeregiem rekomendacji i scenariuszy (ang. profiles) wykorzystania. W przypadku systemów rozproszonych problematyka bezpieczeństwa przetwarzania danych i komunikacji od wielu lat odgrywa jedną z kluczowych ról w konstrukcji i implementacji zarówno samych aplikacji, jak i środowiska ich pracy. Trudność rozwiązywania problemów bezpieczeństwa rosnie wraz ze skalą rozproszenia systemu i jego heterogenicznością. Dodatkowym czynnikiem, współcześnie zyskującym na wadze, są coraz częstsze przypadki realizacji przetwarzania w środowisku obejmującym różne domeny administracyjne. Rodzi to na ogół potrzebę zdefiniowania wymagań odnośnie bezpieczeństwa, niezależnie od samego przetwarzania, w postaci polityki bezpieczeństwa. Przypadek ten dotyczy w szczególności systemów rozproszonych zorientowanych na usługi, w których przetwarzanie jest realizowane przy pomocy kompozycji (o strukturze niekiedy bardzo złożonej) wielu niezależnych usług, podlegających pod oddzielne domeny administracyjne posiadające odmienne wymagania odnośnie bezpieczeństwa. Aby język definicji polityki bezpieczeństwa mógł w sposób jak najdoskonalszy wyrazić wymagania bezpieczeństwa dla środowiska, w którym usługi realizowane są na różnorodnych platformach implementujących paradygmat SOA i oferujących mechanizmy bezpieczeństwa o różnych własnościach, potrzebna jest analiza tych mechanizmów. Raport przedstawia wyniki analizy własności mechanizmów bezpieczeństwa w wybranych implementacjach architektury SOA. Analizie poddano najbardziej reprezentatywne środowiska komercyjne IBM WebSphere [6], Oracle SOA suite [10] oraz Microsoft Windows Communication Foundation (WCF [11]). Ponadto, analizą objęto technologie bazujące na języku Java powszechnie wykorzystywane również w środowiskach niekomercyjnych i open-source. Zakres analizy objął w szczególności zbiór cech istotnych dla definicji polityki bezpieczeństwa, co stanowi podstawę opracowania koncepcji i wykonania projektów metod i narzędzi środowiska do przetwarzania języka definicji polityki bezpieczeństwa zgodnego z paradygmatem SOA i zoptymalizowanego pod kątem współoperatywności w heterogenicznym systemie SOA. Treść raportu powołuje się w wielu miejscach na standardy, specyfikacje i rekomendacje WS- opisane szczegółowo w raporcie TR-ITSOA-OB7-5-PR [5]. Politechnika Poznańska /96

8 Struktura raportu Struktura raportu jest następująca. W rozdziale 2 pokrótce przedstawiono podstawową problematykę bezpieczeństwa ze szczególnym uwzględnieniem kwestii bezpośrednio związanych z architekturą SOA. W kolejnych rozdziałach przedstawiono wyniki analizy implementacji architektury SOA, tj. w kolejności IBM WebSphere (rozdział 3), Oracle SOA suite (rozdział 4) i Microsoft WCF (rozdział 5). Rozdział 6 zawiera krótkie podsumowanie analizy. Politechnika Poznańska /96

9 2. Problematyka bezpieczeństwa w architekturze SOA W tym rozdziale przybliżymy problematykę bezpieczeństwa dotyczącą SOA. Najpierw nakreślimy tę problematykę w kontekście systemów rozproszonych o ogólnej (dowolnej) architekturze (podrozdział 2.1), następnie przedstawimy przykłady praktycznych realizacji paradygmatu SOA (podrozdział 2.2) i ostatecznie wskażemy na specyfikę SOA w stosunku do systemów rozproszonych o ogólnej architekturze w kontekście bezpieczeństwa (podrozdział 2.3). 2.1 Bezpieczeństwo w systemach rozproszonych Koncepcja SOA wywodzi się wprost z systemów przetwarzania rozproszonego. Wielokrotnie już podejmowano próby skonkretyzowania ogólnej architektury środowiska rozproszonego pod kątem specyficznych zastosowań lub osiągalnych własności. Przykładowym rezultatem takiej ewolucji postrzegania przetwarzania rozproszonego, popularnym w ostatniej dekadzie jest grid. Podobnie jak grid, również SOA dziedziczy z systemów rozproszonych większość problemów dobrze rozpoznanych w dziedzinie bezpieczeństwa. Niniejszy podrozdział ma na celu przybliżyć podstawową problematykę bezpieczeństwa przetwarzania rozproszonego. Polityka bezpieczeństwa Opracowanie skutecznych zabezpieczeń jest problemem bardzo złożonym. Wymaga uwagi i systematyczności na każdym etapie. Niewątpliwie decydujące znaczenia ma etap projektowy, na którym popełnione błędy mogą być nienaprawialne w kolejnych etapach. Etap projektowy powinien rozpocząć się od wypracowania strategii firmy dotyczącej bezpieczeństwa (i to nie wyłącznie systemu informatycznego). Polega to w ogólnym schemacie na odpowiedzi na następujące pytania: 1. Co chronić? (określenie zasobów) 2. Przed czym chronić? (identyfikacja zagrożeń) 3. Ile czasu, wysiłku i pieniędzy można poświęcić na należną ochronę (oszacowanie ryzyka, analiza kosztów i zysku) Przykładowo, zasoby jakie mogą podlegać ochronie obejmują szeroki wachlarz różnorodnych składników (w zależności od typu instytucji, dziedziny działalności itp.) w tym m.in.: sprzęt komputerowy infrastruktura sieciowa strategiczne dane kopie zapasowe wersje instalacyjne oprogramowania dane osobowe dane audytu Politechnika Poznańska /96

10 zdrowie pracowników prywatność pracowników zdolności produkcyjne wizerunek publiczny i reputacja. Polityka bezpieczeństwa stanowi element polityki biznesowej firmy. Jest to formalny dokument opisujący strategię bezpieczeństwa. W uproszczeniu ujmując, jest zbiorem nakazów i zakazów określających bezpieczne korzystanie z systemu. Realizacja polityki bezpieczeństwa podlega oczywistym etapom: 1. zaprojektowanie 2. zaimplementowanie (w tym wprowadzenie mechanizmów ochrony) 3. zarządzanie (w tym monitorowanie i okresowe audyty bezpieczeństwa). Szczególnie godnym podkreślenia jest etap 3. odzwierciedlający ciągłą ewolucję jaką przechodzą działalność firmy, środowisko rynkowe jej funkcjonowania, zagrożenia i technologie obrony. Poniżej przedstawione zostaną typowe zagrożenia bezpieczeństwa oraz wybrane mechanizmy, którymi można posługiwać się w celu ochrony przed tymi zagrożeniami. Zagrożenia bezpieczeństwa Systemy informatyczne, w szczególności sieci komputerowe i systemy rozproszone, wykazują nieuchronnie pewną podatność na różnego rodzaju zagrożenia. Część z nich wynika z przypadkowych i niezamierzonych sytuacji powstających w trakcie eksploatacji coraz bardziej różnorodnego oprogramowania systemowego i aplikacyjnego w coraz bardziej skomplikowanym i heterogenicznym środowisku. Za częścią zagrożeń jednak stoi działanie z premedytacją, zmierzające do nieuprawnionego wykorzystania systemu informatycznego, przyjmujące formę ataku elektronicznego. Najczęściej spotykanymi formami ataku elektronicznego są: podszywanie (ang. masquerading) atakujący (osoba, program) udaje inny podmiot, w domyśle zaufany systemowi atakowanemu, np. fałszywy serwer www podszywa się pod znaną witrynę internetową podsłuch (ang. eavesdropping) pozyskanie danych składowanych, przetwarzanych lub transmitowanych w systemie typowy przykład: przechwycenie niezabezpieczonego hasła klienta przesyłanego do serwera powtórzenie (ang. replaying) użycie ponowne przechwyconych wcześniej danych, np. hasła manipulacja (ang. tampering) modyfikacja danych w celu zrekonfigurowania systemu lub wprowadzenia go do stanu, z którego atakujący może osiągnąć bezpośrednio lub pośrednio korzyść (np. zastosować skuteczny atak gotowym narzędziem) Politechnika Poznańska /96

11 wykorzystanie luk w systemie (ang. exploiting) posłużenie się wiedzą o znanej luce, błędzie w systemie lub gotowym narzędziem do wyeksploatowania takiej luki bardzo częste w przypadku ataków zdalnych Pod względem interakcji atakującego z atakowanym systemem wyróżniamy ataki: pasywne atakujący ma dostęp do danych (komunikacji) w systemie, mogąc je odczytać, lecz ich nie modyfikuje przykład: podsłuch komunikacji pomiędzy legalnymi użytkownikami systemu. aktywne atakujący pośredniczy w przetwarzaniu danych (komunikacji) w systemie, mogąc je nie tylko odczytać, lecz również sfałszować czy spreparować z premedytacją, tak by uzyskać zamierzony cel ataku taki atak popularnie nazywa się w języku angielskim man in the middle. Z realizacją zabezpieczeń chroniących nas przed podobnymi zagorzeniami związany jest szereg problemów. Dotyczą one m.in. asymetrii obrony i ataku (aby skutecznie zabezpieczyć system należy usunąć wszystkie słabości, natomiast aby skutecznie zaatakować wystarczy znaleźć jedną), konieczności uwzględniania kontekstu całego otoczenia celu zabezpieczeń oraz trudności utrzymania ciągłej poprawności zabezpieczeń (zarządzania i pielęgnacji). Mechanizmy ochrony W celu przedstawienia problematyki ataku i obrony należy wprowadzić definicje niezbędnych pojęć. Dotyczyć one będą w szczególności użytkowników, ale także i innych komponentów systemu. Identyfikacja (ang. identification) możliwość rozróżnienia użytkowników, np. użytkownicy są identyfikowani w systemie operacyjnym za pomocą UID (ang. user identifier) Uwierzytelnianie (ang. authentication) proces weryfikacji tożsamości użytkownika; najczęściej opiera się na tym: o o co użytkownik wie (ang. proof by knowledge), np. zna hasło co użytkownik ma (ang. proof by possession), np. elektroniczną kartę identyfikacyjną Autoryzacja (ang. authorization) proces przydzielania praw (dostępu do zasobów) użytkownikowi Kontrola dostępu (ang. access control) procedura nadzorowania przestrzegania praw (dostępu do zasobów) Poufność (ang. confidentiality) ochrona informacji przed nieautoryzowanym jej ujawnieniem Nienaruszalność (integralność; ang. data integrity) ochrona informacji przed nieautoryzowanym jej zmodyfikowaniem (ew. detekcja takiej modyfikacji) Autentyczność (ang. authenticity) pewność co do pochodzenia (autorstwa i treści) danych Politechnika Poznańska /96

12 Niezaprzeczalność (ang. nonrepudiation) ochrona przed fałszywym zaprzeczeniem o o przez nadawcę faktu wysłania danych przez odbiorcę faktu otrzymania danych Z procesem autoryzacji związane są kolejne pojęcia: Zasób (obiekt) jest jednostką, do której dostęp podlega kontroli (przykładami mogą być: programy, pliki, relacje bazy danych, czy całe bazy danych, obiekty o wysokiej granulacji: poszczególne krotki bazy danych) Podmiot jest jednostką żądającą dostępu do zasobu (przykładami mogą być: użytkownik, grupa użytkowników, terminal, komputer, aplikacja, proces) Prawa dostępu określają dopuszczalne sposoby wykorzystania zasobu przez podmiot W dowolnym modelu autoryzacji można stosować jedną z poniższych czterech możliwych filozofii: 1. Wszystko jest dozwolone. 2. Wszystko, co nie jest (jawnie) zabronione, jest dozwolone. 3. Wszystko, co nie jest (jawnie) dozwolone, jest zabronione. 4. Wszystko jest zabronione. Z praktycznego punktu widzenia w grę wchodzić mogą środkowe dwie. Jak można zaobserwować, tylko trzecia jest zgodna z zasadą minimalnego przywileju i domyślnej odmowy dostępu. W praktyce wyróżnia się dwie ogólne i skrajnie przeciwstawne metody kontroli dostępu do danych: uznaniową (DAC) i ścisłą (MAC). Istnieją też ich różne warianty jak np. kontrola oparta o role (RBAC) powszechnie spotykana np. systemach baz danych. Podstawowe własności modelu DAC są następujące: właściciel zasobu może decydować o jego atrybutach i uprawnieniach innych użytkowników systemu względem tego zasobu DAC oferuje użytkownikom dużą elastyczność i swobodę współdzielenia zasobów powszechnym zagrożeniem jest niefrasobliwość przydziału uprawnień (np. wynikająca z nieświadomości lub zaniedbań) i niewystarczająca ochrona zasobów najczęściej uprawnienia obejmują operacje odczytu i zapisu danych oraz uruchomienia programu Podstawowe własności modelu MAC są następujące: precyzyjne reguły dostępu automatycznie wymuszają uprawnienia nawet właściciel zasobu nie może dysponować prawami dostępu Politechnika Poznańska /96

13 MAC pozwala łatwiej zrealizować (narzucić) silną politykę bezpieczeństwa i konsekwentnie stosować ją do całości zasobów Ścisła kontrola dostępu operuje na tzw. poziomach zaufania wprowadzając etykiety poziomu zaufania (ang. sensitivity labels) przydzielane w zależności np. od stopnia poufności. Wobec podmiotów i zasobów w systemie MAC narzucone są niezmienne reguły, które wymusza system. Przedstawiając w uproszczeniu, reguły te stanowią iż podmiot nie może czytać danych o wyższej etykiecie (read-up) niż swoja aktualna oraz podmiot nie może również zapisywać danych o niższej etykiecie (write-down) niż swoja aktualna. Zajmiemy się teraz krótkim przedstawieniem mechanizmów stosowanych w celu osiągnięcia wybranych własności bezpieczeństwa. Poufność informacji Poufność, rozumiana jak wiemy jako ochrona przed nieautoryzowanym ujawnieniem (odczytem) informacji, narażona jest na ataki poprzez: nieuprawniony dostęp do danych w miejscu składowania w systemie, np. w bazie danych nieuprawniony dostęp do danych w miejscu przetwarzania, np. w aplikacji końcowej użytkownika podsłuchanie danych przesyłanych w sieci W celu ochrony informacji przed jej nieautoryzowanym odczytem należy przede wszystkim umieć określić czy zamierzony odczyt jest autoryzowany oraz zminimalizować prawdopodobieństwo wycieku danych poza mechanizmem kontroli dostępu (w transmisji). Zatem mechanizmy obrony stosowane do zapewnienia poufności realizować będą następujące zadania: uwierzytelnianie autoryzację i kontrolę dostępu do zasobów utrudnianie podsłuchu Omówimy kolejno problematykę wymienionych zadań i pokażemy przykłady mechanizmów, które je realizują. Uwierzytelnianie W systemach informatycznych stosuje się następujące rodzaje uwierzytelniania: 1. uwierzytelnianie jednokierunkowe polega na uwierzytelnieniu jednego podmiotu (uwierzytelnianego), np. klienta aplikacji, wobec drugiego (uwierzytelniającego) serwera. Obrazuje to Rysunek 1. Uwierzytelnienie następuje poprzez zweryfikowanie danych uwierzytelniających przekazanych przez podmiot uwierzytelniany. Typowymi danymi uwierzytelniającymi są np. identyfikator użytkownika i jego hasło dostępu. Politechnika Poznańska /96

14 dane uwierzytelniające serwer uwierzytelnia klienta klient Rysunek 1. Schemat uwierzytelniania jednokierunkowego 2. uwierzytelnianie dwukierunkowe polega na kolejnym lub jednoczesnym uwierzytelnieniu obu podmiotów (które są wzajemnie i naprzemiennie uwierzytelnianym oraz uwierzytelniającym). Obrazuje to Rysunek 2. Jeżeli wzajemne uwierzytelnianie następuje sekwencyjnie (np. najpierw klient wobec serwera, a później serwer wobec klienta), mówimy o uwierzytelnianiu dwuetapowym, natomiast jednoczesne uwierzytelnienie obu stron nazywamy jednoetapowym. serwer uwierzytelnia klienta a klient uwierzytelnia serwer Rysunek 2. Schemat uwierzytelniania dwukierunkowego 3. uwierzytelnianie z udziałem zaufanej trzeciej strony włącza w proces uwierzytelniania trzecią zaufaną stronę, która bierze na siebie ciężar weryfikacji danych uwierzytelniających podmiotu uwierzytelnianego. Po pomyślnej weryfikacji podmiot uwierzytelniany otrzymuje poświadczenie, które następnie przedstawia zarządcy zasobu, do którego dostępu żąda (serwerowi). Schemat ten pokazuje Rysunek 3. Podstawową zaletą tego podejścia jest przesunięcie newralgicznej operacji uwierzytelniania do wyróżnionego stanowiska, które można poddać zabezpieczeniu szczególnie podwyższonego poziomu. Należy też podkreślić potencjalną możliwość wielokrotnego wykorzystania wydanego poświadczenia (przy dostępie klienta do wielu zasobów, serwerów). Zaufana trzecia strona może być lokalna dla danej domeny (np. korporacyjnej) lub zewnętrzna (wykorzystująca infrastrukturę uwierzytelniania dostępną w sieci rozległej np. publiczne urzędy certyfikujące). Politechnika Poznańska /96

15 klient 1: dane uwierzytelniające 2: poświadczenie zaufana trzecia strona 3: poświadczenie serwer Rysunek 3. Schemat uwierzytelniania z udziałem zaufanej trzeciej strony W przypadku wielu współczesnych środowisk informatycznych, systemów operacyjnych lub systemów zarządzania bazami danych, funkcjonuje klasyczny mechanizm uwierzytelniania poprzez hasło. Proces uwierzytelniania rozpoczyna klient żądając zarejestrowania w systemie. Serwer pyta o identyfikator (nazwę) użytkownika, a następnie o hasło i decyduje o dopuszczeniu do sieci. W większości przypadków hasło w trakcie transmisji narażone jest na zagrożenie poufności. Stąd też takie klasyczne podejście nadaje się do wykorzystania jedynie w ograniczonej liczbie przypadków, kiedy np. mamy uzasadnioną skądinąd pewność wykluczenia możliwości przechwycenia i wykorzystania danych uwierzytelniających. hasło klient serwer Rysunek 4. Schemat klasycznego uwierzytelniania użytkownika Hasła nie są najefektywniejszą, ani najbezpieczniejszą formą weryfikacji tożsamości użytkownika, z następujących powodów: hasło można złamać: o o o odgadnąć, np. metodą przeszukiwania wyczerpującego (ang. brute-force attack) lub słownikową (ang. dictionary attack) często hasła są wystarczająco nieskomplikowane by ułatwiło to odgadnięcie ich przez atakującego podsłuchać w trakcie niezabezpieczonej transmisji wykraść z systemowej bazy haseł użytkowników zwykle hasła nie są przechowywane w systemie w postaci jawnej, często są zakodowane funkcją Politechnika Poznańska /96

16 o jednokierunkową lub zaszyfrowane, jednak niekiedy można stosunkowo łatwo jest pobrać i następnie starać się odzyskać ich oryginalną postać pozyskać inną metodą (np. kupić) hasła się starzeją czas przez który możemy z dużą pewnością polegać na tajności naszego hasła skraca się nieustannie, przez co hasła wymagają systematycznych zmian na nowe. Uwierzytelnianie jednokrotne (SSO single sign on) Procedury uwierzytelniania jednokrotnego są częściowym rozwiązaniem problemu ochrony danych uwierzytelniających przed złamaniem w systemie wielozasobowym, np. sieci komputerowej z wieloma serwerami. Ideą procedury uwierzytelniania jednokrotnego jest minimalizacja ilości wystąpień danych uwierzytelniających w systemie hasło powinno być podawana jak najrzadziej. Zgodnie z tą zasadą, jeśli jeden z komponentów systemu (np. system operacyjny) dokonał pomyślnie uwierzytelniania użytkownika, pozostałe komponenty (np. inne systemy lub zarządcy zasobów) ufać będą tej operacji i nie będą samodzielnie wymagać podawania ponownie danych uwierzytelniających. Przy tym jest możliwe teoretycznie, że wszystkie komponenty samodzielnie korzystają z odmiennych mechanizmów uwierzytelniana. Wówczas, dodatkowo po pierwszorazowym uwierzytelnieniu użytkownika, system może oddelegować specjalny moduł do przechowywania odrębnych danych uwierzytelniających użytkownika i poświadczania w przyszłości jego tożsamości wobec innych komponentów systemu. Schemat SSO przedstawia Rysunek 5. W przedstawionej na rysunku sytuacji tylko jeden serwer dokonuje uwierzytelniania klienta, reszta ufa uwierzytelnianiu dokonanemu przez ten serwer. hasło klient serwery Rysunek 5. Schemat uwierzytelniania jednokrotnego (SSO) Politechnika Poznańska /96

17 Hasła jednorazowe (OTP one time passwords) Istota wykorzystania haseł jednorazowych wynika z zamiaru ochrony ich przed przechwyceniem i nieautoryzowanym wykorzystaniem w przyszłości. Nie polega na zapewnieniu ich poufności w transmisji, lecz na uczynieniu ich de facto bezwartościowymi po przechwyceniu. Opiera się na użyciu, jak sama nazwa wskazuje, danej postaci hasła tylko raz. Hasła jednorazowe mają przy każdym kolejnym uwierzytelnieniu inną postać. Raz przechwycona postać hasła jednorazowego nie jest zatem przydatna intruzowi, bowiem przy kolejnym uwierzytelnieniu będzie obowiązywać już inna postać. Komunikacja między podmiotami procesu uwierzytelniania może być zatem zupełnie jawna. Stosujące takie hasła procedury uwierzytelniania muszą jedynie oferować brak możliwości odgadnięcia na podstawie jednego z haseł, hasła następnego. Hasła jednorazowe generowane są przy pomocy listy predefiniowanych haseł, synchronizacji czasu lub metody zawołanie-odzew (ang. challenge-response). Dostępne są najczęściej w następujących postaciach: listy papierowe, listy-zdrapki, hasła SMS-owe, tokeny programowe czy tokeny sprzętowe. Inne mechanizmy uwierzytelniania Do uwierzytelniania użytkowników można wykorzystać również przedmioty, których posiadaniem musi się wykazać uwierzytelniany. Mogą to być np. karty magnetyczne, karty elektroniczne czy tokeny USB. Ponadto, w przypadku ludzi, można posłużyć się również cechami osobowymi wynikającymi z odmienności parametrów niektórych naturalnych składników organizmu (uwierzytelnianie biometryczne). W środowisku SOA, zwłaszcza dużej skali rozproszenia, takie rozwiązania wydają się jednak mieć aktualnie ograniczone znaczenie praktyczne. Autoryzacja i kontrola dostępu do zasobów Zadania autoryzacji i kontroli dostępu legalnych użytkowników należą do podstawowych funkcji systemów operacyjnych czy systemów zarządzania bazą danych oraz środowisk przetwarzania rozproszonego. W większości przypadków te funkcje są realizowane podobnie. Aktualnie jednym z najczęściej stosowanych mechanizmów weryfikacji praw dostępu jest lista kontroli dostępu, której implementacje, w zależności od konkretnego systemu, noszą nazwy ACL (ang. Access Control List), ARL (ang. Access Rights List) lub Trustees. Ogólna koncepcja działania mechanizmu listy kontroli polega na wyspecyfikowaniu dla każdego udostępnianego zasobu listy indywidualnych podmiotów lub ich grup (ról) bądź kategorii oraz przydzieleniu im podzbiorów uprawnień wybranych ze zbioru wszystkich uprawnień dostępnych dla danego zasobu. Nienaruszalność informacji (integralność) Kolejnym po poufności aspektem bezpieczeństwa omawianym w tym rozdziale jest nienaruszalność informacji, rozumiana jako ochrona danych przed ich nieautoryzowanym zmodyfikowaniem (dostępem do zapisu, w odróżnieniu od poufności, która oznacza ochronę przed nieautoryzowanym dostępem do odczytu). Politechnika Poznańska /96

18 B Nowe technologie informacyjne dla elektronicznej gospodarki i społeczeństwa informacyjnego oparte na paradygmacie SOA Zagrożeniem nienaruszalności informacji jest zatem celowa lub przypadkowa modyfikacja danych przez nieuprawnionych użytkowników bądź oprogramowanie (np. wirusowe). Mechanizmy obrony stosowane do zapewnienia nienaruszalności informacji obejmują w szczególności: kontrolę dostępu do danych wymienione wcześniej mechanizmy list kontroli dostępu kryptograficzne sumy kontrolne i podpis elektroniczny rejestrację operacji na danych (auditing) niezbędną dla formalnego wykrycia naruszeń integralności; zwykle spotyka się podział danych audytu co najmniej na rejestr zdarzeń systemowych oraz rejestr zdarzeń aplikacji. Mechanizmy kryptograficzne Mechanizmy kryptograficzne są powszechnie wykorzystywane w dziedzinie bezpieczeństwa systemów komputerowych. Stanowią bardzo uniwersalne narzędzie osiągania poufności, integralności czy autentyczności, są stosowane w procedurach uwierzytelniania, do ochrony danych składowanych i komunikacji sieciowej. Należą niewątpliwie do najważniejszych mechanizmów bezpieczeństwa. Kryptografia jest dziedziną obejmująca zagadnienia związane z utajnieniem danych (w kontekście przesyłania wiadomości i zabezpieczenia dostępu do informacji) przed niepożądanym dostępem. Przez utajnienie należy tu rozumieć taką operację, która powoduje że wiadomość jest trudna do odczytania (rozszyfrowania) przez podmiot nie znający tzw. klucza rozszyfrowującego dla takiego podmiotu wiadomość będzie wyłącznie niezrozumiałym ciągiem wartości (znaków). Dane, które poddawane będą operacjom ochrony kryptograficznej nazywać tu będziemy po prostu tekstem jawnym lub wiadomością czytelną. Kryptogramem (szyfrogramem) będziemy nazywali zaszyfrowaną postać wiadomości czytelnej. Klucz szyfrowania to ciąg danych służących do szyfrowania wiadomości czytelnej w kryptogram za pomocą algorytmu szyfrowania. Klucz ten jest odpowiednio ustalany (uzgadniany) przez nadawcę w fazie szyfrowania. Klucz rozszyfrowujący jest z kolei ciągiem danych służących do rozszyfrowania kryptogramu do postaci wiadomości czytelnej za pomocą algorytmu deszyfrowania. Naturalnie, klucz ten odpowiada w pewien sposób kluczowi szyfrowania wykorzystanemu w fazie szyfrowania. Szyfry najczęściej spotykane współcześnie w systemach informatycznych opierają swą siłę nie na tajności samego algorytmu lecz jedynie na tajności zmiennego parametru tego algorytmu, jakim jest klucz. Rysunek 6 przedstawia ogólny schemat szyfrowania z użyciem klucza. Użytkownicy uczestniczący w komunikacji, na tym schemacie Alicja oraz Bolek, posługują się swoimi kluczami, odpowiednio K A oraz K B. Aby przesłać zaszyfrowaną wiadomość do Bolka, Alicja poddaje szyfrowaniu wiadomość czytelną M z użyciem klucza szyfrowania KA operacją E KA [M] uzyskując szyfrogram S. Następnie szyfrogram S jest przesyłany do Bolka, który poddaje go operacji D KB [S] rozszyfrowania z kluczem K B. Politechnika Poznańska /96

19 ALICJA wiadomość czytelna E[] zaszyfrowanie metoda + klucz szyfrogram rozszyfrowanie metoda + klucz M S M D[] wiadomość czytelna BOLEK K A K B Rysunek 6. Schemat ogólny szyfrowania z kluczem Mechanizmy szyfrowania z kluczem spełniają zatem własność: D KB [E KA [M]] = M. W przypadku szyfrowania z kluczem spotykane są dwa schematy: szyfrowanie symetryczne i asymetryczne. Szyfrowanie symetryczne Szyfrowanie symetryczne jest schematem, w którym występuje wspólny dla obu uczestników komunikacji tajny klucz K A-B (dalej oznaczany po prostu K). Własność szyfrowania symetrycznego ma zatem postać: D K [E K [M]] = M. BOLEK ALICJA M SZYFRO- WANIE K S DESZYFRO- WANIE K M Rysunek 7. Ogólny schemat szyfrowania symetrycznego Szyfrowanie symetryczne jest o tyle ciekawe, że wymaga posłużenia się tylko jednym kluczem, dla obu uczestników komunikacji i w obu jej kierunkach (choć można wyobrazić sobie wariant tego schematu z oddzielnym kluczem na każdy kierunek). Uczestników takiej komunikacji może oczywiście być więcej niż dwoje i wówczas cała grupa może posługiwać się wspólnym kluczem. Jednak w typowym przypadku komunikacji w pojedynczym kanale komunikacyjnym łączącym tylko dwoje uczestników, pojedynczy klucz przypisany jest wyłącznie do jednej pary użytkowników i musi on być utajniony wobec innych podmiotów. Konieczność utrzymania tajności klucza w obrębie jednej pary użytkowników rodzi szereg praktycznych problemów: tożsamość problemu poufności wiadomości z problemem tajności klucza wiadomość jest bezpieczna dopóki osoba trzecia nie pozna tajnego klucza K Politechnika Poznańska /96

20 B Nowe technologie informacyjne dla elektronicznej gospodarki i społeczeństwa informacyjnego oparte na paradygmacie SOA problem dystrybucji klucza jak uzgodnić wspólny klucz bez osób trzecich, będąc oddalonym o setki, a nawet tysiące kilometrów? problem skalowalności dla 2 komunikujących się w systemie osób wymagane jest przechowywanie przez każdą z nich 1 klucza; dla 3 osób 3 kluczy (przez każdą osobę); 4 os. = 6 kluczy; 10 os. = 45 kluczy; 100 os. = 4950 kluczy;... tajność klucza nie zapewnia autentyczności nie można wykazać formalnie która z dwóch stron jest rzeczywistym autorem wiadomości, skoro obie posługują się tym samym kluczem. Szyfrowanie asymetryczne Istotą szyfrowania asymetrycznego jest wyodrębnienie dwóch kluczy o odmiennych rolach: klucz prywatny i klucz publiczny. I tak przyjmiemy dalej iż odbiorca Bolek posiada parę kluczy: prywatny klucz k b oraz publiczny klucz K. B Z założenia klucz prywatny jest tajny i znany wyłącznie właścicielowi. Publiczny klucz, natomiast, może być powszechnie znany. Aby przekazać zaszyfrowaną postać wiadomości do tego odbiorcy należy zaszyfrować wiadomość czytelną jego kluczem publicznym. Odszyfrowanie jest możliwe tylko przy użyciu klucza prywatnego, odpowiadającego użytemu uprzednio kluczowi publicznemu. Operacje szyfrowania opisuje zatem ogólny wzór: E KB [M] = S, a deszyfrację: Dk b [S] = M. ALICJA SZYFRO- WANIE DESZYFRO- WANIE BOLEK K B k b Rysunek 8. Ogólny schemat szyfrowania asymetrycznego Istotne jest, iż znajomość klucza publicznego K B nie wystarcza do naruszenia poufności kryptogramu uzyskanego przy zastosowaniu tego klucza. Szyfrowanie asymetryczne idealnie nadaje się do zastosowania w następujących celach: zapewnienie poufności (Rysunek 9) tylko posiadacz klucza prywatnego może deszyfrować kryptogram Politechnika Poznańska /96

21 ALICJA SZYFRO- WANIE DESZYFRO- WANIE BOLEK K B kb Rysunek 9. Ogólny schemat zapewnienia poufności w szyfrowaniu asymetrycznym zapewnienie autentyczności (Rysunek 10) wykorzystujemy tu własność przemienności kluczy jedynie autor wiadomości mógł posłużyć się swoim kluczem prywatnym, co można zweryfikować przy użyciu jego klucza publicznego ALICJA SZYFRO- WANIE DESZYFRO- WANIE BOLEK k a K A Rysunek 10. Ogólny schemat zapewnienia autentyczności w szyfrowaniu asymetrycznym Szyfrowanie asymetryczne można wykorzystać do osiągnięcia własności autentyczności wiadomości przy zastosowaniu skrótu wiadomości, o stałym rozmiarze, niezależnie od wielkości wiadomości. Podpis cyfrowy Funkcje skrótu można wykorzystać do zrealizowania ciekawego i niezwykle ważnego narzędzia, jakim jest podpis cyfrowy. Najczęściej wykorzystywana jest w tym celu jest funkcja mieszająca HMAC z kluczem k asymetrycznym (ang. keying hash function) h k [M]. Wartość skrótu HMAC jest zaszyfrowana kluczem prywatnym nadawcy, być może dodatkowo z wykorzystaniem ziarna (ang. salt) lub zawołania (ang. challenge). Proces generowania i weryfikowania podpisu HMAC z kluczem przedstawia Rysunek 11. Nadawca (Alicja) po przygotowaniu wiadomości M przygotowuje jej skrót H, który poddaje szyfrowaniu swoim kluczem prywatnym, który z założenia zna i posiada tylko nadawca. Po połączeniu M z zaszyfrowanym skrótem H' całość przekazuje do odbiorcy dowolnym kanałem komunikacyjnym. Tan następuje deszyfracja H' (przy użyciu otwarcie dostępnego klucza publicznego nadawcy) oraz niezależne wyliczenie skrótu H dla otrzymanego M. Porównanie H wyliczonego z odszyfrowanym wskazuje na autentyczność i nienaruszalność wiadomości M lub jej brak. Gdyby M została zmodyfikowana w trakcie transmisji do odbiorcy, wyliczony skrót nie pasowałby do odszyfrowanego z H'. Natomiast, gdyby nadawcą nie była Alicja, posłużenie się jej kluczem publicznym przy odszyfrowaniu H' nie dałoby skrótu identycznego z wyliczony przez odbiorcę H. Politechnika Poznańska /96

22 BOLEK ALICJA M M M skrót HMAC + H =? H SZYFRO- WANIE H' DESZYFRO- WANIE H k a K A Rysunek 11. Zastosowanie funkcji skrótu Możliwe jest jednoczesne osiągnięcie własności poufności, autentyczności i nienaruszalności wiadomości. Uzyskuje się to poprzez znane już szyfrowanie (np. asymetryczne) pary M + H' z poprzedniego przykładu, przed przesłaniem do odbiorcy. Przy tym szyfrowaniu musi oczywiście być wykorzystany odpowiedni klucz publiczny odbiorcy. Schemat ten przedstawia Rysunek 12. ALICJA BOLEK k a M k b K A K B H E k a[ H] = H' E KB [M + H'] = S D kb [S] = M + H' M H ' S M H ' D KA [H'] = H H = H Rysunek 12. Osiąganie poufności, autentyczności i nienaruszalności Schemat szyfrowania asymetrycznego, dzięki wykorzystaniu powszechnej jawności klucza publicznego, uwalnia nas od problemu dystrybucji klucza znanego z szyfrowania symetrycznego. Należy zwrócić uwagę, iż występuje tu jednak nowy problem związany z dystrybucją kluczy, bowiem w ogólności istnieje ryzyko podstawienia przez nieuczciwą osobę (atakującego) fałszywego klucza pod klucz publiczny domniemanego użytkownika. Rozwiązaniem tego problemu, które zyskało dotychczas największą akceptację jest certyfikacja kluczy publicznych. Politechnika Poznańska /96

23 Certyfikaty elektroniczne Certyfikat jest poświadczeniem autentyczności podpisanym przez osobę (instytucję) godną zaufania, nazywaną urzędem poświadczającym CA (Certification Authority). Certyfikat ma najczęściej formę dokumentu elektronicznego. Certyfikacja pozwala m.in. uniknąć ryzyka podstawienia fałszywego klucza publicznego. Certyfikat zawiera podstawowe dane identyfikujące właściciela. W ogólnym przypadku, urząd poświadczający CA potwierdza, iż informacja opisująca właściciela klucza jest prawdziwa, a klucz publiczny faktycznie do niego należy. Certyfikat posiada też okres ważności wyznaczający czas przez który certyfikowane dane można uważać za poprawne. Niezależnie od okresu ważności certyfikowane klucze mogą zostać uznane za niepoprawne, np. gdy zaistnieje podejrzenie, iż ktoś nieuprawniony wszedł w posiadanie tajnego klucza prywatnego, odpowiadającego certyfikowanemu kluczowi publicznemu. Urząd poświadczający CA musi przechowywać listę niepoprawnych i nieaktualnych certyfikatów. Oczywiście, unieważnienie klucza jest także rodzajem certyfikatu. Struktura podstawowa typowego certyfikatu jest przedstawiona schematycznie na rysunku 13. Oprócz wymienionych tam pól poszczególne certyfikaty mogą zawierać dodatkowe, specyficzne dla konkretnego urzędu CA lub zastosowań, do których certyfikaty są przeznaczone. Przykłady rzeczywistych certyfikatów możemy znaleźć w każdej przeglądarce internetowej. Wersja Numer seryjny Identyfikator algorytmu (algorytm, parametry) Wystawca Okres ważności Podmiot Klucz publiczny podmiotu Podpis informuje o kolejnych wersjach certyfikatu unikalny numer certyfikatu algorytm podpisu cyfrowego i typ parametrów urząd certyfikujący CA, który wystawił certyfikat początkowa i końcowa data ważności certyfikatu nazwa podmiotu, dla którego stworzono certyfikat klucz publiczny podmiotu z identyfikatorem algorytmu i wartościami parametrów podpis urzędu certyfikującego CA Rysunek 13. Schematyczna struktura typowego certyfikatu Jednym z najpopularniejszych współcześnie rodzajów certyfikatów są te zgodne ze standardem ITU-T X.509. Budowa certyfikatu X.509 v.3 obejmuje szereg elementów. Należą do nich: struktura podstawowa uzupełniona o zestaw danych identyfikacyjnych podmiotu certyfikatu Politechnika Poznańska /96

24 sposób wykorzystania klucza (przeznaczenie, np. do szyfrowania danych, do szyfrowania kluczy, do uzgadniania kluczy, do podpisywania danych, do osiągnięcia niezaprzeczalności) informacje o polityce certyfikacji wydawcy certyfikatu (np. ograniczenia długości ścieżki certyfikacji, punkty dystrybucji list certyfikatów unieważnionych). Ponadto istnieje opcjonalna możliwość tworzenia dodatkowych pól / parametrów identyfikacyjnych, wg potrzeb komunikujących się podmiotów. Dystrybucja kluczy przy wykorzystaniu certyfikatów przebiega następująco: w celu uzyskania certyfikatu użytkownik zwraca się do urzędu certyfikującego CA dostarczając mu swój klucz publiczny do zweryfikowania certyfikatu niezbędny jest tylko i wyłącznie klucz publiczny urzędu certyfikującego alternatywnie użytkownik może przesłać swój certyfikat do innych użytkowników z prośbą o poświadczenie jego autentyczności. W tym ostatnim przypadku mówimy o systemie wzajemnej certyfikacji (sieci wzajemnego zaufania, ang. web of trust). Certyfikat użytkownika, dajmy na to Alicji, poświadcza (podpisuje) z reguły kilku (kilkunastu) użytkowników. Jeśli po pobraniu przez Bolka, stwierdza on, że wśród podpisów znajdują się jakieś należące do zaufanych mu osób, uznaje on certyfikat za poświadczony. W każdym przypadku istnieje dylemat, komu na tyle zaufać, aby mógł być on w pełni wiarygodny i poświadczać (wydawać) certyfikaty? Problem ten dotyczy przede wszystkim pierwszego kontaktu, zwłaszcza w relatywnie anonimowej sieci globalnej Internet. Skąd zatem pewność, że certyfikat został pobrany z właściwego urzędu, czy że podpisy poświadczające jego autentyczność rzeczywiście są godne zaufania. ile może istnieć instytucji cieszących takim zaufaniem, iż certyfikaty przez nie podpisane możemy śmiało uznawać za rzetelnie zweryfikowane i autentyczne. Rozwiązaniem tego problemu jest system, w którym certyfikat musi przebyć pewną (często kilkuetapową) procedurę uwierzytelniającą, a urzędy CA mogą tworzyć wielopoziomową hierarchię. Urzędy danego poziomu hierarchii wystawiają certyfikaty kluczy publicznych urzędom lub użytkownikom znajdującym się na niższym poziomie. Na szczycie znajduje jeden z nielicznych urzędów centralnych, który swym powszechnie uznanym autorytetem ostatecznie poświadcza poprawność całej procedury uwierzytelniającej certyfikat. Taka hierarchia urzędów poświadczających jest podstawą funkcjonowania niezwykle ważnego współcześnie mechanizmu informatycznego infrastruktury kluczy publicznych PKI (ang. Public Key Infrastructure). Infrastruktura kluczy publicznych obejmuje sprzęt, oprogramowanie, ludzi, polityki bezpieczeństwa i procedury konieczne do utworzenia, zarządzania, przechowywania, dystrybucji i unieważniania certyfikatów kluczy publicznych w skali najczęściej ogólnonarodowej lub światowej. PKI oferuje często dodatkowe certyfikaty, np. Certyfikaty Znacznika Czasu (dla wiarygodnego potwierdzania czasu). W sieci Internet, PKI wykorzystuje specyfikację X.509 (PKIX, RFC 2459 [59]). Politechnika Poznańska /96

25 Mechanizmem pobierania certyfikatów CA powszechnie uznanym za standardowy jest przekazywanie ich jako typ MIME application/x-x509-ca-cert. 2.2 Architektura SOA i jej realizacje Architektura SOA to paradygmat tworzenia rozproszonych aplikacji w formie usług (serwisów) w luźno powiązanym środowisku rozproszonym obejmującym wiele różnych domen. Serwis jest abstrakcyjną jednostką, która reprezentuje pewną funkcjonalność (lub zasoby) i komunikuje się poprzez wysyłanie i odbieranie wiadomości. Udostępnienie serwisu dla klientów sprowadza się do dostarczania interfejsu, czyli opisu funkcji i ograniczeń związanych z polityką bezpieczeństwa oraz wymagań dotyczących każdej interakcji zarówno żądań dostępu do serwisu jak i jego odpowiedzi. Niezbędne jest, aby forma tych informacji zarówno syntaktyczna jak i semantyczna, była szeroko dostępna i zrozumiała. Klient odwołuje się tylko do interfejsu danego serwisu całkowicie abstrahując od jego implementacji, a komunikacja jest sterowana serią interakcji. Oczywiście, odpowiednia polityka zawierać będzie (lub przynajmniej powinna) zbiór ograniczeń i wymagań dotyczących interakcji SOA. Polityka dotyczyć może w istocie wielu aspektów SOA, zarówno biznesowych jak i technicznych. Należą do nich między innymi: zarządzanie i nadzorowanie systemu, bezpieczeństwo i ochrona, gwarancja jakości usług, godziny pracy i wiele innych. Podczas gdy lokalna polityka bezpieczeństwa opisuje punkt widzenia każdej ze stron biorących udział w komunikacji, kontrakt określa wspólne uzgodnienia obu stron interakcji dotyczące nawiązywania połączenia, ustalone w zakresie wyspecyfikowanym przez ich polityki bezpieczeństwa (lub globalną politykę). Na kontekst interakcji składa się zatem zestaw informacji na temat jednostek interakcji, aspektów technicznych połączenia (infrastruktury) i zawartego kontraktu. Usługi w architekturze SOA muszą zachowywać następujące własności paradygmatu SOA, w szczególności: wysoką współoperatywność, niezależnie od możliwej wielorakości środowisk i technologii implementacji poszczególnych usług, niezależność od infrastruktury komunikacyjnej przy zachowaniu zgodności z szerokim zakresem dotychczas przyjętych standardów komunikacji, zarządzania, opisu interfejsów, realizacji polityki itp., możliwość budowania złożonych aplikacji (usług) poprzez kompozycję usług elementarnych, dając w efekcie zagnieżdżenie interakcji, być może wielopoziomowe, integrację luźno powiązanych aplikacji w szerokiej skali rozproszenia i orkiestrację procesów realizowanych w środowisku obejmującym potencjalnie wiele odrębnych domen administracyjnych. Własności te stanowią wyróżnik technologii implementujących usługi SOA również w kontekście bezpieczeństwa. Politechnika Poznańska /96

26 Web Services Paradygmat SOA jest obecnie powszechnie implementowany poprzez zbiór technologii określanych wspólnie jako Web Services (WS). Architektura Web Services [12] dostarcza koncepcyjnego modelu realizacji usług WS i definiuje relacje pomiędzy komponentami danego modelu. Społeczność WS (w tym w szczególności organizacje W3C, OASIS czy WS-I) dostarcza standardy i profile służące tworzeniu współoperatywnych aplikacji WS działających na różnych platformach. Przykładowo, przyjmuje się że interfejs serwisu WS jest opisany w formacie WSDL [15], a komunikacja odbywa się poprzez protokół SOAP [16] bazujący na składni XML [13], w połączeniu z innymi standardowymi mechanizmami WWW. Język XML oferuje standardowy, elastyczny format danych, kluczowy dla technologii WS. Z kolei protokół SOAP dostarcza standardowych mechanizmów do wymiany wiadomości XML. Natomiast WSDL dostarcza opisu interfejsu serwisu łącznie z abstrakcyjnym opisem wymiany wiadomości pomiędzy agentami (aplikacjami) i powiązaniem z konkretnym protokołem transportowym oraz formatem wiadomości. Koncepcja WS jest pewnym rozwinięciem modelu usługi WWW, alternatywnym wobec REST (REpresentation State Transfer [18]). Model WWW (a z nim i REST) narzuca tylko kilka ograniczeń dotyczących komunikacji: obiekty w systemie identyfikowane są poprzez unikalny adres URI (Uniform Resource Identifiers), zasoby mogą być reprezentowane poprzez różnorodne, powszednie rozumiane formaty danych (XML, HTML, CSS itp.) oraz komunikacja odbywa się poprzez protokoły wykorzystujące adresy URI do identyfikacji zarówno bezpośrednich jak i pośrednich adresów usług i zasobów (HTTP, FTP, SMTP, JMS, IIOP itd.). SOA w technologii Java Technologia Java jest powszechnie znanym i często wykorzystywanym przykładem środowiska programistycznego i wykonawczego dla przenośnych aplikacji. W kontekście heterogenicznych środowisk rozproszonych okazuje się być cenionym zarówno przez platformy komercyjne, jaki i niekomercyjne źródłem wsparcia w konstrukcji usług, zgodnego z paradygmatem SOA i modelem WS (i również REST). Komponenty SOA środowiska Apache Serwer aplikacji Apache jest przykładem środowiska oferującego produkty implementujące podstawowe składniki architektury SOA w technologii Java. Historycznie pierwszym popularnym produktem z rodziny jest Apache Tomcat [43]. Jest to serwer aplikacji rozwijany przez Apache Software Foundation jako środowisko otwarte na licencji Apache Software License. Tomcat jest w istocie implementacją technologii serwletów [44] oraz JavaServer Pages (JSP [45]). Tomcat zawiera jednak wyspecjalizowane komponenty obsługujące XML i protokół SOAP, dzięki czemu oferuje możliwość realizacji usług WS. Apache Axis [41], to przykładowa otwarta implementacja protokołu SOAP oraz specyfikacji SOAP Messages with Attachments, będąca następcą Apache SOAP (historycznie pierwszej implementacji protokołu SOAP w ramach projektu Apache). Axis jest powszechnie używany do oprogramowania komunikacji usług webowych, które następnie są wdrażane jako aplikacje serwera Tomcat. Politechnika Poznańska /96

27 Wersja Axis2 zapewnia m.in.: wsparcie dla SOAP 1.2, WSDL 2.0 wsparcie dla WS-Addressing, WS-RM, WS-Security, WS-SecureConversation wsparcie dla stylu architektonicznego REST rozszerzalność poprzez mechanizm Add-ons GlassFish i Metro GlassFish [48] to otwarty serwer aplikacji Java EE 5 rozwijany przez GlassFish Community. Platforma Java EE 5 zawiera w sobie implementacje m.in. takich technologii jak: JavaServer Pages, JavaServer Faces (JSF), Servlet, Enterprise JavaBeans, Java API for Web Services (JAX-WS), Java Architecture for XML Binding (JAXB), Web Services Metadata for the Java Platform. Ponadto GlassFish w nadchodzącej (najprawdopodobniej wraz z Java EE 6) wersji 3 ma oferować mechanizmy umożliwiające łatwą migrację usług z Apache Tomcat. Metro [49] to stos protokołów, rozwijany przez GlassFish Community, zawierający m.in. implementacje następujących standardów związanych z SOA: Java API for XML Processing (JAXP) Java API for XML-based RPC (JAX-RPC) Java API for Web Services (JAX-WS) Java API for XML Messaging (JAXM) SOAP with Attachments API for Java (SAAJ) Java Authentication and Authorization Service (JAAS) Java bindings of the General Security Services (JGSS) API Java Secure Socket Extension (JSSE) Ponieważ komponenty te mają istotne znaczenie dla realizacji usług zgodnych z modelem SOA, ich funkcje zostaną krótko przeanalizowane poniżej. Politechnika Poznańska /96

28 JAXP JAXP (Java API for XML Processing [50]) to jeden z interfejsów programowania aplikacji dla XML opracowany przez Sun Microsystems. JAXP pozwala aplikacjom na analizę składniową (ang. parsing), transformację, walidację a także stosowanie zapytań dla dokumentów XML z użyciem API niezależnego od poszczególnych implementacji procesorów XML. JAXP oferuje mechanizm wtyczek umożliwiający niezależnym producentom udostępnianie własnych modułów programowych. JAXP jest standardowym komponentem platformy Java J2SE (Java Platform, Standard Edition) 5.0 zawiera implementację JAXP w wersji 1.3, natomiast Java SE 6.0 zawiera implementację JAXP 1.4. Trzy główne interfejsy analizy składniowej oferowane przez JAXP to: interfejs DOM (Document Object Model), interfejs SAX (Simple API for XML), interfejs StAX (Streaming API for XML) dodany w JAXP 1.4. W kontekście SOA szczególnie istotne są oczywiście ostatnie 2 interfejsy. Dodatkowo, JAXP udostępnia interfejs XSLT (Extensible Stylesheet Language Transformations) pozwalający na dowolne transformacje struktur i danych z dokumentów XML do innych formatów reprezentacji danych. JAX RPC / JAX WS JAX-RPC (Java API for XML-Based RPC [51]) to kolejny z interfejsów programistycznych języka Java firmy Sun Microsystems. Specyfikacja JAX-RPC definiuje podstawową funkcjonalność wywołania usług (środowiska Java). Wersja rozszerzona JAX- RPC 2.0 została przemianowana na JAX-WS 2.0 (Java API for XML Web Services [52]), jako że istotnie oferuje obsługę interakcji zgodnych z modelem WS. Stanowiący rdzeń tego projektu Metro JAX-WS Reference Implementation Project wspiera następujące standardy i specyfikacje: JAXM JAX-WS 2.0/2.1 (JSR 224), WS-I Basic Profile 1.1, WS-I Attachments Profile 1.0, WS-I Simple SOAP Binding Profile 1.0, WS-Addressing Core, SOAP Binding, WSDL Binding. JAXM (Java API for XML Messaging) również należy do interfejsów programowania aplikacji z grupy Java XML APIs. JAXM obsługuje komunikację point-to-point z użyciem formatu XML, stanowiąc API pozwalające budować wiadomości SOAP. API zawarte w pakiecie javax.xml.soap pozwala m.in. na: tworzenie i konsumpcję wiadomości SOAP dodawanie i wyodrębnianie zawartości nagłówka wiadomości SOAP Politechnika Poznańska /96