Gdzie znajdę materiały na temat bezpieczeństwa informacji?

W Internecie można znaleźć mnóstwo materiałów na temat bezpieczeństwa informacji i normy ISO 27001. Jak dla mnie jest to wręcz klęska urodzaju – materiałów jest tak dużo, że można stracić tygodnie na poszukiwaniu czegoś wartościowego i oryginalnego. Na kolejnych stronach powielane są te same informacje, a opanowane przez pozycjonerów Google nie pomagają nam w jakiś szczególny sposób wyszukać użytecznych informacji.

Moim, subiektywnym zdaniem warto zaglądać na strony:

 

Dostęp do komputerów dla stażystów i praktykantów – czy muszą posiadać upoważnienia?

Zgodnie z ustawą, dane mogą przetwarzać jedynie osoby posiadające imienne upoważnienie .

Ustawa o ochronie danych osobowych, nie zajmuje się tym, czy osoba przetwarzająca dane jest pracownikiem etatowym, stażystą, czy też pracownikiem świadczącym dla nas usługi w ramach innej umowy. Ustawa mówi, że osoba ta musi posiadać upoważnienie, a rozporządzenie precyzuje, że należy również nadawać uprawnienia w systemie informatycznym (oczywiście tylko w wypadku gdy osoba przetwarzająca dane z niego korzysta).

Wiadomo, że ze stażystami sprawa nie jest taka prosta. Najczęstsze problemy:

  • Stażysta nie jest naszym pracownikiem. Jak pisałem powyżej, nie ma to znaczenia – musi posiadać analogiczne uprawnienia jak „zwykli” pracownicy.
  • Stażysta nie ponosi pełnej odpowiedzialności. Problem leży nie w tym, czy należy dla niego stworzyć identyfikator w systemie, ale czy w ogóle dopuścić go do pracy w systemie. Jeżeli Zarząd podejmuje decyzję, że stażyści mogą pracować w systemie, to bezwzględnie należy dla nich utworzyć konta użytkowników.

Zagadnienia związane z zatrudnianiem stażystów, praktykantów i innych osób, które nie są naszymi etatowymi pracownikami, bardzo często sprawiają dużo problemu Administratorom. Uważam, że rozwiązanie jest tu tylko jedno – nie należy dla tych osób stwarzać wyjątków, traktujemy ich tak jakby byli naszymi pracownikami.

Oczywiście w wypadku dużej rotacji pracowników, konieczność ciągłego tworzenia kont w systemie może się spotkać z pewnym oporem ze strony administratorów systemów. Można pomyśleć o zatrudnieniu dodatkowych administratorów, zakupie oprogramowania ułatwiającego tworzenie kont, ale nie wolno zrezygnować z tworzenia osobnego konta dla każdej osoby mającej dostęp do systemu.

Czy dane z Płatnika podlegają rejestracji u GIODO?

Czyje dane będą w zbiorze?

  • pracowników – zbiorów danych przetwarzanych w celach związanych z zatrudnieniem własnych pracowników nie zgłaszamy.
  • przetwarzasz dane na zlecenie (biuro podatkowe, itp.) – to jest powierzenie danych do przetworzenia (art.31 UODO). Zgłoszenie jest problemem administratora danych. Powiernik jedynie podpisuje umowę.
  • innych osób, na podstawie odrębnych ustaw (np. podopieczni Ośrodka Pomocy Społecznej)–prawdopodobnie zbiór jest już zgłoszony, tzn. istotna jest podstawa prawna na podstawie której przetwarzamy dane. Jeżeli te same dane przetwarzamy przez dwie aplikacje, to nie musimy zgłaszać ich dwukrotnie (na tej samej zasadzie nie zgłaszamy danych przechowywanych w aktach papierowych, jako innego zbioru w stosunku do tych samych danych przetwarzanych w systemie komputerowym) – ale uwzględniamy te systemy w części E zgłoszenia.

