„Skutki” ochrony danych

Jeden z sobotnich poranków, sprawdzam prywatną pocztę i wśród wiadomości znajduję zatytułowaną w następujący sposób: „Komunikat ws. naruszenia ochrony danych osobowych” (więcej o takich komunikatach można znaleźć w sieci Internet) . W pierwszym momencie zrobiło mi się gorąco, bo tego się nie spodziewałem i może to być problem, w zależności od tego, który podmiot wysłał taką wiadomość (w domyśle jakimi danymi dysponował). Spojrzałem na nadawcę i trochę się uspokoiłem. Pierwsze pytanie, które sobie zadałem: „Kiedy korzystałem z tego serwisu?”. Na pewno dawno (po sprawdzeniu okazało się, że kilka lat temu), więc czytam już spokojnie całą wiadomość. Wiadomość można streścić w 5 punktach (więcej o takim zawiadomieniu można znaleźć na stronie UODO):

1. co się stało? czyli opis sytuacji;
2. co to może oznaczać? czyli konsekwencje. Przy tym punkcie postanowiłem, że sprawdzę jakie moje dane mają, zmienię hasło dostępu oraz wyślę prośbę o usunięcie konta.
3. co zrobili i co planują zrobić? To, co przeczytałem wzbudziło mój niepokój ale mnie nie zaskoczyło, bo te elementy znam już z artykułów związanych z RODO (o kilku kwestiach pisałem też na blogu).
4. co mogę zrobić po swojej stornie? Informacje odnosiły się bardziej do sugerowanych reakcji, gdy jednostka/osoba, która weszła w posiadanie moich danych, zaczęła je wykorzystywać. Utwierdziłem się w przekonaniu co do akcji, które chciałem podjąć. Dodatkowo zdecydowałem się na zarejestrowanie się w BIK, co wskazywał jeden z punktów.
5. dodatkowe informacje. Można powiedzieć, że przyjąłem do wiadomości.

Wykonałem akcje:

• [grupa A na diagramie:] sprawdziłem jakie dane podałem – na szczęście nie podałem PESEL, serii dowodu osobistego oraz innych specyficznych danych. Dane były bardzo ograniczone (uff!) i błędnie sformatowane ze względu na wprowadzone zmiany w systemie.
• [grupa A na diagramie:] zmieniłem hasło. Nigdy nie zaszkodzi.
• [grupa A na diagramie:] wysłałem prośbę o usunięcie konta w serwisie ze wszystkimi danymi powiązanymi (bo takiej opcji nie ma w samym serwisie) – nie jest mi potrzebny dostęp do tego serwisu i nie mam żadnych aktywnych usług/transakcji/opcji. Konto zostało usunięte.
• [grupa B na diagramie:] zapoznałem się z informacjami na stronie BIK, a następnie zarejestrowałem się w serwisie.

Powyższy diagram prezentuje wykonane ścieżki postępowania. Rozpoczyna się od zdarzenia inicjującego opartego o komunikat (message event). Następnie przybliża ścieżkę weryfikacji danych, zmiany hasła, prośby o usunięcie konta, a następnie rejestracji w BIK.    

Wskazany proces rejestracji w BIK (link znalazłem po przygotowaniu powyższego diagramu) jak widać ma dużo elementów mających na uwadze bezpieczeństwo danych oraz jednoznaczne potwierdzenie tożsamości. Samo potwierdzenie rejestracji jest wieloetapowe – trzeba zrobić przelew weryfikacyjny (na przykład korzystając z płatności online), dane przelewu muszą się zgadzać z wprowadzonymi danymi, trzeba wykonać kroki z wiadomości wysłanej na wskazany e-mail, po drodze dostajesz specjalny kod na wskazany numer telefonu i go podajesz podczas ustalania hasła, a potem trzeba zalogować się dodatkowo podając PESEL w formie maskowanej. Czułem, że podmiotowi zależy na ochronie moich danych przy równoczesnym zabezpieczeniu się przed nieuprawnionym dostępem do nich.

