WARTO WIEDZIEĆ

SKRZYDEŁKO, CZY NÓŻKA…

Jacek Rembikowski, E-QSM Informatyczne Systemy Zarządzania, Poznań 2014   Konieczność radzenia sobie w świecie IT, który w żadnym z kierunków nie jest światem jednoznacznych odpowiedzi, jest naturalnym czynnikiem, zmuszającym nas do poszukiwania najbardziej optymalnych rozwiązań. Ten czynnik leży np. u podstaw odwiecznej wojny Linux’a z Windows’em.   Ale zaczynając od początku…   Potrzeba kontrolowania ruchu w sieci, a w szczególności niewłaściwych zachowań użytkowników zarówno wewnętrznych, jak i zewnętrznych, to jeden z podstawowych wymogów bezpieczeństwa.   Niestety, nie jest prawdą, że włamania mają miejsce jedynie na kierunku: sieć publiczna – sieć wewnętrzna. Także w ramach wewnętrznej sieci i wydzielonych obszarów mogą i mają miejsce nadużycia lub wręcz włamania, które są o tyle mniej przyjemne, że dzieją się na naszym podwórku, do którego chcielibyśmy mieć 100% zaufania. Tych z zewnątrz spodziewamy się w naturalny sposób. Liczymy się ze złodziejem ale nie zakładamy, że okradną nas goście, czy wręcz domownicy. Dlatego systemy wykrywania włamań, powinny być instalowane na stykach sieci, jak i podsieci.   Zacznijmy od przypadku, czyli od sytuacji gdy nie mamy nic lub prawie nic.   Dość oczywista sprawa. Ale co jeżeli na dodatek nie chcemy, nie możemy lub nie stać nas na drogie rozwiązania w pełni komercyjne, oferowane przez znanych z nazwy i opinii na rynku producentów zabezpieczeń?   Możemy skorzystać z rozwiązań klasy Open Source, co do których mamy prawo do ich użycia w trybie: na użytek własny.   Takim rozwiązaniem jest Snort, który posiada szeroki zakres mechanizmów detekcji ataków oraz umożliwia, dokonywanie analizy ruchu i rejestrowanie pakietów przechodzących przez sieci oparte na protokołach IP/TCP/UDP/ICMP. Snort potrafi przeprowadzać analizę strumieni pakietów, wyszukiwać i dopasowywać podejrzane treści, a także wykrywać wiele ataków i anomalii, (więcej na ten temat można przeczytać w Wikipedii lub pod adresem http://www.snort.org)   Co mówi licencja?   „Ten program jest wolnym oprogramowaniem; możesz go rozprowadzać dalej i/lub modyfikować na warunkach Powszechnej Licencji Publicznej GNU opublikowanej przez Free Software Foundation;(…). (…) program jest rozpowszechniany w nadziei, że będzie użyteczny, ale BEZ ŻADNEJ GWARANCJI; bez nawet domyślnej gwarancji PRZYDATNOŚCI HANDLOWEJ albo PRZYDATNOŚCI DO OKREŚLONYCH ZASTOSOWAŃ. (…)”;   tyle wolnego tłumaczenia…   Pełna treść artykułu, czyli jak podejść do kwestii wyboru rozwiązania, dostępna jest pod adresem:   http://demo.eqsm.com.pl

ZASADA NACZYŃ POŁĄCZONY, CZYLI JAK TESTOWAĆ ABY NIE ZWARIOWAĆ

Jacek Rembikowski, E-QSM Informatyczne Systemy Zarządzania, Poznań 2014   Okazuje się, że niektóre tematy stanowią dość żywy organizm, który co jakiś czas przypomina o swoim istnieniu. Jednym z nich jest np. kwestia testowania oprogramowania, kto i dlaczego powinien się tym zajmować oraz w jakich warunkach powinno się testować oprogramowanie.   Generalnie problem z tym zagadnieniem ma swoje źródło w czymś, co można nazwać procesowym kołem zamachowym, które swój początek bierze w znajomości własnego środowiska (ocena kluczowości i krytyczności elementów składowych), a koniec w ocenie ryzyka. Po drodze nie bez znaczenia pojawia się trzeci składnik układanki, jakim jest proces zarządzania zmianami i/lub rozwój oprogramowania.   „Wprowadzenie nowego systemu informatycznego, jak również znacznej zmiany do już istniejącego systemu, powinno być poprzedzone przeprowadzeniem analizy ryzyka wynikającego z zastosowanych technologii informatycznych oraz dokonaniem oceny wpływu wprowadzanych zmian na środowisko teleinformatyczne i procesy biznesowe banku, ze szczególnym uwzględnieniem aspektów bezpieczeństwa. (…)   Zarówno nowe oprogramowanie, jak i zmiany wprowadzane do już funkcjonujących rozwiązań informatycznych, powinny być testowane adekwatnie do swojej złożoności oraz wpływu na pozostałe elementy środowiska teleinformatycznego banku. Bank powinien posiadać metodologię testowania oprogramowania (...)” tyle Rekomendacja D…   Przeprowadzenie analizy ryzyka z zastosowanych technologii, na pierwszy rzut oka wydaje się być dość proste. Jeżeli jednak rzucimy tym okiem dalej może okazać się, że niekoniecznie. Powodów jest kilka. Jednym z nich jest znajomość danej technologii, jej możliwości i ograniczeń. Drugim jest znajomość (dobra) własnej infrastruktury jej potrzeb i zagrożeń, przed którymi się bronimy.   Najbardziej obrazowym przykładem jest w tym miejscu np. dobór Smart Phone’ów – jeżeli nasza infrastruktura wymaga stosowania antywirusa, to nie możemy dobrać takich urządzeń, dla których systemów nikt nie napisał jeszcze stosownego oprogramowania, bo jest to sprzeczne z zasadami przyjętymi w organizacji PBI. Ale w zakresie sprzętu to w sumie nie jest trudne. Co natomiast z oprogramowaniem?   Tu w pierwszej kolejności pojawiają się na pozór banalne elementy, takie, jak wymagania stricte użytkowe z zakresu: „do czego będę tego używał”. Inne będą wymagania do przetwarzania danych osobowych, inne - do przetwarzania informacji poufnych. Czyli już na początku powinienem umieć określić czy dany element pozwala mi zachować ten zakres bezpieczeństwa, jaki nakłada na mnie prawo i zasady użytkowania.   Kolejna kwestia to technologia – są zwolennicy starych rozwiązań – bo pewne i przetestowane, są miłośnicy nowinek. Są też tacy, co lubią środek. Każdy z nich w określonych warunkach będzie miał rację, ale…   Znam firmę, która nagle postanowiła oszczędzić na drodze obrażenia się na Microsoft i przeszła na Linuksy, także dla użytkowników. Gdyby dokonali analizy ryzyka, to stwierdziliby co następuje:   Nie mam specjalisty od Linuksa i nie wiemy co i jak się potoczy jak nam coś wysiądzie Współpracujemy z zewnętrznymi firmami a OpenOffice;y nie są w 100% kompatybilne z MS Office Itp.;   Z wnioskiem na końcu – czy to nie będzie, że zamienił Stryjek siekierkę na kijek i czy nie wygeneruje to dodatkowego kosztu?   Inny przykład – firmie zaproponowano przejście z oprogramowania instalowanego na dzierżawione. W wyniku oceny działania (stabilności) łącza władze doszły do wniosku, że ryzyko braku dostępu do systemu jest zdecydowanie większe i groźniejsze niż w razie awarii czekanie na serwis.   Każdy z tych elementów pokazuje inny zakres ryzyk i inne spojrzenie wynikające wprost z potrzeb i środowiska, w jakim funkcjonują. Bez tej wiedzy naprawdę trudno o jednoznaczną odpowiedź. Dlatego też należałoby zacząć od rzetelnego opisania zbioru ryzyk i sposobu szacowania (oceniania) nowych lub rozwijanych elementów IT.   Ale co z testowaniem?... Pełna treść artykułu dostępna jest pod adresem: http://demo.eqsm.com.pl  

NU PAGADI CZYLI, A NAM WSIO RAWNO…

Jacek Rembikowski, Bernadeta Gronowska, E-QSM Informatyczne Systemy Zarządzania, Poznań 2014   Niektórzy z nas pamiętają doskonale bajkę rodem z ZSRR. Inne bajki o podobny charakterze tu nie pasują bo ani Pixi i Dixi, ani Tom i Jerry nie prezentują tak wyrazistych postaci, jak Wilk i Zając. No, ale czasy się zmieniają. Zając, nadal jest Zającem, a Wilk? No cóż, czy ktoś zna zbroczyńcę, który nie doskonaliłby swojego warsztatu? Złodziej to prawie taki sam fach, jak inne - tyle, że prowadzony w opozycji do ogólnie przyjętych w społeczeństwie reguł. Podlega jednak temu samemu prawu, co praca wykonywana przez wszystkich z nas. Oznacza to dokładnie tyle, że również w jego przypadku mamy do czynienia z procesem ciągłego doskonalenia – prawie jak w ISO. Skoro nie mogę się dostać tędy, to spróbuję inną drogą…   Nasz Wilk, czyli haker, też podlega ewolucji. Patrząc wstecz można by powiedzieć: „Kiedyś to byli hakerzy – były jakieś zasady.  Nie to, co teraz!”. Tak naprawdę dawnego hakera można porównać do drobnego złodziejaszka, małego oszusta, a właściwie takiego chochlika, który sam wiele złego nie robił – on bardziej do złego namawiał. Dlaczego? Jeżeli haker złamał kod gry, programu itd., a plik tzw. crack zachował dla siebie, to w 100% moglibyśmy mówić o znikomej szkodliwości czynu. No, ale nasz haker chciał pokazać światu swoje osiągnięcie i taki plik umieszczał w sieci, z domyślnym hasłem: „bierzcie i grajcie na tym wszyscy”. No i klops – jeżeli gra kosztowała 100zł, a 15 tysięcy użytkowników pobrało ów plik i skorzystało z gry bez jej kupowania, to łatwo wyliczyć stratę. I tu pojawia się kłopot. Wielu producentów wychodziło bowiem z założenia, że nie będzie zbyt wiele z tym robić, bo to kosztowne, a poza tym, jeżeli kradną nasz produkt – znaczy, że jest dobry, a my już i tak jesteśmy bogaci. Przecież nie od dziś wiadomo, że gdyby prawa autorskie przestrzegano od samego początku, to Internet by się nie rozwinął. Sam Microsoft nie kwapił się aż nadto do ścigania łamiących klucze systemu Windows, ba - robił programy amnestyjne: zgłoś, że masz wersję piracką, a my tobie krzywdy nie zrobimy itd. Obecnie, dzięki temu, mamy cały przemysł gier, no i blisko 90% „zarażonych” Windowsem, którzy dziś - z uwagi na zmianę polityki - są legalni. I tak - w dużej mierze do rozprzestrzenienia się przyzwyczajeń i upodobań użytkowników do danego środowiska przyczyniła się jego dostępność. Konkludując - paradoksalnie można by powiedzieć: „nie taki Wilk straszny, bo nie ma tego złego…”   Pełna treść artykułu dostępna jest pod adresem: http://demo.eqsm.com.pl  

WYMUSZENIA, PRAWO WŁASNOŚCI DO ZBIORÓW I PROBLEMY W ZGŁASZANIU CZYLI ROZ-boje w ODO

Bernadeta Gronowska, E-QSM Informatyczne Systemy Zarządzania, Poznań 2013 Ochrona danych osobowych to temat niejednorodny i wielowątkowy, a przez to rodzący wiele wątpliwości i problemów. Trudno, aby było inaczej, skoro Ustawa o ochronie danych osobowych w wielu miejscach odsyła do zapisów ustaw sektorowych, co wymusza konieczność zgłębiania szeregu innych przepisów prawnych, które również nie są w wielu przypadkach precyzyjne, np. z powodu braku aktualizacji. A nadmiar złego, wszystko to ma lub powinno mieć swoje odzwierciedlenie np. w zapisach w umowach z klientami i kontrahentami.   „Nie myli się tylko ten, co nic nie robi” –  to stare i mądre powiedzenie zawsze mam w pamięci, gdy znajduję różnego rodzaju błędy w zapisach. Bo oczywiście nie chodzi o wytykanie błędów, a jedynie o uniknięcie ich konsekwencji, które w przypadku niewłaściwych zapisów w umowach mogą być dotkliwe.   Pierwszy przypadek, to wadliwe lub nieprecyzyjne zapisy z zakresu ochrony danych osobowych w umowach z klientami.   Artykuł 24, ust. 1 Ustawy z dnia 29.08.1997roku o ochronie danych osobowych nakłada na administratorów danych obowiązek informacyjny w stosunku do osoby, której dane przetwarza m.in. w zakresie znanych lub przewidywanych odbiorców danych. Oznacza to, że klient powinien być poinformowany komu (jakiej instytucji), jego dane będą lub mogą być przekazywane. Standardowo Banki Spółdzielcze, w związku z realizacją umów z kontrahentami i innymi instytucjami przekazują dane swoich klientów m.in. do Banku Zrzeszającego. Ponadto na podstawie art. 105 Prawa bankowego dane klienta mogą trafić do BIK S.A. i/lub Bankowego Rejestru Związku Banków Polskich, a na podstawie art. 3 Ustawy o udostępnianiu informacji gospodarczych na warunkach określonych w art. 14 tej ustawy (Dz.U.2010.81.530 z póź. zm.) – do KRD BIG S.A i/lub BIG Infomonitor S.A. Niestety  te sztandarowe instytucje nie wyczerpują najczęściej kręgu odbiorców, dlatego w każdym banku zwykle należy uwzględnić indywidualnych kontrahentów, o których klient powinien być poinformowany – w przeciwnym bowiem razie może zgłaszać pretensje do banku lub złożyć zażalenie do GIODO.   Druga kwestia związana z zapisami w umowach, to sposób ich konstrukcji. Niestety, często napotykanym błędem jest zawarcie dwóch celów przetwarzania danych w jednej zgodzie klienta. Traktowane to jest jako wymuszenie – ma to miejsce m.in. przy wyrażaniu zgody na przetwarzanie danych w celach marketingowych, przy okazji wyrażenia zgody np. na wykonanie czynności związanych ze złożonym wnioskiem kredytowym.   Część niewłaściwych zapisów w umowach z klientami bierze się często z nieprecyzyjnych zapisów w umowach z kontrahentami, dotyczących przekazywania, powierzania oraz dostępu do danych.   Zawierając umowę z kontrahentem uświadomić sobie należy jaki faktycznie jest jej zakres i co to oznacza w odniesieniu do zapisów Ustawy o ochronie danych osobowych. Wszędzie tam, gdzie ma miejsce przekazywanie danych – należy określić, czy jest to jedynie udostępnianie, czy powierzenie do przetwarzania. Różnica czasem na pierwszy rzut oka wyraźna….. ale czy zawsze? Co więcej, istotny z punktu widzenia obowiązku jest także kierunek przekazywania.   Jeżeli powierzamy dane osobowe ze swojego zbioru do przetwarzania innemu podmiotowi – konieczna jest umowa, która powinna precyzyjnie określać zakres tych danych, cel przetwarzania, odpowiedzialności stron, w tym zobowiązanie do należytego zabezpieczenia danych i spełnienia wymagań ustawy o ochronie danych osobowych i to my powinniśmy o te zapisy zadbać, gdyż to my za nie odpowiadamy.   Podobnie, gdy to nam inny podmiot powierza do przetwarzania dane ze swojego zbioru – tyle tylko, że to on powinien wówczas zadbać o spisanie umowy.   Jak łatwo o pomyłkę pokazuje praktyka. Generalnie bowiem w bankach występują obydwa przypadki kierunków powierzenia danych do przetwarzania. Niestety pozory czasem mylą i to, co wydaje się powierzeniem danych do przetwarzania na zewnątrz – jest tego dokładną odwrotnością, czyli przyjęciem danych do przetwarzania.   To powoduje, iż nagle okazuje się, że bank przetwarza dane osobowe, których nie jest właścicielem (Administratorem), co w praktyce oznacza jedynie lub aż zdjęcie obowiązku rejestracyjnego.   Przykładem takiej sytuacji może być system Dokumenty Zastrzeżone. System umożliwia osobie, która straciła dokument tożsamości zastrzec go w ogólnopolskiej bazie, co ma zapobiec posłużeniu się tym dokumentem w celu np. wyłudzenia kredytu. Co więcej wcale nie musi tego robić w macierzystym banku.   Część banków przyjmuje wnioski o zastrzeżenia dokumentów jedynie od swoich klientów i tu sprawa jest prosta. Coraz większa jednak liczba banków przystępuje do wariantu, w którym to każda osoba – nie tylko klient – może taki wniosek złożyć. Dochodzi wówczas do zbierania i przetwarzania (w ograniczonym zakresie, ale jednak przetwarzania) danych osobowych nie należących do zbioru klientów banku.   Nasuwa się tu pytanie: kto jest ich właścicielem (administratorem) i na kim spoczywa obowiązek rejestracyjny?   Administratorem danych zawartych w systemie Dokumenty Zastrzeżone jest Związek Banków Polskich. Dane te najpierw trafiają jednak do banku i tam są zbierane i przechowywane w formie papierowej, a dopiero w drugim kroku trafiają do systemu. Czy zatem bank jest też administratorem i powinien zgłosić następny zbiór danych osobowych do GIODO?   Analizując zapisy zawarte w formularzach wypełnianych przez osoby składające wniosek o zastrzeżenie dokumentów w Banku  – nasuwa się odpowiedź twierdząca:   TAK – każdy bank przyjmujący wnioski o dokonanie zastrzeżenia dokumentów od osób nie będących jego klientami jest administratorem i powinien zgłosić do GIODO kolejny zbiór danych osobowych. Co więcej Klient, osoba zgłaszający utratę dokumentów jest informowany o tym, że dane będą przekazane do bazy systemu Dokumenty Zastrzeżone, co tym bardziej tworzy obraz banku jako administratora tych danych.   Spójrzmy jednak na to inaczej – czy nie można było tego inaczej zorganizować i uchronić banki przed kolejnymi obowiązkami – nie związanymi bezpośrednio z działalnością bankową? W końcu działając we współpracy z towarzystwem ubezpieczeniowym nie rejestrujemy zbioru ubezpieczanych, prawda?   Skoro Związek Banków Polskich jest administratorem centralnej bazy systemu Dokumenty Zastrzeżone, może na drodze umowy, o której mowa powyżej, powierzyć do przetwarzania dane zawarte w swoim zbiorze w zakresie ich zbierania i przekazywania każdemu z banków przystępujących  do umowy.   Wydaje się to logiczne zarówno z punktu widzenia istnienia jednego systemu, jak i z uwagi na bardzo ograniczony zakres przetwarzania tych danych przez same banki (tylko zbieranie i przechowywanie wniosków w formie papierowej).   Problem polega jednak na tym, że wszelkie kwestie z tym związane powinny być uregulowane na poziomie zapisów w umowie ze Związkiem Banków Polskich.   Ustawa o ochronie danych osobowych nakłada szereg obowiązków, ale – czasami podsuwa rozwiązania i uproszczenia, z których warto korzystać dla ułatwienia sobie życia, a tym samym uniknięcia powielania działań, mnożenia zbiorów i zwiększania ryzyka popełnienia błędów.

DOBRODZIEJSTWO I ZAGROŻENIA SYSTEMÓW DO MONITOROWANIA SIECI, czyli seks w ODO

Jacek Rembikowski, E-QSM Informatyczne Systemy Zarządzania, Poznań 2013 Niestety jakoś tak dziwnie się wszystko na świecie układa, że każdy kij ma dwa końce. Coś, co często bywa dobrodziejstwem, z innego punktu widzenia bywa przekleństwem.    Ot, zwyczajnie – nie ma wolności absolutnej, a perpetuum mobile to jedynie marzenie.   W tej samej kategorii można, a wręcz należy postrzegać wszelkiego rodzaju zabezpieczenia – nie ma takich, które by były idealne i nie ma takich, które z jakiegoś punktu widzenia nie utrudniałyby nam życia. Jak ktoś nie wierzy, proszę poczekać na zdarzenie: „o rany, zaspałem” - wówczas denerwuje nie tylko konieczność zamknięcia drzwi na klucz, ale nawet plączący się w nieskończoność pęk kluczy.   Jednym z nieodzownych zabezpieczeń oraz narzędzi wykorzystywanych w obszarze polityki bezpieczeństwa są systemy do nadzorowania sieci. Z jednej strony dają sporo – jeżeli spojrzymy na to od strony bezpieczeństwa, z drugiej sporo zabierają, jeżeli spojrzymy od strony ergonomii. Tym razem jednak nie chodzi o rozważanie za i przeciw, a o coś zupełnie innego.   Monitorowanie infrastruktury IT, w tym zachowań użytkowników, to praktycznie wymóg prawny, gdyż wiele zadań nakładanych przez Ustawodawcę bez wsparcia narzędziowego w ogóle nie jest możliwe do wykonania. Wystarczy dobrze przyjrzeć się znaczeniu słowa „monitoring” – niestety nie jest to jedynie ocena, która najczęściej ma charakter dorywczy.   Jednym z elementów wskazujących na to, że powinniśmy korzystać z tego typu narzędzi, jest prawo pracy – a nie wygląda, prawda? Oczywiście nie wprost.   Artykuły 22, 94, 100, 120 i 128 kodeksu pracy mówią m.in. o konieczności zapewnienia możliwości pełnego wykorzystania czasu pracy i braku uciążliwości pracy, o obowiązku wykonywania pracy w zadanym czasie i obowiązku przestrzegania regulaminów. Ponadto pracownik ma obowiązek zachowania w tajemnicy informacji związanej z wykonywaną pracą, a w dobie epoki elektronicznej bez odpowiednich narzędzi nie da się udowodnić, co i kiedy pracownik czytał, a więc miał dostęp do informacji i być może był źródłem wycieku. O przykładzie takich praktyk, jak gromadzenie informacji w celu otworzenia konkurencyjnej firmy, pisaliśmy już dość dawno, więc tu nie będę ponownie opisywał przypadku. W każdym bądź razie to jedna z dwóch stron medalu.   Dlaczego? Otóż może się okazać, iż dokładając wszelkich starań w zakresie bezpieczeństwa naruszymy prawo w innym miejscu, narażając firmę na kłopoty   Ustawa o Ochronie Danych Osobowych wskazuje na zadania, które nierozerwalnie wiążą się z monitoringiem, a więc i z narzędziami, które do tego wykorzystamy. Podobnie  Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne – w szczególności w zakresie definiowanym jako podwyższony (punkt XII.2 załącznika do Rozporządzenia).   Problem zaczyna się wtedy, gdy nie sprawdzimy lub co gorsza nie jesteśmy świadomi zakresu danych jakie przechowuje nasz system do monitorowania sieci. Dlaczego? Dane zgromadzone poprzez system do monitorowania pracy użytkowników mogą być danymi osobowymi pracowników.   I jeżeli spełniony jest warunek gromadzenia informacji stanowiących dane osobowe, wówczas dane te mogą być przechowywane prze określony czas i muszą być zabezpieczone zgodnie z zasadami, o których mówi w/w Ustawa i Rozporządzenie, co więcej należy zarejestrować w GIODO zbiór danych z określeniem wszystkich parametrów, jakie w tym zakresie są wymagane.   Kiedy nie mamy takiego problemu? Wtedy, gdy dane nie są gromadzone z przypisaniem do użytkownika, a jedynie do stanowiska i nie będzie możliwy do spełnienia warunek, że określenie personalne osoby będzie wymagało niskiego nakładu kosztów.   To jednak niewielki problem. Jeżeli bowiem monitorujemy ruch na styku sieci – publicznej i wewnętrznej, w której przetwarza się dane osobowe i będziemy zbyt gorliwi w rejestrowaniu danych, może się okazać, że zaczniemy przetwarzać dane wrażliwe. I tu najlepszym przykładem są tzw. brzydkie strony. Jeżeli rejestrujemy tylko adresy główne – to pół biedy, ale jeżeli rejestrujemy co na tych witrynach było oglądane, to mamy niestety zbiór danych określający preferencje seksualne. Brzmi śmiesznie, prawda, ale jak się dobrze temu przyjrzeć, to problem jest poważny. Wystarczy sobie tylko wyobrazić, że taka baza „wyjeżdża” nam z zasobów na zewnątrz – konsekwencje mogą być opłakane. Zatem albo zweryfikujemy to, co gromadzimy i poprzestaniemy na tym, co jest nam potrzebne albo rejestrujemy zbiór – przy czym tu musimy się liczyć z tym, że GIODO go nie zarejestruje, bo nie uzna naszego uzasadnienia, po co nam wiedza na temat brunetki czy blondynki. Warto też zawsze rozważyć ograniczenie ruchu do obszarów Internetu związanych z pracą, to ułatwi nam życie. A i tak nie zmieni to faktu, że Ustawa o Ochronie Danych Osobowych to jak Kuchnia Pełna Niespodzianek i jeżeli nie potraktujemy tematu poważnie, nigdy nie będziemy pewni co nam jutro przyniesie.