Page 14 - ITReseller_kwiecien-2017

» TEMAT NUMERU | SERWERY
Analiza ryzyka z myślą
o ochronie danych
Z Pawłem Korcem, dyrektorem wsparcia sprzedaży w Europie Wschodniej w firmie VMware, rozmawia Mieczysław T. Starkowski
W maju 2016 r. wchodzi w życie unij- ne rozporządzenie o ochronie da- nych osobowych. Stawia ono przed- siębiorstwom wiele ostrych wyma- gań. W razie ich niespełnienia grożą poważne kary. W jaki sposób VMwa- re chce tu pomagać?
– Mamy trzynaście miesięcy na przy- gotowanie się do nowej sytuacji. Zasta- nówmy się, co można zrobić, by 25 ma- ja 2018 r. nie być zaskoczonym. Mam zatem sugestię dla właścicieli i zarzą- dów rm: trzeba sporządzić raport na ten temat. Oczywiście nie chodzi o to, żeby po prostu opracować jakiś doku- ment. Należy już teraz podjąć określo- ne prace w przedsiębiorstwie.
Później, gdy do siedziby przyjdzie in- spektor ochrony danych osobowych, można będzie powiedzieć, że zostały wyznaczone odpowiednie osoby zaj- mujące się tą problematyką, rozpoczę- ły się rozmowy z prawnikami, a system teleinformatyczny traktowany jest wie- lowymiarowo.
Co pan przez to rozumie?
– VMware patrzy na systemy teleinfor- matyczne wielowymiarowo. Dlatego przygotowała dla klientów tzw. anali- zę ryzyka infrastruktury. Ona jest wielo- wymiarowa i składa się z czterech czę- ści. Pierwsza to ocena bezpieczeństwa ruchu wewnątrz rmy i pomiędzy data centers (Data Application Security). To jest szalenie istotne. Ewentualne wła- manie do data center może spowodo- wać duże szkody. Dlatego my wpro- wadziliśmy tak zwaną granulację. Pole- ga ona na tym, że nawet jeśli ktoś się włamie do data center, to będzie miał utrudnione zadanie, bo każdy system operacyjny, każda baza danych, każdy serwer aplikacyjny jest traktowany od- dzielnie.
Drugi, równie istotny aspekt to zaadre- sowanie obszarów Identity and Access Management. Budujemy algorytm, a potem analizujemy ryzyko z punk- tu widzenia zarządzania dostępem do zasobów – kto i na jakich zasadach ma dostęp. W tym przypadku mówimy nie tylko o użytkownikach końcowych, ale o wszystkich pracownikach rmy oraz o tym, w jaki sposób mają oni dostęp do informacji.
Kolejna sprawa to ocena ryzyka (wszel- kiego rodzaju), np. kiedy ostatnio była prowadzona ocena ryzyka. Czy wiado- mo, kto, z kim i jakie dane wymieniał. Bo przecież te dane są często przekazy- wane innym rmom, np. gdy zewnętrz- ny podmiot przeprowadza test wydaj- ności systemu. Warto wtedy pomyśleć, żeby z de nicji mieć zagwarantowany sposób maskowania tych danych, za- nim zostaną one wyprowadzone na ze- wnątrz. I musi być ono na tyle efektyw- ne, żeby nikt nie mógł zarzucić, że te in- formacje można zinterpretować i sko- jarzyć z konkretną osobą.
Inny przykład: weźmy pod uwagę in- formacje z liczników. Wiadomo, że są one anonimowe. Ale gdzieś jest zawar- ta też informacja o kodzie pocztowym klienta. A w innym miejscu może być jego imię. Okazuje się, iż mając niewie- le danych, za pomocą analizy Big Da- ta można z dużą dokładnością określić, gdzie te dane są zlokalizowane. I wte- dy ktoś może nam zarzucić, że utraci- liśmy jego dane. Jeśli przyjdzie inspek- tor z gotowym raportem, przedsiębior- stwo musi wykazać, że miało zrobioną analizę ryzyka.
Ostatni element analizy, jaką propo- nujemy klientom, to monitoring in- frastruktury, polegający na ciągłym przeglądaniu polityk bezpieczeństwa. W zasadzie to nie jest nic nowego. Chodzi o przygotowany formularz do sprawdzenia, czy w przypadku ochro- ny danych osobowych nie zapomni się o czymś, gdy nastąpi przebudowa, modernizacja albo inna zmiana w da- ta center.
Czy można zaobserwować atak na data center?
– Oczywiście. Są mechanizmy potwier- dzające, że nastąpił atak. Są też przy- gotowane procedury awaryjne pod- powiadające, jak postępować w ta- kiej sytuacji. Taką procedurą awaryjną może być całkowite odłączenie syste- mu. Spowoduje to mniejsze szkody niż utrzymywanie systemu, z którego wy- ciekają dane, przy czym nie wiemy, jak długo, w jakim tempie itd. To są bardzo skomplikowane zjawiska i właśnie dla- tego trzeba na nie patrzeć wielowy- miarowo. w
14 iT Reseller nr 5–6 (303–304) • kwiecień 2017