(Nie)Bezpieczeństwo danych - wywiad

Artykuły eksperckie | 07.11.2016 | Czas czytania: 11 minut

Wywiad z Damianem Widerą, trenerem, programistą, administratorem baz danych, współautorem książki “Serwer SQL 2008. Administracja i programowanie”, przeprowadziliśmy przy okazji tegorocznego hakatonu programistycznego, zorganizowanego w JCommerce. Zapytaliśmy go o zagadnienia związane z przeprowadzonymi przez niego warsztatami: Bezpieczeństwo w MS SQL Server 2016, czyli przede wszystkim o bezpieczeństwo danych.

Chcemy się czegoś więcej dowiedzieć o bezpieczeństwie danych.

Cieszę się, bo to chyba jest w ogóle najważniejsza kwestia w naszej branży. Równocześnie jest to bardzo skomplikowane zagadnienie. Bezpieczeństwo danych należy bowiem rozpatrywać na wielu obszarach, a zaczyna się ono już tak naprawdę na naszym komputerze, tablecie, czy telefonie, gdzie te dane widzimy i z nimi pracujemy. Później jest kolejny newralgiczny moment – kiedy te dane przesyłamy i do momentu aż trafią na serwer, musimy mieć pewność, że są one bezpieczne. Oczywiście na samym serwerze te dane też muszą być zabezpieczone. Jak więc widać, jest sporo potencjalnych miejsc, gdzie może się coś niedobrego z tymi danymi stać.

Może więc inaczej. Czy dane w ogóle mogą być bezpieczne? Możemy dane zabezpieczyć na 100%?

Na 100% pewnie nigdy się nie da nic zabezpieczyć. Ale nie wiem czy wiesz, że największe szkody w tym zakresie nie czynią ludzie z zewnątrz, którzy przeprowadzają atak, tylko osoby, które mają całkiem legalnie dostęp do danych. Ktoś sobie wziął backup bazy na swojego laptopa i zgubił komputer lub mu go ukradziono, i te dane dostały się w niepowołane ręce. Albo ktoś zrobił kopie danych na płytach CD i wyrzucił je przez pomyłkę do śmieci. Tak wyciekły jakiś czas temu dane jednego z dużych banków w Niemczech – to był pracownik, osoba „ze środka”, która wskutek pomyłki doprowadziła do takiej sytuacji. Coraz częściej jest tak, że tworzymy piękną strukturę bezpieczeństwa, roztaczamy parasol ochronny nad firmą, serwerami i jest w miarę dobrze z tym bezpieczeństwem na zewnątrz. Natomiast trzeba sporo pracy, aby dobrze zabezpieczyć się „od środka”. Bo jeśli ktoś zrobi wydruk chociażby z Excela, albo nagra dane na płytę, to niewiele da się zrobić. Są wprawdzie pewne punkty, na których firmy się koncentrują w tym zakresie. Na przykład zabezpieczają bazy danych w ten sposób, że jeśli nawet ktoś taką bazę danych zabierze poza firmę, to nie będzie w stanie jej odtworzyć w zewnętrznym systemie, na innym serwerze. Trzeba mieć klucze zabezpieczające, certyfikaty. Dzięki temu administratorzy mają jeden sposób więcej na zabezpieczenie danych. Takie certyfikaty, które szyfrują bazy danych są oczywiście również chronione przez administratorów, a niejednokrotnie fizycznie są zamykane w sejfach.

W sejfach?

Tak. Dla przykładu w ten sposób zabezpiecza się klucze bankowe, które umożliwiają przeprowadzanie transakcji. Żeby wygenerować taki certyfikat, trzeba mieć możliwie jak najwyższe liczby pierwsze. Wygląda to tak, że mnoży się dwie takie liczby pierwsze, z czego powstaje bardzo wysoka liczba, a z niej generuje się właściwe certyfikaty. Te wysokie liczby pierwsze są rzeczywiście przechowywane w skarbcach. Do takiego sejfu dostęp mają tylko nieliczne osoby w firmie. Tak jak kiedyś chowało się w takich skarbcach pieniądze, złoto, czy inne cenne przedmioty, tak teraz jest tam na przykład liczba 2 do potęgi 600 000 000 minus 1.