Co z bazami danych osób, którzy biorą udział w programach lojalnościowych, bo wówczas apteka przekazuje dane osobowe hurtowniom? Co prawda znawcy przedmiotu mówią, że apteka nalicza tylko punkty na kartach klientów, ale nie wie jaka osoba się pod nią kryje. Z tego co wiem jednak większość aptek tworzy bazę osobową, z której nie musi korzystać przy obsłudze programu lojalnościowego, ale ją przecież ma i pytanie czy może ją mieć? Czy własny program lojalnościowy (wewnątrz apteki jest dozwolony), a ten łączący wiele aptek i hurtownie już nie? Istnieje przekonanie, że legalne pozostają wszystkie programy lojalnościowe i akcje marketingowe w których apteka reklamuje samą siebie (ale nie wolno jej reklamować np leku).

Ustawa dopuszcza oczywiście możliwość przekazywania danych pomiędzy administratorami danych. Może się to odbywać na zasadzie udostępnienia lub powierzenia danych do przetwarzania.

W wypadku wszelkiego rodzaju programów lojalnościowych, naturalne wydaje się oparcie o instytucję powierzenia danych do przetworzenia (art. 31 uodo). Możemy mieć do czynienia z sytuacją, gdy administratorem danych osobowych przetwarzanych w celach marketingowych nie będzie apteka, a organizator akcji promocyjnej i to na nim będzie spoczywał obowiązek rejestracji zbioru danych. Przykładowo, apteka zbierając dane klientów i ich zgody na przetwarzanie danych osobowych, będzie występować w imieniu organizatora z którym podpisze umowę powierzenia danych. W takiej sytuacji, apteka nie zgłasza zbioru i nie jest jego administratorem. Nie zwalnia to jednak apteki z dopełnienia innych obowiązków: zabezpieczenia danych, wystawiania upoważnień, itd.

Apteka przetwarza wówczas dane nie będąc ich administratorem, a szczegółowe obowiązki z tym związane, zapisuje się zwykle w umowie. Po zakończeniu obowiązywania umowy, wszystkie kopie danych, muszą zostać zniszczone lub zwrócone administratorowi danych (organizatorowi akcji promocyjnej, programu lojalnościowego, itp).

Należy jeszcze zwrócić uwagę na wszelkie informacje handlowe wysyłane drogą elektroniczną (np. wiadomość e-mail, strona internetowa po zalogowaniu się osoby).  Osoba do której kierujemy takie informacje, musi najpierw wyrazić zgodę na ich otrzymywanie i nie jest to ta sama zgoda co zgoda na przetwarzanie danych osobowych. Szczegóły określa ustawa o świadczeniu usług drogą elektroniczną.

Ustawa o ochronie danych osobowych nakłada na przedsiębiorców szereg obowiązków i ograniczeń. Nie oznacza to, że prowadzący aptekę musi znać wszystkie niuanse ustawy – na rynku jest coraz więcej firm i osób specjalizujących się w ochronie danych, którym można zlecić te zadania.

Czy zgodnie z obowiązującym prawem, apteka musi rejestrować bazę danych osobowych w GIODO? Są to co prawda dane wrażliwe, jednak z drugiej strony – z tego co wiem – bazy danych z pacjentami w ochronie zdrowia zwolnione są z takiego wymogu, a więc także dotyczy to aptek. Z trzeciej strony baza taka służyć ma obsłudze pacjentów np. wydawaniu leków na receptę, ale już wykorzystywanie jej do innych celów np. wysyłki kartek okolicznościowych nie służy „statutowym” działaniom apteki, a więc czy ta sama baza raz musi być rejestrowana w GIODO a raz nie musi. Z czwartej strony oczywiście większość pacjentów nie zgodzi się, żeby bazę służącą wydawaniu recept wykorzystywać do celów marketingowych, a więc w zasadzie powinna powstać druga baza tylko z tymi osobami, które się zgodzą, rozumiem, że wówczas taką „podbazę” trzeba zgłaszać do GIODO. Z piątej strony, o ile znam GIF, to nie zgodzi się na tworzenie takich baz do potrzeb marketingowych, bo apteki nie są po to, aby prowadzić działalność reklamową (nawet samoreklamową). Rozumiem, że takie same ograniczenia towarzyszą wysyłce elektronicznej?

Ustawa o ochronie danych osobowych nakłada na przetwarzających te dane szereg obowiązków. Nie udam się ich dopełnić, jeżeli nie zapoznamy się z podstawowymi pojęciami wprowadzonymi w ustawie.

