Platforma Usług dla Obywateli. Citizen Service Platform (CSP)

Wielkość: px
Rozpocząć pokaz od strony:

Download "Platforma Usług dla Obywateli. Citizen Service Platform (CSP)"

Transkrypt

1 Platforma Usług dla Obywateli Citizen Service Platform (CSP)

2 Spis treści Streszczenie... 4 Założenia ogólne... 5 Założenia organizacyjno-prawne Skutki społeczne wprowadzenia rozwiązania... 7 Założenia interoperacyjności... 8 Dokument elektroniczny i dokument papierowy... 8 Interoperacyjnośd systemów administracji samorządowej z rejestrami centralnymi i Elektroniczną Platformą Administracji Publicznej... 8 MetaStandard dokumentów elektronicznych Powszechne problemy dotyczące architektury Założenia funkcjonalne Założenia architektury CSP Wielokanałowa platforma usług administracji publicznej Podstawowa infrastruktura Usługa współdzielenia i obiegu informacji portal wielofunkcyjny Podsystem CRM Podsystem centrum kontaktowego Podsystem bazodanowy, raportowania i analizy danych Zarządzanie finansami Urzędu Usługa zarządzania projektami Usługa dostępu do sieci Internet Monitorowanie systemów i usług Podsystem instalacji oprogramowania i zarządzanie systemami Usługa poczty elektronicznej Ochrona przed wirusami i oprogramowaniem szpiegowskim Założenia integracji z obecnymi systemami urzędów Usługa zarządzania e-szkoleniami Szkolenia pracowników

3 3

4 Platforma Usług dla Obywateli Citizen Service Platform (CSP) Streszczenie 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 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. Projekt CSP 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 OBYWATELI, 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 organizacyjno-prawnych 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. 4

5 Założenia ogólne 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 OBYWATELI, 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, 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. 5

6 Założenia organizacyjno-prawne. Budowa systemów informacyjnych administracji samorządowej wspomagających usługi dla obywateli jest projektem skomplikowanym z uwagi na koniecznośd zmian organizacyjno-prawnych oraz koniecznośd zdefiniowania, a następnie wdrożenia standardów obejmujących wszystkie współuczestniczące w projekcie jednostki. Złożeniem CSP jest stworzenie struktury Działu Obsługi Klientów, który będzie reprezentował sprawy obywateli wobec różnych jednostek Urzędu lub wobec innych urzędów. 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. By osiągnąd cel projektu, konieczne jest przekazanie odpowiedzialności za przeprowadzenie fazy inwestycyjnej projektu, wdrożenie oraz w dalszej perspektywie utrzymanie trwałości projektu do Biura ds. elektronicznego urzędu, jako komórki koordynującej funkcjonowanie wszystkich usług elektronicznych w mieście. Zespół tworzący kadrę projektu powinien byd koordynatorem wszystkich działao związanych z realizacją projektu, w tym w szczególności: kontroli postępów prac, kontroli terminów, kontroli jakości, dokumentowania prac związanych z realizacją projektu, współpracy z działem finansowo księgowym, stały kontakt z ostatecznym odbiorcą, koordynacji działao: reklamowych i promocyjnych projektu, przygotowania raportów, sprawozdao okresowych, rocznych, w razie nieprawidłowości niezwłoczne informowanie o zaistniałym stanie rzeczy, podejmowania działao naprawczych. 6

7 Skutki społeczne wprowadzenia rozwiązania Omawiany projekt wychodzi naprzeciw oczekiwaniom społecznym, zarówno mieszkaoców jak i przedsiębiorców, którzy liczą na poprawę warunków życia w mieście oraz lepsze warunki inwestycji i rozwoju ekonomicznego. W celu podniesienia konkurencyjności obszaru podlegającego Urzędowi, jako obszaru funkcjonowania podmiotów gospodarczych oraz potencjalnych inwestorów, stworzenia warunków dla długofalowego rozwoju gospodarczego gminy, wzrostu jej spójności ekonomicznej, społecznej i terytorialnej, a także by stawała się ona przyjazna dla swych mieszkaoców, koniecznym jest poprawa obsługi interesantów, w tym dostępu do usług elektronicznych. Korzyści wynikające z wdrożenia usług elektronicznych: 1. stworzenie przyjaznej e-administracji w obszarze administracji publicznej przyczyni się do podniesienia poziomu rozwoju społeczeostwa informacyjnego. 2. administracja publiczna Unii daje impuls do rozwoju gospodarki opartej na wiedzy, generującej trwały wzrost gospodarczy, której towarzyszy jakościowa i ilościowa poprawa zatrudnienia oraz większa spójnośd społeczna, 3. unikanie marginalizacji różnych grup społecznych pod względem osobistym i zawodowym, poprawianie jakości i stabilności zatrudnienia, zwalczanie tzw. podział cyfrowy, promowanie powszechnej dostępności usług na szczeblu lokalnym, 4. poprawa jakości, elastyczności i wydajności usług dla ludności, lepszego gospodarowania zasobami publicznymi, redukcji kosztów, zadowolenia użytkowników, integracji pomiędzy poszczególnymi administracjami publicznymi i uproszczeo procedur administracyjnych. 5. zapewnienie powszechnego i bezpiecznego dostępu do usług szerokopasmowych, tak aby Internet stanowił narzędzie komunikacji i informacji. Zaufanie obywateli do tego instrumentu zależy od stopnia bezpieczeostwa związanego z jego użytkowaniem, co wpłynie na elektroniczną administrację i usługi, które będzie można świadczyd obywatelom. 6. Dotarcie do obywateli: wykorzystanie elektronicznej administracji do wspierania integracji społecznej, co przyniesie korzyści obywatelom korzystającym z wiarygodnych, nowatorskich usług, łatwo dostępnych dla każdego, 7. Sprawne i skuteczne funkcjonowanie: przyczynienie się w znaczący sposób do wysokiego poziomu zadowolenia użytkowników, przejrzystości i odpowiedzialności, do ograniczenia obciążeo administracyjnych oraz do poprawy sprawności działania. 7

8 Założenia interoperacyjności 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. Interoperacyjnośd systemów administracji samorządowej z rejestrami centralnymi i Elektroniczną Platformą Administracji Publicznej Opracowanie na podstawie założeo projektu e-puap oraz projektów dotyczących przebudowy systemu rejestrów centralnych mechanizmów wymiany danych pomiędzy systemami wykorzystywanymi przez Urząd a systemami informatycznymi administracji centralnej. Opracowane interfejsy powinny pracowad w architekturze SOA z wykorzystaniem usług sieciowych (Web Services) oraz silnika procesów biznesowych. Interfejsy opracowane w ramach projektu powinny umożliwiad konwersję postaci i treści komunikatu pomiędzy magistralą usług sieciowych Urzędu a brokerami systemu epuap. Opracowanie powinno także zawierad propozycje dotyczące bezpieczeostwa i kontroli dostępu do danych pozyskanych z rejestrów centralnych, metod przetwarzania tych danych a przede wszystkim harmonizacji aplikacji wykorzystywanych przez administrację samorządową ze strukturami danych rejestrów centralnych. W ramach projektu będzie także możliwe sprawdzenie, w jaki sposób system elektronicznej administracji Urzędu może wymieniad dane i dokumenty elektroniczne z systemem epuap, w jaki sposób przy pomocy rozwiązao lokalnych i systemu epuap można zrealizowad automatyczne przekazywanie informacji i dokumentów pomiędzy organami administracji publicznej w ramach procedur zintegrowanych (one-stop-shopping). Interfejs e-urząd 8

9 epuap można będzie traktowad jako wzorzec interoperacyjności systemów w wymiarze technicznym, semantycznym oraz organizacyjnym. W tym celu trzeba będzie poddad analizie opracowany w ramach projektu MetaStandard dokumentów elektronicznych oraz definicje procesów biznesowych zapisane w systemie Urzędu. Wynikiem projektu oprócz interfejsów umożliwiających wymianę komunikatów pomiędzy systemami powinny byd także mechanizmy zarządzania zmianą (definicji formularza, procesu biznesowego lub struktury danych) umożliwiające w przyszłości automatyczne dostosowanie wszystkich współpracujących systemów. Wzorcem dla interoperacyjności systemów Urzędu i epuap mogłyby byd mechanizmy ram interoperacyjności opracowane dla standardu ebxml. Mechanizmy interoperacyjności będą zgodne z założeniami ram interoperacyjności administracji publicznej opracowanymi przez MSWiA. W ramach niniejszego projektu zostaną zaprojektowane oraz przetestowane mechanizmy umożliwiające integrację usług elektronicznych oraz systemu obiegu dokumentów JST z usługami udostępnionymi na platformie e-puap. Aby było to możliwe konieczne jest opracowanie interfejsów, umożliwiających wymianę komunikatów pomiędzy systemem e-puap i systemem JST oraz zdefiniowanie procesów biznesowych, które będą odpowiedzialne za obsługę komunikacji. Przewidujemy kilka podstawowych scenariuszy, w których będą wykorzystywane interfejsy do systemu e-puap: 1. Przesłanie formularza elektronicznego z systemu e-puap do JST. 2. Przesłanie formularza elektronicznego z JST do e-puap. 3. Wykorzystanie usług infrastrukturalnych e-puap do obsługi formularza/dokumentu. 4. Autoryzacja użytkownika. 5. Rejestracja/modyfikacja usługi. 6. Utworzenie/modyfikacja profilu jednostki. 7. Dostęp do danych rejestrów centralnych. Oczywiście powyższa lista nie prezentuje wszystkich możliwych scenariuszy, zostaną one określone w toku realizacji projektu na podstawie specyfikacji szyny usług e-puap i realnych wymagao JST. Projektując interfejsy 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 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 9

10 HTTPS (HTTP over TLS and SSL), X.509 Public Key Infrastructure Certificate (PKI) 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 (http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wss) 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 10

11 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, 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 (http://schemas.xmlsoap.org/ws/2005/02/rm/) 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 11

12 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. MetaStandard dokumentów elektronicznych W ramach tego projektu zostanie rozszerzona funkcjonalnośd opracowania MetaStandard dokumentów elektronicznych, które powstało w ramach projektu epuap. W ramach istniejącego MetaStandardu, zostały zdefiniowane podstawowe obiekty składowe do budowania formularzy elektronicznych. Za pomocą formularzy elektronicznych zbudowanych z wykorzystaniem założeo MetaStandardu mieszkaocy/przedsiębiorcy mogą kierowad do urzędów administracji publicznej wnioski oraz podania. Celem niniejszego projektu jest rozbudowa MetaStandardu, zostanie one zrealizowana w trzech obszarach: 1. Rozszerzenie słownika o nowe obiekty podstawowe z zakresu zarządzania oświatą, zarządzania infrastrukturą. 2. Rozbudowa MetaStandardu o elementy umożliwiające wykorzystanie formularzy wykorzystujących go do obsługi Wielokanałowej Platformy Świadczenia Usług Administracji Publicznej. 3. Rozbudowa MetaStandardu o komponenty pomocne w budowania komunikatów służących do wymiany informacji i dokumentów pomiędzy jednostkami administracji publicznej. 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. 12

13 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 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). 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 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. Przykład dokumentu zawierającego zagnieżdżoną kopertę Niezwykle istotnym jest fakt, że dzięki takiemu mechanizmowi można w prosty sposób zrealizowad hybrydowy model obsługi interesanta, to znaczy taki, który umożliwia komunikację z urzędem drogą elektroniczną jak i klasyczną. W tym drugi przypadku treścią może byd skanowany dokument papierowy. Załączniki komunikatów 13

14 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). 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). 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 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. Rozszerzenie zabezpieczeo warstwy transportowej Zabezpieczenia wprowadzone w warstwie transportowej chronią poufnośd informacji jedynie podczas przesyłania ich pomiędzy nadawcą a odbiorcą. Poza kanałem komunikacyjnym komunikaty 14

15 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. 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ę. 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. 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 15

16 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 skrótu. 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 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. 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. W ramach projektu zostaną także opracowane założenia dotyczące integracji formularzy elektronicznych i komunikatów Powszechne problemy dotyczące architektury 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. 16

