Dzisiejszy krótki artykuł techniczny jest spowodowany publikacją komentarzy przez Watchdog Polska na temat Biuletynu Informacji Publicznej. Chciałbym zastanowić się, bazując na mojej wiedzy i doświadczeniu, czy rzeczywiście mamy do czynienia z narzędziem godnym zaufania.

Biuletyn Informacji Publicznej (BIP) to urzędowy publikator teleinformatyczny, który w praktyce jest kluczowym źródłem informacji o tym, jak wydawane są publiczne pieniądze oraz umożliwia dostęp do procesów regulujących np. życie samorządowe. To tutaj powinniśmy znaleźć wszystkie informacje o przetargach, zawartych umowach czy wydatkach samorządów - czyli o sprawach, które bezpośrednio dotyczą każdego z nas. Ponieważ wdrażałem takie systemy, poznałem zasady i wymogi integralności danych oraz audytowania zdarzeń. Na czym to polega?

Obecnie według mojej wiedzy większość realizacji BIPów to wdrożenia przez firmy IT w ramach przetargów albo zapytań ofertowych, zazwyczaj jako część większych projektów informatycznych. Zgodnie z ustawą o dostępie do informacji publicznej, każdy BIP musi być prowadzony w formie odrębnej strony WWW, a firma IT wdraża system, który spełnia następujące wymogi formalne, z których wymieńmy najważniejsze:

1. moduł administracyjny zabezpieczony hasłem z delegacją uprawnień i przypisaniem dostępów do zarządzania treścią
2. mechanizm dziennika (Rejestr Zmian) automatycznie odnotowujący zmiany w treści informacji publicznych oraz próby dokonywania takich zmian przez osoby nieuprawnione
3. zapisywanie sum kontrolnych do rekordów zdarzeń np. zmian online, publikowanych dokumentów z wersjonowaniem zdarzeń tak, aby można było zweryfikować zmiany
4. obowiązkowe tworzenie kopii bezpieczeństwa bazy danych nie rzadziej niż raz na dobę
5. utrzymywanie serwera zastępczego na wypadek awarii

W 2017 roku Ministerstwo Cyfryzacji zrobiło krok w kierunku centralizacji, wprowadzając Scentralizowany System Dostępu do Informacji Publicznej (SSDIP). Miał on rozwiązać problemy z autoryzacją przez wprowadzenie logowania przez Profil Zaufany zamiast lokalnych kont, bezpłatną aplikację do prowadzenia stron BIP i scentralizowany system uprawnień. Jednak sama centralizacja logowania bez przeniesienia danych i mechanizmów kontroli poza jednostkę nie rozwiązuje fundamentalnego problemu ponieważ nadal ustawa umożliwia tworzenie własnych systemów. Korzystanie z SSDIP jest dobrowolne.

Chciałbym po prostu pokazać iluzję bezpieczeństwa. Ponieważ system CMS/BIP realizowany lokalnie przez instytucję jest obsługiwany albo przez outsourcing IT, ale w większość przypadków jest utrzymywany na serwerach jednostki po zakończeniu wdrożenia, a to oznacza, że do bazy danych (w tym cały system z rekordami oraz mechanizmu dziennika, czyli szumnie zwanego Rejestrem Zmian) oraz konta administratora systemu ma dostęp osoba z danej instytucji. Nie bójmy się tego powiedzieć, z instytucji, której pracownicy mają być audytowani.

Widzę tutaj ogromny problem potencjalnej możliwości manipulacji rekordami, który sam testowałem dla zabawy podczas wdrożeń sprawdzając czy i jak jest to możliwe. Jest to banalnie proste - aby zmodyfikować treść w BIP nie potrzebujemy oczywiście nawet dostępu do systemu CMS, wystarczy dostęp do bazy danych. Najczęściej jest to najbardziej popularny MySQL/MariaDB. Można zarówno przez odpowiednią nakładkę administracyjną, jak i przez bezpośrednie połączenie do bazy danych, zmodyfikować lub usunąć dowolny rekord… i nie zostanie po tym żadnego, powtarzam żadnego śladu, ponieważ zdarzenia logowania do usługi MySQL/MariaDB nie są częścią audytu systemu CMS. Teoretycznie oczywiście rozporządzenia oraz tzw. dobre praktyki wymagają odpowiedniego zabezpieczenia i pracownik zarządzający serwerem nie powinien tego wykonać. Ale może nie tylko usunąć ślady edycji z logów MySQL, lecz także zmodyfikować wszystkie inne ślady, bo znajdują się one w obrębie tego samego serwera.