Nie stworzymy wymaganych dokumentów, takich jak: polityka bezpieczeństwa, instrukcja zarządzania systemem informatycznym i nie przygotujemy zgłoszenia zbioru, jeżeli nie będziemy prawidłowo rozumieć terminów: dane osobowe, zbiór danych, administrator danych, itd.

Już samo pojęcie zbioru danych osobowych stwarza pewne problemy i jest często mylone z bazą danych. Baza danych to nie jest to samo co zbiór danych osobowych!

Należy wyraźnie odróżnić zbiór danych, od jego fizycznej reprezentacji w bazie danych programu w którym dane przetwarzamy. Ten sam zbiór może być przetwarzany jednocześnie w kilku bazach (lub programach) a nawet w formie akt papierowych. W jednej bazie danych programu komputerowego możemy również przetwarzać kilka zbiorów danych. Co więcej, ta sama informacja, może jednocześnie należeć do różnych zbiorów danych osobowych.

Najlepiej zapomnieć na chwilę o programach komputerowych, bazach danych i zastanowić się jakie dane, w jakim celu i w oparciu o jaką przesłankę uchylającą zakaz przetwarzania (art.23 ust.1 ustawy o ochronie danych osobowych), będą u nas przetwarzane. Przykładowo, możemy stwierdzić, że przetwarzamy dane osobowe w pięciu zbiorach:

–       Dane pracowników – art.23 ust.1 pkt 2-  „jest to niezbędne dla zrealizowania uprawnienia lub spełnienia obowiązku wynikającego z przepisu prawa. Zbiór zwolniony z rejestracji.

–       Dane przetwarzane w związku z realizacją recepty  – art.23 ust.1 pkt 2- „jest to niezbędne dla zrealizowania uprawnienia lub spełnienia obowiązku wynikającego z przepisu prawa. Zbiór zwolniony z rejestracji.

–       Dane przetwarzane w celu wystawienia faktury – art.23 ust.1 pkt 2- „jest to niezbędne dla zrealizowania uprawnienia lub spełnienia obowiązku wynikającego z przepisu prawa. Zbiór zwolniony z rejestracji.

–       Dane przetwarzane w celach marketingowych – art.23 ust.1 pkt 1- „osoba, której dane dotyczą, wyrazi na to zgodę, chyba że chodzi o usunięcie dotyczących jej danych. Zbiór zgłaszamy.

–       Dane przetwarzane w celu dostawy towaru do klienta – art.23 ust.1 pkt 3- „jest to konieczne do realizacji umowy, gdy osoba, której dane dotyczą, jest jej stroną lub gdy jest to niezbędne do podjęcia działań przed zawarciem umowy na żądanie osoby, której dane dotyczą. Zbiór zgłaszamy.

To w ilu i jakich programach i bazach danych są przetwarzane dane z tych zbiorów, nie jest dla identyfikacji zbiorów istotne. Informację o tym będziemy musieli jednak później umieścić w naszej polityce bezpieczeństwa.

Zbiory danych związane z realizacją recept nie podlegają rejestracji. Podobnie, nie podlegają jej zbiory danych tworzone wyłącznie w celu wystawienia faktury, zbiory danych przetwarzanych w związku z zatrudnieniem, itd.

Podkreślmy, że ewentualnej rejestracji podlega zbiór danych (nie „dane”, nie „baza danych”). Dlatego nie możemy twierdzić, że ta sama baza danych raz musi być zgłaszana a raz nie musi, gdyż zgłaszany jest zbiór danych osobowych. Nawet jeżeli, dla ułatwienia, dane są wprowadzane do systemu tylko jeden raz, to mogą być przetwarzane w różnych zbiorach, np. różniących się celem przetwarzania.

To, że zbiór danych osobowych jest zwolniony z rejestracji, nie oznacza, że do przetwarzania danych w tym zbiorze nie znajdują zastosowania przepisy ustawy, a administrator danych jest zwolniony z pozostałych spoczywających na nim obowiązków. W szczególności administrator musi opracować politykę bezpieczeństwa, instrukcję zarządzania systemem informatycznym, dopełnić obowiązku zabezpieczenia danych, prowadzenia dokumentacji, wydawania upoważnień, itd.