No dobrze. A w nieco mniejszych firmach?

Niestety zdarza się, że jest bardzo mała świadomość tego, jak ważne jest bezpieczeństwo danych. Ludzie mają w ogóle bardzo niską świadomość w zakresie obsługi komputera tak naprawdę. Pozwalają sobie instalować bardzo różne oprogramowanie, często zupełnie bezkrytycznie, więc stosunkowo łatwo jest od nich wydobyć nawet najbardziej newralgiczne dane. Jeśli się ktoś postara, to ma te dane jak na dłoni.

Czyli nie szpiedzy, czy hakerzy, a niedoedukowani pracownicy są największym zagrożeniem dla firmy?

Tak właśnie mówią statystyki. Nieodpowiedzialny pracownik – albo taki pracownik, który został zwolniony i stwierdza, że w takim razie „ja jeszcze na złość zrobię” – jest groźniejszy niż atak z zewnątrz. Bo takiego ataku z zewnątrz możesz się spodziewać, dlatego masz odpowiednia architekturę, infrastrukturę, routery, firewalle, grupę administratorów, która tego wszystkiego pilnuje. A od środka? Też powinni pilnować, ale jest to wbrew pozorom trudniejsze zadanie.

Jak się więc zabezpieczyć przed wewnętrznymi zagrożeniami?

Są polityki bezpieczeństwa, wewnętrzne mechanizmy zabezpieczeń, ale najważniejsze jest skonstruowanie odpowiednich poziomów dostępu do zasobów. Czyli jeśli jest baza danych, która ma dane wrażliwe, to może nie wszyscy pracownicy muszą mieć do niej dostęp. Jeżeli deweloperzy potrzebują mieć dostęp do takiej bazy danych, to dokonuje się anonimizacji danych wrażliwych i deweloperzy sobie na takiej kopii pracują. Anonimizacja to proces, w którym wrażliwe dane się zaciemnia. Nawet jeśli więc te dane wyciekną, to trudno – nic strasznego się nie dzieje. Od pewnego poziomu powinna być już jednak taka ścieżka zabezpieczeń danych, że dostęp do nich ma tylko kilka starannie wybranych osób. Więc kiedy coś się tutaj stanie, to grupa „podejrzanych” jest bardzo wąska. Wiadomo wtedy co się dzieje, ponieważ wszystko jest audytowane.

Mam taki projekt dla pewnej firmy farmaceutycznej. My, jako deweloperzy, w ogóle nie mamy dostępu do serwera produkcyjnego. Możemy wprawdzie obejrzeć dane z monitorowania (i to nie wszystkie), ale wykonać modyfikację nie jest łatwo, ponieważ tylko grupa kilku osób na całą globalną korporację może to zrobić. Każda taka operacja jest audytowana, czyli potem w logu jest wskazane, że o tej godzinie, ten pracownik zrobił to i to. A jeśli my jako deweloperzy tylko te dane oglądamy, bo ktoś np. zgłaszał błąd, to nawet to przeglądanie jest rejestrowane.

To jest firma farmaceutyczna, więc tam jest bezpieczeństwo na ekstremalnie wysokim poziomie. A z drugiej strony ta firma powiedziała w pewnym momencie: mamy tak dużo danych, że część z nich przenosimy do chmury. No i rzeczywiście teraz się tym zajmuję. To jest firma w Niemczech i powstało tam nowe centrum Microsoftu, taka „chmurka niemiecka”, więc znaczna część naszej hurtowni danych już się tam znajduje.

No właśnie – jak to jest z bezpieczeństwem rozwiązań chmurowych? W Polsce dalej pokutuje opinia, że to jest spore zagrożenie dla danych.

