Krajowe Ramy Interoperacyjności - uwagi do projektu

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

§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.:

  • brak precyzyjnego określenia gdzie właściwie trzeba te formaty stosować, a gdzie nie (A2C, C2A, A2A?); kilka pytań kontrolnych:
    • czy zgodnie z obecnym brzmieniem dokumenty wymieniane między komponentami backoffice urzędu w formacie SQL powinny być teraz eksportowane do formatu CSV zamaskowanego jako TXT i ponownie importowane?
    • w jakim formacie minister gospodarki ma opublikować listę obciążeń administracyjnych (obecnie w formacie XLS), skoro żaden format arkusza kalkulacyjnego nie jest w załączniku "dozwolony"?
  • przypadkowy katalog popularnych formatów dokumentów, obrazków i archiwów, w wielu przypadkach bez żadnej informacji normatywnej - to dziwne, bo przecież zarówno PDF, ODT jak i OOXML są normami ISO; tymczasem według autora projektu formatami tymi zarządza nadal Adobe (przekazali do ISO) i Microsoft (przekazali do ECMA);
  • brak jakiegokolwiek określenia minimalnych i maksymalnych wersji poszczególnych formatów, przez co załącznik traci sens jako minimalne wymagania (baseline); zgodnie z obecnym brzmieniem zaszyfrowany plik zabezpieczony DRM będzie zgodny, byle tylko nazywał się PDF i jakiś program go otwierał;
  • archaiczne formaty typu RTF;
  • formaty prywatne i nie mające żadnego osadzenia w normach czy standardach typu RAR;

Wymienione usterki były w ostatnich 6 latach głównym powodem, dla którego rozporządzenie o minimalnych wymaganiach nie spełniało swojej roli i w obecnej wersji projektu autorzy te błędy niestety powielili.

Więcej na ten temat w artykule Debata o nowelizacji ustawy o informatyzacji (2008).

I jeszcze krótko o samej formie projektu, bo pozytywnie wyróżnia się na tle innych urzędów. Projekt KRI został opublikowany jako tekstowy PDF (przeszukiwalny i kopiowalny), z wyraźną czcionką (Verdana?) i czytelnymi odstępami między liniami, za co autorom jestem wdzięczny.

AttachmentSize
uwagi_do_kri.pdf603.59 KB
wersja_po_uzgodnieniach_wewnatrz_resortowych_do_akceptacji_kierownictwa_krajowe_ramy_interoperacyjnosci.pdf444.7 KB