Bezpieczeństwo systemów IT na gruncie RODO

Ogólne bezpieczeństwo aplikacji

Architektura aplikacji

Z tworzeniem systemów webowych (ogólnie mówiąc – systemów IT) jest jak z budowaniem domu. Zanim rozpoczniemy prace deweloperskie, musimy przygotować plan oraz zaprojektować architekturę.

Jaka architektura jest najlepsza? Na to pytanie nie można odpowiedzieć jednoznacznie. Wiele zależy od środowiska, w jakim działa aplikacja.

Obecnie coraz więcej aplikacji jest budowanych w chmurze. Są to najczęściej duże projekty. Architektura tych aplikacji składa się z wielu mikroserwisów, a więc kilku miniaplikacji odpowiedzialnych za pojedyncze usługi. Połączone w jeden system dają one aplikację webową, którą widzimy w przeglądarce. Patrząc z punktu widzenia wydajności takiej aplikacji, jej skalowalności czy bezpieczeństwa, jest to duży plus.

Pozostałe architektury nie bazują na mikroserwisach. Często są to aplikacje trzy-, dwu-, a nawet jednowarstwowe. Warstwy aplikacji to fizyczny bądź logiczny podział jej komponentów na poszczególne funkcje. Z punktu widzenia bezpieczeństwa najbardziej optymalny może być podział na trzy warstwy. W praktyce wygląda on jak na schemacie: Dane aplikacji → Serwer logiki aplikacji → Strona www

W tym modelu jedynym elementem publicznie dostępnym dla każdego użytkownika Internetu powinna być część WWW. Jest to warstwa prezentacji, czyli warstwa aplikacyjna, gdzie znajduje się interfejs aplikacji. To w tej warstwie zachodzi interakcja użytkownik – aplikacja. Tam odbywa się także zbieranie wszelkich danych od użytkownika.

Sercem aplikacji jest serwer odpowiadający za jej bezpośrednie działanie i całą logikę działania. Dlatego często tę środkową warstwę nazywa się warstwą logiki aplikacji. Na tym poziomie przetwarzane są wszelkie żądania kierowane przez użytkowników, które zostały przepuszczone przez serwer WWW oraz mechanizmy filtracji.

Podstawą działania każdego systemu jest baza z danymi, gdzie znajdują się rekordy, które aplikacja przetwarza. Baza jest odpowiedzialna za przechowywanie przede wszystkim danych, ale również na przykład wszelkich zgód wyrażonych przez użytkownika podczas korzystania z systemu (takich jak zgody na komunikację marketingową).

Ważne, aby komunikacja między warstwą prezentacji a bazą danych przechodziła przez warstwę logiki aplikacji. Prawidłowe wdrożenie warstwy logiki aplikacji może uchronić aplikację przed atakami typu SQL Injection. Często dwie najwyższe warstwy – serwer aplikacji wraz z serwerem WWW – stanowią jedną fizyczną całość, a jedyne rozdzielenie zachodzi na poziomie logicznym. Dla części systemów nie musi to być duży błąd bezpieczeństwa – oczywiście przy zastosowaniu filtracji ruchu między poszczególnymi warstwami oraz odseparowaniu bazy danych.

Bezpieczeństwo nagłówków odpowiedzi

Rozważania nad bezpieczeństwem nagłówków warto rozpocząć od wprowadzenia do tego, jak wygląda komunikacja HTTP oraz czym jest żądanie, a czym – odpowiedź.
Każda czynność wykonana w aplikacji webowej (np. logowanie) powoduje wysłanie „pod spodem” tzw. żądania klienta do serwera. W odpowiedzi otrzymujemy odpowiedź serwera, a na ekranie przeglądarki widzimy, stronę, którą wyświetla serwer. Każde żądanie i każda odpowiedź zawiera nagłówki z informacjami.

Nagłówki wysyłane przez serwer aplikacji mogą być źródłem wielu informacji dla atakujących. Dlatego warto zadbać o to, aby:

• nagłówki nie zawierały wrażliwych informacji o komponentach (np. o wersji systemu operacyjnego serwera),
• odpowiedź zawierała nagłówek: X-Content-Type-Options: nosniff,
• odpowiedź zawierała nagłówek: Strict-Transport-Security (w każdej odpowiedzi oraz dla każdej subdomeny),
• nagłówek referrer-policy był odpowiednio skonfigurowany, ponieważ może zdradzić informację o tym, z jakiej strony przekierowano użytkownika, czyli o jego poprzedniej lokalizacji.

