Minęło już trochę czasu od chwili ogłoszenia tekstu rozporządzenia zwanego skrótem RODO (4 maja 2016). Mniej od czasu, kiedy rozporządzenie ma zastosowanie (25 maja 2018 r.). Po pierwszej fali, może nie paniki, ale wzmożonego zainteresowania, gdzie temat „RODO” otwierał wiele drzwi nastał okres znudzenia. Właściwie mówienie o RODO jest jak noszenie na głowie „płetwy” albo pod nosem wąsów ze śladami niedzielnej zupy- po prostu „demode”. O RODO/GDPR powiedziano tyle, że Himilsbach z Maklakiewiczem nie wypili tyle wódki, Gargantua tyle nie zjadł, a Casanova tyle nie po… pisał pamiętników. Niemniej pokusa by dorzucić jeszcze do pieca jest tak paląca jak wysypka po Juwenaliach (kto nie przeżył niech nie ocenia).
Oczywiście, że tytuł artykułu jest ironiczny. Taki z tego rozporządzenia „game changer” jak z drabiny winda. RODO było szansą na uporządkowanie problemu zarządzania prywatnością, danymi w organizacji, mogło być szansą na stworzenie wydajnej architektury informacji. Mogło być cynglem odpalającym weryfikacje procesów zarządzających obiegiem informacji wrażliwej.
Stało się natomiast żniwami dla kancelarii lub firm para prawniczych twierdzących, że dzięki kolejnemu podpisanym oświadczeniu i papierowej, niemającej odbicia w rzeczywistości procedurze, zapobiegnie się niemałym przecież karom przewidzianym przez twórców rozporządzenia.
Nie jest to podejście inżynierskie, nie załatwiło się całości spraw. W wielu organizacjach zamiotło się problem pod dywan i tylko postawiło tabliczkę z napisem „Uwaga dane osobowe, nie deptać po wypukłościach”.
Oczywiście RODO nie przeszło niezauważone. Wzrosła świadomość użytkowników, ABI dłubie długopisem w nosie w każdej większej organizacji i nawet gdzieniegdzie pobrzmiewa głos cienki jak głos staruszka wołającego o faworki i kompot z rabarbaru- „Może coś byśmy z tymi danymi zrobili”.
Właśnie idąc za tym głosem poniższe tezy i uwagi:
Trudno mówić o wdrożeniu skutecznego w praktyce procesu ochrony danych osobowych, jeśli nie wyodrębnimy zbiorów danych, które są kluczowym elementem polityk bezpieczeństwa przetwarzania danych osobowych. Jest to istotne również dlatego, że istnieje nowa forma „zgłoszenia” zbiorów danych osobowych. Dotyczy ona tych administratorów danych, którzy zdecydowali się powołać Administratora Bezpieczeństwa Informacji (ABI). ABI prowadzi jawny rejestr zbiorów, zawierający opis zbiorów, dotychczas wymagających zgłoszenia do GIODO.
Czyli musimy wiedzieć, gdzie przetrzymujemy dane osobowe.
I tu pojawia się pytanie. Dlaczego tylko dane osobowe? Przecież nie jest to jedyna istotna informacja, której utrata stanowi ryzyko dla Przedsiębiorstwa. Przecież zawsze, jeżeli coś projektujemy starajmy się rozwiązywać projekt całościowo, przewidywać i minimalizować ryzyka. Dlatego przy okazji załatwienia wymagania „compliance’owego” możemy stworzyć mechanizm informujący nas, gdzie znajduje się dowolna informacja wrażliwa.
Oczywiście wszyscy znamy klasyczny podział danych w środowisku IT. Gartner dzieli je na:
- Uporządkowane (strukturalne)- dane znajdujące się w bazie danych, aplikacjach – 20%
- Nieuporządkowane (niestrukturalne) – znajdujące się na serwerach plików, w poczcie itd. – 80%
Dane strukturalne stosunkowo łatwo śledzić i chronić właśnie dlatego, że są uporządkowane. Maja reguły, strukturę – wiemy, gdzie się znajdują, a więc zabezpieczając bazę (DAM) albo aplikacji (WAF) możemy chronić zasób. Możemy tez zastosować inne podejście – procesowe. I obserwując proces uszczelnić przepływ informacji. Oba takie podejścia można nazwać „postanowieniem noworocznym”, czyli od tej chwili zabezpieczam nie przejmując się co było wcześniej, ile eksportów z aplikacji leży na „szerach” albo w poczcie. Od teraz już będzie wspaniale.
Żeby to było jasne nie krytykuje postanowień noworocznych, sam mam ich za sobą więcej niż pamiętam. Pewnie, że lepiej zacząć chodzić na basen i rzucić dopalacze niż nie zaczynać (nawet w sferze deklaratywnej).
Wyobraźmy sobie hipotetyczny przypadek. Organizacja posiada system bilingowy, który w cyklach miesięcznych wypluwa rachunki dla klientów. System jest uszczelniony i zabezpieczony, dostęp do niego jest monitorowany. Natomiast walidacja poprawności wyliczenia rachunków odbywa się poprzez przesyłanie korporacyjną pocztą bilingowego pliku kontrolnego (zawierającego wszystkie rekordy) do kilku, kilkunastu osób z których każda wykonuje jakiś element sprawdzenia poprawności bilingu: zlicza sumę kontrolna bądź ręcznie waliduje poprawność naliczeń. Czy po sprawdzeniu usuwają te pliki? Czy też po każdym roku w poczcie, na kilkunastu kontach zostaje dwanaście plików zawierających nie tylko dane osobowe, ale dane wrażliwe ze względów biznesowych?
Czy jest to niemożliwe w rzeczywistości? Czy jest to, aby na pewno przypadek hipotetyczny?
Wszystkie takie dokumenty, eksporty z aplikacji, współdzielone listy kandydatów z HR-u, wyciągi z CRMów, bazy danych klientów, współdzielone umowy lub dokumenty do pracy grupowej pomieszane na file serwerach i codziennie w terabajtach produkowane przez pracowników organizacji to dokumenty nieuporządkowane. Informacja nie ma struktury, a proces, który tym zarządza to najczęstszy proces w organizacji, czyli adhoc.
I tutaj zaczynają się cieszyć producenci DLP: „To właśnie przypadek dla nas”.
A figa z makiem (było inne sformułowanie zawierające wyraz „prawda”, ale po interwencji zamieniłem). Wdrożenie DLP jest tutaj jak Grubas, który unika patrzenia w lustro- sam przed sobą udaje, że wszystko jest ok. Co z tego, że zatkaliśmy wyjście rury, która popękała w ścianie. Uszczelniamy na brzegach (co również jest ważne) a bałagan dalej zostaje w środku. Co z tego, że producenci DLP maja wypisane na sztandarach, że znajdują dane wrażliwe, kiedy wynikiem skanu jest lista 500K plików z danymi. Co z tym zrobić?
Musimy wdrożyć mechanizmy korelujące informacje o zawartości plików z mechanizmami informującymi kto ma do plików dostęp, musimy tymi dostępami zarządzać, wiedzieć kto plik używa i czy w ogóle używa. (Ciekawą problemem są pliki „osierocone”). Tylko połączenie takich informacji pozwoli nam sprawnie zarządzić terabajtami danych.
Czy chcemy czy nie, kłania się tutaj system klasy Data Governance.
Podstawowym wymaganiem jest tutaj zaprojektowanie wydajnej architektury informacji korporacyjnej. Oczywiście, że powinny się w niej znaleźć elementy DLP i ochrona danych strukturalnych, ale tylko jeżeli architektura to przewiduje i organizacja jest do tego przygotowana (to ostatnie to osobna historia może niedługo poświęcimy jej osobny post).
Właściwie obowiązek stworzenia architektury zarządzania informacją możemy wywnioskować z samego rozporządzenia. Jednym z filarów GDPR/RODO, jest zasada przejrzystości w stosunku do osób fizycznych, których dane osobowe są przetwarzane. Przejrzystość przejawia się w wielu obowiązkach związanych z przetwarzaniem danych osobowych. Przede wszystkim w następujących:
Zasadzie ochrony prywatności by design. Zgodnie z zasadą ochrony prywatności by design (tzw. zasada prywatności „w fazie projektowania”) administrator już na etapie projektowania danego rozwiązania związanego z przetwarzaniem danych osobowych ma uwzględnić stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych.
Zasada ochrony prywatności by default. Zasada ochrony prywatności by default obliguje z kolei administratora, aby środki techniczne zapewniały, iż domyślnie przetwarzane będą tylko te dane osobowe, które są niezbędne dla osiągnięcia konkretnego celu przetwarzania, odnosząc to także do ilości zbieranych danych, zakresu ich przetwarzania, okresu i ich przechowywania, jak i dostępności.
I wreszcie
Prawo do bycia zapomnianym (usunięcie danych) RODO gwarantuje każdej osobie fizycznej prawo do „bycia zapomnianym”, czyli do tego, by dane osobowe zostały usunięte i przestały być przetwarzane. Jak bez uporządkowania danych niestrukturalnych możemy zrealizować ostatnie wymaganie?
Uzyskanie zgodności z GDPR/RODO powinno się opierać na gruntownym zrozumieniu dostępu i zarządzania danymi osobowymi. Rozwinięciem tego tematu jest architektura informacji korporacyjnej z idącą za nią wspierającą i przemyślanie skonfigurowaną technologią.
Nie każdy system dostarcza narzędzi potrzebnych do tego rodzaju wszechstronnego podejścia, dlatego ten krótki artykuł ma być wstępem do opisania projektów Data Governance. Pewnie pochylimy się nad tematem w jednej obszernej Kampanii.
Na razie krótkie pytanie/spostrzeżenie – Odpowiedzmy sobie na nie cicho, niech tylko nasze sumienie słucha.
Chyba można było z projektów RODO wycisnąć więcej?