Warszawa, 17 lutego 2011 roku UWAGI Polskiej Izby Informatyki i Telekomunikacji [ PIIT] w konsultacjach społecznych w sprawie projektu Rozporządzenia Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w formie elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (projekt z dnia 10 lutego 2011 roku) Polska Izba Informatyki i Telekomunikacji [PIIT] przedstawia poniższe uwagi do projektu rozporządzenia z dnia 10 lutego 2011: 1. Par 2 Pkt 1) termin aktywa jest użyty tylko raz w tekście rozporządzenia, w par 2 pkt 5) - proponujemy skasowanie tego punktu, a w pkt 5) użyć słowa zasoby ; Pkt 3) definicja terminu autentyczność wzbudza dyskusje, gdyż nie jest w pełni zgodna z polską normą PN200-I-2001 lub też nie opisuje tego, co ma opisywać. Może, bowiem bardziej chodzić o jedno z dwóch pojęć: (a) uwierzytelnienie lub (b) identyfikację podmiotu lub zasobu w postaci obiektu zgodnie z deklaracją a istniejącego w systemie teleinformatycznym, a nie o sam rzeczywisty podmiot czy zasób. Propozycja PIIT: niezbędna jest autopoprawka MSWiA. Pkt 5) termin dokładność wydaje się być niejasny... Proponujemy brzmienie: integralność właściwość polegająca na zapewnieniu spójności i kompletności zasobów. W tym sensie słowo spójność odpowiada angielskiemu consistency, czyli brakowi sprzeczności. W przypadku systemu informatycznego oznaczać to będzie w praktyce, że na dane zapytanie zawsze zostanie udzielona ta sama odpowiedź. Pkt 6) termin interesariusz użyty dalej tylko raz w tekście rozporządzenia proponujemy go pominąć, natomiast w par 5 ust 2 pkt 3) bądź pozostawić słowo interesariusz bez odwoływania się do terminu (proponowany termin jest zgodny z kolokwialnym pojmowaniem słowa interesariusz, więc nie musi być dodatkowo tłumaczony) lub też zamiast słowa interesariusz wprowadzić odpowiedni opis (patrz także uwaga 8.). Pkt 14) Proponujemy czytelniejszy zapis podmiot osobę prawną, lub jednostkę organizacyjną nieposiadającą osobowości prawnej, lub organ administracji publicznej. Użycie lub wskazuje, że może to być jedna z przedstawionych w definicji form. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 1
Nowy punkt: Proponujemy zapis: polityki bezpieczeństwa - zestaw efektywnych, udokumentowanych zasad i procedur bezpieczeństwa, wraz z ich planem wdrożenia i egzekwowania Uzasadnienie: W paragrafie 14 co najmniej dwukrotnie pojawia się pojęcie polityka bezpieczeństwa, które naszym zdaniem wymaga zdefiniowania. 2. Par 3. Ust 1. Proponujemy w definicji wprost odnieść się do definicji interoperacyjności zapisanej w ustawie o informatyzacji (art. 3 punkt 18). Dlatego proponujemy brzmienie następujące: Krajowe Ramy Interoperacyjności stanowią zbiór uzgodnionych definicji, wymagań, reguł architektury systemów teleinformatycznych oraz procedur i zasad, których stosowanie umożliwi różnym podmiotom oraz używanym przez nie systemom teleinformatycznym i rejestrom publicznym współdziałanie na rzecz osiągnięcia wzajemnie korzystnych i uzgodnionych celów, z uwzględnieniem współdzielenia informacji i wiedzy przez wspierane przez nie procesy biznesowe realizowane za pomocą wymiany danych za pośrednictwem wykorzystywanych przez te podmioty systemów teleinformatycznych 3. Par 3. Ust 1. Pkt 1) Proponujemy zamiast podmiotom gospodarczym wszędzie użyć zdefiniowanego w par. 1 pojęcia podmiot ; ta sama uwaga przy zapisie podmiot publiczny. Podpunkt c) i d) czy ten zapis jest potrzebny? Przy tak poszerzonych celach interoperacyjności można zgubić zasadniczy cel, jaki jest zapisany w ustawie... Cele c) i d) są celami dla całej administracji, a nie dla interoperacyjności. Porównaj uwaga 1 do par 2 pkt 14) 4. Par 3. Ust 1. Brakuje zapisu dotyczącego realizacji usług ponadgranicznych, który powinien być także celem dla KRI. Proponujemy następujący zapis: g) efektywna realizacja drogą elektroniczną ponadgranicznych usług administracji publicznej Uzasadnienie: Dzięki takiemu zapisowi Rząd RP będzie mógł wykazać się realizacją zadań nakreślonych w grudniu 2010 przez e-government Action Plan z 15 grudnia 2010, a konkretnie 2.2.3 oraz 2.4.1. Być może będzie pierwszym rządem wśród krajów członkowskich, który wykona oczekiwane zalecenie zgrania Europejskich Ram Interoperacyjności z Krajowymi Ramami Interoperacyjności przynajmniej w podstawowym zakresie. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 2
5. Par 3 ust 2 punkt 2) Proponujemy w tekście tego punktu odwołać się nie tylko do art 13 ust 2 pkt 1 i art 18 punkt 1) podpunkt c) mówiącego o zasadach równego traktowania różnych rozwiązań informatycznych, ale także do zawartej w ustawie doskonałej definicji neutralności technologicznej (patrz także art 1 punkt 2), 3) i 4) ustawy o informatyzacji!!!) oraz art 3. Punkt 19). Brzmienie tego punktu: Opcja 1 (z zachowaniem dotychczasowej propozycji): (...) z zapewnieniem zasady neutralności technologicznej i równego traktowania różnych rozwiązań informatycznych. Opcja 2 (tylko neutralność technologiczna): (...) z zapewnieniem zasady neutralności technologicznej. Uzasadnienie: pojęcie neutralności technologicznej zdefiniowane w ustawie zawiera już nakaz równego traktowania różnych rozwiązań informatycznych, a jest szersze. Stąd sugestia zastosowania tego właśnie pojęcia! 6. Par 4 ust. 1 pkt 1) Propozycja: 1) ujednolicenie, rozumiane, jako zastosowanie sprzętu oraz oprogramowania o tej samej architekturze i funkcjonalności i tych samych standardów, polityk, procedur i norm przez różne podmioty realizujące zadania publiczne; Uzasadnienie: Ujednolicenie rozumiane, jako m.in. zastosowanie tego samego typu sprzętu jest posunięte zbyt daleko. Dostatecznym opisem sytuacji jest zastosowanie sprzętu oraz oprogramowania o tej samej architekturze i funkcjonalności. 7. Par 4 ust. 3 Analogicznie do propozycji przedstawionej powyżej w pkt 5 i dotyczącej par 3 punkt 2) Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 3
8. Par 5 ust. 2 punkt 3) Par 5 ust. 3 punkt 1) Par 5 ust. 4 punkt 2) Par 7 ust. 2 punkt 2) Patrz także: uzasadnienie do rozporządzenia W Par. 5 pojawia się pojęcie rekomendacji i ich stosowania. W uzasadnieniu pojawiają się następujące zapisy (podkreślenie PIIT): Pierwszy: Rekomendacje są dynamiczną częścią Krajowych Ram Interoperacyjności. Ich stosowanie przez podmioty realizujące zadania publiczne powinno być obligatoryjne w obszarze interfejsów łączących systemy informatyczne różnych podmiotów. Wewnątrz systemu rekomendacje takie nie muszą obowiązywać, jednak racjonalne wydaje się stosowanie rozwiązań proponowanych przez rekomendacje i w tym obszarze. Z uwagi na to, że delegacja ustawowa nie sytuuje żadnego organu koordynującego osiąganiem interoperacyjności, jedynym rozwiązaniem pozostaje przypisanie funkcji koordynacyjnych w tym zakresie ministrowi właściwemu do spraw informatyzacji. Takie podejście wynika z przepisu art. 12a ustawy z dnia 4 września 1997 r. o działach administracji rządowej. Drugi: Podstawowym narzędziem służącym uzyskaniu interoperacyjności są rekomendacje interoperacyjności. Należy zdawać sobie sprawę, że część tych rekomendacji pozostanie poza wpływem polskiej legislacji, jednak ich przyjęcie jest nieuniknione z uwagi na ponadnarodowy charakter takich bytów jak choćby Internet. Zatem standardy i normy dotyczące takich bytów ustalane przez organizacje, których kompetencje wynikają nie z normy prawnej, a z powszechnie i nieformalnie przyjętej zgody nie mogą zostać pominięte. Jednocześnie już dość dawno w dziedzinie produkcji i świadczenia usług zauważono, że efekt synergii działań różnych podmiotów uczestniczących w danym rynku, mimo występującej konkurencyjności, możliwy jest do uzyskania przy wspólnej zgodzie zainteresowanych stron, co do przyjmowanych standardów. Podobnie w przypadku interoperacyjności efekt synergii działań podmiotów realizujących zadania publiczne możliwy jest do uzyskania, gdy rekomendacje interoperacyjności zostaną wypracowane nie w sposób nakazowy, a w drodze szerokiego konsensusu. Ważne jest jednak, aby stworzone zostały instytucjonalne ramy dla takich uzgodnień oraz aby uzgodnienia były łatwo dostępne. Temu celowi służy umocowanie ministra właściwego do spraw informatyzacji do zarządzania ustalaniem rekomendacji interoperacyjności i publikowania tychże uzgodnień. Możliwość takiego umocowania nie wynika, co prawda explicite z delegacji art. 18 ustawy, niemniej implikowana jest ona zadaniami, jakie posiada minister właściwy do spraw informatyzacji na podstawie art. 12a pkt. 4 ustawy z dnia 4 września 1997 r. o działach administracji rządowej. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 4
Niestety zarówno z zapisu w/w paragrafów, jak i z treści uzasadnienia wynika intencja wprowadzenia prawa powielaczowego. Minister właściwy ds informatyzacji w procesie, który nie jest sformalizowany (jak choćby dyskusja nad niniejszym rozporządzeniem) i nie podlega żadnej kontroli prócz enigmatycznego wypracowania w jawnym i otwartym procesie uzgodnień z możliwie szerokim gronem interesariuszy może dowolnie kształtować zasady dotyczące interoperacyjności skutecznie zaprzeczające treści rozporządzenia. Co więcej, bardzo wyraźnie zostało zapisane obligatoryjne korzystanie z rekomendacji (na razie w zakresie interfejsów, ale przecież tak właśnie działa prawo powielaczowe na początku tylko niewielka część, a potem ciągłe powiększanie zakresu działania)! Na takie traktowanie zagadnień interoperacyjności nie może być zgody. Nasze propozycje: Par 5 ust 2 punkt 3) skreślić (patrz także uwaga 1 definicja interesariusz ) Par 5 ust 3 punkt 1) w brzmieniu: stosowanie struktur danych i znaczenia danych zawartych w tych strukturach, określonych w niniejszym rozporządzeniu (Załącznik 1) Par 5 ust 4 punkt 2) skreślić. Niestety ten punkt jest tak niejasny i daje taką dowolność interpretacji, że nie powinien się utrzymać. Natomiast par 7 ust 2 proponujemy w brzmieniu: Minister właściwy do spraw informatyzacji może publikować rekomendacje interoperacyjności organizacyjnej i semantycznej, których stosowanie nie jest obligatoryjne Oraz dodać par 7 ust 3 w brzmieniu: Rekomendacje, o których mowa powyżej są wypracowywane w jawnym i otwartym procesie z zachowaniem zasady neutralności technologicznej i równego traktowania różnych rozwiązań informatycznych. Uzasadnienie naszej propozycji: Jest dobrą praktyką publikowanie rekomendacji. Rekomendacje z natury rzeczy choć zostały w propozycji wpisane w sposób sugerujący ich obligatoryjne użycie, zaś w uzasadnieniu wprost mówi się o ich obligatoryjnym stosowaniu mają charakter wskazówki, sugestii, propozycji, natomiast ich egzekwowanie będzie bardzo utrudnione. Dotyczy to zarówno organów kontrolnych ze strony administracji, jak też ze strony podmiotów kontaktujących się z administracją. Rekomendacje w takiej formie jak proponowane (obligatoryjne, dowolnie zmieniane) nie mają umocowania w sensie kontroli finansowej procesów wdrażania e-administracji. Po pierwsze, ponieważ każdy minister właściwy do spraw informatyzacji może zmieniać rekomendacje w dowolnej chwili. Po drugie, zmiana rekomendacji nie wymaga wskazania budżetu, z którego pokryje się te zmiany (zmiana rozporządzenia wymaga takiej analizy). Może to prowadzić do nadmiaru pracy, frustracji pracowników, a nawet wręcz do nieuzasadnionych wydatków z budżetu. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 5
Inne jednostki administracji (np. ministerstwa) w trakcie przygotowywania aktów będących w ich gestii muszą się kierować zapisami ustaw i rozporządzeń dot. Informatyzacji, natomiast rekomendacje nie mają takiego umocowania. Może to prowadzić do poważnych problemów. Rekomendacje ograniczone powinny być do interoperacyjności organizacyjnej i semantycznej. Interoperacyjność na poziomie technologicznym, gdzie podstawą są normy i standardy techniczne można w łatwy sposób zapewnić poprzez modyfikację załącznika 2 do KRI. Nie widać powodu dla tworzenia dodatkowego prawa powielaczowego w postaci rekomendacji zawierających normy i standardy techniczne. Jednocześnie: częste zmienianie takich rekomendacji i traktowanie ich, jako obligatoryjnych znacznie podwyższy koszt uzyskania interoperacyjności technologicznej! Także: jeśli Unia Europejska wskaże na nowy standard technologiczny to jego uzupełnienie w KRI powinno być proste na drodze nowelizacji niniejszego rozporządzenia. Uwaga dodatkowa: w propozycji par 7 ust 2 punkt 1) pojawia się po raz jedyny pojęcie otwartych standardów, które pojawiło się w EIF 1.0, ale nie występuje już w EIF 2.0. Owszem, dość podobną definicję otwartości EIF zawiera (p. 5.2.1) wszak po wielu latach bezproduktywnej dyskusji, czym są otwarte standardy należy się jednak wystrzegać wprowadzania do polskiego prawa tego niejasnego i często stosowanego w sposób wyłącznie marketingowy pojęcia. 9. Par 8 ust.1. pkt. 1) Uwaga: Ograniczenie tylko do osób występujących w PESEL znacząco może utrudniać obsługę osób nieposiadających numeru pesel - a docelowo może powodować wykluczenie cyfrowe osób nieposiadających obywatelstwa lub stałego zamieszkania na terytorium RP, dlatego sugeruję delegację umożliwiającą o wyróżnienie cech osób nieposiadających numeru identyfikacyjnego PESEL i ich takie samo traktowanie (przykład: studenci zagraniczni studiujący w polskich publicznych uniwersytetach). 10. Par 9 Paragraf 9 stanowi delegację do publikacji na epuap tylko schematów dla obiektów określonych paragrafem 8 ust 1. To za mało dla ustanowienia interoperacyjności. Oczekiwaniem jest to, że wszystkie podmioty, które tworzą rejestry są zobowiązane w uzgodnieniu z ministrem właściwym do spraw informatyzacji przygotować i opublikować struktury danych wszystkich przetwarzanych przez siebie cech informacyjnych. 11. Par. 10 ust. 2 pkt. 1) Zamiast właściciel usługi warto zastosować termin usługodawca. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 6
Par 11 ust. 4 i nowy ustęp 5 Proponujemy uzupełnienie par 11 o ust 5 o treści: Dopuszcza się kodowanie znaków według standardu Unicode UTF-16 określonego przez normę ISO/IEC 10646-1 Information technology Universal Multiple-Octet Coded Character Set wraz z normami uzupełniającymi lub normą ją zastępującą.. Uzasadnienie: Praktycznie wszystkie systemy operacyjne, narzędzia developerskie i aplikacje wspierają UTF-8 wymieniony w ustępie 4. Jednak dla wielu bardzo popularnych platform, takich jak Java czy Windows, natywnym formatem jest UTF-16. Dopuszczenie wykorzystania UTF-16 powinno, zatem uprościć i potanić tworzenie oprogramowania dla administracji. Należy również pamiętać, że KRI i zadania polskiej administracji wychodzą poza nasz lokalny charakter, a zadania pan-europejskie czy też wręcz kontaktów z administracjami innych państw będą wymagały zastosowania UTF-16 (np. kraje azjatyckie). 12.Par 12 ust. 1 Uważamy, że niezależnie od dobrych intencji zawartych w tym ustępie może on być przyczyną wielu nieporozumień. Jeśli zakładamy, że w podmiocie realizującym zadanie publiczne powinno być dostępne oprogramowanie nieodpłatne służące do odczytania przesłanego pliku to otwiera się prawdziwy problem. Cóż, bowiem może powstrzymać kogoś od wysłania pliku w formacie, który jest odczytywalny za pomocą darmowego oprogramowania dostępnego na superkomputer XYZ?... Warunek został spełniony... Również zapis o powielaczowym prawie, czyli rekomendacjach interoperacyjności powinien być wykreślony (patrz dyskusja w uwadze 8). Dlatego też proponujemy następujące rozwiązanie: Par 12 ust 1 w brzmieniu: Jeżeli dla pisma w formie dokumentu elektronicznego służącego do procedowania danej sprawy nie ustalono wzoru dokumentu elektronicznego systemy teleinformatyczne używane przez podmioty realizujące zadania publiczne powinny umożliwiać przyjmowanie dokumentów w postaci elektronicznej w formatach plików określonych w załączniku 2 do rozporządzenia (część A, punkty 1 i 2). W przypadku przyjęcia powyższej uwagi można wykreślić par 2 punkt 9). Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 7
W załączniku 2, część A należy zatytułować: W celu wymiany zasobów informacyjnych przez podmioty realizujące zadania publiczne stosuje się: Jednocześnie w celu ułatwienia wymiany danych i poprawienia interoperacyjności sugerujemy poszerzenie listy standardów o następujące formaty plików:.xls Dokumenty w postaci sformatowanego arkusza kalkulacyjnego jako plik typu.xls Microsoft Corp.xlsx Dokumenty w postaci sformatowanego arkusza kalkulacyjnego jako plik typu.xlsx Microsoft Corp Patrz także dyskusja dotycząca załącznika 2. Naszą propozycję uzasadniamy faktem, że wielokrotnie w praktyce e-administracji pojawiają się pliki w formie arkuszy elektronicznych (np. RIO) Uzasadnienie: Tak jak par 12 ust 2 mówi o tym, że podmioty realizujące zadania publiczne powinny udostępniać zasoby w jednym ze standardowych formatów, tak można również oczekiwać, że informacja do takiego podmiotu (jeśli nie zostało to sformalizowane) będzie skierowana w jednym z tych właśnie formatów. Zapis mówiący o istnieniu nieodpłatnego oprogramowania może prowadzić do nieporozumień. Zaproponowana przez nas formuła daje symetryczne warunki wszystkim stronom (interesariuszom społecznym). 13.Par. 12 ust. 2 Ustęp ten mówi tylko o plikach, a powinien wskazywać na dane zgodnie z tytułem załącznika 2. 14.Par 12 ust 3 (nowy) Proponujemy dodatkowy zapis dotyczący wymiany informacji pozwalający na łatwą weryfikowalność dokumentów, promocję rozwiązań wykorzystujących podpis elektroniczny (i/lub podpis osobisty!). Propozycja zapisu par 12 ustęp 3: W celu udostępniania zasobów informacyjnych przez podmioty realizujące zadania publiczne zaleca się formaty danych wspierające w swojej specyfikacji podpis elektroniczny. Uzasadnienie: nie wszystkie popularne formaty danych wymienione w Załączniku 2 do niniejszego rozporządzenia mają w opisie formatu standardowo opisany sposób dołączania podpisu elektronicznego. Nie oznacza to, że dokument stworzony w danym formacie nie może być podpisany elektronicznie, natomiast w przypadku, kiedy sposób integrowania podpisu nie jest opisany w standardzie wówczas każdy edytor takiego formatu może to robić na odmienny sposób. Niemożliwa jest wówczas automatyzacja procesów e-administracji, a każdy taki dokument musi być weryfikowany przez człowieka. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 8
Proponowany przez nas zapis nie ogranicza możliwości wykorzystania wszystkich dopuszczonych formatów, natomiast zaleca stosowanie tych, dla których dowolny edytor czy też dowolne oprogramowanie do odczytu będzie mogło korzystać z faktu ustandaryzowania obecności podpisu elektronicznego. 15.Par 13 ust 1. Proponujemy zapis: Projektując system teleinformatyczny podmiotu realizującego zadania publiczne służący do realizacji zadania publicznego należy zapewnić realizację przez ten system wymagań Web Content Accessibility Guidelines (WCAG 2.0) na poziomie A w zakresie dotyczącym interfejsu użytkownika przeznaczonego dla zewnętrznych użytkowników systemu. Zaleca się przystosowanie projektowanego systemu do wymagań na poziomie AA. Uzasadnienie: Po pierwsze, należy wskazać, że w sposób zgodny z wymaganiami WCAG powinny być przygotowane systemy do realizacji zadań publicznych. W przeciwnym wypadku rozporządzenie nakazywałoby stosowanie takich rozwiązań do wszystkich, także wewnętrznych, systemów. W przypadku np. uczelni publicznych byłoby to ogromnym obciążeniem. Po drugie, należy w absolutnie klarowny sposób wskazać, że wymagania dotyczące accessibility dotyczą tej części systemu teleinformatycznego, który jest związany z korzystaniem z niego przez zewnętrznych użytkowników. Trudno sobie wyobrazić, że interfejs dla wewnętrznych developerów systemu także będzie musiał spełniać wymogi WCAG. Po trzecie, zapewnienie dostępności dla osób niepełnosprawnych jest ważnym zadaniem, wszak przystosowanie systemów jest bardzo kosztowne. Warto zwrócić uwagę, że Europejska Agenda Cyfrowa wprawdzie przywołuje wymagań WCAG, ale po pierwsze limituje je tylko do internetowych stron publicznych i publicznych serwisów on-line, a także nie określa, na jakim poziomie będą te wymagania. Uważamy, że w początkowej fazie wdrażania takich serwisów należy zadbać o wymagania na poziomie A wraz z rekomendacją na poziomie AA. Patrz także: uwaga 12 i 13. 16.Par 13 ust. 2. Proponujemy, żeby podstawowa lista wymagań stanowiła załącznik do niniejszego rozporządzenia. Dlatego też brzmienie tego ustępu zmieniłoby się na: Lista wymagań, o których mowa w ust. 1 znajduje się w załączniku 3 do niniejszego rozporządzenia. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 9
17.Par 14 ust. 2 nowy punkt Proponujemy dodać jako pierwszy punkt: instrukcji polityki bezpieczeństwa Opracowanie, wdrożenie i egzekwowanie Uzasadnienie: dla podmiotów administracji publicznej obowiązujące jest rozporządzenie MSWiA z dnia 29 kwietnia 2004 r. (Dz. U. 2004 Nr 100, poz. 1024), nakładające obowiązek opracowania i posiadania formalnej instrukcji polityki bezpieczeństwa. Brak jest, więc zapisu o egzekwowaniu. W takim przypadku niniejszy zapis uzupełnia ten brak. 18.Par 14 ust 2 nowy punkt Proponujemy dołączenie następującego zapisu: Każdorazowo system podlegający odbiorowi po jego wdrożeniu lub przebudowie musi podlegać zewnętrznemu audytowi polegającemu na zastosowani procedur testów penetracyjnych Uzasadnienie: Wszystkie zapisy par 14 nie pokazują, w jaki sposób należałoby sprawdzać bezpieczeństwo, nawet po zastosowaniu wszystkich nakładanych wymogów. Proponujemy uzupełnić zapisy par 14 ust 2 przynajmniej o ten jeden zapis. 19.Par 14 ust 2 punkt 9) Proponujemy brzmienie: zapewnienie, że pracownicy, wykonawcy i użytkownicy reprezentujący stronę trzecią odchodzą z podmiotu, zaprzestają wykonywać zadania lub zmieniają stanowisko w sposób nienaruszający ustalonych zasad bezpieczeństwa informacji. 20.Par. 14 ust.5 (nowy) Proponujemy dodanie nowego ustępu w brzmieniu: Podmiot realizujący zadania publiczne prowadzi w formie pisemnej i wdraża politykę bezpieczeństwa informacji - dokument zawierający i rozszerzający politykę bezpieczeństwa w rozumieniu art39a ustawy o ochronie danych osobowych, na wszystkie informacje przetwarzane w podmiocie. Uzasadnienie: wiele podmiotów posługuje się dokumentem nazywanym polityką bezpieczeństwa informacji (patrz uwaga 18), a odnoszącym się jedynie do danych osobowych, co wynika wprost z rozporządzenia do uodo. Jest okazja by rozszerzyć działanie tej polityki na wszelkie zasoby informacyjne i dokumentowe w podmiocie. W ślad za polityką powinna powstać instrukcja zarządzania systemem teleinformatycznym, zawierająca podstawowe procedury odpowiadające zasadom bezpieczeństwa zawartym w polityce. 21. Par. 15 ust.2 pkt 3) Proponujemy uzupełnić: przetwarzanych w systemach danych podlegających prawnej ochronie w zakresie wymaganym przepisem prawa. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 10
Uzasadnienie: przykładowo: w odniesieniu do przetwarzania danych osobowych jest obowiązek odnotowania identyfikatora użytkownika wprowadzającego dane do systemu oraz kontroli udostępniania. Odnotowanie każdej operacji przetwarzania nie jest wymagane ustawą uodo. 22.Załącznik 2 Zamiast nagłówka: Organizacja określająca normę lub standard Propozycja: Organizacja określająca format, normę lub standard Uzasadnienie: można było domniemywać z dalszego ciągu tabeli, że firmy takie jak Adobe czy Microsoft określają normy dlatego proponujemy poprawkę w przedstawionym wyżej brzmieniu. 23.Załącznik 2 Dot. Formatu PDF Proponujemy zmianę: Jest: Adobe System Inc Propozycja: ISO Jest: puste Propozycja: ISO/IEC 32000 Uzasadnienie: Jest oczywistym, że należy wykorzystywać specyfikację ISO. 24. Załącznik 2 Dotyczy formatu Open Document Format Jest.odt Jest: OASIS Propozycja: ODF Propozycja: ISO Jest: puste Propozycja: ISO 26300 Uzasadnienie: Format ODF jest dostępny w postaci standardu ISO, więc nie ma potrzeby utrzymywania go w postaci formatu OASIS tak jak miało to miejsce w poprzednim rozporządzeniu Uwaga: dzięki takiemu zapisowi można także transferować pliki typu.ods (arkusze kalkulacyjne) patrz dyskusja w uwadze 10. 25. Załącznik 2 Ze względów opisanych w uwadze 13 dołączyć do listy standardów formaty arkuszy kalkulacyjnych.xls i.xlsx. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 11
26. Załącznik 2 Proponujemy dołączenie następującego formatu: L.p. 1.4 Format: OpenXPS Oryginalna Nazwa: Open XML Paper Specification Dokumenty tekstowo-graficzne dostępne przez dowolną przeglądarkę internetową Organizacja: ECMA Nazwa normy: ECMA-388 Uzasadnienie: otwarta, darmowa specyfikacja dla dokumentów tekstowo-graficznych obsługiwana przez dowolną przeglądarkę internetową. 27. Załącznik 2 Dotyczy formatu GIF. Przywołana w rozporządzeniu firma CompuServe została przejęta na początku poprzedniej dekady przez AOL, zaś w 2009 roku serwis zaprzestał działalności w swojej klasycznej wersji. Prawa do standardu GIF (z roku 1987!!!) wygasły i nikt się tą specyfikacją nie opiekuje. Mamy zatem standard de facto nieumocowany w żadnych normach. Zapis w takiej postaci jak był przywołany w rozporządzeniu z 2005 roku należy zmodyfikować! Propozycja 1: wykreślić Propozycja 2: wykreślić CompuServe, zaś sam standard pozostawić (ew. Określenie de facto standard ). 28. Załącznik 2 Pozycje 4.1 i 4.3 wymagają precyzyjniejszego rozróżnienia! Propozycja: wykorzystać zapis HTML 4.01 i specyfikację jako opisaną normą ISO 15445:2000 29. Załącznik 2 Propozycja dołączenia do listy formatów standardu HTML5 rozwijanego przez W3C, jako standardu rozwojowego dla publikacji on-line. W szczególności istotne w kontekście pojawiania się coraz większej ilości materiałów video, także publikowanych przez administrację. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 12
30. Załącznik 2 sekcja elektronicznego podpisywania Warto się jeszcze zastanowić do dopisaniem do listy formatu CAdES (CMS Advanced digital Electronic Signatures, Podpis elektroniczny w formacie CAdES, ETSI TS 101 733). Uzasadnienie: Dyrektywa Usługowa UE obliguje kraje członkowskie do udostępniania tzw. jednego okienka, poprzez które obywatele Unii Europejskiej będą mogli załatwić elektronicznie swoje sprawy. Wtedy administracja publiczna w Polsce nie powinna zabraniać w takim razie używania podpisów w formacie CAdES wszystkim obywatelom Unii. Uwagi końcowe: Nie możemy zgodzić się z argumentacją, że wprowadzenie wymogu stosowania metodyki ITIL (par 10 ust 3) nie będzie miało żadnego wpływu finansowego na jednostki realizujące zadania publiczne. Zwłaszcza w sytuacji, kiedy ta metodyka nie jest powszechnie stosowana praktyce tworzenia systemów (np. uczelnie). Dlatego też prosimy o uwzględnienie tej uwagi w uzasadnieniu do rozporządzenia. Uwagi PIIT do projektu Rozp. RM w sprawie Krajowych Ramach Interoperacyjności Strona 13