Często pracując jako analityk, oprócz weryfikacji wymagań funkcjonalnych i pozafunkcjonalnych, przy zamawianiu nowego systemu zwracam uwagę na kwestie bezpieczeństwa tworzonego rozwiązania. Jest to oczywiście analiza wstępna, duże firmy mają swoje odrębne działy bezpieczeństwa, lub chociaż application security architecta, który powinien dokładnie sprawdzać te tematy. Niemniej jednak chciałbym przedstawić Wam kilka zagadnień, które możemy brać pod uwagę przy takiej analizie. Może to być np. taka lista, do której powinien odnieść się dostawca:
- Architektura systemu musi być co najmniej trójwarstwowa, przy czym podstawowy podział na warstwy musi uwzględniać: warstwa danych (np. bazy danych, pliki), warstwa aplikacyjna (serwery aplikacyjne), warstwa prezentacji (serwery obsługujące interfejsy użytkownika, dostęp kliencki do systemu),
- Architektura systemu powinna pozwalać na fizyczną lub logiczną separacje poszczególnych jego warstw w odniesieniu do maszyn, segmentów sieci (np. VLAN), technologii NAT/PAT oraz dawać się rozdzielić za pomocą firewalli lub ruterów,
- Mechanizmy kontroli dostępu muszą egzekwować zasadę ograniczonego dostępu - wszystko co nie jest dozwolone jest zabronione,
- Zalecanym mechanizmem kontroli dostępu jest Mandatory Access Control,
- Aplikacja powinna bazować co najmniej na mechanizmach opartych o role,
- Dostęp do części administracyjnej aplikacji i części zarządzania treścią merytoryczną aplikacji nie może być udostępniony na zewnątrz,
- Aplikacja musi logować zdarzenia dotyczące kontroli dostępu,
- Wszystkie informacje i pliki konfiguracyjne związane z bezpieczeństwem aplikacji muszą być przechowywane w miejscach chronionych przed nieautoryzowanym dostępem,
- Konfiguracja serwera WWW musi zapobiegać indeksowaniu katalogów,
- Wszyscy użytkownicy aplikacji lub procesy wykonywane w imieniu tych użytkowników muszą być jednoznacznie zidentyfikowani przed uzyskaniem dostępu,
- Aplikacja musi posiadać mechanizm pozwalający na zmianę utraconego hasła w sposób bezpieczny z wykorzystaniem dodatkowego kanału komunikacji (np. e-mail lub SMS,
- Hasła do kont muszą być tworzone z użyciem ciągu zaburzającego (ang. salt),
- Domyślna polityka haseł powinna wymuszać tworzenie haseł o długości minimum 8 znaków, zawierających co najmniej jedną małą i dużą literę, cyfrę oraz znak specjalny,
- System powinien pamiętać co najmniej 6 ostatnio stosowanych haseł,
- Muszą istnieć mechanizmy zapewniające kontrolę sesji uwierzytelnionego użytkownika (np. zamykanie nieaktywnych sesji po określonym czasie),
- Identyfikator sesji nie może być krótszy niż 128 bitów,
- Maksymalny okres bezczynności użytkownika powinien wynosić 15 minut. Upłynięcie maksymalnego czasu bezczynności musi skutkować unieważnieniem sesji po stronie serwera oraz klienta (wylogowaniem),
- Dane uwierzytelniające nie mogą być zaszywane (ang. hardcoding) w kodzie aplikacji lub przekazywane w parametrach adresu URL,
- Aplikacja powinna stosować domyślną politykę blokowania ataków siłowych. Blokowanie możliwości uwierzytelnienia powinno następować po 5 nieudanych próbach,
- Aplikacja powinna wykrywać oraz blokować próby zautomatyzowanego logowania się na konta użytkowników z jednym hasłem (tzw. bruteforce horyzontalny),
- Muszą istnieć mechanizmy zapewniające kontrolę wprowadzanych danych (w przypadku wprowadzania ciągów znaków - ich format i składnię),
- Wszystkie źródła wejścia muszą posiadać zdefiniowaną stronę kodową np. UTF-8,
- Składowanie i przetwarzanie wrażliwych informacji w systemach, aplikacjach i bazach danych powinno być możliwe jedynie w postaci zaszyfrowanej (np. z użyciem natywnych mechanizmów szyfrujących),
- Aplikacja WWW udostępniona w sieci Internet musi stosować certyfikaty SSL wystawione przez zewnętrzne zaufane centrum certyfikacji. Dla szczególnie istotnych usług powinien to być certyfikat typu Extended Validation Certificate (EV SSL, ang. certyfikaty rozszerzonej walidacji),
- Stosowane moduły kryptograficzne muszą pracować w trybie zapewniającym należyty stopień bezpieczeństwa (stosowanie odpowiedniego źródła losowości, należyta obsługa błędów, zgodność z normami, standardami i wewnętrznymi politykami, a także najlepszymi praktykami w dziedzinie kryptografii),
- Aplikacja powinna mieć możliwość implementacji polityk określających zarządzanie kluczami kryptograficznymi (np. generowanie, rozprowadzanie, unieważnianie, w jaki sposób wygasają),
- Rekomendowane jest składowanie danych na dyskach twardych w postaci zaszyfrowanej algorytmem zapewniającym należyty stopień poufności np. AES-128,
- W przypadku budowy aplikacji z wykorzystaniem usług serwisowych (web services) należy stosować mechanizmy zapewniające poufność i integralność przesyłanych danych,
- Aplikacja musi rejestrować wszystkie zdarzenia, które mogą być pomocne w monitorowaniu poziomu bezpieczeństwa, analizie, ewentualnym dochodzeniu lub zgłoszeniu objawów naruszenia bezpieczeństwa,
- Każdy element dostarczanej aplikacji (np. front-end, repozytorium danych) powinien umożliwiać zastosowanie dodatkowych elementów realizujących redundancje,
- Zgodność aplikacji internetowej z wiodącymi na rynku przeglądarkami internetowymi (Internet Explorer w wersji 9,10,11 oraz najaktualniejszymi wersjami: Google Chrome, Mozilla Firefox, Safari, Opera) powinna być zapewniona przez ustalony okres czasu.
To tylko kilka punktów jakie mogą znaleźć się na liście bezpieczeństwa. Oczywiście dużo zależy od rodzaju tworzonego oprogramowania, klienta czy danych które będziemy przetwarzać. Odpowiednio wymagania mogą być bardziej restrykcyjne lub trochę łagodniejsze.
Kwestie bezpieczeństwa są bardzo ważne i nie należy o nich zapominać, mimo, że czasem nam nie po drodze np. przez napięty harmonogram czy zwiększenie kosztów :) Ataki na warstwę aplikacyjną są dużo trudniejsze do wykrycia niż na warstwę sieciową.
