Policy note: rządowy dziennik elektroniczny, a dostęp do dokumentacji technicznej

kontrabanda.net 3 days ago

Niniejszy tekst opracowaliśmy w ramach inicjatywy SPOIWO, której „Kontrabanda” była jednym z członków–założycieli. Jest to nieformalna rekomendacja opracowana przez naszą redakcję w celu przedstawienia naszego stanowiska w związku z informacją o tym, iż ujawnienie kodu oraz dokumentacji technicznej rządowego dziennika elektronicznego nie jest planowane.

Wprowadzenie

Kontrowersje wokół dziennika Vulcan, które narosły we wrześniu 2024 roku po tym, jak zapowiedziane zostały opłaty za moduły takie jak usprawiedliwienia w aplikacji mobilnej, zdają się mieć swoje rozwiązanie po tym, jak Ministerstwo Edukacji Narodowej ogłosiło projekt ustawy powołujący rządowy dziennik elektroniczny.

Zgodnie z postulatami grupy nieformalnej „Szkoła bez opłat”, które zostały wystosowane w petycji do tego samego ministerstwa, oprócz stworzenia samego dziennika padła też kwestia otwartego dostępu do API oraz dokumentacji technicznej dotyczącej dziennika.

Dzienniki elektroniczne przetwarzają szereg danych wrażliwych należących do milionów dzieci i nastolatków uczęszczających do szkół. W sytuacji takiej, gdzie dwa podmioty komercyjne tworzą de facto duopol na rynku dzienników elektronicznych, ewentualne wycieki danych z chociażby jednego z nich mogą stanowić naruszenie ochrony danych osobowych należących do dużej grupy osób.

Autorzy petycji – to jest grupa nieformalna „Szkoła bez opłat” – argumentują, iż opłaty związane z utrzymywaniem dzienników elektronicznych Librus i Vulcan oscylują wokół kwoty 40 milionów złotych. Powołali się tutaj na szacunki przedstawione przez „Dziennik Gazetę Prawną”.

I o ile ministerstwo rzeczywiście spełniło główny postulat dotyczący uruchomienia dziennika elektronicznego, ogłaszając przy tym plan pierwszych wdrożeń w szkołach podstawowych już w następnym roku szkolnym (2026/2027), tak redakcja „Kontrabandy” dowiedziała się, iż rządowy dziennik elektroniczny – choć postulowano – nie będzie miał publicznie dostępnego kodu źródłowego, ani dokumentacji technicznej.

Słowo o otwartych standardach

Otwarte standardy API to uniwersalne i ustandaryzowane sposoby komunikacji aplikacji. Są jednymi z systemów wymiany informacji na świecie. Ich powszechność, użyteczność i otwartość doskonale się sprawdzają jako element wzajemnej komunikacji w różnych systemach komputerowych.

Należy zauważyć, iż otwarte standardy nie będą podlegały jakimkolwiek wpływom, tak jak w przypadku rozwiązań zamkniętych, dając nieprzerwaną ciągłość i pewność utrzymania technologii w dobrej kondycji technicznej. Taki typ komunikacji to publicznie dostępny dokument, przyczyniający się do łatwiejszej integracji, zapraszając innych do tworzenia aplikacji zewnętrznych dowolnie rozszerzających funkcjonalność o takie systemy.

W przypadku dzienników elektronicznych takich jak Vulcan czy Librus, popularnymi alternatywnymi aplikacjami były kolejno Wulkanowy czy szkolny.eu. Obie te aplikacje z uwagi na nieprzyjazność firm tworzących Vulcana czy Librusa musiały jednak zostać zamknięte, ponieważ były one tworzone w modelu wolontariackim i pokrycie kosztów za dostęp do API czy choćby kosztów sądowych znacznie przerastałyby możliwości finansowe zespołów wolontariuszy czy, dużo częściej, pojedynczych osób.

Otwarty kod źródłowy to większa transparentność działania aplikacji przy jednoczesnej oszczędności kosztów na licencje, czy dedykowany sprzęt informatyczny. Możliwość weryfikacji kodu to jeden z najważniejszych elementów niezależnych audytów bezpieczeństwa.

Mając na uwadze inicjatywę „publiczne pieniądze, publiczny kod”, którą w Europie promuje głównie Free Software Foundation Europe, zasadnym jest, aby system rządowego dziennika elektronicznego:

miał publicznie dostępny kod źródłowy,
wspierał otwarty standard komunikacji,
został uruchomiony i utrzymywany w sposób ekonomicznie uzasadniony,
oraz był niezależny od podmiotów zewnętrznych na każdym etapie wdrożenia.

Powyższych wymagań nie spełniają przynajmniej w znacznym stopniu zamknięte rozwiązania technologiczne, stąd opisywana otwartość jest naszym zdaniem drogą do wytworzenia wartości społecznie oczekiwanej.

Powody, dla których MEN powinno przemyśleć otwarcie kodu źródłowego oraz dokumentacji technicznej rządowego dziennika elektronicznego

Przykład mObywatela: jak tego NIE robić

W naszej opinii publikacja kodu źródłowego dziennika opracowywanego przez MEN w pełnym zakresie może być szansą na polepszenie się zaufania przynajmniej w tym zakresie do obecnego rządu.

Ujawnienie kodu jak i dokumentacji technicznej dziennika rządowego paradoksalnie może pomóc w szybszym załataniu luk bezpieczeństwa. Ponieważ kod rządowych aplikacji mogłyby obserwować jednocześnie setki, jak choćby nie tysiące osób jednocześnie, ich dostrzeżenie i załatanie może często nastąpić szybciej.