17 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. 17

18 Wymagania zaprojektowania w pełni wielojęzycznego interfejsu użytkownika, w którym wszystkie łaocuchy 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ąd pod uwagę, że ten sam tekst w różnych językach może mied różną długośd. 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 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 urzędach świadczących te usługi. 18

19 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ą Zaprojektowanie i wdrożenie efektywnego i bezpiecznego systemu zarządzania tożsamością dla usług dla sektora publicznego nie jest zadaniem trywialnym, zważywszy że liczba potencjalnych użytkowników może sięgad setek tysięcy. Ze względu na koszty i złożonośd problemu, jest oczywiste, że zarządzanie tożsamością powinno zostad zaimplementowane w postaci pojedynczego systemu, współdzielonego przez wszystkie usługi. 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 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. 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, 19

20 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. 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 20

21 tożsamością. Chodzi głównie o zasady minimalnego zakresu ujawniania niezbędnych informacji oraz tożsamości ukierunkowanej. 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 (non-repudiation) 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 21

22 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. 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świadczeo 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ą definiowad własne, odpowiednie i różne reguły i procedury identyfikacji początkowej. Zaufanie ukierunkowane poszczególne usługi mogą opierad się na procedurach identyfikacyjnych innych usług. Inaczej mówiąc, mogą ufad 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, 22

23 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ę 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. Integracja natywna 23

24 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ę. 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żdy urząd 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. 24

25 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. 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 25

26 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, 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 26

27 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. 27

28 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. 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. 28

29 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. 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. 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 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, 29

30 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. 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. 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 30

31 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. Założenia funkcjonalne Wdrożenie nowych usług elektronicznych wymagad będzie odpowiedniego oprogramowania umożliwiającego świadczenie tych usług na platformie internetowej, odpowiednich procedur załatwiania sprawy poprzez Internet oraz stworzenia i wykorzystania odpowiedniego systemu informatycznego służącego do przetwarzania tych danych i bezpiecznego ich udostępniania na potrzeby wewnętrzne i zewnętrzne. Wymogi stawiane opisywanemu rozwiązaniu determinują jego modułową budowę. Zakłada się, że do podstawowych do realizacji nowej platformy świadczenia usług potrzebne będą następujące elementy składowe systemu: Platforma Centrum Obsługi Obywateli MetaStandard dokumentów elektronicznych w tym danych przestrzennych i opisowych, Opracowane zasady interoperacyjności usług świadczonych w ramach projektu oraz tych które będą dostępne w ramach projektu e-puap, Standaryzacja interfejsu użytkowników i wspomaganie pracy grupowej, System klasy ERP z modułami budżetowania, Komponent bazodanowy z funkcjami raportowania i analizy danych, Systemu konsultacji planu zagospodarowania przestrzennego, Oprogramowanie wspomagające zarządzanie projektami, Platforma umożliwiająca obsługę użytkowników mobilnych. Wszystkie prace prowadzone w ramach niniejszego projektu powinny zostad przeprowadzone z poszanowaniem minimalnych wymagao dla systemów informatycznych. Wszystkie użyte narzędzia informatyczne muszą byd zgodne z normami ogłoszonymi przez W3C. W ramach projektu nie będą tworzone rejestry publiczne. 31

32 Zgodnie z celem projektu system musi zapewnid realizację wspomagania usług świadczonych przez jednostki Urzędu na rzecz obywateli. Tak więc, zakładane funkcjonalności CSP można podzielid na dwie grupy: 1. Usługi wspomagające obsługę obywateli 2. Usługi pomocnicze, bez których nie jest możliwe zrealizowanie usług grupy 1. Wdrożenie CSP ma zapewnid obywatelom jasny, efektywny i zunifikowany sposób kontaktu z Urzędem Miasta i jednostkami podległymi. 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. Podstawą rozwiązania jest Wielokanałowa Platforma Świadczenia Usług Publicznych (WPU) 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 organizacyjno-prawnych procesem skomplikowanym i długotrwałym. Etap I Mając na celu uzyskanie pozytywnych efektów w zakresie obsługi obywateli w stosunkowo krótkim czasie, konieczne jest zbudowanie następujących podstawowych funkcjonalności w pierwszym etapie wdrożenia: Wdrożenie spójnego systemu kontaktu obywatela z Urzędem (WPU). 32

33 1. Objęcie systemem następujących kanałów kontaktowych: telefon (w tym rejestrację zgłoszeo poza godzinami pracy Urzędu) wybrane sprawy poprzez formularze na portalu okienka informacyjne w placówkach Urzędu mail komunikator 2. Tworzenie bazy danych obywateli i ich spraw (wstępne importowane z lokalnej ewidencji ludności). Docelowym rozwiązaniem jest rejestrowanie wszystkich spraw procesowanych w systemach Urzędu w CRM 3. Możliwośd monitorowania poprzez CRM statusu spraw z udzielaniem informacji o statusie przez urzędnika poprzez portal Urzędu 4. Wprowadzenie do systemu CRM informacji o: sposobie załatwiania spraw lokalnych regulacjach kompetencjach poszczególnych jednostek w Urzędzie danych teleadresowych w Urzędzie (MIIS?) 5. Procesowanie zgłoszeo/spraw w następujący sposób: przejęcie i zarejestrowanie danych obywatela (lub ich potwierdzenie) zarejestrowanie sprawy przekazanie informacji o sposobie załatwienia sprawy lub uruchomienie ręczne sprawy poprzez przekazanie do odpowiedniej jednostki (mail, dokument papierowy, lun poprzez koocówkę systemu) informowanie o statusie sprawy w przypadkach uzasadnionych przekazywanie informacji do 112 badanie poziomu satysfakcji mieszkaoców 6. Analiza danych zawartych w CRM pod kątem wydajności i efektywności obsługi mieszkaoców 7. Tworzenie listy zgłoszeo priorytetowych lub przewlekłych, eskalacja spraw na poziom kierownictwa 8. Integracja CRM z system obiegu dokumentów i archiwum elektronicznym 9. Integracja CRM z systemem Urzędów (serwer formularzy) 10. Utworzenie/szkolenia zespołu Centrum Obsługi Obywateli 11. Przeprowadzenie kampanii wśród obywateli, popularyzującej taką formę kontakt 12. Budowę jednolitego systemu informacyjnego dla obywateli pozwalającego na uzyskanie informacji o: Informacji o sposobie i miejscu realizacji zadao samorządów Liście usług świadczonych przez urzędy Sposobie realizacji tych usług Działaniach i kampaniach poszczególnych urzędów Prawie lokalnym Równolegle z budową ujętą w Etapie I należy w skoordynowany z Etapem I sposób rozpocząd budowę usług pomocniczych bez których pełna funkcjonalnośd usług dla obywateli nie jest możliwa. Usługi te powinny obejmowad zakresem funkcjonalnym: 33

34 Standaryzację zarządzania tożsamością użytkowników (pracowników urzędu), Standaryzację interfejsu użytkownika, Współdzielenie i obieg informacji, Stworzenie przestrzeni roboczych i bibliotek dokumentów dla instytucji, projektów, zespołów i pracowników, Standaryzację dokumentów i formularzy elektronicznych, Wprowadzenie mechanizmów typu workflow, Implementacje PKI, Przetwarzanie danych i kreowanie raportów, Budowę sprawnego systemu poczty elektronicznej i integrację jej z innymi usługami, Integrację systemów zastanych, Budowę uniwersalnej szyny usług i zarządzanie usługami, Wspomaganie zarządzania projektami w tym przetargami publicznymi, Monitorowanie statusu procesów i spraw, Z punktu widzenia architektury drugiego etapu postawiono następujące założenia: Posługiwanie się otwartymi standardami w wymianie informacji, umożliwiające realizację zasad interoperacyjności na wszystkich jej poziomach, takimi jak: Usługi sieciowe (Web Services) Dokumenty w formacie XML oparte o schematy XML Wizualizacja dokumentów w dowolnej przeglądarce internetowej, Formularze dostępne w dowolnej przeglądarce internetowej, PKI zgodne z ustawodawstwem, Możliwośd komunikacji i integracji w warstwie przepływu informacji z dowolną technologią, Łatwośd integracji z przyszłymi centralnymi systemami administracji publicznej (PESEL2, e- PUAP), Wysoka skalowalnośd wydajnościowa i funkcjonalna, Łatwośd wdrożenia zaimplementowanych funkcjonalności w krótkim czasie, Modularnośd systemu, Możliwośd modyfikacji sposobu działania systemu przez uprawnionych użytkowników bez konieczności ingerencji firm zewnętrznych, Otwartośd na dalszą rozbudowę, Prostota obsługi. System informatyczny CSP powinien dostarczad użytkownikom usług komunikacji drogą elektroniczną oraz mechanizmów pracy grupowej. Usługi te powinny umożliwiad: Dostęp do zasobów systemu wymiany poczty elektronicznej i pracy grupowej niezależnie od miejsca pracy użytkownika, Dostęp do elementów pracy grupowej takich jak współdzielone dokumenty, kalendarze, zadania, aplikacje, Możliwośd kreowania obiegów dokumentów elektronicznych zgodnie z wymogami stawianymi przez ustawodawstwo, Efektywne mechanizmy składowania danych w ramach centralnych zasobów systemu, Możliwośd rozbudowy o komunikację głosową, video itp. 34

35 Efektywny, prosty i elastyczny system kreowania raportów zdefiniowanych i raportów adhoc dostępnych dla uprawnionych użytkowników. Założenia architektury CSP Architektura planowanego rozwiązania powinna zapewnid: Uzyskanie szerokiej dostępności systemu i jego interoperacyjności, Zapewnienie dowolnego kształtowania obsługiwanych procedur w urzędach CSP Wykorzystanie zasad otwartej architektury zbudowanej na standardach przemysłowych umożliwiające swobodny przepływ informacji i elastyczną rozbudowę systemu, Użycie rozpowszechnionych narzędzi (interfejsów) w celu przyspieszenia cyklu szkoleo, Zachowanie rozsądnych kosztów budowy systemu, Uzyskanie szybkiego efektu ekonomicznego i społecznego, Stosunkowo niskie koszty utrzymania systemu i ewentualnej rozbudowy, Skalowalnośd rozwiązania od jednej grupy usług do ogólno regionalnego CSP, Możliwośd wyboru spośród wielu wykonawców posługujących się daną technologią. W zakresie wymiany danych pomiędzy systemami teleinformatycznymi zaplanowane powinno byd wykorzystanie plików i usług sieciowych wykorzystujących język XML. Dane publikowane w Internecie zostaną sformatowane przy pomocy języka HTML. Wszelkie procesy biznesowe zostaną zdefiniowane za pomocą języka BPEL. Dokumenty elektroniczne zostaną zdefiniowane na podstawie schematów plików XML, oparte na strukturach XML i zrenderowane za pomocą plików XSLT do postaci HTML. Wielokanałowa platforma usług administracji publicznej Przeniesienie realizacji usług publicznych na platformę elektroniczną powinno odbyd się z wykorzystaniem wszelkich dostępnych środków komunikacji. Realizacji usług np. tylko i wyłącznie za pomocą formularzy elektronicznych stawia poza nawiasem dostępu tak dużą grupę społeczeostwa, że trudno taki pomysł uznad za słuszny w aspekcie finansowania go ze środków publicznych. Na szczęście administracja publiczna ma do dyspozycji coraz to większą gamę środków technicznych za pomocą, których może realizowad swoje usługi. Częśd z nich jak np. telefon nie jest w tej chwili nowinką techniczna ale w połączeniu z innymi technologiami ICT staje się zupełnie nowym narzędziem pracy. Wydaję się też, że już dobrze poznany telefon komórkowy, wyposażony w nowe funkcje bezprzewodowego dostępu do Internetu z narzędzia komunikacji głosowej, przeradza się w przenośny terminal, za pomocą którego będziemy mogli uzyskiwad dostęp do coraz to nowych usług. Wydaje się, że dla dalszego pomyślnego rozwoju elektronicznej administracji konieczne jest osiągnięcie efektu synergii pomiędzy wykorzystaniem różnego rodzaju technik komunikacji. Uzupełnienie udostępnionych formularzy elektronicznych o dostęp za pomocą telefonu, poczty elektronicznej czy komunikatorów internetowych czy VoIP centrum obsługi (call center) powinno znacznie podnieśd standard obsługi mieszkaoców a także zachęcid nowe grupy do korzystania ze zdalnych usług administracji publicznej. Dużą grupę usług, przede wszystkim informacyjnych ale też 35