W Polsce jest wszystko na odwrót. Przede wszystkim źle – bo stereotypowo – o tym myślimy. Dzisiaj podczas swojej prezentacji wykonywałem demo w chmurze. Ja wiem, że to jest gdzieś tam na serwerze w Dublinie, bo tam chyba jest najbliższe nam geograficznie miejsce. Mam tam minimum trzy kopie danych, więc jeśli któraś z tych kopii ulegnie uszkodzeniu, to od razu jest druga i trzecia dostępna. To jest wygodne. Połączenie jest szyfrowane, więc ten transfer jest zabezpieczony. Przypuśćmy, że masz firmę, która udostępnia aplikację webową. Możesz ją zrobić tak, że klient łączy się bezpośrednio na Twój serwer albo przesyła dane do chmury Microsoftu. Nie wiem, czy jesteś w stanie lepiej zabezpieczyć niż Microsoft, który się zajmuje protokołami bezpieczeństwa od lat.  

A co w przypadku ataku?

Serwerownia w przypadku chmury to jest takie pole wielkości boiska do piłki nożnej, tam są tylko ogromne kontenery, w których są dyski i nic więcej. Tego pilnuje strażnik i pies. I nikogo więcej tam nie ma. To jest w jakiejś głuszy w lesie, oczywiście ogrodzone, bo być musi, ale na samą tę serwerownię ataku raczej nie będzie, bo to jest bez sensu. Kluczowe jest to, co się dzieje pomiędzy. Najniebezpieczniejsze miejsce to ten moment, kiedy wysyłamy dane z naszej aplikacji, zanim one trafią na serwer. To tu się może coś stać. Dlatego właśnie wszyscy Ci dostawcy, przynajmniej Ci liczący się na rynku, starają się jakoś tę lukę zabezpieczyć, np. zalecają dodatkowe szyfrowanie. Więc nawet jeśli ktoś przechwyci dane, ma szyfrogram i nie będzie się opłacało tego dekodować.

Czyli nie taka chmura straszna, jak ją malują?

Zgadza się. Słabość chmury zawsze będzie polegała na tym, co my z nią robimy. Jeśli odpowiednio zabezpieczymy dostęp do niej, nic złego nie powinno się wydarzyć. Oczywiście jestem zdania, że nie można bezkrytycznie przenosić wszystkich aplikacji i danych do chmury, ale nie należy jej się bać.

No, ale nie zapominajmy, że podstawowym problemem bezpieczeństwa w Polskich firmach jest to, że jest jedno konto, wszyscy mają do niego hasło i wszyscy z niego korzystają, prawda?

Tak często bywa i jak tu można mówić o bezpieczeństwie? W tym kontekście mówienie, że chmura nie jest bezpieczna, jest naprawdę mało poważne. Ale jest taki stereotyp. Pamiętam, kiedy o rozwiązaniach chmurowych dopiero zaczynało się mówić, to był rok 2010. U nas tego tematu w ogóle nie poruszano, ale akurat wtedy byliśmy z kolegą na konferencji dotyczącej tego tematu. Niemcy czy Holendrzy mieli dosłownie wypieki na twarzach i miliony pomysłów, co z tą chmurą zrobić. Byli zachwyceni tym, jakie to daje możliwości. A kiedy wróciłem do Polski, reakcja była od razu „chmura nie, bo zaraz nam ukradną”. I często dalej tak jest. I dlatego dalej jesteśmy wiele lat za innymi firmami, ludźmi, projektami, gdzie już dawno się coś się w tym kierunku dzieje, a my nadal jesteśmy na etapie strachu, że pewnie ktoś mi coś ukradnie. Tak jakby nie było większych zmartwień.

Tak naprawdę jedyny problem z chmurą występuje chyba na etapie usuwania danych, takiego bezpowrotnego, kiedy chcemy mieć pewność, że one nie będą już dla nikogo dostępne. Kiedy wrzucimy je w chmurę, tracimy też nad nimi kontrolę. Może stąd te obawy?