Ministerstwo Cyfryzacji „opublikowało” kod źródłowy mObywatela, poprzez ujawnienie wyłącznie kodu tworzącego interfejs użytkownika. Należy nadmienić, iż wokół mObywatela zaczęły jeszcze na długo przed „publikacją” powiązanego kodu źródłowego narastać plotki, iż aplikacja „szpieguje ludzi” – a na potwierdzenie lub obalenie tych tez pozwoliłoby ujawnienie kodu w pełnym zakresie, co nie nastąpiło.

Wiemy jedynie o tym, jakie stanowisko wydał CSIRT podległy Ministerstwu Obrony Narodowej, ale tutaj dowiedzieliśmy się z niego jedynie o potencjalnych następstwach ujawnienia kodu – CSIRT MON twierdził, iż może wystąpić ryzyko ataków typu supply chain (polegających na skompromitowaniu systemu metodą „na najsłabsze ogniwo” – czyli atakowaniu nie bezpośrednio serwerów mObywatela, ale np. słabiej zabezpieczonego dostawcy poszczególnej usługi). CSIRT MON jednocześnie podkreślił, iż ujawnienie kodu może zwiększyć zaufanie do mObywatela.

Pozostałe ekspertyzy, za które odpowiedzialne były CSIRT-y GOV i NASK – zostały uznane za tajemnicę państwową, wskutek czego najprawdopodobniej nigdy się nie dowiemy, jakie części kodu musiały pozostać niejawne, a jakie zostały uznane za bezpieczne do publikacji. W ten sposób akcja publikacji kodu mObywatela poskutkowała jeszcze większym pogłębieniem się problemu braku zaufania zarówno do usługi, jak i – długoterminowo – samego rządu.

Jak proces publikacji kodu i dokumentacji technicznej powinien przebiegać?

Zanim kod i dokumentacja techniczna zostanie ujawniona (jak i też zanim system zostanie uruchomiony w pierwszych szkołach), Ministerstwo Edukacji Narodowej powinno zamówić kompleksowy audyt bezpieczeństwa swojego rozwiązania i na jego podstawie wdrożyć wszelkie sugerowane poprawki.

Kod w pełnym zakresie wraz z dokumentacją techniczną powinien być dostępny bez uprzedniej autoryzacji do celów zewnętrznych audytów przez niezależnych ekspertów, wraz z możliwością jego kopiowania na urządzenia odwiedzających osób. Można to osiągnąć dzięki własnej instancji systemu takiego jak Gitea czy Forgejo (lista niewyczerpująca), dostępnej w dedykowanej subdomenie dziennika elektronicznego (np. kod.edziennik.gov.pl – zakładając, iż „eDziennik” rzeczywiście będzie dostępny pod taką domeną).

Na takim serwisie, opartym o wcześniej wspomniane oprogramowanie, proces kodu mógłby przebiegać następująco:

Zakłada się dedykowany profil organizacji – na potrzeby tego dokumentu nazwijmy go „eDziennik”.
Na profilu „eDziennika” tworzy się dedykowane repozytoria dla konkretnych mikroserwisów (moduł wiadomości, moduł planu lekcyjnego, moduł oceniania itd.), frontendu (tj. strony internetowej wyświetlającej dane), aplikacji mobilnych na platformy takie jak Android, iOS i tak dalej. Taka modularność pozwoli na kontrolowane ujawnianie kolejnych części kodu źródłowego wraz z wdrażaniem zaleceń zamieszczonych w wyżej wspomnianym audycie bezpieczeństwa. Streszczając: nie ma znanych luk – bezpieczne do publikacji, i odwrotnie, są znane luki – publikacja wstrzymana do czasu ich załatania.
W końcu, gdy ma się już pewność, iż znane luki zostały już w całości załatane, wtedy treść zamówionego audytu można bezpiecznie opublikować w łatwo dostępnej części strony internetowej Ministerstwa Edukacji Narodowej, lub jeszcze lepiej, na dedykowanej, łatwo dostępnej podstronie witryny informacyjnej rządowego dziennika elektronicznego.

Przykłady, w których bezpieczeństwo przez jawność wygrywa

Niektóre z nich to:

organizacja Signal Foundation (odpowiedzialna za komunikator Signal), której audyty bezpieczeństwa od zewnętrznych podmiotów są w ogromnej większości jawne,
oraz ukraiński odpowiednik naszego mObywatela – aplikacja Diia.

Rozwijając wątek Dii, ważną, fundamentalną różnicą w porównaniu do – naszym zdaniem – katastrofalnie źle przeprowadzonej akcji publikacji kodu mObywatela jest też to, iż Ukraińcy zdecydowali się otworzyć kod źródłowy swojej kluczowej usługi rządowej na wszystkich – choćby spoza granic swojego kraju (w przypadku mObywatela udostępniony kod de facto tylko części interfejsu użytkownika został zamknięty za Profilem Zaufanym, którego nie mogą założyć obcokrajowcy).

To, co do tej pory zostało opublikowane w ramach Dii, jest dostępne „otwartym tekstem” na GitHubie. Do tej pory w żadnych mediach – czy to międzynarodowych, czy ukraińskich – nie słyszeliśmy o żadnych poważnych problemach będących bezpośrednim następstwem publikacji kodu wybranych usług rządowych (stan na lipiec 2026).

Co więcej, kontrargumentem na zasadność modelu „bezpieczeństwa przez niejawność” jest to, iż ukraińska prasa donosiła o tym, iż to właśnie dzięki otwartości kodu Dii każdy o zdolnościach technicznych – nieważne, czy był obywatelem/-ką Ukrainy, czy nie – mógł sprawdzić, czy domniemany wyciek danych, który miał dotknąć choćby 20 milionów Ukraińców we wrześniu 2025 roku, był prawdziwy. Do incydentu w rzeczywistości nie doszło.