36 wspomagających organizację (np. rezerwowanie terminu obsługi) można przenieśd do call center. Dzięki temu staną się dostępne dla n owych grup społeczeostwa, które nie mają dostępu do Internetu. Nawet tak proste medium jak SMS może zostad wykorzystane do realizacji prostych usług. Przykłady z rynku usług bankowych pokazują wyraźnie jak właśnie efekt synergii wpłynął na rozwój sektora banków internetowych. Odrębnym problemem jest polaczenie wszystkich informacji dotyczących obsługi mieszkaoców wewnątrz jednostki administracji publicznej. Także w tym aspekcie można odnaleźd przykłady rozwiązao z organizacji komercyjnych, które do obsługi tych zadao od wielu lat wykorzystują systemy CRM (Customer Relationship Mnanagement). Zaletą tych rozwiązao jest gromadzenie w jednym miejscu wszystkich informacji dotyczących kontaktów z klientem (mieszkaocem), systemy CRM mogą zostad zintegrowane z aplikacjami zaplecza (back-office) w celu zautomatyzowania kolekcjonowania danych. Oczywiste jest, że muszą zostad też połączone z systemami obsługi administracji elektronicznej i obiegu dokumentów. Dopiero jednak połączenie systemu CRM z infrastrukturą telekomunikacyjną i bazami danych daje dostęp do ich pełnej funkcjonalnoś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. 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 MSMQ, pliki w lokalnych lub sieciowych systemach plików, zapytania do baz danych z wykorzystaniem technologii ODBC i OLEDB, SMTP i POP3 do dostępu do poczty elektronicznej i wysyłania wiadomości e mail, 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 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 urzędu. 36

37 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. 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. 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. 37

38 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. 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. 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 38

39 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. 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. Mechanizm publikowania i subskrypcji Podstawowa infrastruktura Zarządzanie W zakresie zarządzania kontami użytkowników i mechanizmami uwierzytelnienia użytkowników proponowane jest zastosowanie usług katalogowych (LDAP). Usługi te pozwalają na uwierzytelnienie użytkownika w centralnej bazie danych oraz autoryzację dostępu do zasobów systemu w oparciu o protokół Kerberos. LDAP pozwala również na delegację praw do zarządzania określoną grupą komputerów i użytkowników poprzez wbudowane mechanizmy delegacji uprawnieo. W zakresie zarządzania i monitorowania środowiska serwerów I stacji roboczych, zdalnej instalacji oprogramowania i monitorowania stanu usług proponowane jest zastosowanie dwóch systemów: Zarządzania oprogramowaniem Zarządzania infrastrukturą sprzętową Bezpieczeństwo Mechanizmy katalogu LDAP muszą zapewnid możliwośd centralnego uwierzytelnienia użytkowników w oparciu o wspólną bazę danych. LDAP pozwoli również na wymuszenie w ramach całości systemu 39

40 wspólnej polityki haseł określającej parametry i złożonośd hasła, jak również warunki i długośd blokady kont itp. LDAP dostarczy mechanizmów zasad grupowych (group Policy) pozwalającego na wymuszenie na stacjach roboczych i serwerach centralnie konfigurowanych ustawieo systemu, uprawnieo i środowiska użytkownika. W oparciu o konta i grupy LDAP możliwe będzie kontrolowanie dostępu do zasobów usług, a ponieważ uwierzytelnienie LDAP oparte jest o standard protokołu Kerberos możliwe jest użycie tych danych we wszystkich systemach wspierających uwierzytelnienie Kerberos. Wraz z mechanizmami kontroli dostępu do zasobów zapewniony będzie mechanizm inspekcji dostępu do tych zasobów na różnym poziomie szczegółowości. W celu zapewnienia możliwości kontroli dostępu użytkowników do zasobów sieci internet proponowane jest użycie podsystemu, który pozwala na uwierzytelnienie I autoryzacje użytkowników w oparciu o katalog LDAP. W zakresie bezpiecznej infrastruktury dostępowej wymagana jest implementacja: Zapory ogniowej (Firewall) Systemu antywirusowego/ anty spyware. Usługi katalogowe LDAP Usługi katalogowe LDAP maja za zadanie dostarczyd możliwośd centralnego zarządzania zasobami systemu informatycznego. W ramach usług katalogowych możliwe będzie tworzenie i zarządzanie obiektami użytkowników i komputerów pracujących w ramach sieci, delegowanie uprawnieo do zarządzania tymi obiektami. Usługa LDAP dostarczy możliwości organizacji zasobów w ramach hierarchicznej struktury katalogu opartego na protokole LDAP w celu zarządzania tymi zasobami. Usługi LDAP dostarczą również mechanizmów silnego uwierzytelnienia i autoryzacji użytkowników w oparciu o protokół Kerberos. Usługa katalogowa LDAP pozwoli na logiczną organizacje obiektów w ramach organizacji i ustanowienie granic bezpieczeostwa pomiędzy organizacjami. Granice bezpieczeostwa w tym przypadku określają granice dostępu administracyjnego i dostępu do zasobów organizacji. LDAP jest to usługa oparta o dobrze określone standardy (DNS, LDAP, Kerberos) zapewniająca hierarchiczny system zarządzania zasobami i bezpieczeostwem sieci. Struktura logiczna katalogu LDAP zbudowana jest w oparciu o podstawowe elementy, z których budowana jest infrastruktura domeny. Elementy struktury logicznej katalogu to: Domena (Domain) - domena zawiera obiekty odpowiadające zasobom sieciowym (komputery, użytkownicy, drukarki itd.), każda z domen przechowuje informacje tylko o obiektach do niej należących. 40

41 Drzewo (Tree) - zgrupowanie lub hierarchiczne ustawienie jednej lub wielu domen LDAP, które współdzielą wspólną przestrzeo nazw DNS. Las (Forest) - zgrupowanie lub hierarchiczne ustawienie jednego lub wielu drzew domen LDAP, które tworzą rozdzieloną przestrzeo nazw. Wszystkie drzewa w lesie współdzielą schemat katalogu. Domeny LDAP mogą byd zorganizowane w ramach lasu w strukturze pojedynczego drzewa, w którym zachowana jest wspólna przestrzeo nazw DNS lub też w strukturze oddzielnych drzew z rozdzielną przestrzenią nazw DNS. W każdym przypadku domeny te współdzielą wspólny schemat oraz informację o konfiguracji lasu, która jest replikowana pomiędzy kontrolerami domeny w poszczególnych domenach. Użytkownicy w ramach lasu LDAP logują się w dowolnymi miejscu sieci na podstawie poświadczeo ze swojej własnej domeny. Usługi sieciowe, takie jak na przykład usługa poczty elektronicznej, mogą byd współdzielone przez wszystkie domeny w ramach jednego lasu. System musi spełniad następujące wymagania: a. Usługi katalogowe zgodne ze standardem LDAPv3 opisanym przez RFC3377, który zawiera: RFC 2251 Lightweight Directory Access Protocol (v3) RFC 2252 LDAP (v3): Attribute Syntax Definitions RFC 2253 LDAP (v3): UTF-8 String Representation of Distinguished Names RFC 2254 String Representation of LDAP Search Filters RFC 2255 The LDAP URL Format RFC 2256 A Summary of X.500(96) User Schema for use with LDAP (v3) RFC 2829 Authentication Methods for LDAP RFC 2830 LDAP (v3): Extensions for Transport Layer Security, wspierające także następujący zestaw RFC: RFC LDAP Control Extension for Simple Paged Results Manipulation RFC Using Domains in LDAP/X.500 Distinguished Names RFC LDAP Protocol (v3): Extensions for Dynamic Directory Services RFC Definition of the inetorgperson LDAP Object Class RFC Using Digest Authentication as an SASL Mechanism RFC LDAP Control Extension for Server Side Sorting of Search Results b. Usługi katalogowe udostępnią poniższe funkcje bez potrzeby instalowania dodatkowego oprogramowania ( prosto z pudełka ): zarządzania środowiskiem użytkownika oraz konfiguracją stacji roboczych dystrybucji oprogramowania na stacje robocze logowania za pomocą kart inteligentnych autentykacji użytkowników za pomocą protokołu Kerberos c. Usługi katalogowe zapewnią replikację typu multi-master (katalog na serwerach przechowujących repliki zawsze do odczytu i zapisu) d. Usługi katalogowe pozwolą na pracę w trybie aplikacyjnym wraz z możliwością instalacji wielu instancji na jednym serwerze. 41

42 e. Usługi katalogowe zapewnią możliwośd komunikacji z innymi aplikacjami za pomocą języka XML. f. Aplikacje posiadane (ew. planowane do wdrożenia) w Urzędzie będą integrowad się z usługami katalogowymi. Podsystem zarządzania tożsamością Przy rosnącej przyszłości liczbie użytkowników CSP 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 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: 42

43 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łonkowstwem, 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, 4. Portal CSP, 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) 43

44 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 Usługa współdzielenia i obiegu informacji portal wielofunkcyjny Z punktu widzenia pracownika jednostki administracji publicznej, proponowane rozwiązanie jest portalem urzędu umożliwiającym: Organizację pracy grupowej, Wspólną, bezpieczną pracę nad dokumentami, Publikację dokumentów, Wersjonowanie dokumentów (dla wersji roboczych), Podpisywanie dokumentów, Wykorzystanie mechanizmów portalu do budowy systemu zarządzania e-szkoleniami (elearning). Z uwagi na podjęcie przez urząd decyzji o standaryzacji posiadanych systemów, konieczne jest: Wykorzystanie portalu, jako standardowego interfejsu użytkownika dla wszystkich posiadanych aplikacji, Zapewnienie wymiany danych z innymi systemami, w tym z centralnymi systemami administracji publicznej. W takim zakresie proponujemy oparcie się o standardowe rozwiązania portalowe. Rozwiązanie to umożliwid ma budowę portalu dla całego regionu, umożliwiającego wykorzystanie wszystkich opisanych funkcjonalności. Oczywiście z funkcjonalnego punktu widzenia, jedną fizyczną infrastrukturę portalu należy zaprojektowad tak, by mogła stanowid zbiór WIELU niezależnych portali, które w zależności od nadanych uprawnieo mogą byd zarządzane niezależnie. Za pomocą rozwiązania portalowego należy stworzyd mechanizmy współpracy między działami/zespołami, udostępnid funkcje zarządzania zawartością, zaimplementowad procesy 44

45 przepływu dokumentów i spraw oraz zapewnid dostęp do informacji niezbędnych do realizacji założonych celów i procesów. Korzystając z szablonów witryn i innych funkcji zawartych w portalu, można będzie szybko i efektywnie tworzyd witryny odpowiadające potrzebom organizacji w zakresie publikowania określonej zawartości, zarządzania zawartością, zarządzania rekordami lub analiz biznesowych. Można będzie na przykład tworzyd witryny na poziomie urzędu, takie jak witryny portali organizacyjnych lub urzędowe witryny sieci Web, albo witryny specjalistyczne, takie jak repozytoria zawartości lub obszary robocze spotkao. Witryny te umożliwią współpracę i Udostępnianie informacji innym osobom, czy to wewnątrz, czy na zewnątrz organizacji. Konieczne jest też zaimplementowanie sprawnego mechanizmu wyszukiwania treści pozwalające skutecznie wyszukiwad osoby, dokumenty i dane, projektowad procesy biznesowe sterowane formularzami i uczestniczyd w tych procesach, a także uzyskiwad dostęp do dużych ilości danych biznesowych i analizowad je. Podsystem portalu wewnętrznego (dla pracowników urzędów) i zewnętrznego (dla klientów urzędu) ma wspomagad działania takie jak: Efektywna współpraca z innymi osobami w organizacji. W kalendarzach można na przykład sprawdzad terminy wydarzeo dotyczących zespołu, a w bibliotekach dokumentów przechowywad dokumenty związane z zespołem, działem lub organizacją. Można również omawiad różne problemy za pomocą blogów lub rejestrowad i przechowywad informacje na stronach typu wiki, które są bazami wiedzy zarządzanymi przez użytkowników. Tworzenie osobistych witryn, które umożliwiają zarządzanie informacjami i Udostępnianie ich innym użytkownikom. Założeniem jest możliwośd tworzenia portali i używania ich jako centralnej lokalizacji do wyświetlania wszystkich swoich dokumentów, zadao, łączy, kalendarza, współpracowników i innych osobistych informacji oraz do zarządzania całą tą zawartością. 45