Ukryte katalogi

Bez wątpienia istotne jest, aby przy udostępnianiu aplikacji webowej publicznie wyłączyć funkcję listowania katalogów. Dzięki temu możemy zapobiec potencjalnemu oglądaniu po kolei zawartości katalogów oraz plików na serwerze za pomocą przeglądarki. Byłby to prezent dla atakującego, który mógłby bez kłopotu przeglądać pliki serwera (oraz aplikacji), a w konsekwencji – natrafiać na wrażliwe dane czy informacje ułatwiające mu przełamanie zabezpieczeń systemu.

Ważna jest również weryfikacja nadanych dostępów do katalogów i metadanych aplikacji. Publicznie dostępne nie mogą być katalogi zawierające pliki konfiguracyjne aplikacji, elementy kodu źródłowego czy backup. Szczególnie warto zadbać o ukrycie metadanych, takich jak Thumbs.db, .DS_Store, .git, .svn. Dostępy do danych tego typu powinny być ograniczone.

Sprawdzanie danych wejściowych

W kontekście bezpieczeństwa kluczowe jest weryfikowanie przez aplikację danych wejściowych. Brak takiego mechanizmu może doprowadzić do powstania istotnych podatności, np. podatności klasy XSS czy SQL Injection.

Niezbędne jest sprawdzenie wszystkich danych wejściowych (np. danych wpisanych w polu formularzy) na podstawie odpowiedniej listy walidacji określającej, jaki typ danych może znaleźć się w danym polu. Dobrą praktyką jest weryfikowanie danych zgodnie ze schematem. To znaczy, że dane w konkretnym polu muszą mieć odpowiednią długość czy określone znaki. Przykładem może być pole na wpisanie numeru telefonu.

Wszelkie pliki, które są przesyłane przez użytkowników, powinny być przechowywane poza folderami głównymi, z ograniczonymi uprawnieniami. Takie pliki najpierw powinny przechodzić szczegółowe badanie na obecność złośliwego kodu. Dobrze, jeżeli warstwa sieciowa aplikacji nie przyjmuje plików z rozszerzeniem plików skompresowanych, kopii zapasowych czy plików tymczasowych.

Trzeba zwrócić uwagę, żeby użytkownicy mogli wgrywać do aplikacji tylko konkretny zakres plików (np. określony format) i nie mieli możliwości wykonać tych plików na serwerze. Ograniczy to ryzyko, że potencjalny cyberprzestępca będzie mógł w prosty sposób, za pomocą samej przeglądarki, dodać na serwer tzw. web shell (mały plik pozwalający na wykonanie kodu na serwerze), a następnie uruchomić go na tym serwerze.

Zapora WAF

Zapora WAF (Web Application Firewall)  jest jednym z podstawowych elementów zabezpieczeń aplikacji webowej. Można ją porównać do firewalla chroniącego infrastrukturę, który odpowiada za filtrację i blokowanie niepożądanego ruchu do aplikacji. Podobnie działa aplikacja i zapora WAF.

Zgodnie ze standardem PCI DSS zapora WAF to punkt wymuszania zasad zabezpieczeń umieszczony między aplikacją sieci web a punktem końcowym klienta. Funkcjonalność ta może być zaimplementowana w oprogramowaniu lub sprzęcie uruchomionym w urządzeniu lub na typowym serwerze, na którym działa wspólny system operacyjny. Może być samodzielnym urządzeniem lub zintegrowanym z innymi elementami sieci.

 Zapora WAF działa w dwóch podstawowych modelach:

• 

  Też wolisz profilaktykę niż leczenie?

  Audyt zgodności z RODO to holistyczne badanie, które pokazuje, w którym miejscu jest organizacja.

  ZOBACZ WIĘCEJ
  opartym na regułach – podobnie jak „zwykły” firewalla zapora korzysta z zestawu reguł, dzięki czemu rozróżnia złośliwe żądania spośród ogółu żądań,
• uczenia się – na podstawie zachowania użytkowników zapora sama uczy się rozróżniać złośliwe zachowania, a następnie automatycznie dodawać reguły.