To prawda. I to jest rzeczywiście pytanie na innym trochę poziomie, bo to jest etap, kiedy my tak naprawdę już tej chmury nie chcemy i nie chcemy, aby pozostały tam nasze dane. Pytanie wtedy brzmi, jak to jest uregulowane. Jakie są mechanizmy i procedury bezpowrotnego usuwania danych w chmurze. Dotyczy to zwłaszcza przypadków, kiedy te dane są szczególnie wrażliwe.

To jest właściwie przede wszystkim kwestia kontroli. Wybór usług w chmurze wiąże się z tym, że oddajemy tę kontrolę operatorowi, dostawcy usług.

No tak, ale z drugiej strony jest ta wspomniana firma farmaceutyczna, która ma bardzo wrażliwe dane, a jednak decyduje się na chmurę. Pewnie opiera się to na umowie, w tym przypadku z Microsoftem, która jest wtedy odpowiedzialna za bezpieczeństwo. W naszym wypadku jest na pewno specjalne łącze, jeśli chodzi o połączenie z tą chmurą, to jest express link, czy coś takiego, które gwarantuje określoną przepustowość, bo to jest jednak połączenie internetowe. Dodatkowo pamiętajmy o tym, że danych naprawdę przybywa w olbrzymim tempie. Teraz jesteśmy na etapie wdrażania u siebie koncepcji Internet of Things, gdzie wszystkie te urządzenia analityczne będą ze sobą połączone, więc danych będzie jeszcze więcej.

No tak. Czyli musieli to jakoś technicznie rozwiązać.

Tak. A z technicznego punktu widzenia chmura to jest bardzo wygodne rozwiązanie. Musi to też być mimo wszystko bezpieczne, bo wiem jakie w tej firmie są procedury bezpieczeństwa. Myśmy tylko raz wystawiali na jednym z portali tej firmy dane i to nie były wcale dane poufne, ale dane, które można było znaleźć na stronach internetowych tej firmy. Sama implementacja rozwiązania, opartego o web services, zajęła niecałe dwa tygodnie, natomiast etap spotkań i uzgadniania zabezpieczeń z działem security trwał pół roku, a potem jeszcze miesiąc testów, podczas których wynajęte z zewnątrz firmy miały za zadanie tylko i wyłącznie atakować ten serwis i doprowadzić do wycieku danych. Dopiero po tych testach można było ten web service udostępnić jako publiczny.  

W takim razie czy taka histeria z punktu widzenia bezpieczeństwa jest wskazana? Weźmy za przykład średniej wielkości polskie przedsiębiorstwo.

To trudna sprawa. Z jednej strony mamy możliwości zabezpieczenia, a z drugiej strony jest to trudny proces, bo wiąże się z nakładami finansowymi. Im bardziej chcemy być bezpieczni, tym więcej będzie to kosztowało.  Trzeba więc znaleźć optymalny poziom bezpieczeństwa, na który nas stać.

Na ile w takim razie kwestia złamania zabezpieczeń to jest kwestia zasobów? Bo z jednej strony mam takie zabezpieczenia, na jakie mnie stać. Z drugiej strony zabezpieczanie ma sens jedynie do tego momentu, kiedy potencjalne sforsowanie systemu przestaje być opłacalne dla przeciwnika – albo zbyt kosztowne, albo zbyt długotrwałe. Gdzie jest tutaj granica?

To jest prawda. Im ktoś ma mniej pieniędzy, tym łatwiej go złamać. Czy to z zewnętrz, czy wewnątrz. To jest też kwestia proporcji sił. Prywatny użytkownik ma małe szanse w starciu z firmą, czy zorganizowaną grupą przestępczą, a nawet czasami państwem, które dysponuje znacznie większymi zasobami. Ale to nie znaczy, że powinien zupełnie odpuścić ochronę.

No dobrze. W takim razie jaki jest taki absolutny must have, jeśli chodzi o bezpieczeństwo w firmie? Elementy, które zagwarantują nam podstawowe bezpieczeństwo i spokój ducha.

