Krajowe Ramy Interoperacyjności - uwagi do projektu

2011-02-14 00:00:00 +0000

MSWiA wystawiło właśnie projekt rozporządzenia Krajowe Ramy Interoperacyjności, które regulować będzie zasady tworzenia systemów informatycznych w administracji i nieobowiązujące już rozporządzenie o minimalnych wymaganiach. Projekt znajdziemy na stronie BIP MSWiA:

http://bip.mswia.gov.pl/portal/bip/218/19358/Projekt_rozporzadzenia_Rady_Ministrow_z_dnia_2011_r_w_sprawie_Krajowych_Ram_Inte.html

§10 mówi jak powinny być budowane systemy teleinformatyczne w administracji - dla sektora prywatnego to w większości truizmy, ale jak wiadomo administracja działa na podstawie przepisów prawa. Obserwując dotychczasową praktykę można dojść do wniosku, że jeśli prawo nie mówi, że system ma być ergonomiczny i wydajny, to będzie niewygodny i ślamazarny. Dobrze więc, że zasady dobrej praktyki zostały w KRI zwerbalizowane.

Prawdopodobnie najistotniejszym konkretem jest powołanie się przez KRI na normy PN-ISO/IEC 20000-1:2007 i PN-ISO/IEC 20000-2:2007 czyli “Technika informatyczna - zarządzanie usługami” (z okolic ITIL i COBIT). Podobne wymagania opisano w § 14 dla bezpieczeństwa, z odwołaniem do norm z serii ISO 27001. W obu przypadkach sformułowano wymagania tak, że nie wykluczają one innych metod osiągania celów funkcjonalnych - tak przynajmniej rozumiem sformułowanie “spełnia wymogi jeżeli został opracowany na podstawie normy”. W §14 normy audytowe (ISO 27001) określono oddzielnie, przez co wydaje mi się, że system budować można według standardu dowolnego, byleby wynik był ten sam.

§11 ustala z kolei hierarchię norm i standardów, gdzie preferowane są “normy, standardy lub rekomendacje ustanowione przez krajową jednostkę normalizacyjną lub jednostkę normalizacyjną Unii Europejskiej” (czyli zapewne PKN, ale także CEN i ETSI), a jeśli ich nie ma - standardy IETF (RFC) i W3C.

Jako standard kodowania znaków w tym samym paragrafie ustala się UTF-8. Trochę nie za bardzo wiadomo o kodowanie czego chodzi - norm i standardów?

§12 sankcjonuje sytuację, w intencji ustawodawcy zapewne wyjątkową, gdy brak jest standardowego wzoru dokumentu elektronicznego w CRD. W takim przypadku “powinny umożliwiać przyjmowanie dokumentów w postaci elektronicznej w formatach plików, dla których dostępne jest nieodpłatne oprogramowanie służące do ich odczytania”. Czy jakiś inny przepis nakłada na kogokolwiek obowiązek tworzenia takich wzorów? Jeśli nie, to biorąc pod uwagę dotychczasową praktykę można oczekiwać, że furtka w §12 posłuży do radosnego zamawiania lokalnych wynalazków z listkiem figowym w postaci “nieodpłatnego oprogramowania”.

§13 nakłada wprost wymóg “realizacji wymagań” Web Content Accessibility Guidelines (WCAG 2.0) na poziomie AA.

Pewne wątpliwości budzi §15, który mówi, że rozliczalność w systemach powinna dotyczyć tylko dostępu z prawami administratora, rekonfiguracji i dość niejasnych “działań użytkowników lub procesów polegających na dostępie do (…) przetwarzanych w systemach danych podlegających prawnej ochronie”. Zdanie to jest mętne zarówno pod względem semantycznym jak i merytorycznym. Nie wiadomo o jaką “prawną ochronę” chodzi i, jeśli dobrze rozumiem, zgodnie z tym przepisem system może w ogóle nie rejestrować dostępu czy modyfikacji dokumentu przez poszczególnych użytkowników (kłania się słynny par. 428).

Załącznik nr 1 zbiera w jednym miejscu i standardyzuje rozmaite typy danych stosowane w administracji (PESEL, REGON, dane geodezyjne).

Moje zdziwienie budzi natomiast załącznik nr 2, bo jest to właściwie przepisane bez zmian rozporządzenie o minimalnych wymaganiach z 2005 roku, ze wszystkimi tego konsekwencjami. Oznacza to, że znajdziemy tam m.in.: