Ramy Interoperacyjności Systemów Administracji Publicznej RISA. (Connected Government Framework) 2009, Microsoft Corporation

Transkrypt

1 Ramy Interoperacyjności Systemów Administracji Publicznej RISA (Connected Government Framework) 2009, Microsoft Corporation

2

3 Spis treści Wprowadzenie... 6 Struktura biznesowa RISA... 6 Co to jest e-administracja?... 6 Interoperacyjnośd w administracji... 6 Europejskie Ramy Interoperacyjności... 7 Integracja semantyczna, integracja danych Integracja aplikacji, integracja systemów Broker RISA Jedno okienko Wymagania systemów administracji Powszechne problemy dotyczące architektury Złożonośd zagadnienia Zapewnienie dostępu do stale rozszerzającego się zakresu funkcji Różnorodnośd kanałów dostępu Szerokie wsparcie różnorodnych platform klienckich Obsługa wielu języków i wszechstronny dostęp Obsługa wielu różnych poświadczeo tożsamości Udostępnienie każdej z usług dla sektora publicznego w spójny i bezpieczny sposób Zarządzanie tożsamością Pojedyncze poświadczenia do dostępu do wielu usług Spójne logowanie a pojedyncze logowanie Odwzorowywanie tożsamości Trudne przypadki Początkowa identyfikacja użytkowników Problemy integracji Różne możliwości integracji Wspólne rozwiązanie integracyjne Elastycznośd i sprawnośd Dlaczego elastycznośd i sprawnośd są tak ważne Tworzenie architektury z myślą o elastyczności Zabezpieczanie rozwiązania Dlaczego bezpieczeostwo jest tak ważne? Projektowanie bezpiecznych rozwiązao Skalowalnośd, wydajnośd, dostępnośd Dostępnośd i odpornośd Odtwarzanie po awariach Konstrukcja wspólnego huba Potrzeba ustalenia właściciela lub finansującego Początkowa inwestycja z odroczonymi korzyściami Typowe konflikty z projektami indywidualnymi Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego Reguły rządzące architekturą Orientacja na usługi Interfejsy i standardy Wyszukiwanie usług Stowarzyszone funkcje zabezpieczeo Elastycznośd Bezpieczeostwo Skalowalnośd i wydajnośd Hub usług Kontekst i interakcje zewnętrzne huba Usługi świadczone przez hub Możliwe topologie Usługi zarządzania tożsamością Podstawowy model tożsamości i zasady Początkowe zgłaszanie użytkowników Zarządzanie użytkownikami i rejestracjami Usługi uwierzytelniania i autoryzacji Uwierzytelnianie Autoryzacja Usługa tokenów bezpieczeostwa Udostępnianie usług uwierzytelniania i autoryzacji Usługa katalogu usług UDDI Usługi rejestracji dokumentów Rola usługi rejestracji dokumentów Podstawowa architektura... 75

4 Format komunikatów Załączniki komunikatów Bezpieczeostwo komunikatów Walidacja komunikatu Magazyn komunikatów Routing komunikatów Niezawodne dostarczanie komunikatów Obsługa transakcji Orkiestracja procesów biznesowych Procesy biznesowe w hubie usług Integracja z usługami zaplecza Przekazywanie dokumentów do zainteresowanych stron Komunikacja z systemami zaplecza Bezpieczeostwo Ogólne sposoby podejścia do problemu bezpiecznej architektury rozwiązania Zagadnienia bezpieczeostwa specyficzne dla architektury systemów dla sektora publicznego Wydajnośd i skalowalnośd Planowanie wydajności Czynniki mające wpływ na wydajnośd systemu Projektowanie wydajnej i skalowalnej architektury rozwiązao dla sektora publicznego Zarządzanie i eksploatacja Wprowadzenie Architektura zarządzania Struktura leżąca u podstaw architektury zarządzania Logiczny układ architektury przedsiębiorstwa Architektura zarządzania MSM Narzędzia administracyjne Dodatkowe zasoby Elementy składowe typowego rozwiązania integracyjnego dla sektora publicznego Wprowadzenie Zarządzanie tożsamością Uwierzytelnianie Autoryzacja Zapewnienie dostępu do usługi U&A za pośrednictwem interfejsu usług sieciowych Hub komunikacyjny Funkcje Projekt Skalowalnośd i wysoka dostępnośd Zagadnienia związane z bezpieczeostwem Hub integracyjny Funkcje Projekt Czynniki do rozważenia podczas integracji z systemami zaplecza Wskazówki dotyczące implementacji Wykorzystywanie dokumentu elektronicznego i podpisów elektronicznych Podstawy prawne dokumentu elektronicznego Dokument elektroniczny i dokument papierowy Interoperacyjnośd systemów administracji samorządowej z rejestrami centralnymi i Elektroniczną Platformą Administracji Publicznej Podstawy podpisów elektronicznych XML Wady i zalety stosowania podpisów elektronicznych dla dokumentów XML w projektach dla administracji publicznej Podpisanie dokumentu XML Weryfikacja podpisu elektronicznego Wybrane akty prawne Standardy Uwarunkowania wynikające z KPA RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 4

5 Microsoft Sp. z o.o. kontakt Al. Jerozolimskie 195a Warszawa tel. (22) , fax: (22) NIP ; KRS Sąd Rejonowy dla m.st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego Kapitał zakładowy zł RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 5

6 Wprowadzenie Pierwsza częśd niniejszego opracowania Struktura biznesowa RISA dotyczy zagadnieo budowy założeo integracji aplikacji dla administracji publicznej (AP). Powstała przede wszystkim w oparciu o posiadane przez Microsoft doświadczenie w zakresie specyfikowania i tworzenia rozbudowanej architektury zorientowanej na usługi i w szczególności o doświadczenie w prowadzeniu projektów dla administracji publicznej w skali całego kraju. Opisano w niej charakterystykę orientacji na usługi oraz zaproponowano sposób definiowania usług biznesowych na podstawie wymagao biznesowych. Przedstawiono podstawowe zasady projektowania systemów dla AP oraz zaproponowano zestaw komponentów i usług biznesowych niezbędnych do utworzenia zorientowanego na obywatela systemu dokumentacji. Przedstawiono także różne pomysły na udostępnienie istniejących aplikacji w postaci usług. W dokumencie poruszono także temat wdrażania pakietów aplikacji w skali całego kraju. W ramach koncepcji Ram Interoperacyjności Systemów Administracji Publicznej - RISA (Connected Government Framework CGF) zajmiemy się najważniejszymi problemami związanymi z architekturą techniczną rozwiązao dla sektora publicznego (interoperacyjności techniczną), obszarami, które wymagają szczególnego potraktowania a często, przynajmniej na początkowych etapach projektu, umykają uwadze i możliwymi wariantami rozwiązao oraz opiszemy zalecany sposób rozwiązywania tych problemów. Oprócz omówienia problemów zwykle spotykanych w wielkoskalowych projektach informatycznych i integracyjnych, szczególny nacisk położymy na najważniejsze problemy charakterystyczne dla rozwiązao dla sektora publicznego. Jednocześnie na bazie doświadczeo krajów, w których elektroniczna forma komunikacji z administracją jest szeroko dostępna ale wykorzystywana tylko przez niektórych interesantów (Wielka Brytania notuje wskaźnik w tym zakresie na poziomie 25-30%) zajmiemy się takimi propozycjami, które będą mogły wesprzed usługi świadczone drogą klasyczną. Struktura biznesowa RISA Co to jest e-administracja? Proponujemy następującą definicję e-administracji: wszystko, co ma postad cyfrową (produkty, systemy, usługi), jest przydatne do celów świadczenia usług przez administrację, łatwośd dokumentowania, wymiany informacji, dostarczania usług, regulowane przez określone przepisy administracyjne i prawne oraz zasady etyczne. Obecna wartośd dodana e-administracji, to zwiększenie produktywności istniejących systemów AP. W przyszłości jednak e-administracja stanie się szkieletem systemów usług ukierunkowanych na obywatela. Interoperacyjnośd w administracji W serii esejów, kanadyjski profesor Denis J. Protti zawarł następujące spostrzeżenia: Cyfrowa era przeobraża nasz świat. Jak pisał Keeler, dwunastolatka może teraz w swoim telefonie użyd funkcji szybkiego wybierania numeru, aby automatycznie zamówid pizzę tę samą, co zawsze. Komputer pizzerii rozpoznaje numer telefonu osoby zamawiającej, określa jej nazwisko, adres i sprawdza zamówienia złożone w ciągu ostatnich trzech miesięcy. W większości RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 6

7 wypożyczalni samochodów czy kampanii lotniczych, pracownik, znając nazwisko i numer klienta, może natychmiast uzyskad dostęp do jego danych adresowych czy informacji na temat preferencji. Również dzisiaj, u progu nowego tysiąclecia, niechęd AP do pełnego wykorzystania możliwości technologii informatycznych sprawia, że nadal nie rozwiązano wielu problemów eliminując model klienta, jako nośnika informacji. Pomimo że nowoczesne społeczeostwo zaakceptowało innowacje w innych dziedzinach życia, AP nadal pozostaje w tyle. Większośd komputerów wykorzystywanych w AP służy do prostych operacji księgowych i opracowywania raportów statystycznych. Ze względu na brak odpowiednich systemów wspierających, większośd urzędów nadal posługuje się modelem papierowym, z charakterystycznymi dla niego procesami, oczekiwaniem dostarczenia wszelkiej informacji (potrzebnej w procesie lub nie) oraz dużą dowolnością procedur i sposobu podejmowania decyzji. Mechanizmem sankcjonującym taki sposób działania jest prawo, które uniemożliwia (bez głębokich zmian) wprowadzenie efektywnych sposobów świadczenia usług w oparciu o dane kolekcjonowane w systemie informacyjnym. Dalej Protti stwierdza: Najważniejszą barierą, uniemożliwiającą lepsze wykorzystanie inwestycji w informatyzację AP, jest złożonośd organizacji oraz duża liczba istniejących systemów. Wiele organizacji AP średniej wielkości wykorzystuje setki systemów informatycznych. Każdy z systemów wspiera inny dział organizacji. Systemy te współdzielą bardzo mało informacji, a często działają zupełnie niezależnie od siebie. Z doświadczenia wiadomo, że jeśli ekonomiczna eksploatacja danej inwestycji wymaga integracji danych i procesów obsługiwanych przez różne systemy i jednostki organizacyjne, to reorganizacja procesów, zmiana zakresów odpowiedzialności, przeszkolenie dużej liczby pracowników i znalezienie dodatkowych funduszy jest niesamowicie trudnym przedsięwzięciem. Krajowe stowarzyszenie do spraw technologii informacji zdrowotnej (National Alliance for Health Information Technology) w USA zaproponowało następującą definicję interoperacyjności. Interoperacyjnośd to możliwośd sprawnej, efektywnej i spójnej komunikacji i wymiany informacji pomiędzy różnymi systemami informatycznymi, aplikacjami i sieciami komputerowymi oraz wykorzystywania otrzymanych w ten sposób informacji. Ta definicja wydaje się byd najbardziej adekwatna dla administracji publicznej. Aby nadrobid te zaległości, niezbędne jest umożliwienie współdziałania istniejących systemów i wzmocnienie ich nową generacją systemów integrujących informację, ukierunkowanych na usługi dla obywateli i przedsiębiorstw. Rozważając zagadnienia integracji i interoperacyjności, szczególną uwagę należy zwrócid na następujące trzy problemy: Integrację semantyczna, integrację danych możliwośd efektywnej i spójnej transmisji szczegółowych informacji. Integrację aplikacji, integrację systemów możliwośd współpracy systemów należących do różnych organizacji i wykorzystywania otrzymanych informacji. Interoperacyjnośd techniczną dostępnośd znormalizowanych funkcji transmisji i prezentacji danych, gwarantujących ochronę danych i niezawodnośd pracy. Europejskie Ramy Interoperacyjności W październiku 2009 Komisja Europejska opublikowała nową wersję dokumentu European Interoperability Framework for European Public Services v. 2.0 (EIF 2.0). Stworzony on został, jako komunikat, a więc dokument obligujący dla samej Komisji, a jednocześnie zbiór zaleceo dla paostw członkowskich. Poniżej prezentujemy wybrane fragmenty EIF 2.0. Cele EIF 2.0 RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 7

8 Celem stworzenia Europejskich Ram Interoperacyjności jest: promowanie i wspieranie dostarczanie Usług Publicznych na poziomie europejskim poprzez wytwarzanie ponadgranicznej i ponadsektorowej interoperacyjności (poprzez sektor rozumie się tu np. e-zdrowie, środowisko, rolnictwo) nakierowanie administracji publicznej krajów europejskich na udostępnianie usług dla przedsiębiorców i obywateli uzupełnienie i połączenie istniejących krajowych ram interoperacyjności w wymiarze ogólnoeuropejskim Europejskie Ramy Interoperacyjności powinny byd uwzględniane przy podejmowaniu decyzji dotyczących wdrażania e-usług administracji wynikających z zobowiązao wspólnotowych, jak również podczas tworzenia serwisów i systemów wspierających implementację inicjatyw i polityk UE. Ponadto Ramy powinny byd uwzględniane przy wdrażaniu usług mogących w przyszłości byd częścią europejskich usług publicznych. EIF tworzony jest w ramach programów IDABC (Interoperable Delivery of European egovernment Services to public Administrations, Businesses and Citizens) 1 i ISA (Interoperability Solutions for European Public Administrations) 2, w porozumieniu i ścisłej współpracy z paostwami członkowskimi UE. Europejskie Ramy Interoperacyjności wspierają rozwój wspólnego rynku wewnętrznego unii poprzez zwiększanie interoperacyjności w ramach europejskich jednostek administracji publicznej. W dokumencie zawarto następującą definicję interoperacyjności Interoperacyjnośd, w ramach kontekstu dostarczania Europejskich Usług Publicznych, jest drogą do umożliwienia różnym organizacjom na interakcję dla osiągnięcia wspólnie ustalonych i korzystnych celów poprzez wymianę informacji i wiedzy pomiędzy organizacjami. Działania te będą wspierały procesy biznesowe organizacji poprzez wymianę danych pomiędzy ich systemami teleinformatycznymi. Kontekst EIF jest częścią zbioru inicjatyw związanych z budową ram interoperacyjności dla Europejskich Usług Publicznych. Wykres poniżej przedstawia zależności pomiędzy tymi inicjatywami: Z jednej strony - Europejską Strategią Interoperacyjności (EIS European Interoperability Strategy), EIF oraz Europejskimi Wytycznymi Interoperacyjności (EIG) i Europejskimi Usługami i Narzędziami Interoperacyjności i z drugiej strony działaniami mającymi na celu stworzenie Europejskich Usług Publicznych RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 8

9 Rekomendowane jest ustalenie sposobu zarządzania interoperacyjności na poziomie UE uwzględniającego wytyczanie konkretnych celów i rezultatów, które mają byd osiągnięte. Na tym polu Europejska Strategia Interoperacyjności (EIS) dostarcza podstawę dla zdefiniowania ram organizacyjnych, finansowych i operacyjnych potrzebnych dla wsparcia interoperacyjności ponadgranicznej i ponadsektorowej. EIS jest punktem wyjścia i motorem biznesowym dla inicjatywy EIF i innych działao poprzez ustalenie strategicznych priorytetów i celów. Podstawowe zasady dotyczące Europejskich Usług Publicznych Poniżej opisane zasady dotyczą kontekstu europejskiego i współpracy pomiędzy systemami różnych krajów członkowskich, ale też mogą byd w łatwy sposób przeniesione na grunt krajowych systemów administracji publicznej. Zasady te opisują kontekst w którym podejmowane są decyzje co do Europejskich Usług Publicznych oraz w którym są one implementowane. Zasady uzupełniają się bez względu na to, że dotyczą innych obszarów (polityczne, prawne, techniczne). 12 podstawowych zasad EIF może byd podzielonych na następujące kategorie: Pierwsza zasada stanowi ramy dla działao wspólnoty w obszarze Europejskich Usług Publicznych, Kolejna grupa zasad obrazuje ogólne potrzeby i oczekiwania użytkowników (2, 3, 4, 5, 6, 7 i 8), Ostatnia grupa zasad stanowi podstawę dla współpracy między administracjami (9, 10, 11 i 12). zasada 1: Subsydiarnośd i Współmiernośd Pierwsza główna zasada obejmuje pojęcia subsydiarności i współmierności, jakie wprowadzone zostały w traktatach UE. Zasada pomocniczości mówi o tym, że decyzje w UE powinny zapadad jak najbliżej obywatela. Innymi słowy, Unia nie podejmuje działao tam, gdzie bardziej efektywne jest działanie na szczeblu paostwowym, regionalnym, czy lokalnym. Zasada współmierności ogranicza UE do działao, które są niezbędne dla osiągnięcia ustanowionych zasad i celów. Oznacza to, że UE wybiera rozwiązania pozostawiające paostwom członkowskim największe możliwe pole manewru w implementacji. zasada 2: Koncentracja na użytkowniku Usługi publiczne adresują potrzeby obywateli i przedsiębiorstw. Te potrzeby powinny decydowad o tym, jakie usługi publiczne są świadczone i w jaki sposób są one udostępniane. W ogólności można przyjąd, że obywatele i przedsiębiorstwa oczekiwad będą: Dostępu do przyjaznych, spersonalizowanych (przy zachowaniu prywatności) użytkownikowi usług, Przekazywania danych informacji tylko raz do administracji publicznej, Udostępnienia pojedynczego punktu kontaktowego dla spraw urzędowych nawet wtedy, gdy sprawa wymaga współdziałania wielu urzędów, Wieloplatformowego dostępu do usług umożliwiającego dostęp do nich zawsze i wszędzie. 3 zasada 3: Przeciwdziałanie wykluczeniu i pełna dostępnośd Użycie technik informatycznych powinno umożliwid stworzenie jednakowych dla wszystkich obywateli i przedsiębiorstw warunków dla dostępu do usług. Odbywa się to dzięki zastosowaniu usług dostępnych publicznie, w sposób przeciwdziałający wykluczeniu i dyskryminacji. Ważnym aspektem jest pełne wykorzystanie nowoczesnych technologii w celu pokonania barier społecznych i ekonomicznych. Dostępnośd jest rozumiana również, jako środek umożliwiający 3 Takie podejście prezentuje między innymi dokument Platforma Usług dla Obywateli opracowany przez Pawła Walczaka, Microsoft 2009 RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 9

10 korzystanie z usług publicznych przez osoby niepełnosprawne i starsze w takim samym stopniu jak pozostałe grupy społeczne. Przeciwdziałanie wykluczeniu i dostępnośd muszą byd czynnikami wpływającymi na cały cykl życia Europejskich Usług Publicznych. Dotyczy to ich projektu, zawartości informacyjnej oraz sposobu dostarczenia. Czynniki te wspierają zazwyczaj wieloplatformowy dostęp. Tradycyjne metody udostępniania usług powinny koegzystowad z nowymi, wykorzystującymi najnowsze technologie umożliwiając obywatelom wybór sposobu dostępu. zasada 4: Bezpieczeostwo i prywatnośd Obywatele i przedsiębiorcy muszą byd przekonani o tym, że ich kontakty z administracją obywają się w środowisku zaufanym i bezpiecznym. W pełni zgodnym z regulacjami dotyczącymi np. prywatności i ochrony danych. Oznacza to, że administracja paostwowa musi zapewnid zachowanie prywatności obywatelom i poufności danych uzyskanych od przedsiębiorców. Mając na uwadze ograniczenia bezpieczeostwa, obywatele i przedsiębiorcy powinni mied prawo weryfikacji danych zebranych od nich przez administrację paostwową i zadecydowania, czy dane te mogą byd przekazane w celach innych, niż w jakich zostały pierwotnie podane. zasada 5: Wielojęzycznośd Należy zachowad balans pomiędzy oczekiwaniami obywateli dotyczącymi uzyskania usługi w ich ojczystym języku, a możliwością udostępniania tychże usług przez administracje poszczególnych krajów członkowskich w każdym języku urzędowym UE. Jednakże Europejskie Usługi Publiczne udostępniane na poziomie UE powinny byd dostępne we wszystkich językach urzędowych Unii. Dostępnośd w wielu językach powinna byd analizowana dużo wcześniej, niż na etapie projektowania interfejsu użytkownika, gdyż np. decyzje co do sposobu reprezentacji danych mogą wpływad na możliwośd oferowania danej usługi w różnych językach. zasada 6: Upraszczanie administracji Przedsiębiorstwa i instytucje tworzą ogromne ilości informacji tylko w celu spełnienia wymagao prawnych, jednak bez żadnych korzyści dla nich i bez wpływu na cele jakie miał spełniad dany przepis prawa. To tworzy poważne bariery administracyjne, które mogą byd traktowane jako koszt dla przedsiębiorstw. Dlatego tez komisja europejska zaproponowała w styczniu 2007 zmniejszenie tychże barier o 25% do roku W celu osiągnięcia tego wyniku administracje w Europie muszą współdziaład. zasada 7: Transparentnośd Obywatele i przedsiębiorcy powinni rozumied przebieg procesu administracyjnego. Powinni mied oni dostęp do informacji o stanie spraw ich dotyczących oraz wgląd w uzasadnienia decyzji mających na nich wpływ. Transparentnośd to także umożliwienie obywatelom i przedsiębiorcom przekazania informacji zwrotnej o jakości usług publicznych, co może prowadzid do ich usprawnienia, bądź do propozycji wdrożenia nowych usług. zasada 8: Przechowywanie informacji Informacja w formie elektronicznej przechowywana jest przez organa administracji publicznej celem udokumentowania przebiegu procesów i podstaw podjętych decyzji. Celem jest zapewnienie, że informacja ta będzie czytelna, dostępna, pewna, a jej integralnośc w czasie będzie chroniona. Dostęp do informacji powinien byd chroniony z uwzględnieniem zasad bezpieczeostwa i prywatności. W celu zapewnienia długotrwałej możliwości przechowywania danych w postaci elektronicznej, powinny zostad wybrane formaty danych zapewniające wskazane powyżej cechy z uwzględnieniem zachowania podpisów elektronicznych i certyfikatów elektronicznych, w tym upoważnieo. zasada 9: Otwartośd RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 10

11 W kontekście EIF otwartośd rozumiana jest, jako gotowośd osób, organizacji do dzielenia się wiedzą w celu stymulowania debaty mającej jako ostateczny cel podwyższanie poziomu wiedzy w danej społeczności (co prowadzi do sprawniejszego rozwiązywania problemów tejże społeczności). W tym rozumieniu otwartośd prowadzi do znacznego wzrostu efektywności. Interoperacyjnośd wiąże się ze współdzieleniem informacji i wiedzy między organizacjami, a tym samym wspiera ideę otwartości. Istnieją różne poziomy otwartości. Tworzenie specyfikacji dla oprogramowania i metody tworzenia oprogramowania tak, aby ich rezultaty były otwarcie dostępne są przykładem realizacji zasady otwartości, podczas gdy oprogramowanie zamknięte, nieudokumentowane i nie korzystające z reużywalności jest przykładem podejścia przeciwnego. Spektrum rozwiązao i podejśd leżące pomiędzy tymi dwoma podejściami można nazwad kontinuum otwartości. Administracja publiczna w Europie musi zadecydowad gdzie chce się plasowad w tym kontinuum w zakresie zagadnieo objętych EIF. Dokładna pozycja może byd różna w zależności od konkretnej sprawy bazując na konkretnych potrzebach, priorytetach, zaszłościach, dostępnym budżecie, sytuacji na rynku i wielu innych czynników. Co prawda istnieje korelacja między otwartością, a interoperacyjnością, to jednak możliwe jest osiągnięcie interoperacyjności poprzez homogenicznośd systemów teleinformatycznych (co oznacza koniecznośd używania przez wszystkich partnerów tego samego rozwiązania do udostępniania i wdrożenia Europejskiej Usługi Publicznej). zasada 10: Reużywalnośd Reużycie jest kluczem dla efektywnego wdrażania Europejskich Usług Publicznych. Reużycie oznacza sytuację, w której administracje postawione przed potrzebą rozwiązania danego problemu korzystają z doświadczeo innych, szukając dostępnych rozwiązao, oceniając przydatnośd i ważnośd dla rozpatrywanego problemu i decydując się na użycie rozwiązao sprawdzonych w innych miejscach. Oznacza to także gotowośd do udostępniania innym administracjom komponentów potrzebnych do budowy i udostępniania usług. Reużycie i udostępnianie prowadzi do współpracy, tj. wspólnej pracy przy osiąganiu uzgodnionych i wzajemnie korzystnych celów. W specyficznym przypadku oprogramowania o otwartym kodzie źródłowym, komisja europejska utworzyła Open Source Observatory and Repository (OSOR) i utworzyła licencję EUPL (European Union Public Licence) celem wsparcia (między innymi) administracji publicznych w dzieleniu się, ulepszaniu i reużyciu komponentów oprogramowania. zasada 11: Neutralnośd technologiczna i adaptowalnośd Podczas tworzenia Europejskich Usług Publicznych, administracje powinny skupid się na potrzebach funkcjonalnych, odsuwając decyzje o wyborze technologii tak długo, jak to możliwe unikając wymuszania na partnerach określonych rozwiązao technicznych. Administracje powinny byd gotowe do szybkiego dostosowywania się do zmiennego otoczenia technologicznego. Administracje publiczne muszą udostępniad usługi publiczne niezależnie od określonej technologii czy zastosowanego produktu. zasada 12: Efektywnośd i Sprawnośd Administracje publiczne powinny zagwarantowad świadczenie usług i udostępnianie rozwiązao służących przedsiębiorstwom i obywatelom w sposób jak najbardziej efektywny i sprawny. Rezultatem tego powinno byd optymalne wykorzystanie pieniędzy podatników. Istnieje wiele sposobów oceny wartości wnoszonych przez rozwiązania usług publicznych, m.in. zwrot z inwestycji (ROI), całkowity koszt pozyskania (TCO), zwiększenie elastyczności, redukcja barier administracyjnych, zwiększona sprawnośd działania, redukcja ryzyka, przejrzystośd, ułatwienie działania, usprawnienie metod działania, jak również docenienie osiągnięd i kompetencji administracji. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 11

12 Dalsza częśd dokumentu dotyczy założeo pojęciowego modelu usług publicznych oraz definiuje pojęcia poziomów interoperacyjności: prawnej, organizacyjnej, semantycznej i technicznej. Integracja semantyczna, integracja danych Niepełne lub niejednoznaczne rozumienie znaczenia danych zgromadzonych w systemie nie pozwala na poprawną integrację systemu. Efekty mogą byd wręcz katastrofalne. Zakładamy, że znamy definicje elementów danych, więc pojęcie obywatel w kontekście jednego systemu powinno znaczyd dokładnie to samo, co w kontekście innego systemu. Jednak nie zawsze jest to prawidłowe założenie. Zanim zaczniemy przesyład dane pomiędzy systemami, musimy upewnid się, ze znaczenie danych jest takie samo w obu tych systemach. Guru branży IT, James Martin, do opisania zamętu i błędów występujących w przypadku niedopasowania i niezrozumienia definicji elementów danych, używa terminu brak integralności semantycznej. W systemach informacyjnych AP istnieje duże prawdopodobieostwo wystąpienia braku integralności semantycznej. Opracowanie definicji terminów, ich znaczeo, przygotowanie szczegółowych modeli danych i słowników wymaga wiele wysiłku. Wiele pracy wymaga także opracowanie zestandaryzowanych terminologii zarówno o bardzo wąskim zakresie, jak i szerokich i pokrywających się wzajemnie. Paradoksalnie, modele i terminologie nie ułatwiają ani integracji, ani współdziałania. Poza definicjami i opisem danych istnieją jeszcze dwa główne czynniki, które trzeba wziąd pod uwagę, jeśli integracja ma zakooczyd się powodzeniem sposób identyfikacji danych oraz standardy stosowane do kodowania i przesyłania danych. Najważniejszym problemem jest sposób identyfikowania danych. Najprostszym rozwiązaniem jest przydzielenie każdemu obywatelowi unikalnego numeru (np. PESEL), który będzie służył za podstawowy identyfikator wszystkich danych pacjenta gromadzonych przez system. Takie właśnie rozwiązanie przyjęto w Wielskiej Brytanii w zakresie opieki zdrowotnej, gdzie każdy pacjent na terytorium Anglii posiada numer NHS, wykorzystywany we wszystkich transakcjach dotyczących jego osoby. Co ciekawe, w Szkocji każdy pacjent także posiada swój unikalny numer (numer CHI). Numer ten jest jednak inny niż numery stosowane w Anglii. Ponieważ wielu obywateli Wielkiej Brytanii przynajmniej raz przeprowadziło się z Anglii do Szkocji lub na odwrót, do zebrania pełnej dokumentacji medycznej pacjentów konieczna jest znajomośd obu numerów identyfikacyjnych. Podobne zjawisko występuje także w Europie kontynentalnej. Problemem są również błędy popełniane często podczas podawania numeru. Według niektórych statystyk, odsetek błędów waha się w przedziale 20 40%, co bardzo utrudnia poprawne powiązanie transakcji z obywatelem. W związku ze szczególną wrażliwością danych medycznych, posłużymy się przykładami z dziedziny opieki zdrowotnej. W Stanach Zjednoczonych zespół doradców noszący nazwę Connecting for Health, doszedł do wniosku, że wprowadzenie pojedynczego krajowego identyfikatora pacjenta w nieodległym terminie jest niemożliwe, a i tak jego wdrożenie nie przyniosłoby oczekiwanych korzyści. Stwierdzono, że nie istnieje łatwy sposób na połączenie danych, który nie naruszałby prywatności pacjentów i nie zagrażał integralności danych. Wcześniejsze propozycje wprowadzenia ogólnokrajowego identyfikatora pacjenta wywoływały ogniste spory na temat poufności danych i stanowiły główną przeszkodę w połączeniu dokumentacji medycznej. Główną obawą było to, że identyfikator utworzony na potrzeby służby zdrowia stanie się tak wszechobecny, jak numer ubezpieczenia (Social Security Number), służąc za pojedynczy krajowy identyfikator do wszystkich celów. Jeśli identyfikator pacjenta stałby się kluczem umożliwiającym pobranie informacji z wielu baz danych przechowujących dane poufne, sprawiłoby to, że wszystkie dane osobowe stałyby się bardziej podatne na nadużycia. Dalej zespół stwierdza: W proponowanym przez nas systemie, decyzje na temat łączenia i udostępniania danych podejmowane są na brzegach sieci. Taki system pozwala na łączenie danych za pomocą katalogu wskaźników i udostępnianie danych dostawcom usług medycznych, partycypującym w systemie, ale także łączenie danych bez ich udostępniania albo z RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 12

13 udostępnianiem danych jedynie jednostkom o wyższym zakresie uprawnieo, a także daje możliwośd rezygnacji z łączenia danych w określonych sytuacjach możliwe jest na przykład pominięcie danych na temat leczenia odwykowego. Podejście to oparto na założeniu, że to pacjent powinien sam decydowad, które informacje należy udostępnid, a które nie powinny zostad ujawnione. Architektura pozwalająca na podejmowanie decyzji na granicach systemu daje szerokie możliwości wyboru. Istnieje także możliwośd lokalnego ustawienia wyższego poziomu zatwierdzenia, pozwalającego na współdzielenie tylko określonych danych. Dla odmiany, NHS w Wielkiej Brytanii już na wstępie odrzucił system wskaźników, ponieważ nie można zagwarantowad, że zdalny system będzie dostępny w chwili, gdy konieczne będzie pobranie przechowywanych w nim danych. W rezultacie podjęto prace mające na celu zaprojektowanie i utworzenie kręgosłupa centralnej bazy danych, zawierającej dane demograficzne pacjentów i ich dokumentację medyczną. Ponieważ pacjent musi mied prawo do kontrolowania, kto ma dostęp do danych o jego zdrowiu, obecnie trwają gorące spory na temat tego, jakie dane mają trafiad do kręgosłupa. Dyskusja skupia się wokół dwóch modeli model domniemanej zgody zakłada umieszczanie w bazie wszystkich danych, chyba że pacjent się temu sprzeciwi, natomiast model zgody wyrażonej jawnie wymaga od pacjenta jawnego zaakceptowania przesłania części lub całości jego danych do bazy. W grudniu 2007 rozgorzała na nowo dyskusja dotycząca takiego modelu. Minister zdrowia gabinetu cieni Andrew Lansley wyraził następującą opinię: W zakresie bezpieczeostwa danych najbardziej niepokoi nas fakt, że kreując potężną bazę danych powodujemy nie tylko możliwośd katastroficznej ich utraty, ale też potencjąlną możliwośd dla każdego, kto uzyska dostęp i hasła do dostępu do danych obywateli. Szyfrowanie nie jest wystarczającym zabezpieczeniem w przypadku dużej liczby osób posiadających hasła dostępu. Wdrażany obecnie model zcentralizowany uwzględnia tylko korzyści z jego zastosowania, ale nie koniecznie zagrożenia z niego wynikające Komentarze te powstały między innymi na skutek udokumentowanego, dziewięciokrotnego nieuprawnionego dostępu do danych medycznych. Do dyskusji włączył się też prof. Ross Anderson zajmujący się na uniwersytecie Cambridge architekturą bezpieczeostwa, podając przykład utraty w systemie jednego z miast 160 tys. rekordów danych dotyczących dzieci. Zwrócił też uwagę, że w systemach bankowych nie ma takich przypadków, aby pojedyncza osoba miała jednocześnie dostęp do wielu rekordów w pełnym zakresie. Dyskusja ta wywołała wiele reakcji ( ) i skłania do zastanowienia się nad celowością całkowitej centralizacji danych obywateli. Problematyczne jest także kodowanie danych. Istnieje wiele systemów i standardów klasyfikacji danych. Niektóre z nich mają określone, specyficzne zastosowania. Sytuacja taka może prowadzid do problemów z translacją oznaczeo, gdy w łączonych systemach używa się różnych standardów kodowania i pomiędzy standardami tymi nie istnieje jednoznaczne powiązanie. Na rynku zaczęły pojawiad się silniki translacji, które oprócz konwersji z jednego standardu na inny pozwalają także na parsowanie opisów pełnotekstowych. Gdy rozwikłaliśmy już zagadnienia klasyfikacji danych, pojawia się inny problem: jakie dane potrzebne są, by opisad określoną sytuację, i w jakiej formie dane te powinny byd przesyłane. Panuje ogólne przekonanie, że najlepszym formatem wymiany informacji jest format XML. Integracja aplikacji, integracja systemów Często wskazywanym zaleceniem jest, by sied była oparta na wspólnej strukturze umów pomiędzy uczestnikami systemu. Sied powinna wykorzystywad zdecentralizowaną, sfederowaną architekturę, która jest oparta na standardach, chroni dane osobowe pacjentów, jest rozwijana stopniowo i nie wymaga stosowania pojedynczego numeru identyfikacyjnego obywatela czy zcentralizowanej bazy danych. Jednym z ważnych skutków wdrożenia proponowanego systemu opartego na sieci łączącej sieci jest fakt, że dane osobowe nadal przechowywane będą tam, gdzie przechowuje się je teraz głównie w gminach lokalnej ewidencji ludności i USC. (Nie należy zapominad o potężnym, acz RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 13

14 niezinformatyzowanym zasobie, jakim są księgi parafialne i koniecznośd uspójnienia z systemami AP w kontekście ślubów konkordatowych. W takim modelu dane obywatela składane są z informacji cząstkowych, przechowywanych w różnych źródłach danych w urzędach. Dzięki temu osoby podejmujące decyzje mają dostęp do informacji potrzebnej urzędowi do wydania decyzji. Dostęp do tych informacji mogą mied zarówno urząd, jak i obywatel. Nowym elementem infrastruktury może byd indeks wskaźników do lokalizacji danych na temat obywatela. Indeks taki nie będzie jednak zawierał żadnych informacji na temat zdarzeo związanych z obywatelem żadne dane na temat obywateli nie powinny byd przechowywane centralnie. Decyzje na temat udostępniania informacji muszą byd podejmowane na stykach sieci wspólnie przez obywateli i administrację, czy na przykład opiekę zdrowotną. Każdy przypadek musi byd rozpatrzony indywidualnie. Aby postawione cele były osiągalne, musimy uwzględnid pewne podstawowe, ogólne zasady: potrzebne są ujednolicone metody poprawnej identyfikacji osób z jednoczesną gwarancją zachowania poufności danych, potrzebne są ujednolicone zestawy danych, jednolite standardy bezpiecznej wymiany danych oraz wspólne słowniki kodowania danych, niezbędne jest opracowanie jednolitych zbiorów wartości i zasad, dzięki którym to obywatele będą kontrolowali informacje na swój temat, możliwe będzie bezpieczne przechowywanie danych wprowadzonych przez administrację i obywateli oraz możliwe będzie przenoszenie informacji w zależności od potrzeb i życzeo każdej z osób. Firma Microsoft zakłada, że poszczególne kraje będą wdrażały rozwiązania e-administracji, które: będą albo nie będą korzystały z pojedynczego systemu identyfikacji obywatela, mogą stosowad różne schematy rozproszenia danych i funkcjonalności od systemów całkowicie rozproszonych, poprzez warianty pośrednie, aż po systemy całkowicie scentralizowane, będą stosowały różne role do uwierzytelniania i autoryzacji użytkowników, będą korzystały z różnych standardów kodowania danych, będą wymieniały dane z wykorzystaniem XML i Web Services. Różne kraje z pewnością będą miały różne wymagania biznesowe i priorytety i bez wątpienia będą chciały zminimalizowad zakupy nowego oprogramowania i infrastruktury, poprzestając na wprowadzaniu modyfikacji i modernizowaniu istniejących zasobów. Aplikacje AP uruchamiane są na różnych platformach i charakteryzują się zróżnicowanymi wymaganiami. Funkcjonalnośd tych aplikacji czasem pokrywa się wzajemnie, a czasem powstają luki. Zwykle są to niezależne aplikacje o niskim poziomie integracji i interoperacyjności. Co więcej, wiele z tych aplikacji to aplikacje stare albo aplikacje oparte na zamkniętych standardach - aplikacje takie trudno zmodyfikowad lub uaktualnid. Integracja aplikacji zapewniania jest przez strukturę biznesową RISA, opracowaną w sposób ukierunkowany na usługi, definiującą zestaw komponentów biznesowych, realizujących określone zadania i usługi, które mogą byd orkiestrowane w celu obsługi różnych procesów biznesowych AP. Wszędzie, gdzie było to możliwe, proponowane jest wykorzystanie istniejącej funkcjonalności i danych. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 14

15 Rys. Wzorzec biznesowy AP Na ilustracji przedstawiono wzorzec biznesowy dla systemów informatycznych w AP. Wzorce tego typu mogą byd bardzo przydatne. Za ich pomocą można opisywad ogólne rozwiązania powtarzalnych problemów w określonym kontekście. Ujmując to w inny sposób: po co na nowo wynajdywad koło, jeśli ktoś kiedyś zrobił już coś podobnego? Wzorce doskonale sprawdzają się w połączeniu z metodologią tworzenia i implementacji architektur zorientowanych na usługi. Dostępne są wzorce obejmujące aspekty biznesowe, techniczne i integracyjne takich architektur. Na problem ten można spojrzed z dwóch komplementarnych punktów widzenia inne instytucje o podobnym profilu działalności byd może posiadają repozytorium komponentów i usług podobnych do komponentów potrzebnych w opracowywanym właśnie rozwiązaniu. Komponenty te różnią się sposobem implementacji jedne i drugie stosowane są w innym środowisku, z inną infrastrukturą, jednak są bardzo podobne do siebie po względem funkcjonalności i przetwarzanych danych. Uściślijmy powyższą definicję wzorzec biznesowy opisuje możliwą do wielokrotnego wykorzystania metodę opracowania rozwiązania danego problemu biznesowego, zwykle ujętego w postaci procesu biznesowego. Wzorzec to propozycja rozwiązania oparta na wcześniejszych, udanych rozwiązaniach takich samych lub podobnych problemów biznesowych. Wzorzec można traktowad, jako szablon architektury rozwiązania biznesowego. Komponenty są niezależne od platform i technologii. Ich funkcjonalnośd jest niezależna od pozostałych komponentów, każdy komponent odpowiada za swoje własne dane. Każdy obejmuje definicję określonych cech charakterystycznych (funkcjonalności i danych). Funkcje i dane komponentów udostępniane są za pośrednictwem zdefiniowanych usług. Metodologia oparta na komponentach pozwala na utworzenie wysoce zmodularyzowanej platformy integracyjnej oraz oprócz dostarczenia specyfikacji programistycznej określa także sposoby definiowania funkcjonalności, zakresu usług i sposobu współpracy z komponentami opracowywanymi przez innych producentów i komponentami już istniejącymi. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 15

16 Mając do dyspozycji takie repozytorium komponentów i usług, można wyobrazid sobie finalną postad zorientowanej na usługi architektury systemu dla AP. Broker RISA Głównym elementem architektury referencyjnej jest broker RISA, umożliwiający udostępnienie między innymi następujących usług: usługi zarządzania tożsamością, usługi poufności i bezpieczeostwa danych, usługi prezentacyjne i punktu dostępu, usługi publikacji i lokalizacji usług, usługi elektronicznej dokumentacji medycznej, usługi domeny AP, usługi rejestrowe, usługi integracyjne, usługi danych, usługi zarządzania systemem, usługi komunikacyjne. Szczegółowy opis poszczególnych usług znajduje się w drugiej części opracowania. W części tej poruszono także następujące zagadnienia: Sposoby wdrażania opis różnych sposobów wdrażania rozwiązao, które warto wziąd po rozwagę implementując wzorcową architekturę e-administracji z uwzględnieniem zmieniających się wymagao i uwarunkowao prawnych. Wydajnośd i skalowalnośd zagadnienia związane z tworzeniem rozwiązania spełniającego wymagania dotyczące dostępności, czasu reakcji i wydajności. Opisano techniki planowania mocy obliczeniowej systemu oraz implementowania skalowalnej architektury sprzętowej i programistycznej. Zarządzanie i eksploatacja analiza problemów związanych z eksploatacją i zarządzaniem rozwiązaniem, zapewnieniem pomocy technicznej i wsparcia oraz dostarczaniem usług. Wymagania biznesowe dotyczące warstwy prezentacyjnej, określone dla interfejsu użytkownika i procesów użytkowników, zaspakajane są przez funkcjonalnośd usług zarządzania tożsamością, usług utrzymania poufności i bezpieczeostwa danych oraz usług prezentacji i punktu dostępu, zdefiniowanych ramach platformy technicznej. Analogicznie, wymagania dotyczące procesów biznesowych zaspakajane są przez usługi publikacji i lokalizacji usług, usługi elektronicznej dokumentacji spraw obywateli, usługi domeny AP, usługi rejestrowe i usługi integracyjne, zapewniane przez platformę techniczną. Wymagania związane z dostępem do danych zaspakajane są przez funkcjonalnośd warstwy dostępu do danych. Usługi biznesowe, zdefiniowane w postaci komponentów w strukturze biznesowej RISA, działają w oparciu o platformę zapewnioną przez strukturę techniczną RISA. W połączeniu z brokerem RISA zaspakajają wymagania biznesowe domeny usług AP. Podsumowując firma Microsoft dostrzega możliwośd zbudowania sprawnego systemu usług AP w oparciu o stabilne podstawy. Platforma RISA zapewnia tę sprawnośd, rozgraniczając bardziej ulotne procesy użytkowników i procesy biznesowe od stabilnych usług biznesowych i usług danych. Ogniwem łączącym ulotne i stabilne części systemu jest broker RISA. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 16

17 Jedno okienko Jednym z postulatów EIF jest tworzenie przyjaznej administracji publicznej, czego warunkiem jest między innymi ograniczenie koniecznych interakcji z administracją. Takie założenia można wdrożyd fizycznie korzystając z całości założeo interoperacyjności. W wymiarze organizacyjnym i technicznym optymalnym wydaje się zastosowanie pewnej klasy rozwiązao umożliwiających zmianę sposobu obsługi klientów urzędu oraz spójnośd procesowania ich spraw. W wielu przypadkach informatyzacja jest wynikiem obowiązków nałożonych na jednostki administracji publicznej poprzez odpowiednie akty prawne. Realizowane są wówczas takie projekty informatyczne, które ustawodawca określa, jako niezbędne. Nie zawsze takie podejście do informatyzacji służy klientom urzędów. Wynikiem analiz przeprowadzonych przy udziale strony Centrum Innowacji Microsoft w Łodzi 4 (CIM) oraz samorządowej w Polsce i w innych krajach jest propozycja innego podejścia do budowy wizji i implementacji systemów teleinformatycznych wspomagających jednostki administracji publicznej. Odpowiedzią na tego typu potrzeby wydaje się byd projekt Citizen Service Platform (CSP) 5, realizowany w Polsce w ramach działao CIM 6, powstały w wyniku doświadczeo zdobytych na całym świecie w trakcie budowy rozwiązao teleinformatycznych dla administracji publicznej. Ma on kilka wymiarów w tym dwa najważniejsze: koncepcyjny i techniczny. Koncepcyjnie jest to realizacja założenia budowy systemu DLA INTERESANTÓW, a więc dostosowująca projekt organizacyjno-techniczny do tego priorytetu. Budowa systemów informacyjnych administracji samorządowej wspomagających usługi dla obywateli jest projektem skomplikowanym z uwagi na koniecznośd zmian organizacyjnoprawnych oraz koniecznośd zdefiniowania, a następnie wdrożenia standardów obejmujących wszystkie współuczestniczące w projekcie jednostki. Złożeniami CSP są: - Stworzenie struktury Działu Obsługi Klientów, który będzie reprezentował sprawy interesantów wobec różnych jednostek Urzędu lub wobec innych urzędów, - Stworzenie zestandaryzowanych i jednolicie obsługiwanych form kontaktu z Urzędem, niezależnie od rodzaju wnoszonej sprawy, - Możliwośd uzyskania w dalszych etapach gwarantowanego czasu odpowiedzi lub załatwienia sprawy, - Możliwośd monitorowania statusu sprawy przez interesanta, - Odciążenie interesantów poprzez zmniejszenie liczby interakcji z urzędem, - Budowa u obywateli obrazu przyjaznej administracji, Trzeba dodad, że koncepcja CSP jest zgodna dyrektywą usługową UE - Wdrożenie nowych usług elektronicznych będzie niosło za sobą korzyści i usprawnienie procesów zaimplementowanych w poszczególnych komórkach organizacyjnych, ułatwiając i przyspieszając codzienną pracę, zwłaszcza osób odpowiedzialnych za ich rozwiązywanie w poszczególnych obszarach merytorycznych. Platforma CSP jest zespołem rozwiązao organizacyjnych i technicznych pozwalająca na projektowanie i wdrażanie systemów teleinformatycznych wspierających usługi dla obywateli świadczone przez jednostki administracji publicznej. Projekt ten powstał w wyniku doświadczeo zdobytych na całym świecie w trakcie budowy rozwiązao teleinformatycznych dla administracji publicznej. Ma on kilka wymiarów w tym dwa najważniejsze: koncepcyjny i techniczny. Koncepcyjnie jest to realizacja założenia budowy systemu dla interesantów, a więc dostosowująca projekt organizacyjno-techniczny do tego priorytetu. Technicznie projekt zakłada: fizyczną realizację założeo interoperacyjności i architektury korporacyjnej, modularną budowę systemu, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 17

18 oparcie się o standardowe, gotowe komponenty w tym: bazy i hurtownie danych, portale wewnętrzne, CRM i odpowiednią infrastrukturę telekomunikacyjną. Wdrożenie CSP ma zapewnid obywatelom jasny, efektywny i zunifikowany sposób kontaktu z Urzędem. Jednocześnie projekt ma umożliwid wykorzystanie wspólnej funkcjonalności systemu przez wszystkie jednostki podległe oraz docelowo zapewnid w zestandaryzowany sposób świadczenie usług dla obywateli w interakcji z innymi jednostkami administracji publicznej. W takim modelu urzędu nastawionego na świadczenie usług konieczne jest zbudowanie struktury organizacyjno-technicznej umożliwiającej minimalizację interakcji obywatel-urząd i wyeliminowanie konieczności dostarczania przez obywatela dokumentów i załączników będących już w posiadaniu urzędu. Wprowadzenie do Platformy modułu CRM przyniesie następujące korzyści: Podstawą rozwiązania jest Wielokanałowa Platforma Świadczenia Usług Publicznych (WPU). RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 18

19 Klasyczny sposób świadczenia usług publicznych na platformie elektronicznej jest kojarzony z dokumentami elektronicznymi przekazywanymi za pomocą Internetu. Rozwój technologii telekomunikacyjnych pozwala jednak myśled o nowych kanałach komunikacji i platformach, na których można udostępniad usługi publiczne. Dobrym przykładem takiej nowej platformy jest telefonia komórkowa. Rosnące możliwości transmisyjne sieci komórkowych, wdrożenie UMTS, a także rosnące możliwości samych telefonów pozwala już realnie myśled o udostępnieniu niektórych usług za pomocą telefonów. Należy także pamiętad o tym, że dostęp do Internetu, a co za tym idzie usług świadczonych za pomocą tego medium, dostęp ma mniejsza częśd naszego społeczeostwa. Skupiając się tylko na tej części społeczeostwa, która ma dostęp do Internetu i odpowiednio potrafi korzystad z Internetu skazuje częśd społeczeostwa na wykluczenie cyfrowe, a także stawia pod znakiem zapytania wydatkowanie środków publicznych na realizacje projektów, z których korzystad może tylko częśd społeczeostwa. Wykorzystanie usług telefonii komórkowej, mobilnego Internetu oraz możliwości, jakie daje interaktywna cyfrowa telewizja, to kierunki, w których zmierzad powinna administracja publiczna, aby uczynid swoje usługi jak najbardziej dostępnymi. Także sama administracja może skorzystad na wykorzystaniu nowych technologii, szczególnie mobilnych. Wiele z zadao realizowanych przez administrację wymaga mobilności, a jednocześnie stawia wysokie wymagania dotyczące dostępu do danych i dokumentowania pracy. W takich wypadkach tylko dostęp do aplikacji mobilnych pozwala pogodzid ze sobą tak sprzeczne wymagania. Dla pełnej implementacji takich rozwiązao konieczna jest integracja wewnętrzna obecnie istniejących systemów Urzędów w regionie, co będzie głównie z przyczyn organizacyjnoprawnych procesem skomplikowanym i długotrwałym. Wymagania systemów administracji Zważywszy na niezbyt zachęcający wstęp, typowe biznesowe wymagania nowej generacji systemów e-administracji powinny obejmowad: opracowanie systemu przechowywania pełnej (obejmującej całe życie) dokumentacji obywateli, umożliwienie obywatelom dostępu do ich własnej dokumentacji, udostępnienie portali komunikacji z AP i bram do informacji na temat usług AP, wdrożenie nowych, spójnych, opartych na rolach interfejsów użytkownika pozwalających na pobieranie danych z aplikacji wykorzystywanych obecnie, zachowanie kontekstu obywatela w różnych usługach, zachowanie poufności danych na temat obywatela, w tym anonimizowanie (depersonalizacja) i pseudoanonimizowanie danych udostępnianych poza właściwą relacją urząd-obywatel, zgodnośd z lokalnymi przepisami i standardami w zakresie zgody i zezwoleo na udostępnianie danych osobowych, stosowanie XML, Web Services oraz bezpiecznych i efektywnych standardów kodowania danych, zarządzanie prawidłowymi relacjami urząd-obywatel i stosowanie ich, budowanie i monitorowanie ścieżek procesów AP, definiowanie i zarządzanie procesami administracyjnymi, zarządzanie informacją i jej obiegiem, tworzenie interfejsów i udostępnienie na powyższych zasadach funkcjonalności wykorzystywanych obecnie aplikacji w postaci usług. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 19

20 Powyższa lista z pewnością nie jest kompletna, a przedstawione na niej wymagania nie zostały uporządkowane w żaden istotny sposób (na przykład według znaczenia). Firma Microsoft jest przekonana, że najlepszym sposobem wdrożenia nowej funkcjonalności w oparciu o istniejący zasób aplikacji jest wykorzystanie architektury zorientowanej na usługi. Architektura taka pozwala na udostępnienie wykorzystywanych obecnie aplikacji w postaci usług ich funkcjonalnośd i zgromadzone w nich dane mogą zostad udostępnione w określonej formie konsumentom zewnętrznym w odpowiedzi na przesłane przez nich zapytania. Zapytania i odpowiedzi są przedmiotem kontraktu, który określa zagadnienia takie jak dostępnośd, dokładnośd oraz reguły związku, na przykład sposób uwierzytelniania i warunki zachowania poufności. Typowe wymagania techniczne, umożliwiające utworzenie platformy informatycznej pozwalającej na realizację wymienionych wyżej wymagao biznesowych, to: otwarte standardy składowania i transmisji danych, w tym standardy technologii zorientowanych na usługi na przykład technologia usług Web Service, bezpieczne operacje obsługi danych i komunikacji, zapewniające mechanizmy uwierzytelniania i autoryzacji, a także funkcje utrzymania ciągłości pracy i zarządzania danymi, interoperacyjnośd z różnymi platformami, pozwalająca na łączenie różnorodnych systemów i źródeł danych w spójne, łatwo kontrolowane środowisko, niezawodne i bezpieczne metody komunikacji, pozwalające na elastyczną i sprawną orkiestrację procesów biznesowych oraz łączenie niezależnych wysp automatyzacji, integracja ze starszymi systemami, czyli zastosowanie otwartych standardów do komunikacji z istniejącymi systemami w różnych domenach, opartymi na różnych platformach, mechanizmy zachowania poufności i tajności danych, umożliwiające obywatelom kontrolowanie udostępniania ich danych, określanie możliwych obszarów wykorzystania tych danych oraz wskazywanie ról uprawnionych, którym dane te można udostępnid, zarządzane środowiska informatyczne odporne na awarie i wyposażone w funkcje samodzielnego monitorowania, a więc zapewniające wysoką solidnośd i niezawodnośd, wydajnośd zarówno pod względem czasu odpowiedzi, jak i łatwości obsługi, pełna dostępnośd 24 godziny na dobę, 7 dni w roku, 365 dni w roku, uzyskiwana dzięki stosowaniu sprawdzonych konfiguracji sprzętowych i rygorystycznie przetestowanego oprogramowania, systemy gorącej rezerwy i metody odtwarzania systemu po awariach, pozwalające łagodzid skutki awarii spowodowanych czynnikami zewnętrznymi. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 20

21 Powszechne problemy dotyczące architektury W ramach koncepcji Ram Interoperacyjności Systemów Administracji Publicznej -RISA (Connected Government Framework CGF) zajmiemy się najważniejszymi problemami związanymi z architekturą techniczną rozwiązao dla sektora publicznego, obszarami, które wymagają szczególnego potraktowania a często, przynajmniej na początkowych etapach projektu, umykają uwadze i możliwymi wariantami rozwiązao oraz opiszemy zalecany sposób rozwiązywania tych problemów. Oprócz omówienia problemów zwykle spotykanych w wielkoskalowych projektach informatycznych i integracyjnych, szczególny nacisk położymy na najważniejsze problemy charakterystyczne dla rozwiązao dla sektora publicznego. Chcąc uświadomid architektom złożonośd projektu, potencjalne problemy i dostępne opcje, zamieściliśmy tu ogólny opis zagadnieo związanych z architekturą techniczną, niezależny od specyficznych technologii czy implementacji. Bardziej szczegółowe zalecenia dotyczące rozwiązywania tych problemów zamieszczono w sekcjach Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego oraz Elementy składowe typowego rozwiązania integracyjnego dla sektora publicznego w dalszej części tego dokumentu. W witrynie MSDN dostępne są szczegółowe wskazówki firmy Microsoft, dotyczące architektur i wzorców projektowych dla korporacyjnych rozwiązao integracyjnych (patrz dział Integration Patterns pod adresem Pomimo że wzorce te opisywane są w kontekście integracji korporacyjnej, to niektóre z nich (na przykład Gateway, Message Broker) nadają się do bezpośredniego zastosowania w rozwiązaniach integracyjnych dla sektora publicznego. Złożonośd zagadnienia Wiele zagadnieo związanych z usługami dla sektora publicznego dotyczy problemu ich złożoności, w związku z czym konsolidacja i uproszczenie wynikające z unifikacji wspólnej infrastruktury, wspierającej te usługi, mogą okazad się bardzo korzystne. Zapewnienie dostępu do stale rozszerzającego się zakresu funkcji Inicjatywy dla sektora publicznego zwykle powstają, jako niewielkie projekty z ograniczonym zestawem funkcji, a następnie są stopniowo rozwijane i obejmują coraz szerszą funkcjonalnośd. Związanych jest z tym kilka specyficznych problemów, wynikających z różnorodności typów systemów i z rosnącej liczby tych systemów. Systemy zaplecza (back-end) świadczące usługi publiczne pracują na wielu różnych platformach i korzystają z różnych technologii. Stopniowe wdrażanie różnorodnych usług jest scenariuszem typowym ze względu na stały rozwój i ewolucję inicjatyw dla sektora publicznego. Zaprojektowanie i wdrożenie wspólnej infrastruktury, zdolnej do efektywnej obsługi rosnącej funkcjonalności systemu, jest dużym wyzwaniem, wykraczającym znacznie poza problemy spotykane w tradycyjnych systemach komercyjnych. Efektywna platforma dla sektora publicznego wdrożona i działająca w warunkach produkcyjnych powinna byd dostatecznie elastyczna, by można było w łatwy sposób wprowadzad nowe usługi, nowe transakcje i dostosowywad platformę do zmieniających się wymagao i to bez zmian w kodzie podstawowego rozwiązania, a najlepiej bez powodowania przestojów innych usług. Wdrażanie nowych usług powinno byd standardową funkcją systemu, odpowiednio uwzględnioną w projekcie rozwiązania, a nie rzadkim, wymagającym specjalnego traktowania przypadkiem. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 21

22 Różnorodnośd kanałów dostępu Istnieje wysokie prawdopodobieostwo, że nawet jeśli kanały dostępu do pierwotnego zestawu usług zostaną dobrze zdefiniowane w początkowym etapie projektu i właściwie przygotowane w pierwszej implementacji, to po pewnym czasie i tak pojawi się potrzeba obsługi nowych kanałów dostępu, takich jak kioski multimedialne, interaktywna telewizja czy urządzenia przenośne. Dobrze zaprojektowana platforma integracyjna, zapewniająca spójny sposób świadczenia usług, powinna umożliwiad dodawanie nowych kanałów dostępu poprzez jednorazowe zmodyfikowanie centralnego huba bez konieczności modyfikowania poszczególnych usług. Szerokie wsparcie różnorodnych platform klienckich Projekty dla administracji publicznej są często przedmiotem znacznie bardziej ścisłych regulacji i ograniczeo niż typowe systemy komercyjne. Zapewnienie niedyskryminującego dostępu do usług administracji publicznej z szerokiej gamy platform klienckich jest często wymaganiem jasno sprecyzowanym w przepisach prawnych, a przynajmniej pożądanym z politycznego punktu widzenia. Może się to wiązad z obsługą różnych typów i wersji sprzętu, systemów operacyjnych i oprogramowania przeglądarkowego. Właściciel systemu komercyjnego może podjąd uzasadnioną ekonomicznie decyzję wykluczenia niewielkiej części potencjalnych klientów poprzez ograniczenie zakresu obsługiwanych platform. Takie postępowanie niewiele zmniejszając potencjalny przychód pozwala uzyskad znaczne oszczędności, wynikające z mniejszego zakresu prac projektowych i programistycznych nad systemem i mniejszej liczby niezbędnych do wykonania testów. Dostawcy usług publicznych dla obywateli i przedsiębiorstw mają w tym zakresie mniejszą swobodę działania i często muszą ponosid znaczne koszty związane z uwzględnieniem różnych platform, by nie wykluczyd i nie dyskryminowad nawet niewielkich grup społecznych. Jest niezwykle istotne, by ograniczenia i wymagania związane z obsługą szerokiego spektrum platform klienckich zostały uwzględnione już na etapie projektowania architektury platformy integracyjnej dla sektora publicznego uwzględnienie tych warunków na dalszych etapach projektu może byd bardzo kosztowne, a nawet niemożliwe. Obsługa wielu języków i wszechstronny dostęp W wielu krajach zapewnienie wielojęzycznego dostępu do usług administracji publicznej jest wymaganiem prawnym, a przynajmniej należy do dobrych zwyczajów. W przypadku komunikacji z przedstawicielstwami Komisji Europejskiej jest to zwykle niezbędne. Uwzględnienie tego warunku już na początku realizacji projektu jest istotne, ponieważ wymaganie to ma duży wpływ na architekturę rozwiązania. Należy też mied na uwadze: - Zapewnienie różnych poziomów obsługi wielojęzyczności, w tym akceptowanie danych wielojęzycznych, zróżnicowanie skryptów i stron (na przykład do obsługi języków zapisywanych od prawej do lewej lub z użyciem znaków diakrytycznych). - Problemy dotyczące przetwarzania i przechowywania danych, które mają wpływ na stosowany model danych i wymagają szczególnej uwagi podczas pisania kodu aplikacji. - Wymagania zaprojektowania w pełni wielojęzycznego interfejsu użytkownika, w którym wszystkie łańcuchy tekstowe i komunikaty są odseparowane od kodu. W takim wypadku do pełnej obsługi języków znakowych pisanych od prawej do lewej niezbędne jest przygotowanie alternatywnych plików graficznych i innych treści. Należy także wziąć pod uwagę, że ten sam tekst w różnych językach może mieć różną długość. Witryny i usługi administracji publicznej są często objęte bardzo rygorystycznymi wymaganiami dotyczącymi przystępności (accessibility) dla osób o ograniczonej sprawności znacznie większymi niż w przypadku zwykłych witryn komercyjnych, gdzie przystępnośd jest pożądana w celu poszerzenia grupy odbiorców, ale jej brak ma jedynie niewielki wpływ na komercyjny efekt RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 22

23 przedsięwzięcia. Dla witryn i usług administracji publicznej przystępnośd jest zwykle wymagana prawem, a na dodatek jest ważnym problemem politycznym. Zajęcie się problemem przystępności już po zaprojektowaniu systemu jest trudne, drogie, a często niewykonalne. Przystępnośd już od samego początku powinna byd podstawowym założeniem projektu. W części Odsyłacze, listy kontrolne i dalsze informacje tego opracowania zamieszczono listy kontrolne dotyczące tworzenia aplikacji łatwych w lokalizacji oraz listę odsyłaczy do bieżących regulacji prawnych dotyczących przystępności, do inicjatyw (w tym także do wytycznych w zakresie przystępności, opracowanych przez organizację World Wide Web Consortium W3C), do programów syntezy mowy odczytujących teksty z ekranu komputera oraz do specjalnych przeglądarek, narzędzi do testowania przystępności aplikacji oraz do innych przydatnych zasobów. Obsługa wielu różnych poświadczeo tożsamości Korzystanie z różnych usług administracji publicznej zwykle wymaga podania specyficznego dla danej usługi identyfikatora użytkownika na przykład numeru PESEL, identyfikatora NIP, identyfikatora dostawcy - REGON itp. Gdy kontrola dostępu jest implementowana niezależnie dla każdej z usług, umożliwienie elektronicznego dostępu do wielu usług oznacza utworzenie odrębnych, niezależnych dla każdej usługi poświadczeo tożsamości. Użytkownicy muszą wtedy pamiętad wiele identyfikatorów i zarządzad wieloma hasłami. Stanowi to problem nawet w przypadku często wykorzystywanych usług, takich jak bankowośd elektroniczna. W przypadku usług administracji publicznej, próba przypomnienia sobie hasła czy identyfikatora do każdej z usług może sprawiad jeszcze większe trudności. Wprowadzenie platformy dla sektora publicznego, zapewniającej dostęp do wielu usług na podstawie pojedynczego zestawu poświadczeo tożsamości, jest niezwykle istotne dla upowszechnienia się usług dla tego sektora. Udostępnienie każdej z usług dla sektora publicznego w spójny i bezpieczny sposób Udostępnienie dowolnej usługi dla sektora publicznego za pomocą kanałów elektronicznych wymaga znacznych nakładów i wysiłków konieczne jest spełnienie wszystkich wymagao w zakresie bezpieczeostwa, dostępności i niezawodności. W niektórych krajach obowiązują rygorystyczne uregulowania prawne i każdy system administracji publicznej przed podłączeniem do Internetu musi przejśd obowiązkowy proces certyfikacji. Tworzenie dostępu elektronicznego dla każdej usługi z osobna prowadzi do powielenia tych wysiłków. Oznacza to stratę czasu, zasobów i niepotrzebne angażowanie specjalistów, którzy nie zawsze są dostępni w agencjach świadczących te usługi. Problem staje się szczególnie istotny, gdy usługi elektroniczne zaczynają byd tak popularne, że muszą byd świadczone nie tylko przez początkową grupę dużych jednostek administracji, które mają odpowiednią wielkośd, widocznośd i wpływy polityczne potrzebne do zabezpieczenia sobie niezbędnych zasobów. Mniejsze organizacje, takie jak administracja samorządowa, nie są w stanie samodzielnie pokryd początkowych kosztów świadczenia usług w sposób elektroniczny. Zidentyfikowanie najbardziej problematycznych elementów systemu dla sektora publicznego i jednokrotne zaimplementowanie ich w powszechnej platformie dla sektora publicznego, współdzielonej przez wszystkie usługi, pozwala zapewnid wysoką jakośd, spójnośd i bezpieczeostwo tworzonych rozwiązao oraz uzyskad znaczące oszczędności. Zarządzanie tożsamością Przy rosnącej przyszłości liczbie użytkowników systemów administracji oraz usług przez nich wykorzystywanych coraz większym wyzwaniem będzie zarządzanie ich uprawnieniami. Administratorzy systemu nie mogą przy tym odpowiadad za procesy przyznawania uprawnieo użytkownikom, gdyż wynikają one raczej ze struktury organizacyjnej i osadzenia pracowników w procesach realizowanych przez urząd. Tak więc konieczne jest zapewnienie sprawnych i prostych RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 23

24 w obsłudze mechanizmów umożliwiających uprawnionej kadrze kierowniczej nadawanie odpowiednich uprawnieo bez konieczności posługiwania się skomplikowanymi narzędziami administracyjnymi. Ponadto konieczne jest umożliwienie osobom uprawnionym łatwe sprawdzenie przyznanych uprawnieo oraz ich modyfikacji. Równie ważnym jest problem NIE nadania przez przypadek uprawnieo nie należnych danemu pracownikowi. Proces nadawania uprawnieo, w szczególności dla dostępu do różnych aplikacji dziedzinowych wymaga zwykle decyzji kilku osób oraz ostatecznej akceptacji (np. kierownika danego działu). Tak więc konieczne jest stworzenie elektronicznej drogi akceptacji, które po dokonaniu decyzji na poszczególnych szczeblach wyzwoli mechanizmy założenia konta (login), konta w poczcie elektronicznej, nadania uprawnieo, generowania certyfikatu itp. Ważnym krokiem w podniesieniu efektywności tego procesu jest Udostępnienie funkcjonalności wnioskowania przez zainteresowanego pracownika o nadanie specyficznych uprawnieo z natychmiastowym przekazaniem do wyżej opisanej drogi akceptacji ich nadawania. Dodatkową (i zwykle spotykaną) trudnością jest rozproszenie danych o użytkowniku w różnych systemach. Zwykle przechowywane one są w: - Bazie usług katalogowych, - Systemie kadrowo-płacowym, - Centrali telefonicznej - Książce adresowej poczty elektronicznej - BIP - Innych natywnych bazach poszczególnych systemów. Pierwszym krokiem do utworzenia spójnego systemu zarządzania tożsamością jest więc utworzenie spójnej bazy danych pracowników zasilanej z istniejących źródeł i stałej synchronizacji tej bazy ze źródłami w celu uzgadniania wszelkich zmian. System zarządzania tożsamością składa się z następujących elementów: 1. LDAP, które jest źródłem informacji o grupach użytkowników i wskazuje systemom, w obrębie której grupy zarządzamy członkostwem, 2. Referencyjna baza informacyjna SQL, która będzie integrowad i dostarczad pełne informacje o użytkownikach i grupach, 3. System integrujący informację, który zapewni łącznośd ze wszystkimi źródłami danych o użytkownikach i zapewni logikę synchronizacji tej informacji, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 24

25 4. Portal zapewniający interfejs zarządzania nadawania uprawnieo wraz z workflow akceptacyjnym oraz mechanizmem udostępniania formularzy poprzez przeglądarkę. Architektura systemu zarządzania certyfikatami System zarządzania certyfikatami ma umożliwid wdrożenie sprawnych mechanizmów dostarczania certyfikatów i zarządzania kartami kryptograficznymi. System ten pozwoli budowad procesy związane z automatycznym wystawianiem certyfikatów dla użytkowników w oparciu o uprzednio zdefiniowany proces biznesowy (w tym delegacje uprawnieo). Główne cechy systemu: - interfejs WWWW do wystawiania certyfikatów - delegacja uprawnieo (żądania i akceptacja wniosków o wystawienie certyfikatów) - definiowanie polityk wystawiania certyfikatów w oparciu o elektroniczny obieg dokumentów - zarządzanie PIN em dostępu do karty oraz SO PIN em - odblokowanie karty użytkownika - raportowanie wykorzystania kart / certyfikatów - system inwentaryzuje kart kryptograficzne wykorzystywane w organizacji Pojedyncze poświadczenia do dostępu do wielu usług Wprowadzenie możliwości wykorzystania pojedynczego poświadczenia tożsamości do dostępu do wielu usług (jak zostało to opisane wcześniej w rozdziale Obsługa wielu różnych poświadczeo RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 25

26 tożsamości) wymaga zbudowania powszechnej infrastruktury uwierzytelniania użytkowników, wspólnej dla wszystkich usług wchodzących w skład systemu. Warto w tym miejscu zauważyd, że stosowanie jednego zestawu poświadczeo tożsamości do dostępu do wielu usług wcale nie oznacza, że do dostępu do wszystkich usług musi byd stosowany jeden i ten sam zestaw poświadczeo. Mimo oczywistych zalet dostępu do wielu usług z wykorzystaniem jednego zestawu poświadczeo, platforma powinna pozostawiad użytkownikom swobodę wyboru usług, do których chcą uzyskiwad dostęp na podstawie określonego zestawu poświadczeo, i umożliwiad korzystanie z wielu niezależnych zestawów poświadczeo. Jest to zgodne z zasadami przedstawionymi w artykule The Laws of Identity, dostępnym pod adresem Spójne logowanie a pojedyncze logowanie Gdy użytkownicy uzyskali już możliwośd logowania się do rosnącej liczby usług za pomocą jednego zestawu poświadczeo, to zarówno dla użytkowników, jak i dostawców usług istotne staje się, by koszty i nakłady pracy, związane z umożliwieniem dostępu do każdej kolejnej usługi, utrzymad na jak najniższym poziomie. Dostęp do poszczególnych usług na podstawie jednego zestawu poświadczeo może byd realizowany na różnych poziomach między innymi poprzez spójne logowanie lub pojedyncze logowanie. Spójne logowanie to forma najprostsza dostęp do poszczególnych usług realizowany jest na podstawie pojedynczego zestawu poświadczeo, ale użytkownik nadal musi meldowad się do każdej usługi z osobna. Co prawda użytkownicy muszą pamiętad tylko jeden zestaw poświadczeo, ale za każdym razem, gdy chcą korzystad z innej usługi, muszą się ponownie zameldowad (jednak w niektórych przypadkach taki dodatkowy etap logowania może okazad się pożądany). Jednym ze sposobów implementacji spójnego logowania jest utrzymywanie przez każdą niezależną usługę własnej bazy danych uwierzytelniających. Bazy danych wzajemnie synchronizują swoją zawartośd, dzięki czemu poszczególne kopie poświadczeo logowania są identyczne. Poszczególne usługi zamiast implementowad własne mechanizmy uwierzytelniania mogą korzystad z pojedynczej, wspólnej usługi uwierzytelniania. Zakładana spójnośd uzyskiwana jest automatycznie, ponieważ poświadczenia użytkowników przechowywane są tylko w jednej lokalizacji. Bardziej zaawansowane rozwiązanie umożliwia użytkownikom przezroczysty dostęp do wielu usług po jednokrotnym zalogowaniu. Oznacza to prostotę korzystania z systemu przez użytkowników i pozwala na agregowanie usług. Dobrymi przykładami takich rozwiązao są portale, które komunikując się w tle z różnymi usługami zapewniają użytkownikom możliwośd korzystania z wielu usług jednocześnie. Odwzorowywanie tożsamości Zastosowanie pojedynczego zestawu poświadczeo do dostępu do wielu usług jest niewątpliwie użyteczne, ale rozwiązuje tylko jedną częśd problemu ułatwia użytkownikowi korzystanie z systemu. Systemy docelowe nadal korzystają z własnych, specyficznych identyfikatorów, wyróżniających użytkownika w kontekście danego systemu. Identyfikatory te są niezbędne do prawidłowego rozpoznania użytkownika i poprawnej pracy systemu i zwykle nie mają żadnego znaczenia poza kontekstem określonej usługi. Większośd obecnie wykorzystywanych systemów korzysta z takich specyficznych identyfikatorów, w związku z tym udostępnianie przez wspólną platformę dla sektora publicznego funkcji odwzorowania pojedynczego zestawu poświadczeo na odpowiednie identyfikatory, specyficzne dla poszczególnych usług, jest niezwykle istotne dla zapewnienia efektywnego dostępu do rosnącej liczby usług. W wielu krajach nie wprowadzono uniwersalnego krajowego identyfikatora dla obywateli, w związku z czym każda usługa wykorzystuje własne, specyficzne identyfikatory. Pewne ograniczenia istnieją nawet w krajach, w których wszyscy obywatele posiadają unikatowe identyfikatory i systemy administracji publicznej mogą w oparciu o nie identyfikowad użytkownika. Na przykład w sytuacji, gdy jedna osoba może mied wiele relacji z daną usługą (np. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 26

27 kontakt z wieloma urzędami), identyfikator obywatela nie pozwala na rozróżnienie poszczególnych relacji, w związku z czym potrzebny jest identyfikator specyficzny dla danej usługi. W przypadku bardziej złożonych relacji (na przykład takich jak opisane w następnym rozdziale Trudne przypadki) koniecznośd odwzorowania pojedynczego zestawu poświadczeo na odpowiedni, właściwy w danym kontekście identyfikator, jest jeszcze bardziej oczywista. Nawet jeśli bezpośrednie zastosowanie numeru identyfikacyjnego obywatela jest technicznie możliwe, mogą pojawid się wątpliwości dotyczące poufności danych. Takie stosowanie numeru identyfikacyjnego stoi także w sprzeczności z podstawowymi zasadami zarządzania tożsamością. Chodzi głównie o zasady minimalnego zakresu ujawniania niezbędnych informacji oraz tożsamości ukierunkowanej, opisane w dokumencie The Laws of Identity pod adresem W czasie obsługi interakcji użytkownika z usługą należy uwierzytelnid użytkownika (jeśli to możliwe na podstawie pojedynczego zestawu poświadczeo), a następnie przekazad usłudze jedynie specyficzne dla niej identyfikatory dotyczące tej interakcji. Nie należy ujawniad głównego identyfikatora użytkownika, który mógłby zostad użyty do skorelowania tożsamości użytkownika w poszczególnych usługach. W przypadkach, gdy taka korelacja jest korzystna i potrzebna (na przykład w celu zapewnienia lepszej obsługi użytkowników i agregacji usług), musi ona zostad przeprowadzona jawnie i za zgodą użytkownika. Korelowanie informacji o użytkowniku bez uzyskania zgody tego użytkownika jest niedozwolone raz ze względu na dobre praktyki, dwa na uwarunkowania prawne. W niektórych krajach, takich jak Francja, Portugalia czy Wielka Brytania, tworzenie takich korelacji jest zabronione prawem. Zapewnienie niezawodnego, bezpiecznego, jednokierunkowego odwzorowania tożsamości użytkownika na specyficzne dla usług i właściwe dla kontekstu interakcji identyfikatory to podstawowe zadanie, realizowane przez powszechną infrastrukturę dla sektora publicznego, współdzieloną przez wszystkie usługi wchodzące w skład systemu. Trudne przypadki W przypadku usług dla sektora publicznego dośd powszechne są sytuacje, których nie da się obsłużyd prostymi, tradycyjnymi metodami zarządzania dostępem. O ile zasada jeden użytkownik, jeden zestaw poświadczeo, dostęp do wielu usług to dobra podstawa, istnieją jednak sytuacje, w których potrzebne są bardziej złożone relacje pomiędzy użytkownikami a usługami docelowymi (np. jeden do wielu lub wielu do wielu): Wiele osób, z których każda posiada własny zestaw poświadczeo, uzyskuje dostęp do tej samej usługi docelowej w tym samym kontekście (innymi słowy, każda z tych osób korzysta z tego samego identyfikatora specyficznego dla usługi). Sytuacja taka ma miejsce w przypadku urzędników określonej organizacji czy pracowników przedsiębiorstwa lub korporacji. Odpowiednio umocowany reprezentant, korzystający z pojedynczego zestawu poświadczeo, uzyskuje dostęp do jednej usługi docelowej, działając w imieniu wielu klientów w różnych kontekstach, a więc używa różnych identyfikatorów specyficznych dla usługi. Ten typ uwierzytelniania dostępu można uzyskad poprzez powiązanie poświadczeo tożsamości określonej osoby z usługą docelową. Każdorazowe uzyskanie dostępu będzie wymagało podania informacji na temat kontekstu. Istotne jest także zapewnienie niezaprzeczalności (nonrepudiation) i możliwości śledzenia realizowanych transakcji, a także inspekcji wykorzystywanych poświadczeo. Utrzymywanie takich powiązao, a także śledzenie ich wykorzystania (o ile nie zmieniają się bardzo często) można realizowad w ramach wspólnej infrastruktury dla sektora publicznego, współdzielonej przez wszystkie usługi, zamiast w każdej usłudze z osobna. Rozwiązanie takie ma dwie zalety. Po pierwsze, implementowane jest tylko jednokrotnie, po drugie nie wymaga modyfikowania istniejących systemów, których dostosowanie do nowych potrzeb może byd utrudnione. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 27

28 Początkowa identyfikacja użytkowników Bezpieczne udostępnianie usług uzależnione jest od rozwiązania problemu identyfikacji początkowej, to jest od przydzielania poświadczeo tożsamości konkretnym osobom. Prawidłowa identyfikacja początkowa jest niezwykle istotna dla ogólnego bezpieczeostwa i udanego wdrożenia rozwiązania. W przypadku platformy dla sektora publicznego, gdzie liczba użytkowników może sięgad wielu milionów, a każdy z użytkowników korzysta z rosnącej liczby usług, niezwykle istotne jest przeprowadzenie tej identyfikacji w sposób efektywny, skalowalny i wystarczająco elastyczny, by uwzględnid szeroki zakres wymagao. Istnieje kilka sposobów początkowej identyfikacji użytkownika: - Scentralizowany pojedynczy, zunifikowany mechanizm początkowej identyfikacji użytkowników. Po początkowym zidentyfikowaniu użytkownika i przydzieleniu mu poświadczeń tożsamości, wszystkie kolejne relacje z różnymi usługami inicjowane są na podstawie tej jednokrotnej identyfikacji początkowej, co implikuje, że wszystkie usługi opierają się na zunifikowanej procedurze identyfikacji początkowej i ufają jej. - Zdecentralizowany (związany z usługami) relacje pomiędzy użytkownikiem a poszczególnymi usługami nawiązywane są indywidualnie i są niezależne od relacji z innymi usługami. W takim wypadku nie występują związki zaufania ani zależności pomiędzy usługami. Poszczególne usługi mogą definiować własne, odpowiednie i różne reguły i procedury identyfikacji początkowej. - Zaufanie ukierunkowane poszczególne usługi mogą opierać się na procedurach identyfikacyjnych innych usług. Inaczej mówiąc, mogą ufać tym usługom. Model ten jest podobny do modelu scentralizowanego, pozwala jednak na tworzenie wielu różnych związków zaufania. Model scentralizowany może wydawad się atrakcyjny, prostszy i bardziej efektywny, istnieje jednak kilka przeszkód utrudniających udaną implementację tego modelu w rozwiązaniach dla sektora publicznego: Model ten wymaga istnienia nadrzędnego organu, któremu ufają i będą ufad wszystkie inne usługi i który będzie prowadził scentralizowany proces identyfikacji. Nawet jeśli dostawcy początkowego zestawu usług uzgodnią odpowiadający im wspólny proces identyfikacji początkowej, to nie ma gwarancji, że powstające w przyszłości usługi będą pasowały do tego modelu. Wymagany poziom szczegółowości i niezawodności identyfikacji początkowej jest różny dla różnych kategorii usług, dlatego pojedyncza uniwersalna procedura identyfikacji musi gwarantowad najwyższy poziom pewności, jaki może byd wymagany przez dowolną z usług. Może to byd zbyt uciążliwe dla użytkowników, którzy korzystają wyłącznie z usług o niższych wymaganiach co do identyfikacji początkowej. Model zdecentralizowany (związany z usługami) daje większą elastycznośd i pozwala na uwzględnienie szerszego zakresu wymagao, włącznie z wymaganiami zmiennymi w czasie i nieznanymi podczas pierwotnej implementacji systemu. Jeśli identyfikacja początkowa zostanie oparta na podstawowej, wspólnej strukturze, pozwalającej na stosowanie wymiennych reguł, definiowanych przez poszczególne usługi, rozwiązanie może łatwo ewoluowad można w nim wprowadzad dodatkowe wymagania dla nowych usług bez wpływu na działanie usług już istniejących. Jeśli liczba oferowanych przez system usług jest znaczna, taki zdecentralizowany, związany z usługami model jest jedynym realnym rozwiązaniem. Szczegółowe praktyczne wskazówki dotyczące implementacji efektywnego, zdecentralizowanego modelu identyfikacji początkowej można znaleźd w rozdziałach poświęconych zarządzaniu tożsamością w sekcjach Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego oraz Elementy składowe typowego rozwiązania integracyjnego dla sektora publicznego niniejszego opracowania. Model zdecentralizowany, opisany w sekcji Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego dzięki elastyczności wymiennych modułów uwierzytelniania początkowego pozwala także na implementację RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 28

29 modelu zaufania ukierunkowanego, który może obejmowad sprawdzenie, czy dany użytkownik został wcześniej zidentyfikowany przez inną usługę. Problemy integracji W przypadku inicjatyw dla sektora publicznego prawdopodobnie największym wyzwaniem jest efektywna integracja pośredniczącego w kontaktach z klientami huba ze stale rosnącą liczbą specjalizowanych systemów, specyficznych dla poszczególnych usług. Podczas gdy nawet najbardziej złożone systemy komercyjne muszą zapewnid integrację ze skooczonym, dobrze znanym już na początkowych etapach projektu zestawem systemów, przed rozwiązaniami z zakresu sektora publicznego stoi zwykle znacznie trudniejsze zadanie. Muszą one zapewnid platformę umożliwiającą integrację większych i w pewnym zakresie nieznanych zestawów usług, które są dostępne obecnie albo będą dostępne dopiero w przyszłości. Ułatwienie zadao integracji oraz zapobieganie przerwom w dostępności istniejących usług to ważny warunek udanego wdrożenia rozwiązania dla sektora publicznego. Różne możliwości integracji W kolejnych sekcjach tego dokumentu opisano różne możliwe sposoby integrowania odrębnych systemów (działających na różnych platformach z różnymi zestawami oprogramowania). Wybór najlepszego wariantu zależy od różnych ograniczeo, wymaganego typu integracji i współpracy oraz od innych czynników. Uwaga szczegółowe wytyczne Microsoft, dotyczące tego zagadnienia, można znaleźd w dokumencie Integration Patterns pod adresem Integracja natywna Warunkiem natywnej integracji dwóch systemów jest ich kompatybilnośd na odpowiednio wysokim poziomie (patrz sześd poziomów podstawowego modelu interoperacyjności wymienionych na początku tego opracowania). Innymi słowy, infrastruktura i systemy sieciowe, funkcje dostępu do danych, model usługowy i komponentowy, sposoby integracji procesów, implementacja systemu zabezpieczeo i zarządzania tożsamością oraz sposoby zarządzania systemem muszą byd wzajemnie kompatybilne w obu integrowanych rozwiązaniach. Jeśli obydwa systemy mogą współpracowad ze sobą, to do ich integracji byd może potrzebny będzie tylko minimalny nakład pracy. Do niedawna taka integracja była możliwa tylko wtedy, gdy obydwa systemy pracowały na tej samej platformie i oparte były na kompatybilnych: oprogramowaniu, modelu obiektowym i narzędziach programistycznych. Obecnie dzięki architekturze zorientowanej na usługi (SOA) taką interoperacyjnośd można uzyskad pomiędzy znacznie bardziej zróżnicowanymi platformami, o ile tylko są one zgodne z ogólnie przyjętymi standardami. Natywna integracja to idealne rozwiązanie dla systemów sektora publicznego. Należy dążyd do niego zawsze, gdy jest to możliwe, ponieważ pozwala na zminimalizowanie nakładów pracy niezbędnych do pełnej integracji. Architektura powinna jednak uwzględniad także przypadki, w których ograniczenia istniejących lub przyszłych systemów, niewspierających lub niemogących wspierad standardowych interfejsów SOA (takich jak usługi Web Services), mogłyby uniemożliwid integrację. Adaptery w hubie Jedną z typowych metod integrowania różnorodnych systemów, które byd może pracują na różnorodnych platformach, jest wbudowanie odpowiednich adapterów w system centralny, czyli hub. Każdy z adapterów zapewnia dostęp do innego typu systemu zdalnego. Podejście to przedstawiono na ilustracji 1. hub zawiera cztery adaptery, które z wykorzystaniem czterech technologii integracyjnych zapewniają dostęp do czterech usług. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 29

30 Ilustracja 1. Integracja różnych systemów poprzez zastosowanie adapterów wewnątrz huba Zaletą tego rozwiązania jest to, że nie trzeba wprowadzad zmian w systemach zdalnych to hub wykonuje wszystkie dodatkowe prace, takie jak tłumaczenie protokołów sieciowych, transformowanie danych, dopasowywanie semantyki, zarządzanie przepływem wymienianych komunikatów. Rozwiązanie to ma jednak pewne wady: Komunikacja pomiędzy hubem, wewnątrz którego znajdują się adaptery, a systemami zdalnymi odbywa się za pomocą natywnych protokołów tych systemów. Stosowanie tych protokołów poza granicami systemów macierzystych może byd kłopotliwe lub niemożliwe, jeżeli komunikacja ma odbywad się poprzez sied WAN lub poprzez Internet. Rozszerzenie integracji na systemy nowego typu wymaga wprowadzenia zmian w hubie konieczne jest dodanie nowego adaptera, co może mied wpływ na pracę innych usług. Rozwiązanie to charakteryzuje się ograniczoną skalowalnością, co może mied duże znaczenie z tego względu, że liczba i zróżnicowanie zintegrowanych systemów stale wzrastają. Realizacja rozwiązania polegającego na umieszczeniu adapterów w centralnym hubie nie jest zwykle realna. Wyjątkiem może tu byd system składający się z kilku adapterów wspierających powszechnie stosowane i dobrze znane standardy. Adaptery w systemach zdalnych Alternatywą powyższej metody jest stosowanie adapterów zdalnych. W takim wypadku adaptacja cech charakterystycznych danego systemu zdalnego łączności i protokołów sieciowych, formatów danych i semantyki komunikatów realizowana jest wewnątrz tego systemu. Każdy system jest sam odpowiedzialny za zapewnienie sposobu komunikacji zgodnego z ogólnie przyjętym standardem. Obecnie powszechnie przyjętym i rekomendowanym standardem, stosowanym do tego celu, są usługi Web Services. System zdalny, wyposażony w odpowiedni adapter, może zostad w sposób natywny zintegrowany z hubem. Zakres niezbędnych prac integracyjnych zależy od tego, na ile system zdalny różni się od przyjętego standardu komunikacji. Zwykle jednak jest porównywalny z zakresem prac wymaganym do przygotowania rozwiązania adapter w hubie jedynie umiejscowienie adaptera jest inne. Adapter może zostad utworzony jako nowa częśd pierwotnego systemu zdalnego lub zaimplementowany osobno z wykorzystaniem platformy pośredniczącej. Ta druga metoda może byd przydatna w przypadku, gdy nie jest możliwe wprowadzenie zmian w istniejących systemach. Zarys architektury, której adaptery umieszczone są w systemach zdalnych, ale nie są ich częścią, przedstawiono na ilustracji 2. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 30

31 Ilustracja 2. Integracja różnych systemów poprzez zastosowanie adapterów w systemach zdalnych Cechy charakterystyczne takiego rozwiązania to: Każdy system jest odpowiedzialny za zapewnienie standardowego sposobu komunikacji; implementacja integracji realizowana jest lokalnie w systemie docelowym, dlatego potencjalnie jest łatwiejsza. Zestandaryzowany sposób komunikacji z systemami zdalnymi za pośrednictwem wydzielonej sieci WAN lub innych sieci, takich jak Internet. Dodawanie nowych usług jest łatwe, ponieważ nie ma potrzeby wprowadzania modyfikacji w hubie centralnym; do huba nie trzeba dodawad nowych adapterów, a integracja ze wszystkimi zdalnymi usługami realizowana jest w ten sam zestandaryzowany sposób. Pomimo że pomiędzy adapterami dla poszczególnych usług może istnied pewne podobieostwo, nakłady pracy poświęcanej na integrację zależą od liczby integrowanych systemów, a często to samo zadanie realizowane jest wielokrotnie. Rozdzielenie integracji ogólnej i specyficznej Adaptery integracyjne są specyficzne, dostosowane i unikatowe dla każdego systemu docelowego, charakteryzują się jednak pewną wspólną funkcjonalnością, niezbędną do integracji obsługiwanych przez nie systemów zdalnych z hubem centralnym. Wydzielenie takiej ogólnej funkcjonalności (na przykład bezpieczeostwo, niezawodnośd komunikacji, zarządzanie przepływem komunikatów) z adaptera integracyjnego niesie pewne korzyści. Daje na przykład możliwośd wielokrotnego wykorzystywania ogólnej podstawy integracyjnej, co eliminuje powtarzanie realizacji niektórych zadao integrując nową usługę z systemem wystarczy zaimplementowad funkcjonalnośd specyficzną dla tej usługi. Na ilustracji 3. przedstawiono wielokrotne wykorzystanie określonych elementów rozwiązania integracyjnego (na ilustracji oznaczono je literą X) w wielu adapterach, co skraca czas i zmniejsza nakłady pracy związane z implementacją integracji. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 31

32 Ilustracja 3. Wielokrotne wykorzystanie ogólnych składników integracyjnych w wielu adapterach systemów zdalnych Wspólne rozwiązanie integracyjne Następnym logicznym krokiem jest utworzenie wspólnej implementacji ogólnej funkcjonalności integracyjnej, co jest korzystne dla wszystkich usług zdalnych. Jednokrotne zainwestowanie w zaprojektowanie, utworzenie i przetestowanie takiego rozwiązania integracyjnego i udostępnienie go dostawcom usług jako podstawy dla ich własnych rozwiązao integracyjnych pozwala uzyskad znaczne oszczędności przy jednoczesnym zachowaniu wysokiej jakości rozwiązania podstawowego. Wspólne rozwiązanie integracyjne może efektywnie obsłużyd większośd trudnych zagadnieo, dotyczących niezawodności komunikacji, bezpieczeostwa i innych wymagao, do których realizacji niezbędne może byd zatrudnienie wysoko wykwalifikowanych specjalistów, na co nie każda agencja może sobie pozwolid zwłaszcza że usługi dla sektora publicznego zaczynają byd świadczone przez mniejsze, regionalne jednostki. Realizacja lokalnie, w systemie docelowym, jedynie integracji specyficznej dla danej usługi może byd znacznie łatwiejsza niż utworzenie pełnego rozwiązania integracyjnego do komunikacji z hubem. Połączenie takiego podejścia do projektowania struktury z odpowiednim nadzorem i działaniami handlowymi (na przykład udostępnienie kompletnego, bazowego rozwiązania integracyjnego, obejmującego sprzęt, oprogramowanie, instalację i wsparcie techniczne) może w znaczący sposób wpłynąd na popularyzację dostarczania usług dla sektora publicznego drogą elektroniczną. Zalety takiego właśnie podejścia do problemu integracji zostały potwierdzone pozytywnymi doświadczeniami w wielu krajach. Jest to znacznie lepsze rozwiązanie niż udostępnienie potencjalnym dostawcom usług jedynie specyfikacji sposobu komunikacji z hubem i pozostawienie ich samym sobie. Elastycznośd i sprawnośd Dla większości systemów możliwośd efektywnego radzenia sobie ze zmianami oraz adaptacji do nowych wymagao to koniecznośd. W przypadku rozwiązao integracyjnych dla sektora publicznego cechy te są jeszcze ważniejsze szybkośd wzrostu i liczba niewiadomych na początku projektu sprawiają, że częstotliwośd zmian w tych systemach jest zwykle wysoka. Również potrzeba zapewnienia kompatybilności wstecznej z wdrożonymi wcześniej systemami i wcześniejszymi wersjami oprogramowania jest szczególnie silna. Dlaczego elastycznośd i sprawnośd są tak ważne Rozwiązanie integracyjne dla sektora publicznego to platforma, która musi wspierad stale rosnącą liczbę usług. W odróżnieniu od wielu systemów komercyjnych, gdzie liczba i zróżnicowanie obecnych i przyszłych usług i kanałów dostępu są zwykle dobrze znane, w przypadku platformy integracyjnej dla sektora publicznego musi istnied możliwośd dostosowania jej do zmieniających się wymagao (niezależnie od tego, czy zmiany te można było przewidzied, czy nie) i to najlepiej bez konieczności przeprojektowywania czy zakłócania pracy istniejących usług. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 32

33 W wielu krajach można spotkad się z następującym schematem: rozwiązanie dla sektora publicznego powstaje jako projekt pilotowy lub jako sprawdzenie koncepcji i obejmuje kilka precyzyjnie wybranych usług (dobranych na podstawie widoczności tych usług, pilności ich udostępnienia i łatwości dostarczenia w postaci elektronicznej). Po udanej fazie wstępnej bardzo szybko rosną ambicje i chęd udostępnienia większej liczby usług. Równocześnie pojawiają się oczekiwania, że dopiero co wdrożona platforma powinna bez trudu poradzid sobie z tym zadaniem. Zmiany takie jak udostępnienie nowych usług, wdrożenie nowych mechanizmów uwierzytelniania czy nowych kanałów dostępu nie mogą byd traktowane jako rzadkie przypadki, wymagające okresowego wdrażania nowych wersji platformy integracyjnej dla sektora publicznego. Wdrażanie nowych usług powinno byd standardową funkcją systemu. Warunek ten musi zostad we właściwy sposób uwzględniony w projekcie architektury systemu, muszą też powstad odpowiednie narzędzia i procedury. Idealne rozwiązanie powinno pozwalad na wprowadzanie takich zmian w działającym systemie bez potrzeby wstrzymywania jego pracy. Udane wdrożenia w kilku krajach potwierdziły, że opracowanie takiego systemu jest możliwe. Tworzenie architektury z myślą o elastyczności Uzyskanie tak wysokiej elastyczności to główny wyznacznik docelowej architektury systemu. Umożliwienie wprowadzania w systemie tak dużych zmian (dodawanie nowych usług, nowych typów transakcji, modyfikowanie reguł walidacji danych, rekonfigurowanie reguł przepływu informacji) i to bez modyfikowania kodu rozwiązania wymaga, by rozwiązaniem można było zarządzad za pomocą parametrów konfiguracyjnych i danych modyfikowanych zgodnie z potrzebami wtedy, gdy potrzeby te występują. Architektura, która z założenia wspiera modułowośd na każdym poziomie (mechanizmy autoryzacji, modele identyfikacji, reguły specyficzne dla usług), to warunek konieczny. Jeśli założymy, że wymagania i reguły związane z poszczególnymi usługami ulegają zmianom (jeśli nie już na pierwszych etapach projektu, to na pewno w przyszłości), to architektura rozwiązania musi wspierad klasyfikację. Pozwala to zminimalizowad liczbę powszechnych reguł i przepływów komunikatów, które będą musieli obsługiwad dostawcy w celu uwzględnienia ich usług w systemie. Gdy rozwiązanie musi wspierad stale rosnącą liczbę usług, unikanie zakładania z góry określonego sposobu komunikacji, konfiguracji zabezpieczeo czy narzucania innych ograniczeo logistycznych to koniecznośd. Zabezpieczanie rozwiązania Ze wszystkich problemów, jakie architekci oprogramowania i programiści muszą rozwiązad, tworząc platformę integracyjną dla sektora publicznego, bezpieczeostwo jeśli nie zostanie we właściwy sposób zaimplementowane na wszystkich poziomach, w całym zakresie aplikacji może sprawid największe kłopoty. Zabezpieczenia często traktowane są jako funkcje dodatkowe, o które można zacząd się martwid już po zaprojektowaniu i wdrożeniu rozwiązania. Takie podejście to proszenie się o kłopoty. Bezpieczeostwo musi zostad uwzględnione w architekturze aplikacji już na początku projektu. Dlaczego bezpieczeostwo jest tak ważne? Wszystkie witryny internetowe, usługi i aplikacje muszą stale bronid się przed utratą danych, atakami użytkowników działających w złych zamiarach, atakami automatycznych programów (takich jak wirusy i robaki internetowe) oraz przed przestojami powodowanymi przez ataki DoS (Denial of Service zablokowanie usługi). Projekty w zakresie sektora publicznego niosą ze sobą szczególne ryzyko nawet większe niż w przypadku instytucji finansowych, takich jak banki internetowe. Jest tak, ponieważ systemy takie są ważnym celem dla: osób próbujących dokonad kradzieży tożsamości na przykład pobrad szczegółowe informacje dotyczące zeznao podatkowych, prawa jazdy, paszportu, dokumentacji medycznej i innych szczegółowych informacji umożliwiających kradzież tożsamości użytkownika, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 33

34 anarchistów i politycznie zaangażowanych włamywaczy, mających na celu włamanie się do systemu i spowodowanie jak największych zniszczeo, ataków na indywidualnych użytkowników, podyktowanych celami pozapolitycznymi, na przykład prób podważenia bezpieczeostwa systemu w oczach użytkownika lub uniemożliwiania mu dostępu do usług, z których ma prawo korzystad, nadużyd lub prób nadużyd poprzez nieautoryzowaną modyfikację danych, na przykład w celu uniknięcia płatności podatku dochodowego, obrotowego lub od wartości dodanej. Do ataków tego typu można również zaliczyd próby zatarcia śladów wykonania działao, co przez opinię publiczną nie zawsze jest uznawane za nadużycie. Niektóre organizacje i instytucje starają się ukryd rezultaty naruszeo ich systemów bezpieczeostwa. Aplikacje dla sektora publicznego charakteryzują się jednak dobrą widocznością dla społeczeostwa, a więc każdy udany atak z pewnością nie zostanie przeoczony przez użytkowników. Wydarzenia takie stawiają organizację w kłopotliwej sytuacji zarówno pod względem politycznym, jak i w zakresie public relations wobec dostawców i użytkowników. Efektem nawet najmniejszych problemów z bezpieczeostwem mogą byd nieprzewidziane koszty oraz utrata zaufania użytkowników i innych organizacji, a więc na dłuższą metę utrudnienie upowszechnienia usług elektronicznych. Projektowanie bezpiecznych rozwiązao Szczegółowe wskazówki dotyczące projektowania i tworzenia bezpiecznych rozwiązao zawarto w sekcji Bezpieczeostwo w rozdziale Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego niniejszego przewodnika. Wskazówki obejmują między innymi sposób zastosowania wielu warstw zabezpieczeo do realizacji trzech głównych celów (poufnośd, integralnośd danych, niezawodne uwierzytelnianie). Opisano także zagadnienia związane z modelowaniem zagrożeo oraz dostępne środki zaradcze. Bezpieczeostwo zależy jednak od czegoś więcej niż od samej implementacji technicznej. Aby rozwiązanie mogło byd na bieżąco przystosowywane do stale zmieniających się wymagao w zakresie bezpieczeostwa, podczas projektowania należy wziąd pod uwagę dodatkowe uwarunkowania: możliwośd stopniowego rozbudowywania i wprowadzania nowych usług i funkcji, zapewnienie bezpiecznych sposobów przechowywania istotnych danych, wykorzystanie kluczy cyfrowych i certyfikatów, zarządzanie zespołem programistycznym i metodologią implementacji w celu zagwarantowania przestrzegania najlepszych praktyk, przetestowanie zabezpieczeo aplikacji we wszystkich możliwych sytuacjach w celu upewnienia się, że projekt architektury jest poprawny i spełnia założone wymagania odnośnie bezpieczeostwa, wprowadzenie odpowiednich zabezpieczeo w trakcie oraz po wdrożeniu środowiska; upewnienie się, że konfiguracja i bezpieczeostwo instalacji spełniają założone wymagania, monitorowanie wydajności aplikacji i usług, inspekcja procesów, tworzenie planów awaryjnych na wypadek włamania lub uszkodzenia danych, stałe działania mające na celu analizowanie nowo odkrytych zagrożeo bezpieczeostwa, regularne aktualizowanie sprzętu i oprogramowania z wykorzystaniem dodatków service pack. Firma Microsoft stara się ułatwid projektowanie, tworzenie i wdrażanie bezpiecznych rozwiązao, zapewniając przewodniki, wzorce i przykłady, szczegółową dokumentację dla programistów oraz udokumentowane najlepsze praktyki. Materiały te można znaleźd w witrynie Microsoft Security Developer Center pod adresem RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 34

35 Skalowalnośd, wydajnośd, dostępnośd Rozwiązania dla sektora publicznego muszą zwykle spełniad rygorystyczne wymagania pod względem wydajności i skalowalności. Ze względu na swą naturę, wiele interakcji z usługami administracji publicznej jest realizowane dośd rzadko raz na rok lub raz na kwartał z charakterystycznymi szczytami aktywności przypadającymi na terminy takie jak koniec roku podatkowego. Wydajnośd tworzonego systemu powinna pozwalad na obsługę takich szczytowych aktywności bez znacznych spadków wydajności. Jest to szczególnie istotne dla powszechnej popularyzacji świadczenia usług dla sektora publicznego drogą elektroniczną. Wszelkie awarie, opóźnienia czy brak dostępności usług w takich krytycznych okresach są kłopotliwe, podważają publiczne zaufanie co do pewności świadczonych usług i mają negatywny wpływ na jeden z najważniejszych czynników istotnych dla popularyzacji elektronicznego dostępu do usług przewagę szybkości interakcji elektronicznych nad tymi obsługiwanymi za pomocą tradycyjnych kanałów dostępu. Rozwiązania dla sektora publicznego, zwykle rozpoczynające swój żywot jako niewielkie projekty, stopniowo rosną i rozbudowują się w miarę wzrostu popularności usług elektronicznych oraz liczby użytkowników korzystających z takich usług. Gdy usługi udostępniane są za pośrednictwem współdzielonej infrastruktury, to poza wzrostem intensywności korzystania z każdej z usług, mamy też wzrost liczby usług. Warto więc dwukrotnie przemyśled i zweryfikowad szacowane i przewidywane współczynniki wzrostu. Zbyt często nasze założenia są za bardzo optymistyczne. Podstawowym wyznacznikiem jest ocena takich czynników poprzez porównanie ich z dostępnymi, znanymi wskaźnikami statystycznymi (obecna liczba interakcji w ramach tradycyjnych kanałów dostępu, rozpowszechnienie usług elektronicznych w podobnych obszarach zastosowao) oraz ograniczeniami (przepustowośd sieci, możliwości wykorzystywanych systemów zaplecza). W kilku przypadkach proste oszacowanie na podstawie liczby interakcji pomnożonej przez średni ruch generowany przez taką interakcję dało wyniki znacznie przekraczające przepustowośd wykorzystywanej sieci, jasno pokazując, że przyjęte wcześniej założenia były nierealne i niemożliwe do osiągnięcia z powodu innych ograniczeo. Ślepe akceptowanie takich przewidywanych wymagao w zakresie wydajności, a także próby spełnienia tak postawionych założeo mogą niepotrzebne skomplikowad projekt i implementację platformy dla sektora publicznego. Wskazówki na temat projektowania wydajnych i skalowalnych rozwiązao dla sektora publicznego można znaleźd w sekcji Wydajnośd i skalowalnośd rozdziału Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego tego opracowania. Dostępnośd i odpornośd Z zagadnieniami skalowalności i wydajności aplikacji związane są także inne problemy. Ograniczona wydajnośd w oczywisty sposób wpływa na dostępnośd rozwiązania, powodując chwilowe lub nawet długotrwałe utrudnienia dla użytkowników próbujących uzyskad dostęp do aplikacji i korzystad z niej. Zapewnienie wysokiej dostępności oznacza zagwarantowanie, że wszystkie składniki infrastruktury, takie jak sprzęt, oprogramowanie czy sied, są odporne na awarie. Innymi słowy, żadna pojedyncza awaria nie powinna zatrzymywad pracy całego systemu. Zagadnienia dostępności i odporności dotyczą wielu problemów związanych z architekturą rozwiązania. W sekcji Wydajnośd i skalowalnośd rozdziału Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego opisano, jak skalowanie sprzętu dzięki wykorzystaniu wielu komponentów lub zastosowaniu komponentów redundantnych pozwala na ochronę systemu przed przestojami, powodowanymi przez pojedynczą awarię sprzętu lub oprogramowania, poprzez przejmowanie pracy uszkodzonych komponentów. Odtwarzanie po awariach Oczywiście nie można zagwarantowad, że awaria nigdy się nie wydarzy. Awaria może zostad spowodowana błędem w oprogramowaniu, uszkodzonym komponentem sprzętowym, a nawet byd skutkiem uszkodzenia łącza internetowego przez ekipę wykonującą w okolicy roboty RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 35

36 drogowe. W przypadku poważniejszych wydarzeo, takich jak pożar lub katastrofa budowlana budynku, w którym zainstalowane są serwery, awaria aplikacji jest prawie że gwarantowana. Innymi przyczynami awarii mogą byd złośliwe działania operatorów systemu, nieumyślne pomyłki personelu czy błędy logiczne danych, które mogą spowodowad utratę zawartości całych macierzy dyskowych. Aby móc poradzid sobie z takimi problemami, niezbędne jest opracowanie szczegółowego, ścisłego, w pełni przetestowanego planu postępowania na wypadek takiej awarii. Plan powinien obejmowad wszystkie możliwości od ponownego wczytania danych z dysków lub taśm zapasowych po przeniesienie działalności do innej lokalizacji, wyposażonej w sprzęt i oprogramowanie gotowe do natychmiastowego podjęcia pracy. Istnieją na rynku firmy świadczące usługi planowania i utrzymywania takich systemów, co może pozwolid na znaczne zredukowanie czasu przestoju aplikacji, których stała dostępnośd jak w przypadku rozwiązao dla sektora publicznego może byd sprawą najwyższej wagi. Konstrukcja wspólnego huba Powszechne rozwiązanie integracyjne dla sektora publicznego, współdzielone przez wiele usług, pozwala w efektywny sposób rozwiązad wiele z przedstawionych dotychczas problemów. Bardziej szczegółowe informacje na ten temat zamieszczono w sekcji Hub usług rozdziału Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego w tym przewodniku. Chociaż rozwiązanie to charakteryzuje się niewątpliwymi zaletami, jego wdrożenie może wiązad się z koniecznością pokonania wielu przeszkód natury politycznej lub komercyjnej oraz innych utrudnieo. Najważniejsze z tych zagadnieo omówiono w kolejnych sekcjach dokumentu. Potrzeba ustalenia właściciela lub finansującego W wielu krajach jednostki administracji publicznej wdrażają własne, oddzielne, nieskoordynowane ze sobą rozwiązania dla sektora publicznego, będące często rozszerzeniami systemów i projektów prowadzonych już przez te instytucje. Nawet jeśli istnieje jakiś centralny organ, odpowiedzialny za inicjatywy dla sektora publicznego, może on mied zbyt małe możliwości, by wspierad i koordynowad implementację wspólnej infrastruktury sektora publicznego oraz zbyt małe fundusze, by zaprojektowad, opracowad i wdrożyd taką infrastrukturę. W efekcie nawet jeśli większośd uczestników rynku uzna zalety stosowania wspólnej platformy integracyjnej i przekona się o możliwych oszczędnościach bez jasnego wskazania właściciela i finansującego, rozwiązanie takie ma nikłe szanse na praktyczną realizację. Najlepsze rezultaty można osiągnąd, gdy istnieje centralna instytucja, posiadająca niezbędną władzę i zasoby finansowe umożliwiające popularyzację usług dla sektora publicznego, która może pokierowad pracami nad tworzeniem wspólnej platformy integracyjnej. Początkowa inwestycja z odroczonymi korzyściami Inwestycja w opracowanie architektury, zaprojektowanie, utworzenie i wdrożenie wspólnej platformy to pierwszy krok w kierunku udostępnienia efektywnych usług dla sektora publicznego. W początkowych fazach tworzona jest jednak tylko podstawowa infrastruktura. Infrastruktura ta nie jest widoczna dla użytkownika koocowego i bezpośrednio nie przynosi żadnych korzyści. Jest jedynie gwarancją sukcesu usług dla sektora publicznego, które są stopniowo udostępniane. Aby móc zademonstrowad zalety nowej platformy, potrzebne jest szybkie wdrożenie początkowego zestawu usług. Dzięki temu dostawcy usług i konsumenci usług szybciej zobaczą bardziej namacalne korzyści. Co więcej, jeśli platforma została poprawnie zaprojektowana i zaimplementowana, ogólne korzyści będą coraz lepiej widoczne wraz z każdą nową usługą dodaną do platformy. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 36

37 Typowe konflikty z projektami indywidualnymi Podczas jednoczesnych prac projektowania i implementowania platformy integracyjnej dla sektora publicznego oraz początkowego zestawu usług, które będą udostępniane w oparciu o tę platformę, pojawiają się napięcia powodowane różnicami pomiędzy ogólnym charakterem platformy a specyficznymi wymaganiami każdej z usług. O ile napięcia takie sprzyjają kreatywności i mają pozytywny wydźwięk, stanowiąc dobry sposób walidacji styku pomiędzy platformą a dostawcami usług na wczesnych stadiach projektu, mogą także wywierad negatywny wpływ na projekt platformy powodując, że zostanie w niej zaimplementowana funkcjonalnośd, która nie powinna się tam w ogóle znaleźd. Pod silną presją ciasnych ram czasowych i ograniczonych środków finansowych, wśród wykonawców odpowiedzialnych za poszczególne części projektu szczególnie wyraźnie widoczna staje naturalna tendencja przesuwania granicy pomiędzy usługami i przekazywania części zadao komuś innemu. W powiązaniu z faktem, że projekty dla sektora publicznego często prowadzone są przez jedną lub kilka silnych podmiotów, które zwykle zakres i budżet projektu wspólnej infrastruktury ustalają samodzielnie, naciski na przesunięcie części funkcjonalności szczególnie tej, która nie jest całkowicie ogólna, ale zaimplementowanie jej w platformie przyniosłoby oszczędności czasu i kosztów mogą byd bardzo duże. Działania takie z pewnością naruszą integralnośd architektury i będą miały wpływ na pozostałe usługi, które trzeba będzie dostosowad do zmian wprowadzonych dla wygody zaledwie kilku osób. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 37

38 Architektura referencyjna ogólnego rozwiązania integracyjnego dla sektora publicznego W tej sekcji przedstawiamy typową referencyjną architekturę rozwiązania integracyjnego dla sektora publicznego, opartą na połączonej platformie Microsoft Ramy Interoperacyjności Systemów Administracji Publicznej. Na rozdział ten składają się następujące sekcje: - Reguły rządzące architekturą omówienie ogólnych zasad projektowania oraz architektury zorientowanej na usługi (Service Oriented Architecture SOA), na której oparta jest cała platforma. - Hub usług jak zapewnid wspólną infrastrukturę, z której może korzystad wielu dostawców usług dla sektora publicznego. - Zarządzanie tożsamością opis zadao takich jak początkowa identyfikacja użytkowników, przydzielanie poświadczeo, rejestrowanie użytkowników w usługach, zarządzanie rejestracjami użytkowników i przypisywanie uprawnieo wewnątrz usługi. - Uwierzytelnianie i autoryzacja bardziej szczegółowy opis implementacji funkcji uwierzytelniania (w tym uwierzytelniania stowarzyszonego ang. federated authentication), autoryzacji, stosowania tokenów bezpieczeostwa oraz technik udostępniania usług uwierzytelniania i autoryzacji. - Katalog usług analiza możliwości zastosowania katalogu do zapewnienia przezroczyści lokalizacji usług tak, by zmiana fizycznej lokalizacji świadczenia usługi nie powodowała awarii aplikacji. - Rejestracja dokumentów zastosowanie usługi rejestracji dokumentów, umożliwiającej przyjmowanie i przetwarzanie dokumentów w imieniu klienta, może uprościd interakcję z użytkownikami i umożliwid orkiestrację procesów z uwzględnieniem usług zaplecza - Orkiestracja procesów biznesowych silnik orkiestracji współpracujący z usługą rejestracji dokumentów pozwala zagwarantowad, że komunikaty będą poprawnie przetwarzane na każdym etapie procesu i na podstawie odpowiedniego zestawu reguł dostarczane do wielu punktów koocowych (partnerzy, inne usługi, aplikacje itp.). - Integracja z usługami zaplecza w niektórych sytuacjach nie ma możliwości zapewnienia natywnej interakcji istniejących usług zaplecza z hubem usług z wykorzystaniem standardów usług sieciowych i konieczne jest zapewnienie komunikacji w inny sposób. - Bezpieczeostwo w jaki sposób system taki jak rozwiązanie integracji usług dla sektora publicznego może i powinien byd zabezpieczony przed złośliwymi użytkownikami, zautomatyzowanymi atakami, atakami mającymi na celu zablokowanie dostępu do usług (denial of service) oraz ujawnianiem poufnych informacji. - Wydajnośd i skalowalnośd opis zagadnieo związanych z problematyką budowy rozwiązania spełniającego kryteria dostępności, czasu odpowiedzi i wydajności. Omówiono techniki planowania obciążenia i implementacji skalowalnych architektur sprzętowych i software owych. - Zarządzanie i eksploatacja zagadnienia związane z eksploatacją i zarządzaniem rozwiązaniem, świadczeniem pomocy technicznej i wsparcia technicznego, dostarczaniem usług. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 38

39 Reguły rządzące architekturą Aby pomyślnie rozwiązad problemy opisane w tym dokumencie, opisywana architektura referencyjna dla sektora publicznego została przygotowana w oparciu o następujące zasady: Orientacja na usługi Zastosowanie architektury zorientowanej na usługi (Service Oriented Architecture SOA) w implementacji dużych i złożonych systemów informatycznych, jakimi są rozwiązania integracyjne dla sektora publicznego, pozwala na spełnienie warunku podstawowego sprawienie, by systemy te były łatwe w adaptacji, elastyczne i niezawodne. Architektura zorientowana na usługi to struktura oraz zestaw zasad i praktyk pozwalających na implementowanie funkcjonalności aplikacji w usługach dostępnych z zewnątrz. Szczegółowośd dekompozycji na usługi zależy wyłącznie od wymagao strony korzystającej z tych usług usługi pozwalają na wyodrębnienie implementacji części funkcjonalności aplikacji z wykorzystaniem pojedynczego, opartego na standardach, typu interfejsu. Funkcjonalnośd platformy integracyjnej dla sektora publicznego powinna byd dostępna w postaci zestawu ogólnych usług, z których można korzystad niezależnie od innych usług i wtedy, gdy jest to potrzebne. Interfejsy i standardy Dominującą metodą udostępniania usług w sposób zgodny z przyjętymi standardami i niezależny od implementacji oraz wykorzystywanej platformy stają się usługi sieciowe Web Services. Standardy związane z usługami Web Services wdrażane są przez wszystkich wiodących producentów oprogramowania i coraz więcej produktów programistycznych wspiera te standardy. Pozwoli to na stopniowe zmniejszenie ilości pracy poświęcanej na tworzenie kodu pisanego na miarę na rzecz korzystania tam, gdzie jest to możliwe z produktów komercyjnych. Oparcie implementacji podstawowych funkcji oprogramowania, takich jak bezpieczeostwo czy niezawodna komunikacja, na gotowych narzędziach i produktach, pozwoli zmniejszyd koszty i nakłady pracy niezbędne do uzyskania wymaganej funkcjonalności. Szczegółowe informacje oraz łącza do pełnej specyfikacji standardów usług Web Services można znaleźd pod adresem oraz w sekcji Odsyłacze, listy kontrolne i dalsze informacje w ostatniej części tego opracowania. Wyszukiwanie usług Architektura referencyjna zapewnia infrastrukturę pozwalającą na rejestrowanie i wyszukiwanie dostępnych usług (w czasie projektowania lub w czasie pracy aplikacji) oraz repozytorium do przechowywania metadanych opisujących usługi schematów, interfejsów, zasad. Format metadanych odpowiada powszechnie przyjętym standardom branżowym. Stowarzyszone funkcje zabezpieczeo Architektura musi obsługiwad wiele różnych mechanizmów uwierzytelniania, typów poświadczeo, dostawców tożsamości, metod autoryzacji i modeli zaufania. Co więcej, niektóre z nich nie są znane nawet na etapie projektowania architektury. Architektura powinna zatem zapewnid ogólną strukturę, umożliwiającą stopniowe dodawanie nowych dostawców i mechanizmów oraz konstruowanie systemów o różnych topologiach, uwzględniających specyficzne wymagania i ograniczenia. Nie należy zakładad, że możliwe jest centralne uwierzytelnianie i zarządzanie wszystkimi potencjalnymi użytkownikami systemu przez jednego dostawcę usług. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 39

40 Wprowadzenie standardów usług Web Service także w tej przestrzeni pozwoli na uzyskanie interoperacyjności pomiędzy różnymi implementacjami i efektywne wykorzystywanie gdy tylko staną się dostępne produktów komercyjnych o takich możliwościach. Elastycznośd Kluczem do sukcesu rozwiązao dla sektora publicznego jest elastycznośd zapewniana przez architekturę i uwzględniona już na pierwszym etapie projektu. Rozszerzanie i adaptowanie podstawowej infrastruktury w odpowiedzi na zmieniające się wymagania (na przykład dodawanie nowych usług lub dostawców uwierzytelniania) to standardowy możliwy do realizacji każdego dnia przypadek użycia, który powinien byd poprawnie obsługiwany przez platformę, procesy i narzędzia, a nie proces realizowany okresowo przy okazji wdrażania nowej wersji platformy. Bezpieczeostwo Aby umożliwid budowanie rozwiązao gwarantujących odpowiedni poziom bezpieczeostwa dostępu do usług dla sektora publicznego, już w pierwszych fazach projektowania architektury należy pomyśled o wielowarstwowych zabezpieczeniach i innych aspektach związanych z bezpieczeostwem systemu. Sam model zabezpieczeo powinien byd elastyczny i pozwalad na adaptację w celu uwzględnienia różnych dostępnych obecnie i w przyszłości technik zabezpieczeo bez potrzeby projektowania systemu od początku. Skalowalnośd i wydajnośd Architektura powinna zapewniad adekwatną wydajnośd i pozwalad na rozbudowę systemu wraz ze wzrostem zapotrzebowania na dostęp do coraz szerszego zakresu oferowanych usług. Hub usług Wspólna infrastruktura, współdzielona przez wielu dostawców usług dla sektora publicznego, jest rozwiązaniem wielu z problemów naświetlonych w rozdziale RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 40

41 Powszechne problemy dotyczące architektury. Infrastrukturę tę będziemy dalej nazywali hubem usług (lub w skrócie hubem). Chociaż zalety stosowania takiego huba są tym większe, im więcej usług z niego korzysta (zamiast niezależnie implementowad podobną funkcjonalnośd), nie oznacza to wcale, że wszystkie usługi dla sektora publicznego muszą byd obsługiwane za pomocą tylko jednego huba. Możliwa jest współpraca wielu hubów, z których każdy implementuje tylko częśd z pełnej funkcjonalności i współpracuje z pozostałymi hubami w różnych topologiach w stowarzyszonym modelu. Celem jest uzyskanie elastyczności umożliwiającej dostosowanie systemu do różnych wymagao, topologii i potrzebnej skali implementacji przy zachowaniu tych samych metod projektowania poszczególnych węzłów. Kontekst i interakcje zewnętrzne huba Hub usług dla sektora publicznego implementuje zestaw usług udostępnianych klientom różnego typu. Sam hub także jest klientem korzysta z innych systemów (usług) zewnętrznych (patrz ilustracja 4). Interakcje z klientami Z punktu widzenia architektury, klientem jest wszystko, co korzysta z usług udostępnianych przez hub usług dla sektora publicznego. Klientami mogą byd witryny internetowe i portale obsługujące własnych użytkowników koocowych w oparciu o usługi świadczone przez hub, aplikacje uruchamiane w systemach klienckich lub inne systemy korzystające z usług huba. Typowe kategorie klientów huba to: - portale mogą korzystad z udostępnianych przez hub usług zarządzania tożsamością i bezpieczeostwem w celu uwierzytelniania użytkowników, wykonywania zadao konserwacyjnych, przekazywania dokumentów w imieniu użytkownika poprzez usługi komunikacyjne huba lub wykorzystywad usługi pomocnicze, - aplikacje klienckie na przykład aplikacje finansowo-księgowe uruchamiane na stacjach roboczych i serwerach klientów, kontaktujące się z hubem w celu przekazywania dokumentów i dostępu do innej funkcjonalności, - inne systemy (albo inne huby) mogą działad i korzystad z funkcjonalności huba jako klienty. Mogą to byd systemy utrzymywane przez niezależne organizacje, systemy zaplecza lub inne huby. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 41

42 Ilustracja 4. Kontekst i interakcje zewnętrzne huba usług dla sektora publicznego Wszystkie interakcje z klientami odbywają się za pośrednictwem opublikowanych interfejsów, opartych na branżowych standardach usług Web Service. Podejście takie zapewnia niezbędną otwartośd, kompatybilnośd z szeroką gamą produktów komercyjnych oraz możliwośd współpracy z oprogramowaniem działającym na innych platformach. Interakcje klientów z hubem usług dla sektora publicznego są niezależne od sposobu implementacji aplikacji klienckich i platform, na których aplikacje te są uruchamiane. Uwaga warto pomyśled przyszłościowo i udostępnid pełną funkcjonalnośd huba za pośrednictwem interfejsów programistycznych. W niektórych wczesnych implementacjach takich systemów częścią huba był przeglądarkowy interfejs użytkownika i częśd funkcjonalności dostępna była wyłącznie za pośrednictwem przeglądarki. Po pewnym czasie okazało się, że wiele urzędów wolałoby korzystad z funkcjonalności huba za pośrednictwem własnych portali ze względu na łatwiejszą obsługę. Dodanie interfejsów programistycznych do działającego systemu jest zwykle dużo trudniejsze niż uwzględnienie ich w projekcie już na samym początku. Interakcje z usługami zewnętrznymi Hub działa także jako klient, uzyskując dostęp do innych usług (wewnętrznych lub zewnętrznych). Z architektonicznego punktu widzenia interakcje te nie różnią się od siebie, chod można wyróżnid wśród nich następujące typy: - Usługi, na których opiera się podstawowa funkcjonalnośd huba zewnętrzni dostawcy mechanizmów uwierzytelniania, wywoływani przez hub w celu weryfikacji poświadczeo tożsamości. - Specjalizowane usługi docelowe, otrzymujące żądania od klientów za pośrednictwem huba. Hub działa jako pośrednik i może pełnid dodatkowe funkcje na drodze przekazywania RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 42

43 komunikatów na przykład zapewnid walidację. Usługi docelowe mogą byd świadczone przez urząd, inne systemy lub inne huby integracyjne działające w takich systemach. - Usługi centralne, z których korzystają klienci. Pomimo że hub może dostarczad usługi ogólnego przeznaczenia, pod względem architektury systemu usługi te znajdują się na zewnątrz huba. Usługi takie często są hostowane i zarządzane w oparciu o infrastrukturę techniczną huba centralnego, a dostęp do nich realizowany jest za pośrednictwem huba. Usługi świadczone przez hub Pełny zakres usług zapewnianych przez hub można podzielid na następujące główne kategorie (patrz ilustracja 4): - usługi tożsamości i bezpieczeostwa, - usługi komunikacyjne, - usługi pomocnicze, - usługi routingu i integracyjne. Usługi te zostały opisane w poniższych sekcjach. Usługi tożsamości i bezpieczeostwa Ta grupa usług obsługuje początkową identyfikację i rejestrację użytkowników, rejestrowanie użytkowników w usługach dla sektora publicznego, uwierzytelnianie i autoryzację, odwzorowywanie poświadczeo ogólnych na identyfikatory specyficzne dla usług oraz bieżące zarządzanie tożsamościami użytkowników. Jedną z podstawowych zasad warunkujących architekturę usług tożsamości i bezpieczeostwa jest wsparcie wielu dostawców każdej głównej funkcji. Na tej właśnie koncepcji opiera się model tożsamości stowarzyszonej. Zakładanie, że hub będzie jedynym centralnym systemem zarządzającym uniwersalnymi poświadczeniami, tożsamościami, służącym jako dostawca uwierzytelniania, nie zawsze jest prawidłowe mimo że istnieją liczne udane implementacje, w których zastosowano ten model. Możliwośd bezproblemowego opierania się na obcych rozwiązaniach pozwala zbudowad elastyczny i kompletny model huba, który może pracowad w wielu różnych topologiach, a nie w jednej, zaprojektowanej specjalnie dla danego rozwiązania. W sekcji Możliwe topologie dalej w tym dokumencie opisano różne systemy oparte na jednym lub wielu hubach ogólnych. Szczegółowy opis architektury usług tożsamości i bezpieczeostwa zawarto w sekcjach Usługi zarządzania tożsamością oraz Usługi uwierzytelniania i autoryzacji dalej w tym dokumencie. Usługi komunikacyjne Funkcja odbierania komunikatów lub rejestrowania dokumentów, weryfikowania ich integralności, sprawdzania autoryzacji i przekazywania ich do odpowiedniej usługi docelowej jest jedną z najważniejszych funkcji dodatkowych, dzięki którym hub usług dla sektora publicznego jest użyteczny zarówno dla klientów, jak i jednostek administracji publicznej świadczących usługi drogą elektroniczną. Możliwośd przeniesienia części pośrednich etapów przetwarzania na współdzieloną wspólną infrastrukturę pozwala agencjom skoncentrowad się na swoich zadaniach biznesowych (przetwarzaniu otrzymanych dokumentów) i ułatwia świadczenie usług drogą elektroniczną. Szczegółowy opis architektury usług komunikacyjnych zamieszczono w sekcjach Usługi rejestracji dokumentów i Orkiestracja procesów biznesowych dalej w tym dokumencie. Usługi pomocnicze Niektóre funkcje często niezbędne do świadczenia usług dla sektora publicznego mogą byd bardziej efektywnie dostarczane w postaci wspólnych usług pomocniczych, udostępnianych przez hub (lub za jego pośrednictwem) i współdzielonych przez dostawców usług dla sektora RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 43

44 publicznego, i nie muszą byd implementowanie niezależnie dla każdej usługi. Możliwośd ta jest szczególnie atrakcyjna dla mniejszych jednostek (na przykład dla ośrodków lokalnych), którym często brak środków i odpowiednio wykwalifikowanego personelu, by móc samodzielnie zaimplementowad takie usługi. Typowe przykłady takich usług pomocniczych to: - Usługi płatności służące do obsługi płatności pomiędzy klientami (obywatele, przedsiębiorstwa, systemy) i dostawcami usług (agencje, urzędy). - Bezpieczna poczta elektroniczna do bezpiecznego przesyłania poufnych informacji pomiędzy jednostkami administracji publicznej a ich usługobiorcami. Zakres usług pomocniczych dostarczanych przez hub może się stopniowo zwiększad, w zależności od potrzeb i spodziewanych korzyści. Ponieważ możliwe jest wdrożenie wielu instancji huba, huby mogą byd umieszczane w lokalizacjach najbardziej odpowiednich do świadczenia określonych usług pomocniczych na przykład na poziomie centralnym, regionalnym lub lokalnym. Możliwe topologie Ogólna natura architektury referencyjnej i funkcjonalności huba umożliwia budowanie wielu różnych topologii. W zależności od specyficznych wymagao i umiejscowienia każdego z hubów, dany hub może oferowad jedynie podzbiór ogólnej funkcjonalności. Daje to elastycznośd wyboru sposobu i miejsca wykonywania różnych operacji. Możliwe topologie są bardzo różne pojedynczy centralny hub, sied stowarzyszonych, współpracujących hubów równorzędnych, wielopoziomowa hierarchia hubów, a nawet bardziej skomplikowane struktury. Pojedynczy centralny hub Najbardziej oczywistą konfiguracją systemu jest wdrożenie pojedynczego, centralnego huba usług dla sektora publicznego (patrz ilustracja 5). Model ten z powodzeniem zastosowano w licznych wdrożeniach infrastruktury dla sektora publicznego w wielu krajach. Skupienie kluczowych funkcji (zarządzanie tożsamością, uwierzytelnianie i autoryzacja, przekazywanie komunikatów, walidacja danych) w pojedynczym hubie, współdzielonym przez wszystkich dostawców usług dla sektora publicznego, jest wygodne i efektywne oraz zapewnia wysoką niezawodnośd. System taki może byd szybko wdrożony i pozwala na bardzo stromy wzrost zarówno liczby oferowanych usług, jak i ich wykorzystania. Ilustracja 5. Pojedynczy, centralny hub Centralny hub usług dla sektora publicznego stanowi powszechną platformę, zapewniającą niezbędną funkcjonalnośd, taką jak zarządzanie tożsamością i bezpieczeostwem czy przetwarzanie RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 44

45 komunikatów (przyjmowanie dokumentów). Dostawcy usług dla sektora publicznego mogą oprzed swoje systemy na usługach zapewnianych przez hub, implementując jedynie funkcje niezbędne do integracji własnych systemów z infrastrukturą dla sektora publicznego oraz funkcje biznesowe do celów przetwarzania otrzymywanych dokumentów. Hub jako platforma integracji systemów zaplecza Okrojona wersja ogólna huba dla sektora publicznego, w której pozostawiono jedynie funkcjonalnośd niezbędną do pełnienia roli systemu integracyjnego, może stanowid bardzo efektywną platformę, zapewniającą połączenie z systemami zaplecza utrzymywanymi przez dostawcę usług (patrz ilustracja 6). Ilustracja 6. Hub integracyjny Hub integracyjny może zapewniad ogólną funkcjonalnośd komunikacyjną, przekazywania komunikatów i integracyjną do celów odbierania komunikatów od huba centralnego lub innych systemów, wykonywania niezbędnej walidacji i przekazywania tych komunikatów do systemów docelowych. Poza ogólnymi funkcjami komunikacyjnymi i integracyjnymi, hub może także udostępniad zaawansowane funkcje integracji i transformacji, specyficzne dla danej agencji lub systemów zaplecza. Więcej informacji na temat możliwości huba w zakresie wsparcia integracji z systemami zaplecza można znaleźd w znajdującej się dalej w tym dokumencie sekcji Integracja z usługami zaplecza. Hub integracyjny może ufad hubowi centralnemu i polegad na nim w zakresie walidacji i uwierzytelniania komunikatów przychodzących, ale może także we własnym zakresie przeprowadzad dodatkowe operacje uwierzytelniania i autoryzowania żądao. Operacje te mogą wymagad odwołao do usług zewnętrznych, w tym do huba centralnego szczególnie w przypadkach, gdy przetwarzane komunikaty nie zostały przesłane za pośrednictwem huba centralnego. Huby równorzędne W wielu przypadkach kierowanie całego ruchu przez jeden centralny hub może byd nieefektywne lub niepraktyczne szczególnie gdy hub nie pełni zbyt wielu funkcji w procesie (walidacja, autoryzacja, śledzenie wywołao itp.). Lepszym rozwiązaniem może byd wdrożenie dla określonych typów komunikatów komunikacji typu peer-to-peer jako uzupełnienia dla komunikacji za pośrednictwem huba. Na przykład odpowiedzi na wywołania mogą byd przekazywane RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 45

46 bezpośrednio do systemu klienta, nawet jeśli żądanie zostało przesłane za pośrednictwem huba centralnego. Komunikacja bezpośrednia może byd także wykorzystywana na określonych etapach konwersacji wymagających przesłania wielu komunikatów, na przykład po zainicjowaniu interakcji za pośrednictwem huba. Efektywną komunikację typu peer-to-peer mogą obsługiwad instancje ogólnego huba, wykonując częśd standardowych zadao, które w innym wypadku wymagałyby implementacji w samych usługach. W zależności od typu interakcji i wymaganej funkcjonalności, można zdecydowad się na wdrożenie sześciu różnych podzbiorów ogólnej funkcjonalności huba. Na ilustracji 7. przedstawiono jeden z możliwych sposobów wymiany komunikatów pomiędzy hubami równorzędnymi, w którym hub centralny pełni rolę dostawcy uwierzytelniania i usługi tokenów bezpieczeostwa (Security Token Service STS). Poszczególne etapy komunikacji mają następujący przebieg: 1. Żądający wywołuje hub centralny lub innego dostawcę tożsamości w celu uzyskania tokenu bezpieczeostwa pozwalającego na komunikację z usługą docelową. Token ten powinien byd wystawiony przez usługę tokenów bezpieczeostwa (Security Token Service STS), której ufa usługa docelowa. 2. Komunikat wraz z tokenem STS zostaje przekazany do huba usługi docelowej. 3. Następuje sprawdzenie poprawności tokenu STS. Usługi zarządzania tożsamością i bezpieczeostwem huba usługi docelowej podejmują decyzję o udzieleniu dostępu do tej usługi. Decyzja może zostad podjęta na podstawie danych przechowywanych lokalnie w hubie lub danych uzyskanych z zewnątrz poprzez odwołanie się do innej usługi. 4. Komunikat zostaje przekazany do usługi docelowej do przetworzenia. Ilustracja 7. Huby równorzędne W tym scenariuszu komunikacja z hubem centralnym odbywa się tylko w pierwszym etapie, w celu pobrania odpowiedniego tokenu STS. Po uzyskaniu tokenu mogą nastąpid interakcje bezpośrednio pomiędzy równorzędnymi hubami (do czasu wygaśnięcia okresu ważności tokenu bezpieczeostwa), bez potrzeby ponownego odwoływania się do huba centralnego, który w tym przypadku pełni wyłącznie rolę dostawcy uwierzytelniania (STS). Możliwych jest także wiele innych scenariuszy. Na przykład po zainicjowaniu interakcji w sposób opisany powyżej, hub usługi docelowej może wystawid własny, specyficzny dla wywoływanej usługi token sesji i przekazad go hubowi żądającego. Kolejne wywołania mogą byd uwierzytelniane w oparciu o ten token, a weryfikacja tokenu przez usługę docelową jest znacznie szybsza. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 46

47 Hierarchia hubów Możliwe jest budowanie jeszcze bardziej złożonych topologii, w których współpracujące ze sobą w stowarzyszonym modelu huby znajdują się na różnych poziomach hierarchii. Częśd z ogólnej funkcjonalności zapewnianej przez huby (routing, orkiestracja, decyzje dotyczące autoryzacji dostępu na różnych poziomach szczegółowości) może byd rozdzielana pomiędzy różne huby na podstawie warunków takich jak wydajnośd, dostępnośd, prawa własności danych, procedury aktualizacji i konserwacji itp. Rozwiązania, zamiast stosowad podejście jednorozmiarowe, mogą byd dostosowywane do znacznie szerszego zakresu wymagao i ograniczeo. Przykład takiej hierarchii przedstawiono na ilustracji 8. Ilustracja 8. Hierarchia hubów W lewej części ilustracji 8. przedstawiono jeden z możliwych sposobów dystrybucji funkcjonalności i organizacji przepływów danych (ze szczególnym uwzględnieniem routingu komunikatów w hubie regionalnym lub w hubie grupy. Proces ma następujący przebieg: 1. Centralny hub przyjmuje i przetwarza komunikaty w standardowy sposób, włącznie z walidacją danych i sprawdzeniem autoryzacji dostępu do żądanej usługi. 2. Komunikat jest następnie przesyłany do należącego do niższego poziomu huba regionalnego lub huba grupy, który może obsługiwad kilka agencji lub kilku dostawców usług. 3. Hub regionalny lub hub grupy może przetworzyd pakiet i użyd zaawansowanych funkcji routingu, na przykład w celu uwzględnienia dynamicznych warunków, takich jak bieżące obciążenie systemów lub trwające awarie, lub zrealizowad orkiestrację procesu w oparciu o kilka usług zaplecza. Odpowiedzialnośd za te działania pozostaje na poziomie grupy hub centralny nie bierze w nich udziału. 4. Komunikaty zostają przekazane do odpowiednich dostawców usług, którzy sami mogą udostępniad swoje systemy za pośrednictwem hubów integracyjnych. W prawej części ilustracji 8. przedstawiono inny sposób dystrybucji funkcjonalności i organizacji przepływów danych (z naciskiem na autoryzowanie dostępu na różnych poziomach szczegółowości przez hub agencji). RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 47

48 1. Centralny hub przyjmuje i przetwarza komunikaty w standardowy sposób, włącznie z walidacją komunikatu, uwierzytelnieniem i sprawdzeniem autoryzacji dostępu do żądanej usługi. Poziom szczegółowości autoryzacji to poziom usługi, a nie poziom huba regionalnego lub huba grupy. 2. Komunikat zostaje następnie przesłany do huba agencji. 3. Hub agencji może dokonad bardziej szczegółowego sprawdzenia autoryzacji na podstawie zaświadczeo otrzymanych wraz z komunikatem. Na przykład odwzorowanie tożsamości może pozwolid związad żądanie z bardziej specyficznymi rolami lub istniejącymi na tym poziomie przypisaniami (np. delegacja uprawnieo). 4. Komunikaty zostają przekazane do odpowiednich dostawców usług, którzy sami mogą udostępniad swoje systemy za pośrednictwem hubów integracyjnych. Terminy hub grupy, hub regionalny, hub agencji i ich funkcjonalnośd, opisana w powyższym przykładzie, służą wyłącznie do celów ilustracyjnych. Istnieje oczywiście wiele różnych sposobów budowy topologii systemu. Ogólna funkcjonalnośd huba może zostad rozproszona na wiele instancji huba, co pozwala na budowanie rozwiązao dopasowanych do określonych wymagao i ograniczeo. Usługi zarządzania tożsamością Zarządzanie tożsamością jest podzbiorem usług zarządzania tożsamością i bezpieczeostwa, świadczonych przez ogólny hub usług dla sektora publicznego. Umiejscowienie usług zarządzania tożsamością w tym kontekście przedstawiono na ilustracji 9. Ilustracja 9. Zarządzanie tożsamością w kontekście huba usług dla sektora publicznego Usługi zarządzania tożsamością są odpowiedzialne za: - początkową identyfikację użytkowników, po której (w niektórych przypadkach) następuje wygenerowanie poświadczeo użytkownika i powiązanie tych poświadczeo z uwierzytelnioną tożsamością, - rejestrowanie użytkowników w usługach, - zarządzanie kontami użytkowników i ich rejestracjami w usługach, - nadawanie uprawnieo do działania w imieniu innej osoby w kontekście określonej osoby (proces nazywany zwykle delegacją). RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 48

49 Szczegółowy opis sposobu realizacji tej funkcjonalności zamieszczono w dalszych sekcjach tego dokumentu. Podstawowy model tożsamości i zasady Sekcja ta zwiera definicję podstawowych encji modelu tożsamości, relacji pomiędzy nimi oraz opis reguł określających wszystkie aspekty zarządzania tożsamością w architekturze. Ogólny model zarządzania tożsamością powinien byd na tyle otwarty i elastyczny, by można go było dostosowad do różnych (obecnych i przyszłych) wymagao dotyczących różnych typów uwierzytelniania, odwzorowywania poświadczeo na identyfikatory użytkowników stosowane w poszczególnych usługach, delegowania uprawnieo itp. Podstawowe encje modelu tożsamości Poniżej zestawiono opis encji składających się na podstawowy model tożsamości: - użytkownik (petent, wyborca) osoba, która musi zostad zidentyfikowana, uwierzytelniona i otrzymad autoryzację do korzystania z określonych usług. W ramach modelu użytkownicy reprezentowani są przez poświadczenia i tożsamośd; - tożsamośd reprezentuje i identyfikuje użytkownika w systemie zarządzania tożsamością. Pojedynczy użytkownik może posiadad kilka niezależnych tożsamości, odpowiadających różnym pełnionym przez niego rolom w systemie lub grupom wydzielonych usług; - poświadczenie informacje lub inne obiekty, których weryfikacja pozwala na ustalenie tożsamości przedstawiającego się nimi użytkownika. Z pojedynczą tożsamością może byd powiązane wiele różnych poświadczeo. Typowe przykłady poświadczeo to nazwa użytkownika wraz z hasłem, certyfikat cyfrowy itp.; - usługa logiczny zbiór funkcjonalności biznesowej udostępniany przez dostawcę usług, charakteryzujący się spójnymi regułami dotyczącymi autoryzacji i dostępu do usługi przez użytkowników. Administracja publiczna może oferowad wiele niezależnych usług, różniących się regułami dostępu i wymaganymi poziomami uwierzytelnienia. Jedna usługa może także udostępniad zbiór funkcjonalności biznesowej oferowanej przez różne agencje warunkiem jest jasne ustalenie zakresu własności i odpowiedzialności za każdą usługę zagregowaną w ramach tej jednej usługi; - rejestracja powiązanie tożsamości z określoną usługą, realizowane za pośrednictwem odpowiednich, specyficznych dla danej usługi atrybutów kontekstu (identyfikatorów). Prawidłowa i aktywna rejestracja uprawnia jej posiadacza (lub dobrze umocowanego reprezentanta) do dostępu do usługi w kontekście określonym przez identyfikatory; - identyfikatory atrybuty informacyjne towarzyszące rejestracji, które jednoznacznie identyfikują i stanowią kontekst relacji tożsamości z daną usługą. Przykładami takich identyfikatorów mogą byd: numer identyfikacji podatkowej, krajowy numer ubezpieczenia, numer ubezpieczenia społecznego, numer rejestrowy przedsiębiorstwa, identyfikator płatnika podatku VAT, identyfikator płatnika podatku od nieruchomości, identyfikator dostawcy czy numer konta; - grupa reprezentuje zbiór użytkowników współdzielących takie same rejestracje. Użytkownicy tacy często pełnią rolę reprezentantów organizacji; - rola szeroka kategoria tożsamości stosowana do określenia lub ograniczenia dostępu do odpowiednich usług dla wszystkich użytkowników w ramach tej tożsamości. Typowe przykłady ról to między innymi: - osoba (obywatel) reprezentuje klientów usług administracji publicznej; - organizacja (grupa) reprezentuje organizacje (firmy), w których wiele osób należących do jednej grupy może współdzielid tę samą rejestrację i działad w imieniu organizacji; - pośrednik (agent, delegat) stały lub wyznaczony tymczasowo reprezentant osoby lub organizacji, uprawniony do działania w ich imieniu w kontekście określonej usługi; RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 49

50 - administracja publiczna osoby i systemy reprezentujące jednostki administracji publicznej, uprawnione do dostępu do określonych usług. Model tożsamości Na ilustracji 10. przedstawiono relacje pomiędzy wymienionymi powyżej encjami modelu tożsamości. Warto zauważyd, że: - pojedynczy użytkownik może posiadad wiele poświadczeo; - każdy zestaw poświadczeo odpowiada pewnej tożsamości, a jedna tożsamośd może byd identyfikowana wieloma zestawami poświadczeo; - każda tożsamośd jest powiązana z jedną rolą, która określa zbiór usług dostępnych dla osoby posługującej się tą tożsamością; - z jedną grupą może byd związane wiele tożsamości; - grupa może posiadad wiele rejestracji w poszczególnych usługach; - jedna rejestracja dotyczy tylko jednej usługi; - każda rejestracja w usłudze ma przypisane określone identyfikatory określające kontekst relacji pomiędzy posiadaczem rejestracji a usługą. Ilustracja 10. Model tożsamości Separacja tożsamości od poświadczeo uwierzytelniania Oddzielenie tożsamości od poświadczeo uwierzytelniania to ważna zasada, od której zależy elastycznośd modelu. Uwierzytelnienie określonej tożsamości może byd związane z niezależną weryfikacją wielu poświadczeo tożsamości. Pozwala to na wygodne uwierzytelnianie użytkownika korzystającego z usług za pośrednictwem wielu kanałów dostępu dostępne technologie i schematy korzystania z poszczególnych kanałów dostępu mogą ograniczad możliwośd przedstawiania niektórych typów poświadczeo (na przykład brak czytników kart elektronicznych, możliwośd wprowadzania wyłącznie danych numerycznych itp.). Obsługa wielu typów poświadczeo pozwala na rozwój i rozszerzanie istniejącego zestawu relacji (rejestracji) poprzez stopniową migrację do wyższych poziomów uwierzytelniania, zapewniających dostęp do szerszego zestawu usług. Migrację taką można zrealizowad minimalnymi nakładami pracy bez zakłócania działania istniejących usług. Odseparowanie poświadczeo od tożsamości pozwala także na uwierzytelnianie na podstawie poświadczeo zewnętrznych, obsługiwane na zewnątrz huba usług dla sektora publicznego. Daje to podstawę do obsługi uwierzytelniania stowarzyszonego i innych zaawansowanych scenariuszy zastosowao. Usługi uwierzytelniania mogą byd zapewniane przez różnych dostawców (w zależności od rodzaju uwierzytelnienia i jego wystawcy) przy jednoczesnym zachowaniu ogólności funkcji autoryzacji i odwzorowywania tożsamości na identyfikatory wykorzystywane przez różne usługi. Jest to możliwe dzięki przypisaniu wielu poświadczeo do jednej tożsamości. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 50

51 Obsługa uwierzytelniania stowarzyszonego Tworząc rozwiązanie perspektywiczne, które bez większych modernizacji powinno funkcjonowad przez wiele lat, warto już na początku prac projektowych zastanowid się nad wdrożeniem modelu uwierzytelniania stowarzyszonego. Innymi słowy warto założyd, że system będzie korzystał z wielu dostawców poświadczeo i tożsamości. Aby to osiągnąd, dobrze jest oddzielid samo uwierzytelnianie (implementowane natywnie w istniejących i przyszłych produktach i technologiach) od specyficznej funkcjonalności, takiej jak odwzorowywanie tożsamości użytkowników na identyfikatory użytkowników stosowane przez usługi (odwzorowanie z pewnością jest specyficzną relacją, wymagającą obsługi za pomocą specjalnie zaprojektowanego do tego celu procesu). Uwierzytelnianie stowarzyszone powinno byd oparte na istniejących obecnie standardach branżowych, takich jak WS-Federation, WS-Trust itd. Takie podejście pozwoli zagwarantowad interoperacyjnośd pomiędzy różnymi platformami i dostawcami oraz umożliwi wykorzystanie produktów komercyjnych wspierających te standardy. Więcej informacji na temat proponowanej przez Microsoft interoperacyjnej architektury zarządzania cyfrową tożsamością, opartej na założeniu, że każda osoba może posługiwad się wieloma cyfrowymi tożsamościami opartymi na różnych technologiach, implementacjach i przyznawanymi przez różnych dostawców, można znaleźd w artykule pod adresem Usługi Web Service Funkcjonalnośd podsystemu zarządzania tożsamościami w hubie usług dla sektora publicznego udostępniania jest w postaci zestawu usług Web Service, które można podzielid na następujące kategorie: - identyfikacja początkowa i rejestracja; - uwierzytelnianie; - autoryzacja i odwzorowywanie tożsamości; - zarządzanie użytkownikami i rejestracjami. Wzorzec ogólny wymienni dostawcy Implementacja usług tożsamości oparta jest na jednym, ogólnym wzorcu, który przedstawiono na ilustracji 11. Na implementację tę składa się wspólna, zunifikowana czołowa usługa Web Service oraz pewna liczba wymiennych dostawców, będących implementacjami dowolnych z następujących sposobów obsługi: - interfejs łączący z zewnętrznym dostawcą usług, który może korzystad ze zdalnych danych referencyjnych, - przetwarzanie wewnętrzne przez reguły znajdujące się w kodzie programu, bez potrzeby sięgania do danych referencyjnych, - wewnętrzny dostawca usługi, który lokalnie przechowuje niezbędne dane referencyjne. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 51

52 Ilustracja 11. Ogólny wzorzec wymiennych dostawców Możliwe jest stosowanie wielu instancji dostawcy tego typu, na przykład w celu realizacji różnych typów walidacji lub dostępu do różnych dostawców zewnętrznych. Zakłada się oparcie wszystkich interakcji zewnętrznych na standardowych usługach Web Service, jednak tam, gdzie nie jest to możliwe, można przygotowad komponent-interfejs, który tłumaczy wywołania na protokół zrozumiały przez dostawcę. Początkowe zgłaszanie użytkowników Jak wspomnieliśmy w sekcji Początkowa identyfikacja użytkowników rozdziału RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 52

53 Powszechne problemy dotyczące architektury tego opracowania, z tworzeniem rozwiązao dla sektora publicznego na wielką skalę związane są liczne problemy. Proces początkowego zgłaszania (identyfikacji i rejestracji) użytkowników musi byd efektywny, bezpieczny, a jednocześnie powinien wymagad jak najmniejszego nakładu pracy ludzkiej po stronie dostawcy usług. Idealnym rozwiązaniem byłoby zgłaszanie samoobsługowe, realizowane w całości przez samych użytkowników. Aby system pozwalał na dopasowanie do ewoluujących i coraz bardziej zróżnicowanych wymagao, musi zapewniad elastycznośd definiowania specyficznych reguł i procesów dla każdej z usług z osobna. Początkowe uwierzytelnianie oparte na wiedzy Zważywszy na specyficzne dla rozwiązao dla sektora publicznego wymagania, takie jak duża liczba potencjalnych użytkowników, brak wcześniejszych doświadczeo z systemami elektronicznymi i mała częstotliwośd interakcji, coraz większą popularnośd zyskuje pomysł nazywany uwierzytelnianiem opartym na wiedzy (Knowledge Based Authentication KBA). Mówiąc krótko, w modelu KBA do weryfikacji tożsamości użytkownika wykorzystywane są dostarczone przez niego informacje. Mogą to byd ogólne informacje związane z użytkownikiem (identyfikujące użytkownika) albo z kontekstem określonej usługi (identyfikacja płatnika podatku od nieruchomości na podstawie posiadanych przez niego nieruchomości). Na ilustracji 12. przedstawiono ogólną architekturę systemu uwierzytelniania na podstawie wiedzy. Obieg informacji, oznaczony na ilustracji kolejnymi liczbami, przebiega następująco: 1. Użytkownik przedstawia zestaw informacji (faza ta poprzedzona jest zadaniem użytkownikowi zestawu pytao). 2. Reguły KBA porównują przedstawione informacje (odpowiedzi na zadane pytania) z danymi referencyjnymi. Dane te mogą byd przechowywane lokalnie lub zdalnie. 3. Odpowiedź systemu zawiera informację na temat wyniku uwierzytelnienia (pozytywny lub negatywny) oraz dane dodatkowe na przykład unikalny identyfikator użytkownika, ustalony w procesie porównywania danych przedstawionych przez użytkownika. Identyfikator nie musi byd elementem tych informacji. Ilustracja 12. Ogólna architektura usługi uwierzytelniania opartego na wiedzy Uwaga szczegółowe informacje na temat uwierzytelniania opartego na wiedzy można znaleźd w prezentacji KBA Applicability to e-government, której autorami są Mindy Rudell, Dick Stewart, Robin Medlock i Angel Rivera. Prezentacja dostępna jest pod adresem %20KBA%20Applicability%20to%20e-Gov.pdf RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 53

54 Wybór odpowiedniego zestawu informacji dla KBA Wiarygodnośd uwierzytelniania KBA zależna jest od rodzaju wybranego zestawu informacji uwierzytelniających oraz od sposobu realizacji procesu walidacji. Typowe wymagania dotyczące doboru tych informacji to: - Informacje są bezpośrednio związane z użytkownikiem i jednoznacznie go identyfikują. Informacją taką nie jest na przykład kod pocztowy, ale numer PESEL lub numer ubezpieczenia społecznego jest. - Informacje są dobrze znane użytkownikowi, ale nie są łatwo dostępne dla innych osób. Informacją taką nie jest na przykład numer rejestrowy firmy (umieszczany na papierze firmowym i wizytówkach, dostępny praktycznie dla każdego). Informacjami takimi mogą byd na przykład specyficzne dane z ostatniej faktury numer referencyjny lub ilośd zamówionego towaru (dane takie znane są zwykle wyłącznie stronie zainteresowanej). - Możliwośd odgadnięcia poprawnej odpowiedzi jest ograniczona zakres wartości jest na tyle szeroki, że wypróbowanie wszystkich możliwych wartości jest niewykonalne, a odgadnięcie poprawnej wartości na podstawie innych, znanych danych jest niemożliwe (należy na przykład unikad stosowania numerowania kolejnymi liczbami). - Wykorzystanie do uwierzytelniania informacji podlegających okresowym zmianom (na przykład kwota ostatniej płatności) dodatkowo zmniejsza prawdopodobieostwo odgadnięcia, a więc dane takie stanowią lepsze zabezpieczenie niż dane niezmienne. Warto podkreślid, że powyższe wymagania dotyczą zbioru informacji jako całości. Innymi słowy, różne informacje, z których każda oddzielnie nie zapewnia dostatecznego poziomu wiarygodności identyfikacji, połączone razem mogą dad wysoką pewnośd i bezpieczeostwo uwierzytelnienia. Logika weryfikująca i dane referencyjne Gdy użytkownik przedstawi informacje uwierzytelniające, trzeba je zweryfikowad. Weryfikacja zwykle odbywa się na podstawie pewnych danych referencyjnych z wykorzystaniem odpowiednich reguł porównujących. Można stosowad różne transformacje pozwalające na porównywanie przybliżone na przykład nie uwzględniad wielkości liter, ignorowad znaki niedrukowane (np. spacje), dokonywad częściowego porównywania danych takich jak kod pocztowy i inne dane adresowe czy dopuszczad stosowanie skrótów i różnych wariantów pisowni. Ogólnie rzecz biorąc, trudno jest jednak opracowad zadowalające metody porównywania danych, które mogą występowad w wielu różnych formatach (tak jak na przykład dane adresowe), zatem zalecane jest wykorzystywanie danych o bardziej przewidywalnych formatach. Reguły porównujące mogą także sprawdzad zależności pomiędzy wprowadzonymi informacjami. Można na przykład uznad, że wystarczające jest udzielenie poprawnej odpowiedzi na 3 z 4 pytao. Ponieważ reguły porównujące mogą byd dostosowywane do potrzeb, i jeśli jest zachodzi taka koniecznośd można stosowad różne reguły dla różnych rodzajów uwierzytelniania i różnych usług, pozwalają na dopasowanie systemu do wielu różnych wymagao zarówno obecnych, jak i tych, które dopiero zostaną zdefiniowane. Jest to istotne dla elastyczności rozwiązania i stanowi jedno z podstawowych założeo architektury platformy (zgodnie z opisem w sekcji Elastycznośd i sprawnośd rozdziału RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 54

55 Powszechne problemy dotyczące architektury wcześniej w tym dokumencie). Dane referencyjne wykorzystane do walidacji mogą byd albo lokalne (dostarczone przez właściciela i przechowywane w hubie), albo zdalne (hub w celu weryfikacji informacji przedstawionych przez użytkownika odwołuje się do właściciela danych, a same dane pozostają u właściciela). Możliwe jest także skonstruowanie reguł sprawdzających, opierających się wyłącznie na informacjach przedstawionych przez użytkownika bez potrzeby korzystania z danych referencyjnych. W takim wypadku wynik uwierzytelnienia zależy od spójności całego zestawu danych. Jedna z przedstawianych informacji może byd na przykład wynikiem jakiejś transformacji pozostałych danych, podobnie jak w przypadku cyfr kontrolnych na kartach kredytowych jednak wykorzystana transformacja musi byd bardziej bezpieczna. W przypadku weryfikacji bez wykorzystania danych referencyjnych, w skład zestawu informacji przedstawianych przez użytkownika musi także wchodzid unikalny identyfikator użytkownika lub informacje te muszą wystarczad do ustalenia (np. obliczenia) identyfikatora użytkownika. Na ilustracji 13. przedstawiono trzy różne sposoby walidacji, możliwe do przeprowadzenia z wykorzystaniem wymiennego dostawcy, takiego jak usługa KBA. - A dane referencyjne przechowywane są zdalnie, reguły KBA w celu walidacji użytkownika odwołują się do dostawcy danych, - B logika walidacyjna jest niezależna od jakichkolwiek danych referencyjnych, - C dane referencyjne przechowywane są wewnątrz huba, reguły walidacyjne odwołują się do nich lokalnie. Ilustracja 13. Różne rodzaje walidacji, korzystające z lokalnych i zdalnych danych referencyjnych Ogólna architektura huba obsługuje wymienne moduły walidacji dowolnego typu. Decyzja co do tego, który moduł należy zastosowad, zależy od wielu czynników. Najważniejsze z nich to: - czas odpowiedzi operacji walidacji przechowywanie danych referencyjnych wewnątrz huba pozwala na przyspieszenie walidacji. Odwołania z huba do zdalnego magazynu danych mogą wprowadzad znaczne opóźnienia, co może mied negatywny wpływ na wydajnośd i ocenę systemu przez użytkownika; - dostępnośd przechowanie danych referencyjnych wewnątrz huba zapewnia niezależnośd procesu weryfikacji od innych systemów, dzięki czemu dostępnośd procesu walidacji jest równa dostępności huba. Oparcie walidacji na zdalnych danych referencyjnych uzależnia dostępnośd całego rozwiązania od dostępności systemu zdalnego; RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 55

56 - objętośd danych rozmiar danych referencyjnych może byd znaczny powinno byd to uwzględnione podczas planowania wydajności systemu. Jeśli z usługi korzystad będzie tylko niewielka częśd użytkowników, przechowywanie wewnątrz huba kopii danych referencyjnych całej społeczności może byd zbyt drogie i zbyt kłopotliwe; - uaktualnianie danych referencyjnych dane referencyjne przechowywane wewnątrz huba muszą byd stale uaktualniane na podstawie ich źródła. W zależności od szybkości zmian zachodzących w tych danych, objętośd zmian danych dotyczących wszystkich potencjalnych użytkowników usługi może byd dośd duża. Korzystanie z danych zdalnych, pozostających u ich właściciela, eliminuje potrzebę aktualizowania danych w hubie; - problemy dotyczące poufności danych prawodawstwo niektórych krajów (na przykład Portugalii) zabrania przechowywania danych specyficznych dla usługi poza systemami administracji publicznej udostępniającymi tę usługę. Przechowywanie danych referencyjnych w hubie centralnym jest tam niemożliwe niezależnie od wszelkich innych czynników czy możliwości technicznych. Wybór najlepszego mechanizmu walidacji i miejsca przechowywania danych referencyjnych może byd różny dla różnych dostawców usług. Pozyskiwanie informacji do celów uwierzytelniania opartego na wiedzy Informacje przedstawiane przez użytkowników do celów uwierzytelniania opartego na wiedzy mogą byd danymi znanymi przez tych użytkowników lub danymi, które uzyskali oni w wyników innych interakcji z dostawcą usług (na przykład w korespondencji lub wraz z rachunkiem). Mogą to byd również informacje przekazane specjalnie do celu pierwszego uwierzytelnienia elektronicznego. Możliwe jest także powiązanie procesu pozyskania niezbędnych informacji z jakąś procedurą, akredytacją lub weryfikacją dokumentów (przedstawianych zdalnie za pośrednictwem poczty elektronicznej lub osobiście). Uwierzytelnianie oparte na wiedzy to ogólny mechanizm, niezależny od dokładnego sposobu pozyskania niezbędnych danych. Realizacja procesów uwierzytelniania odbywa się poza samym hubem, może byd różna dla różnych usług i może byd łączona z innym, zewnętrznym procesem. Skoncentrowane na usługach podejście do zgłaszania użytkowników Jak wspomnieliśmy w sekcji Początkowa identyfikacja użytkowników we wcześniejszym rozdziale RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 56

57 Powszechne problemy dotyczące architektury, opracowanie metody początkowej identyfikacji użytkowników o wiarygodności na poziomie akceptowalnym przez wszystkie usługi jest często bardzo trudne. Aby zapewnid niezbędną elastycznośd i możliwośd adaptacji do zróżnicowanych wymagao, stawianych przez obecnych i przyszłych dostawców usług, preferowane jest przeprowadzanie początkowej identyfikacji użytkowników niezależnie dla każdej usługi. Pozwala to na definiowanie informacji uwierzytelniających, reguł walidacji i danych referencyjnych osobno dla każdej usługi i zupełnie niezależnie od innych usług. Takie specyficzne dla poszczególnych usług uwierzytelnianie początkowe może byd dodatkiem do jakiejś procedury wstępnej walidacji użytkownika jako osoby w sensie bardziej ogólnym (w oderwaniu od usług). Można też całkowicie zrezygnowad z ogólnej identyfikacji użytkownika każda usługa będzie identyfikowała użytkowników niezależnie, bez relacji zaufania do innych usług. W tym drugim wypadku rejestracja użytkownika w systemie zależy od pomyślnej początkowej identyfikacji użytkownika przez co najmniej jedną usługę. Takie rozwiązanie jest przydatne w krajach, w których nie ustalono ogólnego identyfikatora obywateli i identyfikacja początkowa musi byd oparta na danych referencyjnych i procedurach walidacji zdefiniowanych przez dostawców usług. Uwaga chociaż możliwe jest rejestrowanie użytkowników z pominięciem walidacji początkowej i późniejsze wiązanie tożsamości z usługami, należy unikad takich rozwiązao. Gdy nie ma wiarygodnego sposobu identyfikacji początkowej, trudno uchronid hub przed atakami typu DoS (Denial of Service) polegającymi na rejestrowaniu dużych ilości fałszywych użytkowników (bez walidacji przez jakiekolwiek usługi) nie istnieje wtedy żaden mechanizm, który pozwoliłby na odróżnienie rejestracji fałszywej od rejestracji prawdziwego użytkownika. Działania takie mogą ograniczyd objętośd dostępnej przestrzeni przechowywania danych i moc obliczeniową, co może negatywnie wpłynąd na dostępnośd systemu i znacznie podnieśd koszty bieżące. Podejście skoncentrowane na usługach wymaga przeprowadzania walidacji przed rejestracją użytkownika, przez co zapewnia lepsze bezpieczeostwo. Pozwala także na wdrożenie dodatkowych procedur aktywacji, zależnych od danych udostępnionych przez usługi (na przykład dane adresowe), co w przeciwnym wypadku może nie byd możliwe. Szczegółowe rozważania na temat możliwych rozwiązao aktywacji przedstawiono w sekcji Aktywacja zgłoszenia i rejestracji w dalszej części tego opracowania. Rejestracja w usługach i odwzorowywanie tożsamości Po udanej identyfikacji początkowej użytkownika w kontekście określonej usługi, dostępny zestaw unikalnych i specyficznych dla tej usługi identyfikatorów użytkownika pozwala na zarejestrowanie użytkownika w usłudze. Tożsamośd ogólna pozostaje przezroczysta i nie jest widoczna dla dostawcy usług jest ona odwzorowywana na identyfikatory zrozumiałe dla danej usługi. Obiekt rejestracji może na przykład powiązad tożsamośd Jana Kowalskiego z usługą urzędu za pośrednictwem identyfikatora przydzielonego przez tę usługę i z usługą podatkową za pośrednictwem numeru identyfikacji podatkowej i innych danych. Dzięki zapamiętaniu odpowiedniego zbioru unikalnych identyfikatorów, specyficznych dla danej usługi jako atrybutów rejestracji w tej usłudze, możliwe jest w czasie wszystkich późniejszych uwierzytelnieo i autoryzacji użytkownika odwzorowanie tożsamości ogólnej na tożsamośd specyficzną dla usługi. Odwzorowywanie tożsamości to jedna z unikatowych, dodatkowych funkcji zapewnianych przez hub usług dla sektora publicznego. Nawet jeśli mechanizmy uwierzytelniania zostaną przeniesione całkowicie na zewnątrz huba (innymi słowy, informacje na temat tożsamości użytkowników nie będą w żaden sposób przechowywane wewnątrz huba, a hub będzie całkowicie opierał się na zewnętrznych dostawcach uwierzytelniania), odwzorowywanie zweryfikowanej tożsamości ogólnej na odpowiadające jej identyfikatory specyficzne dla usług gwarantuje, że usługa docelowa otrzyma zrozumiałe dla siebie identyfikatory użytkownika. Podejście to jest zgodne z regułami zarządzania tożsamością (zasady minimalnego zakresu ujawniania niezbędnych informacji i tożsamości ukierunkowanej), opisanymi wcześniej w tym opracowaniu w rozdziale RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 57

58 Powszechne problemy dotyczące architektury. Aktywacja zgłoszenia i rejestracji Początkowa identyfikacja oparta na wiedzy może zostad uzupełniona dodatkowymi procedurami, podnoszącymi poziom bezpieczeostwa zapewniany przez identyfikowanie użytkowników na podstawie wprowadzonych przez nich informacji (i niskie prawdopodobieostwo, że jakiś użytkownik także może znad te informacje i wykorzystad je do podszycia się pod innego użytkownika). Dodatkowe procedury mogą byd uruchamiane po udanej walidacji początkowej opartej na wiedzy i mogą obejmowad wysłanie do użytkownika dodatkowych informacji, które ten musi wprowadzid do systemu w celu ukooczenia procesu weryfikacji. Typowa implementacja (zastosowano ją w Wielkiej Brytanii i innych krajach) polega na pobraniu od dostawcy usług adresu korespondencyjnego użytkownika i wysłaniu na ten adres jednorazowego kodu aktywacyjnego. Rejestracja w usłudze (utworzona w stanie oczekiwanie na aktywację) zostaje aktywowana, dając pełny dostęp do funkcjonalności dopiero po przedstawieniu hubowi otrzymanego kodu aktywacyjnego. Dzięki dodatkowej weryfikacji opartej na sprawdzeniu, czy użytkownik otrzymał kod aktywacyjny, procedura ta charakteryzuje się wyższym poziomem bezpieczeostwa. Udany atak przez osobę podszywającą się pod użytkownika wymagałby nie tylko pozyskania i przedstawienia poprawnych informacji do celów uwierzytelnienia w oparciu o wiedzę, ale także przechwycenia przesyłki pocztowej lub ingerencji w proces jej dostarczenia. Ze względu na wysoką wiarygodnośd przedsiębiorstw pocztowych i różne regulacje prawne (w USA na przykład wszelkie próby zakłócenia dostarczania poczty są przestępstwami federalnymi o wysokim wymiarze kary), dodatkowy etap weryfikacji znacząco podnosi ogólne bezpieczeostwo rozwiązania. Do przesłania kodu aktywacyjnego można też stosowad inne kanały komunikacyjne, takie jak poczta elektroniczna, telefon, wiadomośd SMS itp. Pojawia się tu jednak problem wiarygodności adresu docelowego. O ile większośd dostawców usług przechowuje adresy korespondencyjne swoich klientów, to inne dane kontaktowe mogą byd albo niedostępne, albo nieaktualne. Wybierając metodę komunikacji należy dokładnie rozważyd potencjalne zagrożenia i ograniczyd możliwości wykorzystania danego kanału do podszycia się pod użytkownika. Jednym ze sposobów podniesienia wiarygodności adresu poczty elektronicznej jest korzystanie z adresów, które zostały już wcześniej zweryfikowane na przykład adresów poczty elektronicznej podanych w certyfikatach cyfrowych użytkowników. Dodatkowy etap aktywacji może pomóc w podniesieniu bezpieczeostwa, jednak ma też pewne wady: - Dostawca usługi musi dysponowad wiarygodnymi danymi adresowymi użytkowników. Rozpoczęcie dodatkowego etapu weryfikacji wymaga przesłania tych danych do huba (masowo lub pojedynczo w zależności od sposobu prowadzenia rejestracji). - Konieczne jest zakupienie i wdrożenie lokalnie lub u zewnętrznego dostawcy urządzeo do bezpiecznego drukowania i rozsyłania kodów aktywacyjnych (w sposób podobny do stosowanego przez banki przy rozsyłaniu PIN-ów do kart płatniczych). Nie wszystkie jednostki, które będą korzystały z huba, mogą pozwolid sobie na zakup takich urządzeo konieczne jest udostępnienie tych urządzeo w ramach centralnej, współdzielonej infrastruktury dla sektora publicznego. - Bezpieczne sposoby przekazywania kodów aktywacyjnych i danych adresowych do jednostki zajmującej się drukowaniem i rozsyłką dane te są ściśle poufne i powinny byd chronione odpowiednimi środkami technicznymi i procedurami operacyjnymi. - Wprowadzenie opóźnienia druk kodów aktywacyjnych i rozsyłka ich drogą pocztową wydłuża okres pomiędzy identyfikacją początkową a aktywacją rejestracji w usłudze nawet o kilka dni. Może to byd niewygodne dla potencjalnych użytkowników szczególnie wtedy, gdy rejestrują się oni do usług dla sektora publicznego tuż przed jakimś wyznaczonym terminem i dowiadują się, że z powodu oczekiwania na aktywację nie będą RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 58

59 mogli ukooczyd określonej operacji na czas (na przykład nie złożą formularza podatkowego). Istnieje możliwośd wyeliminowania opóźnieo przy jednoczesnym zachowaniu zalet dodatkowej fazy aktywacji. W urzędzie podatkowym w Wielkiej Brytanii i w kilku innych instytucjach z powodzeniem udało się wdrożyd zmodyfikowany model aktywacji, zwany aktywacją natychmiastową. Polega on na wygenerowaniu kodów aktywacyjnych i przekazaniu ich potencjalnym użytkownikom jeszcze zanim zdecydują się zarejestrowad w usłudze. Można połączyd obydwie fazy początkowej identyfikacji użytkowników w oparciu o wiedzę i żądad podania kodu aktywacyjnego wraz z pozostałymi informacjami podczas rejestracji. Przesłany użytkownikowi kod aktywacyjny przechowywany jest wtedy wraz z danymi referencyjnymi, a procedura weryfikacyjna, oprócz sprawdzenia informacji przedstawionych przez użytkownika, sprawdza także podany przez niego kod. Jeżeli użytkownik poda prawidłowy kod, system może od razu aktywowad rejestrację i odpowiednie usługi natychmiast stają się dostępne dla użytkownika. Zmiana kolejności procedur weryfikacyjnych (rozsyłka kodów aktywacyjnych nadal ma miejsce, ale odbywa się przed rejestracją użytkownika w usłudze) pozwala na uzyskanie tak samo wysokiego poziomu bezpieczeostwa i uniknięcie opóźnieo. Rozsyłka kodów aktywacyjnych z wyprzedzeniem działa także jako swoiste zaproszenie do skorzystania z usług i przyczynia się do podniesienia świadomości społecznej dostępności usług dla sektora publicznego, zwiększając także popyt na te usługi. Ogólny dostawca poświadczeo i uwierzytelniania Funkcjonalnośd zarządzania tożsamością w hubie oparta jest na usługach świadczonych przez jednego lub kilku dostawców tożsamości. Niektórzy z dostawców mogą byd dostawcami zewnętrznymi. W takich wypadkach hub w celu weryfikacji poświadczeo przedstawionych przez użytkownika musi odwoład się do dostawcy zewnętrznego. Hub może całkowicie opierad się na zewnętrznych dostawcach uwierzytelniania i nie utrzymywad własnej wewnętrznej bazy poświadczeo, ale może też korzystad z wewnętrznego dostawcy poświadczeo i uwierzytelniania. Dzięki temu użytkownicy, którzy nie ustalili relacji z żadnym z dostawców zewnętrznych, mogą zarejestrowad się w systemie i uzyskad poświadczenia wygenerowane przez hub. Aby system mógł byd dostosowywany do stale zmieniających się wymogów związanych z różnymi typami poświadczeo, ogólny dostawca poświadczeo w hubie musi zapewniad elastyczną obsługę wydawania takich poświadczeo. Reguły mogą byd konfigurowane albo statycznie w czasie instalacji dostawy, albo dynamicznie poprzez zmianę parametrów podczas pracy. Oto przykładowe typy poświadczeo: - identyfikator użytkownika wraz z hasłem dostawca poświadczeo generuje identyfikator użytkownika, który jest unikalny w obrębie huba. Format i długośd identyfikatora są z góry ustalone. Hasło jest albo wybierane przez użytkownika, albo generowane przez dostawcę. Tu także mają zastosowanie reguły narzucające format i odpowiednią złożonośd hasła. Do poprawnego uwierzytelnienia użytkownika niezbędne jest podanie pełnej i poprawnej kombinacji identyfikatora i hasła; - zapamiętywane słowa (z podpowiedzią lub bez podpowiedzi) mechanizm ten można połączyd z nazwą i hasłem użytkownika w celu zapewnienia wyższego poziomu bezpieczeostwa. Podanie słów może byd wymagane tylko podczas przeprowadzania określonych operacji (na przykład zresetowanie hasła użytkownika) albo zawsze. Często stosuje się pytania o fragment zapamiętanego słowa na przykład o losowo wybrane znaki (trzecia i piąta litera, numery liter losowane są za każdym razem) lub wiele par pytao i odpowiedzi i zadanie tylko jednego, losowanego za każdym razem pytania; - certyfikaty ogólny dostawca poświadczeo w hubie może wydawad cyfrowe certyfikaty dla użytkowników. O ile realizacja techniczna takiego systemu jest możliwa, to logistyka i zarządzanie nim wymagają głębokiego namysłu. Obsługa certyfikatów bez odpowiedniego doświadczenia i zaplecza technicznego może byd nie lada wyzwaniem. W większości krajów, w których wdrożono huby dla sektora publicznego, procedury wydawania i obsługi certyfikatów postanowiono oprzed na usługach świadczonych przez akredytowanych i sprawdzonych dostawców zewnętrznych. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 59

60 Wybierając rodzaj poświadczeo i reguły zarządzania poświadczeniami warto rozważyd następujące kwestie: - wcześniejsze ograniczenia i wymagania, takie jak zalecenie wykorzystania jako identyfikatorów użytkownika zamiast identyfikatorów generowanych losowo ustalonych wcześniej unikalnych identyfikatorów (na przykład numer PESEL); - skala zakres i rodzaj użytych identyfikatorów powinny pozwalad na wydanie unikalnych identyfikatorów w liczbie wystarczającej do obsłużenia potencjalnej liczby użytkowników; - bezpieczeostwo długośd i złożonośd identyfikatora oraz hasła powinny byd na tyle duże, by nieopłacalne były ataki metodą przeglądu zupełnego (ang. brute force, próba odgadnięcia identyfikatora i hasła poprzez wypróbowanie wszystkich możliwych kombinacji); - wygoda posługiwanie się identyfikatorami, hasłami i innymi informacjami powinno byd łatwe dla użytkowników (w idealnej sytuacji powinny dad się łatwo zapamiętad). Im dłuższe i bardziej złożone identyfikatory i hasła, tym większe prawdopodobieostwo, że użytkownicy będą musieli je zapisywad, co przyniesie skutek odwrotny do tego, który miał zostad osiągnięty poprzez podniesienie złożoności haseł. W tym obszarze niezbędny jest kompromis między wygodą a bezpieczeostwem; - kanały dostępu sposób doboru identyfikatorów i haseł może ograniczyd stosowanie niektórych kanałów dostępu. Na przykład automatyczne systemy obsługi klienta (IVR), systemy telefoniczne, telefony komórkowe oraz telewizja interaktywna (IPTV) pozwalają na wprowadzanie wyłącznie liczb. Tu także uzyskany poziom bezpieczeostwa zależy od kompromisu pomiędzy zakładanym przeznaczeniem systemu a wygodą użytkowania. Byd może warto zastanowid się nad wprowadzeniem różnych zestawów poświadczeo dla różnych kanałów dostępu oraz zróżnicowaniem zestawów usług udostępnianych za pośrednictwem różnych kanałów w zależności od poziomu bezpieczeostwa zapewnianego przez dany kanał. Zarządzanie użytkownikami i rejestracjami W tej sekcji omówiono funkcje zarządzania użytkownikami i ich rejestracjami oraz zagadnienia bieżącego utrzymywania kont użytkowników, rejestracji w usługach, umowy, delegacje uprawnieo itp. Dodawanie i usuwanie użytkowników Oprócz procesu pełnego początkowego uwierzytelniania i zgłaszania użytkowników, opisanego w sekcji Początkowe zgłaszanie użytkowników w tym rozdziale, system może także obsługiwad inne sposoby zgłaszania użytkowników. Na przykład zarejestrowani użytkownicy mogą działad w roli mentorów i zgłaszad nowych użytkowników według procedury uproszczonej. Aby odróżnid ten proces od pełnego uwierzytelnienia początkowego, procedurę uproszczoną będziemy nazywad procesem dodawania lub wprowadzania nowych użytkowników. Użytkownicy wprowadzani w ten sposób do systemu współdzielą to samo zgłoszenie i nie muszą ustanawiad odrębnych, niezależnych zgłoszeo. Funkcjonalnośd ta jest najbardziej użyteczna w organizacjach, w których wielu użytkowników działa jednocześnie w imieniu całej organizacji oraz w przypadku, gdy wielu użytkowników korzysta z tego samego kontekstu usługi (posiada takie same identyfikatory specyficzne dla usługi). W wielu dotychczasowych implementacjach hubów usług dla sektora publicznego zastosowanie takiej funkcjonalności ograniczano jedynie do ról organizacji. Jednakże w przypadku zastosowania szerszego i bardziej wszechstronnego modelu, funkcjonalnośd taką można udostępnid także dla innych ról i na przykład pozwolid osobom na wprowadzanie innych użytkowników i tworzenie grupy osób współdzielących to samo zgłoszenie. Tożsamośd nowo wprowadzonego użytkownika (potwierdzana na podstawie istniejących lub nowo utworzonych poświadczeo) jest powiązana z tożsamością użytkownika, który wprowadził tę nową tożsamośd. W momencie wprowadzenia pierwszego użytkownika tworzona jest grupa RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 60

61 użytkowników. Kolejni wprowadzani użytkownicy dołączani są do istniejącej grupy, a ich tożsamości łączone są z tożsamościami wszystkich pozostałych użytkowników. Pozwala to na pominięcie całego procesu uwierzytelnienia opartego na wiedzy w relacji do jednej lub kilku usług oraz upraszcza i znacznie przyspiesza całą procedurę. W czasie wprowadzania nowego użytkownika, mentor może określid poziom jego uprawnieo: - użytkownik pełnoprawny nowy użytkownik dołącza do grupy użytkowników równorzędnych, posiadających takie same uprawnienia jak mentor włącznie z możliwością wprowadzania nowych użytkowników i współdzielących wszystkie obecne i przyszłe rejestracje w usługach, utworzone przez dowolnego członka grupy; - użytkownik-asysytent (konto ograniczone albo podrzędne) nowy użytkownik posiada bardzo ograniczone uprawnienia, które są kontrolowane przez mentora. Użytkownik taki musi zostad jawnie przypisany do wszystkich zgłoszeo, do których ma mied dostęp. Użytkownicy należący do grupy mogą przeglądad listę użytkowników tej grupy i usuwad z niej innych użytkowników. Użytkownicy o ograniczonych uprawnieniach widoczni są wyłącznie dla ich mentora i tylko on może nimi zarządzad. W przypadku usunięcia konta mentora, użytkownicy ograniczeni stają się widoczni dla wszystkich użytkowników należących do grupy. Dowolny z tych użytkowników może przypisad ich do nowego mentora. Mechanizm taki jest bardzo wygodny w dużych organizacjach, liczących wielu użytkowników i asystentów pozwala uniknąd powtarzania procesu wprowadzania asystentów, gdy ich sponsor odchodzi z organizacji lub zmienia pełnioną rolę. Użytkownicy mogą także samodzielnie usuwad (wyrejestrowywad) swoje konta - niezależnie od tego, czy należą do grupy, czy nie. Tworzenie, aktywacja i usuwanie rejestracji Rejestracja w nowych usługach odbywa się zgodnie z procesem uwierzytelniania opartym na wiedzy, opisanym w sekcji Początkowe zgłaszanie użytkowników wcześniej w tym rozdziale. Rejestracja w każdej usłudze rządzi się własnymi zasadami i jest całkowicie niezależna od rejestracji w pozostałych usługach. Uwaga rejestracje w usługach tworzone przez niezależnych użytkowników zawsze pozostają niezależne od siebie, nawet jeśli dotyczą tego samego kontekstu usługi (korzystają z tych samych identyfikatorów specyficznych dla usługi). Nie istnieje żadna wiarygodna metoda wykrywania współdzielenia określonych rejestracji czy przyłączenia takiego użytkownika do grupy. Fakt, że dwaj użytkownicy uzyskują dostęp do jednej usługi na podstawie tego samego identyfikatora, nie oznacza wcale, że użytkownicy ci chcą współdzielid pozostałe rejestracje w ramach grupy. W przypadkach, gdy współdzielenie rejestracji jest pożądane, nowi użytkownicy zamiast niezależnie rejestrowad się w systemie i w poszczególnych usługach powinni byd wprowadzani za pomocą funkcji dodawania użytkownika. Dzięki temu cała grupa będzie mogła współdzielid wszystkie rejestracje. Aktywacja rejestracji w nowej usłudze odbywa się w taki sam sposób poprzez jawną opóźnioną aktywację z wykorzystaniem kodu aktywacyjnego lub natychmiastowo o ile usługa pozwala na aktywację natychmiastową, a użytkownik przedstawił prawidłowy kod aktywacyjny. Użytkownicy, którzy utworzyli własne rejestracje, mogą nimi zarządzad i usuwad je, podobnie jak każdy użytkownik należący do ich grupy. Przypisywanie (delegowanie) uprawnieo agenci Użytkownicy mogą przypisywad (delegowad) swoje uprawnienia innym użytkownikom w odniesieniu do określonych rejestracji w usługach. Ustanowieni w ten sposób agenci mogą działao w imieniu użytkownika, który przypisał im prawa. Jednym z przykładów zastosowania tej techniki jest autoryzacja księgowych i agentów podatkowych do przesyłania dokumentów w imieniu ich mocodawcy, którym może byd osoba lub organizacja. W zależności od usługi docelowej można wymusid stosowanie określonych reguł, na przykład: RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 61

62 - Przypisanie (delegacja) uprawnieo może odbywad się na zasadzie wyłączności po przydzieleniu agentowi rejestracji do usługi, mocodawca traci prawo do działania w kontekście tej samej rejestracji do momentu usunięcia agenta (wycofania przypisania). - Aby móc działad jako agent, użytkownik musi zarejestrowad się w określonej usłudze agenta. Jest tak najczęściej w przypadkach, w których wymagane jest zweryfikowanie określonych kwalifikacji zawodowych lub akredytacji. Reguły i procedury uwierzytelniania początkowego mogą w takim przypadku obejmowad niezbędną weryfikację - przedstawienie dokumentów, uzyskanie kodu aktywacyjnego itp. Relacje przypisania agentów są przechowywane wewnątrz huba i wykorzystywane do realizacji odpowiedniego odwzorowania tożsamości agenta na identyfikatory wykorzystywane w rejestracjach przypisanych mu przez mocodawców. W złożonych przypadkach mocodawcy mogą wyznaczad na agentów całe organizacje organizacja ma wtedy możliwośd wyznaczenia agentów-asystentów opiekujących się określonymi klientami. Uwaga wyznaczenie agenta to delikatny proces o poważnych implikacjach prawnych. Fakt wyznaczenia agenta powinien podlegad inspekcji i byd łatwo weryfikowalny. Dowód delegacji uprawnieo powinien byd przechowywany w sposób niebudzący zastrzeżeo (najlepiej w postaci zapisu u dostawcy usługi docelowej) i gwarantowad niepodważalnośd działao agenta podjętych w imieniu użytkownika. Poza możliwością wyznaczenia stałego agenta, możliwa jest także czasowa delegacja uprawnieo (na ograniczony okres i wyłącznie w kontekście określonej transakcji). W takich wypadkach potwierdzeniem delegacji są odpowiednie tokeny bezpieczeostwa, przesyłane wraz z komunikatami w systemie. Tokeny te są niezależnie weryfikowane przez hub podczas przetwarzania żądania. Pomoc techniczna i odzyskiwanie kont użytkowników System musi zapewniad funkcje niezbędne do świadczenia pomocy dla użytkowników i realizacji działao biura obsługi klientów, takich jak resetowanie zapomnianych haseł, odszukiwanie utraconych poświadczeo itp. Aktualizowanie identyfikatorów specyficznych dla usługi W hubie przechowywany jest dla każdej rejestracji zestaw identyfikatorów specyficznych dla usługi, której dotyczy rejestracja. Kolejne interakcje z hubem (uwierzytelnienie, autoryzacja, przesłanie dokumentu) odwzorowują zweryfikowaną ogólną tożsamośd użytkownika na identyfikatory specyficzne dla usługi. Wszelkie zmiany tych identyfikatorów, na przykład ze względu na modyfikacje wprowadzane w systemach informatycznych dostawców usług lub reorganizację agencji, wymagają komunikacji z hubem w celu uaktualnienia odpowiednich identyfikatorów zapisanych wraz z rejestracjami użytkowników. Aktualizacje mogą byd realizowane na poziomie pojedynczej rejestracji (odnalezienie konkretnego zestawu identyfikatorów i wymienienie go na nowy zestaw) lub jako grupowe modyfikacje wybranych identyfikatorów (na przykład odnalezienie wszystkich zestawów identyfikatorów, w którym pole identyfikator urzędu skarbowego ma wartośd 015, 018 lub 022 i zmiana wartości tego pola na 088). Uwaga dobierając zestawy identyfikatorów dla poszczególnych usług, warto wziąd pod uwagę nakłady pracy, jakie będzie pochłaniało utrzymanie ich aktualności. O ile przechowywanie atrybutów dodatkowych (wykraczających poza minimalny zestaw niezbędny do jednoznacznej identyfikacji użytkownika i kontekstu) i otrzymywanie ich w wyniku odwzorowania tożsamości może byd bardzo wygodnym rozwiązaniem, nakład prac na utrzymanie aktualności tych identyfikatorów może przeważyd korzyści wynikające z ich przechowywania. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 62

63 Usługi uwierzytelniania i autoryzacji Uwierzytelnianie i autoryzacja to podzbiór usług tożsamości i bezpieczeostwa, świadczonych przez hub usług dla sektora publicznego. Funkcjonalnośd uwierzytelniania i autoryzacji, zapewniana przez hub usług dla sektora publicznego, jest ogólna i dotyczy wszystkich typów tożsamości reprezentujących użytkowników indywidualnych (bezpośrednio lub przez pośredników), organizacje, systemy i inne jednostki. Funkcjonalnośd ta może zostad wykorzystana bezpośrednio na przykład przez portale do weryfikowania tożsamości użytkowników. W takim wypadku hub pełni rolę dostawcy usług tożsamości i tokenów bezpieczeostwa. Możliwe jest także wykorzystanie niebezpośrednie, na przykład przez usługi komunikacyjne do celów walidacji tożsamości użytej do podpisania dokumentu i autoryzacji dokumentu przez usługę docelową. Uwierzytelnianie Funkcje uwierzytelniania weryfikują poświadczenia tożsamości przedstawione przez użytkownika i odwzorowują je na konkretną tożsamośd. Poziomy uwierzytelniania Do każdego uwierzytelnienia można przypisad poziom określający wiarygodnośd tego uwierzytelnienia i związane z nim procedury. Jedną z takich klasyfikacji jest używana w Wielkiej Brytanii klasyfikacja tscheme, której poszczególne poziomy 0, 1, 2 oraz 3 odpowiadają kolejnym wyższym poziomom wiarygodności uwierzytelnienia, uprawniającym do określonych typów działao. - poziom 0 brak uwierzytelnienia. Rzeczywista tożsamośd osoby nie jest weryfikowana. Poziom ten dotyczy dostępu anonimowego lub sytuacji, w których użytkownicy podają pewne informacje, takie jak imię czy adres poczty elektronicznej, które są wykorzystywane w procesie i zapisywane, ale nie są weryfikowane; - poziom 1 tożsamośd użytkownika jest z dużym prawdopodobieostwem prawdziwa (na przykład internetowe zamówienie książki z użyciem karty kredytowej z dostawą na adres posiadacza rachunku); - poziom 2 istnieje wysoka pewnośd, że tożsamośd użytkownika jest prawdziwa (na przykład złożenie zeznania podatkowego dotyczącego podatku od towarów i usług lub podatku obrotowego, które jest wiążące prawnie); - poziom 3 prawdziwośd tożsamości użytkownika pozostaje poza wszelką wątpliwością (złożenie elektronicznego podania o wydanie paszportu). Im wyższy poziom, tym wyższa wymagana pewnośd weryfikacji tożsamości użytkownika. Poszczególne poziomy wiarygodności weryfikacji uzyskuje się, stosując odpowiednie, zatwierdzone i akredytowane przez tscheme procedury i metody techniczne. Niewątpliwą zaletą stosowania systemu tscheme lub podobnego jest jednolitośd wymagao oraz powszechna akceptacja (i kompatybilnośd) akredytowanych w tscheme dostawców przez wszystkie jednostki administracji publicznej. W krajach, w których struktura taka jeszcze nie istnieje, wdrożenie podobnego systemu może mied wpływ na przyspieszenie popularyzacji usług dla sektora publicznego. Związanie z każdym uwierzytelnieniem informacji o poziomie jego wiarygodności oraz określenie minimalnego poziomu, wymaganego do przeprowadzania poszczególnych operacji, sprawia, że kontrola uprawnieo dostępu na różnych etapach przetwarzania staje się łatwa i bardzo efektywna. Na przykład odpowiedź na pytanie które usługi można udostępnid danemu użytkownikowi? brzmi: te, których minimalny wymagany poziom wiarygodności jest równy lub niższy niż poziom uwierzytelnienia tego użytkownika. Czy ten użytkownik może przesład żądanie tego typu? tak, pod warunkiem, że minimalny poziom wiarygodności, wymagany do RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 63

64 przesłania tego żądania, jest równy lub niższy niż poziom uwierzytelnienia tego użytkownika oraz spełnione są pozostałe warunki autoryzacji. Gdy szczegółowośd tscheme nie jest wystarczająca do zaspokojenia jakichś specyficznych wymagao, możliwe jest rozszerzenie i uogólnienie tej struktury na dwa sposoby: - Dodanie poziomów pośrednich na przykład 1,5; 2,1; 2,3 przy jednoczesnym utrzymaniu prostoty reguły podstawowej (poziom uwierzytelnienia musi byd większy lub równy minimalnemu wymaganemu poziomowi wiarygodności). Różne rodzaje uwierzytelniania nadal porównywane są wyłącznie na podstawie zapewnianego przez nie poziomu, a więc poziom 2,2 zawsze będzie wyższy niż 2, niezależnie od dostawcy wybranego do celu uwierzytelnienia. Klasyfikacja ta jest powszechnie akceptowana przez wszystkich uczestników projektu i dostawców usług docelowych. - Rozróżnianie dostawców uwierzytelniania (nawet jeśli oferują takie same poziomy wiarygodności) i stosowanie bardziej złożonych reguł na przykład uzależniających prawa dostępu zarówno od poziomu uwierzytelnienia, jak i od dostawcy. Chociaż takie podejście jest elastyczne i pozwala na definiowanie specyficznych wymagao (takich jak wymagaj uwierzytelniania na poziomie 3 za pomocą karty inteligentnej wbudowanej w prawo jazdy, ale nie akceptuj uwierzytelnienia na poziomie 3 od innego dostawcy, na przykład na podstawie karty kredytowej ), ogranicza jednak spójnośd oraz możliwości wielokrotnego wykorzystywania dostawców uwierzytelniania we wszystkich usługach dla sektora publicznego. Model każda usługa z własnym dostawcą uwierzytelniania nie jest zbyt wygodny, a jego zakres zastosowao jest ograniczony do spełnienia określonych wymagao. Zgodnie z zasadą elastyczności (patrz wcześniejsza sekcja Reguły rządzące architekturą), aby hub usług dla sektora publicznego mógł zaspokoid wszystkie wymagania, jakie mogą pojawid się w okresie jego eksploatacji, usługa uwierzytelniania i autoryzacji powinna zapewniad pełną elastycznośd według powyższego opisu (większa szczegółowośd poziomów oraz możliwośd definiowania bardziej skomplikowanych reguł). Przedstawianie poświadczeo i stwierdzeo Uwierzytelnienie polega na zweryfikowaniu poświadczeo lub stwierdzeo przedstawionych przez użytkownika. Jeśli weryfikacja zakooczy się pozytywnie, z użytkownikiem można powiązad odpowiednią tożsamośd, co pozwala na utworzenie nowych związanych z tą tożsamością. Model ogólnego dostawcy (opisany w sekcji Wzorzec ogólny wymienni dostawcy w rozdziale Usługi zarządzania tożsamością wcześniej w tym dokumencie) pozwala na stosowanie wielu dostawców obsługujących różne rodzaje poświadczeo tożsamości. Na ilustracji 14. przedstawiono kilka możliwych przebiegów procesu uwierzytelniania w oparciu o różnych dostawców uwierzytelniania. Numerami oznaczono różne sposoby weryfikacji tożsamości użytkownika w oparciu o przesłane wraz z żądaniem poświadczenia, ich rodzaj oraz miejsce, z którego je wysłano: - bezpośrednio przez wewnętrznego (lokalnego) dostawcę (1), który weryfikuje dane użytkownika w oparciu o lokalny magazyn poświadczeo (2), - poprzez odwołanie się do zaufanego dostawcy zewnętrznego (3), który przeprowadza własną procedurę weryfikacji poświadczeo. Gdy żądanie uwierzytelnienia zawiera token bezpieczeostwa, jest on zwykle weryfikowany lokalnie (4). Może to byd token wystawiony przez zaufaną przez hub usługę tokenów bezpieczeostwa (Security Token Service STS) lub token wystawiony przez sam hub w wyniku wcześniejszego uwierzytelnienia według jednego z opisanych wcześniej sposobów. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 64

65 Ilustracja 14. Wywoływanie różnych dostawców uwierzytelniania Niezależnie od konkretnego typu weryfikacji i dostawcy wykorzystywanego w procesie uwierzytelniania (dostawca wewnętrzny lub zewnętrzny), pomyślna weryfikacja odwzorowuje poświadczenia lub stwierdzenia na tożsamośd użytkownika. Daje to podstawę do dalszego odwzorowania tożsamości na identyfikatory użytkownika wykorzystywane przez poszczególne usługi (patrz sekcja Odwzorowanie tożsamości na identyfikatory specyficzne dla usług w dalszej części tego dokumentu) oraz wydawania tokenów bezpieczeostwa (patrz sekcja Usługa tokenów bezpieczeostwa w dalszej części tego dokumentu). Uwierzytelnianie stowarzyszone Tradycyjne modele uwierzytelniania, w których weryfikację poświadczeo realizuje jeden dostawca tożsamości, uniemożliwiają stosowanie wielu istniejących lub przyszłych dostawców tożsamości i ograniczają dostęp różnych grup użytkowników do wspólnego podstawowego zestawu usług dla sektora publicznego. Uwierzytelnianie stowarzyszone zapewnia lepszą elastycznośd i pozwala użytkownikom należącym do różnych (niezależnych i oddzielnych) domen zaufania uwierzytelniad się na podstawie poświadczeo charakterystycznych dla ich domen i uzyskiwad dostęp do zasobów w innych domenach w oparciu o relacje zaufania pomiędzy domenami. Usługi docelowe nie muszą znad lokalnych identyfikatorów użytkowników, w związku z czym tożsamośd i inne atrybuty mogą pozostawad niejawne. Pozostaje to w zgodzie z zasadami zarządzania tożsamością zasadą minimalnego zakresu ujawniania niezbędnych informacji oraz zasadą tożsamości ukierunkowanej opisanymi wcześniej w rozdziale RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 65

66 Powszechne problemy dotyczące architektury oraz w artykule Model uwierzytelniania stowarzyszonego oparty jest na zestawie specyfikacji i standardów usług Web Service, dzięki czemu jest niezależny od platform systemowych i implementacji. Pozwala to na łatwą integrację systemu oraz na stosowanie gotowego, komercyjnego oprogramowania. Więcej informacji na temat standardów takich jak WS-Security, WS-Trust i WS-Federation można znaleźd w ostatniej części tego opracowania, zatytułowanej Odsyłacze, listy kontrolne i dalsze informacje. Hub usług może pełnid wiele różnych ról i byd elementem różnych topologii relacji zaufania w modelu uwierzytelniania stowarzyszonego. Jak opisano w sekcji Możliwe topologie w rozdziale Hub usług wcześniej w tym przewodniku, pojedyncza topologia może obejmowad wiele hubów. Hub może działad jako: - żądający dostawca tożsamości w procesie uwierzytelniania użytkownika hub generuje token bezpieczeostwa, który następnie w celu uzyskania autoryzowanego dostępu do usługi docelowej może zostad przedstawiony tej usłudze, - docelowy dostawca tożsamości weryfikuje tokeny bezpieczeostwa przedstawiane przez użytkowników i wystawia tokeny uprawniające do dostępu do usługi docelowej, - broker relacji zaufania pomiędzy dwiema lub więcej stronami (patrz ilustracja w temacie Huby równorzędne w sekcji Możliwe topologie wcześniej w tym opracowaniu) relacje zaufania każdej ze stron z brokerem zaufania pozwalają na utworzenie pośredniej relacji zaufania pomiędzy stronami. Na ilustracji 15. przedstawiono przykład typowych przepływów danych pomiędzy stronami. Numerami oznaczono kolejne kroki: 1. Żądający A przedstawia niezbędne poświadczenia swojemu dostawcy tożsamości w hubie Dostawca tożsamości żądającego w hubie 1 weryfikuje poświadczenia i zwraca token tożsamości żądającemu A. 3. Żądający A przedstawia token tożsamości docelowemu dostawcy tożsamości w hubie Docelowy dostawca tożsamości w hubie 2 sprawdza poprawnośd i pochodzenie tokenu tożsamości i zwraca token dostępu uprawniający do dostępu do zasobu docelowego. Docelowy dostawca tożsamości nie musi znad żądającego A ani jego tożsamości ufa dostawcy tożsamości żądającego w hubie 1 i wydanemu przez niego tokenowi tożsamości. 5. Żądający A w celu uzyskania dostępu do zasobu docelowego C, którego zabezpieczenia zarządzane są przez hub 2, przedstawia mu token dostępu. Ilustracja 15. Uwierzytelnianie stowarzyszone RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 66

67 W przykładzie tym specjalnie rozdzielono poszczególne strony, by móc jasno przedstawid wszystkie interakcje. Żądający A może byd portalem lub innym systemem, hub 1 centralnym hubem usług dla sektora publicznego, zasób docelowy może byd jakimś dostawcą usług dla sektora publicznego, korzystającym z usług uwierzytelniania i autoryzacji świadczonych przez hub 2. Oczywiście możliwe są także inne warianty implementacji takiego samego ogólnego przepływu danych. Na przykład podsystem komunikacyjny (B), znajdujący się wewnątrz huba 1, także może pełnid rolę żądającego, który w celu komunikacji z podsystemem komunikacyjnym (D), działającym wewnątrz huba 2, musi uzyskad niezbędne tokeny tożsamości i dostępu. Autoryzacja Po poprawnym uwierzytelnieniu się i ustaleniu tożsamości użytkownika zwykle następuje proces autoryzacji o szczegółowości odpowiadającej poziomowi kontekstu. Połączenie procesu uwierzytelnienia z procesem autoryzacji pozwala podnieśd wydajnośd cały proces może zamknąd się w jednym odwołaniu do podsystemu uwierzytelniania i autoryzacji. Żądania autoryzacji można realizowad na dwa podstawowe sposoby: - pobierz wszystko podaj listę wszystkich zasobów, do których dana tożsamośd posiada uprawnienia (i do których żądający może uzyskad autoryzowany dostęp patrz komentarze poniżej), - proces jawny żądanie autoryzacji zawiera jawne określenie zasobu docelowego, którego dotyczy. O ile metoda pobierz wszystko może wydawad się prostsza i łatwiejsza, przed podjęciem decyzji o jej wykorzystaniu warto wziąd pod uwagę kilka istotnych w kontekście usług dla sektora publicznego zagadnieo. Stosując tę metodę można niepotrzebnie udostępnid żądającemu informacje, co do których nie mamy pewności, czy żądający może mied do nich dostęp. Ogólnie rzecz biorąc, zastosowanie tej metody może doprowadzid do złamania niektórych podstawowych zasad zarządzania tożsamością. Weźmy na przykład użytkownika, który posiada pojedyncze poświadczenie, uprawniające go do dostępu do kilku usług dla sektora publicznego. Użytkownik może nie życzyd sobie, by w czasie, gdy używa portalu systemu emerytalnego, portal ten mógł pobrad identyfikatory związane ze sprawami podatkowymi, czy chodby uzyskad informacje, że użytkownik jest zarejestrowany w takich usługach, skoro informacje te nie mają żadnego związku z usługą, z której korzysta użytkownik. Jeśli portal może przeprowadzid operację autoryzacji pobierz wszystko, to może uzyskad informacje o wszystkich relacjach pomiędzy tym użytkownikiem a innymi użytkownikami, co nie jest pożądane. Zalecanym rozwiązaniem w takich przypadkach jest autoryzacja jawna. Żądający definiuje, jakiego obiektu dotyczy żądanie, a dostawca usług autoryzacji zwraca odpowiednią odpowiedź. Żądanie autoryzacji nie musi dotyczyd pojedynczego celu może zawierad całą listę usług docelowych. Można też uwzględniad dodatkowe warunki, na przykład w oparciu o tożsamośd żądającego (w przypadku pośrednika można na przykład sprawdzid, do jakich zasobów żądający ma prawo sprawdzad autoryzację) lub w oparciu o jawną zgodę użytkownika, dołączoną do samego żądania. W uzasadnionych wypadkach (i gdy użytkownik wyraził na to zgodę) można odstąpid od tego ogólnego zalecenia i uzyskad autoryzację do wszystkich usług, do których użytkownik posiada prawa dostępu. Przykładem takiej sytuacji jest przedstawienie pełnej listy dostępnych usług w celach konserwacyjnych (zarządzanie rejestracjami, przypisywanie praw itp.). Sprawdzanie rejestracji w usługach Jednostką autoryzacji w przyjętym ogólnym modelu tożsamości (opisanym w części Podstawowy model tożsamości i zasady w sekcji Usługi zarządzania tożsamością wcześniej w tym dokumencie) jest pojedyncza usługa docelowa można sprawdzid tylko to, czy użytkownik może, czy nie może uzyskad dostęp do usługi X. Ma to wpływ na definicję usługi docelowej każda usługa musi byd grupą akcji (żądao lub operacji przedłożenia dokumentu) o odrębnych regułach dostępu. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 67

68 Żądanie autoryzacji odwzorowuje uwierzytelnioną wcześniej tożsamośd na poprawne, istniejące i aktywne rejestracje w usługach. W przypadku żądao typu pobierz wszystko operacja autoryzacji zwraca listę wszystkich rejestracji związanych z daną tożsamością. Autoryzacja jawna porównuje żądanie zawierające listę usług, do których żądający chce uzyskad dostęp, z ważnymi rejestracjami dla danej tożsamości i zwraca jedynie podzbiór tej listy (to jest listę usług, w których tożsamośd posada prawidłową rejestrację). Odwzorowanie tożsamości na identyfikatory specyficzne dla usług Ważnym aspektem autoryzacji jest odwzorowanie ogólnej (i potencjalnie takiej samej dla wielu usług) tożsamości na identyfikatory specyficzne dla danych usług, związane z aktywnymi rejestracjami, odnalezionymi w procesie autoryzacji. Odwzorowanie pozwala na ukrycie tożsamości ogólnej i określa kontekst relacji z daną usługą. Usługi docelowe mogą niezależnie ustalad wykorzystywane przez nie identyfikatory i nie ma potrzeby modyfikowania istniejących już systemów w celu wprowadzenia jakiegoś nowego identyfikatora (chyba że właściciel sam zdecyduje się na taki krok). Gdy ogólna tożsamośd zostanie związana z usługą poprzez proces rejestracji ustalający kontekst relacji i zbiór identyfikatorów specyficznych dla usługi, kolejne żądania autoryzacji dla tej tożsamości będą zwracały te identyfikatory. Szczegółowe zasady działania opisano w temacie Rejestracja w usługach i odwzorowywanie tożsamości w sekcji Usługi zarządzania tożsamością wcześniej w tym dokumencie. Delegowanie zaufania W przypadku delegowania uprawnieo, które polega na upoważnieniu innego użytkownika do działania w imieniu określonej osoby lub organizacji w kontekście określonej usługi (patrz temat Przypisywanie (delegowanie) uprawnieo agenci w sekcji Zarządzanie użytkownikami i rejestracjami wcześniej w tym dokumencie), proces odwzorowania jest bardziej skomplikowany. Polega on na odszukaniu prawidłowego łaocucha odwzorowao łączącego tożsamośd z usługą docelową. Użytkownik z jednej organizacji może na przykład uprawnid inną organizację-agenta do działania w jego imieniu, a następnie użytkownik z organizacji-agenta może ustanowid asystenta, którego zadaniem jest opiekowanie się określonymi klientami. Wynik operacji autoryzacji ma jednak nadal tę samą postad tożsamośd A może uzyskad dostęp do usługi S w kontekście wyznaczanym przez specyficzne dla tej usługi identyfikatory X, Y i Z. Taka delegacja uprawnieo jest relatywnie wygodna w przypadku stałej, długotrwałej delegacji, która może zostad unieważniona przez jawne jej wypowiedzenie. W przypadku delegacji krótkotrwałych (takich jak delegacje ustanowione jedynie na potrzeby określonej interakcji na przykład przedłożenia dokumentu), prawo delegacji może zostad przesłane wraz z samym żądaniem autoryzacji. W takim wypadku proces odwzorowania tożsamości na rejestrację w usłudze bierze pod uwagę delegację (i daje wynik taki sam, jak w przypadku delegacji stałej, jedynie o krótszym okresie ważności i z innymi ograniczeniami). Taki proces nie oznacza trwałego zapisania relacji delegacji. Zrealizowana delegacja krótkotrwała nie ma wpływu na nowe żądania, chyba że żądania te same dotyczą delegacji. Szczegółowośd autoryzacji Testy autoryzacji, realizowane przez hub w oparciu o aktywne rejestracje i ewentualne delegacje uprawnieo, są ograniczone do poziomu usługi docelowej. Dalsze decyzje autoryzacji na niższych poziomach mogą byd realizowane gdzie indziej (na przykład w innym hubie) w oparciu o dostarczone przez hub identyfikatory specyficzne dla danej usługi. Ustalenie odpowiedniej szczegółowości usług oraz poziomu szczegółowości identyfikatorów to bardzo ważne zagadnienie. Niezbędne jest zachowanie równowagi pomiędzy wygodą otrzymywania wszystkich informacji w ramach identyfikatorów zwracanych w procesie autoryzacji (identyfikatory te mogę obejmowad także rolę i inne atrybuty) a koniecznością utrzymania aktualności kopii tych identyfikatorów, przechowywanej w hubie. Przykładem autoryzacji kaskadowej może byd przypadek prawnika działającego w imieniu swojego klienta w kontekście procesu sądowego. Prawnik, zarejestrowany w odpowiednich usługach prawniczych (przy czym rejestracja wymaga przedstawienia dokumentów RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 68

69 potwierdzających prawo do wykonywania zawodu), może uzyskad dostęp do centralnego huba usług dla sektora publicznego, korzystając z poświadczeo wystawionych przez ten hub lub uzyskanych od innego zaufanego lub stowarzyszonego dostawcy tożsamości. Gdy prawnik korzysta z portalu prawnego lub innej usługi, hub sektora publicznego uwierzytelnia go i autoryzuje jego dostęp do usług prawniczych. Proces autoryzacji zwraca odpowiednie identyfikatory wykorzystywane przez usługi prawnicze. Z punktu widzenia huba, uwierzytelniona tożsamośd prawnika ma prawa dostępu do usług prawniczych w kontekście określanym przez odpowiednie, specyficzne dla tej usługi identyfikatory. W oparciu o te identyfikatory portal (lub inny system, z którego ten portal korzysta) może podejmowad dalsze decyzje dotyczące autoryzacji. Może na przykład sprawdzid powiązania z określoną sprawą lub pełnioną rolę i na tej podstawie udzielid dostępu do pewnych dokumentów. Usługa docelowa utrzymuje szczegółowe informacje autoryzacyjne, dotyczące powiązao prawników ze sprawami, i nie udostępnia tych informacji hubowi zadaniem huba jest tylko uwierzytelnienie użytkownika i sprawdzenie autoryzacji dostępu do określonej usługi jako całości. Usługa tokenów bezpieczeostwa Hub usług dla sektora publicznego może pełnid rolę usługi tokenów bezpieczeostwa (Security Token Service STS), zdefiniowanej w standardach WS-Trust, WS-Federation i WS-Security (łącza do tych standardów znajdują się w sekcji Odsyłacze, listy kontrolne i dalsze informacje). Hub może zatem byd częścią stowarzyszonej sieci usług Web Service, zapewniających funkcje uwierzytelniania, autoryzacji i inną funkcjonalnośd ułatwiającą integrowanie systemu w oparciu o sprawdzone standardy i specyfikacje. Usługa tokenów bezpieczeostwa wydaje, weryfikuje i wymienia tokeny bezpieczeostwa. Żądający przesyła żądanie, a usługa jeśli pozwalają na to wymagania adresata oraz obowiązujące zasady wydaje mu token bezpieczeostwa. Tokeny bezpieczeostwa Tokeny bezpieczeostwa zawierają zbiory stwierdzeo, których wiarygodnośd gwarantowana jest przez wydawcę tokenu. Wydawca może podpisywad tokeny z wykorzystaniem metod kryptograficznych, co gwarantuje ich integralnośd (brak możliwości wprowadzenia zmian po podpisaniu) i pozwala na weryfikację ich pochodzenia. Pomyślne przeprowadzenie przez hub usług dla sektora publicznego procesu uwierzytelniania i autoryzacji skutkuje zwykle wydaniem żądającemu tokenu bezpieczeostwa. Wydawanie tokenów bezpieczeostwa Token bezpieczeostwa jest wynikiem przeprowadzonego przez hub procesu uwierzytelniania i autoryzacji. Token może zawierad następujące informacje: - uzyskane w wyniku uwierzytelnienia informacje na temat tożsamości wraz z odpowiednimi atrybutami, takimi jak sposób uwierzytelnienia i poziom wiarygodności, - informacje na temat autoryzacji dostępu, na przykład w postaci listy dostępnych usług docelowych, - specyficzne dla poszczególnych usług identyfikatory i atrybuty. Rodzaj stwierdzeo zawartych w tokenie może się różnid w zależności od roli pełnionej przez hub i jego lokalizacji w topologii całego systemu. Możliwe jest także wydawanie wielu tokenów uprawniających do dostępu do różnych usług docelowych. W następnej sekcji przewodnika opisano kilka przykładowych scenariuszy zastosowao. Możliwe scenariusze zastosowao Interakcje pomiędzy poszczególnymi hubami oraz role pełnione przez odpowiadające im usługi tokenów bezpieczeostwa mogą byd różne, w zależności od wybranej topologii systemu RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 69

70 i przyjętego modelu zabezpieczeo. Na ilustracji 16. przedstawiono kilka możliwych scenariuszy. Kolejne etapy procesu oznaczono numerami: 1. Użytkownik kontaktuje się z portalem i przedstawia mu swoje poświadczenia tożsamości dla systemu dla sektora publicznego. 2. Portal wysyła żądanie do huba A (który może byd centralnym hubem dla sektora publicznego), przedstawiając poświadczenia tożsamości użytkownika i wskazując usługę docelową X. 3. Po pomyślnym uwierzytelnieniu użytkownika i sprawdzeniu autoryzacji dostępu do usługi X, hub A zwraca dwa tokeny wystawione przez usługę STS A: a.token uwierzytelnienia (Au) potwierdzający pomyślne uwierzytelnienie użytkownika. Token ten może zostad później wykorzystany do uzyskania dodatkowych autoryzacji bez potrzeby ponownego pełnego uwierzytelnienia użytkownika na podstawie poświadczeo tożsamości; b.token autoryzacji dostępu użytkownika do usługi X (AzX), zawierający odpowiednie identyfikatory specyficzne dla usługi X, definiujące kontekst relacji użytkownika z tą usługą (na przykład numer identyfikacji podatkowej, identyfikator PESEL, identyfikator usług socjalnych). 4. Portal w imieniu użytkownika kontaktuje się z usługą STS X i przedstawia jej token uwierzytelnienia AzX wystawiony przez usługę STS A. 5. Usługa STS X sprawdza prawidłowośd tokenu AzX i wystawia nowy token X (token specyficzny dla tej usługi STS), zawierający stwierdzenia potrzebne do dostępu do usługi X. Usługa może na przykład przetłumaczyd lub dokonad odwzorowania znajdujących się w tokenie AzX identyfikatorów specyficznych dla usługi na informację na temat roli danego użytkownika i na inne atrybuty w kontekście interakcji z usługą X. 6,7,8... Obsługując kolejne wywołania usługi X przez użytkownika koocowego, portal przedstawia token X, którego walidacja może byd bardzo efektywna o wiele bardziej wydajna niż wcześniejsza walidacja tokenu AzX z translacją lub odwzorowywaniem atrybutów. Umieszczenie w kontekście wywołania odpowiednich identyfikatorów, specyficznych dla usług X, zawartych w tokenie X, pozwala także na podejmowanie dalszych decyzji dotyczących autoryzacji wewnątrz usługi. Ilustracja 16. Role usług STS i wymiana tokenów RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 70

71 Kontynuujmy nasz przykład. Po zakooczeniu interakcji z usługą X, użytkownik (lub portal w imieniu użytkownika) chce uzyskad dostęp do usługi Y. Proces autoryzacji przedstawiono na ilustracji 17. Proces przebiega nieco inaczej niż w poprzednim przykładzie. Jeśli token uwierzytelnienia (Au), wystawiony w poprzednim przykładzie przez usługę STS A, jest nadal ważny i został w odpowiedni, bezpieczny i wiarygodny sposób przechowany przez pośrednika (portal) lub użytkownika koocowego, uzyskanie autoryzacji dostępu do usługi Y jest prostsze i nie wymaga ponownego podania poświadczeo przez użytkownika. W ten sposób użytkownik raz zameldowany do systemu może uzyskad dostęp do wielu usług. Proces autoryzacji przebiega następująco: 1. Użytkownik żąda dostępu do usługi Y. 2. Portal wysyła żądanie do huba A, przedstawiając token uwierzytelniania (Au), uzyskany wcześniej od usługi STS A, i wskazuje usługę docelową Y. 3. Po zweryfikowaniu poprawności tokenu uwierzytelniania Au i autoryzacji dostępu użytkownika do usługi Y, hub A zwraca dwa tokeny wystawione przez usługę STS A: a. opcjonalnie odświeżony lub odnowiony token uwierzytelnienia (Au) o przedłużonym okresie ważności, co pozwala na przedłużenie pierwszego uwierzytelnienia i dalsze korzystanie z usług dostępu z jednokrotnym logowaniem (wystawienie takiego tokenu podlega odpowiednim zasadom konieczne jest utrzymanie równowagi między wygodą użytkowania a bezpieczeostwem); b. token autoryzacji dostępu użytkownika do usługi Y (AzY), zawierający odpowiednie identyfikatory specyficzne dla usługi Y, definiujące kontekst relacji użytkownika z tą usługą. 4. Portal w imieniu użytkownika kontaktuje się z usługą Y i przedstawia jej token autoryzacji AzY wystawiony przez usługę STS A. 5. Usługa STS Y sprawdza prawidłowośd tokenu AzY i wystawia nowy token Y (token specyficzny dla tej usługi STS), zawierający stwierdzenia potrzebne do dostępu do usługi Y. 6,7,8... W kolejnych wywołaniach usługi Y użytkownik koocowy lub portal przedstawia usłudze token Y, którego walidacja może byd bardzo efektywna o wiele bardziej wydajna niż początkowa walidacja tokenu AzY z translacją lub odwzorowywaniem atrybutów. Umieszczenie w kontekście wywołania odpowiednich identyfikatorów specyficznych dla usług Y, zawartych w tokenie Y, pozwala także na podjęcie dalszych decyzji dotyczących autoryzacji wewnątrz usługi. Ilustracja 17. Role STS i wymiana tokenów kolejna usługa RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 71

72 Możliwośd pełnienia przez hub usług roli usługi tokenów bezpieczeostwa STS pozwala na obsługę także wielu innych scenariuszy i umożliwia stosowanie różnych topologii odpowiadających określonym wymaganiom i ograniczeniom. Udostępnianie usług uwierzytelniania i autoryzacji Funkcjonalnośd uwierzytelniania i autoryzacji udostępniania jest w postaci zbioru usług Web Service, dzięki czemu jest ogólne dostępna dla klientów wszystkich typów innych systemów, portali i pakietów oprogramowania uruchamianych na komputerach klienckich. Bezpieczeostwo wywołao usług Web Service może zostad zapewnione na różnych poziomach: - bezpieczeostwo na poziomie transportowym, na przykład wykorzystanie protokołów TLS/SSL, które pozwalają na szyfrowanie wszystkich przesyłanych informacji i chronią przed podsłuchami. Protokoły te pozwalają także na zapewnienie dostępu tylko tym jednostkom, które posiadają odpowiedni certyfikat klienta; - bezpieczeostwo na poziomie komunikatu (Web Service) żądanie samo zawiera elementy zabezpieczeo niezbędne do zidentyfikowania nadawcy i zaszyfrowania określonych części komunikatu. Zważywszy na poufnośd wywołao dotyczących uwierzytelniania i autoryzacji, warto rozważyd ograniczenie dostępu do różnych części tej funkcjonalności poprzez identyfikowanie klientów i wprowadzenie ochrony przed potencjalnymi atakami. Na przykład: Czy ten portal (usługa) jest akredytowany i ma prawo przeprowadzad operacje uwierzytelnienia i autoryzacji? oraz Czy ten klient ma prawo pytad o autoryzację dostępu do usługi X?. W przypadkach, gdy hub usług dla sektora publicznego zapewnia zarówno funkcjonalnośd komunikacyjną, jak i funkcjonalnośd uwierzytelniania i autoryzacji, warto rozważyd udostępnienie funkcjonalności uwierzytelniania i autoryzacji niezależnie od interfejsów Web Service wewnętrznie, dla zaufanych podsystemów, takich jak usługi komunikacji. Pozwoli to uniknąd dodatkowych nakładów zasobów obliczeniowych na wywoływanie publicznie dostępnych usług Web Service i podnieśd wydajnośd. Podejmując decyzję o takiej modyfikacji, należy wziąd pod uwagę także inne interfejsy publiczne i prywatne. Usługa katalogu usług Jedną z głównych cech architektury zorientowanej na usługi (Service Oriented Architecture SOA) jest przezroczystośd (niezależnośd) lokalizacji usług udostępnianych konsumentom. Fizyczna lokalizacja usługi może ulec zmianie z wielu powodów jedna usługa, udostępniana w ramach jednego kontraktu usługowego, może byd świadczona jednocześnie z wielu rozproszonych geograficznie lokalizacji; udostępnienie usługi w innej lokalizacji może też byd spowodowane awarią w podstawowej lokalizacji świadczenia tej usługi. Fizyczny adres usługi może zostad odnaleziony ręcznie i zapisany w aplikacji w czasie jej tworzenia, ale także może byd przechowywany w danych konfiguracyjnych. Przeniesienie lub wycofanie usługi sprawi jednak, że aplikacja ta przestanie poprawnie funkcjonowad. Co więcej, konsumenta nie interesuje fizyczne miejsce świadczenia usług. Konsument jest zainteresowany tym, co dana usługa może mu zaoferowad. W związku z tym, aby móc uniknąd zapisywania fizycznego adresu świadczenia usługi w kodzie aplikacji, konsument musi mied możliwośd ustalenia tego adresu w czasie pracy aplikacji. W tym zakresie można polegad na katalogu usług. Katalog umożliwia konsumentom wyszukiwanie usług na podstawie pewnego zbioru kryteriów w czasie pracy aplikacji, wtedy, gdy zachodzi taka potrzeba. Ze względu na brak wiedzy na temat wzajemnego położenia aplikacji i usługi przed skorzystaniem z tej usługi, dostawca usługi powinien udostępnid prosty interfejs wywołania usługi. Interfejs zbyt drobnoziarnisty lub gadatliwy może powodowad kłopoty z wydajnością w przypadku, gdy aplikację i usługę będą dzieliły tysiące kilometrów. Usługi powinny przyjmowad komunikaty zawierające wszystkie dane niezbędne do realizacji całej operacji, bez konieczności prowadzenia RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 72

73 długiej i kosztownej wymiany komunikatów pomiędzy konsumentem a dostawcą, typowej dla protokołów typu RPC z rozproszonym modelem obiektowym. Usługa katalogu usług powinna utrzymywad rejestr wszystkich usług huba dla sektora publicznego (bezpieczeostwo, komunikacja, usługi pomocnicze), pozwalając konsumentom na wyszukiwanie określonych usług na przykład usługi rejestracji dokumentów dla określonego regionu lub usługi pomocniczej oferującej funkcje obsługi płatności. Interakcje pomiędzy konsumentem a dostawcą z wykorzystaniem katalogu usług przedstawiono na ilustracji 18. Ilustracja 18. Interakcje pomiędzy konsumentem usługi, dostawcą usługi i katalogiem usług Dostawca usługi rejestruje się w katalogu usług, umożliwiając konsumentom odnalezienie potrzebnych im usług. Konsument może przeszukad katalog usług na podstawie metadanych opisujących zarejestrowane usługi. Po odnalezieniu odpowiedniej usługi konsument nawiązuje połączenie z jej dostawcą i może rozpocząd korzystanie z usługi. UDDI UDDI to zaakceptowany przez branżę standard, definiujący strukturę katalogu usług i odpowiednie protokoły do obsługi tego katalogu. Uwaga UDDI to akronim od Universal Description, Discovery and Integration (uniwersalne opisywanie, wyszukiwanie i integrowanie usług). Niedawno opublikowana została wersja 3. tego standardu, natomiast standard WS-I Basic Profile 1.1 (stanowiący podstawy interoperacyjności pomiędzy usługami Web Service) obecnie oparty jest na wersji 2 tego standardu. Tworzeniem specyfikacji UDDI zajmuje się organizacja OASIS; specyfikacja dostępna jest pod adresem UDDI umożliwia dostawcom rejestrowanie udostępnianych usług Web Service i publikowanie opisów usług dla konsumentów. Katalog może zatem służyd do ogłaszania dostępności usług i wyszukiwania potrzebnych usług. Usługi UDDI oferują zwykle trzy kategorie usług: tzw. białe strony, żółte strony i zielone strony. Białe strony zawierają dane kontaktowe, adresy i inne informacje na temat przedsiębiorstw udostępniających usługi Web Service. Żółte strony kategoryzują usługi Web Service zgodnie ze standardową taksonomią. Zielone strony obejmują specyfikacje techniczne zarejestrowanych usług, takie jak informacje niezbędne do nawiązania połączenia czy szczegóły na temat implementacji. Uwaga ze względu na potencjalnie dużą złożonośd relacji tworzonych w rejestrze UDDI, możliwośd rozszerzania modelu danych o nowe schematy kategoryzacyjne oraz koniecznośd stosowania spójnych standardów nazewniczych, przed implementacją katalogu konieczne jest zaplanowanie odpowiedniej struktury rejestru UDDI. Planowanie i projektowanie struktury zwykle odbywa się na zasadach podobnych do tych stosowanych podczas implementowania katalogu Active Directory. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 73

74 Metadane usług Każda usługa może posiadad w katalogu UDDI zestaw metadanych, który konsumenci mogą wykorzystywad w poszukiwaniu usług umożliwiających wykonanie określonej operacji lub funkcji. Te metadane to tmodel wykorzystywany do wymiany informacji takich jak opis usługi (który może byd zapisany w WSDL) lub wskaźników do innych metadanych związanych z usługą. tmodel nie jest ograniczony do poszczególnych rejestracji usług w UDDI może posłużyd do wyszukiwania kompatybilnych usług Web Service. Wiele usług może zawierad wskaźniki do tego samego obiektu tmodel. Każda usługa może także zawierad wskaźniki do wielu różnych obiektów tmodel, odpowiadających różnym implementowanym przez nią interfejsom. Publikacja usługi Katalog UDDI udostępnia interfejsy SOAP API do publikowania i pobierania informacji z katalogu UDDI. Dostawcy usług korzystają z publikacyjnego interfejsu API do wprowadzania do katalogu UDDI informacji kontaktowych na temat przedsiębiorstwa, nowych usług, tmodeli i klasyfikacji. Wszystkie żądania wykonania operacji przesyłane są do operatora katalogu UDDI z wykorzystaniem protokołu HTTPS, co zapewnia zachowanie poufności przekazywanych informacji. Dostawca usług, aby móc korzystad z publikacyjnego interfejsu API, musi najpierw zarejestrowad się u operatora katalogu UDDI (właściciela katalogu usług) i uzyskad poświadczenia niezbędne do nawiązania połączenia z katalogiem. Na podstawie tych poświadczeo dostawca usługi może za każdym razem, gdy chce skorzystad z interfejsu publikacyjnego do wprowadzenia danych o udostępnianych przez siebie usługach, uzyskad token uwierzytelniający. Wystawienie tokenu realizowane jest z wykorzystaniem operacji get_authtoken. Model danych UDDI obejmuje wymienione poniżej encje. Encje te modyfikowane są przez publikacyjny interfejs API podczas wprowadzania informacji o dostawcy usług oraz oferowanych przez niego usługach. businessentity opis dostawcy usługi. Z tą strukturą związane są wszystkie poniższe struktury oraz dane kontaktowe, takie jak nazwa i adres dostawcy. Dostawcy mogą byd organizacjami, oddziałami przedsiębiorstw itp. Wzajemne relacje pomiędzy elementami businessentity reprezentowane są przez encję publisherassertion; businessservice opis zbioru jednej lub więcej usług biznesowych udostępnianych przez dostawcę. Opis może zawierad kategoryzację usługi na podstawie schematu i obejmowad lokalizację geograficzną, typ usługi, parametry zapewnienia jakości obsługi (QoS Quality of Service) itd.; bindingtemplate opis sposobu połączenia z usługą Web Service reprezentującą określoną usługę biznesową. W przypadku usług Web Service udostępnianych za pośrednictwem protokołu SOAP, którego komunikaty przekazywane są za pomocą protokołu HTTP, encja ta zawiera adres URL, pod którym dostępna jest usługa; tmodel odcisk palca zbiór informacji na temat specyfikacji usługi Web Service. Zwykle jest to określenie lokalizacji przechowywania zapisanej w języku WSDL specyfikacji interfejsów usługi, jednak mogą to byd także inne dane opisowe. Relacje pomiędzy tymi encjami przedstawiono na ilustracji 19. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 74

75 Ilustracja 19. Relacje pomiędzy encjami UDDI Wyszukiwanie usługi Interfejs API wyszukiwania usług umożliwia konsumentowi usług odszukanie i nawiązanie połączenia z usługą Web Service w czasie wykonywania aplikacji. Kryteriami wyszukiwania mogą byd dane organizacji udostępniającej usługę, atrybuty usługi lub obiekty tmodel (interfejsy usług). W wyniku operacji wyszukiwania konsument otrzymuje zbiór wyników, który może następnie przejrzed i wybrad najbardziej odpowiednią usługę. Zawieranie kontraktu (tzn. ustalanie warunków dostarczania usług przez dostawcę) w czasie pracy aplikacji nie jest działaniem typowym to zadanie zwykle realizowane jest na etapie opracowywania aplikacji. Programista, aby móc wykorzystad daną usługę w swojej aplikacji, musi zrozumied jej interfejs. Nie da się tego zrobid dynamicznie. Dynamiczne łączenie z usługą w czasie wykonywania aplikacji dotyczy wyłącznie fizycznej lokalizacji usługi (adres lub łaocuch URL) oferującej znany interfejs. API umożliwia realizację kilku podstawowych operacji związanych z wyszukiwaniem zbioru powiązanych ze sobą usług: - find_business wyszukanie informacji o jednej lub większej liczbie organizacji charakteryzowanych przez określone kategorie lub identyfikatory. Można także wyszukiwad według nazwy lub referencji do obiektu tmodel; - find_service operacja zwraca listę usług spełniających podane kryteria wyszukiwania, na przykład typ usługi; - find_tmodel operacja zwraca struktury tmodel, umożliwiając konsumentowi przeszukanie katalogu pod kątem usług implementujących interfejsy odpowiadające wyszukanej strukturze tmodel. Istnieje możliwośd wdrożenia prostej metody równoważenia obciążenia przy każdym wywołaniu usługi, aplikacja powinna nawiązywad połączenie z kolejną usługą z listy odnalezionych usług implementujących ten sam interfejs (tak zwane wybieranie round-robin). Co więcej, jeśli w przypadku niepowodzenia wywołania usługi Web Service aplikacja ponowi żądanie, wysyłając je do tej samej usługi lub do usługi następnej na liście, uzyskamy ochronę przed skutkami awarii pojedynczego dostawcy usług. Replikacja Rejestr UDDI pozwala na replikację danych z innymi rejestrami w sposób podobny do systemu DNS (Domain Name System). Do obsługi replikacji służy specjalny interfejs API, umożliwiający operatorom rejestru synchronizację rejestrów UDDI. Synchronizacja powoduje, że pomiędzy bazami danych przesyłane są informacje na temat zmian wprowadzonych do tych baz (na RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 75

76 przykład zmienione adresy usług), jednak dostawca usług powinien aktualizowad własne informacje zawsze u tego operatora, u którego zarejestrował je po raz pierwszy. Replikacja rejestrów usług sprawia, że konsument może w lokalnym katalogu usług wyszukiwad usługi, których dostawcy zarejestrowani są w innych katalogach. Jedyna niezbędna konfiguracja to podanie lokalizacji odpowiedniego katalogu usług. Gdyby nie było replikacji, konsument, chcąc odszukad fizyczną lokalizację potrzebnej usługi, musiałby jeszcze przed rozpoczęciem poszukiwao wiedzied, w którym katalogu zarejestrowany jest dostawca poszukiwanej usługi. Usługi rejestracji dokumentów Opisana w tym przewodniku architektura referencyjna pozwala na elektroniczną interakcję z administracją publiczną za pośrednictwem wielu różnych kanałów dostępu. Najważniejszym etapem interakcji z dowolną jednostką administracji publicznej jest etap przedłożenia dokumentu. Złożenie zeznania podatkowego, wystąpienie o zezwolenie lub zgłoszenie błędu wszystkie te operacje wymagają przedłożenia w agencji dokumentu określonego rodzaju (czasem wraz z załącznikami takimi jak zdjęcia). Rola usługi rejestracji dokumentów Usługa rejestracji dokumentów w hubie usług jest odpowiedzialna za przyjmowanie dokumentów i przetwarzanie ich w imieniu usługi rejestracji dokumentów kanału lub innej równorzędnej usługi rejestracji dokumentów, która zainicjowała dostarczenie dokumentu. Koperta dokumentu to komunikat, który zawiera nie tylko sam dokument, ale także metadane opisujące ten dokument, takie jak tożsamośd nadawcy, aplikacja użyta do utworzenia dokumentu, data przedłożenia dokumentu oraz typ dokumentu dołączonego do komunikatu. Metadane komunikatu mogą byd przydatne dla usług, które muszą analizowad pewne ogólne cechy zawartości komunikatu (czyli dokumentu) w celu podjęcia decyzji na temat dalszego przetwarzania lub dalszej drogi przesyłu komunikatu. Przykładem podstawowych metadanych, jakie mogą byd przydatne podczas podejmowania decyzji o przekazaniu komunikatu do właściwej agencji, mogą byd agencja docelowa i typ dokumentu. Usługa rejestracji dokumentów jest także odpowiedzialna za sprawdzanie bezpieczeostwa komunikatu i ochronę przed manipulowaniem jego zawartością. Oprócz sprawdzenia poprawności komunikatu, obowiązkiem usługi może także byd odszyfrowanie zawartośd komunikatu w celu przekazania jej usłudze agencji, która nie ma dostępu do technologii umożliwiającej poznanie treści komunikatu. Po sprawdzeniu poprawności komunikatu, usługa rejestracji dokumentu powinna zweryfikowad autentycznośd jego nadawcy poprzez sprawdzenie, czy dołączony do komunikatu token bezpieczeostwa jest poprawny. Następnie musi przeprowadzid autoryzację dokumentu w oparciu o wymagania usługi docelowej i porównanie poziomu uwierzytelnienia nadawcy z minimalnym poziomem określonym dla tej usługi. Innymi słowy, usługa może wymagad weryfikacji tożsamości nadawcy w oparciu o nazwę użytkownika i odpowiednio silne hasło. Jeśli uwierzytelnienie odbędzie się za pośrednictwem nazwy użytkownika i słabego hasła, usługa może odrzucid komunikat. Poziom uwierzytelnienia powinien byd właściwością komunikatu (zabezpieczoną podpisem elektronicznym przed ewentualnymi nadużyciami). Po zweryfikowaniu nadawcy i potwierdzeniu poziomu uwierzytelnienia odpowiedniego dla usługi docelowej może nastąpid ogólna autoryzacja operacji. Przez operację rozumiemy tu przedłożenie dokumentu określonego typu w określonej usłudze docelowej albo przekazanie dokumentu do innej, równorzędnej usługi rejestracji dokumentów. Przed takim przekazaniem może jednak nastąpid autoryzacja wstępna. Autoryzacja polega na sprawdzeniu zestawu stwierdzeo w oparciu o usługę autoryzacji. Jako stwierdzenia można przyjąd prawo nadawcy do przedkładania dokumentów typu X, jego przynależnośd do grupy Y lub dowolną kombinację takich stwierdzeo. Przekazanie dokumentu do usługi docelowej następuje po pozytywnym przejściu komunikatu przez wszystkie testy bezpieczeostwa. Jeśli dokument przekazywany jest do równorzędnej usługi rejestracji dokumentów, testy bezpieczeostwa mogą nie byd przeprowadzane zależy to tylko od RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 76

77 wymagao stawianych nadawcy. Wymagania mogą byd określone w taki sposób, że komunikat zostanie sprawdzony tylko po przesłaniu go do właściwego odbiorcy lub przez dowolną usługę pośredniczącą w przekazywaniu tego dokumentu. Przekazanie dokumentu do usługi docelowej wymaga dostępu do pewnej formy funkcjonalności EAI (Enterprise Application Integration) najczęściej udostępnianej przez platformę integracyjną. Zagadnienia integracji zebrano w osobnej sekcji dalej w tym dokumencie. Podstawowa architektura Podstawową architekturę usługi rejestracji dokumentów można podzielid na dwa obszary: - stronę publiczną, wykorzystywaną przez konsumentów przedkładających dokumenty, - stronę prywatną, wykorzystywaną przez dostawcę usługi (centralną jednostkę administracji, władze, lokalny organ zarządzający lub pojedynczą agencję udostępniającą usługę rejestracji dokumentów) i umożliwiającą integrację usługi z systemami informatycznymi agencji. Dwa obszary podstawowej architektury usługi rejestracji dokumentów przedstawiono na ilustracji 20. Ilustracja 20. Podstawowa architektura usługi rejestracji dokumentów Interfejs publiczny Publiczny interfejs usługi rejestracji dokumentów wyznacza sposób interakcji konsumentów z tą usługą, określa obsługiwane operacje, protokoły i formaty komunikatów oraz inne nakładane przez usługę na konsumenta niefunkcjonalne wymagania, takie jak wymagany poziom szyfrowania i podpisywania zawartości. Określa sposób, w jaki usługa ta jest widoczna dla konsumenta. Zewnętrzny konsument usługi, którym może byd portal, aplikacja niezależnego producenta, inna usługa lub partner, komunikuje się z usługą rejestracji dokumentów za pośrednictwem interfejsu publicznego. Dostawca usługi udostępnia interfejs, który umożliwia konsumentom przedkładanie dokumentów zarówno w sposób synchroniczny, jak i asynchroniczny. Interfejs obsługuje także operacje pomocnicze, takie jak sprawdzenie stanu dokumentu, a w przypadku komunikacji asynchronicznej pobranie i usunięcie odpowiedzi itp. Ogólną strukturę publicznego interfejsu usługi rejestracji dokumentów przedstawiono na ilustracji 21. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 77

78 Ilustracja 21. Wysokopoziomowe usługi świadczone przez interfejs publiczny usługi rejestracji dokumentów Komunikacja asynchroniczna Usługa rejestracji, aby zapewnid wsparcie dla jak największej liczby aplikacji klienckich, implementuje podstawowe mechanizmy komunikacyjne (synchroniczne i asynchroniczne). Gdy konsument korzysta z interfejsu synchronicznego, usługa musi przyjąd dokument, przetworzyd go i zwrócid odpowiedź w ramach tego samego połączenia. Oznacza to dłuższe blokowanie zasobów niż w przypadku połączeo asynchronicznych oraz ograniczenie skalowalności usługi. Preferowanym interfejsem, wykorzystywanym do przedkładania dokumentów, jest interfejs asynchroniczny, który zapewnia lepszą skalowalnośd konsument nie jest blokowany w oczekiwaniu na odpowiedź. Co więcej, technologia zastosowana do implementacji usługi rejestracji dokumentów nie musi gwarantowad przetworzenia dokumentu i zwrócenia odpowiedzi w najkrótszym możliwym czasie. Konsument podaje usłudze adres, na który ta ma przekazad swoją odpowiedź po przetworzeniu tego dokumentu, niezależnie od sesji, w której zostało przekazane żądanie. Jeśli konsument nie może podad takiego adresu, może co jakiś sprawdzad, czy odpowiedź jest już gotowa i czy można ją pobrad (tzw. polling). Z tego względu niezbędne jest, by usługa przechowywała informacje o stanie wszystkich odpowiedzi otrzymanych asynchronicznie z usług agencji, usług pomocniczych czy równorzędnych usług rejestracji dokumentów. Rodzi się także pytanie po jakim okresie można usunąd odpowiedzi nieodebrane przez konsumentów? Najprostszym wyjściem jest wprowadzenie w usłudze rejestracji dokumentów funkcji oczyszczania konsument po zakooczeniu przetwarzania odpowiedzi może uprzątnąd (zwolnid) zajmowane zasoby. Poza tym usługa rejestracji dokumentów może sama zwalniad zasoby po odebraniu odpowiedzi przez konsumenta, a w przypadku odpowiedzi nieodebranych po ustalonym okresie zwłoki. W istocie jest to implementacja mechanizmu Garbage Collector dla komunikatów odpowiedzi. Komunikacja synchroniczna W niektórych przypadkach klient może nie mied możliwości obsłużenia asynchronicznego mechanizmu komunikacji, wymagającego podania adresu dla komunikatów z odpowiedzią. W takiej sytuacji klient może albo asynchronicznie sprawdzad co jakiś czas stan przetwarzania (polling), albo z innych względów odwoład się do usługi rejestracji dokumentów w sposób synchroniczny na przykład gdy musi natychmiast przekazad odpowiedź użytkownikowi koocowemu. Protokoły takie jak HTTP są protokołami żądania-odpowiedzi: przeglądarka internetowa wysyła żądanie do serwera, serwer generuje stronę HTML i w tym samym połączeniu zwraca ją do przeglądarki. W przypadku protokołu synchronicznego, odpowiedź jest faktyczną odpowiedzią RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 78

79 biznesową usługi, natomiast w przypadku komunikacji asynchronicznej może to byd jednie techniczne potwierdzenie przyjęcia żądania. Ze względu na to, że odpowiedź dla konsumenta zależy od odpowiedzi uzyskanych z innych usług (np. usług innych agencji lub usług pomocniczych), realizacja synchronicznego schematu komunikacji na poziomie usługi rejestracji dokumentów (a nie na poziomie usługi agencji) może byd niezwykle trudna. Możliwośd wygenerowania odpowiedzi w trybie synchronicznym w całości zależy od tego, czy wszystkie pozostałe usługi biorące udział w procesie obsługują komunikację synchroniczną. Oznacza to, że w czasie projektowania aplikacji konsumenta należy sprawdzid, czy wykorzystywane usługi agencyjne i usługi pomocnicze obsługują interfejsy synchroniczne i asynchroniczne. Preferowanym sposobem komunikacji jest komunikacja asynchroniczna, jednak przez to interfejs publiczny musząc obsługiwad sprawdzanie stanu żądania i operacje oczyszczania rejestru stanu żądao staje się bardziej skomplikowany. Natomiast stosowanie wyłącznie synchronicznej metody komunikacji (o ile wykorzystywane usługi agencyjne na to pozwalają) może spowodowad dodatkowe problemy ze skalowalnością, które nie wystąpiłyby w przypadku rejestracji dokumentów z użyciem metody asynchronicznej. Warto zatem stosowad metodę synchroniczną tylko wtedy, gdy jest to konieczne na przykład w usłudze obsługi płatności, która weryfikuje dane na temat karty kredytowej i generuje odpowiedź w trybie natychmiastowym. Stosowanie standardów pozwala uzyskad lepszą interoperacyjnośd Poza funkcjonalnością usługi dostawca udostępnia także informacje niezbędne konsumentowi usługi do zrozumienia jej interfejsu, sposobu działania i komunikatów generowanych w czasie pracy. Dostawca usługi podaje także wszelkie wymagania tej usługi w zakresie stosowanych protokołów, formatów kodowania danych, bezpieczeostwa, poufności i integralności danych. Wymagania mogą byd opisywane z wykorzystaniem różnych specyfikacji. WS-Policy służy do opisu wymagao i funkcji usług Web Service, WSDL pozwala opisad sposób wywoływania usługi, XML Schema (XSD) pozwala definiowad format komunikatów, SOAP zapewnia podstawowy protokół transportu żądao i odpowiedzi, a XML stanowi podstawowy format zapisu żądao i odpowiedzi usług Web Service. Łącza do szczegółowych informacji na temat wymienionych specyfikacji znajdują się w sekcji Odsyłacze, listy kontrolne i dalsze informacje na koocu tego dokumentu. Zwykle protokół HTTP uznawany jest za protokół wyższego poziomu (w stosie protokołów sieciowych znajduje się on wyżej niż na przykład protokół TCP), który może służyd do przesyłania żądao SOAP podczas wywoływania usług Web Service. W rzeczywistości jednak do tego celu równie dobrze nadaje się dowolny protokół sieciowy, taki jak TCP czy UDP. Tak długo, jak długo działa odbiornik przyjmujący i przetwarzający żądania SOAP, protokół sieciowy stosowany do przesyłania tych komunikatów praktycznie nie ma znaczenia. Protokół HTTP ze względu na to, że jest powszechnie wykorzystywany do komunikacji między przeglądarkami i serwerami internetowymi jest po prostu najwygodniejszym protokołem do celów transmisji żądao SOAP. Dzięki wykorzystaniu serwera internetowego, który przyjmuje pakiety HTTP i HTTPS na portach odpowiednio 80 i 443 protokołu TCP, nie ma potrzeby rozbudowy i rekonfiguracji istniejącej infrastruktury sieciowej (zapory firewall, routery itp.) do obsługi nowego rodzaju ruchu. Wywoływanie usług Web Service za pomocą protokołu SOAP w sposób naturalny wpasowuje się w istniejące środowisko. Projektując usługę rejestracji dokumentów, poza wyborem odpowiedniego protokołu należy także zwrócid uwagę na następujące zagadnienia: - Podstawowa interoperacyjnośd. Ze względu na to, że w systemach administracji publicznej wykorzystywane są bardzo różne platformy i technologie, nowo wdrażane usługi Web Service muszą charakteryzowad się interoperacyjnością niezależnie od tego, w jakiej technologii zostały utworzone. Specyfikacja WS-I Basic Profile (na koocowym etapie prac, dostępna pod adresem stanowi podstawy interoperacyjności usług Web Service, definiując zestaw standardów, na których oparte powinny byd wszystkie implementacje usług Web Service. Specyfikacja ta precyzuje minimalny zestaw wymagao dla usług Web Service, których spełnienie gwarantuje interoperacyjnośd pomiędzy usługami działającymi na różnych platformach. Wymagane RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 79

80 standardy to SOAP 1.1 (mimo że status rekomendacji W3C uzyskała już wersja 1.2 tego protokołu), XML 1.0 i HTTP 1.1 jako sposoby zapisu i przesyłania komunikatów, WSDL 1.1 i XML Schema 1.0 do opisu usług, UDDI v2 do publikowania i wyszukiwania usług oraz HTTPS (HTTP over TLS and SSL), X.509 Public Key Infrastructure Certificate i CRL Profile jako standardy zapewniające bezpieczeostwo. - Bezpieczeostwo komunikatów. Po ustaleniu podstawowych specyfikacji, następnym krokiem jest zapewnienie bezpieczeostwa przesyłanych komunikatów. Zabezpieczanie komunikatów ma istotną przewagę nad zabezpieczaniem kanałów transmisji ma znacznie szerszy zakres działania. Innymi słowy, zastosowanie mechanizmów zabezpieczeo na poziomie warstwy transportowej jest nieistotne, ponieważ zabezpieczenia dotyczą bezpośrednio samego komunikatu. Zastosowanie specyfikacji WS-I Basic Security Profile (obecny status Working Group Draft, dokument dostępny pod adresem do zapewnienia bezpieczeostwa na poziomie komunikatu gwarantuje interoperacyjnośd w zakresie zabezpieczeo pomiędzy wszystkimi stronami interakcji, które wiedzą, w jaki sposób komunikat jest zabezpieczony. Specyfikacja definiuje akceptowalne mechanizmy zabezpieczania komunikacji z usługami Web Service. Uwzględniono zabezpieczenia warstwy transportowej (SSL i TLS) oraz zabezpieczanie komunikatów SOAP zgodnie ze specyfikacją WS-Security ( oraz określono wspierane typy tokenów bezpieczeostwa. Istnieją także dodatkowe specyfikacje, definiujące inne typy tokenów na przykład REL (Rights Expression Language) czy SAML (Security Assertion Markup Language). Pozostałych aspektów bezpieczeostwa komunikatów dotyczą inne specyfikacje z rodziny WS-*, na przykład WS-Trust dotyczy wystawiania tokenów bezpieczeostwa, WS-SecureConversation określa sposoby generowania kluczy sesji, używanych do zabezpieczania komunikacji na poziomie sesji, a WS-SecurityPolicy uzupełnia specyfikację WS-Security o możliwośd definiowania wymagao w zakresie bezpieczeostwa komunikatów typów obsługiwanych tokenów, algorytmów szyfrowania itp. - Wymagania usług. Z poszczególnymi usługami mogą byd związane wymagania dotyczące konsumentów korzystających z tych usług. Wymagania te mogą precyzowad typy obsługiwanych tokenów bezpieczeostwa czy algorytmów podpisywania komunikatów. Informacje o wymaganiach powinny byd udostępniane w jednym, standardowym dla wszystkich usług formacie. Format taki został zdefiniowany w specyfikacji WS-Policy. Specyfikacja ta pozwala na określanie wymagao i możliwości usług poprzez tworzenie odpowiednich zasad, pobieranych przez programistów podczas tworzenia aplikacji. Ponieważ w specyfikacji nie określono sposobu pobierania zasad czy też dołączania ich do usług Web Service, konieczne jest oparcie się na innych specyfikacjach, charakterystycznych dla wykorzystywanych technologii. Taką specyfikacją jest WS-PolicyAttachment, która określa mechanizmy wiązania zasad z usługami Web Service. - Adresowanie usług Web Service. Aby móc rozpocząd korzystanie z usługi Web Service, niezbędne jest poznanie stosowanego przez tę usługę protokołu wymiany komunikatów oraz adresu, pod który komunikaty te należy wysyład. Stosowanie specyfikacji WS-Addressing (posiadającej obecnie status Working Draft; specyfikacja znajduje się pod adresem do przesyłania komunikatów w sieci w sposób niezależny od warstwy transportowej gwarantuje, że każda ze stron kontraktu będzie rozumiała sposoby adresowania komunikatów stosowane przez drugą stronę i znała adres, pod który ma wysyład komunikaty. Specyfikacja określa standardowe sposoby adresowania punktów koocowych usług Web Service za pomocą referencji punktu koocowego oraz przekazywania w nagłówkach informacyjnych komunikatu informacji na temat routingu komunikatu oraz sposobu wywołania usługi. Dzięki temu w nagłówkach komunikatu SOAP w standardowy sposób można definiowad przepływy zarówno synchroniczne, jak i asynchroniczne. Metoda ta jest całkowicie niezależna od warstwy transportowej, w przeciwieostwie do metod polegających na zawarciu opisu wywołania w nagłówkach warstwy transportowej. Przykładem może byd stosowanie nagłówka SOAP-ACTION w protokole HTTP do opisu operacji SOAP na poziomie warstwy transportowej, jak ma to dziś miejsce w większości usług Web Services. Przeniesienie tej informacji do nagłówka SOAP, dzięki czemu stanie się ona częścią komunikatu SOAP, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 80

81 pozwala zagwarantowad pomyślne przesłanie komunikatu SOAP z wykorzystaniem dowolnego protokołu sieciowego i wykonanie właściwej operacji we właściwej usłudze. - Niezawodne dostarczanie. W każdej rozproszonej architekturze opartej na wymianie komunikatów, niektóre komunikaty z pewnością uznawane są za krytyczne i ich poprawne dostarczenie jest wymaganiem stawianym całemu systemowi. Stosowanie specyfikacji WS-ReliableMessaging ( pozwala na transmisję komunikatów z gwarancją dostarczenia. Przed przesłaniem komunikatu, nadawca i odbiorca wymieniają serię pakietów powitalnych (handshake), co gwarantuje niezawodnośd transmisji. Co więcej, specyfikacja WS-RealiableMessaging definiuje także mechanizmy zachowania kolejności komunikatów wywoływana usługa otrzymuje komunikaty w takiej kolejności, w jakiej zostały wysłane. - Obsługa transakcji. Czasami zachodzi koniecznośd, by wywołanie usługi Web Service było elementem transakcji wchodzącej w skład większej operacji. Zakres transakcji może byd bardzo różny od prostych transakcji bazodanowych (będących zwykle transakcjami zgodnymi z warunkami ACID) po długoterminowe transakcje biznesowe, których czas realizacji liczony jest w dniach, tygodniach i miesiącach, a nie w sekundach. Specyfikacje WS-Coordination, WS-AtomicTransaction oraz WS-BusinessActivity zapewniają wsparcie dla transakcji, definiując sposób reprezentacji transakcji w komunikacie SOAP i pozwalając odbiorcy komunikatu na uczestnictwo w transakcji związanej z tym komunikatem. - Załączniki komunikatów. Stosowanie załączników jest dośd powszechne, szczególnie w przypadku poczty elektronicznej. Może zaistnied potrzeba dołączenia do komunikatu jakiegoś materiału w celu przesłania go do usługi oddziałowej. W takim wypadku protokół stosowany do komunikacji z usługą Web Service musi pozwalad na osadzanie załączników. Zarówno specyfikacja SOAP Message Transmission Optimization Method (MTOM) jak i XML-binary Optimized Packaging (XOP) pozwalają na osadzenie danych binarnych w kodzie XML w postaci wiadomości zakodowanej w MIME i dołączenie takiej treści do komunikatu SOAP. - Metadane usług Web Service. Wraz z upowszechnieniem się usług Web Service nadejdzie koniecznośd udostępnienia standardowego mechanizmu pobierania metadanych, dzięki któremu konsumenci w czasie projektowania aplikacji będą mogli pobrad metadane związane z usługą Web Service w sposób niezależny od wykorzystywanej warstwy transportowej. Dzięki temu konsument będzie mógł poznad wymagania i możliwości usługi Web Service. Metadane obejmują informacje takie jak zasady (WS-Policy), kontrakt (WSDL) i schemat (XSD). Taki standardowy mechanizm pobierania metadanych związanych z usługą został zdefiniowany w specyfikacji WS-MetadataExchange. W skrócie dla konsumenta widoczny jest interfejs publiczny i tylko z tym interfejsem może on współpracowad. Aby zagwarantowad, że tworzone usługi będą mogły współpracowad z systemami działającymi na różnych platformach i korzystającymi z różnych technologii, usługi te nie mogą byd oparte na zamkniętych i zastrzeżonych standardach i specyfikacjach opracowanych specjalnie na potrzeby danego rozwiązania. Efektywne wdrożenie elektronicznych usług administracji publicznej wymaga utworzenia zestandaryzowanej publicznej infostrady, dostępnej i zrozumiałej dla wszystkich elementów systemu. Implementacja prywatna Zadaniem interfejsu publicznego usługi rejestracji dokumentów jest zapewnienie standardowego sposobu interakcji z konsumentami. Natomiast zadaniem implementacji prywatnej jest faktyczne przetwarzanie dokumentów, zapewnienie integracji z usługami agencji i usługami pomocniczymi, generowanie odpowiedzi oraz zagwarantowanie, że usługa będzie dostarczała innym usługom prawidłowe informacje. Usługa rejestracji dokumentów pełni wiele różnych funkcji wymagających odpowiedniej implementacji. Niektóre z nich to: - odbieranie i przetwarzanie żądao, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 81

82 - zwracanie odpowiedzi synchronicznie lub asynchronicznie, w zależności od wymagao agencji lub usługi pomocniczej, - zapisywanie żądao, których dostarczenie do docelowej agencji lub usługi pomocniczej jest w danej chwili niemożliwe, - zapisywanie odpowiedzi, które nie mogą byd dostarczone w sposób asynchroniczny, lub gdy konsument sam cyklicznie sprawdza dostępnośd odpowiedzi (polling), - autoryzacja żądao, - sprawdzanie dostępności odpowiedzi (polling), - oczyszczanie rejestru odpowiedzi, - inspekcja żądao, odpowiedzi oraz operacje związane z bezpieczeostwem na przykład autoryzacja, - zapewnienie instrumentacji w postaci informacji o błędach, ostrzeżeo, podstawowych informacji operacyjnych, liczników wydajności umożliwiających sprawdzenie stanu usługi oraz możliwości włączania i wyłączania dodatkowych funkcji monitorowania, ułatwiających diagnozowanie ewentualnych problemów, - integracja z usługami agencji i usługami pomocniczymi, - przekazywanie dokumentów do usług agencji, usług pomocniczych lub równorzędnych usług rejestracji, - wsparcie protokołów aplikacyjnych wyższego poziomu poprzez orkiestrację procesów biznesowych. Funkcje te omówiono bliżej w tej i w następnych sekcjach dokumentu. Na ilustracji 22. przedstawiono zarys implementacji usługi rejestracji dokumentów. Ilustracja 22. Usługi wysokiego poziomu świadczone przez prywatną implementację usługi rejestracji dokumentów RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 82

83 Format komunikatów Komunikaty przesyłane są w formacie XML, który de facto stał się standardem komunikacji pomiędzy aplikacjami (konsumentami usług) a usługami Web Service (dostawcami usług). XML pozwala na zdefiniowanie struktury, która nadaje znaczenie suchym danym. Uwaga nadzór nad specyfikacją XML utrzymuje organizacja World Wide Web Consortium (W3C). Obecnie obowiązującą wersją specyfikacji jest wersja 1.1, specyfikacja ta posiada status rekomendacji W3C. Witryna organizacji W3C znajduje się pod adresem a specyfikację XML można znaleźd pod adresem Swoją popularnośd standard XML zawdzięcza głównie łatwości użycia oraz faktowi, że jest on oparty na tekście, dzięki czemu komunikaty oparte na XML mogą byd odczytywane nawet przez najprostsze systemy. Funkcje obsługi XML są powszechnie dostępne w wielu systemach operacyjnych, XML jest też obsługiwany przez bazy danych jako natywny typ danych. W związku z powyższym, stosowanie XML jako podstawowej struktury komunikatu w strukturze mającej zapewnid interoperacyjnośd pomiędzy różnymi systemami i aplikacjami w heterogenicznym środowisku administracji publicznej wydaje się byd rozwiązaniem jak najbardziej właściwym. Koperty, nagłówki i zawartości komunikatów Zastosowanie kopertowego formatu komunikatów pozwala na przechowywanie metadanych komunikatu wraz z treścią tego komunikatu. Format obejmuje nagłówek zawierający metadane oraz ciało komunikatu zawierające jego treśd. Przykładem wykorzystywanego obecnie formatu kopertowego jest SOAP protokół oparty XML (i wykorzystywany przez wielu producentów oprogramowania opartego na Web Services), służący do komunikacji pomiędzy aplikacjami i pozwalający na uzupełnienie żądao i odpowiedzi odpowiednimi metadanymi. Usługa rejestracji stosuje format SOAP do przesyłania żądao i odpowiedzi do innych usług. Ponieważ protokół SOAP powinien byd obsługiwany praktycznie przez wszystkie usługi administracji publicznej niezależnie od platformy sprzętowej i systemu operacyjnego zastosowanie tego protokołu w usłudze rejestracji komunikatów zapewnia wysoką interoperacyjnośd. Uwaga nadzór nas specyfikacją SOAP sprawuje organizacja W3C. Wersja 1.2 specyfikacji, posiadająca status rekomendacji W3C, dostępna jest pod adresem Na ilustracji 23. przedstawiono przykładową strukturę dokumentu o formacie kopertowym. Koperta to struktura zawierająca w sobie zarówno nagłówek, jak i treśd dokumentu. Ilustracja 23. Przykład dokumentu o formacie kopertowym Format ten pozwala także na zagnieżdżanie dokumentów. Zaawansowany format koperty, wykorzystywany w systemach administracji, może na przykład pozwalad na zagnieżdżenie treści dokumentu SOAP wewnątrz komunikatu SOAP. Pozwala to na budowanie wielopoziomowej RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 83

84 struktury metadanych komunikatu metadane związane z dokumentem (metadane biznesowe) mogą byd oddzielone od metadanych związanych z komunikatem SOAP (metadane techniczne, dotyczące raczej kwestii bezpieczeostwa i wiarygodności). Uwaga przykładem kopertowego formatu wykorzystywanego w administracji publicznej w Wielkiej Brytanii jest schemat GovTalk, wchodzący w skład biblioteki schematów dostępnej pod adresem Na ilustracji 24. przedstawiono zagnieżdżony komunikat o formacie kopertowym treśd komunikatu pierwszego poziomu zawiera inną kopertę. Zagnieżdżanie może byd wielopoziomowe w razie potrzeby zagnieżdżone koperty mogą zawierad kolejne koperty. Ilustracja 24. Przykład dokumentu zawierającego zagnieżdżoną kopertę Załączniki komunikatów Czasami konieczne jest dołączenie do dokumentu jakichś dodatkowych informacji. Mogą to byd na przykład fotografie, kopia prawa jazdy, zeskanowany tradycyjny, papierowy list czy inne materiały cyfrowe. Osadzanie załączników w dokumentach XML jest już od jakiegoś czasu możliwe technicznie dzięki różnym mechanizmom i różnym specyfikacjom, takim jak SOAP with Attachments. Najnowsza specyfikacja, która zastępuje wszystkie poprzednie, jest oparta na dwóch specyfikacjach organizacji W3C: XML-binary Optimized Packaging (XOP) i SOAP Message Transmission Optimization Mechanism (MTOM). Uwaga specyfikacja XOP znajduje się pod adresem a specyfikacja MTOM pod adresem XOP pozwala na pakowanie danych binarnych w wiadomośd sformatowaną zgodnie z MIME za pomocą kodowania Base64. Schemat dokumentu definiuje dane Base64 jako typ danych xs:base64binary wspieraną leksykalną formę kanoniczną ujętą w specyfikacji XML InfoSet (abstrakcyjny model danych dla serializowanych dokumentów XML). Uwaga znaki Base64 muszą byd zapisane w postaci kanonicznej bez dodatkowych znaków niedrukowanych na początku, wewnątrz lub na koocu zakodowanego dokumentu. Jeśli warunek ten nie zostanie dotrzymany, usługa Web Service, która odbierze komunikat, nie będzie mogła odkodowad zawartości pól Base64. Format binarny prawdopodobnie jest bardziej optymalny niż dokument zakodowany w Base64, który przed odczytaniem musi jeszcze zostad odkodowany. Dane zapisane binarnie powinny także mied mniejszą objętośd. Zamiast danych XML InfoSet, zakodowanych w Base64, element XOP zawiera łącze do zoptymalizowanej binarnej treści komunikatu MIME. Otrzymany w ten sposób RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 84

85 pakiet (po serializacji obiektu InfoSet) nazywany jest pakietem XOP. Zawiera on dokument XML (dokument XOP) oraz przetworzoną treśd komunikatu w postaci pakietu MIME Multipart/Related. MTOM to specyfikacja precyzująca sposoby optymalizacji transmisji komunikatów SOAP (a w szczególności koperty). W zakresie implementacji optymalizacji specyfikacja ta oparta jest na specyfikacji XOP. Usługa Web Service w momencie otrzymania komunikatu SOAP powinna odtworzyd oryginalny komunikat poprzez odkodowanie zoptymalizowanej zawartości binarnej z powrotem do reprezentacji Base64, jednak procedura ta nie jest obowiązkowa. Bezpieczeostwo komunikatów Podstawowa komunikacja z usługami Web Service polega na wysyłaniu i odbieraniu komunikatów. Najczęściej stosowanym formatem komunikatów jest SOAP. Przesyłanie dokumentów jako treści komunikatów SOAP jest dośd problematyczne, ponieważ nie ma możliwości zabezpieczenia poszczególnych komunikatów. Specyfikacja SOAP nie obejmuje żadnych mechanizmów zabezpieczeo, a jedynie podstawową strukturę komunikatu SOAP (koperta, nagłówek i treśd). Brak odpowiednich standardów i specyfikacji we wczesnych stadiach rozwoju usług Web Service i w szczególności protokołu SOAP powodował, że do zapewnienia bezpieczeostwa komunikacji stosowano inne mechanizmy. Stosowane mechanizmy zależały od środowiska, w którym działało rozwiązanie. Najczęściej stosowano protokoły zapewniające bezpieczeostwo na poziomie transportowym SSL, TLS oraz IPSec. Taki poziom zabezpieczeo często nie jest jednak wystarczający. Dlaczego zabezpieczenie tylko warstwy transportowej może nie byd wystarczające? Zabezpieczenia wprowadzone w warstwie transportowej chronią poufnośd informacji jedynie podczas przesyłania ich pomiędzy nadawcą a odbiorcą. Poza kanałem komunikacyjnym komunikaty są niezabezpieczone, mają postad jawnego tekstu. W takim przypadku bezpieczeostwo komunikatu zależy od zapewnianych przez platformę mechanizmów zachowania poufności i integralności komunikatów. Z tego względu w momencie otrzymania komunikatu przez adresata nie można zagwarantowad, że integralnośd tego komunikatu nie została naruszona i nikt nie poznał jego treści. Co gorsza, jeśli komunikat przesyłany jest z wykorzystaniem jednego lub kilku węzłów pośrednich, podczas przechodzenia przez te węzły komunikat pozostaje niezabezpieczony. Nawet w granicach pojedynczego systemu, zabezpieczenia warstwy transportowej często zapewniane są przez specjalistyczny sprzęt i oprogramowanie (ze względu na wydajnośd i efektywnośd działania), zainstalowane na granicy systemu. Bezpieczne sesje kooczą się właśnie w tym miejscu. Nawet jeśli do celów nawiązania połączenia zastosowano odpowiedni mechanizm uwierzytelnienia wzajemnego, podczas przetwarzania komunikatu przez system informacje o nadawcy tego komunikatu mogą zostad utracone. Przyszłośd to zabezpieczenia na poziomie komunikatu Problemy związane z zapewnieniem bezpieczeostwa transmisji na poziomie transportowym można rozwiad, stosując zabezpieczenia na poziomie pojedynczych komunikatów. Istnieje kilka specyfikacji pozwalających na umieszczenie w nagłówku SOAP informacji dotyczących bezpieczeostwa komunikatu. Najlepszą z tych specyfikacji jest WS-Security. Specyfikacja WS-Security zawiera definicje zestawu pól nagłówkowych SOAP, umożliwiających zachowanie poufności i integralności komunikatów w trakcie przesyłania ich pomiędzy nadawcą a odbiorcą niezależnie od rodzajów sieci, przez jakie są przesyłane, liczby węzłów pośrednich czy typów systemów wykorzystywanych do składowania komunikatów przed wysłaniem ich w dalszą drogę. Uwaga pieczę nad standardem WS-Security piastuje organizacja OASIS, patrz strona RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 85

86 Poufnośd Poufnośd danych chroniona jest za pomocą mechanizmów szyfrowania jawna treśd komunikatu zostaje z użyciem standardowego algorytmu szyfrowania (takiego jak potrójny DES, AES czy RSA) zamieniona na niemożliwe do odcyfrowania dane binarne. Rozróżnia się dwie metody szyfrowania symetryczną i asymetryczną. Obie oparte są na zaawansowanych algorytmach matematycznych, a do zaszyfrowania i odszyfrowania danych niezbędne jest posiadania odpowiedniego klucza szyfrującego. W przypadku szyfrowania symetrycznego zarówno nadawca, jak i odbiorca komunikatu dysponują tym samym kluczem szyfrującym (zwanym też wspólnym sekretem). Do stosowania szyfrowania symetrycznego niezbędne jest istnienie jakiegoś mechanizmu wymiany kluczy szyfrujących, gwarantującego, że obie strony przed rozpoczęciem zabezpieczonej transmisji dysponują identycznymi kluczami szyfrującymi. W przypadku szyfrowania asymetrycznego każda strona posiada dwa klucze prywatny i publiczny. Klucz publiczny służy do szyfrowania wiadomości nadawanych i odbieranych od jego właściciela; właściciel może udostępnid ten klucz wszystkim osobom, z którymi chce się komunikowad. Klucz prywatny (pozostający w wyłącznej dyspozycji jego właściciela) służy do odszyfrowywania komunikatów. Treśd zaszyfrowana z użyciem klucza publicznego może zostad odszyfrowana wyłącznie za pomocą klucza prywatnego, a treśd zaszyfrowana z użyciem klucza prywatnego może zostad odszyfrowana wyłącznie za pomocą klucza publicznego. Tak długo, jak długo właściciel klucza prywatnego potrafi uchronid go przed niepowołanym dostępem, szyfrowanie asymetryczne jest wygodną i pewną metodą ochrony poufności komunikatów klucz publiczny można udostępniad dowolnym osobom. Skoro dystrybucja kluczy w przypadku szyfrowania asymetrycznego jest tak łatwa, dlaczego ta metoda szyfrowania nie jest oczywistym wyborem za każdym razem, gdy trzeba zaszyfrowad jakieś dane? Jest tak, ponieważ algorytm matematyczny oraz rozmiar stosowanych kluczy (minimalny rozmiar zapewniający ochronę przed atakami metodą przeglądu zupełnego) sprawiają, że stosowanie tej metody wymaga większej mocy obliczeniowej niż w przypadku szyfrowania symetrycznego. Dlatego tam, gdzie jest to możliwe, należy stosowad szyfrowanie symetryczne, na przykład podczas wymiany komunikatów pomiędzy usługami Web Services. Szyfrowanie asymetryczne jest przydatne na etapie negocjacji współdzielonego sekretu albo klucza sesji, który zostanie użyty do symetrycznego szyfrowania transmisji. Przykładem protokołu opartego na takim mechanizmie jest HTTPS HTTP over Secure Sockets Layer (SSL). Zastosowanie standardu WS-Security pozwala na wprowadzenie szyfrowania na dowolnym poziomie. Można szyfrowad całą treśd komunikatu albo jedynie jej części. Można zaszyfrowad nawet pola nagłówków komunikatu. W zakresie opisu konwencji stosowanych do szyfrowania poszczególnych części komunikatu SOAP, standard WS-Security opiera się na specyfikacji XML Encryption. Integralnośd Nawet jeśli treśd komunikatu nie jest poufna i tajna i nie wymaga szyfrowania, często występuje koniecznośd zagwarantowania, że podczas transmisji komunikatu nie doszło do żadnej manipulacji i integralnośd komunikatu nie została naruszona. Mechanizm taki jest szczególnie przydatny w przypadku transmisji listu lub formularza aplikacyjnego możliwa jest wtedy weryfikacja tożsamości nadawcy dokumentu. Mechanizm ten nazywany jest podpisaniem dokumentu, jego wynikiem jest dołączenie do dokumentu podpisu elektronicznego. Uwaga więcej informacji na temat technik i funkcji podpisu elektronicznego można znaleźd w temacie Podpisy elektroniczne i certyfikaty w sekcji Elementy składowe typowego rozwiązania integracyjnego dla sektora publicznego w tym przewodniku. Podpisanie dokumentu wiąże z użyciem algorytmu funkcji skrótu (na przykład SHA-1) do obliczenia małej (i o stałym rozmiarze) wartości binarnej nazywanej wartością hasz lub skrótem RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 86

87 dokumentu. Wartości skrótu są unikalne; wartości dwóch nawet niewiele różniących się od siebie dokumentów także są różne od siebie. Wartośd skrótu dokumentu zaszyfrowana prywatnym kluczem nadawcy stanowi podpis elektroniczny tego dokumentu. Odbiorca dokumentu może odszyfrowad podpis za pomocą klucza publicznego nadawcy, ponownie obliczyd wartośd skrótu dokumentu za pomocą tego samego algorytmu funkcji skrótu i porównad wartośd odszyfrowaną z wartością obliczoną. Jeśli wartości te różnią się od siebie, treśd dokumentu uległa zmianie i komunikat powinien zostad odrzucony. Jeśli wartości są identyczne, adresat ma gwarancję, że komunikat dotarł do niego w stanie nienaruszonym. W przypadku obliczania wartości skrótu dokumentu XML występuje dodatkowy problem dwa dokumenty XML mogą byd identyczne syntaktycznie, ale różnid się ze względu na dodatkowe znaki niedrukowane (odstępy, znaki kooca linii itp.). Znaki te mają jedynie wpływ na formatowanie znaczników XML, ale nie zmieniają treści dokumentu. Zatem przed obliczeniem wartości skrótu dokumentu zachodzi koniecznośd doprowadzenia go do postaci kanonicznej za pomocą odpowiedniego algorytmu usuwającego niedrukowane znaki zgodnie ze ustalonymi zasadami. Uwaga organizacja W3C opracowała specyfikację o nazwie Canonical XML (czasem oznaczaną także symbolem C14N jako skrót słowa canonicalization), która precyzuje reguły transformowania dokumentów XML do postaci kanonicznej w celu obliczenia wartości skrótu dla podpisu cyfrowego. Specyfikacja w wersji 1.0 ma status rekomendacji W3C i dostępna jest pod adresem Standard WS-Security pozwala na cyfrowe podpisywanie różnych części komunikatu SOAP tak samo, jak ma to miejsce w przypadku szyfrowania. W zakresie tworzenia podpisów cyfrowych i dołączania ich do komunikatów SOAP, standard WS-Security opiera się na specyfikacji XML Signature. Uwaga specyfikacja XML Signature ma status rekomendacji W3C i jest dostępna pod adresem Autoryzacja Usługa rejestracji dokumentów powinna poprawnie obsługiwad przesłane w nagłówkach komunikatów SOAP tokeny zabezpieczeo, pozwalające adresatowi zidentyfikowad nadawcę dokumentu. Nadawca przed wysłaniem dokumentu powinien uwierzytelnid się w swojej domenie zaufania, dzięki czemu pod warunkiem, że pomiędzy domeną, która wystawiła token, a domeną, w której znajduje się usługa rejestracji dokumentów, istnieje relacja zaufania usługa zaakceptuje uwierzytelnienie nadawcy. Możliwośd manipulowania zawartością tokenu jest wykluczona przez podpis cyfrowy tokenu. Istnieje także możliwośd sprawdzenia integralności komunikatu. Po zweryfikowaniu tokena bezpieczeostwa, usługa rejestracji dokumentów musi sprawdzid, czy nadawca posiada autoryzację do przesłania dokumentu do usługi agencji lub usługi pomocniczej. Może to zrobid poprzez sprawdzenie rejestracji nadawcy w tych usługach. Poza tym sprawdzany jest także poziom uwierzytelnienia nadawcy w jego lokalnej domenie zaufania w odniesieniu do minimalnego poziomu akceptowanego przez usługę agencji lub usługę pomocniczą. Dowolna negatywna odpowiedź usługi uwierzytelniania powoduje, że usługa rejestracji dokumentów zwraca komunikat błędu SOAP z informacją, że nadawca nie jest autoryzowany do przesłania dokumentu do tej usługi. Walidacja komunikatu Po zweryfikowaniu nadawcy i autoryzowaniu go do przesłania dokumentu i komunikatu oraz po sprawdzeniu nagłówków komunikatu może byd konieczne zwalidowanie treści komunikatu. Walidacja treści pozwala przed dostarczeniem dokumentu do docelowej usługi agencji lub usługi pomocniczej upewnid się, że struktura i zawartośd dokumentu mają właściwą postad. Można RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 87

88 także przeprowadzid walidację dokumentów, które mają zostad przekazane do równorzędnej usługi rejestracji dokumentów. Podejście to można stosowad na przykład wtedy, gdy usługa równorzędna nie ma wystarczających zasobów do przeprowadzenia takiej walidacji. Jeśli walidacja dokumentu nie powiedzie się, usługa rejestracji dokumentów powinna zwrócid komunikat błędu SOAP. Zaletą wykonywania podstawowej walidacji przez usługę rejestracji dokumentów jest fakt, że usługi docelowe otrzymują wyłącznie dokumenty zgodne z ustalonym schematem. Zwykle do walidacji wykorzystywany jest schemat zdefiniowany za pomocą XML Schema (XSD). XSD pozwala na ścisłe zdefiniowanie struktury dokumentu XML, włącznie z ograniczeniem liczby powtórzeo poszczególnych elementów, obowiązkiem istnienia pewnych elementów itd. XSD pozwala także na sprawdzanie typów danych poszczególnych elementów i atrybutów, a także sprawdzanie, czy użyte wartości danych należą do dozwolonych zakresów wartości (lub zbiorów wartości typów wyliczeniowych) oraz na porównywanie danych ze złożonymi wzorcami. Magazyn komunikatów Usługa rejestracji dokumentów powinna zwrócid nadawcy informację o poprawnym przyjęciu komunikatu i zagwarantowad, że przesłany komunikat nie zostanie zagubiony lub zignorowany. Aby dotrzymad tych warunków, kopia dokumentu na czas jego przetwarzania zostaje zapisana w tymczasowym magazynie danych. Jeśli usługa rejestracji dokumentów nie będzie mogła dostarczyd dokumentu do usługi agencji, usługi pomocniczej lub równorzędnej usługi rejestracji dokumentów, komunikat będzie przechowywany tak długo, aż jego dostarczenie będzie możliwe. Usługa rejestracji dokumentów może na przykład okresowo ponawiad próby dostarczenia dokumentu zgodnie z określonym algorytmem. Magazyn komunikatów jest także miejscem tymczasowego składowania odpowiedzi, które nie zostały jeszcze przekazane nadawcy dokumentu (w przypadku, gdy nadawca podał adres zwrotny) lub nie zostały jeszcze pobrane przez nadawcę komunikatu (w przypadku, gdy nadawca zdecydował się na okresowe sprawdzanie dostępności odpowiedzi polling). Magazyn komunikatów jest elementem krytycznym dla działania usługi rejestracji dokumentów, powinien byd więc odpowiednio zabezpieczony przed awariami sprzętu i oprogramowania oraz skutkami klęsk żywiołowych. Routing komunikatów Jednym z głównych zadao usług rejestracji jest przekazywanie dokumentów do ich odpowiednich odbiorców. Może się to wiązad z koniecznością przekazania dokumentu do: - stowarzyszonej usługi znajdującej się lokalnie, w agencji (w przypadku dokumentów przekazywanych przez usługę rejestracji dokumentów na poziomie domenowym), - stowarzyszonej usługi centralnej dla danej domeny (w przypadku dokumentów przekazywanych przez lokalną usługę rejestracji dokumentów), - stowarzyszonej usługi znajdującej się w innej domenie zaufania (w przypadku dokumentów przekazywanych przez usługi rejestracji dokumentów na poziomie lokalnym lub poziomie domeny), - centralnej usługi pomocniczej, - usługi agencyjnej. Na ilustracji 25. przedstawiono różne ścieżki przekazywania dokumentu. Kolory linii oznaczają: - linia czerwona fizyczna droga przekazania dokumentu pomiędzy stowarzyszonymi usługami, - przerywana linia czerwona logiczna droga przekazania dokumentu; faktyczna fizyczna droga dokumentu może prowadzid przez inne węzły, - linia niebieska droga przekazania komunikatu do usługi urzędu, - linia zielona droga przekazania komunikatu do usługi pomocniczej. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 88

89 Ilustracja 25. Drogi przekazywania dokumentów przez usługę rejestracji dokumentów Adresowanie usług Web Services Lokalizacja usługi Web Services ustalana jest w czasie działania aplikacji poprzez przeszukanie katalogu UDDI. Pozwala to utrzymad jedno z podstawowych założeo architektury zorientowanej na usługi przezroczystośd lokalizacji. Adres uzyskany w wyniku wyszukiwania odpowiada fizycznej lokalizacji usługi Web Service. Może on mied postad adresu URL protokołu HTTP jeśli komunikacja z usługą Web Service odbywa się za pośrednictwem protokołu HTTP, ale może to byd także inny typ adresu jeśli wykorzystywany jest inny protokół komunikacyjny, na przykład podstawowy TCP/IP. Komunikat SOAP z dokumentem biznesowym powinien zawierad nagłówki SOAP z adresem punktu koocowego, który ma otrzymad i przetworzyd dokument. Adresem tym często jest adres usługi rejestracji dokumentów, której zadaniem jest przekazanie komunikatu do docelowej usługi agencji lub usługi pomocniczej. Oprócz adresu punktu koocowego, komunikat może zawierad także zestaw właściwości opisujących docelową usługę agencji lub usługę pomocniczą, a także inne właściwości techniczne i specyficzne dla aplikacji, wymagane przez daną usługę agencji lub usługę pomocniczą. Dzięki tym właściwościom usługa rejestracji dokumentów, do której trafi komunikat, może przekazad komunikat dalej do właściwej usługi docelowej. Specyfikacja WS-Addressing umożliwia stosowanie zestandaryzowanego formatu adresów Web Service w nagłówkach komunikatów SOAP. Adresat komunikatu (adres punktu koocowego) jest określony przez element To, a operacja, która ma zostad wykonana przez usługę Web Service jest określana przez element Action. Element From identyfikuje nadawcę komunikatu, a element ReplyTo wskazuje adres, pod który należy skierowad odpowiedź. Natomiast element FaultTo wskazuje adres, pod który należy kierowad komunikaty informujące o błędach. Z każdym elementem adresu punktu koocowego mogą byd (opcjonalnie) związane właściwości referencji, reprezentowane przez element ReferenceProperties. Ścieżki komunikatów i węzły pośredniczące Istnieje możliwośd przesłania komunikatu do usługi rejestracji dokumentów, która działa jako serwer pośredniczący i nie jest usługą identyfikowaną przez element To nagłówka SOAP. W takim wypadku usługa rejestracji dokumentów przekaże komunikat dalej, używając reguł biznesowych RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 89

90 do wyznaczenia kolejnego węzła na podstawie zawartości adresu podanego w nagłówku To. Kolejny węzeł także nie musi byd węzłem koocowym komunikat SOAP przekazywany jest wyznaczaną dynamicznie ścieżką pomiędzy kolejnymi węzłami pośredniczącymi. O ile możliwe jest zdefiniowanie ścieżki przekazywania komunikatu SOAP w nagłówku tego komunikatu (starsze specyfikacje, takie jak WS-Routing proponowały nawet standardy definiowania takich ścieżek), nie zawsze jest to pożądane. Gdy ścieżka przekazywania komunikatu jest określona w jego nagłówku, wprowadzanie jakichkolwiek zmian jest praktycznie niemożliwe, chyba że węzeł pośredniczący ma możliwośd aktualizacji nagłówka. Węzeł musiałby albo usunąd swój wpis ze ścieżki albo ustawid flagę wskazującą, że komunikat został poddany przetwarzaniu. Z działaniem takim związany jest problem bezpieczeostwa. Aby uniknąd przesyłania komunikatów do podejrzanych węzłów, nagłówki adresowe tych komunikatów powinny byd chronione podpisem cyfrowym. Jeśli węzeł pośredniczący ma mied możliwośd uaktualnienia nagłówka, nagłówek ten nie może byd podpisany, a to z kolei mogłoby umożliwid atakującemu zmodyfikowanie nagłówków i umieszczenie w nich adresu podstawionego węzła. Jest więc oczywiste, że nagłówki muszą byd podpisywane cyfrowo, a zatem dynamiczne modyfikowanie ścieżki komunikatu przez węzły pośredniczące jest niemożliwe w nagłówku komunikatu musi byd ustalona stała ścieżka. Routing komunikatów do węzłów równorzędnych Dany węzeł może przekazad komunikat do innego, równorzędnego węzła do innej usługi rejestracji dokumentów istniejącej w tej samej lub w innej domenie zaufania. Przekazanie takie może byd spowodowane na przykład niedostępnością koocowego węzła, do którego ma trafid dany komunikat. Usługa docelowa, do której przekazany zostanie komunikat, ustalana jest poprzez odwzorowanie określonego w nagłówku adresu punktu docelowego na adres kolejnego węzła w łaocuchu albo adres węzła koocowego. Reguły odwzorowao zwykle utrzymywane są przez silnik reguł lub bufor routujący (podobnie jak w przypadku routera sieciowego). Reguły mogą byd modyfikowane przez administratorów w celu optymalizacji przekazywania komunikatów. Routing komunikatów w oparciu o metadane Czasami samo odwzorowanie adresu docelowego z nagłówka nie wystarcza do ustalenia dalszej drogi komunikatu potrzebne są dodatkowe właściwości. Właściwości te są związane z komunikatem, ale nie są uznawane za treśd tego komunikatu. Właściwościami tymi może byd protokół sieciowy wykorzystany do przesłania komunikatu (HTTP, TCP, UDP, IPX itp.), usługa agencji, która może przetwarzad dokumenty tego typu, nadawca komunikatu itd. Takie dodatkowe informacje mogą wesprzed proces podejmowania decyzji dotyczącej następnego węzła w ścieżce. Routing komunikatów w oparciu o treśd dokumentu Przekazywanie dokumentów w oparciu o treśd dokumentu (Content Based Routing CBR) jest rozwinięciem pomysłu przekazywania komunikatów w oparciu o metadane. Mechanizm ten zapewnia bardzo precyzyjną kontrolę nad regułami rządzącymi przekazywaniem komunikatów. Węzeł odpowiedzialny za podjęcie decyzji o dalszej drodze komunikatu musi z treści dokumentu pobrad właściwości, na podstawie których decyzja ta ma byd podjęta. Węzeł ten musi zatem znad format dokumentu i umied go odczytad. Niezawodne dostarczanie komunikatów Samo wysłanie komunikatu do usługi rejestracji dokumentów nie daje gwarancji, że komunikat ten zostanie dostarczony. Nadawca komunikatu nie ma żadnej możliwości dowiedzenia się, że adresat otrzymał ten komunikat lub że konieczne jest jego ponowne wysłanie. Co więcej, dostawca usługi może wymagad dostarczania komunikatów w kolejności takiej, w jakiej zostały wysłane. Podstawowy protokół SOAP nie zawiera żadnego mechanizmu wspierającego dostarczanie komunikatów w kolejności wysłania. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 90

91 Specyfikacja WS-ReliableMessaging 7 definiuje standardowy protokół niezawodnej transmisji komunikatów w określonej kolejności, odporny na awarie sieci i systemów. Pomimo że specyfikacja WS-ReliableMessaging została dopiero niedawno przekazana do OASIS, będzie podstawą nowej technologii komunikacyjnej Microsoft o nazwie Indigo. Komunikacja przebiega w następujący sposób: aplikacja wysyła komunikat do węzła docelowego. Węzeł docelowy potwierdza przyjęcie komunikatu, wysyłając komunikat zwrotny do aplikacji adresata. Ścieżka przekazywania komunikatów ustalana jest z wykorzystaniem różnych komunikatów określonych w standardzie WS-ReliableMessaging CreateSequence, LastMessage, SequenceAcknowledgement oraz TerminateSequence. Przyjrzyjmy się teraz przebiegowi komunikacji na poziomie protokołu. System źródłowy (source system) po otrzymaniu komunikatu od aplikacji-nadawcy wysyła do systemu docelowego (target system) komunikat CreateSequence. System docelowy generuje identyfikator sekwencji i wysyła do systemu źródłowego komunikat CreateSequenceResponse. Następnie system źródłowy wysyła jeden lub klika komunikatów opatrzonych numerami rosnącymi. Ostatni komunikat jest oznaczony tokenem LastMessage. System docelowy odpowiada komunikatem SequenceAcknowledgement, zawierającym numery otrzymanych komunikatów. System źródłowy sprawdza otrzymany komunikat, i jeśli niektóre komunikaty nie zostały dostarczone wysyła je ponownie z prośbą o potwierdzenie dostarczenia. Gdy system docelowy potwierdzi otrzymanie wszystkich komunikatów, system źródłowy wysyła komunikat TerminateSequence. Mechanizm wymiany komunikatów, opisany w specyfikacji WS-ReliableMessaging, przestawiono na ilustracji 26. Komunikat nr 2 nie został dostarczony, mechanizm komunikacji wykrywa brak i powoduje ponowne wysłanie komunikatu przez nadawcę. Ilustracja 26. Podstawowy protokół wymiany komunikatów niezbędny do niezawodnej komunikacji 7 specyfikacja protokołu WS-ReliableMessaging dostępna jest pod adresem RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 91

92 Obsługa transakcji Dostarczenie komunikatu może byd elementem działania o wyższym poziomie abstrakcji na przykład transakcji obejmującej wiele operacji. Transakcje mogą byd krótkoterminowe lub długoterminowe. Transakcje krótkoterminowe są podobne do transakcji znanych z systemów baz danych i mają charakter operacji niepodzielnych (atomowych). Wszystko albo nic albo wykonanie wszystkich operacji składowych transakcji powiedzie się, albo wszystkie zostaną wycofane. Co więcej, do czasu zatwierdzenia transakcji wyniki wszystkich operacji wykonanych w ramach tej transakcji są odseparowane od pozostałych transakcji w innym wypadku dane stałyby się niespójne. Koniecznośd izolowania transakcji krótkoterminowych od innych operacji i blokowanie zasobów do momentu zakooczenia wszystkich operacji składających się na transakcję sprawia, że transakcje takie nie mogą byd realizowane zbyt długo, gdyż zachodzi możliwośd wyczerpania zasobów i spowodowania problemów współbieżności. Efekty realizacji transakcji widoczne we wszystkich menedżerach zasobów są trwałe po zatwierdzeniu transakcji wynik jest trwały i widoczny dla innych transakcji. Opisane tu warunki realizacji transakcji określa się mianem ACID (atomicity niepodzielnośd, consistency spójnośd, isolation izolacja, durability trwałośd). Natomiast realizacja transakcji długoterminowych może trwad dni, tygodnie czy nawet miesiące, co nie jest możliwe w przypadku transakcji krótkoterminowych. Ten typ transakcji stosuje się zwykle w procesach, w których niezbędna jest wymiana komunikatów pomiędzy różnymi organizacjami. Transakcja długoterminowa może zainicjowad wiele mniejszych transakcji długoterminowych lub pojedynczych operacji, jednak efekt wykonania transakcji długoterminowej nie jest zgodny z regułami ACID, które dotyczą z reguły transakcji krótkoterminowych. W przypadku niepowodzenia wykonania operacji wchodzącej w skład transakcji długoterminowej nie jest możliwe automatyczne wycofanie efektów wykonanych wcześniej operacji (jak to ma miejsce w przypadku transakcji niepodzielnych). Może to spowodowad zakłócenie spójności zasobów zewnętrznych. Niezbędne jest więc wdrożenie procedur kompensacyjnych, pozwalających na umiejętne wycofanie rezultatów wcześniejszych, udanych operacji. Obecnie usługi Web Service nie pozwalają na korzystanie z dobrodziejstw przetwarzania transakcyjnego specyfikacja protokołu SOAP nie definiuje protokołu umożliwiającego włączenie wywołania usługi Web Service do transakcji. Z braku wysokopoziomowego protokołu aplikacyjnego, wszystkie komunikaty SOAP traktowane są jako niezależne operacje (zresztą procesor SOAP nie mógłby inaczej traktowad komunikatów, ponieważ ewentualny protokół byłby specyficzny dla aplikacji i nie obejmowałby warstwy komunikacyjnej SOAP). Protokoły niezbędne do obsługi różnych typów transakcji przez usługi Web Service definiowane są przez specyfikację WS-Coordination, a także specyfikacje WS-AtomicTransaction oraz WS-BusinessActivity. W specyfikacjach tych zdefiniowano zestaw standardowych nagłówków SOAP, dzięki którym operacje wykonywane na usługach Web Service mogą byd elementami rozproszonych transakcji pomiędzy różnymi organizacjami. Przedłożenie dokumentu w usłudze rejestracji dokumentów może byd realizowane w ramach transakcji krótko- lub długoterminowej w zależności od wymagao konsumentów oraz możliwości usługi agencji lub usługi pomocniczej. Jednak zanim obsługa transakcji stanie się realna, potrzebne jest ukooczenie prac nad wymienionymi wyżej specyfikacjami oraz implementacja tych specyfikacji w platformach wykorzystywanych do budowy systemów informatycznych. Orkiestracja procesów biznesowych Usługa rejestracji przekazuje dokumenty dalej do innych usług na podstawie reguł działających w oparciu o mapowanie adresów, metadane lub treśd dokumentu. Usługa ta powinna byd oparta na przyjętych w branży standardach i specyfikacjach opracowanych przez organizacje W3C i OASIS oraz specyfikacjach WS-* i spełniad podstawowe wymagania dotyczące komunikacji i wymiany RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 92

93 komunikatów, takie jak zachowanie poufności i integralności komunikatów, gwarantowane dostarczenie komunikatu, obsługa transakcji, załączników itp. Spełnienie wymienionych wyżej wymagao warstwy komunikacyjnej jest w niektórych przypadkach krytyczne, a w innych pożądane. Opisane do tej pory usługi nie pozwalają jednak na zbudowanie protokołu aplikacyjnego w oparciu o proste mechanizmy wymiany komunikatów, koordynujące przepływ komunikatów oraz wysyłanie i odbieranie komunikatów z różnych węzłów systemu. Protokół aplikacyjny (zwany też procesem biznesowym) budowany jest zwykle na podstawie zestawu statycznych i dynamicznych reguł biznesowych. Czasem używa się też pojęcia systemowy obieg zadao (system workflow) obieg zadao pomiędzy systemem lokalnym i systemami zdalnymi, nie wymagający interakcji z użytkownikami tych systemów. Realizacja procesu biznesowego przez silnik orkiestracji polega na ustaleniu drogi przepływu komunikatu przez ten proces i dostarczeniu komunikatu do pewnej liczby punktów koocowych (partnerów, usług, aplikacji itp.) zgodnie z określonymi dla tego procesu regułami. Na przykład protokół wymiany komunikatów między konsumentem a dostawcą usługi realizacji płatności (payment service provider PSP) może składad się z następujących etapów: - wysłanie do PSP żądania autoryzacji wstępnej, - odbiór potwierdzenia żądania, - sprawdzenie stanu autoryzacji, - następnie, jeśli autoryzacja przebiegła pomyślnie: o o o wysłanie do PSP żądania realizacji płatności, odbiór potwierdzenia żądania, sprawdzenie, czy realizacja żądania przebiegła bezbłędnie. W przyszłości proces taki mógłby zostad rozbudowany o dodatkowy etap, polegający na wybraniu najbardziej ekonomicznego PSP w oparciu o kwotę transakcji oraz opłatę pobieraną przez PSP za realizację płatności o danej wysokości. W tym wypadku statyczna częśd procesu biznesowego definiuje poszczególne kroki, decyzje i rozgałęzienia sterowania, niezbędne do budowy logiki biznesowej. Częśd ta jest częścią statyczną, ponieważ pozostaje niezmieniona do czasu, aż zmiana wymagao systemowych spowoduje koniecznośd dodania kilku dodatkowych kroków związanych na przykład z włączeniem do procesu jakiejś aplikacji branżowej. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 93

94 Ilustracja 27. Przykład procesu biznesowego implementującego protokół biznesowy pomiędzy dwiema stronami Częśd dynamiczna procesu definiuje parametry lub zasady biznesowe, mające wpływ na wyniki poszczególnych decyzji. Zmiany zasad biznesowych wymagają odpowiedniego uwzględnienia ich w sposobie działania systemu w celu utrzymania sprawności jego działania. Wródmy do naszego przykładu. Elementem takich dynamicznych zasad biznesowych mogą byd wysokości prowizji od operacji płatności informacje takie muszą byd natychmiast aktualizowane w odpowiedzi na zmiany cen, publikowane przez dostawców usług realizacji płatności. Innym parametrem wymagającym aktualizacji może byd progowa wartośd transakcji płatności, określająca preferowanego dostawcę dla realizacji tej transakcji. Na ilustracji 27. przedstawiono uproszczony schemat opisanej wyżej interakcji pomiędzy dwoma uczestnikami. Kolorowe trójkątne symbole odpowiadają interfejsom publicznym usług, czyli punktom, w których realizowane są interakcje. Symbolami dokumentów oznaczono przepływy danych pomiędzy stronami interakcji. Do reprezentacji interakcji pomiędzy elementami systemu służy specyfikacja WS-BPEL (znana wcześniej pod nazwą BPEL4WS), która może byd wykorzystywana przez silnik orkiestracji do wykonywania logiki procesu biznesowego. BPEL to standard reprezentacji procesów biznesowych. Standard ten jest niezależny od wykorzystywanych technologii i może obejmowad usługi działające w różnych systemach i organizacjach. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 94

95 Uwaga pieczę nad standardem WS-BPEL sprawuje organizacja OASIS. Wersja 2 tej specyfikacji, posiadająca obecnie status Draft, dostępna jest pod adresem Procesy biznesowe w hubie usług Mimo że podstawowym zadaniem huba jest ułatwienie komunikacji, częśd operacji komunikacyjnych może byd bardziej złożona niż proste przekazanie dokumentu pomiędzy dwoma punktami koocowymi. Jeśli potrzebne jest stosowanie wysokopoziomowych protokołów biznesowych i procesów, hub powinien zapewnid możliwośd wykonywania tych procesów w standardowy sposób, którego realizacja możliwa jest na różnych platformach, z wykorzystaniem różnych technologii. W odróżnieniu od interfejsu publicznego (protokołu biznesowego wykorzystanego do interakcji pomiędzy różnymi elementami systemu), prywatne implementacje procesów biznesowych są z reguły wewnętrzną sprawą realizujących je organizacji. Dostępne w hubie usług warstwa publiczna oraz usługi warstwy prywatnej usługi przekazywania komunikatów, usługi integracyjne, usługi procesów biznesowych można modyfikowad i dopasowywad do potrzeb organizacji będącej właścicielem danej części rozwiązania niezależnie od tego, czy jest to agencja centralna, agencja lokalna czy partner współuczestniczący w kosztach utrzymania huba. Integracja z usługami zaplecza Większośd wcześniejszych sekcji tego dokumentu zawiera opis architektury referencyjnej ogólnego huba usług, w którym interakcje pomiędzy usługami zachodzą w oparciu o uznane standardy branżowe i specyfikacje, pozwalające uzyskad tak ważny w środowisku heterogenicznym wysoki poziom interoperacyjności. Uzyskanie bezpośredniej interoperacyjności pomiędzy systemami opartymi na standardach to ważny cel w budowaniu systemu, jednak integracja z istniejącymi systemami i usługami administracji publicznej rozwiązaniami bardzo zróżnicowanymi, tworzonymi na zamówienie albo produktami gotowymi jest sporym wyzwaniem. Prawdopodobnie systemy te z wolna będą uzyskiwały możliwośd komunikacji z wykorzystaniem usług Web Service o ile w ogóle taka możliwośd się pojawi. Prywatna strona (biała skrzynka) usługi rejestracji przekazuje dokument do innej usługi lub do silnika usług integracyjnych. Usługi integracyjne to ogólna nazwa wspólnej platformy integracyjnej, zapewniającej komunikację EAI (Enterprise Application Integration) i B2B (Businessto-Business). Implementacja białej skrzynki usługi rejestracji jest elementem platformy usług integracyjnych, pozwala więc na integrację z usługami agencji nieobsługującymi interfejsu Web Service opartego na standardach i profilu interoperacyjności przyjętym w sektorze publicznym na przykład WS-I Basic Profile. W ramach wspólnej platformy usługi integracyjne umożliwiają integrację z systemami wykorzystującymi różnorodne mechanizmy, takie jak: - SOAP do komunikacji z usługami Web Service, - HTTP proste publikowanie dokumentów na serwerach internetowych, często w formacie XML, - FTP do transmisji plików zawierających duże ilości danych, - mechanizmy kolejkowania, takie jak IBM MQSeries i Microsoft MSMQ, - pliki w lokalnych lub sieciowych systemach plików, - zapytania do baz danych z wykorzystaniem technologii ODBC i OLEDB, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 95

96 - SMTP i POP3 do dostępu do poczty elektronicznej i wysyłania wiadomości , - niestandardowe interfejsy API czasami oferowane przez producentów oprogramowania w celu umożliwienia klientom dostępu do danych w zorganizowany i wspierany sposób. Na ilustracji 28 przedstawiono strukturę logiczną platformy usług integracyjnych. Adaptery to komponenty zapewniające obsługę konkretnego protokołu lub komunikację z interfejsem API. Implementacje czarnej i białej skrzynki są logicznie elementami usługi rejestracji, jednak implementacja białej skrzynki może korzystad z platformy usług integracyjnych w zakresie komunikacji z usługami agencji. Ilustracja 28. Struktura logiczna usług integracyjnych Systemy zwykle obsługują jakąś metodę integracji. Czasem jest to po prostu możliwośd wsadowego importu danych, bez komunikacji w czasie rzeczywistym. Zdarzają się jednak systemy wykorzystujące gotową aplikację, która nie oferuje żadnych możliwości integracji. Aplikacje takie albo wykorzystują zamknięty format danych, albo są oparte na standardowej bazie danych, ale ich producent nie przewidział żadnego interfejsu umożliwiającego dostęp do zgromadzonych danych. W takich przypadkach zachodzi koniecznośd rozszerzenia typowo systemowego przepływu zadao o elementy obsługiwane przez ludzi. Element obsługiwany przez operatora lub użytkownika koocowego służy zadaniom takim jak przyjmowanie danych i wprowadzanie ich do aplikacji, która nie daje się zintegrowad. Uwaga w niektórych przypadkach aplikacje oparte są na standardowej bazie danych, takiej jak Oracle czy SQL Server, ale nie zapewniają żadnego wspieranego interfejsu dostępu do danych zgromadzonych w bazie danych. Chociaż producenci baz danych zapewniają metody dostępu programistycznego do baz danych, taka metoda dostępu do danych aplikacji nie jest zalecana. Polega ona na bezpośrednim dostępie do surowych danych w tabelach bazy danych, a struktura danych może byd różna w różnych wersjach aplikacji. W przypadku budowy rozwiązania integracyjnego na poziomie bazy danych każde uaktualnienie oprogramowania może uniemożliwid dalsze funkcjonowanie systemu lub byd przyczyną występowania błędów, na które nie można sobie pozwolid w środowisku produkcyjnym. Istnieje także prawdopodobieostwo, że platforma integracyjna i integrowana aplikacja będą zarządzane przez różne departamenty. W takiej sytuacji uaktualnienie aplikacji może nastąpid bez wiedzy departamentu zarządzającego platformą integracyjną. W celu uniknięcia takich problemów każda integracja systemu lub aplikacji powinna byd oparta na wspieranym interfejsie lub protokole. Przekazywanie dokumentów do zainteresowanych stron Chociaż silnik usług integracyjnych nie zawsze jest głównym silnikiem decydującym o drodze przekazywania komunikatów, zapewnia on możliwośd przekazywania komunikatów w oparciu RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 96

97 o reguły routingu zapisane w postaci metadanych lub w oparciu o treśd komunikatu (patrz wcześniejsza sekcja Usługi rejestracji dokumentów). Po przyjęciu dokumentu przez platformę integracyjną, silnik usług integracyjnych musi przekazad ten dokument do odpowiedniego systemu, aplikacji lub partnera z wykorzystaniem mechanizmu komunikacyjnego skonfigurowanego dla systemu docelowego. Mechanizmem takim może byd folder dyskowy, publikacja dokumentu na serwerze WWW lub wywołanie procedury składowanej z określonej bazy danych. Schemat brokera komunikatów Broker komunikatów stanowi pewien rodzaj separatora pomiędzy systemem źródłowym a docelowym. Rozwiązanie to przewyższa rozwiązania integracyjne punkt-punkt pod tym względem, że broker może transformowad dane systemu źródłowego na format oczekiwany przez system docelowy. Oznacza to, że systemy docelowe nie muszą obsługiwad danych w formatach udostępnianych przez systemy źródłowe. Co więcej, broker komunikatów może pracowad zarówno w trybie bezpośrednim, jak i pośrednim. Tryb pracy decyduje o sposobie komunikacji systemu źródłowego z systemem docelowym. W trybie bezpośrednim system źródłowy kieruje do brokera pytanie o lokalizację systemu docelowego, a gdy otrzyma odpowiedź, komunikuje się bezpośrednio z systemem docelowym. Ten tryb pracy nie zapewnia jednak pełnej separacji systemu źródłowego i docelowego. Z tego względu brokery komunikatów obsługują także pośredni tryb komunikacji, w pełni kontrolując komunikację pomiędzy systemem źródłowym i docelowym. Mogą także oferowad dodatkowe usługi związane z bezpieczeostwem, transformowaniem komunikatów, routingiem, inspekcją i raportowaniem. Pośredni tryb komunikacji często nazywany jest modelem huba i szprych. Schemat brokera komunikatów przedstawiono na ilustracji 29. Ilustracja 29. Schemat brokera komunikatów Schemat magistrali komunikacyjnej Schemat magistrali komunikacyjnej różni się od schematu brokera komunikatów tym, że systemy docelowe zgłaszają chęd uczestnictwa w procesie przekazywania komunikatów, a dostarczanie komunikatów z użyciem magistrali odbywa się albo poprzez routing (na podstawie danych o konfiguracji routingu), albo poprzez mechanizm publikowania i subskrypcji. W przeciwieostwie do schematu brokera komunikatów, w którym system źródłowy musi znad lokalizację systemu docelowego, w przypadku magistrali komunikacyjnej system źródłowy nie musi nawet wiedzied, kto jest odbiorcą komunikatów. Stosowanie schematu magistrali komunikacyjnej ułatwia dodawanie i usuwanie systemów docelowych bez wpływu na pozostałe interakcje pomiędzy systemami i zapewnia pełną separację systemów źródłowych i docelowych. Wszystkie systemy korzystające z magistrali komunikacyjnej muszą obsługiwad pewien wspólny (kanoniczny) zbiór schematów komunikatów z danymi oraz komunikatów sterujących i stosowad te schematy do formatowania wszystkich komunikatów przesyłanych magistralą. Jeśli jakiś system źródłowy nie obsługuje natywnie wymaganego formatu komunikatów, konieczne jest zastosowanie translatora konwertującego format natywny systemu na format kanoniczny. Analogicznie, w przypadku systemu docelowego konieczne jest zastosowanie translatora konwertującego format kanoniczny na format natywny. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 97

98 Systemy źródłowe i docelowe muszą byd wyposażone w interfejsy łączące je z magistralą komunikacyjną. Jeśli nie zapewniają takiej funkcjonalności w sposób natywny, konieczne jest opracowanie odpowiednich adapterów obsługujących komunikację z systemem poprzez wywołania odpowiedniego interfejsu API lub z wykorzystaniem określonego protokołu sieciowego. Schemat magistrali komunikacyjnej przedstawiono na ilustracji 30. Ilustracja 30. Schemat magistrali komunikacyjnej Wspólna platforma infrastruktury zapewnia mechanizmy do wysyłania komunikatów z użyciem magistrali. Zarządza komunikatami przesyłanymi magistralą i dba, by były one przekazywane do właściwych systemów docelowych na postawie zestawu reguł routingu lub mechanizmu znanego jako mechanizm publikowania i subskrypcji. Mechanizm ten opisano w następnej sekcji. Mechanizm publikowania i subskrypcji Jednym z najbardziej elastycznych mechanizmów routingu komunikatów na magistrali komunikacyjnej jest mechanizm publikowania i subskrypcji. System źródłowy publikuje komunikat na magistrali komunikacyjnej nie musi nic wiedzied o systemie docelowym. Z kolei systemy docelowe rejestrują chęd otrzymywania komunikatów określonych typów poprzez subskrypcję komunikatów spełniających określone wymagania. Nowe i istniejące systemy docelowe mogą subskrybowad komunikaty i rezygnowad z subskrypcji, nie wpływając w żaden sposób na publikowanie ich przez systemy źródłowe i subskrypcje innych systemów docelowych. Subskrypcje mogą byd bardzo precyzyjnie definiowane w oparciu o zasady routingu zapisane w metadanych oraz w oparciu o treśd komunikatów (patrz wcześniejsza sekcja Usługi rejestracji dokumentów). Współdzielona infrastruktura magistrali komunikacyjnej implementuje mechanizm publikowania i subskrypcji i utrzymuje subskrypcje zarejestrowane przez systemy docelowe. Jest także odpowiedzialna za filtrowanie subskrypcji i identyfikowanie systemów docelowych, do których powinny trafid komunikaty opublikowane na magistrali. Zasadę działania magistrali komunikacyjnej i mechanizmu publikowania i subskrypcji przedstawiono na ilustracji 31. Dokument opublikowany przez system źródłowy A nie trafi ani do systemu docelowego B, ani do systemu docelowego C parametry zarejestrowanych przez te systemy subskrypcji (określające metadane i treśd komunikatu) nie odpowiadają właściwościom opublikowanego komunikatu. Właściwości komunikatu odpowiadają natomiast parametrom subskrypcji zarejestrowanych przez systemy docelowe A i D i w związku z tym komunikat zostanie doręczony do tych właśnie systemów. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 98

99 Ilustracja 31. Mechanizm publikowania i subskrypcji Uwaga szczegółowy opis struktury magistrali komunikacyjnej i mechanizmu publikowania i subskrypcji znajduje się w dziale Microsoft Patterns and Practices witryny MSDN pod adresem Komunikacja z systemami zaplecza Usługa rejestracji (opisana wyżej w sekcji Usługi rejestracji dokumentów) obsługuje zarówno asynchroniczne, jak i synchroniczne mechanizmy przekazywania dokumentów, w zależności od możliwości systemu zaplecza. Synchroniczne przesyłanie dokumentów do systemu zaplecza zwykle wymaga, by system zaplecza w ramach operacji żądania-odpowiedzi udzielił jakiejś odpowiedzi biznesowej. Na przykład gdy usługa rejestracji zażąda walidacji znanych faktów określonej usługi agencji, żądanie zostanie zablokowane do czasu otrzymania odpowiedzi. To, czy system zaplecza potrafi obsługiwad żądania synchroniczne czy asynchroniczne, zależy wyłącznie od technologii, w jakiej system ten został zaimplementowany. Niektóre systemy obsługują tylko jeden tryb komunikacji. Aby skompensowad wymagania i zapewnid pełne możliwości integracyjne, architektura usług integracyjnych powinna uwzględniad obsługę zarówno żądao synchronicznych, jak i asynchronicznych. Szczegółowy opis sposobów integracji z różnymi technologiami i platformami wykracza poza zakres tego dokumentu, jednak w następnych sekcjach zamieszczono ogólne wskazówki na ten temat. Komunikacja synchroniczna Gdy komunikacja z systemem zaplecza realizowana jest w sposób synchroniczny, usługa integracyjna w ramach operacji żądania-odpowiedzi powinna otrzymad jakąś odpowiedź biznesową. Innymi słowy, dokument zwrócony w wyniku wywołania systemu powinien zawierad odpowiedź na to żądanie. Ta metoda komunikacji jest typowa dla protokołów żądania-odpowiedzi takich jak HTTP, w którego przypadku przeglądarka internetowa w odpowiedzi na żądanie określonej strony otrzymuje treśd dokumentu HTML. System zaplecza może obsługiwad integrację na podobnych zasadach, przyjmując w ramach żądania HTTP dokument XML z typem zawartości text/xml zamiast tradycyjnego text/html, charakterystycznego dla stron internetowych. Następnie system zwraca odpowiedź biznesową, zawartą w standardowej odpowiedzi HTTP z odpowiednim kodem odpowiedzi (np. 200 OK w przypadku poprawnego przetworzenia dokumentu lub z kodem błędu, jeśli podczas przetwarzania napotkane zostały jakieś błędy). Przesłanie odpowiedzi biznesowej może zostad zrealizowane z użyciem dowolnego innego protokołu synchronicznego, na przykład specyficznego dla aplikacji protokołu opartego na TCP/IP RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 99

100 o ile oczywiście istnieje adapter pozwalający usłudze integracyjnej na komunikację z użyciem tego protokołu. Na ilustracji 32. przedstawiono usługę integracyjną, obsługującą komunikację synchroniczną z usługą agencji w imieniu usługi rejestracji użytkowników za pośrednictwem usługi rejestracji dokumentów. W tym scenariuszu usługa rejestracji użytkowników (początkowy system źródłowy) żąda walidacji informacji przedstawionych przez użytkownika względem danych referencyjnych przechowywanych przez usługę docelową, a nie w lokalnej składnicy danych. Ilustracja 32. Komunikacja synchroniczna Uwaga komunikacja synchroniczna może mied poważny wpływ na wydajnośd i skalowalnośd systemu. Pomiędzy żądaniem a odpowiedzią powinny występowad jak najmniejsze opóźnienia, co może nie byd możliwe w przypadku dużego obciążenia systemu (w zależności od przyjętej architektury). Wraz ze wzrostem obciążenia systemu opóźnienie wzrasta do poziomu, na którym przestaje byd akceptowalne dla użytkowników koocowych. Może także wykroczyd poza ramy określone w umowie o poziomie usługi (Service Level Agreement SLA). Komunikacja synchroniczna może mied także wpływ na skalowalnośd rozwiązania, szczególne w przypadku, gdy w umowie SLA określono limity opóźnieo. Ponieważ wymagania dotyczące rozwiązao synchronicznych (niskie opóźnienia, praca w czasie rzeczywistym) z reguły różnią się od wymagao dla rozwiązao asynchronicznych (przepustowośd, praca prawie w czasie rzeczywistym, trwałośd komunikatów), dlatego infrastruktura potrzebna do obsługi obu typów rozwiązao jest różna; różnią się także sposoby dostrajania wydajności. Komunikacja asynchroniczna Komunikacja asynchroniczna z systemem zaplecza to preferowany model komunikacji w systemach opartych na wymianie komunikatów. Skalowalnośd systemów asynchronicznych jest wyższa niż systemów synchronicznych nie ma potrzeby zapewniania obsługi w czasie rzeczywistym z minimalnymi czasami odpowiedzi. Nadawca może jednak po przesłaniu żądania nadal wymagad odpowiedzi biznesowej. Udzielenie takiej odpowiedzi na komunikat żądania w ramach ścieżki zwrotnej lub komunikatu zwrotnego nie jest możliwe. W takim przypadku nadawca podaje adres zwrotny (np. używając elementu ReplyTo specyfikacji WS-Addressing), na który system docelowy ma przesład odpowiedź biznesową. Na wypadek niemożliwości przesłania odpowiedzi (np. z powodu jakiegoś błędu), nadawca może określid także dodatkowy adres (element FaultTo specyfikacji WS-Addressing), na przykład lokalizację odbiorcy wszystkich komunikatów o błędach. Sposób dostarczenia początkowego żądania do systemu zaplecza może nadal wymagad jakiejś odpowiedzi technicznej, np. kodu odpowiedzi HTTP 200 OK potwierdzającej poprawne przyjęcie komunikatu. Na ilustracji 33. przedstawiono asynchroniczną komunikację z usługą agencji przez usługi integracyjne w imieniu usługi rejestracji dokumentów. Usługa agencji odsyła odpowiedź do usługi rejestracji z użyciem osobnego kanału komunikacyjnego (na adres ReplyTo), która następnie przekazuje ją nadawcy żądania w tym wypadku jest to portal internetowy. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 100

101 Ilustracja 33. Komunikacja asynchroniczna Bezpieczeostwo Jednym z najważniejszych aspektów, dotyczących każdej aplikacji, jest zabezpieczenie tej aplikacji przed działaniami złośliwych użytkowników, automatycznymi atakami z wykorzystaniem wirusów i robaków internetowych, atakami typu DoS (Denial of Service zablokowanie usługi) czy wyciekami informacji poufnych. W przypadku projektów integracyjnych dla sektora publicznego wymagania te mają szczególne znaczenie charakter przechowywanych danych sprawia, że aplikacje te są narażone na częste ataki mające na celu kradzież tożsamości, zniszczenie danych lub zablokowanie dostępu do usług. Architektura bezpiecznego rozwiązania musi uwzględniad zarówno ogólne zagadnienia związane z bezpieczeostwem, jak i zagadnienia specyficzne dla rozwiązao integracyjnych dla sektora publicznego. Ogólne sposoby podejścia do problemu bezpiecznej architektury rozwiązania Trzy najważniejsze związane z bezpieczeostwem cele, o których należy pamiętad projektując dowolną aplikację, to: - poufnośd aplikacja musi dawad gwarancję, że dostęp do danych oraz do wszystkich funkcji modyfikujących dane mają wyłącznie uprawnieni użytkownicy. Żaden inny użytkownik nie powinien mied możliwości wyświetlenia, usunięcia lub zmodyfikowania jakichkolwiek danych; - integralnośd wszystkie realizowane na danych operacje muszą chronid te dane przed uszkodzeniem. Każda operacja powinna albo zakooczyd się pomyślnie i pozostawid dane w nowym, poprawnym stanie, albo zakooczyd się niepowodzeniem, pozostawid dane w stanie niezmienionym i poinformowad użytkownika lub inną uprawnioną osobę o niepowodzeniu. Wszelkie modyfikacje danych muszą byd odnotowywane (na przykład w dzienniku inspekcji) z możliwością odtworzenia danych oryginalnych i bieżącego monitorowania wprowadzanych zmian; - uwierzytelnianie każdy użytkownik musi zostad odpowiednio zidentyfikowany na początku pracy z aplikacją, oraz jeśli zachodzi taka potrzeba także w trakcie pracy, przed wykonaniem określonej operacji. Dotyczy to przede wszystkim przeglądania, usuwania i modyfikowania danych. Realizacja tych celów wymaga podziału architektury na warstwy logiczne i zaimplementowania bezpieczeostwa w poszczególnych warstwach. Każda warstwa, odwołując się do innej warstwy albo do usługi zewnętrznej, wraz z wywołaniem przesyła informacje uwierzytelniające, oparte na uwierzytelnieniu użytkownika, który spowodował wywołanie danej usługi. Jeśli warstwa lub usługa odbierająca wywołanie wymaga dodatkowych informacji, powinna zażądad ich przed przejściem do dalszych etapów procesu. Wskazówki dotyczące projektowania architektur bezpiecznych rozwiązao, opartych na.net Framework i usługach Web Service, oraz implementowania takich rozwiązao można znaleźd w witrynie Microsoft Security Developer Center. Witryna, znajdująca się pod adresem zawiera ogólne informacje dotyczące bezpieczeostwa oraz łącza do witryny Microsoft Patterns and Practices Center, w której zgromadzono zalecenia dotyczące określonych przykładów zastosowao. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 101

102 Wzorce i dobre praktyki dotyczące bezpieczeostwa Koncepcję wzorców i najlepszych praktyk opisano na stronie katalogowej witryny Microsoft Patterns and Practices Center pod adresem Lista dostępnych wzorców i praktyk znajduje się pod adresem Pierwszy etap tworzenia bezpiecznej architektury polega na rozpoznaniu zagrożeo dla danej aplikacji oraz analizie dostępnych technik zabezpieczenia aplikacji przed tymi zagrożeniami. Najczęstsze zagrożenia przedstawia ilustracja 34, zaczerpnięta z opracowanego przez dział Microsoft Patterns & Practices dokumentu Improving Web Application Security: Threats and Countermeasures. Dokument ten dostępny jest pod adresem Ilustracja 34. Zakres ulepszeo bezpieczeostwa aplikacji internetowych zagrożenia i środki zaradcze (ilustracja zaczerpnięta z dokumentu Improving Web Application Security: Threats and Countermeasures, opracowanego przez dział Patterns and Practices) Dokument zawiera opisy zagadnieo takich jak modelowanie zagrożeo, zabezpieczanie poszczególnych warstw aplikacji, zabezpieczanie hostów oraz zabezpieczanie samej aplikacji. W dokumencie zamieszczono także listy kontrolne, pomocne w praktycznym wykorzystaniu zgromadzonych informacji, oraz serię artykułów jak to zrobid, opisujących poszczególne zadania w systematyczny sposób. Najlepsze praktyki dotyczące bezpieczeostwa Szczegółowe informacje na temat projektowania bezpiecznych architektur rozwiązao dostępne są w witrynie Security Best Practices pod adresem Można tam znaleźd serie artykułów poświęcone najlepszym praktykom stosowanym w określonych sytuacjach, w tym między innymi: - wskazówki dotyczące pisania bezpiecznego kodu dla platformy.net Framework, - najlepsze praktyki stosowania zabezpieczeo opartych na uprawnieniach kodu (Code Access Security), RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 102

103 - minimalizacja ilości kodu dostępnego dla niezaufanych użytkowników, - projektowanie zarządzanych przez aplikację mechanizmów autoryzacji, - budowa i konfiguracja bezpiecznych witryn internetowych. Zabezpieczanie usług Web Service Bezpieczeostwo aplikacji opartych na architekturze zorientowanej na usługi (SOA), czyli większości aplikacji integracji usług w tym także projektów integracyjnych dla sektora publicznego w znacznym stopniu zależy od bezpieczeostwa i niezawodności protokołów wykorzystanych do przekazywania komunikatów pomiędzy użytkownikami a usługami docelowymi. Aby zapewnid odpowiedni poziom bezpieczeostwa, usługi Web Service muszą byd wyposażone w niezawodne mechanizmy uwierzytelniania, zapewniad poufnośd danych na wszystkich etapach przetwarzania i wspierad mechanizmy gwarantowanego jednorazowego dostarczania komunikatów z niezaprzeczalnością ich odbioru. Przekazywaniem komunikatów zwykle zajmują się usługi i oprogramowanie orkiestracyjne na przykład Microsoft BizTalk Server. BizTalk Server zapewnia funkcjonalnośd niezawodnego dostarczania komunikatów. Ochrona zawartości i zachowanie poufności komunikatów wymagają utrzymania bezpiecznych połączeo sieciowych pomiędzy użytkownikiem, hubem i usługami docelowymi. Odpowiednie bezpieczeostwo połączeo zapewniają protokoły SSL (Secure Sockets Layer) oraz HTTPS. Gwarancja niepodważalności i ochrona przed manipulowaniem zawartością komunikatów zapewniana jest przez certyfikaty cyfrowe. Uwierzytelnianie dostępu do usług Web Service najlepiej jest rozwiązad poprzez wykorzystanie rozszerzeo WS* standardów usług Web Services. Jedną z implementacji tych rozszerzeo jest pakiet Microsoft Web Service Enhancements (WSE). Szczegółowe informacje na temat pakietu można znaleźd pod adresem Dostępny jest także artykuł opisujący całą serię rozszerzeo oraz uzasadniający koniecznośd stosowania ich w aplikacjach Web Service. Artykuł ten znajduje się pod adresem Uwaga warto w tym miejscu podkreślid, że WSE to pakiet zbiorczy, obejmujący obsługę wielu rozszerzeo standardów Web Service. Z punktu widzenia bezpieczeostwa, najważniejszymi rozszerzeniami są: - WS-Security pozwala na łatwe przekazywanie zabezpieczonych komunikatów z wykorzystaniem istniejących mechanizmów transportowych. Bezpieczeostwo realizowane jest na poziomie pojedynczego komunikatu, a nie warstwy transportowej. - WS-Trust zapewnia funkcje bezpiecznego przesyłania poświadczeo tożsamości za pośrednictwem usług Web Service. - WS-Policy definicja składni XML do celów walidacji odbieranych komunikatów SOAP w oparciu o opis cech takich jak podpisy elektroniczne i szyfrowanie. Cechy te nie są obsługiwane przez standardowe dokumenty WSDL. - WS-Addressing zapewnia lepszą kontrolę nad przekazywaniem komunikatów Web Service pomiędzy serwerami i usługami. Jednym ze sposobów uproszczenia uwierzytelniania i autoryzacji w rozwiązaniu integracyjnym, obejmującym wiele zdalnych usług, jest zaimplementowanie do tego celu centralnej usługi opartej na tokenach, której będą ufały wszystkie pozostałe usługi. Usługa centralna zaimplementowana wewnątrz huba wydaje użytkownikom tokeny, które ci następnie przedstawiają każdej usłudze, do której uzyskują dostęp. Usługi zdalne mogą zweryfikowad token, odwołując się do usługi centralnej. Uzyskujemy w ten sposób proste rozwiązanie problemów zwielokrotnienia, charakterystycznych dla wszystkich rozwiązao integracyjnych. Podejście takie na dodatek ułatwia tworzenie niestandardowych mechanizmów uwierzytelniania dla każdego użytkownika i każdej usługi. System uwierzytelniania wykorzystany w architekturze referencyjnej opisano w sekcji na temat uwierzytelniania i autoryzacji. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 103

104 Zagadnienia bezpieczeostwa specyficzne dla architektury systemów dla sektora publicznego Projekty integracyjne dla sektora publicznego mają wiele cech wspólnych z innymi systemami usług elektronicznych powszechnego użytku (na przykład z usługami bankowymi czy sklepami internetowymi). Wszystkie wymienione w poprzednim rozdziale ogólne zagrożenia oraz wskazówki dotyczą także systemów dla sektora publicznego. Istnieją jednak pewne związane z bezpieczeostwem zagadnienia specyficzne dla architektury systemów dla sektora publicznego. Opisujemy je w tym rozdziale. Ochrona i poufnośd danych W zależności od wybranej topologii i sposobu implementacji, hub usług dla sektora publicznego może przechowywad dane osobowe bardzo wielu użytkowników nawet wszystkich obywateli kraju. Na kształt architektury systemu mogą mied wpływ różne uwarunkowania prawne, co może ograniczyd wybór dostępnych rozwiązao technicznych. Jeśli na przykład lokalne regulacje prawne zabraniają jakiegokolwiek współdzielenia informacji (nawet samych identyfikatorów) przez jednostki administracji publicznej, początkowa identyfikacja użytkowników podczas rejestracji do usług będzie musiała byd realizowana zdalnie. Centralny hub w celu zweryfikowania informacji przedstawionych przez użytkownika, zamiast skorzystad z przechowywanych zwykle lokalnie danych referencyjnych, będzie musiał odwoład się do dostawcy usługi (szczegółowy opis możliwych rozwiązao identyfikacji początkowej znajduje się w sekcji Logika weryfikująca i dane referencyjne rozdziału Usługi zarządzania tożsamością wcześniej w tym dokumencie). Gdy dane referencyjne poszczególnych usług przechowywane są w hubie centralnym, niezbędne jest zastosowanie odpowiednich środków kontroli dostępu do tych danych. Na przykład przechowywanie danych referencyjnych różnych usług w niezależnych bazach danych pozwala na zróżnicowanie praw dostępu do tych danych dla poszczególnych administratorów. Infrastruktura techniczna i sieci komputerowe W niektórych krajach istnieje dedykowana infrastruktura techniczna (w tym sieci komputerowe) przeznaczona do obsługi urzędów. Ze względu na określone reguły dostępu i procedury akredytacyjne, określające kto i w jaki sposób może korzystad z infrastruktury, infrastruktura ta zwykle może byd uważana za bardziej bezpieczną. Samo uzyskanie dostępu do infrastruktury zwykle zapewnia wystarczająco wysoki poziom bezpieczeostwa i niezawodności komunikacji z innymi agencjami, co ułatwia proces integracji całego rozwiązania. W przypadkach, gdy taka infrastruktura jest dostępna i łączy już dostawców usług dla sektora publicznego, łatwiejsze jest bezpieczne udostępnienie usług tych dostawców dla społeczeostwa za pośrednictwem wspólnego huba usług dla sektora publicznego. Hub może pracowad jako most łączący bezpieczną infrastrukturę administracji publicznej z siecią publiczną. Poszczególni dostawcy usług nie muszą niezależnie spełniad wymagao bezpieczeostwa przed podłączeniem ich systemów do sieci publicznej. Praca ta (i wszelkie potrzebne akredytacje) może zostad wykonana jednokrotnie podczas budowy centralnego huba. Jedyne, co muszą zrobid dostawcy usług, to uzyskad połączenie z hubem. Nawet jeśli taka bezpieczna infrastruktura istnieje, a dostawcy usług mogą z niej korzystad, trzeba zadbad o to, by architektura systemu nie stała się zbyt uproszczona. Nie należy zakładad, że połączenia ze wszystkimi dostawcami usług obecnymi i przyszłymi zawsze będą realizowane za pośrednictwem bezpiecznej sieci. Architektura powinna zapewniad funkcje niezbędne do obsługi bezpiecznej komunikacji za pośrednictwem sieci publicznych, najlepiej w postaci prostej opcji, konfigurowanej niezależnie dla poszczególnych usług lub węzłów sieci. Pozwoli to w przyszłości dostosowad się do nowych wymagao, takich jak na przykład obsługa dostawców usług dla sektora publicznego, działających poza jednostkami administracji publicznej posiadającymi dostęp do bezpiecznej sieci komputerowej. Z doświadczeo, zebranych w ramach licznych projektów integracyjnych dla sektora publicznego w wielu krajach, wynika, że potrzeba takiej elastyczności zwykle pojawia się znacznie szybciej niż się spodziewano, a koszt późniejszego RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 104

105 dostosowania ograniczonej, opracowanej na podstawie z góry przyjętych założeo architektury, może byd wysoki. Zabezpieczanie hostów Systemy dla sektora publicznego mają często postad skomplikowanej pajęczyny, łączącej różnorodne węzły oparte na różnych platformach. Poszczególne węzły należą do różnych właścicieli i zarządzane są w różny sposób. Czasami brak jest jednostki nadrzędnej, która mogłaby efektywnie zobligowad wszystkich członków do stosowania dobrych praktyk w zakresie bezpieczeostwa. W niektórych krajach wszystkie elementy infrastruktury administracji publicznej muszą spełniad odpowiednie standardy bezpieczeostwa (na przykład ISO 17799) z obowiązkową akredytacją przed dopuszczeniem do użytku produkcyjnego, ale nie jest tak w każdym kraju. Odpowiednie zabezpieczenie hostów pracujących w takim środowisku jest zadaniem znacznie trudniejszym niż w przypadku środowisk komercyjnych. Należy więc założyd, że niektóre hosty mogą byd celem udanego ataku, w związku z czym niezbędne jest wdrożenie odpowiednich, dodatkowych warstw ochrony, umożliwiających efektywne działanie w przypadku włamania. Błędne założenia, co do fizycznego bezpieczeostwa systemów uczestniczących w wymianie komunikatów i nadmierna ufnośd w skutecznośd takich zabezpieczeo mogą byd zagrożeniem dla systemów pracujących w bezpiecznych centrach danych (na przykład w rejestrach podstawowych). Przykładem może byd założenie, że wzajemne uwierzytelnianie TLS/SSL punktów koocowych połączenia daje wystarczającą gwarancję, że żądania pochodzą z zaufanego źródła i nie ma potrzeby wprowadzania zabezpieczeo na poziomie pojedynczego komunikatu. Jednak, gdy ta sama usługa zostanie udostępniona szerszej rzeszy klientów, ryzyko komunikacji ze skompromitowanym hostem jest dużo wyższe. Na przykład udostępnienie usługi małym firmom, których komputery nie są fizycznie bezpieczne, a pracownicy nie są specjalistami IT, wymaga wprowadzenia dodatkowych zabezpieczeo konkretnie szyfrowania przesyłanych komunikatów. Zalecanym rozwiązaniem jest więc zaprojektowanie odpowiednich warstw zabezpieczeo już w pierwszej fazie projektu architektury, z możliwością włączania i wyłączania tych zabezpieczeo w razie potrzeby. Pozwoli to na uzyskanie lepszej elastyczności i szybsze dostosowywanie się do różnych obecnych i przyszłych, znanych i nieznanych wymagao. Zabezpieczanie hostów to ważny element ogólnej polityki bezpieczeostwa. Zaleca się, by poziom bezpieczeostwa hostów był tak wysoki, jak to tylko możliwe. W zależności od wykorzystywanej platformy i wersji systemów operacyjnych, dostępna jest cała gama możliwości od narzędzi przeznaczonych dla środowisk zarządzanych (SMS, WSUS) po usługi zorientowane na konsumenta (na przykład automatyzacja aktualizacji Windows Update) ułatwiających instalowanie najświeższych uaktualnieo i rozszerzeo zabezpieczeo. Ataki typu DoS (Denial of Service) Ataki typu DoS (Denial of Service zablokowanie usługi) są dośd często kierowane przeciwko systemom komercyjnym i istnieje duże prawdopodobieostwo wykorzystania ich przeciwko systemom dla sektora publicznego (co może mied znacznie poważniejsze skutki) po pierwsze systemy dla sektora publicznego są atrakcyjnym i dobrze widocznym celem, a po drugie liczba użytkowników dotkniętych takim atakiem jest znacznie wyższa. Należy więc dołożyd wszelkich starao, aby do minimum ograniczyd możliwości przeprowadzenia ataków DoS przeciwko hubom usług dla sektora publicznego. Objawy takich ataków to między innymi: - Zgłaszanie wielu fałszywych użytkowników - gdy testy wiarygodności zgłoszenia nowego użytkownika są nieefektywne, osoba atakująca może zgłosid do systemu bardzo wielu użytkowników z nieprawdziwymi danymi osobowymi. Zgłoszenie dużej liczby użytkowników może przeciążyd dostępne zasoby obliczeniowe i zablokowad magazyny danych, czego wynikiem zwykle jest zablokowanie dostępu do systemu dla rzeczywistych użytkowników. - Powtarzające się nieudane próby logowania brak efektywnej kontroli logowao (na przykład zliczania nieudanych prób logowania i blokowania konta po przekroczeniu limitu) może zostad wykorzystany przez osobę atakującą do obciążenia systemu dużą liczbą żądao uwierzytelnienia, co w konsekwencji prowadzi do zablokowania zasobów systemowych. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 105

106 Jeśli natomiast kontrola logowao została zaimplementowana, a atakujący zna prawidłowe identyfikatory użytkowników, atak może doprowadzid do zablokowania kont użytkowników. - Powtarzające się żądania, których obsłużenie wymaga dużej mocy obliczeniowej powtarzające się żądania innego niż wymienione wyżej typu, których obsługa zajmuje zasoby systemowe. Może to byd na przykład przesyłanie poprawnych, ale dużych dokumentów za pośrednictwem systemu rejestracji dokumentów. Zapewnienie ochrony przed takimi atakami może wymagad odpowiedniego przygotowania architektury systemu. Poniżej podano przykładowe techniki minimalizujące prawdopodobieostwo przeprowadzenia udanego ataku. Zabezpieczenie przed zgłaszaniem fikcyjnych użytkowników Jeśli nie istnieje wiarygodna metoda weryfikacji, czy próba zgłoszenia dotyczy prawdziwego użytkownika, zgłoszenie można uzależnid od innego, weryfikowalnego procesu na przykład od prawidłowej rejestracji w usłudze. Nie należy przyjmowad zgłoszeo użytkowników wyłącznie na podstawie wybranej nazwy lub identyfikatora oraz hasła, ponieważ proces taki nie pozwala na efektywne rozróżnienie prawdziwych i fałszywych danych osobowych. Dobrym rozwiązaniem jest uzależnienie utworzenia konta użytkownika od prawidłowej rejestracji w co najmniej jednej usłudze, co wymaga zweryfikowania informacji podanych przez użytkownika z informacjami referencyjnymi. Praktycznie eliminuje to ryzyko przyjęcia zgłoszenia dużej liczby fikcyjnych użytkowników. Szczegółowe informacje na temat rejestrowania użytkowników w usługach znajdują się w podsekcji Początkowa identyfikacja użytkowników w sekcji Zarządzanie tożsamością wcześniej w tym dokumencie. Zabezpieczenie przed nieudanymi próbami logowania Zabezpieczenie systemu przed powtarzającymi się nieudanymi próbami logowania może byd trudne, zwłaszcza w przypadku ataków na losowe identyfikatory użytkowników. Licznik nieudanych prób logowania zawsze musi byd związany z jakimś unikalnym identyfikatorem najczęściej z identyfikatorem użytkownika. Rozproszenie ataku na różne, losowe identyfikatory użytkowników sprawia, że standardowe metody zliczania nieudanych prób logowania na poziomie systemu lub aplikacji stają się nieskuteczne. Ataki takie mają jednak jedną cechę charakterystyczną dużą liczbę nieudanych prób logowania z jednego lub kilku źródeł w sieci możliwa jest więc obrona na poziomie infrastruktury sieciowej w oparciu o lokalizację, z której nadchodzą żądania (na przykład adres IP atakującego komputera). Istnieje jednak prawdopodobieostwo nieprawidłowego zidentyfikowania jako atak działao dużej liczby użytkowników pracujących w środowisku widocznym w sieci jako pojedyncza lokalizacja (tak jest na przykład, gdy użytkownicy korzystają z serwera pośredniczącego proxy). Zakres stosowania opisanych wyżej środków zaradczych musi zostad bardzo precyzyjnie dobrany. Aby zminimalizowad prawdopodobieostwo zablokowania dostępu prawidłowym użytkownikom, można wdrożyd mechanizm samonaprawczy założenie blokady na pewien okres i automatyczne odblokowanie dostępu po upłynięciu tego okresu. Dzięki temu, jeśli atak spowoduje zablokowanie dostępu dla dużej liczby użytkowników, po pewnym czasie dostęp zostanie przywrócony. Bez mechanizmu samonaprawczego, udany atak nie tylko zablokowałby dostęp, ale także dołożyłby pracy służbom pomocy technicznej, które musiałyby ręcznie przywracad dostęp poszczególnym użytkownikom. Zabezpieczenie przed żądaniami wymagającymi dużej mocy obliczeniowej Dobrym przykładem, ilustrującym koniecznośd zabezpieczenia się przed atakami polegającymi na przesyłaniu żądao, których obsługa wymaga dużej mocy obliczeniowej, jest odnawianie certyfikatów cyfrowych. Certyfikaty cyfrowe mogą służyd do weryfikowania tożsamości użytkownika i wiązania jej z rejestracjami w poszczególnych usługach dla sektora publicznego. Uwierzytelnienie użytkownika na podstawie certyfikatu zwykle polega na sprawdzeniu pochodzenia certyfikatu (jego wystawcy), poprawności (nie wygasł i nie został odwołany) oraz odwzorowania unikalnego identyfikatora certyfikatu na tożsamośd użytkownika. Kolejnym RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 106

107 etapem jest odszukanie odwzorowao łączących tożsamośd użytkownika z rejestracjami w usługach. Gdy system korzysta z zewnętrznych wystawców certyfikatów, okresowe odnawianie certyfikatów może odbywad się bez wiedzy huba. Na przykład gdy certyfikat jest odnawiany (u niektórych wystawców proces odnowienia certyfikatu jest przezroczysty dla użytkownika), wystawiany jest nowy certyfikat z takimi samymi danymi osobowymi nowe są tylko numer seryjny i data wygaśnięcia. Pierwsza próba uwierzytelnienia w hubie za pomocą nowego certyfikatu i standardowej procedury porównującej nie powiedzie się, ponieważ hub nie wie nic o odnowieniu certyfikatu, a w bazie nadal zapisany jest poprzedni numer seryjny. Aby poprawnie obsłużyd uwierzytelnienie, hub musi skorzystad z bardziej złożonej procedury porównania, uwzględniającej także inne dane osobowe z certyfikatu. Jeśli wynik porównania będzie pozytywny, hub aktualizuje swoje dane uaktualnia zapisany numer seryjny, utrzymując jednocześnie wszystkie pozostałe rejestracje i powiązania. Aby móc obsłużyd taką procedurę odnawiania certyfikatów, hub musi przechowywad więcej informacji niż sam numer seryjny (na przykład nazwę wyróżniającą lub inne atrybuty). Dane te potrzebne są do rozpoznania i porównania starego i nowego certyfikatu. Poszukiwanie polega na porównywaniu długich łaocuchów znaków jeśli populacja użytkowników jest duża, poszukiwanie może byd dośd kosztowe pod względem zapotrzebowania na zasoby systemowe. Poszukiwanie takie realizowane jest za każdym razem, gdy numer seryjny certyfikatu nie zostanie znaleziony w lokalnym magazynie danych referencyjnych także w przypadku przedstawienia dowolnego (nie związanego z systemem dla sektora publicznego) certyfikatu wystawionego przez zaufanego wystawcę. Niektóre techniki, powszechnie używane do obrony przed takimi atakami, to: - Poprzedzenie wyszukiwania i porównywania długiego identyfikującego łaocucha znaków (nazwy wyróżniającej) wyszukaniem wartości skrótu (ang. hash) tego łaocucha znaków. Długośd wartości skrótu łaocucha jest dużo mniejsza niż długośd tego łaocucha, co pozwala na zwiększenie wydajności operacji wyszukiwania. Wymaga to jednak wcześniejszego obliczenia i zapisana wartości skrótów nazw wyróżniających wszystkich certyfikatów w bazie danych oraz odpowiedniego poindeksowania tych danych. W czasie uwierzytelniania należy obliczyd wartośd skrótu nazwy wyróżniającej z przedstawionego certyfikatu i poszukad jej w bazie. Prawdopodobieostwo wystąpienia kolizji (dwie różne nazwy wyróżniające mają taką samą wartośd skrótu) jest bardzo niskie, należy jednak po udanym wyszukiwaniu według wartości skrótu porównad także nazwy wyróżniające. - Zastosowanie rejestru identyfikatorów certyfikatów wykorzystywanych do uwierzytelniania. Do inicjacji uwierzytelniania wymagane jest posiadanie prawidłowego certyfikatu wystawionego przez zaufanego wystawcę (w innym wypadku certyfikat zostanie odrzucony na etapie walidacji, przed rozpoczęciem procesu poszukiwania starego certyfikatu). Można więc przypuszczad, że do ataku zostanie wykorzystane tylko kilka certyfikatów. Ochrona przed atakiem polega na prowadzeniu rejestru podejrzanych, kilkakrotnie odrzuconych już certyfikatów i sprawdzaniu takiej czarnej listy przed rozpoczęciem poszukiwao wymagających dużej mocy obliczeniowej. Przedstawiono tu zaledwie kilka wybranych przykładów, ilustrujących dodatkowe problemy i zagadnienia mające wpływ na architekturę rozwiązao dla sektora publicznego. Wydajnośd i skalowalnośd Implementowane rozwiązanie musi byd bezpieczne, niezawodne i odporne. Mimo tego, wiele systemów nie zapewnia oczekiwanej wydajności i w związku z tym nie są one akceptowane przez użytkowników po wdrożeniu w świecie rzeczywistym. Dzięki testowaniu można wykryd wiele problemów i zlokalizowad sekcje aplikacji, które stanowią wąskie gardła i ograniczają ogólną wydajnośd systemu. Możliwośd spełnienia wymagao w zakresie wydajności uwarunkowana jest jednak dobrym zrozumieniem wymogów oraz faktycznych lub zakładanych schematów wykorzystania aplikacji. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 107

108 Dział Patterns and Practices firmy Microsoft udostępnił w Internecie pełne wydanie książki poświęconej tym zagadnieniom. Publikacja, zatytułowana Improving.NET Application Performance and Scalability dostępna jest pod adresem Opisano w niej zadania dla osób pełniących różne role w cyklu implementacji rozwiązania architektów oprogramowania, projektantów, programistów, testerów i administratorów. Zakres tematyczny publikacji przedstawiono na ilustracji 35, która została zapożyczona z tej książki. Ilustracja 35. Zakres tematyczny opracowanego przez dział Microsoft Patterns and Practices przewodnika Improving.NET Application Performance and Scalability. Ilustracja pochodzi z dokumentu Planowanie wydajności Zaprojektowanie systemu zapewniającego akceptowalną wydajnośd jest praktycznie niemożliwe bez poprawnego ustalenia wymagao już we wstępnej fazie projektu. Teza ta sprawdza się szczególnie w przypadku systemów rozproszonych, w których proste zwiększanie dostępnej pamięci operacyjnej, mocy obliczeniowej procesorów czy pojemności zainstalowanej w serwerach pamięci masowej nie wystarcza do uzyskania odpowiedniej wydajności, gdy wąskie gardła istnieją na innych etapach rozproszonego procesu. Planowanie wydajności pozwala projektantowi lub architektowi systemu na wyznaczenie realistycznego zestawu wymagao dla aplikacji jako całości i na podstawie tych wymagao obliczenie i sprawdzenie wymagao dla poszczególnych części aplikacji. W dokumencie Tools for Capacity Planning, opublikowanym przez Microsoft pod adresem opisano ogólne zasady planowania wydajności i analizy wymagao systemu i przedstawiono szeroką gamę narzędzi służących do testowania różnych komponentów złożonych systemów. W dokumencie przedstawiono następujące zagadnienia: - Gromadzenie informacji dotyczących wymagao szacowanej średniej i maksymalnej liczby jednoczesnych użytkowników, sposobów korzystania z aplikacji, wymaganego czasu odpowiedzi poszczególnych procesów lub działao oraz innych czynników, takich jak maksymalne akceptowalne procentowe obciążenie procesorów w systemach. - Stosowanie różnych narzędzi obliczeniowych do oszacowania wymagao sprzętowych systemów, włącznie z walidacją wydajności danej konfiguracji sprzętowej, oraz wykorzystanie narzędzi symulujących obciążenie systemu takich jak Microsoft RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 108

109 Application Center Test (ACT) i LoadSim for Microsoft Exchange Server do testowania konfiguracji sprzętowych. Czynniki mające wpływ na wydajnośd systemu Bardziej szczegółowa analiza wydajności systemu wymaga rozpatrzenia kilku czynników mających bezpośredni wpływ na budowę infrastruktury sprzętowej i sieciowej. Niezbędne jest zrozumienie implikacji, jakie niosą ze sobą wymagania określonego procentowego poziomu dostępności systemu oraz sposobu, w jaki skalowanie rozwiązania pomaga w sprostaniu tym wymaganiom. W przypadku rozproszonych aplikacji branżowych bardzo duże znaczenie ma identyfikacja pojedynczych punktów awarii, które mogłyby wstrzymad pracę całego systemu, i wyeliminowanie ich poprzez zastosowanie mechanizmów równoważenia obciążenia lub skonfigurowanie serwerów do pracy w klastrze, co pozwala na rozdzielenie obciążenia na kilka serwerów. Jeśli jeden serwer ulegnie awarii, pozostałe serwery przejmą jego zadania, rozdzielając między siebie wykonywane przez niego operacje. Proces ten nazywany jest przełączeniem awaryjnym (ang. failover). Stosowanie mechanizmów równoważenia obciążenia i pracy w klastrze możliwe jest dzięki usługom systemowym Microsoft Cluster Service (MSCS) oraz Network Load Balancing (NLB) oraz specjalistycznym rozwiązaniom sprzętowym udostępnianym przez innych producentów. Większośd komponentów systemów korporacyjnych, w tym Microsoft Exchange Server, Microsoft BizTalk Server, Microsoft Internet Information Services (IIS), Microsoft SQL Server i Microsoft Commerce Server potrafi poprawnie korzystad z opisanych wyżej mechanizmów. Istotne jest także zapewnienie odpowiedniej ochrony twardych dysków i innych systemów składowania danych przed awariami sprzętowymi. Współdzielone macierze dyskowe, dołączane do serwerów za pośrednictwem wysokowydajnych połączeo światłowodowych lub magistrali SCSI, mogą zostad zabezpieczone na przykład poprzez zastosowanie odpornej na uszkodzenia konfiguracji RAID. Skalowad wzwyż czy wszerz? Terminem skalowanie wszerz nazywa się proces konfiguracji systemu do pracy w klastrze wydajnościowym lub do pracy z równoważeniem obciążenia. Obciążenie systemu jest rozkładane wszerz na wiele serwerów i urządzeo sprzętowych, co dodatkowo zapewnia także ochronę aplikacji przed awariami sprzętu. Natomiast alternatywne podejście, nazywane skalowaniem wzwyż, jest przydatne w przypadku procesów, które muszą zagwarantowad wysoką dostępnośd i wymagają serwerów o dużych zasobach pamięci operacyjnej i mocy obliczeniowej. Na rynku dostępne są serwery odporne na awarie, pozwalające na wymianę niektórych komponentów w czasie pracy i przetrwanie awarii sprzętu bez przerywania pracy aplikacji. W połączeniu z nowymi typami procesorów i możliwością adresowania dużych ilości pamięci operacyjnej przez systemy operacyjne Microsoft Windows Server, skalowanie wzwyż jest dobrym alternatywnym rozwiązaniem. Szczegółowe omówienie kwestii dostępności, skalowalności i wydajności można znaleźd w dokumencie Overview of System Performance, dostępnym pod adresem Zgromadzono tam także łącza do innych użytecznych zasobów. Dostrajanie wydajności usług systemu Windows Na ogólną wydajnośd aplikacji, na równi z silną i niezawodną implementacją infrastruktury odpornej na pojedyncze awarie, ma także wpływ konfiguracja poszczególnych usług. Na przykład poprawna konfiguracja serwera IIS i dobrze przemyślany wybór techniki przechowywania stanu sesji mają duży wpływ na optymalizację wydajności aplikacji opartych na ASP.NET i Web Services. Analogicznie, stosowanie odpowiednich metod indeksowania danych może znacznie zwiększyd wydajnośd dostępu do baz danych SQL Server. Metody dostrajania wydajności ASP.NET opisano w artykule Performance Tuning a.net Framework Deployment, dostępnym pod adresem Opisano w nim między innymi sposób wykrywania wąskich gardeł w aplikacjach z użyciem RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 109

110 narzędzi testowania wytrzymałościowego i liczników wydajności systemu Windows. Dokument zawiera także odsyłacze do innych dokumentów dotyczących dostrajania wydajności IIS oraz doboru sposobów indeksowania danych w SQL Server. Czynniki związane z projektem i implementacją aplikacji Poza planowaniem zasobów sprzętowych pod kątem wymaganej wydajności, dobieraniem odpowiedniego modelu skalowania i dostrajaniem konfiguracji platformy i usług, ogromny wpływ na przepustowośd i czas odpowiedzi aplikacji mają także zastosowane techniki projektowania architektury i implementowania aplikacji (programowania). Poznanie tych zależności jest bardzo ważne, temat ten poruszany jest w wielu dokumentach opublikowanych w witrynie internetowej firmy Microsoft. Dokumenty te kierowane są do programistów i dotyczą różnych sposobów, w jakie przyjęte techniki kodowania aplikacji mogą wpłynąd na jej wydajnośd: - W dokumencie Performance Considerations for Run-Time Technologies in the.net Framework, dostępnym pod adresem opisano wbudowane w środowisko mechanizmy odzyskiwania zasobów (garbage collection) i tworzenia pul wątków, wpływ stosowania kompilacji just-in-time na wydajnośd oraz sposoby zwiększania wydajności poprzez optymalizację domen aplikacyjnych. Poruszono także zagadnienia dotyczące bezpieczeostwa, remotingu, doboru typów danych oraz hostowania środowiska.net Framework. - Ogólne wskazówki dotyczące tworzenia wydajnego kodu można także znaleźd w dokumencie Performance Tips and Tricks in.net Applications, dostępnym pod adresem Zawarto w nim ogólne wskazówki dotyczące wydajności wszystkich typów aplikacji, wskazówki dotyczące tworzenia wysokowydajnego kodu zapewniającego dostęp do baz danych oraz wskazówki dotyczące wydajności aplikacji ASP.NET. Dokument zawiera także informacje na temat typowych błędów, poprawiania wydajności i niezawodności aplikacji podczas migracji kodu źródłowego do Visual Basic.NET i zarządzanego C++ oraz pisania nowych aplikacji w tych językach. Wydajnośd dostępu do danych Do uzyskania wysokiej wydajności aplikacji niezbędne są efektywne mechanizmy dostępu do danych. W przypadku dostępu do relacyjnych baz danych z aplikacji.net oczywistym wyborem jest biblioteka ADO.NET. Czynniki mające wpływ na wydajnośd ADO.NET oraz sposoby projektowania i pisania kodu, ułatwiające uniknięcie typowych błędów i wąskich gardeł, jakie z tych błędów mogą wyniknąd, opisano w dokumencie ADO Performance Best Practices, dostępnym pod adresem Wydajnośd usług Web Service Stosowanie usług Web Service niesie ze sobą liczne korzyści, ale wiąże się z dodatkowymi wymaganiami w zakresie wydajności. Ogólnie rzecz biorąc, usługi Web Service wymagają większej mocy obliczeniowej i większej przepustowości sieci niż tradycyjne metody integracji, takie jak bezpośredni dostęp do danych w formacie binarnym, składowanych w relacyjnej bazie danych. Koniecznośd serializacji danych do formatu XML do celów przesyłania ich pomiędzy usługami wprowadza dodatkowe zapotrzebowanie na moc obliczeniową. Stosowanie zabezpieczeo wywołao usług Web Service na poziomie pojedynczych komunikatów (często wymagane, patrz temat Zabezpieczanie usług Web Service w sekcji Bezpieczeostwo wcześniej w tym dokumencie) także wiąże się z dodatkowym zapotrzebowaniem na moc obliczeniową do celu obliczania podpisów cyfrowych komunikatów wychodzących i dodawania do nich informacji dotyczących uwierzytelniania oraz do celu walidacji podpisów i danych uwierzytelniających komunikatów przychodzących. Aby zminimalizowad negatywny wpływ na wydajnośd i utrzymad zalety wynikające ze stosowania usług Web Service, warto dokładnie przemyśled zakres funkcjonalności RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 110

111 udostępnianej za pośrednictwem tych usług, stosowane modele wywoływania usług i inne najlepsze praktyki. Rozdział Improving Web Services Performance z przewodnika wymienionego na początku tej sekcji zawiera wskazówki projektowe oraz opis technik takich jak zarządzanie stanem, wywoływanie asynchroniczne, serializacja i wątkowanie. Dobre zrozumienie tych technik jest niezbędne do opracowania wydajnych usług Web Service. Projektowanie wydajnej i skalowalnej architektury rozwiązao dla sektora publicznego Dobre zrozumienie ogólnych zasad i technik projektowania architektury skalowalnych i wysokowydajnych systemów (opisanych w poprzedniej sekcji dokumentu) to nieodzowna podstawa udanego wdrożenia każdego rozbudowanego systemu. Oprócz wymienionych wyżej czynników istnieją jednak także inne, specyficzne dla rozwiązao dla sektora publicznego, aspekty dotyczące wydajności i skalowalności, które mogą mied wpływ na ostateczną postad architektury systemu. Wyższe oczekiwania i wymagania Zwykle wymagania dotyczące wydajności i dostępności oraz oczekiwania pokładane w rozwiązaniach dla sektora publicznego są wyższe niż w przypadku porównywalnych systemów komercyjnych. Rozwiązania dla sektora publicznego, często postrzegane jako elementy krytycznej infrastruktury paostwowej, powinny byd zawsze dostępne, charakteryzowad się bardzo krótkim czasem odpowiedzi i umied obsłużyd bardzo wysokie szczytowe obciążenia związane z różnymi terminami ostatecznymi, takimi jak koniec roku podatkowego. Wszystkie awarie na przykład zbyt duże opóźnienia lub niedostępnośd niektórych usług są bardzo denerwujące i mogą dotyczyd bardzo dużych liczb użytkowników. Podważa to publiczne zaufanie i osłabia jeden z najważniejszych czynników popularyzujących korzystanie z usług elektronicznych możliwośd elektronicznej realizacji interakcji w sposób szybszy i łatwiejszy niż z użyciem tradycyjnych kanałów obsługi. Rozmiar i wzrost Systemy dla sektora publicznego często tworzone są jako rozwiązania na małą skalę, a następnie są rozwijane w miarę wzrostu popularności korzystania z usług elektronicznych i zwiększania się liczby aktywnych użytkowników systemu. Trzy główne kierunki wzrostu, które wyznaczają wymaganą wydajnośd systemu, to: - liczba użytkowników (całkowita liczba użytkowników i liczba użytkowników jednocześnie korzystających z systemu), - liczba udostępnianych usług, - intensywnośd korzystania z poszczególnych usług oraz złożonośd udostępnianej funkcjonalności. Ze względu na zwykle stały wzrost tych wskaźników wraz z upływem czasu, niezbędne jest dokładne planowanie rozbudowy systemu tak, by mógł obsłużyd rosnące zapotrzebowanie. Ważna jest też dobrze zaprojektowana, skalowalna architektura. Przedsięwzięcia polegające na zaprojektowaniu, zbudowaniu i wdrożeniu systemu, który od razu będzie zdolny obsłużyd obciążenie spodziewane za wiele lat, realizowane są bardzo rzadko. Częściej stosowanym podejściem jest uwzględnienie w projekcie możliwości dalszej rozbudowy systemu, wdrożenie niewielkiej konfiguracji początkowej i zwiększanie jej wydajności w miarę potrzeb. Możliwośd zwiększania mocy obliczeniowej bez przerywania pracy systemu jest w przypadku systemów dla sektora publicznego niezwykle istotna. Istotna jest także możliwośd oszacowania absolutnych, maksymalnych oczekiwao w zakresie opisanych wyżej kierunków wzrostu: liczby użytkowników (czy będzie ich milion, 100 milionów, czy może miliard?), liczby usług (10, 100, a może 1.000?), liczby transakcji (żądao) na sekundę (100, 1.000, ?). Czynniki te mogą mied duży wpływ na ostateczną architekturę systemu RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 111

112 i wykorzystywane rozwiązania techniczne. Na przykład w przypadku systemu, z którego korzysta miliard (czy chodby tylko 100 milionów) użytkowników, zastosowanie pojedynczego katalogu użytkowników nie będzie najwłaściwszym rozwiązaniem w takim wypadku należy zastosowad system rozproszonych lub stowarzyszonych składnic danych. Chcąc wykorzystad zalety płynące ze skupienia określonych usług w pojedynczym, centralnym węźle i udostępnienia ich wielu dostawcom usług, należy oszacowad zasoby systemowe i moc obliczeniową, jaką będzie musiał dysponowad ten węzeł, i byd może wdrożyd rozwiązanie bardziej rozproszone. Rozproszona natura systemów dla sektora publicznego Oprócz czysto technicznych opcji i możliwości związanych ze skalowaniem wzwyż, skalowaniem wszerz i geograficznym rozproszeniem systemu, na decyzje dotyczące rozproszonej architektury rozwiązao mają wpływ także inne czynniki systemy dla sektora publicznego często stanowią zdywersyfikowaną sied systemów wydziałowych lub systemów należących do agencji, systemów centralnych, regionalnych i lokalnych, z niezależnymi właścicielami, sposobami finansowania, dostawcami, partnerami i ramami czasowymi projektów. Synchronizacja i optymalizacja tak zróżnicowanych systemów w celu zbudowania spójnej i zintegrowanej architektury (patrząc z perspektywy projektowej i technologicznej) jest prawie niemożliwa. Uwzględnienie różnych czynników politycznych, komercyjnych i prawnych często skutkuje powstaniem architektury, która nie jest optymalna z technicznego punktu widzenia. Bardzo duże znaczenie ma tu elastycznośd i możliwości (lub ich brak) przebudowy i ulepszania istniejącej topologii i podziału funkcjonalności pomiędzy systemami składowymi. Podstawową potrzebą jest identyfikacja ewentualnych ograniczeo i przeszkód, które mogą mied wpływ na przyszły kształt rozwiązania. Podstawowe zasady, rządzące referencyjną architekturą rozwiązao integracyjnych dla sektora publicznego (patrz sekcja Reguły rządzące architekturą wcześniej w tym dokumencie), to zapewnienie maksymalnej elastyczności i możliwości adaptacji systemu do różnych wymagao, w tym także związanych ze zdywersyfikowaną i rozproszoną naturą systemów dla sektora publicznego. Niektóre z cech architektury, zapewniających taką elastycznośd i ułatwiających uzyskanie wysokiej wydajności i skalowalności, to: Stowarzyszone podejście do problemu początkowej identyfikacji użytkowników i ich późniejszego uwierzytelniania, umożliwiające rozproszenie danych referencyjnych i magazynów poświadczeo tożsamości (patrz tematy Usługi zarządzania tożsamością oraz Uwierzytelnianie stowarzyszone w sekcji Usługi uwierzytelniania i autoryzacji wcześniej w tym dokumencie). Pozwala to na obsługę bardzo dużych ilości użytkowników w rozproszony sposób i charakteryzuje się innymi zaletami. Wsparcie różnych topologii składających się z wielu instancji ogólnego huba usług dla sektora publicznego, co pozwala na rozproszenie funkcjonalności i obciążenia w sposób spełniający określone wymagania i ograniczenia (patrz temat Możliwe topologie w sekcji Hub usług wcześniej w tym dokumencie). Wzorce użycia Ze względu na elastycznośd umożliwiającą implementację części funkcjonalności systemu jako kaskadowej sekwencji wywołao przekazywanych pomiędzy autonomicznymi i rozproszonymi usługami, warto zastanowid się, w jaki sposób takie rozproszenie przetwarzania może wpłynąd na wydajnośd systemu. Obsługa uwierzytelniania przez hub może wymagad odwołania się do zewnętrznego dostawcy uwierzytelniania (jak przedstawiono to w temacie Przedstawianie poświadczeo i stwierdzeo w sekcji Usługi uwierzytelniania i autoryzacji wcześniej w tym dokumencie). Czas odpowiedzi na pierwotne żądanie nie zależy wyłącznie od wydajności huba, ale także od dostępności i wydajności zewnętrznej usługi, z której korzysta hub. O ile w wielu przypadkach takie rozproszenie przetwarzania jest pożyteczne czy nawet nieodzowne, przed podjęciem decyzji o zastosowaniu takiego rozwiązania należy dokładnie rozważyd jego wpływ na wydajnośd systemu. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 112

113 Innym ważnym zagadnieniem, mającym wpływ na wydajnośd, jest wybór przetwarzania synchronicznego lub asynchronicznego. Chociaż usługi Web Service poprawnie obsługują oba typy wywołao, ogólnie zaleca się, by stosowanie wywołao synchronicznych (podobnych do wywołao RPC) ograniczyd jedynie do przypadków, w których są one absolutnie konieczne, a usługa docelowa potrafi zapewnid czas odpowiedzi na rozsądnym poziomie. Wysłanie wywołania synchronicznego do zewnętrznej usługi Web Service wstrzymuje przetwarzanie i powoduje zablokowanie zasobów we wszystkich węzłach biorących udział w obsłudze żądania. Jeśli czas odpowiedzi na wywołanie jest znaczny, nawet niewielka liczba jednoczesnych wywołao w trakcie realizacji może wyczerpad zasoby takie jak wątki czy pamięd operacyjna serwera wywołującego, czyli innymi słowy huba. Ma to także wpływ na ogólną wydajnośd systemu włącznie z zablokowaniem dostępu do wszystkich usług. Natomiast w przypadku wywołao asynchronicznych, operacja żądania kooczy się natychmiast po wysłaniu wywołania, po czym większośd zaalokowanych zasobów jest zwalniana. Przetwarzanie odpowiedzi na żądania realizowane jest niezależnie, w miarę jak napływają one z systemu zdalnego. Odszukanie odpowiadających im żądao nie wymaga przeprowadzania skomplikowanych operacji. Czas, jaki upływa pomiędzy wysłaniem żądania a uzyskaniem odpowiedzi, nie ma większego wpływu na ogólną wydajnośd huba, chod nadal ma duży wpływ na ogólny czas odpowiedzi dla pierwszego wywołania. Jak widad, przetwarzanie asynchroniczne pozwala uzyskad zwykle wyższą przepustowośd niż przetwarzanie synchroniczne i dlatego jest rozwiązaniem preferowanym. Asynchroniczny model komunikacji pozwala także na bardziej elastyczną obsługę nagłych wzrostów aktywności poprzez buforowanie żądao i przetwarzanie ich z taką szybkością, na jaką pozwala ogólna przepustowośd systemu. Buforowanie takie może byd realizowane niejawnie (platforma może je zapewniad w sposób przezroczysty dla usług) lub jawnie (poprzez implementację kolejkowania i mechanizmów zapamiętaj i wyślij). Tak długo, jak długo wszystkie zaległe żądania mogą zostad zapisane i następnie przetworzone w akceptowalnych ramach czasowych, model obsługi nie ulega zmianie, zapewniając oczekiwany poziom usług. Wywołania synchroniczne mają natomiast dużo mniejszą tolerancję na szczytowe obciążenia. System po osiągnięciu maksymalnej możliwej wydajności odrzuca dalsze żądania i muszą one zostad ponownie przesłane przez wywołujących. Szczegółowy opis przetwarzania synchronicznego i asynchronicznego znajduje się w temacie Komunikacja z systemami zaplecza w sekcji Integracja z usługami zaplecza wcześniej w tym dokumencie. Zarządzanie i eksploatacja Architektura i projekt dobrego rozwiązania dla sektora publicznego powinny uwzględniad specyficzne zagadnienia i wymagania związane z zarządzaniem systemem i jego eksploatacją. Usługi i procesy wspomagające operacje w środowisku IT stanowią podstawę zrozumienia możliwości i wymagao, jakie wiążą się z zarządzaniem usługami w organizacji. Kluczem do efektywnej architektury zarządzania jest integracja rozwiązao zarządzania usługami ze zintegrowanymi procesami operacyjnymi. Poprzez stosowanie wskazówek eksploatacyjnych, określonych dla każdej usługi, oraz zintegrowanych usług zorientowanych na zarządzanie, architektura zarządzania stanowi podstawę zarządzania różnymi rozwiązaniami Microsoft wdrażanymi w ramach architektury dla sektora publicznego. Wprowadzenie Ta częśd platformy RISA oparta jest na rozwiązaniach Microsoft w zakresie zarządzania (Microsoft Solutions for Management MSM). MSM to połączenie rozwiązao automatyzacji, najlepszych praktyk oraz usług ułatwiających wdrażanie tych praktyk, ułatwiające osiągnięcie wysokiej sprawności operacyjnej, przekładającej się na wysoką jakośd obsługi (Quality of Service QoS), niezawodnośd, dostępnośd, bezpieczeostwo i niski całkowity koszt posiadania (TCO). RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 113

114 Wspomniane najlepsze praktyki MSM oparte są na strukturze Microsoft Operations Framework (MOF) ustrukturyzowanym, a jednocześnie elastycznym podejściu skoncentrowanym na ITIL. MOF obejmuje wskazówki na temat planowania, wdrażania i konserwacji procesów operacyjnych IT w ramach obsługi rozwiązao krytycznych dla działania organizacji. Zasadniczymi elementami MOF (i najważniejszymi, wymaganymi do zrozumienia struktury tego przewodnika) są model procesu i model zespołu. Model procesu i podległe mu funkcje zarządzania usługami (Service Management Functions SMF) są podstawą metody opartej na procesach, zalecanej w tym przewodniku do celów konserwacji rozwiązania. Model zespołu i jego zbiory ról oferują pomoc w zakresie przypisania właściwych pracowników do poszczególnych ról. Na ilustracji 36. przedstawiono model procesowy MOF oraz funkcje SMF składające się na każdą fazę modelu procesu (przedstawioną w postaci dwiartki koła). Ilustracja 36. Model procesu MOF oraz funkcje zarządzania usługami (SMF) Na ilustracji 37. przedstawiono model zespołowy MOF wraz z wybranymi rolami funkcjonalnymi lub zespołami funkcyjnymi, jakie mogą istnied w strukturach zarządzania usługami. Role i funkcje przedstawiono w powiązaniu z zestawami ról MOF, do których mogą należed. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 114

115 Ilustracja 37. Model zespołowy MOF oraz przykłady ról funkcjonalnych lub zespołów Architektura zarządzania Wprowadzenie Wiele organizacji przekonało się, że funkcje IT powinny byd traktowane jako usługa świadczona na rzecz organizacji. Przekonanie to nakłoniło organizacje do skoncentrowania zasobów w celu utworzenia specyficznych zasobów, takich jak bazy danych, usługi komunikacyjne i katalogowe, eksploatowanych zgodnie ze zdefiniowanymi celami pozostającymi w zgodzie z misją firmy. Gdy organizacja decyduje się na postępowanie według zasad określonych w ITIL, działy techniczne stają się odpowiedzialne za negocjowanie i realizowanie celów zgodnych z polityką firmy. Podstawą realizacji tych celów są umowy poziomu usługi (Service Level Agreements SLA). Umowy te dotyczą także innych warunków, takich jak zapewnienie odpowiedniej obsługi, wydajności czy planowania pojemności systemu. Wszystkie te warunki wypełniane są z wykorzystaniem usług operacyjnych, narzędzi zarządzania i interfejsów zorientowanych na eksploatację usług. Centralizacja zasobów służących zarządzaniu sieciami i aplikacjami oraz rozwijanie umiejętności i procesów wykraczających poza organizacyjne granice IT to działania postrzegane jako środki umożliwiające działom IT realizację celów określonych w umowach SLA z jednoczesną kontrolą wydatków lub ograniczaniem kosztów. Funkcje zarządzania często definiowane są w ramach obszarów funkcjonalnych dotyczących bezpieczeostwa, wydajności, monitorowania pracy systemu, zarządzania składowaniem danych i odtwarzaniem danych czy zarządzania sieciami. Zagadnienia projektowe Zadaniem zespołów operacyjnych IT jest zapewnienie wysokiego poziomu jakości obsługi (Quality of Service QoS) przy utrzymaniu kosztów na rozsądnym poziomie. QoS nie jest wartością absolutną. Określając wymagania (i metryki) QoS, a także strukturę kosztów niezbędnych do RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 115

116 zapewnienia QoS, należy posłużyd się odpowiednimi analizami i zdrowym rozsądkiem. Ogólnie rzecz biorąc, im wyższy wymagany poziom QoS, tym wyższe koszty jego zapewnienia. Istnieje wiele (często wzajemnie sprzecznych) wymagao i zagadnieo projektowych, które trzeba przeanalizowad podczas budowania architektury zarządzania systemem. Korzyści wynikające z zastosowania zunifikowanego zestawu narzędzi, aktywnego monitorowania, utrzymania wysokiej dostępności muszą zostad szczegółowo przeanalizowane w odniesieniu do wszelkich czynników mających wpływ na środowisko. Należy wybrad wymagania i dopasowad je do potrzeb projektu. Z poszczególnymi wymaganiami związane są wymogi w zakresie specjalistycznej wiedzy, interoperacyjności, wspieralności oraz inne ukryte koszty związane z rozwiązaniami. Ważnym aspektem związanym z obniżaniem TCO (zarówno sprzętu, jak i oprogramowania) jest utworzenie standardowego, jednolitego zestawu narzędzi spełniających potrzeby działu IT i cele biznesowe. Wspólny zestaw narzędzi pozwoli zmniejszyd koszt związany z utrzymaniem specjalistycznej wiedzy lub personelu potrafiącego posługiwad się danym narzędziem lub wyposażeniem. Wdrożenie architektury zarządzania do monitorowania sieci i zapobiegania problemom jest często ważnym celem, definiowanym w czasie rozważania problemów implementacyjnych związanych ze spełnieniem założonych poziomów SLA. Proaktywne monitorowanie sieci, rejestrowanie awarii i ograniczenie czasu przestojów pozwala zwiększyd efektywnośd operacyjną, uzyskad lepszy poziom obsługi i zmniejszyd koszty. Scentralizowanie danych ułatwia na przykład wyznaczenie średniego czasu pomiędzy awariami (mean time between failures MTBF) dla różnych rodzajów sprzętu. Uzyskane informacje można wykorzystad do tworzenia dokładniejszych prognoz zapotrzebowania na sprzęt. Dostępnośd danych, umożliwiających śledzenie statystyk wykorzystania sprzętu, może pomóc w identyfikowaniu charakterystycznych trendów na przykład wykazad, że produkt, który wydawał się dobrym zakupem, w rzeczywistości generuje duże koszty obsługi i pomocy technicznej. W czasie budowy systemu warto zaprojektowad architekturę zarządzania tak, by zagwarantowad wysoką dostępnośd zarówno narzędzi zarządzania, jak i niezbędnych danych. Można to osiągnąd stosując redundancję. Można ją uzyskad stosując klastry serwerów lub inne techniki umożliwiające pracę pomimo awarii. W przypadku organizacji posiadających odległe biura należy zadbad o zapasowe połączenia sieciowe z centralą. Podjęte działania umożliwią spełnienie wynegocjowanych i zatwierdzonych umowami SLA wymagao w zakresie dostępności usług i danych. Efektywna architektura zarządzania musi byd także skalowalna. Miara skalowalności określa, jak łatwo dany komputer, usługa lub aplikacja mogą zostad rozbudowane lub ograniczone przy zachowaniu takiego samego poziomu niezawodności i spełnieniu wymagao w zakresie wydajności. W miarę wzrostu liczby użytkowników konieczne jest zwiększanie liczby serwerów lub podnoszenie mocy operacyjnej istniejących serwerów tak, by rosnące obciążenie sytemu nie spowodowało jego przeciążenia. Można także zdecydowad się na podzielenie dużego systemu serwerowego na mniejsze, bardziej specjalizowane serwery. Kolejnym uwarunkowaniem jest sposób, w jaki dane i wiedza zebrane w czasie eksploatacji systemu IT i sieci są integrowane i udostępniane. Personel działu obsługi i pomocy technicznej powinien posiadad aktualną i dokładną bazę wiedzy, umożliwiającą spełnienie wymagao określonych w umowach SLA. Aby zmniejszyd złożonośd systemów raportowania i zminimalizowad duplikację raportów, można wdrożyd wspólną infrastrukturę raportowania. Dzięki takiej infrastrukturze kierownicy poszczególnych działów mają dostęp do danych, na podstawie których mogą tworzyd interesujące ich raporty. Natomiast użytkownicy mogą zarządzad zgłoszonymi przez siebie incydentami pomocy technicznej. Zalety architektury zarządzania Możliwośd korzystania z dobrze zaprojektowanej architektury zarządzania niesie ze sobą liczne korzyści. Oto niektóre z nich: - konsolidacja narzędzi opracowanie zestandaryzowanego, wszechstronnego zestawu narzędzi, spełniającego zarówno potrzeby działu IT, jak i wymagania biznesowe, umożliwia RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 116

117 pozbycie się zwielokrotnionych lub nieefektywnych narzędzi i w efekcie ułatwia zarządzanie TCO w organizacji; - zestaw narzędzi wdrożenie rodziny lub znanego zestawu narzędzi pozwala na pełne wykorzystanie poszczególnych narzędzi oraz zalet płynących z interoperacyjności tych narzędzi; - pojedyncza architektura zarządzania konstruowanie architektury z uwzględnieniem możliwych przyszłych zmian pozwala stworzyd system, który będzie można łatwo rozbudowad. Architektura taka jest bardziej elastyczna i może byd łatwo skalowana do wymagao biznesowych; - objęcie całej organizacji możliwośd przeglądania danych dotyczących zarządzania wszystkimi komputerami w organizacji pozwala szybciej poznad interesujące nas informacje i podnieśd poziom obsługi. Alternatywne rozwiązania, umożliwiające przeglądanie danych tylko z określonego punktu widzenia czy dotyczących tylko określonych urządzeo sprzętowych, zwykle powodują tworzenie odizolowanych wysp przeterminowanych danych; - elastyczna architektura szybko zmieniające się potrzeby biznesowe powodują koniecznośd wprowadzania zmian w modelu operacyjnym. Elastyczna architektura pozwala na szybkie i efektywne dostosowanie jej do odpowiedniego modelu scentralizowanego, rozproszonego lub współdzielonego; - zunifikowane funkcje raportowania i powiadamiania dostępnośd jednej standardowej struktury pozwala na tworzenie spójnych raportów i powiadomieo; - interoperacyjnośd ważną zaletą wdrożenia architektury zarządzania jest możliwośd stosowania narzędzi w połączeniu ze sobą lub włączenia do systemu dodatkowych narzędzi w razie takiej potrzeby. Gdy narzędzia mogą zostad zintegrowane w taki sposób, że zdarzenia i ostrzeżenia generowane przez system monitorowania są automatycznie widoczne w systemie zarządzania incydentami, dział IT może zapewnid dużo wyższy poziom obsługi. Struktura leżąca u podstaw architektury zarządzania Na każdą organizację składają się pracownicy (ludzie), zadania, które ci pracownicy wykonują (procesy) oraz narzędzia umożliwiające pracownikom wykonywanie swoich zadao (technologie). Połączenie wysiłków w celu osiągnięcia wspólnych celów obniżenia kosztów i uzyskania wyższych poziomów usługi wymaga współpracy ludzi, procesów i technologii. Ludzie Pracownicy jeden z najważniejszych elementów niezbędnych do osiągnięcia sukcesu zarządzają różnymi komponentami usług technicznych, wykonują procesy i świadczą usługi zarządzania obejmujące kilka domen technicznych, realizując wymagania określone w umowach poziomu operacyjnego (Operating Level Agreement OLA). Aby zarządzanie usługami było możliwe, w architekturze muszą istnied rola administracyjna i rola zarządzania usługami. Ludzie muszą znad wykorzystywane technologie oraz procedury operacyjne stosowania tych technologii. Strategie stosowania procesów operacyjnych oraz model zespołu, umożliwiający przeprowadzanie tych operacji, zostały zdefiniowane w ramach struktury Microsoft Operations Framework (MOF). Model zespołu MOF oparty jest na założeniu, że każda osoba w organizacji pełni jedną lub kilka ról operacyjnych. Role definiowane są w ramach zbiorów nazywanych zbiorami zawodów, które grupują funkcje robocze w ramach określonej roli zadania IT. Role zdefiniowane w ramach architektury ułatwiają identyfikowanie i wydzielanie funkcji administracyjnych dla każdej usługi. Zapewnia to lepszą kontrolę nad sposobem, w jaki prawa administracyjne są rozdzielone pomiędzy pracownikami operacyjnymi. Definicje ról są bardzo precyzyjne, co daje dużo lepsze bezpieczeostwo i rozdzielenie funkcji zarządzania dla każdej usługi. Więcej informacji na temat modelu zespołu MOF można znaleźd w dokumencie MOF Team Model for Operations dostępnym pod adresem RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 117

118 (dokument można także odnaleźd wpisując MOF Team Model for Operations w polu wyszukiwania w witrynie TechNet pod adresem Procesy W każdej organizacji występują jakieś praktyki operacyjne czy procesy. Procesy umożliwiają pracownikom realizowanie określonych zadao w spójny, powtarzalny sposób. W niektórych organizacjach procesy są bardzo sformalizowane, w innych mniej formalne. Wiele organizacji na całym świecie w zakresie implementacji własnych modeli operacyjnych opiera się na zasadach opisanych w powszechnie przyjętym branżowym standardzie definiowania praktyk operacyjnych standardzie ITIL (Information Technology Infrastructure Library). Więcej informacji na temat ITIL można znaleźd w witrynie Ponieważ koncepcje opisane w ITIL przeznaczone są do wykorzystania przez dowolne organizacje, konieczna jest adaptacja koncepcji opisanych w ITIL do praktyk stosowanych w danej firmie. W celu ułatwienia obsługi środowisk opartych na technologiach Microsoft, firma Microsoft utworzyła strukturę MOF, opartą na koncepcjach ITIL. Obie struktury definiują sformalizowane, ale jednocześnie elastyczne podejście. W MOF zawarto wskazówki dotyczące osób, procesów, technologii i problemów zarządzania występujących podczas eksploatacji złożonych, rozproszonych i heterogenicznych środowisk technicznych ze szczególnym uwzględnieniem środowisk opartych na technologiach Microsoft. Projekt architektury zarządzania w strukturze MOF oparty jest na modelu procesu MOF, na który składają się cztery fazy, reprezentowane w postaci kwadrantów: zmiany, operacje, wsparcie, optymalizacja. Z każdym z etapów związany jest określony cel, odpowiadający specyficznym aspektom cyklu życia rozwiązao IT. Z każdym z etapów skojarzone są także funkcje zarządzania usługami (Service Management Functions SMF). Na przykład z fazą zmian skojarzone są funkcje SMF zarządzania zmianami i zarządzania konfiguracją. Więcej informacji na temat typów zadao operacyjnych, wykonywanych w ramach poszczególnych funkcji SMF, można znaleźd w dokumencie MOF Process Model for Operations dostępnym pod adresem (dokument można także odnaleźd, wpisując MOF Process Model for Operations w polu wyszukiwania w witrynie TechNet pod adresem Metodologia MOF zaleca wykonywanie przeglądów (analiz), oceniających efektywnośd operacyjną poszczególnych etapów i związanych z nimi funkcji SMF. Po wykonaniu tych przeglądów (przegląd gotowości wydania, przegląd operacyjny, przegląd SLA, zatwierdzenie wydania), model procesu MOF zostaje zakooczony. Po ukooczeniu przeglądu zatwierdzenia wydania, plan operacyjny jest gotowy do wdrożenia w środowisku produkcyjnym. Tabela 1. Przegląd oraz zadnia obsługi związane z poszczególnymi etapami (kwadrantami) etap (kwadrant) zadania obsługi przegląd zmiany wprowadzanie nowych rozwiązao usługowych, technologii, systemów, aplikacji, sprzętu i procesów przegląd gotowości wydania operacje efektywna i wydajna realizacja codziennych zadao przegląd operacyjny wsparcie szybka obsługa incydentów, problemów, zapytao przegląd SLA (Service Level Agreement) optymalizacja wprowadzanie zmian w celu optymalizacji kosztów dostarczania usług IT oraz wydajności, maksymalnego obciążenia i dostępności tych usług zatwierdzenie wydania Technologia Wiele organizacji IT przyjęło model dostarczania usług dla swoich przedsiębiorstw, zamiast dostarczania narzędzi i technologii. Wartośd biznesowa oceniana jest na podstawie korzyści, jakie RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 118

119 przynosi zastosowanie danej technologii, a nie na podstawie samej technologii. W tabeli 2. wymieniono kilka przykładów usług architektury zarządzania MSM, które mogą pomóc w utworzeniu architektury technologii zarządzania. Więcej informacji na temat tych usług można znaleźd w sekcji Architektura zarządzania MSM. Tabela 2. Wartośd usług dla architektury technologii zarządzania nazwa usługi monitorowanie i kontrolowanie usług usługi katalogowe zarządzanie zmianami zarządzanie konfiguracją zarządzanie incydentami pełna biblioteka oprogramowania (Definitive Software Library DSL) wdrażanie uaktualnieo wdrażanie serwerów i stacji roboczych administracja zdalna technologie potrzebne do dostarczenia usługi monitorowanie i ostrzeganie, zarządzanie siecią, zarządzanie urządzeniami oprogramowanie serwera katalogowego baza danych zarządzania zmianami oprogramowanie do zarządzania systemem, technologie inspekcji zabezpieczeo i konfiguracji oprogramowanie do zarządzania biurem pomocy technicznej serwer plików z obsługą replikacji oprogramowanie do wdrażania uaktualnieo, łat i dodatków service pack oprogramowanie do tworzenia obrazów dysku i automatyzacji wdrażania oprogramowanie i narzędzia konsoli zdalnej służące do zdalnej administracji usługi zapewniane przez architekturę technologii zarządzania monitorowanie sieci, komputerów, urządzeo i aplikacji w sposób umożliwiający wzbudzanie alarmów i automatyczne reagowanie na zdarzenia; usługi te są nieodzowną częścią procesów śledzenia, powiadamiania i reagowania składowanie obiektów reprezentujących użytkowników, komputery i inne zasoby; zarządzanie uwierzytelnianiem i autoryzacją; replikacja i partycjonowanie danych w celu bezpiecznego udostępniania ich użytkownikom śledzenie zmian w kodzie oprogramowania, sprzęcie, procesach i urządzeniach; zagwarantowanie realizacji procesów wdrażania zmian dokumentacja zasad (polis) zarządzania konfiguracją, inspekcja konfiguracji systemu, zabezpieczeo i oprogramowania śledzenie incydentów (zgłoszeo problemów) od utworzenia po rozwiązanie; oprogramowanie do śledzenia problemów jest wykorzystywane głównie do zarządzania interakcjami pomiędzy służbami pomocy technicznej a klientem zapewnienie magazynu wykorzystywanego oprogramowania; biblioteka DSL zapewnia kontrolę wersji oraz funkcje dystrybucji oprogramowania w przedsiębiorstwie bieżąca aktualizacja komputerów i aplikacji; automatyzacja wdrażania uaktualnieo i utrzymywanie katalogu obowiązujących poziomów uaktualnieo wykorzystanie do wdrażania nowych serwerów i stacji roboczych; pomoc w automatyzacji i zapewnieniu spójności procesu budowy serwerów i stacji roboczych zapewnienie kontroli nad zarządzaniem systemem lub dostęp konsolowy do systemu w celach zdalnej administracji; obejmuje stosowanie narzędzi zarządzania bezpośredniego, takich jak konsola zarządzania Microsoft (Microsoft Management Console MMC) lub usług terminalowych na platformach Microsoft oraz awaryjnych środków zarządzania, takich jak karty (adaptery) zarządzania serwerem, gdy bezpośrednie zarządzanie nie jest możliwe RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 119

120 nazwa usługi debugowanie i klasyfikacja błędów (triage) technologie potrzebne do dostarczenia usługi oprogramowanie do debugowania i dodatkowe narzędzia usługi zapewniane przez architekturę technologii zarządzania stosowane do debugowania kodu i rozwiązywania problemów z komputerami i aplikacjami Logiczny układ architektury przedsiębiorstwa Opisana tu architektura zarządzania została oparta na architekturze Microsoft Systems Architecture (MSA). Istnieją trzy możliwe układy architektury przedsiębiorstwa: scentralizowany, rozproszony i współdzielony. Opcje te nie wykluczają się wzajemnie, a większośd organizacji korzysta z architektur będących połączeniem tych układów, co pozwala na dostosowanie architektury zarządzania do struktury organizacyjnej firmy. Scentralizowana architektura zarządzania Scentralizowana architektura zarządzania pozwala na zarządzanie systemem z jednej, centralnej lokalizacji. Układ ten charakteryzuje się największymi zaletami, ale nie jest wolny od wad. Według raportu META Group Centralizing the Command Center Function, scentralizowaną architekturę zarządzania w swych centrach dowodzenia stosuje obecnie 30 procent z 500 największych przedsiębiorstw z listy Global Więcej informacji dostępne jest w witrynie Zgodnie z tym raportem względy ekonomiczne przyspieszą opracowywanie i konsolidację narzędzi i grup operacyjnych do kooca 2006 roku scentralizowana architektura zarządzania będzie stosowana już w 60 procentach 500 największych firm. Schemat scentralizowanej architektury zarządzania przedstawiono na ilustracji 38. Ilustracja 38. Scentralizowana architektura zarządzania RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 120

121 Poza centralizacją fizyczną, architektura ta charakteryzuje się wysokim stopniem konsolidacji narzędzi, dzięki czemu poszczególne funkcje zarządzania mogą byd realizowane z wykorzystaniem mniejszej liczby narzędzi. Konsolidacja narzędzi pozwala na uzyskanie wysokiego stopnia scentralizowanej kontroli nad takimi usługami IT, jak zarządzanie zmianami, zarządzanie wydaniami, zarządzanie biurem obsługi technicznej, zarządzanie incydentami, metryki raportowania, zarządzanie składowaniem danych. Aby możliwe było zredukowanie liczby narzędzi, konieczne jest wdrożenie technik zapewniających obsługę istniejących, zróżnicowanych platform sprzętowych i programowych. Powodzenie konsolidacji narzędzi zależy od tego, czy skalowalnośd wybranych narzędzi jest na tyle duża, by nadążyd za wzrostem rozmiarów i złożoności systemu przy jednoczesnym wsparciu scentralizowanego model zarządzania. Scentralizowana architektura zarządzania pozwala organizacji IT skupid umiejętności, możliwości reakcji i zasoby w wysoko wyspecjalizowanych centrach operacyjnych. Centra te nazywane są wzorcowymi centrami dowodzenia (command centers of excellence C-COE) i stanowią połączenie centrów zarządzania siecią (network operations center NOC) i centrów zarządzania systemami (systems operations center SOC). Model scentralizowany posiada i zalety, i wady. Wady nadal są problematyczne dla osób podejmujących decyzję i były powodem opóźnienia popularyzacji tego modelu w środowiskach IT. Mimo to, branża zaczyna zdawad sobie sprawę z niebagatelnych zalet stosowania wszechstronnych i scentralizowanych narzędzi zarządzających. Zalety Model scentralizowany charakteryzuje się następującymi zaletami: - wszystkie dane operacyjne oraz informacje dotyczące stanu usług widoczne są w jednym miejscu za pośrednictwem scentralizowanych konsol zarządzania i systemu raportowania, - sposób podejmowania decyzji jest spójny dla całego przedsiębiorstwa, - istnieje możliwośd opracowania i dotrzymania warunków SLA dla usług zapewnianych przez całą organizację, - istnieje możliwośd oszacowania ryzyka operacyjnego na poziomie całej organizacji i zarządzanie nim, - konsolidacja narzędzi zarządzania oraz personelu obsługi technicznej centrów operacyjnych pozwala na obniżenie kosztów utrzymania. Wady Model scentralizowany charakteryzuje się następującymi wadami: - wiele usług świadczonych przez organizację pochodzi od różnych producentów. Może to powodowad problemy ze współpracą narzędzi zarządzania z technologiami wykorzystywanymi do świadczenia usług, - chociaż usługi takie jak monitowanie usług można łatwo scentralizowad, szybka reakcja personelu lokalnego na ewentualne problemy wymaga uruchomienia centralnego procesu zarządzania incydentami, - ugrupowania polityczne i związki zawodowe w organizacji będą przeciwne zmianom ze względu na awersję do zmian oraz utratę autonomii poszczególnych domen. Lokalny personel wsparcia technicznego woli mied pełną kontrolę nad swoim regionem i stawia opór przed wprowadzeniem procesów sterowanych centralnie, - architektura zarządzania nie jest odporna na awarie i w niektórych ważnych sytuacjach może stad się niedostępna. Rozproszona architektura zarządzania Głównym czynnikiem sprzyjającym wdrażaniu rozproszonych architektur zarządzania jest silna rejonizacja organizacji. Przykład takiej architektury przedstawiono na ilustracji 39. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 121

122 Ilustracja 39. Rozproszona architektura zarządzania W modelu tym wstępują takie same usługi, jak w modelu scentralizowanym. Różnica polega na poziomie konsolidacji systemu zarządzania w organizacji. W przypadku modelu rozproszonego, oddziały organizacji lub geograficznie rozproszone jednostki biznesowe utrzymują usługi i procesy zarządzania w ramach własnych granic. Model ten odpowiada sytuacji obecnej większośd organizacji nadal posiada rozproszone architektury zarządzania. Na ilustracji 39. każdy z wydzielonych obszarów organizacyjnych ma podobne potrzeby w zakresie zarządzania, w związku z tym każdy z nich korzysta z podobnych usług zarządzania siecią, zarządzania serwerami i zarządzania klientami. Zalety Model rozproszony charakteryzuje się następującymi zaletami: - odwzorowuje istniejące podziały organizacyjne, - poszczególne grupy operacyjne mają wolną rękę w zarządzaniu własnymi środowiskami, - architektura ta jest mniej podatna na awarie infrastruktury sieciowej i telekomunikacyjnej, które mogą byd poważnym utrudnieniem w przypadku stosowania scentralizowanej architektury zarządzania, - poszczególne jednostki biznesowe mogą opracowywad i wdrażad własne procedury operacyjne, procesy i technologie, - implementacje najlepszych w branży rozwiązao dla komputerów i użytkowników obsługiwanych przez daną jednostkę biznesową są mniej skomplikowane, - bariery pomiędzy zespołami zarządzania w wysoce niezależnych jednostkach biznesowych mogą ułatwid utrzymanie izolacji i bezpieczeostwa szczególnie chronionych obszarów organizacji, - większa niezależnośd usług zarządzania niż w przypadku pojedynczego centrum C-COE ze względu na redundancję centrów operacyjnych, - operacje mogą byd konsolidowane lub przenoszone pomiędzy jednostkami organizacyjnymi, - daje większą elastycznośd we wdrażaniu strategii zarządzania follow the Sun funkcje zarządzania mogą byd rozproszone między centra operacyjne znajdujące się w różnych lokalizacjach geograficznych, funkcjonujące w standardowych godzinach roboczych. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 122

123 Wady Model rozproszony charakteryzuje się następującymi wadami: - rozproszenie składnic danych i narzędzi zarządzania utrudnia ocenę ogólnego poziomu obsługi (QoS) na poziomie całego przedsiębiorstwa, - trudności w ocenie QoS powodują, że definiowanie i dotrzymywanie poziomu SLA także jest utrudnione, - definiowanie i realizowanie jednolitych dla całej organizacji procesów i procedur operacyjnych jest trudniejsze, - występują tendencje do mnożenia narzędzi i usług, których nie da się łatwo zintegrowad. Współdzielona architektura zarządzania Podstawą współdzielonej architektury zarządzania jest elastycznośd w zakresie różnych opcji zarządzania. Przykład współdzielonej architektury zarządzania przedstawiono na ilustracji 40. Ilustracja 40. Współdzielona architektura zarządzania W przypadku współdzielonej architektury zarządzania, lokalna usługa zarządzania lub usługa związana z określonym produktem może opierad się na innej usłudze zarządzania i przekazywad do niej zdarzenia i alarmy. Lokalne rozwiązanie monitorowania może na przykład rejestrowad zdarzenia i alarmy generowane przez urządzenia sieciowe, a następnie przekazywad je do aplikacji zarządzającej służącej do konsolidacji. Zalety Model współdzielony charakteryzuje się następującymi zaletami: - całkowicie niezależna jednostka biznesowa może znacznie ograniczyd koszty utrzymania IT, współdzieląc częśd architektury zarządzania z inną jednostką biznesową, - niektóre sytuacje mogą wymagad stosowania unikalnych narzędzi i nietypowej wiedzy, - możliwośd ograniczenia kosztów poprzez współdzielenie części firmowej architektury zarządzania. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 123

124 Wady Model współdzielony charakteryzuje się następującymi wadami: - koniecznośd utrzymania części usług i procesów jako niezależnych elementów, - do utrzymania spójności narzędzi zarządzania i całego procesu konieczne jest wdrożenie mechanizmu zatwierdzania, - brak zalet ekonomii skali, które możliwe są wyłącznie w przypadku zarządzania scentralizowanego. Niezależnie od tego, która architektura zarządzania zostanie wybrana, konieczne jest przemyślenie kilku kluczowych zagadnieo związanych z konsolidacją narzędzi, bezpieczeostwem, skalowalnością i dostępnością. Architektura zarządzania MSM Kluczem do silnej infrastruktury zarządzania jest zaprojektowanie i wdrożenie architektury zarządzania dopasowanej do potrzeb zarządzanego środowiska. Podczas projektowania infrastruktury zarządzania trzeba uwzględnid wiele czynników. Na koocowy kształt infrastruktury wpływ mają wybór odpowiedniego modelu zarządzania (scentralizowanego lub zdecentralizowanego), liczba obsługiwanych lokalizacji i serwerów, szybkośd połączeo pomiędzy lokalizacjami oraz potrzeby i względy biznesowe. W tej sekcji wskazano najlepsze praktyki projektowania architektury dla różnych, przydatnych w środowisku IT, technologii i produktów Microsoft. Opisano tu różne usługi architektury zarządzania MSM, które mogą stanowid podstawę dla architektury technologii zarządzania na przykład monitorowanie i kontrola usług, będące kluczowymi komponentami architektury zarządzania. Architektura zarządzania MSM składa się z trzech poziomów: dolnego poziomu zarządzanych węzłów, średniego poziomu narzędzi zarządzania i raportowania oraz najwyższego poziomu narzędzi zarządzania i raportowania. Ilustracja 41. Trzy poziomy architektury zarządzania MSM RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 124

125 Monitorowanie i kontrola usług Monitorowanie i kontrola usług to najważniejszy komponent architektury zarządzania. Jego zadaniem jest monitorowanie wszystkich aspektów stanu usług IT w celu wykrywania problemów i zapobiegania im oraz gromadzenia danych wykorzystywanych przez inne funkcje SMF do optymalizacji świadczonych usług IT. We wszystkich organizacjach wykorzystujących w swym działaniu usługi IT występują awarie, które potencjalnie mogą zakłócid normalną działalnośd firmy. Dział IT jest odpowiedzialny za zapewnienie dostępności infrastruktury IT, udostępniającej usługi biznesowe oraz inne oparte na niej usługi zgodnie z warunkami opisanymi w SLA. Ponieważ działalnośd organizacji w coraz większym stopniu zależy od infrastruktury IT, możliwośd przewidywania problemów oraz szybkiego i efektywnego reagowania na problemy jest warunkiem koniecznym świadczenia usług IT. Dzięki wdrożeniu monitorowania usług i procesów kontroli, dział IT może stale monitorowad stan usług i reagowad na potencjalne lub rzeczywiste sytuacje awaryjne natychmiast w momencie ich pojawienia się i dzięki temu minimalizowad negatywny wpływ na działalnośd firmy. Samo monitorowanie, bez możliwości kontrolowania, a przynajmniej powiadamiania o wystąpieniu określonych typów zdarzeo i konieczności reakcji, nie jest zbyt wartościowe. Kontrolowanie może odbywad się na zasadzie reakcji (po zajściu określonego zdarzenia) lub prewencji (unikanie przestojów jeszcze zanim pojawią się problemy). System monitorowania i kontrolowania usług gromadzi dane wykorzystywane przez funkcje SMF do optymalizacji wydajności usług IT i zapobiegania przestojom i udostępnia te dane innym funkcjom SMF, co pozwala im reaktywnie i proaktywnie robid to samo. Aby osiągnąd te cele, architektura zarządzania raportuje najważniejsze dane dotyczące komponentów, usług i trendów wydajności, na podstawie których można automatycznie wyzwalad reguły i działania. Usługi monitorowania i kontrolowania usług, umożliwiając monitorowanie wszystkich aspektów działania usług, wspierają usługi IT w zakresie zapewnienia wynegocjowanego poziomu SLA i spełnienia innych udokumentowanych lub umownych wymagao biznesowych. Monitorowanie dotyczy także dotrzymania umów poziomu operacyjnego (Operating Level Agreement OLA) oraz kontraktów z firmami trzecimi, od których zależy dotrzymanie wynegocjowanych poziomów SLA. Każdy proces w ramach MOF jest w pewnym stopniu wspierany przez funkcje monitorowania i kontrolowania usług funkcje te są niezbędne do stałego ulepszania procesów. Jest to szczególnie widoczne w przypadku fazy operacyjnej modelu procesu MOF, w której poszczególne SMF są ze sobą ściśle powiązane. Narzędzia administracyjne W tej sekcji zawarto informacje na temat przykładowych narzędzi administracyjnych przydanych w zarządzaniu serwerami. Microsoft System Center Cechy i funkcje monitorowania Niektóre z cech System Center Operations Manager to: - bezpieczeostwo, - szybkośd i łatwośd wdrożenia, - małe wykorzystanie przepustowości sieci, - dobre funkcje diagnostyki problemów, - dostęp do dużej ilości danych oraz możliwośd filtrowania danych, - elastyczne, sprawne i bezpieczne funkcje raportowania, - wysoka dostępnośd, - dobra skalowalnośd, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 125

126 - wysoki stopieo integracji. Monitorowanie poziomu usługi (Service Level Agreement SLA) za pomocą System Center Operations Manager System Center Operations Manager (SCOM) oferuje także pewne funkcje monitorowania poziomu SLA. Wiążąc zdarzenia i ich ważnośd z czasami odpowiedzi SLA i stanem zdarzeo, operatorzy SCOM mogą wskazad te problemy, których rozwiązanie jest najbardziej pilne i określid czas, w jakim problemy te muszą zostad rozwiązane, by utrzymad warunki określone w SLA. Proces ten może byd także objęty raportowaniem, co pozwala na analizowanie sposobu obsługi poszczególnych zdarzeo oraz sprawdzanie, czy obsługa ta mieści się w ramach warunków SLA skonfigurowanych w SCOM. SCOM umożliwia oddziałom IT mierzenie i monitorowanie efektywności działania, ułatwiając tym samym spełnienie warunków SLA. Co więcej, zarejestrowane zdarzenia mogą byd łatwo przekazywane (eskalowane) do analizy na wyższych stopniach odpowiedzialności. Zarządzanie uaktualnieniami Windows Server Update Service (WSUS) Osoby zarządzające zasobami serwerowymi muszą stale dbad, by na serwerach, którymi się opiekują, były regularnie instalowane najnowsze łaty oprogramowania i uaktualniania zabezpieczeo, w tym niezbędne poprawki hotfix i dodatki service pack. Idealnym rozwiązaniem, umożliwiającym spełnienie tych wymagao, jest nowe narzędzie udostępnione przez Microsoft WSUS. Innym narzędziem o podobnej funkcjonalności jest System Center Configuration Manager 8, jednak jest on przeznaczony raczej do tworzenia korporacyjnych rozwiązao zarządzania stacjami roboczymi. Usługi WSUS zostały zaprojektowane specjalnie do obsługi serwerów w dużych przedsiębiorstwach. Z tego i innych względów zalecanym rozwiązaniem jest właśnie WSUS. Oto niektóre z zalet stosowania usług WSUS: - scentralizowana kontrola, - możliwośd generowania tygodniowych raportów, - elastyczne opcje konfiguracyjne. Wskazówki dotyczące konfiguracji Ze względu na specyficzną naturę rozwiązao dla sektora publicznego, struktura rozwiązania WSUS powinna byd relatywnie prosta (w porównaniu z potencjalnie złożonymi środowiskami, którymi usługi te mogą zarządzad). Dzięki definicjom grup komputerów, usługi WSUS umożliwiają administratorom kierowanie określonych rodzajów uaktualnieo do określonych serwerów. Automatyzacja pobierania uaktualnieo sprawia, że proces ich instalowania jest bardziej wydajny. Ilustracja 42. Stosowanie usług Windows Server Update Service (WSUS) 8 RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 126

127 Interoperacyjnośd Ze względu na naturę i różnorodnośd systemów i aplikacji wykorzystywanych w środowiskach IT, często potrzebne jest wdrożenie systemu lub rozwiązania zarządzania zapewniającego obsługę środowisk heterogenicznych. System System Center Operations Manager może współpracowad z innymi systemami i platformami zarządzania za pośrednictwem struktury Microsoft Connector Framework (MCF). Struktura ta wprowadza obiekt zwany konektorem, który jest łącznikiem pomiędzy strukturą MCF a innym systemem lub aplikacją. Konektor pozwala na dwustronne przekazywanie alarmów i biletów obsługi. Większośd konektorów umożliwiających współpracę SCOM z innymi systemami została przygotowana przez niezależnych producentów oprogramowania, w związku z czym korzystanie z takiego konektora może wiązad się z koniecznością poniesienia dodatkowych kosztów. Możliwe jest opracowanie własnego konektora z wykorzystaniem pakietu SCOM SDK 9, który pozwala na programistyczny dostęp do biblioteki klas SCOM (SCOM Class Library). Możliwośd tworzenia własnych konektorów pozwala na integrację SCOM z dowolną istniejącą aplikacją lub systemem. Dodatkowe zasoby - Management Architecture Guide: Version mspx - Microsoft Operations Framework (MOF) - Introduction to Infrastructure Management Services Services/default.mspx - Platform Manageability Best Practices ractices.mspx - IT Infrastructure Library (ITIL) RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 127

128 Elementy składowe typowego rozwiązania integracyjnego dla sektora publicznego Wprowadzenie Elementy składowe są referencyjnymi implementacjami podsystemów lub fragmentów architektury referencyjnej, przygotowanymi w celu objaśnienia określonych aspektów projektu i zilustrowania użycia technologii Microsoft w określonych zastosowaniach. Elementy składowe to nadające się do wielokrotnego wykorzystania projekty podsystemów będących rozwiązaniami określonych zagadnieo technicznych spotykanych często w scenariuszach użycia. Wiele z nich zawiera przetestowane implementacje referencyjne, które pozwalają na znaczne skrócenie czasu opracowywania systemu. Zakres i zasięg przykładowych implementacji elementów składowych będą stale powiększane w miarę zdobywania nowych doświadczeo w realizacji rozwiązao dla sektora publicznego i rozwoju nowych technologii. Tworzone przez partnerów i klientów elementy składowe można podzielid na następujące kategorie: - zarządzanie tożsamością i dostępem, - komunikacja i usługi sieciowe (Web Service), - orkiestracja procesów, - integracja, - zarządzanie, - architektura biznesowa. W tej sekcji zamieszczono szczegółowy techniczny opis projektu i budowy poszczególnych składników rozwiązania. Obecnie sekcja ta zawiera opisy następujących elementów składowych: zarządzanie tożsamością przykład implementacji usługi uwierzytelniania i autoryzacji z zastosowaniem usług sieciowych Web Service, hub komunikacyjny odpowiedzialny za bezpieczną i niezawodną wymianę dokumentów elektronicznych pomiędzy wieloma punktami koocowymi, hub integracyjny obsługujący transformowanie i przesyłanie dokumentów XML pomiędzy jednostkami administracji publicznej i hubem komunikacyjnym; zadaniami huba są także rejestrowanie historii transakcji i raportowanie awarii, podpisy elektroniczne i certyfikaty wykorzystanie podpisów elektronicznych XML do uwierzytelniania komunikatów XML i ich nadawców, opis metod elektronicznego podpisywania dokumentów XML, weryfikowania podpisów i stosowania certyfikatów. Zarządzanie tożsamością Zarządzanie tożsamością to jeden z podstawowych składników każdego projektu integracyjnego dla sektora publicznego. Z projektami tego typu wiąże się wiele zagadnieo dotyczących zarządzania tożsamością: Projekty te zwykle integrują wiele istniejących, zróżnicowanych rozwiązao, a każde z nich korzysta z innego mechanizmu uwierzytelniania. Wymiana wszystkich istniejących rozwiązao zwykle nie jest możliwa. Do rozwiązania będzie miało dostęp wiele agencji i wiele typów klientów, co oznacza, że rozwiązanie to będzie musiało obsłużyd użytkowników z różnych obszarów, uwierzytelnianych za pomocą różnych mechanizmów. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 128

129 System uprawnieo dla użytkowników w takim środowisku jest dośd skomplikowany i trudno zastosowad tu model spotykany zwykle w większości aplikacji (np. zastosowanie znanego z Microsoft Windows standardowego modelu z kontami użytkowników, grupami i listami ACL nie jest możliwe). Do obsługi takich zastosowao służy specjalna usługa uwierzytelniania i autoryzacji (U&A). Usługa ta implementowana jest jako usługa sieciowa (Web Service) i pełni wiele ważnych funkcji. Jej funkcjonalnośd to między innymi: Uwierzytelnianie klientów np. w portalu internetowym, za pośrednictwem którego użytkownicy korzystają z rozwiązania. Autoryzowanie klientów portal internetowy pyta usługę U&A o to, czy określony użytkownik ma prawo skorzystad z określonej usługi, o listę usług, w których dany użytkownik się zarejestrował lub o uprawnienia, jakie musi posiadad określony użytkownik, by móc uzyskad dostęp do systemu zintegrowanego z naszym rozwiązaniem. Uwierzytelnianie i autoryzacja wewnętrznych składników rozwiązania. Identyfikacja i rejestracja klientów (np. klient rejestruje się w określonej usłudze za pośrednictwem portalu internetowego). Proces rejestracji może wymagad dodatkowej weryfikacji użytkownika. Po zweryfikowaniu użytkownika, usługa U&A dostarcza użytkownikowi zestaw identyfikatorów umożliwiających dostęp do usługi. Dostęp do usługi uwierzytelniania i autoryzacji mają wszystkie inne składniki rozwiązania. Usługa ta zwykle udostępnia interfejs publiczny, dostępny dla klientów zewnętrznych, i interfejs prywatny, dostępny dla klientów wewnętrznych. W kolejnych sekcjach opisano sposób obsługi przez tę usługę różnych zastosowao, typowych dla rozwiązao integracyjnych dla sektora publicznego. Uwierzytelnianie Uwierzytelnianie to proces polegający na ustaleniu tożsamości użytkownika, który chce skorzystad z rozwiązania. Uwierzytelnienie dostępu do firmowej sieci komputerowej może zależed na przykład od podania nazwy użytkownika i hasła, a uwierzytelnienie dostępu do budynku od posiadania karty RFID (Radio Frequency Identity). Istnieje wiele różnych mechanizmów umożliwiających uwierzytelnienie użytkownika. Przykłady mechanizmów uwierzytelniania to: domena Active Directory, lokalna baza użytkowników w systemie Windows (bez domeny), karty inteligentne (smartcard) do logowania do systemu Windows, certyfikaty klienta SSL do logowania do zabezpieczonej witryny internetowej, mechanizm logowania do bezpiecznej powłoki systemu z wykorzystaniem protokołu SSH. Możliwe jest też stosowanie kombinacji różnych mechanizmów uwierzytelniania. Przy tak dużej różnorodności dostępnych technik nic dziwnego, że w rozwiązaniach heterogenicznych uwierzytelnianie jest jednym z największych problemów. Z uwierzytelnianiem związane są także dwa inne zagadnienia: Użytkownik, korzystając z wielu usług, powinien mied możliwośd używania jednego konta użytkownika pojedyncza nazwa użytkownika i hasło powinny zapewniad dostęp do wielu usług. Komponent uwierzytelniania powinien umożliwiad powiązanie pojedynczej nazwy użytkownika z różnymi poświadczeniami tożsamości, niezbędnymi do dostępu do systemów zintegrowanych z rozwiązaniem. Zatem gdy użytkownik ma meldowad się do systemu z użyciem pojedynczej nazwy użytkownika i hasła, musi istnied sposób pobrania poświadczeo dla wszystkich usług, z których użytkownik ten ma korzystad. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 129

130 Bilety uwierzytelnienia Pierwsze zagadnienie to sposób, w jaki usługa zapamiętuje uwierzytelnienie użytkownika po zalogowaniu tego użytkownika. Najczęściej spotykanym rozwiązaniem są bilety uwierzytelnienia. Słowo bilet przyjęto ze względu na podobieostwo do sytuacji ze świata rzeczywistego, w którym także często potrzebny jest pewien rodzaj uwierzytelnienia. Przykładem może byd kino najpierw kupujemy bilet, a później na podstawie tego biletu wchodzimy do kina (zwykle na określony czas i na określony film). Bilet jest dowodem, na którego podstawie ustalane jest prawo dostępu do kina. Taką samą metodę zastosowano w katalogu Active Directory. Serwer uwierzytelniający użytkownika wystawia bilet Kerberos, który następnie może zostad użyty do potwierdzenia uwierzytelnienia użytkownika. Stosowanie biletów nie wyklucza uwierzytelniania użytkowników na podstawie podpisu cyfrowego bilety są jedynie mechanizmem, dzięki któremu przez relatywnie krótki czas możliwe jest unikanie powtórnego uwierzytelniania użytkownika. Najważniejsze atrybuty zapisane w bilecie to: unikalny identyfikator użytkownika umożliwiający zlokalizowanie i załadowanie profilu użytkownika, czyli jego informacji osobistych i listy usług, w których ten użytkownik jest zarejestrowany, data i czas wystawienia biletu, dzięki którym możliwe jest ustalenie ważności biletu, data i czas wygaśnięcia biletu; atrybut ten może byd aktualizowany przez dostawcę uwierzytelniania w ramach tzw. opóźnionego wygasania (sliding expiration), typ biletu (jeśli w systemie stosowane są też bilety innego typu) w niektórych zaawansowanych rozwiązaniach stosowane są bilety różnych typów, na przykład posiadacz biletu głównego może żądad wydania biletów do innych usług, informacje o usłudze lub usługach, do których posiadacz biletu może uzyskad dostęp, lokalizacja użytkownika, np. nazwa komputera lub adres IP, podpis cyfrowy wygenerowany przez dostawcę uwierzytelniania, chroniący bilet przed nieuprawnioną modyfikacją; opcjonalnie bilet może byd także szyfrowany. Proces uwierzytelnienia Proces uwierzytelnienia użytkownika chcącego za pośrednictwem portalu internetowego uzyskad dostęp do usługi administracji publicznej przebiega następująco: użytkownik podaje swoje poświadczenia logowania w portalu internetowym; portal tworzy wiadomośd XML, zawierającą poświadczenia logowania użytkownika, i wysyła ją do dostawcy uwierzytelniania; dostawca uwierzytelniania sprawdza poświadczenia w odpowiedniej jednostce (katalogu Active Directory, bazie danych lub urzędzie certyfikatów); jeśli poświadczenia logowania są prawidłowe, dostawca uwierzytelniania generuje bilet i przesyła go do portalu internetowego; portal internetowy zapisuje bilet w sesji użytkownika, a następnie wykorzystuje go do dostępu do usługi docelowej i innych usług. Jak można się domyślid z tego opisu, do przeprowadzenia procesu uwierzytelnienia z wykorzystaniem biletu potrzebne jest kilka technik: metoda serializacji biletu do formatu XML; sposób elektronicznego podpisania dokumentu XML z biletem; sposób zamiany podpisanego elektronicznie dokumentu XML z powrotem na bilet; metoda walidacji biletu pod względem czasu wygasania, listy usług i innych atrybutów. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 130

131 Przykład prostej implementacji klasy biletu uwierzytelniającego, włącznie z metodami serializacji i ekstrakcji biletu z postaci XML, ale bez obsługi podpisów elektronicznych, przedstawiono poniżej: public class Ticket { #region Ticket data public string UserID; public DateTime IssueTime; public DateTime ExpireTime; public int TicketType; public ArrayList ServiceList; #endregion #region Serialization and signature public string GetSerializedTicket() { XmlSerializer serializer = new XmlSerializer(typeof(Ticket)); System.Text.StringBuilder serializedticket=new System.Text.StringBuilder(); System.IO.StringWriter sw=new System.IO.StringWriter(serializedTicket); serializer.serialize(sw, this); sw.close(); return serializedticket.tostring(); } #endregion #region Ticket creation public static Ticket CreateTicketFromXml(string xml) { XmlSerializer serializer = new XmlSerializer(typeof(Ticket)); System.IO.StringReader sw=new System.IO.StringReader(xml); Ticket t=(ticket)serializer.deserialize(sw); sw.close(); return t; } #endregion } Więcej informacji na temat elektronicznego podpisywania dokumentów XML i walidacji podpisów elektronicznych można znaleźd w opisie elementu składowego Wykorzystywanie dokumentu elektronicznego i podpisów elektronicznych dalej w tym dokumencie. Autoryzacja Po uwierzytelnieniu użytkownika następnym ważnym etapem jest ustalenie uprawnieo tego użytkownika. Uprawnienia określają, z których usług dany użytkownik może korzystad. Najniższym poziomem szczegółowości (granularity) jest usługa, co oznacza, że uprawnienia nadawane są wyłącznie na zasadzie może uzyskad dostęp albo nie może uzyskad dostępu. Jak widad, podstawowa funkcjonalnośd usługi autoryzacji to dostarczanie informacji o tym, czy dany użytkownik ma dostęp do określonej usługi. Istnieją jednak pewnie specyficzne zagadnienia związane z autoryzacją dostępu w projektach dla administracji. Najważniejsze z nich to delegacja jeden użytkownik może delegowad swoje RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 131

132 uprawnienia innemu użytkownikowi. Określone agencje mogą na przykład działad w imieniu obywateli, którzy nie mają komputera i dostępu do Internetu. Żona może reprezentowad męża. Istnieją także bardziej skomplikowane sytuacje użytkownik może na przykład upoważnid agencję do reprezentowania go tylko w jednej z usług, a agencja przekierowuje to upoważnienie na jednego ze swoich pracowników. Taki scenariusz wymaga specjalnego mechanizmu autoryzacji nie obsługuje go żaden ze standardowych systemów, takich jak Active Directory. Zwykle mechanizm autoryzacji, który obsługuje delegację, udostępnia tylko jedną metodę AuthorizeUser. Metoda ta przyjmuje jako parametry identyfikator użytkownika i referencję do usługi, do której użytkownik ten chce uzyskad dostęp. Czasami potrzebna jest jeszcze informacja, czy użytkownik próbuje uzyskad dostęp bezpośrednio (w swoim własnym imieniu), czy reprezentuje innego użytkownika na zasadzie delegacji uprawnieo. Na przykład, gdy Jan Kowalski, który pracuje w agencji, przesyła deklarację podatkową wypełnioną dla obywatela, parametry wejściowe metody będą wskazywały, że Jan Kowalski próbuje uzyskad dostęp do usługi DeklaracjaPodatkowa w imieniu agencji, która działa w imieniu określonego obywatela. Aby móc obsłużyd model delegowanych uprawnieo, usługa musi przechowywad informacje w bazie danych o strukturze takiej, jak przedstawiona na ilustracji 43. Ilustracja 43. Logiczny model bazy danych usługi uwierzytelniania i autoryzacji Użytkownicy rozwiązania mogą byd albo osobami fizycznymi, albo reprezentowad jakąś jednostkę prawną. Każdy użytkownik może mied różne relacje z innymi użytkownikami oraz rejestracje w usługach. Każda relacja określa konkretną usługę oraz typ relacji na przykład pracownikpracodawca, żona-mąż, obywatel-agencja. W tabeli Identifier dla każdej usługi, do której użytkownik ma prawo dostępu, zapisany jest zestaw poświadczeo umożliwiających dostęp do tej usługi. Poświadczenia te mogą byd różne dla różnych użytkowników. W związku z tym autoryzacja przebiega według następującego algorytmu: Jeśli użytkownik chce uzyskad bezpośredni dostęp do usługi, należy w tablicy Enrolment sprawdzid, czy użytkownik ten jest uprawniony do dostępu do tej usługi. Jeśli użytkownik chce uzyskad dostęp do usługi jako reprezentant innego użytkownika, należy przejrzed wszystkie relacje tego użytkownika zapisane w tablicy Relationships. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 132

133 Użytkownik może byd na przykład pracownikiem agencji i reprezentowad obywatela, który upoważnił agencję do reprezentowania go. Po odnalezieniu właściwej relacji należy sprawdzid, czy osoba reprezentowana przez użytkownika jest uprawniona do dostępu do tej usługi. Zapewnienie dostępu do usługi U&A za pośrednictwem interfejsu usług sieciowych Po przeanalizowaniu procesu uwierzytelniania i autoryzacji użytkowników, w tej sekcji zajmiemy się udostępnianiem funkcjonalności usługi U&A za pośrednictwem interfejsu usług sieciowych Web Service. Usługa U&A musi automatycznie zapisywad rejestracje użytkowników we wszystkich usługach rozwiązania. Z tego względu podstawowe operacje obsługiwane przez usługę U&A podzielono na dwie grupy interfejs publiczny i interfejs prywatny. Podstawowym kryterium podziału jest newralgicznośd tych operacji. Operacje należące do interfejsu publicznego mogą byd wykonywane przez większe grono użytkowników, po wcześniejszym uwierzytelnieniu i autoryzacji. Interfejs publiczny, dostępny dla portali internetowych i innych zewnętrznych komponentów systemu, korzystających z mechanizmów uwierzytelniania i autoryzacji zapewnianych przez usługę U&A, musi pozwalad na: rejestrację nowego użytkownika, sprawdzenie listy usług, w których dany użytkownik jest zarejestrowany, pobranie listy identyfikatorów dostępu do usług, w których dany użytkownik jest zarejestrowany, pobranie listy wszystkich usług, zmianę danych użytkownika, zmianę hasła lub certyfikatu używanego do logowania do systemu. Interfejs prywatny, dostępny wyłącznie dla huba komunikacyjnego i innych wewnętrznych komponentów systemu, musi pozwalad na: zmianę statusu rejestracji, zapisanie identyfikatora umożliwiającego użytkownikowi dostęp do usługi, utworzenie relacji pomiędzy dwoma użytkownikami, utworzenie nowej rejestracji użytkownika, określenie reprezentanta danego użytkownika. Wszystkie wymienione wyżej funkcje udostępniane są w postaci metod usług Web Service przyjmujących dokumenty XML jako parametry wejściowe. Na przykład lista usług zwrócona przez usługę U&A będzie miała następującą postad: <?xml version="1.0" encoding="utf-8"?> <ServiceAuthenticateList xmlns=" <Service> <ServiceName>MOSW1</ServiceName> <ServiceState>Active</ServiceState> <Identifiers> <Identifier IdentifierType="PostCode">TR5 7ZE</Identifier> <Identifier IdentifierType="NINO">3234KDDDF8</Identifier> </Identifiers> </Service> <Service> <ServiceName>MOSW2</ServiceName> <ServiceState>Active</ServiceState> RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 133

134 <Identifiers> <Identifier IdentifierType="IDNo">3940P2</Identifier> <Identifier IdentifierType="Shoesize">5</Identifier> </Identifiers> </Service> <Service> <ServiceName>ServiceFour</ServiceName> <ServiceState>Suspended</ServiceState> </Service> <Service> <ServiceName>ServiceFive</ServiceName> <ServiceState>HandedToAgent</ServiceState> </Service> <Service> <ServiceName>ServiceSix</ServiceName> <ServiceState>Enrolled</ServiceState> <ActivateAttemptsLeft>2</ActivateAttemptsLeft> </Service> </ServiceAuthenticateList> Schemat odpowiadający temu dokumentowi XML to: <?xml version="1.0" encoding="utf-8"?> <xsd:schema targetnamespace=" xmlns=" xmlns:xsd=" elementformdefault="qualified" attributeformdefault="unqualified" version="1.44" id="serviceauthenticatelist"> <xsd:annotation> <xsd:documentation>service Authenticate List Schema</xsd:documentation> </xsd:annotation> <xsd:element name="serviceauthenticatelist" type="serviceauthenticatelisttype" /> <xsd:complextype name="serviceauthenticatelisttype"> <xsd:sequence> <xsd:element name="service" type="servicetype" minoccurs="0" maxoccurs="unbounded" /> </xsd:sequence> </xsd:complextype> <xsd:complextype name="servicetype"> <xsd:sequence> <xsd:element name="servicename" minoccurs="1" maxoccurs="1"> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:maxlength value="50" /> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name="servicestate" type="servicestatetype" RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 134

135 minoccurs="1" maxoccurs="1" /> <xsd:element name="activateattemptsleft" type="xsd:nonnegativeinteger" minoccurs="0" maxoccurs="1" /> <xsd:element name="identifiers" type="identifierstype" minoccurs="0" maxoccurs="1" /> </xsd:sequence> </xsd:complextype> <xsd:simpletype name="servicestatetype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="notenrolled" /> <xsd:enumeration value="submitted" /> <xsd:enumeration value="enrolled" /> <xsd:enumeration value="active" /> <xsd:enumeration value="handedtoagent" /> <xsd:enumeration value="suspended" /> </xsd:restriction> </xsd:simpletype> <xsd:complextype name="identifierstype"> <xsd:sequence> <xsd:element name="identifier" type="identifiertype" minoccurs="1" maxoccurs="unbounded"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="identifiertype"> <xsd:simplecontent> <xsd:extension base="identifiervaluetype"> <xsd:attribute name="identifiertype" use="required"> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:maxlength value="40" /> </xsd:restriction> </xsd:simpletype> </xsd:attribute> </xsd:extension> </xsd:simplecontent> </xsd:complextype> <xsd:simpletype name="identifiervaluetype"> <xsd:restriction base="xsd:string"> <xsd:maxlength value="50" /> </xsd:restriction> </xsd:simpletype> </xsd:schema> Każdej z funkcji usługi U&A towarzyszy odpowiedni schemat XML określający wymagane parametry. Bezpieczeostwo interfejsu U&A Zarówno publiczny, jak i prywatny interfejs usługi U&A wymagają odpowiedniej ochrony przed dostępem osób nieupoważnionych. Ochronę taką można uzyskad na kilka sposobów: Zastosowanie standardowego szyfrowania SSL z wykorzystaniem certyfikatów klientów. Oznacza to, że każdy użytkownik, chcąc skorzystad z interfejsu, będzie musiał przedstawid prawidłowy certyfikat. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 135

136 Zastosowanie standardowego, podstawowego uwierzytelniania HTTP. Oznacza to, że każdy użytkownik interfejsu musi podad nazwę użytkownika i hasło. Zastosowanie komponentów Microsoft Web Service Enhancements (WSE), implementujących standardy WS-Security. Jest to najbardziej elastyczne rozwiązanie, ponieważ poziom bezpieczeostwa może byd konfigurowany za pomocą WS-Policies. Komponenty WSE dostępne są pod adresem Dobrą praktyką jest także wprowadzenie dodatkowych zabezpieczeo, takich jak inspekcja pomyślnych uwierzytelnieo i dalszych działao użytkowników. Inspekcja powinna obejmowad wszystkie operacje, włącznie z ich parametrami i kontekstem bezpieczeostwa (poświadczeniami podanymi przez użytkownika). Hub komunikacyjny Hub komunikacyjny to element składowy odpowiedzialny za bezpieczne i niezawodne przesyłanie dokumentów elektronicznych pomiędzy wieloma punktami koocowymi. W przypadku rozwiązao dla sektora publicznego element ten obsługuję transakcje C2G i B2G oraz stanowi przyjazną platformę wymiany komunikatów elektronicznych pomiędzy różnymi jednostkami. W tej sekcji omówiono różne aspekty projektu huba komunikacyjnego funkcjonalnośd, główne komponenty i występujące między nimi zależności oraz zagadnienia związane ze skalowalnością i bezpieczeostwem. Funkcje Hub komunikacyjny zapewnia następującą funkcjonalnośd: przyjmowanie dokumentów GovTalk z różnych źródeł hub komunikacyjny udostępnia usługę Web Service, za pośrednictwem której aplikacja kliencka (na przykład portal internetowy) może przesład dokument, sprawdzid jego status i pobrad odpowiedzi od urzędu; walidacja dokumentów rozmiar dokumentu musi mieścid się w określonych limitach, a koperta musi byd zgodna ze schematem GovTalk; uwierzytelnianie nadawcy i autoryzacja transakcji hub komunikacyjny pobiera określone dane z koperty GovTalk i przekazuje je usłudze uwierzytelniania i autoryzacji (U&A) celem walidacji; routing i dostarczanie dokumentów do odpowiednich urzędów hub komunikacyjny przechowuje adresy punktów koocowych agencji i realizuje routing na podstawie zawartości komunikatów; pobieranie odpowiedzi od jednostek administracji publicznej odpowiedź zostaje zapisana tymczasowo i jest przechowywana do następnego cyklu sprawdzania odpowiedzi przez aplikację kliencką; dostarczanie odpowiedzi do aplikacji klienckiej hub komunikacyjny może dostarczyd odpowiedź bezpośrednio, jeśli aplikacja zażyczyła sobie tego podczas inicjacji komunikacji. Projekt W hubie komunikacyjnym można wyróżnid następujące podsystemy: czołowa usługa sieciowa (Front End Web Service FEWS), będąca interfejsem dla klientów zewnętrznych, podsystem komunikacyjny BizTalk (BizTalk Messaging Subsystem BMS), obsługujący inteligentne odbieranie, routing i dostarczanie dokumentów do i od jednostek administracji publicznej, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 136

137 podsystem bazodanowy (TrackingDB i AuditDB) przechowujący metadane na temat transakcji, informacje inspekcji i odpowiedzi od jednostek administracji publicznej. Poszczególne podsystemy i związki między nimi przedstawiono na ilustracji 44. Ilustracja 44. Główne podsystemy huba komunikacyjnego Czołowa usługa sieciowa Czołowa usługa sieciowa (Front-End Web Service FEWS) udostępnia interfejs do przekazywania dokumentów elektronicznych. Interfejs ten przeznaczony jest dla klientów zewnętrznych, takich jak portale internetowe i aplikacje ISV. Interfejs jest zgodny z protokołem GovTalk Document Submission Protocol i został zaimplementowany jako usługa sieciowa ASP.NET. Komunikacja z klientami zewnętrznymi odbywa się w sposób synchroniczny FEWS akceptuje dokument, przetwarza go i zwraca odpowiedź, której treśd zależy od statusu wykonania transakcji odpowiedź może zawierad potwierdzenie zaakceptowania dokumentu i informację o kontynuacji komunikacji sposobem asynchronicznym albo dokument zwrócony przez urząd w odpowiedzi na dokument do niej wysłany. Po otrzymaniu dokumentu podsystem FEWS inicjuje następujący proces: 1. Uwierzytelnienie i autoryzacja aplikacji nadawcy opcjonalny krok pozwalający upewnid się, że tylko znane aplikacje (np. portale internetowe) mogą przesyład komunikaty za pomocą huba komunikacyjnego. Więcej informacji na temat zabezpieczania podsystemu FEW znajduje się w sekcji Zagadnienia związane z bezpieczeostwem niżej w tym dokumencie. 2. Sprawdzenie rozmiaru otrzymanego dokumentu ze względu na ochronę systemu przed przeciążeniem i zgłaszaniem fałszywych dokumentów wymagane jest, by rozmiar dokumentu mieścił się pomiędzy określonymi granicami minimalną i maksymalną. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 137

138 Ograniczenie maksymalnego rozmiaru żądania w konfiguracji IIS lub ASP.NET pozwala także zmniejszyd zagrożenie atakami typu DoS. 3. Weryfikacja dokumentu XML względem schematu GovTalk. Weryfikacja zawartości elementu Body nie jest możliwa, ponieważ element ten może zawierad dowolne dane XML związane z konkretną usługą. 4. Wykonanie odpowiednich akcji w oparciu o wartośd elementów Function i Qualifier koperty GovTalk i zwrócenie odpowiedzi właściwej dla protokołu przekazywania dokumentów. Poprawne kombinacje elementów Function i Qualifier w kopertach wiadomości nadsyłanych przez klientów zewnętrznych to submit/request, submit/poll, list/request oraz delete/request. Poniżej zamieszczono opis przetwarzania komunikatu submit/request (SUBMISSION_REQUEST). Komunikat ten wykorzystywany jest w przypadku, gdy obywatel lub organizacja biznesowa przesyła nowy dokument do określonej jednostek administracji publicznej. 1. Jeśli metoda uwierzytelnienia, podana na kopercie GovTalk, to W3Csigned, następuje sprawdzenie poprawności podpisu elektronicznego i certyfikatu. 2. Wyodrębnienie poświadczeo z komunikatu GovTalk i przesłanie ich do usługi U&A. Pozwala to na uwierzytelnienie nadawcy i sprawdzenie, czy posiada on rejestrację w usłudze wskazanej przez element Class koperty GovTalk. 3. Wygenerowanie nowej wartości CorrelationID i dodanie jej do komunikatu. Wartośd CorrelationID to 32-bajtowy ciąg znaków *0-9A-F+,0,32-, pozwalający na skorelowanie wszystkich dokumentów związanych z określoną transakcją. Dokumentami mogą byd żądania, potwierdzenia i odpowiedzi. W celu zagwarantowania unikalności, wartośd CorrelationID wyznaczana jest na podstawie wartości skrótu identyfikatora GUID wyznaczonego algorytmem MD5. 4. Dodanie do komunikatu wartości GatewayTimestamp. Wartośd ta określa oficjalny termin przyjęcia dokumentu przez hub komunikacyjny. 5. Przekazanie komunikatu do podsystemu komunikacyjnego BizTalk (BizTalk Messaging System BMS) do routingu i przesłania dokumentu dalej. Przekazywanie dokumentów do BMS może odbywad się na różne sposoby i z wykorzystaniem różnych protokołów przez system plików albo z wykorzystaniem MSMQ i HTTP. 6. Dodanie do bazy danych śledzenia transakcji (TrackingDB) nowego rekordu z metadanymi opisującymi transakcję. Opcjonalne dodanie nowego rekordu do bazy danych inspekcji (AuditDB). 7. Zwrócenie odpowiedzi klientowi. Jeśli komunikat przeszedł wszystkie testy i został poprawnie zapisany lub dostarczony do punktu docelowego, FEWS zwraca komunikat SUBMISSION_ACKNOWLEDGEMENT, zawierający wartośd CorrelationID wygenerowaną w kroku 3. Klient może później wykorzystad wartośd CorrelationID do sprawdzenia statusu transakcji. Jeśli komunikat nie przeszedł testów lub wystąpiły inne błędy, FEWS zwraca komunikat SUBMISSION_ERROR. Przetwarzanie komunikatów z innymi wartościami pól Function i Qualifier przebiega w podobny sposób, zgodnie z zaleceniami protokołu Document Submission Protocol. Podsystem komunikacyjny BizTalk (BMS) Podsystem komunikacyjny BizTalk (BizTalk Messaging Subsystem BMS) jest odpowiedzialny za wszelkie przetwarzanie związane z routingiem i wymianą dokumentów z urzędami. Funkcje podsystemu BMS to w większości odpowiedniki wbudowanych funkcji serwera Microsoft BizTalk Server 2004: pobieranie komunikatów z FEWS, routing komunikatu na podstawie jego zawartości (Content-based routing CBR) w oparciu o wartości elementów Class i Qualifier, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 138

139 dostarczanie komunikatów do docelowej jednostek administracji publicznej z wykorzystaniem protokołu BizTalk Framework 2.0 (BTF) Reliable Messaging, automatyczne ponawianie prób w przypadku błędów komunikacji, odbieranie i przetwarzanie odpowiedzi jednostek administracji publicznej. Ogólną strukturę podsystemu BMS przedstawiono na ilustracji 45. Ilustracja 45. Podsystem komunikacyjny BizTalk Odbieranie dokumentów z FEWS BMS posiada jednokierunkowy port odbiorczy (ReceiveFromFEWS na ilustracji 45), za pomocą którego pobiera wszystkie dokumenty, które pomyślnie przeszły walidację w FEWS. Istnieją różne adaptery protokołów, umożliwiające wymianę dokumentów pomiędzy FEWS a BMS (warto w tym miejscu zauważyd, że w typowym środowisku produkcyjnym podsystemy FEWS i BMS będą najprawdopodobniej znajdowały się w różnych warstwach rozwiązania): System plików FEWS zapisuje dokument w lokalnym folderze plików, a w BMS skonfigurowana jest lokalizacja odbioru plików, wskazująca ten folder za pomocą ścieżki UNC (folder musi byd udostępniony); MSMQ FEWS wysyła dokumenty do zdalnej kolejki prywatnej. BMS do pobierania komunikatów z lokalnej kolejki wykorzystuje adapter BizTalk Adapter for MSMQ. MSMQ dobrze się sprawdza dla dokumentów o rozmiarze poniżej 4 MB; HTTP FEWS wysyła dokument używając adresu protokołu HTTP, wskazanego przez BMP jako adres odbiorczy. Ponieważ komunikacja pomiędzy FEWS a BMS jest komunikacją wewnętrzną, wybór mechanizmu transportowego zależy głównie od wymagao w zakresie wydajności i niezawodności. Przekazywanie dokumentów przez system plików nie jest obarczone ograniczeniami rozmiaru, takimi jak w MSMQ, zapewnia dobrą wydajnośd i pozwala na skalowanie wszerz poprzez RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 139

140 skonfigurowanie wielu folderów i wielu instancji serwera BizTalk. Uwaga w przypadku adapterów protokołów dla BizTalk, system plików i protokół HTTP mają zbliżone charakterystyki wydajnościowe (dla dokumentów o rozmiarze poniżej 200 MB). Routing dokumentów do agencji docelowej BMS posiada port nadawczy dla każdej usługi elektronicznej identyfikowanej przez element Class w kopercie GovTalk. Każdy z portów jest połączony z odpowiadającym punktem koocowym danej usługi. Każdy port nadawczy ma następujące ustawienia: Tabela 3. Ustawienia portu nadawczego typ połączenia typ transport URI potok filtry statyczny jednokierunkowy http ReliableMessagingTransmit Class=={GovTalkClassName X} And Qualifier==request Wyrażenie filtrujące pozwala kierowad dokumenty GovTalk do odpowiedniego portu w oparciu o wartośd elementu Class (tak właśnie działa routing na podstawie treści dokumentu). Ponieważ wartośd pola Class w dokumentach odpowiedzi jest taka sama, jak w dokumencie oryginalnym, wyrażenie filtrujące zostało rozszerzone o dodatkowy warunek Qualifier==request, co pozwala uniknąd odsyłania odpowiedzi z powrotem do jednostek administracji publicznej. Implementacja w BizTalk Server 2004 mechanizmu routingu w oparciu o określone elementy koperty GovTalk wymaga: wdrożenia schematu GovTalk na serwerze BizTalk Server, promocji elementów Class i Qualifier; promocja właściwości to proces, w którym wartośd właściwości zostaje wydobyta z dokumentu XML z użyciem wyrażenia XPath i zapisana w kontekście komunikatu, co umożliwia wykorzystanie jej do routingu komunikatu, konfiguracji potoku odbiorczego zawierającego komponent XML disassembler. Przetwarzanie odpowiedzi od jednostek administracji publicznej BMS do odbierania odpowiedzi od jednostek administracji publicznej używa jednokierunkowego portu odbiorczego (ReceiveFromIH na ilustracji 45). Odpowiedziami mogą byd komunikaty SUBMISSION_ACKNOWLEDGEMENT, SUBMISSION_RESPONSE lub SUBMISSION_ERROR. Port odbiorczy ma pojedynczą lokalizację (ReceiveFromIHviaHttp) o następujących ustawieniach: Tabela 4. Ustawienia portu odbiorczego transport address (URI) potok odbiorczy http /ReceiveFromIH/BtsHttpReceive.dll ReliableMessagingReceive Ponieważ adapter odbiorczy HTTP jest hostowany przez ISS, BMS wymaga utworzenia odpowiedniego katalogu wirtualnego (ReceiveFromIH), wskazującego ścieżkę C:\Program Files\Microsoft BizTalk Server 2004\HttpReceive (przy założeniu, że BizTalk zainstalowany jest na dysku C). Komunikaty odebrane przez BMS (jako dokumenty GovTalk) zostają zapisane w bazie danych BizTalk o nazwie MessageBox, a następnie trafiają do portu nadawczego ProcessResponse, widocznego na ilustracji 45. Wartośd wyrażenia filtrującego tego portu to BTS.ReceivePortName==ReceiveFromIH port ten otrzymuje wszystkie komunikaty odebrane przez port ReceiveFromIH. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 140

141 Port ProcessResponse korzysta z niestandardowego adaptera realizującego różne akcje w zależności od wartości elementów Function i Qualifier koperty GovTalk. submit/acknowledgement aktualizacja statusu transakcji w bazie TrackingDB w celu wskazania, że dokument został poprawnie dostarczony do agencji docelowej; submit/response lub submit/error zapisanie odpowiedzi w bazie TrackingDB; dokument zostanie zwrócony klientowi, gdy FEWS otrzyma od klienta komunikat SUBMISSION_POLL - uaktualnienie statusu transakcji w bazie TrackingDB, - wysłanie powiadomienia (jeśli element Address komunikatu SUBMISSION_REQUEST zawierał adres ). Hub komunikacyjny może dostarczyd odpowiedź bezpośrednio do klienta, który zainicjował transakcję. Może to byd szczególnie przydatne w przypadku realizacji komunikacji G2G. Aby bezpośrednie dostarczenie odpowiedzi było możliwe, klient musi podad prawidłowy adres URL w polu ResponseEndPoint koperty GovTalk. FEWS sprawdza wartośd pola ResponseEndPoint w komunikatach przychodzących, i jeśli pole to zawiera prawidłowy adres URL, adres zostaje zapisany wraz z innymi metadanymi w bazie danych śledzenia transakcji. W czasie przetwarzania odpowiedzi przez adapter BizTalk zapisany adres URL zostaje wykorzystany do przesłania odpowiedzi bezpośrednio do klienta. Niezawodna komunikacja Gwarantowane jednokrotne przesyłanie dokumentów GovTalk pomiędzy hubem komunikacyjnym i urzędami jest realizowane z wykorzystaniem technologii BizTalk Framework (BTF) Reliable Messaging. Niezawodnośd komunikacji zapewniana jest przez następujące elementy: ReliableMessagingReceive specjalny potok zawierający komponent BizTalk Framework Disassembler; ReliableMessagingTransmit specjalny potok zawierający komponent BizTalk Framework Assembler; port SendRMReceipts dynamiczny, jednokierunkowy port nadawczy służący do dostarczania potwierdzeo Reliable Messaging Receipt. Wyrażenie filtrujące portu ma wartośd BTS.MessageType==BTF2DeliveryReceipt; przez port ten przechodzi każdy komunikat informujący o dostarczeniu komunikatu. Komponent BizTalk Framework Assembler wymaga konfiguracji niektórych właściwości: Tabela 5. Właściwości komponentu BizTalk Framework Assembler Nazwa właściwości adres dostarczania potwierdzeo typ adresu dostarczania potwierdzeo okres ponawiania próby wysłania potwierdzenia dostarczenia adres docelowy typ adresu docelowego Wartośd Biz:httpURL 30 czas życia komunikatu (w minutach) 30 temat dokumentu adres źródłowy typ adresu źródłowego GovDept Biz:OrganizationName Gateway biz:organizationname Wartośd właściwości adres dostarczania potwierdzeo to adres URL lokalizacji odbiorczej HTTP, udostępnianej przez hub komunikacyjny do celów przetwarzania wszystkich potwierdzeo niezawodnej komunikacji, wysyłanych przez jednostki administracji publicznej. Uwaga do przetwarzania potwierdzeo niezawodnej komunikacji można także wykorzystad lokalizację RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 141

142 odbiorczą używaną do przyjmowania odpowiedzi z jednostek administracji publicznej (ReceiveFromIHviaHttp). Wartości właściwości okres ponawiania próby wysłania potwierdzenia dostarczenia i czas życia komunikatu wymagają szczegółowego omówienia. Jeśli hub komunikacyjny nie dostarczy komunikatu do określonej agencji w czasie wskazanym przez czas życia komunikatu, próba dostarczenia komunikatu uważana jest za nieudaną i hub nie ponawia prób połączenia. Ustawienie właściwości na wartości większe niż 30 minut (na przykład 1 lub 2 dni) może byd przydane w przypadku, gdy łącza komunikacyjne lub systemy informatyczne agencji docelowej są często niedostępne. Obsługa niedostarczonych komunikatów i zablokowanych transakcji BMS posiada wbudowany mechanizm ponawiania prób w przypadku kłopotów z dostarczeniem komunikatu. Wykorzystano w nim ustawienia licznik prób i okres pomiędzy próbami portu nadawczego BizTalk. Po określonej liczbie nieudanych prób dostarczenia komunikatu, BMS wstrzymuje ten komunikat i czeka na interwencję zewnętrzną. Do automatyzacji procesu ponownego wysyłania wstrzymanych komunikatów można zastosowad specjalny komponent, który okresowo za pomocą WMI sprawdza listę wstrzymanych komunikatów, automatycznie wysyła te, które można wysład, a pozostałe kasuje. Hub komunikacyjny wyposażono także w możliwośd wykrywania zablokowanych transakcji. Transakcja zostaje zablokowana w przypadku nieotrzymania komunikatu w określonym terminie na przykład wtedy, gdy potwierdzenie lub odpowiedź oczekiwana od jednostek administracji publicznej nie nadchodzi we właściwym czasie. Metadane opisujące każdą transakcję przechowywane są przez hub w bazie danych TrackingDB. Przechowywany jest między innymi status transakcji oraz data i czas ostatniej zmiany statusu. Uruchamiany w tle proces (zadanie SQL Server uruchamiane przez proces SQL Server Agent) okresowo przegląda bazę danych, i jeśli jakaś transakcja znajduje się w określonym stanie przez czas dłuższy od określonego limitu oznacza tę transakcję jako wygasłą. Następnym razem gdy klient prześle pytanie o stan transakcji, hub komunikacyjny zwróci komunikat informujący o błędzie i usunięciu zablokowanej transakcji. Osoba, która zainicjowała transakcję, może następnie skontaktowad się z urzędem, do której kierowała dokument i jeśli jest to potrzebne wysład dokument ponownie. Podsystem bazodanowy (DBS) Podsystem bazodanowy (Database Subsystem DBS) przechowuje metadane opisujące transakcje, informacje historyczne i odpowiedzi od jednostek administracji publicznej. Podsystem ten oparty jest na SQL Server 2000 i składa się z następujących baz danych: TrackingDB baza zawierająca metadane na temat transakcji i dokumenty odpowiedzi, AuditDB baza zawierająca historię zdarzeo związanych z przetwarzaniem komunikatów GovTalk, bazy danych specyficzne dla BizTalk baza danych MessageBox (BizTalkMsgBoxDb), baza danych SSO (SSODB), baza danych z konfiguracją (BizTalkMgmtDb) i inne. TrackingDB Podstawową funkcją bazy danych TrackingDB jest zapis przebiegu transakcji. Użyty tu termin transakcja pochodzi z definicji protokołu Document Submission Protocol i oznacza wymianę kilku dokumentów GovTalk o tej samej wartości CorrelationID. Wymieniane komunikaty mogą byd typu: SUBMISSION_REQUEST, SUBMISSION_ACKNOWLEDGEMENT, SUBMISSION_POLL, SUBMISSION_RESPONSE, DELETE_REQUEST lub DELETE_RESPONSE. Każdej transakcji odpowiada rekord w bazie TrackingDB zawierający następujące pola: CorrelationID wartośd elementu CorrelationID z koperty GovTalk; DocStatus status transakcji. Zwykle jest to numer powiązany z opisem słownym, na przykład status 200 oznacza, że dokument przeszedł wszystkie testy w FEWS i spodziewane jest dostarczenie go do jednostek administracji publicznej ; 600 dokument został dostarczony do jednostek administracji publicznej (otrzymano komunikat RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 142

143 SUBMISSION_ACKNOWLEDGEMENT); 700 otrzymano odpowiedź z jednostek administracji publicznej itp.; DocDate data i czas ostatniej zmiany pola DocStatus; DocClass wartośd elementu Class koperty GovTalk; SenderID wartośd elementu SenderID koperty GovTalk; ErrorID identyfikator określający typ ostatniego błędu, jaki wystąpił podczas przetwarzania komunikatu; Empire wartośd tego pola wskazuje, czy transakcja znajdowała się w określonym stanie przez okres dłuższy niż dozwolony; Address wartośd elementu Address koperty GovTalk. Jeśli w komunikacie inicjującym transakcję (SUBMISSION_REQUEST) znajdował się poprawny adres , hub komunikacyjny tymczasowo zapisuje adres, a następnie wykorzystuje go do powiadomienia klienta o nadejściu odpowiedzi od jednostek administracji publicznej ; ResponseEndPoint FEWS wypełnia to pole, jeśli w elemencie ResponseEndPoint komunikatu inicjującego transakcję podany był prawidłowy adres URL. Po nadejściu odpowiedzi od jednostek administracji publicznej BMS sprawdza adres i próbuje wysład odpowiedź bezpośrednio do klienta. Odpowiedzi powiązane z określonymi transakcjami są zapisywane w osobnej tabeli o następujących kolumnach: CorrelationID wartośd elementu CorrelationID z koperty GovTalk; DocContent cała treśd dokumentu GovTalk z odpowiedzią od jednostek administracji publicznej (komunikat SUBMISSION_RESPONSE lub SUBMISSION_ERROR). Odebranie komunikatu DELETE_REQUEST powoduje usunięcie odpowiedzi z tabeli Responses komunikat DELETE_REQUEST zawiera wartośd CorrelationID dokumentu, który ma zostad usunięty. Jeśli hub komunikacyjny nie otrzyma komunikatu DELETE_REQUEST w określonym przedziale czasowym, zadanie SQL Server automatycznie usunie rekord odpowiedzi związany z tą transakcją. Podana lista pól to jedynie zarys metadanych przechowywanych przez hub komunikacyjny w celu obsługi transakcji. Projekt bazy danych musi uwzględniad stosowanie standardowych technik optymalizacji baz danych, takich jak indeksowanie i normalizacja hub komunikacyjny może przetwarzad bardzo duże liczby transakcji, więc obciążenie bazy TrackingDB będzie wysokie. AuditDB Zadaniem bazy danych AuditDB jest zapewnienie kompletnego logowania zdarzeo związanych z przetwarzaniem komunikatów przez poszczególne podsystemy. Baza AuditDB może byd pomocna w rozwiązywaniu problemów związanych z obsługą transakcji i dostarczyd danych statystycznych, takich jak średni czas realizacji transakcji przez określoną usługę. Usługa zarządzania tożsamością także może korzystad z bazy AuditDB do zapisu historii zdarzeo związanych z pomyślnym i niepomyślnym logowaniem się użytkowników, rejestracjami itp. Oto przykład użyteczności bazy. Wyobraźmy sobie transakcję, która przez bardzo długi czas znajduje się w stanie 200 (dokument zaakceptowany i przekazany dalej w celu dostarczenia do usługi docelowej). Dokument może nadal znajdowad się w folderze plików ze względu na jakiś problem w BMS, może znajdowad się w bazie danych BMS ze względu na problem z komunikacją z hubem komunikacyjnym, a mógł też zostad przesłany do agencji docelowej, ale agencja nie odesłała potwierdzenia otrzymania dokumentu. W takim przypadku zespół pomocy technicznej może odczytad z bazy AuditDB zdarzenia związane z tą transakcją i określid miejsce, w którym utknął dokument, co byd może pozwoli także na zidentyfikowanie przyczyny problemu. Baza danych AuditDB może mied bardzo prostą strukturę. Historia zdarzeo zapisywana jest w tabeli zawierającej identyfikator zdarzenia, datę i czas wystąpienia zdarzenia, identyfikator nadawcy (wartośd pola SenderID) i identyfikator transakcji (wartośd pola CorrelationID). RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 143

144 W osobnej tabeli przechowywana jest lista identyfikatorów zdarzeo wraz odpowiadającymi im identyfikatorami zdarzeo. Warto zauważyd, że podsystem BMS w celu zapisu do bazy AuditDB (np. zapisania zdarzenia dostarczenia komunikatu do docelowej jednostek administracji publicznej ) może wymagad dodatkowych komponentów. BMS pracuje pod kontrolą BizTalk Server, który do śledzenia komunikatów wykorzystuje własne bazy danych. Można rozważyd następujące rozwiązania: specjalny komponent w potoku proste rozwiązanie działające w powiązaniu ze standardowym adapterem nadawczym HTTP serwera BizTalk. Rozwiązanie to jednak nie pozwala na analizowanie dostarczania komunikatów w przypadku, gdy błąd komunikacyjny spowoduje zawieszenie przetwarzania HTTP; specjalny adapter to rozwiązanie wymaga większego zaangażowania programistów, ale daje lepsze rezultaty. Informacje zapisywane w bazie danych są zawsze poprawne, ponieważ adapter pozwala na sprawdzenie, czy jednostka administracji publicznej zaakceptowała wysłany do niej dokument. Zgodnie z zaproponowanym projektem, wszystkie komunikaty otrzymywane od agencji są przetwarzane przez specjalny adapter zapisujący dane w bazie danych TrackingDB. W związku z tym dodanie funkcjonalności niezbędnej do zapisywania zdarzeo w bazie AuditDB nie będzie skomplikowane. Warto zauważyd, że baza danych AuditDB jest systemem rejestrującym zdarzenia na poziomie biznesowym rejestrowane zdarzenia są bezpośrednio powiązane z logiką biznesową huba komunikacyjnego i podsystemu zarządzania tożsamościami. Zdarzenia odpowiadają na przykład wysłaniu dokumentu do agencji, otrzymaniu potwierdzenia, zarejestrowaniu użytkownika itd. Do celów rejestrowania zdarzeo na poziomie systemowym w FEWS można wykorzystad moduł Logging and Instrumentation Application Block z pakietu Enterprise Library (patrz BizTalk Server zawiera także funkcjonalnośd Health and Activity Tracking, ułatwiającą rozwiązywanie problemów związanych z przetwarzaniem komunikatów. Skalowalnośd i wysoka dostępnośd W przypadku rozwiązao testowych, cały hub komunikacyjny może znajdowad się na pojedynczym serwerze. Na serwerze zainstalowany będzie system operacyjny Windows Server 10 i IIS, ASP.NET, BizTalk Server 11 i SQL Server 12. Jednakże w przypadku środowiska produkcyjnego, taka konfiguracja raczej nie osiągnie wymaganej przepustowości (liczba dokumentów na sekundę) i dostępności. Skalowalnośd i dostępnośd huba komunikacyjnego zależą głównie od produktów i technologii wykorzystanych do budowy głównych podsystemów huba: podsystem FEWS oparty jest na IIS i ASP.NET, tak więc naturalnym wyborem jest zastosowanie równoważenia obciążenia (IP Load Balancing), które zapewnia zarówno wysoką dostępnośd, jak i skalowanie wszerz. Stosowanie klastrów niezawodnościowych opartych na usłudze (Microsoft Cluster Service MCS) nie ma sensu, ponieważ rozwiązanie takie nie zapewnia skalowalności, a na dodatek MCS wymaga wyspecjalizowanego sprzętu, takiego jak zewnętrzna macierz dyskowa; podsystem BMS działa w oparciu o BizTalk Server, który z definicji zapewnia możliwośd uzyskania wysokiej dostępności i skalowanie wszerz poprzez stosowanie wielu serwerów BizTalk Server pracujących w grupie. Uwaga tylko edycja Enterprise serwera BizTalk pozwala na instalowanie więcej niż jednego procesora w serwerze i więcej niż jednego serwera w grupie; RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 144

145 podsystem DBS opiera się na SQL Server, który może zapewnid wysoką dostępnośd poprzez pracę w klastrze niezawodnościowym (z wykorzystaniem usługi Microsoft Cluster Service, wbudowanej w Windows Server Enterprise Edition). Konfigurację na małą skalę huba komunikacyjnego, zapewniającą wysoką dostępnośd, przestawiono na ilustracji 46. Ilustracja 46. Wysokodostępna konfiguracja huba komunikacyjnego Warstwa internetowa Serwery w farmie internetowej równoważą obciążenie przetwarzaniem komunikatów nadsyłanych przez klientów zewnętrznych, wykorzystując technikę IP Load Balancing (w FEWS zastosowano procesy bezstanowe, więc konfigurowanie koligacji serwerów nie jest potrzebne). Ta sama farma może obsłużyd zarówno podsystem FEWS, jak i usługę zarządzania tożsamościami. Ponieważ metadane opisujące transakcje są składowane we wspólnej bazie danych TrackingDB, każdą transakcję w dowolnej chwili może obsłużyd dowolny z serwerów wchodzących w skład farmy, co ułatwia tak równoważenie obciążenia, jak i uzyskanie odporności na awarie. W niewielkich wdrożeniach, obsługujących niewielkie liczby jednoczesnych transakcji, podsystem FEWS i BMS mogą znajdowad się w tej samej warstwie rozwiązania, jednakże z punktu widzenia bezpieczeostwa i wydajności lepiej jest je odseparowad. Połączenie warstwy internetowej z BizTalk Wymiana komunikatów pomiędzy warstwą internetową a warstwą BizTalk musi odbywad się w sposób zapewniający równoważenie obciążenia i odpornośd na awarie. Połączenie pomiędzy podsystemami FEWS i BMS można zrealizowad na wiele sposobów z użyciem protokołu HTTP, MSMQ lub systemu plików. W przypadku protokołu HTTP, FEWS używa metody POST protokołu HTTP (lub SOAP) i wysyła komunikaty do lokalizacji odbiorczej HTTP na jednym z serwerów BizTalk RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 145

146 pracujących z równoważeniem obciążenia (komunikaty wysyłane są na wirtualny adres IP). W tym wypadku opóźnienia komunikacji sieciowej mogą byd przyczyną kłopotów FEWS musi poczekad na zakooczenie transmisji komunikatu, zanim synchronicznie zwróci odpowiedź klientowi. Innym rozwiązaniem jest wykorzystanie transportu plików, który jest prosty w realizacji, a jednocześnie zapewnia dobrą wydajnośd komunikacji pomiędzy dwiema warstwami. Odpornośd na awarie i skalowalnośd można uzyskad, stosując następującą konfigurację: każdy serwer FEWS zapisuje otrzymane dokumenty w folderze na dysku lokalnym; folder jest udostępniony i dostępny dla serwerów BMS; dla każdego folderu, udostępnionego na serwerze internetowym, w BizTalk utworzona jest lokalizacja odbiorcza pliku; wiele instancji BizTalk obsługuje wiele lokalizacji odbiorczych. Opóźnienie zapisu pliku będzie minimalne, ponieważ FEWS zapisuje dane na dysku lokalnym. Do przesyłania komunikatów o rozmiarach mniejszych niż 4 MB można także wykorzystad MSMQ. W przypadku komunikatów o większych rozmiarach, system powinien automatycznie przełączad się na transport z użyciem systemu plików. Klaster BizTalk Podsystem BMS pracuje w klastrze BizTalk (grupie). W małych konfiguracjach wysokodostępnych dwa serwery BizTalk pracujące w grupie mogą obsługiwad przyjmowanie, routing i przetwarzanie komunikatów pochodzących od FEWS i od jednostek administracji publicznej. Aby uzyskad jak największą wydajnośd, dobrą praktyką jest rozproszenie realizacji różnych zadao na różne hosty: hosty odbiorcze obsługują lokalizacje odbiorcze i są odpowiedzialne za przyjmowanie i zapisywanie komunikatów nadsyłanych przez FEWS i jednostki administracji publicznej; hosty nadawcze obsługują wysyłanie komunikatów protokołem HTTP i są odpowiedzialne za dostarczanie komunikatów do jednostek administracji publicznej ; hosty przetwarzające obsługują wysyłanie komunikatów z użyciem specjalnego adaptera i są odpowiedzialne za przetwarzanie odpowiedzi od jednostek administracji publicznej. Dodatkowo, ze względu na koniecznośd utrzymania wysokiej wydajności, każdy host wdrożony jest na więcej niż jednym serwerze BizTalk. Jeśli wymagana jest większa przepustowośd, serwery BizTalk można podzielid na różne warstwy do odbierania komunikatów i do przetwarzania i wysyłania komunikatów. Każda warstwa odpowiedzialna będzie za odrębne zadania i może byd skalowana niezależnie. Na ilustracji 47. przedstawiono przykładową konfigurację z dwiema maszynami fizycznymi i trzema hostami BizTalk. Host odbiorczy obsługuje dwie lokalizacje odbiorcze plików (do odbierania plików z dwóch różnych folderów udostępnionych) oraz lokalizację odbiorczą HTTP do odbierania odpowiedzi od jednostek administracji publicznej (lokalizacja odbiorcza HTTP pracuje z równoważeniem obciążenia). Host nadawczy obsługuje wszystkie porty nadawcze służące do dostarczania komunikatów do jednostek administracji publicznej. Host przetwarzający zawiera specjalny adapter zapisujący odpowiedzi w bazie danych TrackingDB i powiadamiający klientów. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 146

147 Ilustracja 47. Przykładowa konfiguracja hostów BizTalk Klaster SQL Server SQL Server 2000 wykorzystywany jest i przez podsystemy FEWS, i do składowania danych związanych z przetwarzaniem komunikatów, a więc skalowalnośd i dostępnośd całego huba komunikacyjnego zależy od skalowalności i dostępności podsystemu bazodanowego. SQL Server pozwala na stosowanie różnych technik zapewniania wysokiej dostępności można stosowad m.in. klastry niezawodnościowe, przesyłanie dzienników transakcji, replikację. Więcej na temat poszczególnych technik można dowiedzied się z dokumentu Microsoft SQL Server High Availability, dostępnego pod adresem W małych konfiguracjach wysokiej dostępności wszystkie bazy danych huba komunikacyjnego i systemu zarządzania tożsamością mogą byd obsłużone przez pojedynczy dwuwęzłowy klaster SQL Server. Bazy danych można rozłożyd na dwie wirtualne instancje SQL Server. W normalnych warunkach każda z instancji będzie pracowała na osobnej maszynie fizycznej (klaster aktywny/aktywny), co zapewnia statyczne równoważenie obciążenia. Rozkład baz danych powinien zależed od charakterystyk ich obciążenia. Na przykład baza danych MessageBox serwera BizTalk i baza TrackingDB są znacznie obciążone operacjami odczytu i zapisu, a baza danych AuditDB i baz danych Tracking serwera BizTalk są obciążone jedynie operacjami zapisu. Informacje na temat zaleceo dotyczących rozkładania obciążeo baz danych BizTalk można znaleźd w dokumencie BizTalk Server Technical Guide for High Availability pod adresem Zagadnienia związane z bezpieczeostwem W projektach współdzielonej infrastruktury do wymiany (i tymczasowego przechowywania) dokumentów tworzonych przez obywateli, przedsiębiorstwa i jednostki administracji publicznej, jeden z najwyższych priorytetów powinno mied bezpieczeostwo tak samo jak niezawodnośd, skalowalnośd i łatwośd zarządzania. W tej sekcji dokumentu zebrano kilka praktycznych porad dotyczących zabezpieczania interfejsów huba komunikacyjnego. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 147

148 Hub komunikacyjny powinien mied możliwośd bezpiecznej wymiany komunikatów z różnymi jednostkami z wykorzystaniem sieci publicznych takich jak Internet. Hub komunikacyjny udostępnia dwa różne interfejsy do obsługi dwóch różnych grup jednostek klientów zewnętrznych (portale internetowe, aplikacje ISV) i jednostek administracji publicznej. Zabezpieczanie komunikacji z klientami zewnętrznymi Ponieważ interfejs zewnętrzny dostępny jest z Internetu, cała komunikacja pomiędzy hubem komunikacyjnym a klientami zewnętrznymi musi byd szyfrowana. Naturalnym wyborem jest tu użycie protokołu HTTPS (SSL/TLS). HTTPS to standardowy mechanizm, który gwarantuje, że przesyłane dane mogą byd odczytane tylko przez dwa punkty uczestniczące w sesji SSL. Poza samym szyfrowaniem danych warto także zaimplementowad mechanizm ograniczający dostęp do usługi sieciowej huba komunikacyjnego (FEWS) dostęp powinny mied jedynie uprawnione klienty. Uprawionymi klientami mogą byd portale internetowe prowadzone przez centralne i lokalne jednostki administracji publicznej lub aplikacje biznesowe wymieniające dokumenty z administracją publiczną. Pozwolenie na bezpośrednie przesyłanie dokumentów przez anonimowych użytkowników Internetu narazi hub komunikacyjny na ataki odmowy usługi (denial of service) walidacja i weryfikacja poświadczeo są operacjami kosztownymi obliczeniowo. W żadnym wypadku anonimowy dostęp do huba nie zapewni znaczących korzyści użytkownikom koocowym, takim jak obywatele i przedsiębiorstwa. W celu uwierzytelnienia nadawcy, FEWS może podczas negocjacji sesji SSL zażądad przedstawienia certyfikatu uwierzytelnienia klienta. Certyfikat weryfikowany jest na podstawie listy przechowywanej przez FEWS w jakiejś składnicy konfiguracyjnej, na przykład w pliku web.config (obywatele i przedsiębiorstwa komunikują się z hubem komunikacyjnym za pośrednictwem portalu, a więc w czasie negocjacji SSL nie muszą przedstawiad certyfikatu uwierzytelnienia klienta). Dodatkowo na poziomie katalogu wirtualnego IIS można ustawid listę certyfikatów zaufanych (Certificate Trust List CTL), co pozwoli zapewnid dostęp wyłącznie klientom posiadającym certyfikat wydany przez określonego wydawcę. Zabezpieczanie komunikacji z jednostkami administracji publicznej W proponowanym rozwiązaniu hub komunikacyjny odbiera wszystkie odpowiedzi od jednostek administracji publicznej z użyciem standardowego adaptera odbiorczego HTTP serwera BizTalk (adapter ten jest aplikacją ISAPI). Dostęp do tego interfejsu można ograniczyd, stosując następującą, sprawdzoną procedurę: Skonfigurowanie katalogu wirtualnego IIS tak, by wymagał szyfrowania SSL i uwierzytelniania klienta za pomocą certyfikatu. Dzięki temu serwer będzie obsługiwał wyłącznie komunikację szyfrowaną wyłącznie z klientami legitymującymi się prawidłowym certyfikatem. Zastosowanie listy zaufanych certyfikatów (Certificate Trust List CTL) do zawężenia listy akceptowalnych certyfikatów do certyfikatów wydanych przez określonego wydawcę (certyfikaty mogą byd wydawane przez dedykowane centrum certyfikacji na przykład usługi certyfikatów Windows Certificate Services). Wyłączenie dostępu anonimowego do katalogu wirtualnego IIS i włączenie mapowania certyfikatów klientów na określone konto użytkownika Windows z użyciem w IIS mapowania jeden do jeden. W przypadku gdy klient przedstawi certyfikat, dla którego mapowanie nie zostało skonfigurowane, IIS zapyta o podanie nazwy użytkownika i hasła. Zamapowanie konta użytkownika Windows w BizTalk i włączenie uwierzytelniania na porcie odbiorczym BizTalk, dzięki czemu do BMS dostęp będzie miało tylko określone konto użytkownika. Uwaga protokół Reliable Messaging (RM) wymaga szczególnej uwagi podczas zabezpieczania komunikacji z jednostkami administracji publicznej z użyciem certyfikatów uwierzytelniania RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 148

149 klienta. Protokół RM wymaga, by strona odbierająca komunikat wygenerowała i zwróciła potwierdzenie RM, które BizTalk dostarcza z użyciem portu dynamicznego (nasłuchującego komunikatów typu BTF2DeliveryReceipt). Aby skonfigurowad obsługę certyfikatów uwierzytelniania klienta dla portu dynamicznego, kontekst komunikatu z potwierdzeniem RM powinien mied zainicjowaną właściwośd HTTP.Certificate, zawierającą odcisk klucza z certyfikatu uwierzytelniania klienta. W takim wypadku standardowym podejściem jest utworzenie specjalnego potoku, który ustawia właściwośd HTTP.Certificate, a następnie powiązanie tego potoku z portem dynamicznym. Innym możliwym rozwiązaniem jest opracowanie aplikacji pośredniczącej ASP.NET, która przechwytuje komunikaty z potwierdzeniami RM i automatycznie nawiązuje połączenia HTTP z użyciem certyfikatu uwierzytelniania klienta. Aby umożliwid przechwytywanie komunikatów z potwierdzeniami RM, adres dostarczania potwierdzeo można zmienid na przykład z postaci: na następującą: gdzie to adres URL lokalizacji odbiorczej przetwarzającej komunikaty RM. Hub integracyjny Hub integracyjny to odpowiednik huba komunikacyjnego, znajdujący się w każdej usłudze agencyjnej i zapewniający integrację z systemami zaplecza. Hub integracyjny zapewnia następującą funkcjonalnośd: Gwarantowane przesyłanie dokumentów XML pomiędzy jednostką administracji publicznej a hubem komunikacyjnym, z wbudowaną obsługą mechanizmu zapamiętaj i wyślij, automatycznego ponawiania transmisji i dostarczania jednokrotnego. Funkcja ta oparta jest na technologii BizTalk Framework (BTF) Reliable Messaging (RM). Elastyczna, realizowana bez potrzeby pisania kodu integracja z systemami zaplecza w oparciu o BizTalk Server. Hub integracyjny obsługuje wiele różnych protokołów, formatów danych i adapterów aplikacyjnych, wyposażony jest także w narzędzia graficzne do definiowania komunikatów, transformacji i orkiestracji. Transformacja komunikatów na formaty zrozumiałe dla systemów zaplecza. Powiadamianie o błędach komunikacji z systemami zaplecza. Rejestrowanie historii transakcji i archiwizowanie przetworzonych dokumentów. W niniejszej sekcji zgromadzono zalecenia dotyczące implementacji huba integracyjnego z wykorzystaniem BizTalk Server z uwzględnieniem udostępnianych funkcji, projektu systemu, integracji z systemami zaplecza. Podano także inne zalecenia implementacyjne. Funkcje Hub integracyjny realizuje następujące główne funkcje: odbieranie od huba komunikacyjnego komunikatów GovTalk z wykorzystaniem protokołu BTF Reliable Messaging, walidacja struktury komunikatów, generowanie i dostarczanie komunikatów SUBMISSION_ACKNOWLEDGEMENT protokołu GovTalk do huba komunikacyjnego, także z wykorzystaniem protokołu BTF Reliable Messaging, dostarczanie do systemów zaplecza komunikatów związanych z transformacją komunikatów i z wykorzystaniem różnych protokołów transportowych i interfejsów API, przetwarzanie odpowiedzi i dostarczanie ich do huba komunikacyjnego z wykorzystaniem protokołu BTF Reliable Messaging, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 149

150 zapis medatanych i historii transakcji do wykorzystania w celach raportowania i rozwiązywania problemów. Projekt Podobnie jak w przypadku huba komunikacyjnego, projekt huba integracyjnego musi zapewnid dużą elastycznośd współpracy z usługami on-line i systemami zaplecza. Z tego względu podstawowa funkcjonalnośd powinna byd generyczna i niezależna od schematów takich jak treśd komunikatów GovTalk lub interfejsy systemów zaplecza. Ilustracja 48. Projekt huba integracyjnego Przykładową implementację huba integracyjnego, opartą na różnych elementach BizTalk, przedstawiono na ilustracji 48. Warto podkreślid, że: cała wymiana komunikatów pomiędzy hubem komunikacyjnym a systemami zaplecza odbywa się z wykorzystaniem portów nadawczych i odbiorczych BizTalk; logika biznesowa huba integracyjnego została zaimplementowana z wykorzystaniem orkiestracji BizTalk; RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 150

151 hub integracyjny do przechowywania danych konfiguracyjnych, danych śledzenia i historii zdarzeo wykorzystuje bazy danych SQL Server. Podobnie jak w przypadku huba komunikacyjnego, hub integracyjny rejestruje wszystkie transakcje do celów śledzenia i dane historyczne do celów audytu; w celu zapewnienia wygodnego interfejsu użytkownika do przeglądania zgromadzonych danych śledzenia i danych historycznych można zbudowad aplikację internetową. Zastosowanie do budowy huba integracyjnego głównie gotowych komponentów pozwala znacznie zmniejszyd ilośd kodu, jaki trzeba napisad, a także podnosi niezawodnośd, łatwośd zarządzania i skalowalnośd systemu. Odbiór dokumentów od huba komunikacyjnego Hub integracyjny odbiera dokumenty za pośrednictwem jednokierunkowego portu odbiorczego (IH_ReceiveFromTxE na ilustracji 48), który zawiera jedną lokalizację odbiorczą o nazwie ReceiveFromTxEviaHTTP. Lokalizacja ta oparta jest na standardowym adapterze odbiorczym HTTP serwera BizTalk. Ponieważ komunikacja pomiędzy hubem komunikacyjnym a hubem integracyjnym odbywa się z wykorzystaniem protokołu BTF Reliable Messaging, lokalizacja odbiorcza współpracuje z potokiem zawierającym komponent BizTalk Framework Disassembler (potok ReliableMessagingReceive na ilustracji 48). Hub komunikacyjny weryfikuje wszystkie komunikaty względem schematu GovTalk, a usługa zarządzania tożsamością uwierzytelnia je i autoryzuje. W związku z tym, w większości przypadków hub integracyjny nie musi wykonywad szczegółowej walidacji komunikatów przychodzących. Musi mied jednak pewnośd, że komunikaty rzeczywiście zostały wysłane przez hub komunikacyjny. Zewnętrzny interfejs huba integracyjnego można zabezpieczyd w taki sam sposób, jak opisano to dla huba komunikacyjnego (patrz fragment Zagadnienia związane z bezpieczeostwem w sekcji Hub komunikacyjny wcześniej w tym dokumencie). Przetwarzanie i wysyłanie komunikatów do systemów zaplecza Każdy dokument otrzymany od huba komunikacyjnego powoduje aktywację nowego procesu orkiestracji huba integracyjnego. W procesie orkiestracji zaimplementowano następującą logikę biznesową: Pobranie informacji na temat usługi docelowej z konfiguracyjnej bazy danych. W bazie tej zapisane są adresy URL systemów zaplecza, stan każdej z usług (on-line lub off-line), wymagany sposób komunikacji (synchroniczna lub asynchroniczna) i inne informacje. Wygenerowanie komunikatu SUBMISSION_ACKNOWLEDGEMENT i wysłanie go do huba komunikacyjnego. Komunikat ten stanowi dla huba komunikacyjnego potwierdzenie, że dostarczenie dokumentu powiodło się, i że dokument ten został zapisany wewnątrz huba integracyjnego. Przesłanie dokumentu do docelowego systemu zaplecza. Komunikacja z tym systemem może odbywad się synchronicznie lub asynchronicznie, a komunikat może byd przesyłany z wykorzystaniem różnych protokołów. W wielu przypadkach niezbędna jest orkiestracja pośrednia. W przypadku stosowania komunikacji synchronicznej przetworzenie odpowiedzi od systemu zaplecza oraz ponowne wysłanie dokumentu do systemu zaplecza, jeśli system zwrócił komunikat SUBMISSION_ERROR, a typ błędu wskazuje, że można ponowid próbę przetworzenia komunikatu. W przypadku stosowania komunikacji synchronicznej odesłanie odpowiedzi do huba komunikacyjnego. Zapis odpowiednich informacji w bazie danych śledzenia i bazie danych z informacjami historycznymi. Hub integracyjny do komunikacji z systemami zaplecza używa dwóch portów nadawczych (patrz ilustracja 48): RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 151

152 IH_SendToOrgAsync jest dynamicznym portem jednokierunkowym stosowanym do komunikacji asynchronicznej, IH_SendToOrgSync jest dynamicznym portem żądanie-odpowiedź stosowanym do komunikacji synchronicznej. Protokół transportowy i adres URI każdej usługi konfigurowane są dynamicznie w oparciu o wartości przechowywane wewnątrz konfiguracyjnej bazy danych huba integracyjnego. W przypadku stosowania komunikacji asynchronicznej, hub integracyjny odbiera wszystkie odpowiedzi od systemów zaplecza za pośrednictwem pojedynczego portu odbiorczego (IH_ReceiveFromOrg) i orkiestracja nie bierze udziału w przetwarzaniu komunikatów orkiestracja kooczy działanie po wysłaniu żądania asynchronicznego. W zależności od wymagao, port odbiorczy może zawierad wiele lokalizacji odbiorczych opartych na różnych protokołach, takich jak HTTP, FTP czy system plików. Odpowiedzi do huba komunikacyjnego dostarczane są za pośrednictwem jednokierunkowego portu nadawczego (IH_SendToMH na ilustracji 48), który nasłuchuje wszystkich komunikatów pochodzących z portu IH_ReceiveFromOrg. Konfiguracja portu nadawczego obejmuje potok zawierający komponent BizTalk Framework Assembler (ReliableMessagingTransmit na ilustracji 48). Komunikaty SUBMISSION_ACKNOWLEDGEMENT i synchroniczne odpowiedzi od systemów zaplecza wysyłane są z użyciem tego samego portu. Konfiguracyjna baza danych Konfiguracyjna baza danych powinna zawierad wszystkie informacje niezbędne do inicjalizacji portów dynamicznych, za pomocą których hub wymienia dane z systemami zaplecza. Hub integracyjny może przechowywad informacje konfiguracyjne w prostej tabeli SQL Server, zawierającej po jednym rekordzie dla każdej usługi elektronicznej. Rekord powinien zawierad następujące pola: GovTalkClass identyfikator usługi, odpowiadający wartości elementu Class koperty GovTalk dokumentów kierowanych do tej usługi; PostUrl adres URI systemu zaplecza, zwykle adres URL protokołu HTTP, ale możliwe jest wykorzystanie dowolnego protokołu obsługiwanego przez BizTalk; Online flaga statusu wskazująca, czy usługa jest w danej chwili aktywna. Jeśli nie jest, mechanizm orkiestracji huba integracyjnego powinien wstrzymad dostarczanie komunikatów do usługi i poczekad na interwencję operatora; Sync pole określające sposób komunikacji z systemem zaplecza synchroniczny lub asynchroniczny; AuthenticationScheme sposób uwierzytelniania transmisji HTTP lub SOAP. Możliwe wartości to Anonymous, Basic, Digest i Kerberos; UserName nazwa użytkownika stosowana podczas uwierzytelniania w systemie zaplecza z użyciem sposobów Basic lub Digest; Password podane jawnym tekstem hasło odpowiadające nazwie użytkownika; RetryCount liczba kolejnych prób skontaktowania się z systemem zaplecza w przypadku występowania problemów z komunikacją; RetryInterval czas (w minutach) pomiędzy kolejnymi próbami kontaktu. Konfiguracyjną bazę danych można także rozszerzad, dołączając parametry specyficzne dla poszczególnych usług. Dodatkowe procesy orkiestracji mogą wykorzystad te parametry do konfiguracji procesów biznesowych specyficznych dla poszczególnych usług. Czynniki do rozważenia podczas integracji z systemami zaplecza W idealnym świecie systemy zaplecza powinny udostępniad oparty na protokole HTTP lub SOAP interfejs asynchroniczny, za pomocą którego hub integracyjny może przesyład dokumenty GovTalk. Systemy zaplecza przetwarzają dokumenty asynchronicznie i zwracają hubowi RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 152

153 integracyjnemu odpowiedzi w postaci dokumentów GovTalk także za pośrednictwem protokołu HTTP lub SOAP. W rzeczywistości systemy zaplecza nie zawsze pozwalają na taką współpracę. Integracja z nimi nie jest zadaniem łatwym. Typowym przykładem, zwłaszcza w komunikacji z lokalnymi systemami informatycznymi administracji publicznej, są systemy zarządzania dokumentami (Document Management System DMS), które nie udostępniają żadnego interfejsu programistycznego do wymiany danych ze światem zewnętrznym. Opakowania Web Service Rozwiązaniem umożliwiającym integrację często jest przygotowanie opakowania Web Service (lub aplikacji internetowej przyjmującej wywołania HTTP) implementującego interfejs GovTalk i zintegrowanego z systemem zaplecza na poziomie danych. W przypadku systemu DMS opakowanie może realizowad następujące funkcje: akceptowanie komunikatów SUBMISSION_REQUEST protokołu GovTalk i przetwarzanie określonych danych z treści dokumentu; wykonywanie walidacji biznesowej danych; tworzenie rejestracji dokumentu bezpośrednio w bazie danych DMS; synchroniczne zwracanie komunikatów SUBMISSION_RESPONSE, zawierających na przykład numer rejestracji dokumentu. Hub integracyjny może przekazad taki komunikat do huba komunikacyjnego z użyciem protokołu BTF Reliable Messaging. Zaletą stosowania opakowania Web Service jest to, że wewnątrz huba integracyjnego potrzebne jest jedynie minimalne dopasowanie, niewymagające tworzenia kodu. Interfejs taki mogą także wykorzystywad inne aplikacje wewnętrzne. Implementacja opakowania wymaga jednak szczegółowej wiedzy na temat logiki aplikacji i struktury bazy danych wykorzystywanej przez system zaplecza. Opracowanie opakowania zwykle wymaga współpracy z producentem integrowanego systemu. Obsługa wielu odpowiedzi od systemów zaplecza W przypadku systemów zarządzania dokumentami często zdarza się, że usługa okresowo wysyła powiadomienia o bieżącym stanie przetwarzania dokumentu. Z technicznego punktu widzenia oznacza to generację wielu komunikatów SUBMISSION_RESPONSE protokołu GovTalk w ramach jednej i tej samej transakcji. Jeśli usługa elektroniczna wysyła wiele odpowiedzi do klienta, opakowanie Web Service powinno także akceptowad komunikaty SUBMISSION_POLL. Inicjatorem sprawdzenia stanu dokumentu (pollingu) może byd albo hub integracyjny, albo portal internetowy użyty przez obywatela do wysłania dokumentu. Gdy klientem jest portal internetowy, pierwszy komunikat SUBMISSION_RESPONSE powinien zawierad poprawny element ResponseEndPoint, instruujący portal, by kolejne komunikaty SUBMISSION_POLL wysyłał bezpośrednio do opakowania Web Service. W takim przypadku rolę poświadczeo logowania pełni wartośd CorrelationID. Gdy klientem jest hub integracyjny, pollingiem może zająd się proces orkiestracji, okresowo wysyłając komunikaty SUBMISSION_POLL. Czas wysyłania kolejnych komunikatów i limit czasu oczekiwania na odpowiedź będą ustalane na podstawie parametrów w konfiguracyjnej bazie danych. Aby uniknąd wysyłania identycznych komunikatów do huba komunikacyjnego, proces orkiestracji musi mied możliwośd określenia, czy odpowiedź różni się od odpowiedzi otrzymanych wcześniej. Jednym z rozwiązao jest parsowanie określonych pól komunikatu, wskazujących stan sekwencji przetwarzania dokumentu. Pozwala to zatrzymad proces orkiestracji po zakooczeniu przetwarzania dokumentu. Wybrane problemy XML/HTTP Istnieje kilka problemów, o których należy pamiętad podczas konfigurowania opartej na XML i HTML integracji z aplikacjami firm trzecich. Jeden z nich związany jest ze znacznikiem kolejności RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 153

154 bajtów (Byte Order Mark BOM), dodawanym przez adapter HTTP serwera BizTalk na początku każdego dokumentu XML z kodowaniem Unicode. Znacznik BOM to ciąg danych binarnych o długości trzech bajtów, wykorzystywany do wykrywania sposobu kodowania dokumentu. Znacznik ten może stanowid problem dla niektórych parserów XML innych producentów. Rozwiązaniem jest albo usunięcie znacznika z dokumentu po stronie usługi zaplecza, albo usunięcie go po stronie BizTalk w tym celu należy zainstalowad odpowiednie uaktualnienie (patrz Drugi problem dotyczy techniki chunked encoding (kodowanie porcjami), stosowanej w protokole HTTP. Technika ta polega na przesyłaniu danych w porcjach o różnej wielkości. Pozwala ona na przesyłanie danych strumieniowo, dzięki czemu nadawca nie musi buforowad wszystkich danych przed wysłaniem i podawad całkowitego rozmiaru komunikatu w nagłówkach HTTP. Serwer BizTalk domyślnie stosuje technikę chunked encoding dla komunikatów o rozmiarze większym niż 48 KB. Może to sprawiad problemy w przypadku, gdy druga strona kanału komunikacyjnego HTTP nie obsługuje tego sposobu kodowania. W takim wypadku należy wyłączyd kodowanie chunked encoding w adapterze HTTP serwera BizTalk (patrz Przyczyną nieprawidłowej komunikacji pomiędzy hubem integracyjnym a systemem zaplecza może byd także podawanie niewłaściwych kodów odpowiedzi HTTP. Na przykład jeśli system zaplecza zaakceptował i zarejestrował wysłany do niego dokument, ale z powodu jakiegoś błędu zwrócił nieprawidłowy kod odpowiedzi (na przykład 500), hub integracyjny ponowi próbę wysłania dokumentu. Może to byd przyczyną zduplikowania informacji. Z drugiej strony, jeśli przetworzenie dokumentu nie powiedzie się, ale system zaplecza zwróci kod odpowiedzi informujący o poprawnym obsłużeniu żądania (200 lub 202), dokument zostanie utracony. Aby uniknąd duplikowania lub gubienia informacji, system zaplecza musi mied poprawnie zaimplementowany mechanizm obsługi błędów. Rozszerzanie funkcjonalności huba integracyjnego Czasem trudno jest uzasadnid wdrożenie huba integracyjnego jedynie przekazywaniem komunikatów pomiędzy systemami zaplecza a hubem komunikacyjnym. Jeśli jednostka administracji publicznej zaimplementowała w swoim systemie zaplecza interfejs GovTalk, istnieje techniczna możliwośd bezpośredniej komunikacji pomiędzy systemem a hubem komunikacyjnym. W takim wypadku główną zaletą huba integracyjnego jest skrócenie czasu i obniżenie kosztów integracji poprzez wykorzystanie gotowych funkcji komunikacyjnych, takich jak przekazywanie komunikatów metodą zapamiętaj i wyślij, automatyczne ponawianie prób komunikacji w przypadku błędów i gwarantowane dostarczanie jednorazowe. Rzeczywistą wartośd huba integracyjnego można jednak zauważyd dopiero po pełnym wykorzystaniu dodatkowych możliwości integracyjnych serwera BizTalk. Jeśli na przykład określona usługa elektroniczna wymaga integracji z wieloma systemami, można opracowad dodatkowy proces orkiestracji i umieścid go pomiędzy orkiestracją huba integracyjnego a systemami zaplecza. Proces orkiestracji będzie obsługiwał wymianę komunikatów z wieloma systemami, a także z systemami klienckimi obsługiwanymi przez ludzi, rejestrował przesyłane przez nie dokumenty i generował odpowiedzi. Hub integracyjny może także stanowid punkt koocowy protokołu GovTalk i obsługiwad dalszą komunikację z systemami zaplecza z użyciem natywnych formatów komunikatów i interfejsów API. Ten sposób pracy można rozumied jako usunięcie koperty GovTalk, transformację treści komunikatu na postad pliku płaskiego i zapakowanie odpowiedzi z powrotem w kopertę GovTalk. Istnieje już ponad 300 gotowych adapterów, które można wykorzystywad do wymiany danych z istniejącymi systemami zaplecza. Oprócz innych funkcji, hub integracyjny może obsługiwad raportowanie transakcji, archiwizowanie wszystkich dokumentów przychodzących i wychodzących oraz elektroniczne podpisywanie dokumentów odpowiedzi. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 154

155 Podpisy elektroniczne i certyfikaty Systemy teleinformatyczne podmiotów publicznych powinny byd przygotowane do obsługi podpisu elektronicznego w kontaktach zewnętrznych z obywatelami oraz innymi podmiotami publicznymi, urząd może także wymagad ralizacji podpisu w wewnętrznych procedurach. Implementacja obsługi podpisów elektronicznych i certyfikatów stanowi wyzwanie dla jednostek administracji publicznej, w szczególności w zakresie organizacyjnym, a nie technicznym. W realizacji systemiu hub komunikacyjny i usługa zarządzania tożsamością mogą obsłużyd walidację podpisów dokumentów przychodzących, ale bardziej zaawansowane funkcje jak pobieranie określonych informacji z certyfikatu klienta (na przykład nazwisko lub unikalny identyfikator obywatela) lub elektronicznie podpisywanie generowanych odpowiedzi wymaga imlemenacji specjalizowanych serwisów do realizacji tego zaadania. Należy zwrócid uwagę, że akceptowanie podpisanych pism i wydawanie decyzji wymaga ingerencji człowieka i realizowanie podpisu bezpiecznego (kwalifikowanego) osoby fizycznej, która akceptuje treśd wydanego dokumentu lub kontroluje zgodnośd złożonych podpisów z polityką przyjętą przez daną organizację. Na przykład może byd wymagane elektroniczne podpisanie dokumentu przez jednego lub kilku pracowników urzędu, by dokument ten był wiążący prawnie dla przeciwnej strony komunikacji. Rozszerzenie funkcjonalności huba integracyjnego tak, by obsługiwał wszystkie operacje związane z podpisami elektronicznymi, może znacznie obniżyd złożonośd systemu i skrócid czas potrzebny na implementację usług elektronicznych zapewniających wymaganą funkcjonalnośd. Dodatkowa funkcjonalnośd huba integracyjnego może obejmowad: parsowanie certyfikatów z wykorzystaniem dostępnych klas biblioteki.net. Wydobyte informacje mogą byd przekazane do systemu zaplecza w dowolnym wygodnym formacie; dodatkowy komponent umieszczony w potoku, służący do elektronicznego podpisywania odpowiedzi z użyciem określonego certyfikatu; jest to użyteczne w przypadkach, gdy podpisanie dokumentu nie wymaga interwencji użytkownika, np. w realizacji poświadczenia przedłożenia lub oznaczania czasem; dodatkową aplikację dla urzędników paostwowych, pozwalającą na podpisywanie dokumentów. Aplikacja może składad się z portalu internetowego i zestawu elementów BizTalk odpowiedzialnych za zarządzanie przepływem zadao i integrację z systemami zaplecza. Wskazówki dotyczące implementacji Na ilustracji 49. przedstawiono prosty proces orkiestracji, implementujący podstawową logikę biznesową huba integracyjnego. Orkiestracja huba integracyjnego odbiera dokument SUBMISSION_REQUEST protokołu GovTalk i na podstawie wartości elementu Class pobiera informacje konfiguracyjne odpowiedniej usługi elektronicznej. Parametry konfiguracyjne mogą zostad zwrócone w postaci klasy.net z pojedynczą metodą statyczną lub klas należących do modułu Configuration Management Application Block biblioteki Enterprise Library. Moduł Configuration Management Application Block zapewnia większą elastycznośd przechowywania i odczytywania informacji konfiguracyjnych. Więcej informacji na ten temat można znaleźd pod adresem Następnie proces orkiestracji przygotowuje i wysyła komunikat SUBMISSION_ACKNOWLEDGEMENT. Jest to niezbędne do powiadomienia huba komunikacyjnego, że hub integracyjny poprawnie odebrał i zaakceptował komunikat do dalszego przetwarzania. Komunikat potwierdzenia można wygenerowad na dwa sposoby poprzez zamapowanie oryginalnego komunikatu lub z wykorzystaniem pomocniczej klasy.net (przykładowy kod takiej klasy zamieszczono w dokumentacji BizTalk Server 2004). RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 155

156 Ilustracja 49. Logika huba integracyjnego zaimplementowana w postaci orkiestracji BizTalk Następny etap to przygotowanie komunikatu żądania. Oryginalny komunikat otrzymany od huba komunikacyjnego zostaje skopiowany i uzupełniony o dodatkowe parametry, których wartości ustawiane są na podstawie informacji pobranych z konfiguracyjnej bazy danych. Ponieważ w komunikacji wykorzystywane są porty dynamiczne, właściwości kontekstu komunikatu muszą określad liczbę dozwolonych prób dostarczenia dokumentu oraz odstęp pomiędzy kolejnymi próbami (właściwości te ustalane są za pomocą elementu (shape) przypisania komunikatu w procesie orkiestracji): //Create a new message as copy of the original message GovTalkRequest = GovTalkOrig; //Set Retry Count for the message GovTalkRequest(BTS.RetryCount) = RetryCount; //Set Retry Interval for the message GovTalkRequest(BTS.RetryInterval) = RetryInterval; RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 156

157 Następnie, w zależności od przyjętego sposobu komunikacji z usługą docelową, proces orkiestracji kontynuuje pracę zgodnie z jedną z dwóch możliwych ścieżek. W obydwu przypadkach następuje inicjalizacja parametru URI odpowiedniego portu dynamicznego i wysłanie komunikatu żądania. Obsługa błędów w komunikacji asynchronicznej i synchronicznej W przypadku asynchronicznej komunikacji z usługą docelową, proces orkiestracji zostaje zakooczony natychmiast po wysłaniu komunikatu. Natomiast komunikacja synchroniczna wymaga jeszcze przetworzenia komunikatu otrzymanego w odpowiedzi na żądanie. Zgodnie ze specyfikacją protokołu GovTalk, jeśli komunikat odpowiedzi to SUBMISSION_ERROR, a typ błędu wskazuje, że błąd jest odwracalny, hub integracyjny powinien ponowid próbę wysłania dokumentu. Można to łatwo osiągnąd, umieszczając logikę ponawiania prób wewnątrz orkiestracji. Ilustracja 50. Obsługa wyjątków i logika ponawiania prób umieszczone wewnątrz orkiestracji Na ilustracji 50. przedstawiono przykładową implementację bloku ponawiania prób z elementem (shape) pętli. Synchroniczna odpowiedź OK. zostaje przekazana do huba komunikacyjnego. Jeśli system zaplecza zwróci informację o błędzie z możliwością ponowienia transmisji, proces orkiestracji odczeka czas określony parametrem okresu oczekiwania i ponownie wyśle komunikat. Po przekroczeniu maksymalnej liczby powtórzeo proces orkiestracji wstrzyma dostarczanie komunikatu i będzie czekał na interwencję. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 157

158 Innym rozwiązaniem jest poinformowanie huba integracyjnego o konieczności ponowienia transmisji za pomocą natywnych kodów błędów protokołów HTTP lub SOAP. W takim wypadku kolejne próby przesłania komunikatu realizuje adapter BizTalk. Jedną z najważniejszych cech huba integracyjnego powinna byd odpornośd na awarie różnego typu. Żaden dokument nie powinien zostad utracony, a przetwarzanie powinno zostad normalnie wznowione po ponownym uruchomieniu systemu, który uległ awarii. Na przykład jeśli port nadawczy serwera BizTalk jest skonfigurowany tak, by podejmował próby dostarczenia komunikatu co pięd minut, ale ponawiał je tylko trzy razy, awaria modułu komunikacyjnego serwera zaplecza trwająca dłużej niż 20 minut może spowodowad wstrzymanie dostarczenia dokumentu. Prostym rozwiązaniem jest dopasowanie liczby i okresu powtórzeo tak, by odpowiadały spodziewanej dostępności systemu zaplecza. Podobnie jak w przypadku huba komunikacyjnego, użytecznym rozwiązaniem jest implementacja specjalnego komponentu, który uruchamiany okresowo zlicza wstrzymane komunikaty za pomocą WMI i automatycznie wznawia próby ich dostarczenia. Rozwiązanie to jest szczególnie przydatne w sytuacji, gdy hub integracyjny korzysta z jednokierunkowego (asynchronicznego) sposobu komunikacji z systemem zaplecza oraz w komunikacji pomiędzy hubem integracyjnym i hubem komunikacyjnym. W przypadku synchronicznego sposobu komunikacji, proces orkiestracji po przekroczeniu maksymalnej liczby powtórzeo zostanie wznowiony i za pomocą portu nadawczego żądanieodpowiedź zgłosi wyjątek. Wyjątek zgłoszony zostanie także w przypadku otrzymania odpowiedzi w niewłaściwym formacie, na przykład nieprawidłowego dokumentu XML. Uzyskanie możliwości ponawiania prób dostarczenia komunikatu w procesie orkiestracji wymaga uzupełnienia opisanego wcześniej bloku ponawiania o moduł obsługi wyjątków. Moduł ten powinien byd umieszczony w zakresie nietransakcyjnym, zawierającym kształty nadawczy i odbiorczy, używane do wymiany dokumentów z systemami zaplecza. Jeśli dostarczenie komunikatu nie powiedzie się lub odpowiedź systemu nie będzie prawidłowa, moduł obsługi wyjątków powinien wstrzymad wykonywanie procesu orkiestracji. Przed wstrzymaniem procesu może także powiadomid administratora odpowiednim komunikatem . Gdy administrator wznowi proces orkiestracji, element (shape) pętli spowoduje ponownie próby dostarczenia komunikatu. Wykorzystywanie dokumentu elektronicznego i podpisów elektronicznych W tej części przewodnika opisano sposób elektronicznego podpisywania dokumentów XML oraz walidacji podpisów. Elektroniczny podpis XML pozwala na uwierzytelnianie komunikatów XML lub ich nadawców. Standardy w zakresie elektronicznego podpisywania XML ustala organizacja W3C (więcej informacji można znaleźd pod adresem Podstawy prawne dokumentu elektronicznego Dokumenty elektroniczne przetwarzane przez podmioty publiczne powinny spełniad wymagania określone przepisami wykonawczymi do następujących ustaw: - Ustawa o informatyzacji podmiotów publicznych - Ustawa o podpisie elektronicznym - Ustawa Kodeks posterowania administracyjnego - Ustawa o narodowym zasobie archiwalnym i archiwach W szczególności należy zwrócid uwagę na obowiązek podpisywania bezpiecznym (kwalifikowanym) podpisem elektronicznym dokumentów biorących udział w postępowaniu administracyjnym oraz realizację procesów przyjmowania i doręczania dokumentów z wykorzystaniem technologii podpisu elektronicznego. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 158

159 Podstawowym obowiązkiem nałożonym przez akty wykonawcze jest stosowanie odpowiedniego formatu podpisów zgodnie ze standardem XML Signature i w formacie określonym standardem ETSI TS v (XAdES XML Advanced Electronic Signature). Przyjęcie dokumentu elektronicznego przez podmiot publiczny powinien zostad potwierdzony elektronicznym potwierdzeniem przedłożenia (Urzędowe Potwierdzenie Odbioru), natomiast doręczenia realizowane przez podmiot publiczny powinny uzależniad dostarczenie pisma do adresata od uprzedniego potwierdzenia jego otrzymania. Wyżej wymienione funkcje są realizowane na styku urząd i podmioty zewnętrzne, wymagania prawne nie zobowiązują urzędu do implementacji podpisu elektronicznego i zaawansowanych procedur doręczania w ramach procesów wewnątrz urzędu, które mogą byd realizowane wewnętrzną polityką bezpieczeostwa oraz procedurami umożliwiającymi wykorzystanie właściwości systemu workflow do zapewnienia dokumentacji ścieżki podstępowania w sprawach toczących się w urzędzie. Dokument elektroniczny i dokument papierowy Większośd działao związanych z informatyzacją urzędów opiera się na obowiązujących regulacjach dotyczących dokumentu elektronicznego w formacie XML. Tym niemniej, należy spodziewad się, że w ciągu najbliższych dziesięciu lat większośd spraw będzie wnoszona w postaci dokumentów papierowych. Istnieje więc koniecznośd wypracowania metod przekształcania dokumentu papierowego na elektroniczny w sposób zgodny z obowiązującymi regulacjami w zakresie dokumentu elektronicznego, archiwizacji i podpisu elektronicznego oraz w zgodzie z możliwością użycia tej formy dokumentów w obiegach dokumentów elektronicznych. Odpowiedzią na ten problem jest specyfikacja metastandardu dokumentów elektronicznych opracowanego w ramach projektu epuap. Przewiduje ona tworzenie szablonów (wzorów) dokumentów elektronicznych nie tylko w postaci pełnych formularzy, ale też nagłówków kopertujących. Użycie mechanizmu załączania skanu dokumentu papierowego do nagłówka XML zawierającego metadane i podstawowy opis sprawy umożliwia: - Jednorodne procesowanie dokumentów elektronicznych i skanowanych, - Zgodnośd z obowiązującymi regulacjami między innymi w kontekście archiwizacji danych, - Możliwośd podpisania całości (nagłówek + załącznik) podpisem elektronicznym, - Możliwośd prostej realizacji mechanizmów wyszukiwania, - Możliwośd udostępniania urzędnikom podejmującym decyzję wglądu w kluczowe dla procesu informacje i status sprawy bez konieczności dostępu do pełnej treści załączników - Możliwośd budowy brokerów usług pozwalających na automatyzację uprawnionego dostępu do niezbędnych informacji. Z uwagi na obowiązujące regulacje prawne obieg i archiwizacja informacji muszą opierad się na dokumentach elektronicznych w formacie XML tworzonych na bazie schematów XML przechowywanych w repozytorium wzorów (szablonów) dokumentów elektronicznych. Wymiana informacji pomiędzy systemami teleinformatycznymi administracji publicznej, a także komunikacja pomiędzy urzędami i osobami fizycznymi wymaga uzgodnienia standardów umożliwiających łatwe uzgodnienie interfejsów i jednolite rozumienie przekazywanych danych przez różne systemy teleinformatyczne. Jedną z podstawowych zasad dla ustalenia tych standardów jest przyjęcie języka komunikacji i standardu dla opisu struktur danych. Tym językiem jest XML, a standardem opisu są schematy w postaci XSD. Zwykle dokument papierowy powstaje w urzędzie lub jest wypełniany przez interesanta na bazie szablonu - formularza. Bliższe przyjrzenie się dokumentowi papierowemu, pozwala zauważyd, że dokument posiada pewną strukturę, w której bez trudu można odnaleźd i wskazad "logiczne bloki", zawierające specyficzne elementy, stanowiące całośd informacji. RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 159

160 Szczegółowy opis zasad tworzenia dokumentu elektronicznego został przyjęty zgodnie z opublikowanym na portalu epuap standardem: n&id=45 Tak więc, do stworzenia dokumentu elektronicznego, który będzie procesowany w urzędzie w formie sprawy oraz jego archiwizacji niezbędny jest następujący scenariusz: Przewidywane są dwie metody procesowania informacji w zgodzie z obowiązującymi regulacjami: 1. Oparcie się całkowicie o dokument elektroniczny XML (od jego utworzenia do archiwizacji), 2. Oparcie się o papierowy dokument źródłowy załączony do pliku XML zawierającego jego opis. Dla realizacji wymaganego prawem obiegu dokumentów w urzędzie, niezbędne jest przygotowanie łatwych w użyciu i efektywnych narzędzi do tworzenia dokumentów XML, zarówno dla interesantów jak i dla urzędników. Narzędzia tego typu powinny obsługiwad formularze elektroniczne powstałe na bazie schematów XML i pozwalad na: - Wypełnienie formularza ze wspomaganiem walidacji poszczególnych pól (o ile to możliwe), - Zapisanie wypełnionego formularza w postaci dokumentu XML, RISA Ramy Interoperacyjności Systemów Administracji Publicznej Strona 160