Podstawa to na pewno dobrzy administratorzy, którzy poustawiają uprawnienia na stacjach roboczych, czy dostępy do serwerów, na których przechowywane są wrażliwe informacje. Najlepiej jeśli będą to serwery wirtualne, ponieważ wtedy na stacjach roboczych nie musimy już mieć żadnych danych. Firma, która ma już około setki pracowników, musi już mieć dobry zespół administratorów, który wie jak firmę zabezpieczyć, monitorować. Poza tym muszą mieć odpowiednie narzędzia. Muszą umieć to wszystko zorganizować i egzekwować. Jeśli są jakieś problemy, reagować. To nie jest prosty temat. Pamiętajmy, że nie ma tutaj drogi na skróty. Później jest już tylko większy problem, bo jeśli mamy firmę, która jest prawnie zobowiązana do wykonywania pewnych operacji, to tej litery prawa się trzeba trzymać.

To, co sprawia, że wielu użytkowników wychodzi z założenia, że przed atakiem nie da się uchronić, to są głośne, spektakularne wpadki wielkich, nawet nie tylko firm. Przychodzi mi do głowy ostatnia wpadka Hillary Clinton z mailami albo wyciek danych z Yahoo, czy afera z bazą PESEL w Polsce.

To prawda. Ale groźniejsze są takie właśnie sprytne ataki albo spektakularne luki aplikacyjne. Ostatnio był taki przypadek w ZUSie, w jego aplikacji, gdzie wykorzystywano profil zaufany. Okazało się, że jeśli zostawiło się okno do wprowadzania danych z profilu zaufanego otwarte dłuższy czas, to wygasała sesja i jeśli się wtedy zrobiło powrót, to łamało się zabezpieczenia i przechodziło dalej bez podawania wymaganych informacji. W kodzie aplikacji był błąd i nie został on wykryty na etapie testowania. Być może z powodu braku takiego scenariusza testowego lub z innych powodów, także finansowych. Może to oznaczać, ze ktoś nie przewidział ryzyka wystąpienia ataku w ten sposób lub wręcz zaniechał testowania tego fragmentu kodu.

Czyli typowo polskie „jakoś to będzie”?

Czasem tak bywa. Testów się niestety robi u nas stosunkowo mało, a są one naprawdę bardzo potrzebne. Czasami na zrobienie dobrego testu trzeba poświęcić więcej czasu niż się pisało program. Zdarza się, że wiele rzeczy robi się za najmniejsze pieniądze, „studentami”, a to potem ma swoje odbicie w jakości kodu i jego bezpieczeństwie. Dla mnie standardem jest, że jeśli w projekcie jest development na 200 godzin, to testy też powinny trwać 200 godzin. Później jest jeszcze przegląd kodu oraz czas na napisanie dobrej dokumentacji. Prosty projekt może być wtedy wykonywany wielokrotnie dłużej. I to jest okej, jeśli firma ma na to środki. Bo wtedy będzie miała bezpieczną aplikację, przetestowaną i udokumentowaną. Ale jeśli jest to startup, to często będzie chciał oszczędzić. I niestety to właśnie na testach najczęściej się oszczędza. A chyba nigdzie tak jak w przypadku bezpieczeństwa danych nie sprawdza się powiedzenie, że oszczędny dwa razy traci. 

Autorem wpisu jest

Damian Widera

Data Expert

Od 15 lat zajmuje się projektowaniem, tworzeniem i wdrażaniem aplikacji wykorzystujących platformy: .NET, SQL Server oraz Oracle. Jest trenerem, programistą, administratorem baz danych, twórcą dokumentacji oraz analitykiem biznesowym. Współautor książki "Serwer SQL 2008. Administracja i programowanie". Speaker na wielu konferencjach branżowych. Posiada certyfikaty firmy Microsoft: MCT, MCITP-DBA, MCITP-DD, MCSD.NET, od 2009 roku nagradzany nieprzerwanie tytułem MVP w kategorii SQL Server (obecnie Data Platform MVP).

Komentarze

  • Aktualnie brak komentarzy.

Skontaktuj się z nami