Po otrzymaniu takiej wiadomości, mamy jakieś opcje, aby upewnić się czy nasze dane nie zostały wykorzystane lub jak poznać, że zostały wykorzystane lub też co możemy zrobić, aby się ustrzec przed takim ryzykiem w przyszłości (wiadomość wskazywała takie opcje, można też znaleźć takie informacje w dedykowanych artykułach). Wiele zależy od rodzaju danych, które wpadły w niepowołane ręce. Im ich więcej lub/i bardziej detaliczne, to można powiedzieć, że ryzyko jakiś niechcianych zdarzeń, z perspektywy ich właściciela, rośnie.

Dobrze zawsze się zastanowić czy udostępniane dane (wprowadzane podczas rejestracji lub przy innej okazji) pasują do działań/operacji możliwych do wykonania w serwisie lub w danej funkcjonalności/procesie. Jeżeli na przykład w serwisie będzie tylko korzystać z publikacji wewnątrz serwisu, podawanie numeru PESEL czy dowodu osobistego nie wydaje się uzasadnione. Z kolei, gdy zamierzamy podejmować zobowiązania wymagające jednoznacznego potwierdzenia tożsamości, brak podania takich danych może uniemożliwić skorzystanie z takich usług online czy nawet stacjonarnie. O przykładzie nadmiarowych danych podczas zgłoszenia reklamacji pisałem w innym wpisie.

Reklama

Czy RODO wpływa na BPR?

Dwanaście lat temu, dokładnie 9 lutego 2008, we wpisie na moim blogu, wymieniłem kroki składające się na proces reengineeringu (tj. reinżynierii procesów biznesowych, w skrócie BPR). W powiązanych wpisach opisałem, wykorzystując również dostępne publikacje w tym temacie, z czego składają się wybrane kroki tego działania. Natomiast część kroków pozostawiłem bez rozbudowanych wyjaśnień. Wspomniany proces reengineeringu ma na celu przebudowę/zmianę procesu, która odbywa się w oderwaniu od obecnego przebiegu procesu. Takie podejście ma na celu stworzenie procesu, który spełnia oczekiwania jego odbiorców, realizuje potrzeby podmiotu oraz adresuje w odpowiedni sposób kwestie, które dotychczas nie zostały wzięte pod uwagę. Przypomnijmy jakie kroki zawiera to działanie – przedstawione w postaci procesu na diagramie poniżej.

Podczas przygotowania odpowiedzi na pytanie postawione w tytule, trafiłem na ciekawy artykuł, który idealnie podsumowuje kroki, które należy wykonać, aby przejść przez proces dostosowania organizacji do RODO. W artykule jest informacja że „te wymagania dotyczące zgodności [mój dopisek: chodzi o RODO] mogą stymulować inicjatywy związane z przeprojektowaniem procesów biznesowych”, czyli wspomnianym reengineeringiem.
Autor artykułu wymienia 6 kroków, które powinny podjąć organizacje, podmioty czy przedsiębiorstwa w momencie, gdy dostosowują się do wymogów RODO (GDPR).

Autor artykułu zwraca uwagę zarówno na aspekt budowy świadomości, zmiany kultury, zarządzania, jak i na kwestie samego procesu dostosowania. Sam proces dostosowania jest rozbity, trochę to upraszczając, na identyfikację danych, identyfikację przepływów oraz na zmianę kluczowych polityk i procesów. Właśnie tym 3 krokom składającym się na proces dostosowania chciałbym się bliżej przyjrzeć w kontekście reengineeringu. Dlaczego? Ponieważ efekty identyfikacji danych i przepływów mogą wpłynąć na decyzję o tym, jaki proces wybierzemy do reengineeringu a potem na dalsze kroki realizowane w ramach tego działania. Przyjrzę się teraz bliżej tym 3 krokom wskazanym w artykule i spróbuję (mam nadzieję, że w poprawny sposób) je odnieść do kroków reengineeringu – podsumowanie takiego odniesienia (w poniższych wyjaśnieniach takie elementy są podkreślone) znajduje się również na diagramie:

• Identyfikacja danych/Zestawienie danych w przedsiębiorstwie (odpowiednik „Catalogue data across the enterprise z artykułu”) – sprowadzając to do kroków reengineeringu, możemy podczas wyboru procesu zdecydować się na ten, w którym przetwarza się najwięcej danych osobowych lub/i który został oceniony jako (najbardziej) problematyczny pod względem zgodności z RODO (co się wpasowuje moim zdaniem w punkt „dotyczący skali problemów powodowanych przez proces” wymieniony w książce, o której piszę w jednym z wcześniejszych wpisów). Podczas analizy procesu możemy zwrócić uwagę na to jakie rodzaje danych występują lub nawet mogą być nadmiarowe w określonych krokach lub czy same czynności przetwarzania nie są zbyt rozbudowane a może dane są za długo przechowywane. Warto też przyjrzeć się uczestnikom procesu i ich potrzebom w zakresie danych. Odnosząc się do regulacji RODO, można jeszcze postawić wiele innych pytań. Myślę jednak, że już te wskazane pytania dają podstawy do głębszej analizy procesu. Celem działania jest określenie potrzeb i oczekiwań odnośnie docelowego procesu.
• Identyfikacja przepływów/Zweryfikuj przepływy danych w ramach przedsiębiorstwa (odpowiednik „Audit data flow across the enterprise” z artykułu) – podczas analizy procesu możemy spojrzeć na proces z perspektywy danych, które przepływają między jednostkami przedsiębiorstwa. Wyobraźmy sobie, że proces jest oparty o system i uczestniczą w nim co najmniej 2 jednostki biznesowe. Wykonują one różne zadania, ale mają dostęp do tych samych danych. Wg RODO w danym momencie użytkownik powinien mieć dostęp do danych, które są mu rzeczywiście potrzebne. W zależności od sytuacji, trzeba pogłębić temat lub odnotować ten fakt w wynikach analizy/rekomendacjach. Angażując różne jednostki kontrolne, regulacyjne, wspierając się specjalistami ochrony danych (na przykład włączając ich do zespołu), przedsiębiorstwo może wybrać określoną strategię postępowania w samym procesie i określić jakie dodatkowe działania należy podjąć, aby uniknąć problemów w przyszłości. Opiekun czy właściciel procesu może tutaj odegrać ważną rolę, ponieważ z założenia zna oczekiwania odnośnie procesu i jego dotychczasowy przebieg, a także związane z nim regulacje.
• Utwórz lub popraw kluczowe polityki i procesy (odpowiednik „Create or improve key policies and processes” z artykułu) – w ramach reengineeringu budujemy nowy proces. Jest to szansa aby spojrzeć na dane wykorzystywane w tym procesie z nowej perspektywy i zmienić sposób ich wykorzystywania. Podczas uwzględniania aspektu RODO może się okazać, że dla procesu trzeba dobudować lub podłączyć (istniejące lub nie) dodatkowe podprocesy lub procesy powiązane, które będą adresować specyficzne sytuacje. Może się także okazać, że w nowym procesie dane można ograniczyć do minimum i uprosić proces także z perspektywy jego odbiorcy. Budując nową wersję procesu konieczne jest także spojrzenie na obowiązujące regulacje oraz polityki postępowania związane z procesem. One także muszą zostać odpowiednio przebudowane, z zachowaniem zgodności z wprowadzonymi przez organizację procesami ochrony danych osobowych czy dedykowanymi politykami w tym zakresie.

Mam nadzieję, że udało mi się trochę przybliżyć ten wpływ RODO na BPR.  Sama odpowiedź na pytanie postawione w tytule jest jak najbardziej twierdząca. Tak jak wskazuje wspomniany artykuły może wręcz się przyczynić do rozpoczęcia takich działań lub nawet ich przyspieszenia.

—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Gdy aplikacja pamięta Twój telefon

Wczoraj otrzymałem maila o tytule „Próba logowania przy użyciu nieznanego urządzenia”. W pierwszym momencie zacząłem się zastanawiać… Czy ktoś loguje się moimi danymi, a może ktoś się pomylił… Przeglądając jednak treść wiadomości zauważyłem oznaczenie aplikacji, która wygenerowała taką wiadomość. Zainstalowałem na nowym telefonie aplikację (jednego ze sklepów stacjonarnych wraz ze sklepem internetowym), którą miałem także na starym telefonie. Podczas próby zalogowania się pomyliłem się i pewnie aplikacja zidentyfikowała, że logowanie nastąpiło po przerwie, ale z innego urządzenia. Sprawdziłem w regulaminie aplikacji, że oprócz podawanych świadomie danych przez użytkownika, zapisuje ona również numer używanego urządzenia mobilnego. Element ten widocznie pozwala na rozróżnienie, że użytkownik, który próbuje się zalogować użył innego urządzenia. Regulamin wskazuje po co zbiera tę informację i jawnie o tym informuje.