46 Znajdowanie osób, wiedzy i danych w aplikacjach biznesowych. Przeszukując na przykład witryny typu Moja witryna w intranecie, można znaleźd osobę o określonych umiejętnościach lub zainteresowaniach, nawet nie znając jej imienia i nazwiska. Dane można również znaleźd w firmowej bazie danych lub aplikacji biznesowej, na przykład w systemie zarządzania relacjami z klientami (CRM). Zarządzanie dokumentami, rekordami i zawartością sieci Web. Urząd może na przykład opracowad proces wycofywania dokumentów lub anulowania ich ważności po upływie określonego czasu zgodnie z obowiązującym prawem. Zarządzanie procesami za pomocą mechanizmów workflow, w łatwy sposób definiowalnego przez użytkowników. Obsługiwanie formularzy w formacie XML, które są składnikiem obiegu informacji i komunikacji z podmiotami zewnętrznymi. Można więc będzie opracowywad formularze wniosków (na bazie opublikowanych w repozytorium schematów XML), tak aby użytkownicy mogli wypełniad te formularze bezpośrednio w przeglądarce lub za pomocą dostępnych mechanizmów trybu off-line. Dane wprowadzone w formularzu mogą byd przesyłane do bazy danych w sieci samorządu poprzez skrzynkę podawczą. Łatwe publikowanie raportów, list i kluczowych wskaźników wydajności (KPI) przez tworzenie łączy do aplikacji biznesowych, takich jak SAP, Siebel czy Microsoft SQL Server. Ponadto mechanizm portalu ma zawierad mechanizm udostępniania dla użytkowników wewnętrznych i zewnętrznych formularzy opartych na schematach XML i umożliwiających podpisanie wynikowego dokumentu XML zgodnie z ustawodawstwem. Portal powinien też zawierad mechanizmy przechowywania i udostępniania (zgodnie z uprawnieniami) wzorów (szablonów) dokumentów elektronicznych pochodzących z lokalnego lub centralnego repozytorium wzorów dokumentów (epuap). Przewiduje się, że szablony formularzy użytkownika może wdrażad dowolna osoba z odpowiednimi uprawnieniami. Szablon formularza użytkownika to szablon, który zawiera tylko funkcje deklaracyjne, takie jak formatowanie warunkowe (formatowanie warunkowe: Zmiana wyglądu formantu, w tym jego widoczności i trybu odczytu-zapisu, na podstawie wartości wprowadzonych w formularzu.), ale nie zawiera kodu zarządzanego. Szablony formularzy zatwierdzone przez administratora to szablony, które mogą zawierad kod zarządzany, wymagają pełnego zaufania, korzystają z połączenia danych zarządzanego przez administratora lub wymagają wdrożenia na dużą skalę w zbiorze witryn. Czynności przekazywania i weryfikacji podczas wdrażania szablonu formularza zatwierdzonego przez administratora wykonuje zwykle administrator całości portalu lub lokalnego podportalu do zarządzania którego uprawnienia zostały przekazane administratorom danej jednostki, chociaż zadanie weryfikacji może również wykonad projektant szablonu formularza Usługa pracy grupowej Jedną z podstawowych funkcjonalności portalu ma byd możliwośd tworzenia przestrzeni roboczych (workspace) dla instytucji, zespołów i pracowników. Osoba posiadająca odpowiednie uprawnienia ma mied w tym modelu możliwośd tworzenia każdej z wymienionych typów przestrzeni roboczych i administrowania nimi. 46

47 Założeniem jest hierarchiczna struktura portalu pozwalająca tworzyd różnego typu struktury przenosząc uprawnienia do nich z przestrzeni nadrzędnej lub nadając unikalne uprawnienia dla użytkowników wewnętrznych lub zewnętrznych. Ponadto wymagany jest mechanizm określania na bazie uprawnieo w LDAP które informacje są dostępne dla użytkowników lub ich grup, a które treści są dostępne dla wszystkich. Przewidywane gotowe struktury portalu to: Podprzestrzenie o takiej samej funkcjonalności, Biblioteki: dokumentów z możliwością wersjonowania dokumentów, formularzy opartych o schematy XML, stron Wiki, zdjęd lub rysunków, raportów, Ogłoszenia stałe lub z zadanym okresem ważności (publikacji), Kontakty, czyli bazy kontaktów, Grupy dyskusyjne Linki do dokumentów oraz stron wewnętrznych i zewnętrznych, Kalendarze prywatne i zespołowe, Zadania dla użytkowników i zespołów z mechanizmami monitoringu ich wykonania, wykresami Gantta, i śledzeniem zadao, Ankiety różnych typów z możliwością graficznej prezentacji ich rezultatów, Definiowalne listy, Tabele z możliwością definiowania kolumn (pól) i rekordów oraz wykonywania na nich różnych zdefiniowanych lub definiowalnych operacji wraz z generowaniem raportów, Wskaźniki KPI monitorujące status procesów i zadao, Tabele powstałe z importu arkuszy kalkulacyjnych, Dodatkowo wymagana jest możliwośd umieszczania w przestrzeniach roboczych okien różnego rodzaju aplikacji Centrum danych Funkcjonalnośd ta umożliwia stworzenie centralnego repozytorium danych elektronicznych rekordów. W proponowanym rozwiązaniu, administratorzy danych portalu wykorzystują centrum danych do określania typu oraz opisu metadanych dokumentów, które dzięki temu mogą byd zarządzane jak typowe rekordy. Centrum danych przedstawione na poniższym rysunku zawiera trzy repozytoria przygotowane do przechowywania projektów, raportów i umów kreowanych w postaci dokumentów XML poprzez odpowiednie departamenty czy biura. Przygotowywane są one w wyniku pracy zespołowej i mechanizmu workflow na wydzielonych przestrzeniach roboczych danego działu. Zaletą takiego rozwiązania jest automatyzacja segregowania dokumentów w skali firmy, odpowiedni sposób ich procesowania i przechowywania (retencji) oraz wykorzystanie spójnego sytemu opisu metadanych dokumentu. 47

48 Centrum Danych przekierowuje odpowiednie dokumenty do odpowiadających ich typom repozytoriów, na przykład raporty finansowe przygotowane przez księgowośd są przekierowywane do repozytorium danych finansowych. Osoba zarządzająca danymi może określid politykę unieważniania i usuwania dokumentów z repozytorium poprzez określenie czasu ich ważności oraz sposobu ich retencji. Na przykład dokumenty (lub ich typ opisany schematem XML), których okres ważności został określony na 10 lat będą po tym czasie trwale usuwane. Dodatkowe założenia dla architektury portalu wielofunkcyjnego Interfejs użytkownika: Praca z dokumentami typu XML w oparciu schematy XML przechowywane w repozytoriach portalu bezpośrednio z aplikacji opisanego w specyfikacji pakietu biurowego (otwieranie/zapisywanie dokumentów, podgląd wersji, mechanizmy ewidencjonowania i wyewidencjonowania dokumentów, edycja metryki dokumentu). Praca bezpośrednio z aplikacji pakietu biurowego z portalowymi rejestrami informacji typu kalendarze oraz bazy kontaktów Tworzenie witryn w ramach portalu bezpośrednio z aplikacji pakietu biurowego Możliwośd pracy off-line z plikami przechowywanymi w repozytoriach portalu Umożliwienie uruchomienia prezentacji stron w wersji pełnej oraz w wersji uproszczonej dla użytkowników urządzeo mobilnych PDA, telefon komórkowy). Integracja z pozostałymi modułami rozwiązania oraz innymi systemami: Wykorzystanie poczty elektronicznej do rozsyłania przez system wiadomości, powiadomieo, alertów do użytkowników portalu w postaci maili 48

49 Dostęp poprzez interfejs portalowy do całości bądź wybranych elementów skrzynek pocztowych użytkowników w komponencie poczty elektronicznej, z zapewnieniem podstawowej funkcjonalności pracy z tym systemem w zakresie czytania, tworzenia, przesyłania elementów Wykorzystanie oferowanego systemu poczty elektronicznej do umieszczania dokumentów w repozytoriach portalu poprzez przesyłanie ich w postaci załączników do maili Integracja z systemem obsługującym serwis WWW w zakresie publikacji treści z repozytoriów wewnętrznych firmy na zewnętrzne strony serwisu WWW (pliki, strony) Integracja z usługą katalogową w zakresie prezentacji informacji o pracownikach. Dane typu: imię, nazwisko, stanowisko, telefon, adres, miejsce w strukturze organizacyjnej mają stanowid źródło dla systemu portalowego Wsparcie dla standardu wymiany danych z innymi systemami w postaci XML, z wykorzystaniem komunikacji poprzez XML Web Services Mechanizm jednokrotnej identyfikacji (single sign-on) pozwalający na autoryzację użytkowników portalu i dostęp do danych w innych systemach biznesowych, niezintegrowanych z systemem LDAP. Przechowywanie całej zawartości portalu (strony, dokumenty, konfiguracja) we wspólnym dla całego serwisu podsystemie bazodanowym. Zarządzanie treścią i wyglądem portalu: Narzędzia umożliwiające prostą i intuicyjną publikację treści w formacie HTML w trybie WYSIWYG, bez konieczności znajomości języka HTML i innej wiedzy technicznej przez autorów treści Proste osadzenie i formatowanie plików graficznych, łącz (linków) różnych typów, tabel, paragrafów, wypunktowao itp. w treści artykułów publikowanych w intranecie (stron HTML) Spójne zarządzanie wyglądem stron intranetu, głównie pod kątem formatowania tekstu: możliwośd globalnego zdefiniowania krojów tekstu, które mogą byd wykorzystywane przez edytorów treści, możliwośd wklejania treści przy publikacji stron intranetu z plików tekstowych lub edytorów tekstu (np. MS Word) z zachowaniem lub z usunięciem formatowania oryginalnego Zarządzanie galeriami zasobów elektronicznych (pliki graficzne, firmy video, dokumenty), wykorzystywanymi przy tworzeniu stron intranetu i przechowywanymi w intranetowym repozytorium treści. Możliwośd współdzielenia tych zasobów na potrzeby stron umiejscowionych w różnych obszarach portalu intranetowego. Podstawowe funkcjonalności związane z wersjonowaniem i wyszukiwaniem tych zasobów Definiowanie szablonów dla układów stron (tzw. layout ów), określających ogólny układ stron intranetu oraz elementy wspólne dla stron opartych na tym samym szablonie. Możliwośd stworzenia wielu szablonów na potrzeby różnych układów stron w zależności od potrzeb funkcjonalnych w różnych częściach intranetu. Możliwośd generalnej zmiany wyglądu utworzonych już stron poprzez modyfikację szablonu, na którym zostały oparte Możliwośd wielokrotnego wykorzystania elementów zawartości intranetu (części treści publikowanych na stronach) w różnych częściach portalu, tzn. modyfikacja zawartości w jednym miejscu powoduje jej faktyczną zmianę na wszystkich stronach intranetu, gdzie dana treśd została opublikowana 49

