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.