zarządzanie bezpieczeństwem danych

Ryzyko by default, podatność by design, czyli zarządzanie bezpieczeństwem danych

Zarządzanie bezpieczeństwem danych a RODO

Jedną z nowości, które wniosły ze sobą nowe przepisy o ochronie danych osobowych było wprowadzenie klauzul „privacy by default” oraz „privacy by design”. Ich zadaniem było wymuszenie na administratorach danych osobowych zapewnienia ochrony danych jako domyślnej cechy każdego zbioru oraz opracowanie procedur bezpieczeństwa już na etapie projektowania systemów informatycznych. Trochę szerzej pisałem o tym w artykule pt. GDPR / RODO i marketing zastraszany. Od wejścia w życie RODO minęło już sporo czasu, można by się zatem spodziewać, że w kwestii ochrony danych osobowych wiele zmieniło się na lepsze. Czy w rzeczywistości zarządzanie bezpieczeństwem danych przyniosło pozytywne efekty? Niestety niewiele na to wskazuje. Codziennie praktycznie spotykam się z przykładami braku wystarczającej rzetelności w procesie zabezpieczania danych.

Wyciek danych jako pożądana funkcjonalność?

Wycieki danych nie zawsze są efektem błędów technicznych czy świadomych działań intruzów. Zdarza się też tak, że system informatyczny zwyczajnie pozwala na dostęp do danych, ponieważ jego autorzy nie widzą w tym nic niestosownego. Z takim przypadkiem spotkałem się przy okazji udziału w jednym z biegów organizowanych na okoliczność setnej rocznicy odzyskania przez Polskę niepodległości. Jako uczestnik biegu otrzymałem od organizatorów link, pod którym mogłem zweryfikować swoją obecność na liście startowej. Formularz weryfikacyjny wyglądał, jak poniżej:

zarządzanie bezpieczeństwem danych - bieg
fot. formularz weryfikacyjny uczestników biegu

Jak widać powyżej, w celu weryfikacji swojej obecności na liście startowej należało podać samo nazwisko i klub (miasto), z którego nastąpiło zgłoszenie. Już na pierwszy rzut oka wydaje się to dziwne, bo czy można zakładać, że na tak dużą imprezę (ponad 30 tys. uczestników) zapisze się tylko po jednej osobie o konkretnym nazwisku z każdego miasta? Oczywiście nie. A zatem po wpisaniu własnego nazwiska i miasta oczom moim ukazała się lista wszystkich osób o takim samym nazwisku startujących z Poznania. Ponadto na liście tej oprócz nazwiska przy każdej osobie widniał jej numer startowy, rok urodzenia oraz informacja o wniesionej opłacie startowej. O ile moje nazwisko nie należy do bardzo popularnych, o tyle po wpisaniu w formularzu wartości „Nowak” otrzymać można było dane kilkuset osób:

zarządzanie bezpieczeństwem danych - nowak
fot. lista wyników dla nazwiska Nowak

Powtórzenie tej samej operacji dla kilku innych popularnych nazwisk daje już dostęp do kilku tysięcy rekordów. I żeby nie było wątpliwości, są to dane osobowe. W myśl definicji za dane takie należy uznać każdą informację, która pozwala na identyfikację konkretnej osoby fizycznej. Imię, nazwisko, rok urodzenia i miejscowość bez wątpienia stanowią zatem dane osobowe. Co więcej, numer startowy widniejący na liście pozwala również bardzo często na uzyskanie wizerunku zawodnika. Dzieje się tak ponieważ podczas biegów wykonywane są zdjęcia, które później można wyszukiwać online w celu zamówienia odbitek lub kopii cyfrowych. Wyszukiwanie odbywa się najczęściej właśnie za pomocą numeru startowego. Jak to możliwe, że autorzy systemu służącego do rejestracji uczestników nie przejmują się tym faktem? Odpowiedź po części znaleźć można w klauzuli informacyjnej dołączonej do jednego z formularzy wypełnianych przez zawodników:

zarządzanie bezpieczeństwem danych - stara klauzula
fot. Stara klauzula zgody odnosząca się do ustawy z 1997r.

Jak widać autorzy serwisu odnoszą się jeszcze do przepisów starej Ustawy o Ochronie Danych Osobowych z 1997r. Być może dlatego nieznane im są takie pojęcia jak „privacy by default” czy „privacy by design” i zarządzanie bezpieczeństwem danych.

Ale to nie wszystko, są też podatności techniczne

Próbując odpytywać formularz o kilka popularnych nazwisk, za którymś razem pomyliłem się wpisując zamiast polskiego znaku diakrytycznego jakiś „krzaczek”. W efekcie otrzymałem błąd serwera SQL. Błąd taki często wynika z faktu, iż autor systemu nie poddaje danych wejściowych prawidłowej weryfikacji. Jest to zatem jednocześnie wskazówka, iż system może zawierać podatności techniczne typu sql injection. Aby to potwierdzić wysłałem formularz jeszcze kilkukrotnie z różnymi wartościami pola ‚klub’, próbując zmienić składnię wykonywanego w bazie danych zapytania. Ostatecznie udało mi się dodać do niego wartość powodującą wyświetlenie wszystkich rekordów z bazy, dla których pole ‚imie’ zawiera dowolną treść. W efekcie możliwy było wyświetlenie danych wszystkich, ponad 30 tys. uczestników biegu. Informację o dokonanych próbach i znalezionych błędach wysłałem natychmiast do autorów serwisu. Warto pamiętać, iż gdyby działania te zakłócały funkcjonowanie systemu i nie miały na celu zwiększania poziomu jego bezpieczeństwa, to ich przeprowadzenie byłoby niezgodne z obowiązującym w Polsce prawem.

Zarządzanie bezpieczeństwem danych kuleje

Opisany scenariusz nie stanowi wcale pojedynczego przypadku. W ostatnich tylko dniach głośno było o dużo poważniejszych wyciekach danych m.in. z serwisów morele.net, wietnamwiza.com czy sieci hoteli Marriott. Niestety wielu administratorów danych uczy się na własnych błędach i procesy zarządzania bezpieczeństwem wdrażane są u nich dopiero wówczas, gdy wystąpi poważny incydent. Taki stan rzeczy utrudnia prawidłowe reagowanie i obsługę sytuacji krytycznych, o czym pisałem już w artykule Wyciek danych –  jak tego nie robić – studium „przypadku”

Jak widać musi jeszcze upłynąć sporo czasu zanim pojawiające się w przepisach prawa idee ochrony naszej prywatności przyniosą wymierne efekty.

 

Podobał Ci się tekst? Pomóż nam w jego promocji.

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.