Przeanalizujmy teraz mechanizm sum kontrolnych. System działa następująco: przy tworzeniu lub modyfikacji wpisu w BIP, w bazie danych powstaje nowy rekord z przypisanym numerem pozycji, powiązaniami i sumą kontrolną dla danej wersji. Ta suma teoretycznie ma gwarantować integralność wpisu - możemy sprawdzić czy jego treść nie została zmieniona. Jednak jest to zabezpieczenie pozorne z dwóch powodów:

Po pierwsze, mając dostęp do bazy, możemy po prostu usunąć wybrany wpis, zmodyfikować jego treść i wygenerować dla niego nową sumę kontrolną.

Po drugie, suma kontrolna tworzona jest tylko dla treści wpisu, ale już nie dla metadanych (jak data czy indeks w bazie). To otwiera furtkę do manipulacji historią wpisów - możemy stworzyć nowy wpis z dowolną datą historyczną, skopiować do niego zawartość innych rekordów i usunąć oryginalne wpisy. To może brzmieć skomplikowanie, ale w praktyce to prosta operacja, którą można zautomatyzować prostym skryptem czyszczącym wszystkie ślady.

Rozwiązaniem problemu mogłoby być delegowanie uprawnień administracyjnych poza jednostkę odpowiedzialną za publikację treści. Alternatywnie, minimalnym zabezpieczeniem powinno być chociaż utworzenie zewnętrznego serwera logów, gdzie wszystkie zapisy systemowe byłyby automatycznie replikowane. Wtedy każda nieuprawniona modyfikacja zostawiałaby ślad, którego nie dałoby się ukryć, bo istniałaby jego kopia poza kontrolą administratora lokalnego. Natomiast obecny system sum kontrolnych to w mojej ocenie fikcja: sumy są przechowywane w tej samej bazie danych co treść, więc można je dowolnie modyfikować. Nawet gdyby były przechowywane na zewnętrznym serwerze, powinny być dodatkowo powiązane relacyjnie z wpisami w sposób uniemożliwiający ich modyfikację bez pozostawienia śladu.

Te formalne zabezpieczenia, wymagane przez ustawę, w praktyce okazują się niewystarczające. Co można z tym zrobić? Oto kilka praktycznych propozycji, wykraczających chyba poza obecne wymogi prawne:

1. Zewnętrzny serwer logów - wszystkie zdarzenia systemowe powinny być automatycznie replikowane do niezależnego serwera, poza kontrolą jednostki. Najlepiej, żeby była to usługa zarządzana przez zewnętrznego dostawcę z odpowiednimi certyfikatami bezpieczeństwa.

2. Rozproszone sumy kontrolne - zamiast trzymać sumy kontrolne w tej samej bazie danych, można wykorzystać technologię blockchain do tworzenia niemodyfikowalnego rejestru zmian albo relacyjne sumy kontrolne. Każda zmiana byłaby zapisywana w rozproszonej sieci, co praktycznie uniemożliwiłoby manipulację historią.

3. Niezależny audyt - regularne, niezapowiedziane kontrole przeprowadzane przez zewnętrznych specjalistów ds. bezpieczeństwa, którzy sprawdzaliby nie tylko logi systemowe, ale także integralność bazy danych.

4. Automatyczna archiwizacja - cykliczne tworzenie kopii zapasowych całego systemu, przechowywanych w zewnętrznym, zaufanym repozytorium.

Próby częściowej centralizacji, jak SSDIP z 2017 roku, pokazują że kierunek jest dobry, ale implementacja niewystarczająca. Moim zdaniem potrzebujemy pełnej centralizacji mechanizmów kontroli i integralności danych, nie tylko warstwy dostępowej.

Wydaje mi się, że w realiach niedoborów pracowników IT z doświadczeniem takie mechanizmy kontrolne to raczej fikcja i ja osobiście widziałbym jakąś formę jednak częściowej centralizacji w kontekście np. elementów systemu zabezpieczeń. Ja nie posiadam odpowiednich kompetencji, żeby tworzyć architekturę takiego systemu, są odpowiedni specjaliści od tego. Widzę jednak poważny problem i chciałem tylko zwrócić uwagę na to jakim pozornymi zabezpieczeniami są wymogi co do BIPów. Fajnie było jednak się bawić tymi pseudo zabezpieczeniami posiadając wiedzę jak wielkie możliwości manipulacji procesem przetargu może mieć opóźnienie albo brak kompletności pewnych informacji…

Chciałbym tylko dodać na koniec, że po realizacji wielu wdrożeń dla sektora publicznego unikam tego segmentu.

• Dostęp Do Informacji