50 Możliwośd odwzorowania w systemie CMS przyjętej wizualizacji portalu intranetowego (projekt graficzny i funkcjonalny). Organizacja i publikacja treści: Wersjonowanie treści stron intranetu, działające automatycznie przy wprowadzaniu kolejnych modyfikacji przez edytorów treści. Zastosowanie procesów zatwierdzania zawartości przez publikacją, tzn. Udostępnieniem jej dla szerokiego grona pracowników. Możliwośd zdefiniowania przynajmniej dwóch poziomów uprawnieo edytorów (edytor i recenzent), przy czym treści publikowane przez edytorów muszą uzyskad pozytywną akceptację recenzenta przed Udostępnieniem jej wszystkim użytkownikom intranetu. Możliwośd budowania hierarchicznej struktury stron portalu z prostym przenoszeniem stron i sekcji w ramach struktury nawigacji. Automatyczne tworzenie nawigacji na stronach intranetu, odwzorowujące obecną hierarchię. Automatyczne generowanie mapy stron portalu. Umożliwienie zarządzania poszczególnymi obszarami portalu osobom nietechnicznym, pełniącym rolę edytorów bądź administratorów merytorycznych. Istotne jest nieangażowanie zespołu IT w proces zarządzania treścią intranetu. Definiowanie uprawnieo użytkowników niezależnie do poszczególnych sekcji i stron intranetu, np. do obszarów poszczególnych spółek, dywizji, biur. Dotyczy to zarówno uprawnieo do odczytu zawartości, jak i edycji oraz publikacji (różni edytorzy zawartości intranetu w zależności od jego części). Definiowanie uprawnieo powinno byd dostępne dla administratorów merytorycznych poszczególnych obszarów portalu w sposób niezależny od pracowników działu IT. Automatyczne dołączanie do publikowanych stron informacji o autorze (edytorze) i dacie publikacji. Możliwośd personalizacji i filtrowania treści w intranecie w zależności od roli lub innych atrybutów pracownika (np. stanowiska, działu, pionu lub spółki). Funkcjonalnośd ta ma byd niezależna od mechanizmów zarządzania uprawnieniami użytkownika do zawartości, i ma mied na celu dostarczenie pracownikowi adekwatnych, skierowanych do niego informacji. Wsparcie dla obsługi różnych wersji językowych wybranych zawartości intranetu. Repozytoria dokumentów: Możliwośd prostej publikacji dokumentów w intranecie przez edytorów portalu. Prosty sposób publikacji dokumentów, funkcjonalny dostęp użytkowników intranetu do opublikowanych dokumentów Wykorzystanie do publikacji, edycji i przeglądania dokumentów w repozytorium narzędzi znanych użytkownikom np. pakiety biurowe czy przeglądarka internetowa Możliwośd tworzenia wielu tematycznych repozytoriów dokumentów w różnych częściach intranetu Możliwośd publikacji plików w strukturze katalogów Możliwośd definiowania metryki dokumentu, wypełnianej przez edytora przy publikacji pliku 50

51 Prosty, elastyczny i niezależny od działu IT mechanizm zarządzania uprawnieniami do publikowanych dokumentów. Możliwośd definiowania różnych poziomów uprawnieo przez administratorów merytorycznych, np. uprawnienia do odczytu, publikacji, usuwania Zarządzanie wersjonowaniem dokumentów: obsługa głównych oraz roboczych wersji (np.: 1.0, 1.1, 1.x 2.0), automatyczna kontrola wersji przy publikacji dokumentów Możliwośd zdefiniowania w systemie procesu zatwierdzania nowych lub modyfikowanych dokumentów. System informuje użytkowników recenzujących materiały o oczekujących na nich elementach do zatwierdzenia i pozwala podjąd decyzję o ich publikacji lub odrzuceniu Możliwośd tworzenia specjalnych repozytoriów lub katalogów przeznaczonych do przechowywania specyficznych rodzajów treści, np. galerie obrazów dla plików graficznych. Wyszukiwanie treści: Pełnotekstowe indeksowanie zawartości intranetu w zakresie różnych typów treści publikowanych w portalu, tj. stron portalu, dokumentów tekstowych (w szczególności dokumentów XML) Centralny mechanizm wyszukiwania treści dostępny dla użytkowników intranetu Opcja wyszukiwania zaawansowanego, np. wyszukiwanie wg typów treści, autorów, dat publikacji Możliwośd budowania wielu wyszukiwarek w różnych częściach portalu, służących do przeszukiwania określonych obszarów intranetu wg zadanych kryteriów, np. wg typów dokumentów Możliwośd definiowania słownika słów wykluczonych (często używanych) Możliwośd tworzenia linków sponsorowanych, prezentowanych wysoko w wynikach wyszukiwania w zależności od słów wpisanych w zapytaniu Podświetlanie w wynikach wyszukiwania odnalezionych słów kluczowych zadanych w zapytaniu. Przedstawianie w wynikach duplikatów plików Statystyki wyszukiwanych fraz Administracja intranetem i inne funkcjonalności Możliwośd definiowania ról / grup uprawnieo, w ramach których definiowane będą uprawnienia i funkcje użytkowników. Przypisywanie użytkowników do ról w oparciu o ich konta w LDAP lub poprzez grupy domenowe. Funkcjonalnośd zarządzania uprawnieniami dostępna dla administratorów merytorycznych intranetu, nie wymagająca szczególnych kompetencji technicznych Możliwośd określania uprawnieo do poszczególnych elementów zawartości intranetu tj. sekcja, pojedyncza strona, repozytorium dokumentów, katalogu dokumentów, pojedynczego dokumentu Generowanie powiadomieo pocztą elektroniczną dla użytkowników intranetu z informacją o publikacji najbardziej istotnych treści Definiowanie metryk opisujących dokumenty w poszczególnych repozytoriach portalu Konfigurowanie procesów zatwierdzania publikowanych stron i dokumentów. Możliwośd odrębnej konfiguracji w poszczególnych częściach portalu tj. definiowanie różnych edytorów i recenzentów w ramach różnych obszarów intranetu 51

52 Statystyki odwiedzin poszczególnych części i stron intranetu analiza liczby odsłon w czasie. Opcjonalnie zaawansowane statystyki i analizy Funkcjonalności wspierające pracę grupową - do wykorzystania na najniższym poziomie intranetu do celów pracy działów i zespołów zadaniowych. Funkcjonalności wspierające gromadzenie dokumentów, wsparcie komunikacji, planowanie zadao i wydarzeo Funkcjonalnośd publikowania w intranecie formularzy elektronicznych XML umożliwiających wizualizację zgodnie z definicjami w standardzie XSL w dowolnej przeglądarce obsługującej standard XML. Funkcjonalnośd definiowania procesów obiegu dokumentów (workflow) przy wykorzystaniu prostych w obsłudze narzędzi portalu. Usługa obiegu dokumentów i spraw Obieg dokumentów i spraw zaplanowano jako usługę portalu wielofunkcyjnego, zrealizowaną w ramach jego architektury i zawartych w nim mechanizmów workflow. Zakładana funkcjonalnośd ma umożliwiad przyjmowanie dokumentów elektronicznych od interesantów oraz tworzenie ich przez pracowników urzędu. Narzędzia systemu mają umożliwiad budowanie schematów obiegu sprawy (workflow) dla każdego rodzaju sprawy i przyjmowanego dokumentu oraz budowania schematów wewnętrznego obiegu dokumentów. 52

53 Konfiguracja standardowego workflow: Określenie, czy proces ma byd wysyłany kolejno czy równolegle do wskazanych osób. Określenie, czy istnieje możliwośd przypisywania swoich zadao w danym workflow innym osobom. Określenie, czy istnieje możliwośd zmiany workflow ad-hoc. Określenie osób akceptujących oraz powiadamianych w danym procesie. Określenie ilości dni niezbędnych do wykonania zadania. Określenie zachowania po wykonaniu lub odrzuceniu zadania. W zakładanym rozwiązaniu podstawowymi funkcjami udostępnianymi pracownikom urzędu są: Przyjęcie wniosku, Dekretacja dokumentu, Akceptacja dekretacji, Obsługa wniosku. Podstawowy system w urzędzie powinien realizowad funkcjonalności zilustrowane poniższym rysunkiem: Interesant, który jest osobą fizyczną działającą w imieniu własnym lub w imieniu firmy wnosi podanie. W tym celu system wystawia formularz umożliwiający utworzenie dokumentu, złożenie pod nim podpisu elektronicznego oraz przekazanie przygotowanego dokumentu do urzędu. Pracownicy urzędu będą mieli możliwośd realizowania różnych funkcji związanych z obsługą dokumentu i sprawy. 53

54 Architektura workflow W niniejszym projekcie założono, że realizowany system będzie stanowił odrębny system obsługi spraw w urzędzie, który będzie się komunikował się z systemami zewnętrznymi (np. e-puap), przeznaczonymi do przekazywania dokumentów i udostępniania usług dla systemów lokalnych. Dlatego poza funkcjonalnością przyjęcia dokumentu priorytetowym zadaniem jest Udostępnienie funkcji systemu w technologii WebServices oraz możliwośd wykorzystywania zewnętrznych serwisów WS. Realizacja powyższych funkcjonalności wymaga zastosowania architektury bazującej na udostępnianych serwisach poszczególnych komponentów. Takie przygotowanie systemu umożliwia optymalne wykorzystanie narzędzi, integrację z innymi systemami oraz rozszerzanie modelu o usługi udostępniane przez inne systemy. System opracowany w ramach niniejszego projektu musi zostad rozszerzony o następujące funkcjonalności: wystawianie Urzędowego Poświadczenia Odbioru dla przyjmowanych dokumentów, doręczenie dokumentu elektronicznego (decyzji lub wezwania) obywatelowi lub firmie, wykonanie weryfikacji podpisów i zabezpieczenie ważności przez wykonanie paczki XAdES-A, przekazanie tzw. paczki archiwalnej do Archiwum Paostwowego. Formularze elektroniczne 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 54

55 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. Szczegółowy opis zasad tworzenia dokumentu elektronicznego został przyjęty zgodnie z opublikowanym na portalu epuap standardem: 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: 55

Platforma Usług dla Obywateli. Citizen Service Platform (CSP)

Platforma Usług dla Obywateli. Citizen Service Platform (CSP) Platforma Usług dla Obywateli Citizen Service Platform (CSP) Spis treści Streszczenie... 3 Założenia ogólne... 4 Założenia organizacyjno-prawne.... 5 Skutki społeczne wprowadzenia rozwiązania... 6 Założenia

Bardziej szczegółowo

Platforma Usług dla Obywateli - Microsoft Citizen Service Platform

Platforma Usług dla Obywateli - Microsoft Citizen Service Platform Platforma Usług dla Obywateli - Microsoft Citizen Service Platform Paweł Walczak pawel.walczak@microsoft.com CSP w kilku słowach Citizen Services Platform Ogólnoświatowy projekt Microsoft na bazie Doświadczeń

Bardziej szczegółowo

Platforma epuap. Igor Bednarski kierownik projektu epuap2 CPI MSWiA. Kraków, 16.05.2011 r.

Platforma epuap. Igor Bednarski kierownik projektu epuap2 CPI MSWiA. Kraków, 16.05.2011 r. Platforma epuap Igor Bednarski kierownik projektu epuap2 CPI MSWiA Kraków, 16.05.2011 r. Agenda 1. Czym jest epuap 2. Cele projektu epuap2 3. Możliwości portalu 4. Komunikacja poprzez epuap 5. Stan zaawansowania

Bardziej szczegółowo

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU

ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO W RAMACH PROJEKTU Projekt Rozwój elektronicznej administracji w samorządach województwa mazowieckiego wspomagającej niwelowanie dwudzielności potencjału województwa ZAŁOŻENIA TECHNICZNO-TECHNOLOGICZNE SYSTEMU BUDOWANEGO

Bardziej szczegółowo

Platforma epuap. 1-3 marca 2011

Platforma epuap. 1-3 marca 2011 Platforma epuap 1-3 marca 2011 Co to jest epuap? elektroniczna Platforma Usług Administracji Publicznej (epuap) to system informatyczny, na którym instytucje publiczne udostępniają usługi oparte na elektronicznych