Reguły, które „zna” zapora WAF, mogą być wykorzystywane w trzech trybach:

• negatywnym (czarna lista) – ustawione reguły mają za zadanie blokować wyraźnie niepożądany (złośliwy) ruch oraz ruch, który próbuje wykorzystywać konkretne luki w zabezpieczeniach. Jest to optymalny tryb pracy dla zapory aplikacji działającej w sieci publicznej. Może być skuteczny na przykład w przypadku ataków DDoS,
• pozytywnym (biała lista) – zapora dopuszcza tylko konkretny ruch (skonfigurowany w regułach). Przykładem może być takie skonfigurowanie zapory WAF, aby akceptowała żądania HTTP GET albo żądania jedynie z konkretnych adresów IP. To rozwiązanie prawdopodobnie będzie skuteczne przy blokowaniu różnych cyberataków, ale przy tym może blokować dużo poprawnego ruchu. Dlatego taki tryb pracy zapory WAF najbardziej sprawdzi się do ochrony aplikacji działających w sieci wewnętrznej, gdzie jest ograniczone grono odbiorców,
• hybrydowym – będącym połączeniem dwóch powyższych. To, czy tryb hybrydowy nadaje się do publicznie dostępnych aplikacji czy do aplikacji wewnętrznych, zależy od sposobu konfiguracji zapory WAF.

Podczas konfigurowania zapory WAF warto mieć na uwadze, że atakujący może w różny sposób próbować ją ominąć, np. dodając odpowiedni nagłówek w wysyłanym żądaniu.

Zarządzanie aktualizacjami oraz podatnościami

Bez dwóch zdań odpowiedni nadzór nad aktualizacjami systemu IT oraz zachowywanie wszystkich aktualnych komponentów, które składają się na ten system, to jedne z filarów jego bezpieczeństwa. Często przestępcy skanują dostępne w sieci aplikacje webowe pod względem ich podatności technicznych istniejących w różnych miejscach, takich jak serwery, na których zainstalowana jest aplikacja, biblioteki itp. Regularne aktualizacje pozwolą na minimalizację ryzyka związanego z wystąpieniem podatności technicznych w systemie, a to ograniczy potencjalne wektory ataków na ten system.

Poza regularnymi aktualizacjami administratorzy powinni zadbać o weryfikację podatności w aplikacji. Systemy, szczególnie te dostępne w otwartym Internecie, powinny być okresowo skanowane pod względem istnienia w nich podatności. Częstotliwość skanowania powinna zostać określona po przeprowadzeniu wewnętrznej analizy ryzyka. Następnie administratorzy na podstawie przyjętego planu postępowania z wykazanymi podatnościami powinni zająć się ich usuwaniem albo mitygowaniem.

Okresowo warto również sięgać po wyższy poziom badań podatności, jaki zapewniają testy penetracyjne. Podczas takich testów audytorzy badają aplikację pod względem istnienia w niej podatności i próbują przełamać zabezpieczenia. Testy kończą się raportem, który pokazuje, jakie konkretne podatności występują w systemie i jak należy je wyeliminować. Dzięki eliminowaniu podatności zmniejszamy prawdopodobieństwo, że natrafi na nie przestępca, który będzie próbował je wykorzystać, żeby złamać nasz system.

Bezpieczeństwo uwierzytelniania

Współczesne systemy powinny charakteryzować się wdrożonymi silnymi zasadami uwierzytelniania użytkownika. Rozumie się przez to stworzenie polityki logowania odpornej na siłowe próby łamania haseł, odgadywania, porównywania czy ich błędnego resetowania.

Zasady bezpieczeństwa systemów powinny uwzględniać również sytuację, gdy hasło użytkownika zostanie skompromitowane albo gdy użytkownik go po prostu zapomni.

Polityka haseł

Zacznijmy od podstaw – hasło, które ustawia użytkownik, musi być silne. Wielu z nas pamięta regułkę: „osiem znaków, mała i duża litera, cyfra oraz znak specjalny to silne hasło”. Być może kiedyś to się sprawdzało, jednak obecnie hasło stworzone zgodnie z tą zasadą jest stosunkowo łatwe do złamania. Dobre hasło to takie, które charakteryzuje się odpowiednią długością. Przyjmuje się, że jest to min. 12 znaków. Pamiętajmy, że komputery są coraz wydajniejsze, a więc za jakiś czas i taka długość może być już niewystarczająca.