10 niezmiennych reguł bezpieczeństwa

W 2000 roku Scott Culp z Microsoft Security Response Center opublikował „10 niezmiennych reguł bezpieczeństwa”. Czy pomimo upływających lat są one nadal obowiązujące? Oceńcie sami.
W tym samym roku opublikowano „10 niezmiennych reguł administratora bezpieczeństwa”. Na pewno warto się z nimi zapoznać i pamiętać o nich w codziennej pracy.

10 niezmiennych reguł bezpieczeństwa:

1-Jeżeli zły facet może Cię zmusić do zainstalowania jego programu na Twoim komputerze, to nie jest już Twój komputer.

Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore.

2-Jeżeli zły facet może zmodyfikować system operacyjny na Twoim komputerze, to nie jest już Twój komputer.

Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore

3-Jeżeli zły facet ma nieograniczony dostęp fizyczny do Twojego komputera, to nie jest już Twój komputer.

Law #3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore

4-Jeżeli dopuścisz, by zły facet umieścił program na Twojej stronie internetowej, to nie jest już Twoja Stronia.

Law #4: If you allow a bad guy to upload programs to your website, it’s not your website any more

5-Słabe hasła niwelują silne zabezpieczenia

Law #5: Weak passwords trump strong security

6-Komputer jest tylko na tyle bezpieczny, na ile administrator jest godny zaufania.

Law #6: A computer is only as secure as the administrator is trustworthy

7-Zaszyfrowane dane są jedynie tak bezpieczne, jak bezpieczny jest klucz deszyfrujący.

Law #7: Encrypted data is only as secure as the decryption key

8-Używanie nieaktualizowanego oprogramowania antywirusowego jest tylko nieznacznie lepsze niż nieużywanie takiego oprogramowania.

Law #8: An out of date virus scanner is only marginally better than no virus scanner at all

9-Całkowita anonimowość jest niepraktyczna, zarówno w życiu jaki i w Internecie.

Law #9: Absolute anonymity isn’t practical, in real life or on the Web

10-Technologia nie stanowi panaceum.

Law #10: Technology is not a panacea

Oryginalny, pełny tekst pod adresem:
http://technet.microsoft.com/pl-pl/library/cc722487%28en-us%29.aspx

10 niezmiennych reguł administratora bezpieczeństwa:

1-Nikt nie wierzy, że to właśnie jemu przydarzy się coś złego, dopóki to się nie stanie.

Law #1: Nobody believes anything bad can happen to them, until it does

2-Bezpieczeństwo funkcjonuje tylko wtedy, gdy “bezpieczny sposób” oznacza również “łatwy sposób”.

Law #2: Security only works if the secure way also happens to be the easy way

3-Jeżeli nie instalujesz na bieżąco poprawek bezpieczeństwa, Twoja sieć już niedługo przestanie należeć do Ciebie.

Law #3: If you don’t keep up with security fixes, your network won’t be yours for long

4-Na niewiele zda się instalowanie poprawek bezpieczeństwa na komputerze, który nie był zabezpieczony od początku.

Law #4: It doesn’t do much good to install security fixes on a computer that was never secured to begin with

5-Nieustanna czujność jest ceną bezpieczeństwa.

Law #5: Eternal vigilance is the price of security

6-Naprawdę istnieje ktoś, kto próbuje odgadnąć Twoje hasła.

Law #6: There really is someone out there trying to guess your passwords

7-Najbardziej bezpieczna sieć, to dobrze administrowana sieć.

Law #7: The most secure network is a well-administered one

8-Stopień trudności obrony sieci jest wprost proporcjonalna do jej złożoności.

Law #8: The difficulty of defending a network is directly proportional to its complexity

9-W bezpieczeństwie nie chodzi o unikanie ryzyka, a o zarządzanie ryzykiem.

Law #9: Security isn’t about risk avoidance; it’s about risk management

10-Technologia nie stanowi panaceum.

Law #10: Technology is not a panacea

Oryginalny, pełny tekst pod adresem:

http://technet.microsoft.com/en-us/library/cc722488.aspx