Privacy by Design okiem architekta

Data: 2018-05-08
Autor: Sebastian Konkol
Privacy by Design okiem architekta

Zaznajomieni z tematem RODO / GDPR wiedzą, że jednym z wymogów formalnych wprowadzanych przez tę legislację jest obowiązek stosowania privacy by design i privacy by default. Legislacja nie określa jednak, czym są te terminy. Rzecz jasna, Internet oferuje wiele stron odnoszących się do tych terminów, ale na pytanie „to co mam konkretnie zrobić?” bezpośredniej odpowiedzi raczej brak. Ja potrzebowałem takich odpowiedzi. Jak więc podejść do privacy by design z perspektywy architektury?

Perspektywa bezpieczeństwa w architekturze – Enterprise i Solution – to niełatwa sprawa. Sfera wiedzy o bezpieczeństwie jest dość hermetyczna – na tyle hermetyczna, że nie integruje się dobrze z architekturą. Rzecz jasna każdy architekt wie, że identyfikacja to coś innego niż uwierzytelnienie i jeszcze coś innego niż autoryzacja. Tym niemniej, architekci z rzadka zagłębiają się w zagadnienia bezpieczeństwa dostępu do informacji na tyle, żeby uchwycić ich powtarzalność. Z powtarzalności aplikowania perspektywy bezpieczeństwa wynikają wzorce architektoniczne – na przykład takie, jakie potrzebne są dla realizacji privacy by design. O jednym z takich wzorców, Chińskich Murach, pisałem kilka lat temu.

Zasada privacy by design zobowiązuje do wbudowywania zabezpieczeń danych osobowych już na wczesnym etapie konstrukcji systemu. To właśnie jedno z zadań architektury – wskazać uwarunkowania i ograniczenia konstrukcji rozwiązania, które nie mogą być zmieniane, podlegać kompromisom lub interpretacjom. W sferze privacy by design istnieje lista zagadnień, jakie architekt powinien przemyśleć. Obejmują one szeroki wachlarz tematów, od wprowadzania i organizacji danych, przez audyt ich wykorzystania i weryfikacji uprawnień, po identyfikację sytuacji złamania obowiązujących reguł i komunikacji z użytkownikami o dostępie do danych osobowych. Dla obsługi takich sytuacji istnieje kilkadziesiąt wzorców architektury – jedne proste, inne wyrafinowane – gotowe do zastosowania w architekturze rozwiązań. Efektem stosowania tych wzorców mogą być – w uzupełnieniu do oczywistego wymuszania zabezpieczeń –  zapewnienie anonimowości, separowanie danych, sprawowanie nadzoru nad przetwarzaniem danych, identyfikowanie sytuacji wymagających działań, zdolność do dowodzenia stosowania zabezpieczeń. Co więcej, wzorce te mogą być dobrze osadzone w kontekście strategii rozwoju architektury rozwiązania – strategii odnoszących się wprost do realizacji wymagań legislacyjnych zapisanych w RODO / GDPR.

Sama legislacja RODO / GDPR tworzona była przez kilka lat i – co należy podkreślić – oparła się o prace dziedzinowe i solidne podstawy merytoryczne. Nie jest to zbiór przepisów, ale materiał osadzony w normach i pracach specjalistów zagadnień bezpieczeństwa informacji. Rozważając praktyczne aspekty wdrożenia zmian wynikających z RODO / GDPR można się oprzeć choćby o normy, np. ISO/IEC 29100, choćby w zakresie pryncypiów zabezpieczeń informacji danych osobowych.

W praktycznych sytuacjach, kiedy do głosu dochodzą (i mają „swoje 5 minut”!) takie funkcje jak bezpieczeństwo informacji, ujawniają się tendencje do przegięcia w drugą stronę – jeśli dotąd można było wszystko, to „w związku z RODO” nie będzie można już nic. Prawda jest taka, że większość reguł działania organizacji wcale nie jest opisana procesami – zdecydowana większość opiera się na praktyce wypracowanej w trakcie działania. Część „w trakcie działania” zasadza się na tym, do jakich danych można mieć dostęp. Poza więc oczywistą szkodliwością przegięcia, takie podejście „zabrońmy wszystkiego” może mieć paraliżujący wpływ na działalność firmy. Tym niemniej, RODO / GDPR przerzuca na firmę ocenę ryzyka wycieku danych osobowych – ryzyka wycenianego wartością monetarną. Ograniczać więc trzeba, ale w sposób rozsądny. W bardzo niewielu przypadkach leczenie wstrząsowe prowadzi do pozytywnych skutków – w praktyce wdrażania privacy by design zalecałbym pełzające wdrożenia, choć podstawą dla podejmowania decyzji o docelowych rozwiązaniach powinno być bezwzględne stosowanie polityki need to know. W redukcji ryzyka pomaga także retrospekcja w ujęciu „a gdyby to były moje dane?”

Stosowanie wzorców i perspektyw architektonicznych w konstrukcji rozwiązań pozwala na nie tylko na operacjonalizację RODO / GDPR w ramach własnych działań, ale także – a może przede wszystkim – nakłada siatkę pojęciową oceny rozwiązań zewnętrznych i „chmurowych” w obszarze zgodności z RODO / GDPR. Świadome organizacje zaczęły już prace w taki sposób, duża część dopiero teraz „się budzi”. Świadomość przyjdzie nagle wraz z pierwszymi wyrokami sądowymi za brak stosowania tych przepisów.

Pozostaw komentarz