Warto rozważyć implementację mechanizmów polegających na zablokowaniu użytkownikowi możliwości ustawiania już skompromitowanych, a przynajmniej najbardziej popularnych haseł. Takie listy są dostępne w Internecie, np.: https://github.com/danielmiessler/SecLists/tree/master/Passwords.

Jak jeszcze możemy zabezpieczać proces uwierzytelniania? W praktyce ataki na hasła można ograniczyć, blokując logowanie na konto użytkownika w momencie podania kilkukrotnie błędnego hasła. Po pierwszych pięciu próbach błędnego logowania możemy pozwolić na czasową blokadę konta (np. 30 minut). Po następnym cyklu nieudanego logowania możliwość odblokowania konta danego użytkownika powinien mieć już tylko administrator danego systemu. Aby zablokować próby siłowego odgadywania hasła w systemie, w procesie odblokowania konta administrator powinien dokładnie zweryfikować tożsamość danego użytkownika.

Dwuskładnikowe uwierzytelnienie

Użytkownik, który chce udowodnić swoją tożsamość w systemie, powinien użyć nie tylko czegoś, co wie (czyli hasła), lecz także czegoś, co ma (np. klucza lub tokena). Wynika to z prostego powodu – hasła, a właściwie ich hashe, wyciekają. Hasła użytkowników często zostają przejęte w wyniku ataków phishingowych. Dodatkowe zabezpieczenie w mechanizmie uwierzytelniania powoduje, że nawet jeżeli niepowołana osoba uzyska dostęp do hasła, to nie zaloguje się do systemu, ponieważ nie będzie w posiadaniu drugiego składnika.

Istnieje wiele sposobów dwuskładnikowego uwierzytelniania (2FA). Obecnie najpopularniejsze są cztery metody:

• kody SMS,
• połączenie na telefon użytkownika,
• aplikacje uwierzytelniające,
• klucze U2F.

Przyjrzyjmy się ich zaletom oraz wadom.

Zacznijmy od metod, w których jako drugi element uwierzytelniający wykorzystywany jest kod. W przypadku kodu SMS system wysyła go na numer telefonu. Następnie użytkownik musi go wpisać, aby potwierdzić swoją tożsamość. Na podstawie generowania kodu działa też część aplikacji uwierzytelniających – wygenerowany kod użytkownik musi wprowadzić do systemu. Sama zasada wydaje się dość prosta, tania w utrzymaniu oraz bezpieczna – przecież kod przychodzi na nasz numer telefonu albo sami go generujemy. Niestety rzeczywistość (zwłaszcza w cyfrowym świecie) jest o wiele bardziej złożona. Przestępcy często korzystają z narzędzi pozwalających przechwytywać wszystkie informacje, które wpisujemy do systemu w czasie rzeczywistym (np. za pomocą narzędzi działających na zasadzie proxy zwrotnej). Łatwo zatem jest wywnioskować, że gdybyśmy padli ofiarą takiego ataku, to złodziej najpierw przejąłby nasz login i nasze hasło, a później wygenerowany kod – i zdążyłby zalogować się przed nami. Warto pamiętać, że dodatkowym czynnikiem obciążającym wykorzystywanie kodów SMS są ataki typu SIM-SWAP. W ich wyniku niepożądana osoba może przejąć nasz numer telefonu, a w konsekwencji – odbierać SMS-y i połączenia.

Niektóre aplikacje uwierzytelniające działają na innych zasadach – po prostu wysyłają powiadomienie o próbie logowania z prośbą o zatwierdzenie. Jeśli prośba ta nie zostanie zaakceptowana w aplikacji, dostęp do konta nie będzie możliwy. Zabezpiecza to użytkownika w przypadku, gdy jego hasło „tylko” zostanie skompromitowane i będzie chciała się na nie zalogować nieupoważniona osoba. Nie zabezpieczy go to jednak na wypadek prób przejęcia hasła w czasie rzeczywistym (podobnie jak w przypadku metod wykorzystujących kod). Gdy nieświadomy niczego użytkownik będzie próbował uzyskać dostęp do konta w tym samym czasie co przestępca, prawdopodobnie to on wyśle żądanie do aplikacji po to, by ofiara zaakceptowała jego logowanie.