Bardziej szczegółowo

Kraków, 2 kwietnia 2004 r.

Kraków, 2 kwietnia 2004 r. Realizacja projektu Rozbudowa systemów elektronicznej administracji w Małopolsce w kontekście Wrót Małopolski oraz E-PUAP Kraków, 2 kwietnia 2004 r. 1 Agenda Podstawowe założenia Miejsce Wrót Małopolski

Bardziej szczegółowo

Ocena stanu i zasadnicze kierunki informatyzacji administracji publicznej

Ocena stanu i zasadnicze kierunki informatyzacji administracji publicznej Główne cele konferencji: Ocena stanu i zasadnicze kierunki informatyzacji administracji publicznej Nowe oblicze epuap Mariusz Madejczyk Ministerstwo Spraw Wewnętrznych i Administracji 1 Główne cele warsztatów

Bardziej szczegółowo

e-administracja Uniwersytet Jagielloński Wydział Prawa i Administracji mgr inż.piotr Jarosz

e-administracja Uniwersytet Jagielloński Wydział Prawa i Administracji mgr inż.piotr Jarosz e-administracja Uniwersytet Jagielloński Wydział Prawa i Administracji mgr inż.piotr Jarosz Definicje e-administracji Elektroniczna administracja to wykorzystanie technologii informatycznych i telekomunikacyjnych

Bardziej szczegółowo

Instrukcja integratora - obsługa dużych plików w epuap2

Instrukcja integratora - obsługa dużych plików w epuap2 Instrukcja integratora - obsługa dużych plików w epuap2 Wersja: 1.1 Strona 1 z 18 Spis treści SPIS TREŚCI... 2 WPROWADZENIE ORAZ INFORMACJE OGÓLNE... 3 1.1 WSTĘP... 3 1.2 WARUNKI KONIECZNE DO SPEŁNIENIA

Bardziej szczegółowo

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl

omnia.pl, ul. Kraszewskiego 62A, 37-500 Jarosław, tel. +48 16 621 58 10 www.omnia.pl kontakt@omnia.pl .firma Dostarczamy profesjonalne usługi oparte o nowoczesne technologie internetowe Na wstępie Wszystko dla naszych Klientów Jesteśmy świadomi, że strona internetowa to niezastąpione źródło informacji,

Bardziej szczegółowo

Założenia i stan realizacji projektu epuap2

Założenia i stan realizacji projektu epuap2 Założenia i stan realizacji projektu epuap2 Michał Bukowski Analityk epuap Serock, 28 października 2009 r. Agenda 1. Projekt epuap - cele i zakres. 2. Zrealizowane zadania w ramach epuap. 3. Projekt epuap2

Bardziej szczegółowo

Projekt epuap obecny stan realizacji i plany na przyszłość

Projekt epuap obecny stan realizacji i plany na przyszłość Projekt epuap obecny stan realizacji i plany na przyszłość Waldemar Ozga Centrum Projektów Informatycznych MSWiA Projekt współfinansowany Agenda 1. Czym jest epuap 2. Korzyści z zastosowanie epuap 3. Funkcjonowanie

Bardziej szczegółowo

Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna

Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna 1. Wstęp Wprowadzenie do PKI Infrastruktura klucza publicznego (ang. PKI - Public Key Infrastructure) to termin dzisiaj powszechnie spotykany. Pod tym pojęciem kryje się standard X.509 opracowany przez

Bardziej szczegółowo

Zastosowania PKI dla wirtualnych sieci prywatnych

Zastosowania PKI dla wirtualnych sieci prywatnych Zastosowania PKI dla wirtualnych sieci prywatnych Andrzej Chrząszcz NASK Agenda Wstęp Sieci Wirtualne i IPSEC IPSEC i mechanizmy bezpieczeństwa Jak wybrać właściwą strategię? PKI dla VPN Co oferują dostawcy

Bardziej szczegółowo

epuap Opis standardowych elementów epuap

epuap Opis standardowych elementów epuap epuap Opis standardowych elementów epuap Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka SPIS TREŚCI SPIS TREŚCI...

Bardziej szczegółowo

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów

Bardziej szczegółowo

Platforma epuap. Igor Bednarski kierownik projektu epuap2 CPI MSWiA. Kraków, 18.05.2011 r.

Platforma epuap. Igor Bednarski kierownik projektu epuap2 CPI MSWiA. Kraków, 18.05.2011 r. Platforma epuap Igor Bednarski kierownik projektu epuap2 CPI MSWiA Kraków, 18.05.2011 r. Agenda 1. Czym jest epuap 2. Cele projektu epuap2 3. Możliwości portalu 4. Komunikacja poprzez epuap 5. Stan zaawansowania

Bardziej szczegółowo

Ramy Interoperacyjności Systemów Administracji Publicznej

Ramy Interoperacyjności Systemów Administracji Publicznej Ramy Interoperacyjności Systemów Administracji Publicznej (Connected Government Framework) 2008, Microsoft Corporation Spis treści Wprowadzenie... 6 Struktura biznesowa RISA... 6 Co to jest e-administracja?...

Bardziej szczegółowo

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI Instrukcja użytkownika Narzędzie do modelowania procesów BPEL Warszawa, lipiec 2009 r. UNIA EUROPEJSKA EUROPEJSKI FUNDUSZ

Bardziej szczegółowo

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz Część I -ebxml Po zrealizowaniu materiału student będzie w stanie omówić potrzeby rynku B2B w zakresie przeprowadzania transakcji przez Internet zaprezentować architekturę ebxml wskazać na wady i zalety

Bardziej szczegółowo

Internetowe Konto Pacjenta

Internetowe Konto Pacjenta Internetowe Konto Pacjenta Bezpieczne rozwiązanie dla Pacjentów i Lekarzy Tomasz Orlewicz Dyrektor Obszaru Biznesowego tomasz.orlewicz@unizeto.pl Warszawa, 28 listopada 2011 Internetowe Konto Pacjenta

Bardziej szczegółowo

ZAŁĄCZNIK NR 1 DO REGULAMINU SERWISU ZNANEEKSPERTKI.PL POLITYKA OCHRONY PRYWATNOŚCI

ZAŁĄCZNIK NR 1 DO REGULAMINU SERWISU ZNANEEKSPERTKI.PL POLITYKA OCHRONY PRYWATNOŚCI ZAŁĄCZNIK NR 1 DO REGULAMINU SERWISU ZNANEEKSPERTKI.PL POLITYKA OCHRONY PRYWATNOŚCI Headlines Spółka z ograniczoną odpowiedzialnością i spółka spółka komandytowa szanuje i troszczy się o prawo do prywatności

Bardziej szczegółowo

SSL (Secure Socket Layer)

SSL (Secure Socket Layer) SSL --- Secure Socket Layer --- protokół bezpiecznej komunikacji między klientem a serwerem, stworzony przez Netscape. SSL w założeniu jest podkładką pod istniejące protokoły, takie jak HTTP, FTP, SMTP,

Bardziej szczegółowo

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem.

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium. 1. Wnioskodawca przeprowadził inwentaryzację zasobów nauki objętych projektem. Kryteria merytoryczne wyboru projektów dla poddziałania 2.3.1 Cyfrowe udostępnianie informacji sektora publicznego (ISP) ze źródeł administracyjnych oraz zasobów nauki Programu Operacyjnego Polska Cyfrowa

Bardziej szczegółowo

ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ

ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ WYMAGANIA BEZPIECZEŃSTWA DLA SYSTEMÓW IT Wyciąg z Polityki Bezpieczeństwa Informacji dotyczący wymagań dla systemów informatycznych. 1 Załącznik Nr 3 do Część II SIWZ Wymagania

Bardziej szczegółowo

Warszawa, dnia 16 kwietnia 2013 r. Poz. 463 ROZPORZĄDZENIE MINISTRA ZDROWIA 1) z dnia 28 marca 2013 r.

Warszawa, dnia 16 kwietnia 2013 r. Poz. 463 ROZPORZĄDZENIE MINISTRA ZDROWIA 1) z dnia 28 marca 2013 r. DZIENNIK USTAW RZECZYPOSPOLITEJ POLSKIEJ Warszawa, dnia 16 kwietnia 2013 r. Poz. 463 ROZPORZĄDZENIE MINISTRA ZDROWIA 1) z dnia 28 marca 2013 r. w sprawie wymagań dla Systemu Informacji Medycznej 2) Na

Bardziej szczegółowo

Projekty realizowane przez CPI MSWiA

Projekty realizowane przez CPI MSWiA Projekty realizowane przez CPI MSWiA CPI MSWiA Państwowa jednostka budżetowa utworzona zarządzeniem Nr 11 Ministra Spraw Wewnętrznych i Administracji z dnia 21 stycznia 2008 r. (Dz. Urz. Ministra Spraw

Bardziej szczegółowo

Elektroniczna Księga Wieczysta

Elektroniczna Księga Wieczysta Elektroniczna Księga Wieczysta Aspekty wdrażania systemu informatycznego świadczącego usługi drogą elektroniczną Robert Ciurkot Dyrektor Departamentu Konsultingu Grupa Bull Grupa Bull na świecie 50 krajów

Bardziej szczegółowo

sms-api.pl Zastosowania SMS w rozwiązaniach biznesowych www.sms-api.pl niezawodna bramka SMS

sms-api.pl Zastosowania SMS w rozwiązaniach biznesowych www.sms-api.pl niezawodna bramka SMS sms-api.pl Zastosowania SMS w rozwiązaniach biznesowych Agenda Możliwości bramki SMS Zastosowania Możliwości integracyjne Wskaźniki jakościowe Korzyści Do kogo skierowana jest usługa Źródła dodatkowych

Bardziej szczegółowo

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium

Opis znaczenia kryterium. Lp. Nazwa kryterium Opis kryterium Kryteria merytoryczne wyboru projektów dla poddziałania 2.3.2 Cyfrowe udostępnienie zasobów kultury Programu Operacyjnego Polska Cyfrowa na lata 2014-2020 Typ projektu Cyfrowe udostępnienie zasobów kultury

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

Dzień dobry Państwu, nazywam się Dariusz Kowal, jestem pracownikiem Śląskiego Centrum Społeczeństwa Informacyjnego, gdzie pełnię rolę inspektora ds.

Dzień dobry Państwu, nazywam się Dariusz Kowal, jestem pracownikiem Śląskiego Centrum Społeczeństwa Informacyjnego, gdzie pełnię rolę inspektora ds. Dzień dobry Państwu, nazywam się Dariusz Kowal, jestem pracownikiem Śląskiego Centrum Społeczeństwa Informacyjnego, gdzie pełnię rolę inspektora ds. CC SEKAP. W dniu dzisiejszym przedstawię Państwu w jaki

Bardziej szczegółowo

Realizacja projektu e-puap.

Realizacja projektu e-puap. Realizacja projektu e-puap. Współpraca Ministerstwa Spraw Wewnętrznych i Administracji z Województwem Małopolskim. Marek Słowikowski Dyrektor Departamentu Informatyzacji 17.02.2006 KONFERENCJA "E-ADMINISTRACJA

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r.

ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r. 132 ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r. w sprawie wymogów dla systemów wyliczania utrzymywanych w podmiotach objętych obowiązkowym systemem gwarantowania Na podstawie art. 38j

Bardziej szczegółowo

Studium przypadku Bank uniwersalny

Studium przypadku Bank uniwersalny Studium przypadku Bank uniwersalny Przedsiębiorstwo będące przedmiotem studium przypadku jest bankiem uniwersalnym. Dominującą strategią banku jest przywództwo produktowe. Cele banku koncentrują się, zatem

Bardziej szczegółowo

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42

SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH. info@prointegra.com.pl tel: +48 (032) 730 00 42 SYSTEM VILM ZARZĄDZANIE CYKLEM ŻYCIA ŚRODOWISK WIRTUALNYCH info@prointegra.com.pl tel: +48 (032) 730 00 42 1. WPROWADZENIE... 3 2. KORZYŚCI BIZNESOWE... 4 3. OPIS FUNKCJONALNY VILM... 4 KLUCZOWE FUNKCJE

Bardziej szczegółowo

System ZSIN wyzwanie dla systemów do prowadzenia EGiB

System ZSIN wyzwanie dla systemów do prowadzenia EGiB System ZSIN wyzwanie dla systemów do prowadzenia EGiB Szymon Rymsza Główny specjalista w projekcie ZSIN - Faza I Główny Urząd Geodezji i Kartografii Warszawa, 10-11.09.2015 r. Agenda spotkania 1. Dostosowanie

Bardziej szczegółowo

Zapytanie ofertowe. zakup usługi doradczej z zakresu integracji systemu z istniejącym w firmie oprogramowaniem sztuk 1.

Zapytanie ofertowe. zakup usługi doradczej z zakresu integracji systemu z istniejącym w firmie oprogramowaniem sztuk 1. 101 Studio DTP Tomasz Tęgi i Spółka Sp. z o.o. ul. Ekonomiczna 30/36 93-426 Łódź Tel. +4842/250 70 92-94 Fax. +4842/250 70 95 NIP: 725-12-59-070 REGON: 471-35-84-10 Łódź, 10.02.2011 (miejsce, data) Zapytanie

Bardziej szczegółowo

W perspektywie kluczowych projektów informatycznych MSWiA uwarunkowania prawne, koncepcyjne i realizacyjne

W perspektywie kluczowych projektów informatycznych MSWiA uwarunkowania prawne, koncepcyjne i realizacyjne Czy realizacja projektu to dostarczenie narzędzia biznesowego, czy czynnik stymulujący rozwój społeczeństwa informacyjnego? W perspektywie kluczowych projektów informatycznych MSWiA uwarunkowania prawne,

Bardziej szczegółowo

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B

Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Załącznik Nr 1 Wzorcowy załącznik techniczny, do umowy w sprawie przesyłania faktur elektronicznych pomiędzy Firmą A oraz Firmą B Wersja 1.0 Na podstawie: Europejskiej Modelowej Umowy o EDI (w skrócie:

Bardziej szczegółowo

ARIADNA - Dostosowanie Profilu Zaufanego do unijnych wymogów rozporządzenia eidas

ARIADNA - Dostosowanie Profilu Zaufanego do unijnych wymogów rozporządzenia eidas Lider: Ministerstwo Administracji i Cyfryzacji Partner: Centrum Projektów Informatycznych ARIADNA - Dostosowanie Profilu Zaufanego do unijnych wymogów rozporządzenia eidas CEL PROJEKTU Głównym celem projektu

Bardziej szczegółowo

ROZPORZĄDZENIE MINISTRA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI 1) z dnia 2007 r.

ROZPORZĄDZENIE MINISTRA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI 1) z dnia 2007 r. Projekt z dnia 8 października 2007 r. ROZPORZĄDZENIE MINISTRA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI 1) z dnia 2007 r. w sprawie dokonywania wpisów danych SIS oraz aktualizowania, usuwania i wyszukiwania danych

