Ochrona danych osobowych w systemach ERP

Mówiąc o ochronie danych w systemach informatycznych często mamy na myśli ochronę danych osobowych, o której wiele się mówi i która jest regulowana ustawowo oraz rozporządzeniem Ministra Spraw Wewnętrznych i Administracji. W istocie zagadnienie ochrony danych jest jednak dużo szersze i w przypadku systemów ERP dotyczy także innych obszarów. Żadna firma nie chce wycieku informacji finansowych, kartoteki poddostawców czy danych technologicznych. Warto więc przyjrzeć się jak nasze systemy są zabezpieczone, bo nie wszyscy dostawcy ERP przykładają do tego dostateczną wagę; wiele także zależy od wewnętrznej polityki firmy korzystającej z systemu i przyjętych w niej procedur.

DANE OSOBOWE NAJWAŻNIEJSZE

Na początek zastanówmy się jak chronimy właśnie dane osobowe. Mają one priorytet, gdyż obowiązek ten wynika z prawa, a poza tym lista wymogów jest w miarę dobrze w przepisach określona. Nikt też z pewnością nie zamierza narażać się pracownikom Biura Generalnego Inspektora Ochrony Danych Osobowych, który dowolnego dnia może zapukać do naszych drzwi w celu „przeprowadzenia niezbędnych badań lub innych czynności kontrolnych”.

WARTO PRZY TYM ZWRÓCIĆ UWAGĘ, ŻE PRZEPISY ZOBOWIĄZUJĄ DO ZAPEWNIENIA ODPOWIEDNIEGO POZIOMU BEZPIECZEŃSTWA DANYCH OSOBOWYCH FIRMĘ LUB INSTYTUCJĘ KORZYSTAJĄCĄ Z SYSTEMU A NIE DOSTAWCĘ OPROGRAMOWANIA.

A więc firma we własnym interesie powinna przenieść wymogi wynikające z prawa na producenta systemu żądając od niego spełnienia określonych wymagań i ewentualnie zabezpieczając się odpowiednio skonstruowaną umową. Oczywiście nie wszystkie punkty ustawy oraz rozporządzenia dotyczą systemu sensu stricte, część z nich jest sprawą wewnętrzną firmy (np. procedury dot. przechowywania zapasowych kopii danych).

ODPOWIEDZIALNOŚĆ KARNA

W razie stwierdzenia uchybień Generalny Inspektor może w najłagodniejszym przypadku np. zażądać usunięcia uchybień lub zastosowania dodatkowych zabezpieczeń a w najczarniejszym – skierować do organów ścigania zawiadomienie o popełnieniu przestępstwa. Wówczas może nam grozić grzywna, kara ograniczenia wolności lub pozbawienia wolności do roku (w razie np. niedostatecznych zabezpieczeń) lub do lat 2 (w razie nieuprawnionego przetwarzania) albo do lat 3 (jeżeli miałoby to dotyczyć danych ujawniających np. pochodzenie rasowe, przekonania religijne, dane o życiu seksualnym, przynależność związkową lub dane o stanie zdrowia). Łatwo zauważyć, że w dwu ostatnich przypadkach (przynależność związkowa, dane o stanie zdrowia) takie informacje mogą znajdować się w systemie ERP (w postaci np. odliczeń na składki związkowe, wyników badań okresowych lub zwolnień lekarskich).

PRZEPISY W NAJWIĘKSZEJ MIERZE DOTYCZĄ ADMINISTRATORA DANYCH I TO ON POWINIEN BYĆ NAJBARDZIEJ ŚWIADOMY ODPOWIEDZIALNOŚCI PRAWNEJ, JAKA NA NIM SPOCZYWA. WYMOGI ROZPORZĄDZENIA

Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych opisuje szereg wymogów, z których część dotyczy systemu informatycznego. Systemy takie powinny:

• Automatycznie odnotowywać datę pierwszego wprowadzenia danych osobowych do systemu oraz identyfikator osoby je wprowadzającej w momencie zatwierdzania przez użytkownika operacji bazodanowej.
  
  
• Ewidencjonować źródła pochodzenia danych osobowych jeśli nie pochodzą one bezpośrednio od osoby, której one dotyczą. W systemach ERP może to np. dotyczyć obciążeń komorniczych.
  
  
• Umożliwiać ewidencję odbiorców, którym dane osobowe zostały udostępnione, dat i zakresów tego udostępnienia.
  
  
• Umożliwiać odnotowanie sprzeciwu dot. przetwarzania danych w celach marketingowych lub udostępniania danych na zewnątrz.
  
  
• Posiadać wbudowane mechanizmy kontroli dostępu do danych.
  
  
• Umożliwiać zarejestrowanie dla każdego użytkownika osobnego identyfikatora.
  
  
• Zapewniać dostęp do danych wyłącznie po wprowadzeniu identyfikatora i poprawnego hasła (chyba że zastosowano inną metodę identyfikacji).
  
  
• Być zabezpieczone przed utratą danych spowodowaną awarią zasilania lub zakłóceniami w sieci zasilającej.
  
  
• Umożliwiać nałożenie na użytkowników wymogów zmiany hasła co określoną ilość dni oraz dot. minimalnej długości i złożoności hasła. (Administrator powinien tak sparametryzować system, by użytkownicy zmieniali hasła nie rzadziej, niż co 30 dni oraz by każde hasło musiało składać się ono co najmniej z 8 znaków, zawierać małe i wielkie litery oraz cyfry lub znaki specjalne.)
  
  
• Umożliwiać przygotowanie kopii bazy danych.
  
  
• Odpowiednio zabezpieczać dane, które są przesyłane w sieci publicznej.

SPEŁNIAJĄC WYMOGI ROZPORZĄDZENIA OSIĄGNIEMY PODWÓJNĄ KORZYŚĆ: NIE TYLKO BĘDZIEMY W ZGODZIE Z PRAWEM, ALE WSZYSTKIE DANE NASZEGO SYSTEMU (NIE TYLKO OSOBOWE) BĘDĄ DUŻO BEZPIECZNIEJSZE. WYMOGI WEWNĘTRZNE

Niezależnie od powyższych punktów, aby w pełni spełnić wymogi rozporządzenia administrator we własnym zakresie powinien opracować odpowiednią dokumentację, na którą składają się polityka bezpieczeństwa i instrukcja zarządzania systemem informatycznym. Będą one zawierać m.in. wykaz budynków i pomieszczeń, w których przetwarzane są dane osobowe, procedury tworzenia kopii zapasowych, sposób przechowywania kopii zapasowych itp.

Dodatkowo jeśli system ERP „niedomaga” administrator powinien podjąć działania mające na celu spełnienie wymogów rozporządzenia. Przykładowo: jeśli system nie umożliwia ewidencji odbiorców, którym dane osobowe zostały udostępnione, to należy stworzyć taką ewidencję poza nim.

LUKI W SYSTEMACH

Ustawodawca poprzez szczegółowe wymogi starał się wysoko umieścić poprzeczkę dla systemów informatycznych. Jednak nie wszystko można przewidzieć, a pomysłowość złodziei danych jest duża. Faktycznie nawet spełniając skrupulatnie wymogi rozporządzenia nadal może pozostać wiele obszarów niezabezpieczonych lub słabych zabezpieczeń, które doświadczony hacker mógłby pokonać. Postarajmy się przyjrzeć kilu możliwym lukom:

• Dostęp z poziomu konsoli programu może inaczej wyglądać, niż „od spodu”. Zwykle nowoczesne systemy umożliwiają wieloraki dostęp do danych poprzez liczne interfejsy, np. ODBC, Web Services. Warto sprawdzić, czy uprawnienia dot. ograniczenia dostępu dla do części danych z poziomu tych interfejsów są takie same, jak z poziomu konsoli programu.
  
  
• Dane mogą być zapisywane na bazie lub lokalnie tymczasowo przechowywane w cache w postaci niezaszyfrowanej lub słabo zaszyfrowanej umożliwiającej złamanie szyfru.
  
  
• Hasło dostępu dla użytkownika może być lokalnie zapisywane w postaci niezaszyfrowanej.
  
  
• Użytkownik, który ma ograniczony dostęp do danych może dotrzeć do nich w inny sposób: np. nie widzi kartoteki kontrahentów, ale może dotrzeć do informacji o nich na podstawie faktur.
  
  
• Użytkownik ma ograniczony przez administratora dostęp do pewnych danych poprzez nie udostępnienie dla niego części formularzy, ale może dotrzeć do danych „od spodu” lub poprzez takie miejsca w programie, gdzie może elastycznie definiować nowe pola, formularze lub wydruki.

LUKI W PROCEDURACH

A oto przykładowe luki, jakie mogą się pojawić w wewnętrznych procedurach w firmie:

• Niewłaściwe postępowanie z wydrukami zawierającymi istotne dane. Mogą być one np. rozprowadzane wśród pracowników w sposób niekontrolowany lub – gdy przestaną być potrzebne – być wyrzucane zamiast niszczenia.
  
  
• Niewłaściwe przechowywanie wydruków elektronicznych utworzonych w oparciu o dane z systemu a przechowywanych poza nim. Z sytuacją tą mamy do czynienia w firmach, w których wydruki elektroniczne (np. w formacie PDF lub RTF) są przechowywane w publicznie dostępnych lokalizacjach sieciowych.
  
  
• Niewłaściwe przechowywanie kopii danych w sposób nie gwarantujący ich przetrwania w razie np. pożaru lub w sposób umożliwiający dostęp do nich osobom postronnym.
  
  
• Zbyt wiele osób mających dostęp do systemu z uprawnieniami administratora danych. Może to dotyczyć np. firm wielodziałowych, gdzie w każdym oddziale tworzy się oddzielne stanowisko administratora. Należy pamiętać, że niezależnie od zastosowanych zabezpieczeń i ograniczeń dostępu do danych, administrator zawsze będzie mieć do nich pełny dostęp.

Literatura:

• Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r. Nr 101, poz. 926).
• Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. Nr 100 Poz. 1024)

Źródło: TETA SA
Autor: Zbigniew Lisowski - Analityk wiodący TETA SA