Na tę chwilę najbezpieczniejsze są klucze U2F. Dlaczego? Odpowiedź jest prosta: dotąd nie znaleziono sposobów, aby je złamać. Nawet gdy ktoś zna hasło, nie może w żaden sposób przejąć klucza U2F, gdyż jest to fizyczne urządzenie, które wkłada się do komputera. Warto pamiętać, aby zablokować możliwość korzystania przez użytkownika z innych metod dwuskładnikowego uwierzytelniania w momencie, kiedy skonfiguruje klucz U2F. Jeżeli istniałyby bowiem alternatywne metody uwierzytelniania, przestępca mógłby je wykorzystać.

Jedyne problemy, jakie wynikają ze stosowania kluczy U2F, to ich wysoka cena i mała wygoda użytkowania. Z tego powodu organizacje często decydują się na korzystanie z innych metod (kodów SMS czy aplikacji uwierzytelniających). Jeżeli jednak z jakichś powodów nie możemy czy nie chcemy wdrażać kluczy fizycznych jako zabezpieczenia, to mimo ryzyk warto pomyśleć o innych metodach (kody SMS czy aplikacje). Nie każdy atakujący potrafi przechwytywać kody SMS czy sygnał z aplikacji, dlatego o wiele lepiej mieć skonfigurowaną jakąkolwiek formę uwierzytelniania wieloskładnikowego, niż nie mieć jej w ogóle.

Enumeracja kont

Jak ma zachować się system w momencie, kiedy informacje wejściowe podane przez użytkownika nie są zgodne z rzeczywistymi danymi przypisanymi do tożsamości konkretnej osoby? Oczywiście mechanizmy logowania powinny odrzucić próbę uzyskania dostępu. Ważne jest również zwrócenie uwagi na informację zwrotną przekazywaną osobie chcącej się zalogować (upoważnionej lub nie). W tym zakresie często popełniane są błędy. Przestępcy wykorzystują źle skonfigurowane systemy, aby w pierwszym kroku uzyskać informację, czy w systemie w ogóle istnieje dane konto dla określonego loginu. Po podaniu danych wejściowych przez przestępcę system zwraca informację zwrotną typu: „Dane konto nie istnieje” – w przypadku podania błędnego loginu lub „Podano nieprawidłowe hasło” – w przypadku gdy login istnieje w danym systemie, ale podane hasło jest nieprawidłowe.

Nieistotne jest zatem, czy system otrzymał błędny login czy błędne hasło. W odpowiedzi do użytkownika system nie może wskazywać, która część danych była niepoprawna. System „Produkcja” powinien zwrócić informację typu: „Podano błędne dane logowania” czy „Adres e-mail lub hasło są nieprawidłowe”.

Monitorowanie aktywności kont

Monitorowanie aktywności kont w systemach jest bardzo ważnym elementem w strukturze bezpieczeństwa. Procedura logowania powinna zostać skonfigurowana tak, aby natychmiast alarmowała administratorów czy zespoły bezpieczeństwa o podejrzanych aktywnościach na koncie użytkownika, lub  prób przełamania zabezpieczeń systemu oraz logowania. Podejrzane konta powinny być wtedy blokowane, a hasła do tych kont – resetowane.

Również użytkownicy powinni mieć wgląd do swojej historii logowań. Dobrze jest, gdy po zalogowaniu do systemu użytkownik otrzymuje informację zarówno o poprzednim udanym logowaniu, jak i o nieudanych próbach uzyskania dostępu do konta. Dzięki takiemu rozwiązaniu może sprawdzić, czy ktoś nieuprawniony nie próbował uzyskać dostępu do jego konta. W przypadku gdy użytkownik zidentyfikuje nieudane bądź – co gorsza – udane logowanie, ma możliwość zmiany hasła oraz sprawdzenia aktywności na swoim koncie.

Przypominanie hasła

Może się wydawać, że mechanizm przypominania hasła nijak ma się do wymagań bezpieczeństwa. Jest on jednak bardzo ważną składową systemu zarządzania dostępem. Powody są dwa:

• użytkownik musi mieć możliwość zresetowania hasła, gdy go zapomni, tak aby móc pracować w systemie, szczególnie jeżeli pełni kluczową funkcję w realizacji danych procesów biznesowych,
• i najważniejsze –  cyberprzestępca, który chce uzyskać dostęp do tożsamości użytkownika w systemie, może wykorzystać wadliwy mechanizm przypominania hasła, aby je zresetować, ustawić własne hasło i w efekcie uzyskać dostęp do systemu. Istotne jest więc zadbanie o to, aby w momencie gdy użytkownik zapomni swojego hasła, link do zmiany hasła mógł przyjść tylko na adres powiązany z jego kontem.

Zmiana hasła

Użytkownik musi mieć możliwość zresetowania hasła, jeśli podejrzewa, że obecnie używane przez niego hasło zostało skompromitowane. To pozwoli mu zabezpieczyć konto przed nieuprawnionym dostępem.

Ważne jest, aby element systemu zarządzania tożsamością, jakim jest mechanizm zmiany hasła, był odpowiednio skonfigurowany. Użytkownik, który chce wprowadzić nowe hasło, najpierw powinien podać poprzednie lub potwierdzić zmianę mailowo. Skutecznie zabezpiecza to przed potencjalnym atakiem – nawet jeśli nieuprawniona osoba uzyska dostęp do aktywnej sesji użytkownika, to bez znajomości aktualnego hasła nie będzie w stanie ustawić nowego.

Należy przy tym uwzględnić możliwość, że atakujący wcześniej wykradł hasło użytkownika, zalogował się do konta i próbował zmienić hasło. Dlatego mechanizm zmiany hasła warto wzmocnić dodatkowym zabezpieczeniem, np. drugim składnikiem uwierzytelniania.

Zarządzanie sesją

Prawidłowe zarządzanie sesją użytkownika jest kolejnym wymaganiem, któremu musi sprostać system. Sesja łączy bezstanowe połączenia HTTP w jedną całość. Dzięki niej jesteśmy w stanie rozróżniać użytkowników i dowiedzieć się, co robili w systemie. Odpowiedzialność za ten obszar opiera się na zapewnieniu unikalności sesji oraz kontrolowaniu czasu jej trwania.

Generowanie i utrzymywanie sesji

Sesje użytkowników muszą być unikalne, a więc tokeny sesji muszą być indywidualne dla każdej z sesji. Nowe tokeny powinny być generowane każdorazowo podczas procesu uwierzytelniania. Szczególną uwagę trzeba zwrócić oczywiście na bezpieczeństwo tokenów sesji i na ich przechowywanie.

Dużym błędem jest ujawnianie tokenów w URL. Stwarza to potencjalne ryzyko manipulacji tokenem, a w konsekwencji – przejęcia sesji innego użytkownika, czyli uzyskania dostępu do jego konta z pominięciem procesu logowania. Rozwiązaniem może być na przykład przechowywanie tokenów sesji z użyciem obiektów Web Storage w HTML5 lub odpowiednio zabezpieczonych plików cookies. Przy wyborze tej metody zarządzania sesją należy zadbać o to, aby:

• pliki cookies miały oznaczoną flagę „secure”, co zapewni ich przesyłanie jedynie podczas połączenia HTTPS,
• pliki cookies miały oznaczoną flagę „HTTPOnly”, co zapewni ich odczytanie jedynie przez serwer (a nie np. przez kody JavaScript),
• tokeny sesji używały prefiksu „__Host”, co zagwarantuje, że pliki cookies zostaną wysłane do serwera, który je ustawił.

Zamykanie sesji

Aby zakończyć sesję, konieczne jest unieważnienie tokena. Może to nastąpić, kiedy użytkownik wybierze opcję „wyloguj” lub kiedy upłynie czas wygaśnięcia sesji. Czas ten zależy od specyfiki systemu, w tym od jego przeznaczenia lub od rodzaju przetwarzanych w nim danych.

Jeżeli nie zdecydujemy się na zamykanie sesji w momencie zamknięcia przeglądarki, powinniśmy rozważyć wszelkie potencjalne ryzyka grożące użytkownikom naszej aplikacji, a następnie – zgodnie z tą analizą – określić maksymalny czas trwania sesji. Dobrą praktyką jest umożliwienie użytkownikowi podglądania wszystkich aktywnych sesji oraz zamknięcia wybranych sesji lub ograniczenie liczby aktywnych sesji do jednej.