Bardziej szczegółowo

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

Bardziej szczegółowo

Linia współpracy Projekt Informatyzacja JST z wykorzystaniem technologii przetwarzania w Chmurze. Warszawa, 17 lutego 2015 r.

Linia współpracy Projekt Informatyzacja JST z wykorzystaniem technologii przetwarzania w Chmurze. Warszawa, 17 lutego 2015 r. Linia współpracy Projekt Informatyzacja JST z wykorzystaniem technologii przetwarzania w Chmurze Warszawa, 17 lutego 2015 r. Chmura obliczeniowa w Programie Zintegrowanej Informatyzacji Państwa Zbudowanie

Bardziej szczegółowo

ZETO Koszalin Sp. z o.o.

ZETO Koszalin Sp. z o.o. Izabela Wrzeszcz Dział Nowych Usług ZETO Koszalin Sp. z o.o. Zakład Elektronicznej Techniki Obliczeniowej Sp. z o.o. Firma powstała w 1967 roku Największa firma informatyczna w regionie PomorzaŚrodkowego

Bardziej szczegółowo

bo od menedżera wymaga się perfekcji ANKIETY ONLINE W SYSTEMIE BUSINESS NAVIGATOR

bo od menedżera wymaga się perfekcji ANKIETY ONLINE W SYSTEMIE BUSINESS NAVIGATOR bo od menedżera wymaga się perfekcji ANKIETY ONLINE W SYSTEMIE BUSINESS NAVIGATOR SPIS TREŚCI 1. INFORMACJE O FIRMIE... 3 2. CHARAKTERYSTYKA PLATFORMY BUSINESS NAVIGATOR... 4 3. WYKORZYSTANIE USŁUGI ANKIETY

Bardziej szczegółowo

Interoperacyjność system nie działa w próżni

Interoperacyjność system nie działa w próżni Interoperacyjność system nie działa w próżni Tomasz Rakoczy Centrum Projektów Informatycznych Warszawa, dnia 8 maja 2012 r. Agenda Interoperacyjność Narzędzia interoperacyjności Interfejsy systemu epuap

Bardziej szczegółowo

E-fakturowanie w praktyce ze szczególnym uwzględnieniem systemów EDI. Warszawa, 25 września 2006 roku

E-fakturowanie w praktyce ze szczególnym uwzględnieniem systemów EDI. Warszawa, 25 września 2006 roku E-fakturowanie w praktyce ze szczególnym uwzględnieniem systemów EDI Warszawa, Uregulowanie w przepisach ROZPORZĄDZENIE MINISTRA FINANSÓW z dnia 14 lipca 2005 r. w sprawie wystawiania oraz przesyłania

Bardziej szczegółowo

Oracle COREid Federation Przegląd

Oracle COREid Federation Przegląd Oracle COREid Federation Przegląd Dokument techniczny Oracle Listopad 2005 ORACLE FUSION MIDDLEWARE Oracle COREid Federation Wprowadzenie COREid Federation to jedyny w branży serwer federacji tożsamości,

Bardziej szczegółowo

Wiarygodna elektroniczna dokumentacja medyczna dr inż. Kajetan Wojsyk

Wiarygodna elektroniczna dokumentacja medyczna dr inż. Kajetan Wojsyk Wiarygodna elektroniczna dokumentacja medyczna dr inż. Kajetan Wojsyk Zastępca Dyrektora ds. Europejskich Centrum Systemów Informacyjnych Ochrony Zdrowia V Konferencja i Narodowy Test Interoperacyjności

Bardziej szczegółowo

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej

Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Aplikacje webowe wspomagające działalność przedsiębiorstwa na przykładzie przychodni stomatologicznej Małgorzata Barańska Wydział Informatyki i Zarządzania, Politechnika Wrocławska Beata Laszkiewicz Wydział

Bardziej szczegółowo

Bezpieczeństwo w sieci I. a raczej: zabezpieczenia wiarygodnosć, uwierzytelnianie itp.

Bezpieczeństwo w sieci I. a raczej: zabezpieczenia wiarygodnosć, uwierzytelnianie itp. Bezpieczeństwo w sieci I a raczej: zabezpieczenia wiarygodnosć, uwierzytelnianie itp. Kontrola dostępu Sprawdzanie tożsamości Zabezpieczenie danych przed podsłuchem Zabezpieczenie danych przed kradzieżą

Bardziej szczegółowo

INTERNET - Wrocław 2005. Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid

INTERNET - Wrocław 2005. Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid Bartłomiej Balcerek Wrocławskie Centrum Sieciowo-Superkomputerowe Plan prezentacji Podstawowe pojęcia z dziedziny gridów Definicja

Bardziej szczegółowo

Łódź, 01.02.2011 (miejsce, data)

Łódź, 01.02.2011 (miejsce, data) 101 Studio DTP Tomasz Tęgi i Spółka Sp. z o.o. ul. Ekonomiczna 30/36 93-426 Łódź Tel. +4842/250 70 92-94 Fax. +4842/250 70 95 NIP: 725-12-59-070 REGON: 471-35-84-10 Łódź, 01.02.2011 (miejsce, data) Zapytanie

Bardziej szczegółowo

System DiLO. Opis interfejsu dostępowego v. 2.0

System DiLO. Opis interfejsu dostępowego v. 2.0 System DiLO Opis interfejsu dostępowego v. 2.0 Warszawa 2015 1 Wprowadzone zmiany Wersja Opis 1.0 Wersja bazowa 1.1 Dodanie możliwości przejścia z wydania karty w POZ (WK-POZ) do zabiegu operacyjnego (ZAB-OPER)

Bardziej szczegółowo

Elektroniczna Skrzynka Podawcza

Elektroniczna Skrzynka Podawcza Elektroniczna Skrzynka Podawcza Instrukcja dla administratora Wersja 1.6.0 Przewodnik przeznaczony jest dla użytkowników, którzy administrują kontem urzędu w systemie Elektronicznej Skrzynki Podawczej.

Bardziej szczegółowo

Strategia informatyzacji sektora ochrony zdrowia

Strategia informatyzacji sektora ochrony zdrowia Strategia informatyzacji sektora ochrony zdrowia dr inż. Kajetan Wojsyk, z-ca Dyrektora ds. Europejskich Centrum Systemów Informacyjnych Ochrony Zdrowia w Warszawie Konferencja MedTrends, Zabrze, 2016-03-18

Bardziej szczegółowo

Program pl.id a standaryzacja i integracja procesów wewnątrz administracji publicznej

Program pl.id a standaryzacja i integracja procesów wewnątrz administracji publicznej Program pl.id a standaryzacja i integracja procesów wewnątrz administracji publicznej (Na przykładzie Urzędu m.st. Warszawy) Olsztyn - Stare Jabłonki, 10-12 marca 2011 r. Warszawa podstawowe informacje

Bardziej szczegółowo

Wykład 4 Bezpieczeństwo przesyłu informacji; Szyfrowanie

Wykład 4 Bezpieczeństwo przesyłu informacji; Szyfrowanie Wykład 4 Bezpieczeństwo przesyłu informacji; Szyfrowanie rodzaje szyfrowania kryptografia symetryczna i asymetryczna klucz publiczny i prywatny podpis elektroniczny certyfikaty, CA, PKI IPsec tryb tunelowy

Bardziej szczegółowo

Zdalne logowanie do serwerów

Zdalne logowanie do serwerów Zdalne logowanie Zdalne logowanie do serwerów Zdalne logowanie do serwerów - cd Logowanie do serwera inne podejście Sesje w sieci informatycznej Sesje w sieci informatycznej - cd Sesje w sieci informatycznej

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

JTW SP. Z OO. Zapytanie ofertowe. Zewnętrzny audyt jakościowy projektu technicznego dedykowanego systemu B2B Platforma Integracji Serwisowej

JTW SP. Z OO. Zapytanie ofertowe. Zewnętrzny audyt jakościowy projektu technicznego dedykowanego systemu B2B Platforma Integracji Serwisowej JTW SP. Z OO Zapytanie ofertowe Zewnętrzny audyt jakościowy projektu technicznego dedykowanego systemu B2B Platforma Integracji Serwisowej Strona 1 z 8 Spis treści 1. Klauzula poufności... 3 2. Wskazówki

Bardziej szczegółowo

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Zasady Wykorzystywania Plików Cookies

Zasady Wykorzystywania Plików Cookies Zasady Wykorzystywania Plików Cookies Definicje i objaśnienia używanych pojęć Ilekroć w niniejszym zbiorze Zasad wykorzystywania plików Cookies pojawia się któreś z poniższych określeń, należy rozumieć

Bardziej szczegółowo

SiR_13 Systemy SCADA: sterowanie nadrzędne; wizualizacja procesów. MES - Manufacturing Execution System System Realizacji Produkcji

SiR_13 Systemy SCADA: sterowanie nadrzędne; wizualizacja procesów. MES - Manufacturing Execution System System Realizacji Produkcji System informatyczny na produkcji: Umożliwi stopniowe, ale jednocześnie ekonomiczne i bezpieczne wdrażanie i rozwój aplikacji przemysłowych w miarę zmiany potrzeb firmy. Może adoptować się do istniejącej

