Krytyka Politechniczna Krytyka Politechniczna
169
BLOG

Systemy informatyczne PESEL&ŹRÓDŁO

Krytyka Politechniczna Krytyka Politechniczna Technologie Obserwuj notkę 0

Dzisiaj RMF FM podał informację o wycieku z bazy PESEL danych ok. 800 tyś. osób. Informację podał dalej portal ZaufanaTrzeciaStrona.pl i Niebezpiecznik.pl. Wyciek został zauważony przez Ministerstwo Cyfryzacji. Był ponoć dokonany przez 5 kancelarii komorniczych, do których weszła prokuratura; sprawę bada ABW.

Trzy dni temu padł system ŹRÓDŁO, nie można było rejestrować zgonów przez jakiś czas. Awarię usunięto tego samego dnia, dalej COI miał analizować przyczynę awarii - czyli zrobiono obejście (workaround) problemu, a jego przyczyna i rozwiązanie długofalowe pewnie powstanie później (o ile w ogóle - to zależy).

Pierwszy problem pokazuje, że można było przez długi czas (rzędu roku) wyciągać zgrupowanymi zapytaniami (po 100 osób - bo ponoć API dla komorników na tyle pozwala) dane dotyczące obywateli. Media podają, że wyciągnięto przez 5 kancelarii w sumie ok. 2 mln rekordów.

W tego typu systemie powinny być mechanizmy (procesy), które uniemożliwiają proceder na taką skalę. Powinien być limit dzienny rekordów do pobrania per konto. Po stronie serwera powinny logować się informacje o wywoływanych funkcjach API (czyli np. pobieraniach danych na podstawie numerów PESEL), które pozwalają na przeprowadzanie analizy w czasie rzeczywistym (ale i takiej typu Business Intelligence - miesięcznej, kwartalnej, rocznej), aby wykryć anomalnie w ruchu. Zapytania z kancelarii idące w setki tysięcy rekordów, to coś raczej podejrzanego, a można to dość łatwo wykryć.

Ministerstwo cyfryzacji wykryło to po prawie roku od objęcia rządów, mam nadzieję, że przyjrzą się innym systemom i wprowadzą (o ile już nie wprowadzili) procesów, które pozwalają kontrolować sposób wykorzystania ich systemów. Być może wymagać to będzie ingerencji w te systemy - ale to są poprawki z kategorii bezpieczeństwa aplikacji, które są dość krytyczne i trzeba je brać na poważnie.

Skupmy się teraz na drugim systemie, który wspomniałem na wstępie. Wszystkie systemy techniczne cechuje awaryjność, która w przypadku urządzeń mechanicznych/elektronicznych wyrażana jest przez parametr MTBF (Mean Time Between Failure) - który mówi, za ile nasz zegarek, dysk twardy, samochód, elektrownia atomowa ulegnie awarii. Jest on wyznaczany co do zasady statystycznie, raczej mówi o rzędzie wielkości niż o konkretnych wielkościach (np. 500 000 godzin). Podobne zachowanie cechują systemy informatyczne - oprogramowanie.

Oprogramowanie może działać w sposób niepożądany z kilku powodów. Najczęstszą przyczyną jest błąd w kodzie źródłowym, który może objawić się praktycznie na dowolnym stadium życia oprogramowania - jego wykrycie zależy od częstotliwości występowania, powtarzalności, skutków jakie wywołuje. Możliwe są też inne przyczyny błędnego działania programu - co jakiś czas trafiają się przekłamania w przetwarzaniu danych przez procesor (np. bit w przerwie zabronionej, między stanem wysokim i niskim), mogą się trafić niewykryte błędy w danych przesyłanych między urządzeniami. Istnieją co prawda kody korekcyjne i retransmisja uszkodzonych ramek/segmentów/pakietów, ale hipotetyczna możliwość istnieje. A błędy pojawiają się stosunkowo często - BER (Bit Error Rate) dla Wi-Fi jest rzędu od 10^(-3) (1 błędy bit na 1000) do 10^(-6), w przypadku połączeń miedzianych jest to ok. 10^(-9), dla światłowodów 10^(-12). Więc wszystko może być jak trzeba, a mimo tego jest szansa, że coś nieoczekiwanego się stanie.

Zastanówmy się teraz, jak wygląda sprawa dostępności do takiej usługi, jak system ŹRÓDŁO. Dostępność na poziomie 99% w skali roku oznacza, że system może nie działać przez 3,5 dnia (1 % z 365 dni w roku to ok. 3,5 dnia). Dostępność na poziomie 99,9% oznacza, że przez 0,365 dnia (ok. 8h) system może sumarycznie nie działać. Czy jest to dużo czy mało - to zależy. W przypadku systemu rejestracji zgonów (a taki uległ tutaj awarii), nie ma potrzeby, aby system był z dostępnością np. 99,999% (ok 5 minut niedostępności w skali roku), ponieważ osoba korzystająca z usługi może po prostu poczekać chwilę. Ale w przypadku, gdy ulegnie awarii np. OADM (Optical Add-Drop Multiplexer - element infrastruktury telekomunikacyjnej sieci optycznej, używany np. w sieci szkieletowej), który jest podłączony do światłowodu z sygnałem o przepływności 40 Gbit/s (a to nie jest high-tech, są takie po 320 Gbit/s), to w przeciągu 50 ms (czas na rekonfigurację sieci w przypadku wykrycia awarii) idzie 'w powietrze' 50 ms * 40 Gbit/s = 2000 Mbit = 2 Gbit = 250 megabajtów (tylko z jednego światłowodu).

Owszem, dobrze jest mieć wysoką dostępność systemu (po to je tworzymy, aby działały). Trzeba jednak pamiętać, że wraz ze wzrostem dostępności rosną też koszty CAPEX/OPEX systemu (wytworzenia i utrzymania systemu). I dobrze jest, gdy właściciel systemu się zastanowi, czy opłaca mu się w to inwestować dowolnie duże pieniądze (które w omawianych systemach są nasze - podatników).

Nowości od blogera

Komentarze

Inne tematy w dziale Technologie