Na poniższym diagramie w BPMN, będącym moim wyobrażeniem procesu występującego w takiej aplikacji na bazie obserwacji aplikacji/narzędzi, z których korzystam, są wskazane kroki (na zielono), które w tle identyfikują urządzenie użytkownika i następnie w przypadku poprawnego logowania zapisują te dane. W przypadku nieudanego logowania, używa tych danych do weryfikacji zgodności urządzenia z poprzednio stosowanym. Taki mechanizm, stosowany także przez inne narzędzia, pozwala podnieść bezpieczeństwo logowania, chronić dane osobowe. Wykonuje to przez każdorazowe informowanie użytkownika na podany podczas rejestracji adres e-mail co najmniej o tym, że nastąpiła jakaś nieudana próba logowania (ścieżka (1) na diagramie).

Niektóre narzędzia/aplikacje wysyłają powiadomienie o poprawnym logowaniu, które nastąpiło z innego urządzenia niż dotychczas (ścieżka (3) na diagramie). W podanym przykładzie nastąpiło wejście do aplikacji, ale nie musi to nastąpić – zależy to od sposobu zbudowania aplikacji i przyjętych założeń. Może być tak, że najpierw użytkownik musiałby potwierdzić, że to on się logował. Na diagramie zostały zaznaczone obydwie takie opcje obok ścieżki gdy dane poprawne logowanie odbywa się z tego samego urządzenia co dotychczas (ścieżka (2)).

Powyższy przebieg procesu został zasygnalizowany przy użyciu odpowiednich elementów BPMN, przy czym:

• (oznaczona przez (A)) do przeprowadzenia równoczesnej identyfikacji urządzenia oraz identyfikacji użytkownika pod kątem późniejszej autentykacji  użyto bramek rozdzielających i łączących dla ścieżek równoległych (ang. paralel gateway).
• (oznaczona przez (B)) do podjęcia decyzji są użyte bramki oparte o dane, w których tylko jedna ze ścieżek jest możliwa (ang. exclusive).

Użytkownik otrzymując taką wiadomość (kroki oznaczone na żółto na diagramie) może zadecydować czy jest to sytuacja, o której wie, czy może jest to sytuacja, na którą powinien zareagować. Na przykład nie używał aplikacji danego dnia lub w ostatnim czasie, a nagle otrzymuje informację o próbie zalogowania nieudanego lub udanego.

Jeżeli dane narzędzie/aplikacja ma taką obsługę logowań, to widzę 2 możliwości:

• Twórca/Właściciel narzędzia równocześnie zapewnia narzędzia wspierające obsługę reakcji użytkownika (np. tymczasowa blokada użytkownika, kontakt z twórcą/właścicielem lub inne) lub
• Mechanizm ma tylko charakter informacyjny i użytkownik na własną rękę musi poszukać metod reakcji (np. zmienić hasło).

Myślę, że to dobrze, że istnieją takie mechanizmy. Dzięki takim rozwiązaniom mamy większą pewność, że nasze dane, przechowywane w aplikacji, nie zostaną podejrzane przez nieuprawnioną osobę lub też dowiemy się szybko o tym, że ktoś taką próbę wykonał. Patrząc na serwisy, aplikacje dostępne z różnych urządzeń, jest to duże ułatwienie oraz wsparcie w zakresie realizacji wskazówek dotyczących bezpiecznego korzystania z aplikacji mobilnych (opublikowanych na stronach urzędowych).

Użytkownik otrzymując taką wiadomość w sytuacji, gdy określa ją jako wymagającą zareagowania, powinien zastanowić się jakie dane podał w danej aplikacji – ograniczoną liczbę informacji (np. tylko e-mail) czy dane generujące dla ich właściciela duże ryzyko (np. dane pesel, adres zamieszkania, numer dowodu wraz z wizerunkiem czy danymi finansowymi). Mam nadzieję, że nikt z czytelników mojego bloga nie doświadczył tego bardziej ryzykownego wariantu.

—
Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.