Bardziej szczegółowo

POLITYKA PRYWATNOŚCI Konkurs wiedzy dermatologicznej dla lekarzy

POLITYKA PRYWATNOŚCI Konkurs wiedzy dermatologicznej dla lekarzy POLITYKA PRYWATNOŚCI Konkurs wiedzy dermatologicznej dla lekarzy Organizowanego przez HealthThink public relations Niniejsza Polityka Prywatności określa zasady przechowywania i dostępu do informacji na

Bardziej szczegółowo

e-awizo SYSTEM POTWIERDZANIA DORĘCZEŃ POCZTY ELEKTRONICZNEJ

e-awizo SYSTEM POTWIERDZANIA DORĘCZEŃ POCZTY ELEKTRONICZNEJ e-awizo SYSTEM POTWIERDZANIA DORĘCZEŃ POCZTY ELEKTRONICZNEJ www.e-awizo.pl BrainSoft sp. z o. o. ul. Bolesława Chrobrego 14/2 65-052 Zielona Góra tel.68 455 77 44 fax 68 455 77 40 e-mail: biuro@brainsoft.pl

Bardziej szczegółowo

System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch

System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch System Rozproszone Komunikator Dokumentacja Maciej Muszkowski Jakub Narloch Wymagania Zgodnie ze wstępnymi założeniami komunikator musi, realizowad następujące funkcje: 1. Jest oparty o model Peer2Peer,

Bardziej szczegółowo

Przewodnik użytkownika

Przewodnik użytkownika STOWARZYSZENIE PEMI Przewodnik użytkownika wstęp do podpisu elektronicznego kryptografia asymetryczna Stowarzyszenie PEMI Podpis elektroniczny Mobile Internet 2005 1. Dlaczego podpis elektroniczny? Podpis

Bardziej szczegółowo

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne.

Dodatkowo, w przypadku modułu dotyczącego integracji z systemami partnerów, Wykonawca będzie przeprowadzał testy integracyjne. Załącznik nr 1a do Zapytania ofertowego nr POIG.08.02-01/2014 dotyczącego budowy oprogramowania B2B oraz dostawcy sprzętu informatycznego do projektu pn. Budowa systemu B2B integrującego zarządzanie procesami

Bardziej szczegółowo

TC Faktury zarządzanie fakturami kosztowymi w firmie

TC Faktury zarządzanie fakturami kosztowymi w firmie TC Faktury zarządzanie fakturami kosztowymi w firmie Aplikacja TC Faktury przechowuje i tworzy rejestr wszystkich faktur kosztowych. Integruje się z posiadanym system FK i zarządza obiegiem faktur. Z poziomu

Bardziej szczegółowo

Zarządzanie kontem użytkownika Lokalnego Systemu Informatycznego w ramach RPO WSL 2014-2020. Katowice, 15 października 2015r

Zarządzanie kontem użytkownika Lokalnego Systemu Informatycznego w ramach RPO WSL 2014-2020. Katowice, 15 października 2015r Zarządzanie kontem użytkownika Lokalnego Systemu Informatycznego w ramach RPO WSL 2014-2020 Katowice, 15 października 2015r Rejestracja konta Użytkownicy rejestrują konta samodzielnie poprzez formularz

Bardziej szczegółowo

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego a. Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego Ministerstwo Finansów Departament Informatyzacji 23 May 2016 Version 1.3 i Spis treści 1 Przygotowanie danych JPK... 3 1.1 Przygotowanie

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

System Cyfrowego Obiegu Dokumentów to rozwiązanie ułatwiające procesy przechowywania, zarządzania i wyszukiwania dokumentów.

System Cyfrowego Obiegu Dokumentów to rozwiązanie ułatwiające procesy przechowywania, zarządzania i wyszukiwania dokumentów. System Cyfrowego Obiegu Dokumentów to rozwiązanie ułatwiające procesy przechowywania, zarządzania i wyszukiwania dokumentów. Większości procesów biznesowych występujących w organizacji towarzyszą dokumenty.

Bardziej szczegółowo

Sylabus modułu e-urzędnik

Sylabus modułu e-urzędnik Sylabus modułu e-urzędnik Wymagania konieczne: Zakłada się, że przystępując do egzaminu modułu e-urzędnik, zdający będzie miał opanowany blok umiejętności i wiadomości podstawowych w zakresie zgodnym z

Bardziej szczegółowo

GEOPORTAL 2. Broker INSPIRE Broker krajowy Broker branżowy. Eliza Asendy, Marek Szulc 23-25.10.2012, Warszawa

GEOPORTAL 2. Broker INSPIRE Broker krajowy Broker branżowy. Eliza Asendy, Marek Szulc 23-25.10.2012, Warszawa GEOPORTAL 2 Broker INSPIRE Broker krajowy Broker branżowy Eliza Asendy, Marek Szulc 23-25.10.2012, Warszawa Czym jest GEOPORTAL 2? GEOPORTAL 2 jest jednym z największych projektów w Polsce, który koncentruje

Bardziej szczegółowo

E-administracja warunkiem rozwoju Polski. Obecna i potencjalna rola epuap w procesowym zarządzaniu w administracji

E-administracja warunkiem rozwoju Polski. Obecna i potencjalna rola epuap w procesowym zarządzaniu w administracji E-administracja warunkiem rozwoju Polski Obecna i potencjalna rola epuap w procesowym zarządzaniu w administracji Mariusz Madejczyk Ministerstwo Spraw Wewnętrznych i Administracji 1 epuap, a zarządzanie

Bardziej szczegółowo

Małopolska wobec epuap

Małopolska wobec epuap Małopolska wobec epuap Zasady integracji samorządów Małopolski na platformie epap poprzez Cyfrowy Urząd Kraków, 2 kwietnia 2004 r. Cyfrowy Urząd stan obecny Elektroniczna platforma komunikacyjna umoŝliwiającą

Bardziej szczegółowo

Prezentacja specjalności studiów II stopnia. Inteligentne Technologie Internetowe

Prezentacja specjalności studiów II stopnia. Inteligentne Technologie Internetowe Prezentacja specjalności studiów II stopnia Inteligentne Technologie Internetowe Koordynator specjalności Prof. dr hab. Jarosław Stepaniuk Tematyka studiów Internet jako zbiór informacji Przetwarzanie:

Bardziej szczegółowo

VENDIO SPRZEDAŻ kompleksowa obsługa sprzedaży. dcs.pl Sp. z o.o. vendio.dcs.pl E-mail: info@dcs.pl Warszawa, 16-10-2014

VENDIO SPRZEDAŻ kompleksowa obsługa sprzedaży. dcs.pl Sp. z o.o. vendio.dcs.pl E-mail: info@dcs.pl Warszawa, 16-10-2014 VENDIO SPRZEDAŻ kompleksowa obsługa sprzedaży dcs.pl Sp. z o.o. vendio.dcs.pl E-mail: info@dcs.pl Warszawa, 16-10-2014 Agenda Jak zwiększyć i utrzymać poziom sprzedaży? VENDIO Sprzedaż i zarządzanie firmą

Bardziej szczegółowo

REGULAMIN. 1 Postanowienia ogólne

REGULAMIN. 1 Postanowienia ogólne REGULAMIN 1 Postanowienia ogólne Niniejszy Regulamin określa zakres i warunki świadczenia usług za pośrednictwem systemu elektronicznej Platformy Usług Administracji Publicznej (epuap), mając na uwadze,

Bardziej szczegółowo

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

Michał Jaworski Wiceprezes PIIT

Michał Jaworski Wiceprezes PIIT Michał Jaworski Wiceprezes PIIT Warszawa, 2 grudnia 2009 Europejskie Ramy Interoperacyjności 2.0 Pozycjonowanie dokumentu: Europejska Strategia Interoperacyjności zapewnia ład korporacyjny (Governance)

Bardziej szczegółowo

mtim Dedykowane aplikacje mobilne dla TIM S.A.

mtim Dedykowane aplikacje mobilne dla TIM S.A. mtim Dedykowane aplikacje mobilne dla TIM S.A. O TIM TIM S.A. jest jednym z największych dystrybutorów artykułów elektrotechnicznych w Polsce. 25 lat w branży, z czego 17 lat na Giełdzie Papierów Wartościowych

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

Zarządzanie kontem użytkownika Lokalnego Systemu Informatycznego w ramach RPO WSL 2014-2020

Zarządzanie kontem użytkownika Lokalnego Systemu Informatycznego w ramach RPO WSL 2014-2020 Zarządzanie kontem użytkownika Lokalnego Systemu Informatycznego w ramach RPO WSL 2014-2020 Rejestracja konta Użytkownicy rejestrują konta samodzielnie poprzez formularz dostępny na stronie logowania https://lsi.slaskie.pl.

Bardziej szczegółowo

Zintegrowany System Informatyczny (ZSI)

Zintegrowany System Informatyczny (ZSI) Zintegrowany System Informatyczny (ZSI) ZSI MARKETING Modułowo zorganizowany system informatyczny, obsługujący wszystkie sfery działalności przedsiębiorstwa PLANOWANIE ZAOPATRZENIE TECHNICZNE PRZYGOTOWANIE

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

ROZPORZĄDZENIE WYKONAWCZE KOMISJI (UE) NR

ROZPORZĄDZENIE WYKONAWCZE KOMISJI (UE) NR L 134/32 ROZPORZĄDZENIE WYKONAWCZE KOMISJI (UE) NR 463/2014 z dnia 5 maja 2014 r. ustanawiające, na mocy rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 223/2014 w sprawie Europejskiego Funduszu

Bardziej szczegółowo

Europeana Cloud: Wykorzystanie technologii chmurowych do współdzielenia on-line baz danych dziedzictwa kulturowego

Europeana Cloud: Wykorzystanie technologii chmurowych do współdzielenia on-line baz danych dziedzictwa kulturowego Europeana Cloud: Wykorzystanie technologii chmurowych do współdzielenia on-line baz danych dziedzictwa kulturowego Cezary Mazurek, Aleksandra Nowak, Maciej Stroiński, Marcin Werla Poznańskie Centrum Superkomputerowo-Sieciowe

Bardziej szczegółowo

System B2B jako element przewagi konkurencyjnej

System B2B jako element przewagi konkurencyjnej 2012 System B2B jako element przewagi konkurencyjnej dr inż. Janusz Dorożyński ZETO Bydgoszcz S.A. Analiza biznesowa integracji B2B Bydgoszcz, 26 września 2012 Kilka słów o sobie główny specjalista ds.

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1 Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących

Bardziej szczegółowo

Praktyczne zastosowanie modelu usługowego na platformie epuap. Przykłady zrealizowanych usług

Praktyczne zastosowanie modelu usługowego na platformie epuap. Przykłady zrealizowanych usług www.comarch.pl Architektura epuap Praktyczne zastosowanie modelu usługowego na platformie epuap. Przykłady zrealizowanych usług Tomasz Matysik XV Forum Teleinformatyki 24-25 września 2009 Architektura

Bardziej szczegółowo

Informatyzacja JST z zastosowaniem technologii przetwarzania w chmurze

Informatyzacja JST z zastosowaniem technologii przetwarzania w chmurze Informatyzacja JST z zastosowaniem technologii przetwarzania w chmurze Centrum Projektów Informatycznych Warszawa, 22 kwietnia 2013 r. Agenda 1. Prezentacja ogólnych informacji na temat uruchomionego projektu

Bardziej szczegółowo

Uchwała nr 3/2015. z dnia 15 maja 2015 r. w sprawie przyjęcia rekomendacji do kryteriów wyboru projektów z zakresu digitalizacji

Uchwała nr 3/2015. z dnia 15 maja 2015 r. w sprawie przyjęcia rekomendacji do kryteriów wyboru projektów z zakresu digitalizacji Uchwała nr 3/2015 Zespołu ds. koordynacji działań w obszarze e-administracji, udostępniania informacji sektora publicznego oraz rozwoju kompetencji cyfrowych z dnia 15 maja 2015 r. w sprawie przyjęcia

Bardziej szczegółowo