Kryptografia

Jak wiadomo, wszelkie dane, a szczególnie dane osobowe, to waluta XXI wieku. Warto pamiętać, że przy tym stale rozwija się kryptografia. Należy więc weryfikować zarówno bezpieczeństwo algorytmów, jak i długość używanych kluczy.

Dane w spoczynku

Jeśli w aplikacji znajdują się dane w czasie spoczynku, powinny być one szyfrowane. W związku z tym podczas projektowania systemów należy zapewnić możliwość zmiany wykorzystywanych algorytmów. Wybierając metody szyfrowania oraz hashowania, warto opierać się na sprawdzonych rekomendacjach branżowych czy rządowych.

Dane w przesyle

Wszelkie połączenia muszą być zabezpieczone szyfrowaniem przy użyciu protokołu TLS 1.2 bądź nowszego, przy czym zaleca się korzystanie z najnowszej wersji. Ważne jest zadbanie o to, aby komunikacja klienta zawsze była szyfrowana, a korzystanie z tego rodzaju zabezpieczeń było obligatoryjne (np. wymuszane za pomocą protokołu HSTS). Warto pamiętać, aby szyfrowana komunikacja była wymagana dla wszystkich połączeń, a więc również na przykład do zarządzania systemem, połączeń API czy połączeń do baz danych.

Ciągłość działania

Bezpieczeństwo aplikacji to nie tylko zapewnienie poufności i integralności danych, lecz także zagwarantowanie dostępności.

W myśl art. 32 ust. 1 lit. b i c RODO system musi być zaprojektowany tak, aby wykazywać:

• zdolność do ciągłego zapewnienia poufności, integralności, dostępności i odporności,
• zdolność do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu fizycznego lub technicznego.

Podstawą spełnienia powyższych obowiązków są kopie zapasowe. Jak jednak zapanować nad całym procesem zarządzania kopiami zapasowymi w aplikacji? Przede wszystkim powinniśmy dokładnie przemyśleć, jakie zasoby chcemy objąć backupem. Na pewno warto rozważyć:

• bazy danych,
• dane systemowe,
• kod strony,
• wszelkie pliki konfiguracyjne,
• historie zmian,
• konfiguracje specyficzne dla środowiska produkcyjnego, takie jak ustawienia bezpieczeństwa.

Najbardziej polecaną metodą tworzenia kopii zapasowych jest metoda 3-2-1. Polega ona na tworzeniu trzech kopii. Powinny być one przechowywane na dwóch różnych nośnikach, a jedna z nich powinna być przechowywana poza głównym miejscem przechowywania produkcyjnych danych (np. w chmurze). Najlepiej, gdy trzecia kopia nie ma stałego połączenia z systemem produkcyjnym. Pozwoli to na minimalizację ryzyka zniszczenia kopii, np. w razie ataków na system i jego środowisko pracy.

Poza wykonywaniem kopii zapasowych warto je również testować. Obejmuje to odtwarzanie kopii zapasowej, aby upewnić się, że wszystko przebiega poprawnie i w razie potrzeby będzie możliwość prawidłowego przywrócenia danych.

Kolejną kwestią, na którą należy zwrócić uwagę podczas testów, jest czas odtwarzania backupu. Trzeba rozważyć, czy nie jest on zbyt długi. Czas odtwarzania kopii zapasowej nie powinien być dłuższy niż maksymalny akceptowalny czas niedostępności systemu.

Rejestrowanie i monitorowanie zdarzeń

Rejestrowanie i monitorowanie zdarzeń jest istotnym elementem zarządzania systemem. To źródło cennych informacji o błędach czy próbach przełamywania zabezpieczeń i wykorzystywania podatności technicznych aplikacji.

Projektując proces monitoringu, należy zadbać o to, aby logi (inaczej: dzienniki zdarzeń) zawierały wyłączenie niezbędne informacje. To oznacza, że nie powinny być logowane dane uwierzytelniające, tokeny sesji czy inne dane wrażliwe, zdefiniowane zgodnie z politykami bezpieczeństwa organizacji oraz regulacjami prawnymi (np. RODO). Logowane powinny być natomiast wszelkie zdarzenia bezpieczeństwa, w tym zdarzenia związane z uwierzytelnianiem, błędy kontroli dostępu czy walidacji danych wejściowych.

