50 Największych Banków w Polsce 2017: Najważniejsze są dane i procesy
Rozmowa z Rafałem Owczarkiem, Business Development Managerem IBM Security w Avnet oraz Łukaszem Durkalcem, Dyrektorem ds. Technicznych w Advatech.
Od czego należy rozpocząć przy – gotowania do projektu GDPR?
Rafał Owczarek [RO]: Często można spotkać się z przekonaniem, że GDPR to problem ograniczony do działu IT, w związku z czym wystarczy wdrożyć odpowiednie rozwiązanie informatyczne. Oczywiście to nieprawda. Rozporządzenie do – tyczy całej organizacji, wszystkich jej działów i jednostek. Dlatego przede wszystkim należy uważnie przyjrzeć się całemu procesowi przetwarzania danych osobowych. Trzeba sprawdzić, jak dane wpływają do organizacji, w jaki sposób staje się ona ich posiadaczem i co się później z nimi dzieje. Każda organizacja jest inna. Proces musi być zmodyfikowany, a rozwiązania dobrane zgodnie z przebiegiem informacji w danej firmie. Może się też okazać, że część pracy została już wykonana wcześniej, przy okazji projektów mających na celu zapewnienie zgodności z innymi, branżowymi regulacjami i nor – mami. Czasem trzeba będzie jednak zacząć od zera.
Na co należy zwrócić szczególną uwagę?
Łukasz Durkalec [ŁD]: Przede wszystkim na dane. Kluczowe jest zidentyfikowanie danych osobowych i systemów, w których się one znajdują. Dotyczy to także rozmaitych plików zawierających informacje pozwalające identyfikować konkretne osoby, ale nie zapominać jednocześnie o tradycyjnych dokumentach zalegających często tonami w magazynach. GDPR wprowadza zmiany w samym rozumieniu tego, czym są dane osobowe. W Polsce dotychczas obowiązywała Ustawa o ochronie danych osobowych z 1997 r. W chwili jej powstawania nie było tylu systemów informatycznych, tylu informacji, tylu rodzajów danych. Warto przypomnieć, że dopiero rok później po – wstało Google. Rozporządzenie rozszerza definicję danych osobowych. To już nie tylko imię i nazwisko, ale także wszelkie dane np. biometryczne, które pozwalają na jednoznaczne identyfikowanie konkretnych osób.
Z jakimi wyzwaniami będzie trzeba się zmierzyć?
RO: Dokonanie audytu danych strukturalnych, znajdujących się w ustrukturyzowanej hierarchii bazodanowej, to będzie tylko część sukcesu. Większe wyzwanie stanowią dane niestrukturalne zlokalizowane w plikach i dokumentach rozproszonych w całej infrastrukturze. A to właśnie danych tego rodzaju przybywa najszybciej. Tymczasem ich wyszukiwanie nie jest proste. Dlatego wymaga zastosowania specjalizowanych rozwiązań.
ŁD: Potencjalnych wyzwań i problemów jest bardzo wiele. Można sobie wyobrazić następujący przypadek: mamy aplikację działającą na bazie danych zawierającej dane osobowe. Twórca aplikacji wprowadził do niej tzw. odkładanie wyjątków. To oznacza, że w przypadku awarii, informacje o błędzie, razem z przetwarzanymi danymi zostaną zapisane w logach. W konsekwencji mogą się tam znaleźć dane osobowe i nikt nie będzie o tym wiedział, dopóki nie zacznie analizować logów.
RO: Niektóre firmy mogą zetknąć się z problemem zapomnienia, który niestety często jest pomijany we wstępnej fazie przygotowań do projektu GDPR. Każdy ma prawo zażądać usunięcia swoich danych – jeśli zezwala na to prawo. Takie wymazanie jest wyzwaniem w kontekście zapewnienia spójności dla całego zbioru. Dotyczy to zwłaszcza systemów analizujących duże zbiory danych, czyli coraz bardziej popularne systemy big data. Biznes stara się wykorzystać jak najwięcej różnorodnych danych do zdobywania wartościowych informacji. Tymczasem z chwilą usunięcia danych osobowych wyzwaniem jest zachowanie prawdziwości informacji bez części dostępnych wcześniej danych.
Czy wyzwaniem może być technologia?
ŁD: Rozporządzenie GDPR jest neutralne technologicznie. W przeciwieństwie do innych regulacji, takich jak np. rekomendacja D, autorzy nie wskazują rozwiązań, jakie należy zaimplementować. Niemniej wyspecjalizowane rozwiązania techniczne są niezbędne.
A co IT ma do zaproponowania w kontekście GDPR?
ŁD: W naszej ofercie znajdują się technologie IBM, które pozwalają w relatywnie krótkim czasie uporać się z problemem związanym z danymi niestrukturalnymi. Umożliwiają one indeksowanie danych znajdujących się nie tylko na serwerach, ale także wszystkich urządzeniach końcowych. Dzięki nim można stworzyć mapę, która obejmuje wszystkie dane osobowe – strukturalne oraz nie – strukturalne – i prezentuje, gdzie one się znajdują. W oparciu o to wprowadza się mechanizmy retencji i restrykcji, a za pomocą narzędzi informatycznych można przenieść je w bezpieczne miejsce, objęte monitorowaniem, do którego dostęp jest regulowany odpowiednią polityką.
RO: Mamy do dyspozycji także narzędzia do anonimizacji lub pseudoanonimizacji danych – w zależności od tego, czy mówi- my o zachowaniu anonimowości podczas ich składowania, czy tylko w chwili ich użycia. To system pośredniczący pomiędzy bazą danych a aplikacjami, które pyta – ją o informacje. Rozwiązanie tak modyfikuje dane, że pozostają one spójne. Przykładowo, zgadza się suma kontrolna numeru PE- SEL, ale danych nie można powiązać z konkretną osobą. W takiej sytuacji, nawet kiedy nie jesteśmy w stanie zapewnić wymazania informacji z jakiegoś względu – z powodu regulacji prawnych albo architektury systemu – to możemy je chronić, w taki sposób, żeby uniknąć naruszenia.
ŁD: Dla uniknięcia tego problemu w przypadku nowych systemów GDPR wprowadza koncepcję privacy by design. Dane osobo – we i transakcyjne powinny być oddzielone. Niestety dla istniejących systemów takie rozdzielenie może być trudne do wykonania, jeśli w ogóle możliwe. Warto także wspomnieć, że proponowane rozwiązania techniczne dostępne są również w postaci usługi. Przy tym umożliwiają one zapanowanie nad danymi strukturalnymi i niestrukturalnymi, nawet jeśli zmieni się architektura środowiska. Również w sytuacji, kiedy przeniesiemy część lub wszystkie dane do chmury, to jesteśmy w stanie podążać za tymi danymi.
W którym momencie można uznać, że projekt się zakończył?
RO: GDPR ma swój początek, ale nie ma końca. Zgodność trzeba weryfikować na bieżąco. Każda organizacja jest odpowiedzialna za to, że zastosowane środki ochrony zapewniają bezpieczeństwo. Przykładem mogą być algorytmy szyfrowania. Jeśli okaże się, że z jakiegoś powodu przestały gwarantować bezpieczeństwo, trzeba je zmienić. To oznacza, że projekt GDPR nie skończy się nigdy.