Aby usprawnić proces wykrywania niepożądanych zdarzeń w logach, warto rozważyć rozwiązania pozwalające na ich automatyczną analizę czy korelację. W celu agregacji i automatyzacji logów można wdrożyć na przykład systemy SIEM informujące o wystąpieniu anomaliach w systemie, a także korelować te zdarzenia z podobnymi zdarzeniami w środowisku.

Istotne w całym systemie zarządzania dziennikami zdarzeń jest to, aby logi były odpowiednio zabezpieczone przed nieuprawnionym dostępem, usunięciem oraz modyfikacją, np. przez ich przesłanie do osobnego serwera gromadzącego logi.

Wymagania RODO

RODO samo w sobie nie jest aktem technicznym, a co za tym idzie –  nie narzuca konkretnych wytycznych, które dana aplikacja musi spełnić, aby można było ją uznać za zgodną z przepisami. I bardzo dobrze! Technologia cały czas idzie do przodu, wobec czego tekst rozporządzenia musiałby być aktualizowany co kilka miesięcy. Przepisy RODO odnoszą się jednak do bezpieczeństwa tworzonych i używanych systemów czy usług.

Privacy by design oraz privacy by default

Dwie siostrzane zasady wynikające z art. 25 RODO – privacy by design oraz privacy by default – wprost nakazują, aby tworzone systemy były bezpieczne oraz zapewniały maksymalną ochronę prywatności użytkowników. Już podczas projektowania systemu ochrony danych osobowych należy wdrażać takie środki, by od samego początku chronić przetwarzane dane oraz prywatność osób, których dane dotyczą. Po wdrożeniu systemu jego ustawienia domyślne powinny przewidywać możliwie najdalej posunięte zabezpieczenia danych osobowych. Ustawienia aplikacji domyślnie powinny udostępniać minimalną ilość informacji o użytkowniku.

Jak w praktyce zrealizować zasadę privacy by design?

• Należy przeprowadzić analizę ryzyka dla systemu. Najpierw twórcy powinni zderzyć wszelkie zagrożenia oraz podatności z rzeczywistością, a więc z kontekstem, w jakim będzie działała aplikacja (chociażby środowisko on premise czy cloud, wersja serwera, podatności charakterystyczne dla architektury, języka aplikacji itp.). W następnych krokach powinni wdrażać zabezpieczenia odpowiadające na określone zagrożenia. Dobrym pomysłem na weryfikację czy dopełnienie analizy zagrożeń są testy penetracyjne albo badania skanerami podatności.
• Należy wykonać ocenę skutków dla ochrony danych (DPiA), jeżeli jest wymagana. Jej celem jest weryfikacja, czy w procesie przetwarzania danych w systemie prywatność użytkownika jest odpowiednio chroniona.
• Konieczne jest stworzenie odpowiedniej dokumentacji projektowej, uwzględniającej to, w jaki sposób zostaną zrealizowane wymogi wynikające z RODO.

Realizacja praw użytkowników

Bezpieczeństwo to nie jedyny aspekt, z którym musimy się zmierzyć, gdy projektujemy, wdrażamy i utrzymujemy system. RODO nakazuje, aby zadbać również o prawa i wolności osób korzystających z naszych usług, czyli użytkowników, których dane znajdują się w systemie.

System powinien zapewniać użytkownikowi możliwość usunięcia jego danych (z wyjątkiem sytuacji, gdy administrator przetwarza dane, aby np. realizować obowiązek prawny, wykonać umowę lub dochodzić swoich praw). Każdy użytkownik powinien mieć także możliwość swobodnego importowania swoich danych z systemu (dotyczy to danych przetwarzanych na podstawie zgody lub umowy, nie obejmuje zaś danych przetwarzanych w ramach władzy lub interesu publicznego). Warto, aby użytkownik miał również interfejs, za pomocą którego będzie mógł edytować swoje dane (np. kontaktowe). Pozwoli to na realizację jego prawa do sprostowania danych.

Oczywiście, mówiąc o wymaganiach RODO, nie sposób nie wspomnieć o polityce prywatności  systemu. Informuje ona użytkowników o sposobie przetwarzania danych oraz ich prawach wynikających z RODO.